Unveiled: Camelot Unchained Newsletter #54 - City State Entertainment View this email in your browser Share Tweet Team Tidings -by Max Porter Hey folks,



Welcome to the end-of-April newsletter, where we have lots to talk about in another great month of progress and updates to the game! We have been having lots of fun jumping in to test with our awesome Backers and the very dumb (but less dumb than they used to be) NPCs that we crowd the tests with to really stress the engine. I think the last I heard, the siege scenario we’re testing had over 200 trebuchets firing away, smashing their payloads into the mighty Tuatha Dé Danann keep, plus about 800 NPCs operating siege engines, magic mortars, and the like, and we’re still pushing that forward to greater and greater improvements.



You may have heard that mages are in for testing, ready to blast enemies into oblivion. Check out the recent Mageapalooza news post for a look at masses of mages manipulating their magic! The Siege of Cherry Keep has really led to some exciting screenshots, and the game is rolling forward at a tremendous pace. Filling the screen with chaos and fire has never been so fun! Chaarge!



In both offices, we’ve been the thankful recipients of so much assistance and many gifts from our wonderful Backers, most recently pizza from our Rich Creepy Uncle and of course lots and lots of testing assistance from so many Backers, so I’d just like to take this opportunity to thank you all from all of us. From start to finish, we truly could not make this game without your help.



Along with all of this progress, we consider it our responsibility to be extremely open and scrupulously honest. Therefore, we continue to put up raw, unedited, and unrehearsed streams, giving you a sense of how we’re moving along with our latest updates and news. The streams are fun for us, but they are also very important, as we always want to be as informative as possible for our Backers and fans, as we move through Beta 1! If you want to catch up on any missed streams, they can always be found on our Twitch and YouTube channels. For a good read of our news, as well as our weekly Top Tenish updates, check out the News section of our website.



So, what have we got for you this month? Well, in this issue of Unveiled we present a Dose of Design from Ben on developer tools, where he lays out the many challenges, twists, and turns that go into making and maintaining them. Not to be missed is Brian’s interview with the awesome Backer and builder Treville, chatting about everything under the sun, and especially Cherry Keep, which Treville built for the siege scenario! To cap off April’s newsletter, we’re bringing back the Artitup section to get some updates on animations with Scott! Should be a pretty full menu of good things to read!



As always, please click the “view this email in your browser” link on the top right to see the whole newsletter! Thank you for your interest, your support, and your awesome help with the development of Camelot Unchained™! Read on for updates, articles, and art, and please enjoy this, the fifty-fourth issue of Unveiled.

Hot Topics



We're looking for feedback! If you're a Backer, join the discussion on our Forums via our website and chime in.



Hot topics on the forums right now include discussion of the latest siege developments, rubble, Arcs and AoEs in our latest tests, excitement over testing of the new ability builder, and some of the marvelous constructions that enterprising builders are trying out for Camelot Unchained! Dose of Design -by Ben Pielstick Tackling the Tools

While building a game is largely a matter of programming and art, one thing that tends to get overlooked is the glue that sticks everything together: tools. In game development, tools are things like scripts that convert data from one format to another to import assets into the game, data entry forms that validate and compile raw alphanumeric input down to efficient database records in a format the game understands, and so on. Some game engines even have entire scripting languages that allow designers to implement gameplay systems without ever looking at the underlying code written by programmers that makes the game engine function.



When I say that tools are overlooked, I don’t just mean to players, for whom tools are as invisible as the code that makes the game run. I also mean by game studios, who have to focus on getting games done so much that they often don’t have time to fully develop and maintain their tools.



At a basic level, you could consider a tool to be any piece of software that helps developers make a game. Artists, in most instances, use software developed by outside sources, such as Adobe for Photoshop, or Autodesk for Maya. Programmers largely use Visual Studio from Microsoft, and even producers and designers have various applications outside of what is built in-house to develop the game. However, what are generally considered “tools,” in the colloquial sense, are the pieces of software specific to the game engine, which are often built and maintained by the studio to be unique to a specific game. These can be things like an item editor that allows designers to specify a model, visual effects, animations, and stats that define an item, or a model importer that lets artists define the materials, 3d meshes, and metadata that go together to make and add a model to the game.



Since games are big and complicated, and many tools have very specific uses, there tend to be a lot of them required to support a game. While you might think writing a bunch of small applications should be fairly easy, the real challenge tends to come over the course of a game’s development as the complexity of the game grows. While developers always have a long list of improvements and new features they want for tools to improve their workflows, changes to the game over time also tend to break functionality for the tools, due to changes to underlying features such as data format and communication protocols.



