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



Happy end of June! It’s a hot summer day as I write this here in beautiful downtown Fairfax, Va, and the season is definitely getting into full swing.



There are lots of things to talk about this month, in terms of progress made, tests completed, and important pieces getting into the game! Over the past five or six weeks we’ve been overachieving, as you can see from the extra long Top Tenish highlight lists in our news updates! Not only that, but lots of the updates are especially exciting for those of us who are really into sieges. For example, rams have been coming along nicely: As well as Doors, which are giving us super important tech, and which you can read more about in this very newsletter! I really can’t wait to connect those two things together with a loud BOOM noise. Check out this newsletter’s articles for tons of details on how all of that is going, from Ben’s Dose of Design on Why Designing Games is Hard, to Tyler and Mike’s Art It Up article It’s Just a Door (that will tell you how it’s NOT just a door), and Brian’s interview with Caleb, which will give you tons of intricate technical details!



We’ve also got this fun little project going on in the background which you can read more about in today’s update email!







As always, we have remained firm in our strong commitment to openness, honesty, and being upfront about the game. To assist in updating you all with the latest in how things are moving rapidly along, we continue to put up raw, unedited, and unrehearsed streams! 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, whom we thank for their support and patience 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.



Thanks as always for your patience, support, or just interest in Camelot Unchained®. As usual, please bear with my reminder to click the “view this email in your browser” link in the top right to see the whole newsletter. Read on for updates, articles, thoughts, news, and more, and please enjoy this, the fifty-sixth 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 using rams and doors, the latest siege developments, rubble, theories and excitement over the classes as we develop them, and as usual, some of the marvelous constructions that enterprising builders are trying out for Camelot Unchained! Look What You Did -by Brian Ward It’s been a while, so we thought it might be good fun to do another contest! Now, we’ve recently been looking at the island Point Capture scenario in playtesting. Seems like a rich source of inspiration! Write up your fan fiction story about capturing an island in 250 words or less and make a post to the Forums in the Roleplay & Fan Fiction section. (Brian’s bonus writing prompts: How did you get there? Why are you fighting? And what adventures did you have while you were there?) We’ll pick a winner and feature it in next month’s newsletter! Dose of Design -by Ben Pielstick Why Designing Games is Hard

In a recent livestream I was asked a question about the most difficult thing I’ve had to design for Camelot Unchained. While it is easy to point to specific features or pieces of content and say that they were harder to design than others, it is a little more difficult to explain why game design in general is so hard.



Games that don’t turn out well can often be faulted for their art not looking appealing enough, or the state of their tech if it crashes or contains bugs that detract too much from the experience. More than anything else, I feel that games tend to run into problems based on their design. Partially this is because games by their nature are interactive experiences, and design defines the interactions players are able to experience; but also, the types of challenges design runs into can often be exceptionally difficult, and to a degree that is easily overlooked.



If you aren’t familiar with game design as a discipline, you might expect that a designer’s job is primarily coming up with game ideas. While this, along with documenting those ideas, is definitely part of design, it is actually a very small part, and the limits placed on ideas are what make it especially challenging. When writing up a design document, designers have to keep in mind the limitations of the project they are working on. This includes known limitations, like the technical capabilities of the engine they are working with, and time limitations for how long it will take to produce all the art. Unfortunately there are also unknown limitations, since the designer doesn’t know what difficulties will be encountered along the way when attempting to implement the design.



You can think of designing without knowing all the limits like trying to color in a coloring book without being able to see all the lines. Later, when all the lines are revealed and you see you’ve colored outside of them, you have to decide whether to reign in the coloring, or have someone redraw the lines. In game design, a lot of time and effort goes into dealing with these situations. Maybe a feature that on the surface seemed easy runs into technical problems that would take weeks to resolve, or maybe a level design turns out to be too complicated to run at a good framerate. These are some of the most difficult types of problems for designers to deal with.



Simply removing features wherever problems are encountered is an easy fix, but runs the risk of cutting too deeply and removing too much fun from the game. Sticking by the original design no matter what, on the other hand, forces crunch time or delays to overcome the problems, in order to somehow make the original design work. The best solution possible, when trying to solve this kind of problem, is the one where the design can be adjusted in a way that players won’t notice the difference, or one that ends up with something roughly equivalent that ends up being just as fun as the original design. Coming up with something that stays within the limitations and doesn’t compromise too much on quality is exceptionally difficult, but is something designers have to try and do all the time.