Since just keeping tools functional takes a lot of time, programmers working on tools end up spending a lot of their time just maintaining the current functionality of the tools. This often doesn’t leave much time for fixing minor bugs or adding new features, so tools often feel like they fall behind during the development of a game. In terms of studio priorities, it can also be hard to balance with hiring programmers who directly contribute toward adding features required for the completion of the game. It can also be difficult to even find tools programmers to hire, as there aren’t nearly as many developers out there specifically experienced in building and maintaining tools for games, compared to those focused on more general areas, like gameplay systems or graphics rendering.



Struggling with tools is an experience every designer is destined to run into at some point. Sometimes there are workarounds, like using “hacks” to make unintended use of features to accomplish something the tools wouldn’t otherwise allow. Other times, designs simply have to be changed, since something that should be theoretically possible just can’t be done due to the limitations of the tools.



As with virtually every game studio, CSE has had its share of challenges with tools. As an example, we have a solution right now for dealing with abilities: programmers implementing abilities directly through writing code. This isn’t ideal from a design perspective, but it does allow forward progress without diverting limited tools resources toward building an internal ability component editor. On the world building side, there are some pretty impressive features allowing nodes to be assembled into a graph that procedurally generates terrain based on a complex set of input parameters. The tradeoff for this is that the process of manually creating terrain is quite difficult, but is at least basically functional, so resources tend to be directed elsewhere rather than focused on improving it.



One of the big features for tools in progress is making it so that individual changes made using our tools can be tracked, so that we can easily revert changes for testing, and move individual changes from one internal development branch to another without copying the entire asset database. Obviously, this is a lot more important than making it a little easier to sculpt the terrain heightmap: thus, this is a great example of the types of prioritization decisions common in game development. This isn’t to say that this will always be the case. As the focus of the development of Camelot Unchained continues to shift from all of the basic foundational functionality to allowing us to produce fun content, the needs of the development team will change, and so will the tools. Developer Quote “People might not love Camelot Unchained, but I’ll be damned if they’ll hate it because our game was a buggy mess at launch. We test now so we don’t crash later. :)” -- Mark Jacobs Artitup -by Scott Trolan We have made a lot of improvements to our characters, first on the modeling side, and more recently, on the animation side of tech as well. This work changed and improved how we produce these assets, from modeling, to weighting, and finally animation. To accomplish this, we upgraded our tools right along with the art in a project we branded “Characters 2.0”. For those of you who have been with us awhile, and joined us in recent playtests, you have seen how vastly improved our characters look, and the still-ongoing improvements over our old animations. I’d like to take a few paragraphs to explain from an animator’s perspective how all of these changes created a better, easier, and more fun workflow!



First off, we transitioned our animation production software from 3ds Max to Maya. This was no easy task, as we needed to quickly migrate our character assets over to new file formats, making sure everything came through the process as expected. Additionally, there was a bit of a learning curve for some to come up to speed on the new interface and tools. Overall, Maya is a more favorable application, not only for animation but for its flexibility in customization, easier workflows, and tools both built in and third party. Additionally, one of our new animators was also well versed in creating custom tools in Maya, so it was a pretty obvious transition to make.







After the migration of our original character assets, it was time to begin using all the new fancy tools and custom scripts. But before doing so, we had to address the looming question...



“Do we continue using our assets as they are -- or do we take this time right now and improve all the things we now know we could make better?” This is always a dilemma projects face, as teams tend to improve their skills and tech over time. We all decided if ever there was a time to make it better, this was it, before beginning to make more armors and races.



We started by improving the look and feel of our characters in several areas including, texture resolutions, UV mapping regions, character scale and proportions, as well as the style and timing of our animations. These topics were covered by Tyler in previous newsletters! He discusses the character model changes HERE, animation changes HERE, and some of the wrap-up process HERE. In this article, we’ll be looking at how some of these changes have improved things for the animators.



Previously, many initially unknown restrictions or problem areas resided in our character models and rigs (skeletons). A lot of our animation work starts with poses, and we animate between them. Unfortunately, some of these character poses were difficult to achieve, because the character model would deform oddly based on the bone positions and weighting. Consequently, animation choices would be made based on hiding those results.



Because of this, we animators had a short list of improvements, that started with updating the character proportions. This allowed us to better line up the rig’s bones to the character mesh. In terms of proportions, we changed everything from head size, torso, arm, and leg lengths, and the size of the feet and hands. So basically, everything! Once we did that, a new master character skeleton was needed. We maintained bone names so we could reuse and retarget some of our older animations, but other than that, each bone was re-positioned and scaled to support the new character proportions.



We also took a step back and worked directly with our primary character artist, Jon, to improve the geometry of the characters in typically problematic areas around all the joints. Now, when we position our characters, we don’t get those previously-mentioned undesirable results where the character deforms...let’s just say oddly. When animating, this greatly freed us up to create more dynamic poses and attacks. The proportion changes and improved anatomy of the models helped a ton. Tyler even mentioned to me that I just seemed happier animating!



Along with using better tools in Maya, Joe, our Senior Animator, is quite the automator! Within Maya, Joe provides and updates scripts that expedite our more tedious tasks, and has also given us a whole host of other buttons to do just about everything. Really useful tools or scripts like quick selects, weapon/prop parenting, IK solutions for two-handed weapons, and group select for export buttons. “Bo... Joe knows Baseball.”



Previously, our Luchorpán shared the same animations based on the Human skeleton. This had limitations. Re-using Human animation prohibited us from maintaining signature features of the Luchorpan such as its head size, long fingers, and feet. Previously we would have had to reposition those fingers and feet in every animation! Now, using a third-party tool in Maya that Joe found, we can re-target animations originally done on the Human Skeleton. Doing so retains the Luchorpan’s uniqueness and saves us a lot of time!



Something new, which we’ve only briefly touched on during our live streams, is the new blending tech currently being implemented by our Tools/Gameplay Engineer, Mike D. This will allow us to support more diversity between character types without making a ton of unique animations. We are currently testing the flexibility of blending modes between unique idle animation sets and shared generic weapon attacks and locomotions. Capitalizing on this saves a lot of time, yet allows us to maintain unique Realm or class visuals on a chaotic battlefield!



After updating our characters to our “2.0” changes, animating with these new assets has been a delight. Natural postures and movements are much more recognizable when done right (even more so when done wrong!). We’re saving much more time, not only in how we create these animations, but also in the number of assets we need to create!



Even with all these new additions to our animation development, we still have more improvements coming. I feel the most important one is the “variable speed timing” support that goes hand-in-hand with the game’s ability system design (more info linked above). I’m very excited to see that put into action in the game! Of course there’s still more to come, but for now, it’s back to work to get all those weapon animations updated and back into the game! Thanks for reading!



Death to “1.0”.

Long live “2.0!!”



Scott Community Spotlight -by Brian Ward Interview with Treville, the Builder of Cherry Keep

In between catching up on house chores and watching Avengers: Endgame (seriously, go see it!), I took some time this weekend to speak with Backer Treville of the Builders’ Brigade about his experience building the massive Cherry Keep stronghold, featured in recent playtests. Interview has been edited for length.



Brian: So tell us a bit about your background. Are you generally into design? What drew you towards being a builder?



Treville: My background is not in design at all! I mean, outside in that whole "real world" thing, I'm a business major! I've always loved to design things, though. My passion really began as a kid creating interesting drawings and designs to build — "projects" as I called them (my father called them nightmares! [...]). That really hit its peak when my older brother and I created a working eight or nine foot tall trebuchet when I was eight [...]. Needless to say, my father was furious that we used a large amount of his wood supplies, but... I mean... it was a WORKING trebuchet! He never seemed to be as impressed about it as us, tragically. Later on I got into website design and just loved thinking outside of the box. Design in general has always been a wonderful creative outlet, and it was a natural progression to go into the building design with Camelot Unchained, in fact, the building design was one of the two things that sold me on this game; the other was Mark Jacobs, as I am a former Dark Age of Camelot player.



B: So you already have a preexisting relationship with the destructive power of trebuchets! What’s it like to build a 9.4 million block keep and watch it get brutally destroyed by hundreds of them over and over again?



T: Well, needless to say, I've had to hire the services of a therapist now to get over the shock of seeing my building get pummeled repeatedly!