Even when all the art and technical challenges have been overcome for part of a design, the big question still remains: Is it fun? As much as we as designers try and get things right the first time, the reality is that the first pass at putting something into a game is rarely the final pass. What normally happens is a feature gets implemented, some testing happens, and a lot of feedback is generated on what needs to be done to improve upon the feature. The response to this feedback can lead to anything from ripping the feature out entirely to ignoring the feedback and shipping the feature as-is, but usually things end up somewhere in between. This starts us on another big part of design work: iteration. Once a feature goes into testing, designers gather any feedback from testers, along with any metrics that provide a statistical picture of how different parts of the test went, and start making changes to the design to make things better for the next test. What kinds of changes depends on the type of feature being iterated upon, but can involve things like changing health and damage values, changing the number and types of enemies in part of a level, or revising the layout of the user interface.



Once a set of changes have been made, another round of testing ensues, and the process repeats. Iteration can go on for many rounds in order to make a feature fun, but can also have to end early if a project runs out of time, or if it becomes apparent that a feature simply isn’t getting any better, and needs to be cut and possibly replaced with something else. This puts pressure on designers to make iteration cycles short, and to make the right decisions about what and how much to change in each iteration cycle in order to get a feature to a shippable state as quickly as possible.



And so, keep in mind that game design is a lot more than just coming up with ideas. Design ideas have to be constrained by known technical and production limitations, account for unexpected limitations discovered during implementation, and be iterated upon again and again in order to reach a finished state. The video game world is full of fun ideas, coming from professional designers, other developers, and even players. Being able to think up ideas and select good ideas from others is an important part of design, but only a small part compared to taking those ideas and working them through the process of becoming real playable experiences. That’s what most of game design is really about, and why it is a lot harder than it may seem. Developer Quote “To date, no [other] MMORPG has shown that they can handle 1K battles with players, all close-up and personal like, on a small patch of land. Building that tech has been the greatest challenge for us and as history has shown, everybody else who tried to do it.” -- Mark Jacobs Art It Up/Tech Central -by Tyler Rockwell and Mike Dickheiser When Max asked if I (Tyler) had any thoughts on an article for the newsletter, I was a little stumped. Ideally, I try to write something relevant to what we’re tackling at the time and that also gives some insight into the work involved.



At the moment, most of the artists are working through bugs or finishing up existing work. So the question was, “What challenges are we working on right now?” Doors! Exciting, right? From an art perspective, doors are actually pretty easy, which is why it didn’t immediately seem like a great topic. However, part of my job is to be the glue between Art and Engineering and Design; to pull all the pieces together while meeting the needs of designers and engineers. So it felt right to make this more of an art and tech article, rather than solely art.



Let’s start with the easy stuff, and look at the art. Our doors in CU will come with a frame that fits within the ½ meter block size of our building system. This frame will allow us to make various door shapes and sizes that are not strictly rectangles. It also allows us to add more visual flair specific to each Realm. For our initial needs to test the tech, we pulled an old door from our library that we’d made ages ago. Scott rigged the door so it could be animated, and added bones as corresponding attachment points that players would need to be near to activate the door opening and closing, depending on the side you’re on. All of which was using new supporting code. With a simple open and close animation complete, we handed this off to Mike to use as a test case.



In order to further explain how complicated getting doors into CU is I’m going to pull in a co-writer on this article. Mike is a relatively new engineer with CSE, but he has already become known as a talented, hard-working problem solver, making him a great add to the team.



Mike:



When we set out to add doors to the game, what we were really embarking upon was the development of a generalized system that supports an open-ended variety of “Animated Items.” These are things that players can place in the world, collide with, attach to buildings, interact with in some way, and generally bring their creations and the CU world to life with motion and dynamic gameplay-affecting elements.





Doors are a great first example of the impact of this system on the game. They enable players to change the traversability of the world by creating or revealing hidden or protected spaces, but they are just the beginning. The system has paved the way not only for other door-like things, such as windows, trap doors, portcullises, and drawbridges, but countless other motion-rich objects, like waving flags, water wheels, and windmills. Down the road a bit, we will be able to support composite objects, such as double-doors built into attached frames that are placeable and usable as a single object, and items like chairs, which allow interactions that change the actions and animations of the players using them.



In this regard, Animated Items exercise and test the limits of every part of the system, from the client to the various servers on the backend. When a door opens, for example, every player in the world needs to see the door in the same initial closed state, and then witness smooth animated motion as the door opens. This chain of events begins when a player uses a door in their client, which then notifies a Game Server of the action, which then propagates the continuous motion simultaneously to a dedicated Physics Server and to all attached clients. Easy, right?



Synchronization of the animation is just the beginning. The physics of the door must also be consistent, so that the door blocks all players as expected, and not just some of them, or different ones on different clients. Further, the animation and physics must coincide accurately, so that visual representation of the door matches the physical. Complicating things further still, the physical location and orientation of an item must match for all players, in addition to the animated parts within the item. Imagine a huge castle door attached to a building that is in the middle of opening when it gets blown out of the wall and starts tumbling to the ground. Making that look and feel awesome and consistent for all players is not just a worthy challenge, but a necessity for an event that has such a huge impact on the navigability of the world and physical response of affected entities.