When [CSE] sent us the initial files, I was absolutely elated! Although I have been a Backer for years, I was a later addition to the Builders’ Brigade, so I never got to work on any project prior to this castle. I devoured the information for the build requirements, and excitedly loaded up the rough that [they] provided the builders to use as our guide to the overall size and scope of the build. It was massive! You can see what they gave us in a previous newsletter if you are so inclined [Editor’s note: see Unveiled #52 - So It Begins: Building A Battle]. I was beaming ear-to-ear at a project of this size and scope, and couldn't wait to start! I knew CSE would give us a while to make this thing look great, probably a month or two, and I couldn't wait to try to make a TDD version of Helm's Deep! Then I reread the build document and saw we had two weeks to build this monstrosity; the panic attack immediately set in, and I started laughing hysterically! [...]



The build was a challenge, but after nearly ninety hours of revisions and design, I was able to call it a job completed, and watch you fine Backers and CSE ravage the castle over, and over, and over, and over, and over, and over again! I'm thrilled to have been able to create this castle and enjoy seeing players get a chance to decimate the castle! It's such a fun part of Camelot Unchained to see the building destruction and physics in action.



B: What do you think about building destruction tech in general, and what it will bring to CU?



T: The building destruction tech in Camelot Unchained is unparalleled, and an absolute industry-changing creation by CSE. Admittedly, during some of the earlier iterations, I was concerned that it would not work as intended, but the team has made leaps and bounds in the past three months, and the technology is absolutely astonishing. I've never played a game that made me so excited for strategically capturing a building as Camelot Unchained. This tech will keep builders on their toes for new ways to build structures and always keep the game interesting! No two sieges will be the same, and that is a wildly exciting prospect. I can't think of any gamer who would balk at a game that intuitively changes in a dynamic way every time you perform a key function of gameplay.



B: What are some things you want people to know about your build — now known as Cherry Keep?



T: First, I hope the Backers enjoy it! There was a lot of design that went into the build as a whole, and sadly some of the things I wanted to add could not be added, as they would have taken far too much time to make work. I went through many rough sketches before I came to the design you see now in those scenarios. The castle is made with the defenders in mind, as there are many chokepoints in the design, and the final stand area in the throne room. The downside, for balance, is that there are ways for the attackers to cut off a lot of the paths to certain parts of the castle with proper siege strikes.



Fun Fact: At one point during the building of Cherry Keep, a bug caused me to no longer be able to load up the build files, and I freaked out! I had apparently stumbled upon a bug, one of several, that dealt with the new BPO system [Editor’s note: see Unveiled #51 - Beep Beep! What are BPOs?]. I immediately begged Matt for help, and he got right on it, fixing the code to save Cherry Keep! Otherwise, there would never have been this castle! [...]



Cherry Keep was definitely a labor of love, and one I would gladly do again! In fact, I nearly made a second version that was a Viking build, as I had an initial sketch of that as well; but once Arrobee joined in the building process, I quickly stayed true to TDD. Hopefully, this build inspires more Backers to try their hand at building, as a lot went into it, from a technology perspective, by CSE. Matt created the amazing BPOs for this scenario, Tyler created a gorgeous area, Brian kept them from killing me, and was the point-man to get things to the right people, and of course Andrew and Colin did an amazing job getting the physics and destruction to make a quantum leap. This was a huge team effort, and the game systems made huge leaps in the creation of this scenario! [...]



B: To you, what defines the style of TDD architecture?



T: TDD Style, for me, is a very hard mark to hit. The beauty of this Realm is that there are so many styles that really fit it! My idea of their architecture could be drastically different from someone else's idea. When I built Arthurian designs, there was really a set historical precedents, so I had issues being able to build outside of that box, and with Vikings I really have only ever had a single building style and could not come up with another appealing option. However, with TDD I have several different styles!



The Wurlitzer [Editor’s note: see Unveiled #47 - Community Spotlight] and Cherry Keep both fall into the same "Aristocratic TDD" style, which is more columns and stonework, while some of the non-defensive designs I have incorporated a lot of wood design and have a very organic feel to them. That's the beauty of TDD; I can have something that is robust and stone-centric like the Cherry Keep, something far more Fae and menacing such as Scott Florence's awesome build he was working on for this project, or a highly organic Elven building style that still fits within the framework. I absolutely love the variety that this Realm offers!



B: Do you have any ideas for what you might make next?



T: Oh, I'm already working on that now! But it will stay shrouded in mystery until I post it on the Backer's Forums! Moreover, I will be releasing updated "Building 101" videos to help new (and old!) community members who want to build get on their feet quickly, so keep an eye out for those. The more builders, the better!



B: Anything you want to add?



T: I just want to add a huge thank you to the CSE team, once again, and all their amazing help during this project! I really got to know a few of them better and see their amazing work ethic, drive, and passion for this project. So thanks for dealing with my crazy self and helping me, Matt, Tyler, and Brian!



Camelot Unchained has been delayed over the years, but getting the "peek behind the curtain" I was allowed during this project, I can definitely say this project could not be in better hands, and any frustration I've felt for the delays was alleviated knowing how amazing the team that is developing this title is, and how great a game Camelot Unchained will be when all is said and done! Thanks City State for all that you guys do, and enabling people like me to build to my heart's content! (And people who just want to siege those buildings to oblivion!)



B: Thanks so much for taking the time today!



T: You're welcome! Final Note -by Max Porter And that’s Unveiled number fifty-four! Thanks so much for reading our end-of-the-month newsletter update! It is always a huge pleasure for me to put this together, and I hope you’ve enjoyed reading it as much as I have had writing and editing it! I’m already looking forward to next month’s update progress! That’s all for now, so until next time -- Max out!