Orchestrating all this synchronization for doors, and animated items in general, was the bulk of the challenge for this feature. Yet the orchestration was not limited to the results in the game itself. This feature required some serious teamwork and communication. No less than four different development efforts ran simultaneously in different code branches, and ultimately had to be reconciled, harmonized, and merged before everything could come to life. Building Placed Object Entities, Multi-interaction Siege Engines, Physics Synchronization, and Animated Items were all in development at the same time, largely overlapping in the code and data they touched, each with substantial improvements and additions to the Client, Game Server, and the Physics Server.



And we pulled it off. In the end, we brought all of these efforts together and into the game, forever increasing the array of possibilities for player interactions with the world and other players.



Tyler:



Over several weeks, we went through pages of doors with their own unique styling per Realm. Here’s a selection of basic TDD doors: At the beginning of this newsletter, you may have seen a render of Jon’s sculpt of the first test door that is currently being integrated into Cherry Keep by the Builder Treville. It’s huge, at about 29 meters high! Here’s some other variations of TDD large doors we concepted: Working on the doors has not only presented a lot of known work to be completed, but also a lot of random unknowns we stumble upon. One of my favorite issues we noticed was the doors, when open, can’t swing past 90’ or you can potentially trap players in the space behind the door, depending on the structure around it. Here’s a quick doodle illustrating this fun little problem. Thanks for joining us for a little insight into what it takes to get a simple door into the game, and honestly, there’re still quite a few other issues I didn’t add, as this article would just go on and on. So next time you see a door in CU, useable by players, animating, falling apart with rubble, colliding with players and the world, you’ll know a whole pile of work was required for that "simple" door!



Tyler and Mike out! Developer Spotlight -by Brian Ward Interview with Caleb Fisher

I took a few minutes this week to catch up with developer Caleb!



Brian: What’s your role at CSE?



Caleb: I started as a gameplay engineer, but then I started getting into more backend gameplay support systems. There were a few missing architectural blocks around entities and the data for NPCs and the event system, so at this point, support systems for gameplay. It’s kind of deeper gameplay.





B: Tell us about your background before you came to the studio.



C: Actually, I have an interesting path. I first got a degree in painting and marketing. Then I f***ed around for a couple of years and finally went back to school at the prestigious game school in Redmond, WA called DigiPen. Went there for 4 years, learned programming, and got out of there and did game [programming] for a company called Z2, a mobile game company in downtown Seattle, and now I’m here!



I worked on three big efforts [at Z2] that are notable. One was called Shadowslayer. It was kind of like a casual Diablo for mobile. You have a single character and you discover a little town and you build up the town. Kind of light city builder, and then you go off on adventures to kill little things and bring the resources back to level up your town or to craft more gear. Some nice story elements: We had a pretty good writer who wrote some great dialog for it.



Second game was a dogfighting plane game. Z2’s original claim to fame was MetalStorm, so we were making a new version of that. It was kind of highly-cinematic, highly-scripted. Like combat on rails; like a rails shooter a little bit. Kind of like the new Ace Combat game for PlayStation, etc. Very highly-scripted dogfighting. So that was really cool: It was a prototype effort, and was also that studio’s first effort using Unity, so we had a lot of guinea pig things going on. [...]



And then after that, Z2 is then acquired by King. [...] I started working on the other flagship game of the studio, Rise of Tyrants, which was a similar city builder plus kind of tactical army battler where you recruit units, build tanks, and go fight against other people.



B: Give us a peek into the daily life of a gameplay programmer. Is it all unicorns and rainbows?



C: [...] There are definitely teams I’ve been on where it was unicorns and rainbows all day long. We’d come in energized, sit down, have your meetings for the day, get pumped up, have constant communication throughout the day, showing each other things. Mobile is real fast-paced -- at Z2 we had some very nice LiveOps tools -- we could roll things out and test market it every other day. To get that kind of constant feedback is very invigorating. You can see your ideas tested really quickly.



So the transition from that fast-paced environment to [CSE] has been interesting for me. I had not been on features that last this long. It [can take] weeks to get an entity system and the editor and the networking all kind of singing. Granted, I didn’t have to rebuild integral parts of the architecture as often as I’ve had to do here. These kind of very long efforts I’ve been a part of are new to me. [...]



It presents different challenges -- I enjoy these challenges -- they are hard problems; they can’t be solved in two days. You can’t go get data on these right away: You have to sit back and really consider the technical requirements for what we’re gonna do on the Client and on the Proxies and on the Game Server and on the Web API and how the data is going to get to Progression. All these data formats all have to be solved at once.



B: What are your most recognizable contributions to Camelot Unchained?



C: Easily the most recognizable to players would be the scenario system, the main way that people interact with our game features during our test period. Scenarios were designed to be a well-structured set of features we want to test, and just adding some light gameplay parameters around incentivizing doing those behaviors.



Like gaining points for kills is an easy way to do Deathmatch. At this point, we can pretty much generate points for anything. We can generate points for capturing a point and holding it over time, for doing damage to buildings or destroying buildings, for whatever it is we want to incentivize players to do. We could do it for resource collection and crafting when we get there, so this system was just designed to help structure tests. I basically built that system, it was one of the first things I was tasked to do [at CSE].



That naturally lead into our ECT system, which is our Entity Component Template, which is basically just a data format we use from the Editor to get into zones and scenarios. It was kind of the data format that scenarios use to initialize entities. So the Entity Factory consumes those ECTs and spits out Entity Instances, so that was a very important system that I built as well, to make scenarios work.



The next step in getting scenarios to work was the Post Office. The original notion was that we don’t have a generic way for servers to talk to each other, like: I fired a message, somebody else is listening for it, and they’ll get that message. Up until this point, it’s been very like: I need to make a TCP connection with you, and I am sending you this very specific command, and you have to know how to interpret that. Post Office round one was a generic attempt at making the subscription and receive be very easy. And that was successful. With the Ability changes that we’ve had recently, we are also integrating the Post Office to that system. That changed the nature of the Post Office a little bit, in that it needed to have thousands and thousands of registrations and message sends through it.



B: At a really high level, is the Post Office, like, various things are subscribed to listening to certain types of messages, and if you send a message to a certain list of things, then the Post Office will just deal with all the people who have subscribed to this and get that kind of message?



C: Exactly. It’s a pattern called pub/sub, which is you publish and subscribe. Users subscribe to the system and say, “I care about messages that fit this shape,” and then anything that produces messages just fires off messages in different shapes. And the Post Office, which is a pub/sub system basically, says, “oh, that shape fits this hole. here’s all the subscribers for that hole.” And that had some very interesting optimization constraints that we had to have for the Ability System, given the volume of events the Ability System creates. [It] needs to be extremely optimized, but also flexible enough that it’s easy to script and write gameplay against those events.



The Post Office will be used heavily to connect things happening across zones. There’s been talk of having highly-scripted interactions from zone to zone to zone that all the players interact with in a way that is meaningful and helps drive PvP engagement, and those systems need a loosely coupled messaging system that is powerful as well. That ties into scenarios, [as] scenarios will begin to use the Post Office more and more to create more and more varied gameplay and interesting interactions.





B: Tell us about the future of scenarios. How will they differ from what’s in the final game?



C: My understanding [...] is that the scenarios aren’t really going to be used in the way that they face the community right now: Those are strictly for testing.



In the long run though, scenarios [what] they really are is a bucket of ECTs that go together in a cohesive fashion. Scenarios can absolutely be used for events, and those can be overlaid on top of the world. So say we have some main city and we do -- the example we’ve used just arbitrarily -- [is] a “Halloween Event.” We can litter the world with pumpkins in ECTs and say that that’s the [hypothetical] Halloween Scenario, and when we bring [it] online, all the pumpkins show up and everyone is in that scenario, and we can track player states separately specifically just for “Halloween” events, if we want to do it that way.



It’s really just a vehicle for grouping Entities and State together and having some rules around how people interact with them. We can use it for events, we could use it for one-off instances, we could absolutely use it for The Depths. A scenario will be an instance of something happening in those Depths. Scenarios can also be used -- with some retooling -- to create random chunks of the world. Say we want to have a little scene where there’s a burning caravan and a bunch of NPCs running around on fire and monsters are attacking it and there’s some scripted things we want to have happen as you approach it. That could be a little scenario. [...]



We’ve talked about having random inputs, almost like randomly generating those little scenes. So scenarios could be used that way as well. I alluded to earlier that there’s talk of a system that connects all those zones together. It’s possible that that will also be scenario-driven as well: That the different pieces of that interconnected system will be considered a scenario.



So basically changing in every way possible: Going from instanced battles to integrating with the world.





B: One last light one: What do you like to do for fun? I know that you like gloomy board games.



C: Played a lot of Gloomhaven, the initial set. The expansion just came out, so hopefully I’ll be able to play that a little bit. I am a family man. I’ve got two kids and a wife and I love spending time with them. And we live in beautiful Seattle, so this summer is going to be full of camping. My son is in scouts, so that’s good times. That’s about it! Final Note -by Max Porter Thanks for reading Unveiled number fifty-six! I always enjoy putting this newsletter together for you folks, and I hope you have enjoyed reading. As always, I’m already looking forward to next month, and to more progress! Thanks again, and that’s all for now, so -- Max out!