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



That was August! We have been very busy and got a lot done, and in this newsletter we take a look back at the month and how things went. You’re probably tired of hearing this, but we never get tired of having one: it was a good month overall!



It’s been a hot summer here in downtown Fairfax, Va., and I hear the same is true on the other coast. However, we have had some breaks in the weather, and some truly gorgeous days, so I’m hoping for another lucky break for the holiday weekend!



The heat hasn’t slowed us down, however, as we have made swift progress over the month. In our weekly updates, Tyler often mentions how quick our concept artists are. We actually had so many ideas for these NPC Draugr mages we didn’t show it all in that week’s update, instead deciding to split them between the update and this month’s newsletter!



Tyler says the cool thing about these ideas is how different all of them are. This is an important skill to learn as a concept artist, going very wide with your ideas to start! Tyler adds that once a choice is made on these, we’ll come back to these concepts when it’s time to add more NPCs to the world of CU.



Lots of things to talk about as always this month, with progress on gameplay, server stability, and many important art assets! Check out the State of the Build for a selection of the Top Tenish items from the month. Also, Ben has a Dose of Design article on making changes to the design of games, and Brian has brought back the classic CMsphere article format! Should be a good read!



Our determination rarely wavers to stay true to our principles of openness, honesty, and being upfront about our progress. We published news posts, ran tests, and continued 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 for reading up on Camelot Unchained, thank you for your support, and thank you again and again for your patience. 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. Continue reading for updates, articles, thoughts, news, and more, and please enjoy this, the fifty-eighth 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 our latest tests, questions on 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! Dose of Design -by Ben Pielstick The Challenges of Change

In last month’s newsletter, I talked about the challenges presented when making changes to the design of a game. By contrast, there are also times when opportunities for change present themselves, but need to be left unexplored in favor of maintaining a strong core experience. Change to existing features just for the sake of change takes time away from changes where they are really needed, and the addition of new features that can add a lot of value to the game. Too many changes can also cause confusion or dissatisfaction within a game’s active playerbase, and can even leave developers confused about what exactly the game is supposed to be about. Unnecessary changes can easily happen in game design, however, because nothing is ever completely perfect.



Whether from playing a game or by gathering feedback from players or QA testers, designers will often determine that there are some problems that could be addressed by making changes. The first question that needs to be asked in these cases is whether potential changes will move the game away from its core defining concept. In the case of Camelot Unchained, these core things are summarized as Foundational Principles, but most games have something similar, like formalized high-level design documentation or summaries from pre-production meeting notes. If changes to a game would fundamentally alter the core vision of what the game was originally intended to be, there is a very high risk that the game may falter, losing its identity and confusing both players and developers.



Even when changes don’t alter the core concept of what a game is all about, it is still possible they could cause more problems than they solve. A good change will be one where almost all the players like the new version of the game better than the old version by a significant enough amount to make them alter their behavior. Depending on the game, this might be keeping their subscription longer (important in CU), spending more money on microtransactions (not really a thing in CU), or simply staying engaged longer and participating in activities that were previously neglected.



In actuality, when changes are made, the results can sometimes be a lot less favorable, with some portion of the players preferring the newly updated version of the game, while another significant portion prefer the old version. This means that the desired changes in behavior improve in one portion of the players, but also become negative in another portion. If the balance between positive and negative responses ends up as a net positive, developers can often consider changes to be successful, but these results can be deceptive.



When developers see that the results of a change have improved slightly overall, or at least remained neutral, it is easy to assume that more changes might be needed in order to improve the situation further. Layering changes on top of changes however, increases the risk of alienating players, and actually reducing engagement in the long term.



A term sometimes used in game development that describes changes made over and over that never seem to end up with a good solution is ‘thrashing’. There are a lot of reasons design thrashing can happen. Sometimes it is because designers are assigned to work on managing and improving part of a game like its progression or economy, so their official job is basically making changes over and over again because that is what they’ve been assigned to do. Sometimes a new designer has been put in charge of a system, and they have a different idea of what would make that system more fun than the previous designer in charge of it, and start to change it to fit their personal vision.



Thrashing can even happen simply due to excessive feedback. When developers keep receiving feedback indicating that players aren’t satisfied with a feature, whether from metrics, chat and forum feedback, on social media, or in exit surveys, developers often focus their attention on what they identify as the top issues that could make the biggest difference in improving the game. While being responsive to feedback is generally a good thing, changes have to be considered carefully so that the results don’t end up worse than how things started.



For example, if developers discovered a lot of negative feedback surrounding the way character stats worked, they might do a stat revamp, adding and removing some stats, and changing the functionality of existing stats. Since changes are almost never universally liked and objectively better, inevitably some players will like the new changes, and some players will like things better the old way.



Some time later, if developers discover there is still too much negative feedback regarding stats, some of which of course being players asking for the old system back, they might decide to do another revamp to the system. This revamp might drive the system in a third entirely different direction, or it might be some kind of compromise between the second system and the first, to try and win over players who didn’t like the changes. Both of these possibilities are perilous, however. A new direction splinters the opinions among players even further, creating a group of players who liked the first system, a group of players who liked the second system, and a group of players who like the third system. A compromise, on the other hand, risks displeasing both sides, and leaving virtually no one happy. If half the players like red and half the players like blue, compromising on purple is not the best solution.



Going a step further and creating another set of changes, making a fourth revamp to the system is even less likely to improve the situation. It is not impossible, of course, that far down the line a designer may come up with something brilliant, which far exceeds the player satisfaction levels of all previous versions of a system, but the more changes happen, the less likely this becomes.



This is of course not to say that designers should never revamp failing systems, but there are a lot of considerations to keep in mind, so that efforts to improve the game are made in the right places. If a designer really believes in a feature that clearly isn’t succeeding, instead of revamping it, they might instead help explain it better, by improving the interface and providing more information to players who might actually like the system if they better understood it. It might also be better, in some cases, to simply accept certain criticisms as unnecessary to address, focusing effort instead on things like adding something new to the game that will make a bigger difference to a lot more players.



For Camelot Unchained, of course, we’re always looking to make improvements, because our game is still in Beta testing, and a lot of what we put forward is a very early work in progress that we want to get feedback on before finalizing. At the same time, there are certain things we will not compromise on, even if a lot of potential players wish we would. These things can be either near the core of what defines the game, or simply low priority, compared to work along the critical path we have to follow in order to get the game ready to launch. After the game has launched, we will be even more careful about making changes, and most importantly will be focused on adding features. Whether that is new ability components or whole new classes, new enemies for The Depths and crafting materials to discover, or entire expansion packs adding whole new systems to the game that never existed as part of the launch featureset, we have a lot in mind for the future of Camelot Unchained. We hope you’ll be sticking with us as we focus on what’s important to bring you all the best RvR MMO we can. Developer Quote “I wish that we’d hadn’t been so late but I know that we couldn’t have delivered that experience 2 years ago if we had used a commercial engine for the same reason nobody else has either – they weren’t built for it. Our engine is and the proof, well, it’s in the rubble, not the pudding. :)” -- Mark Jacobs CMsphere -by Brian Ward Muggy! That’s the way it’s been this past week in the Seattle area, and I’ve been very grateful to be able to hide away in the office for much of it, with the notable exception of Wednesday, when obligations forced me out into the summer weather -- an experience, for sure.

Playtesting

Our recent playtest this month went off without a hitch. We had a good turnout of 120 concurrent testers, the build performed excellently, and I think I speak for all when I say that it was fun as hell! There have been numerous Community requests for a test like this -- scheduled far in advance -- and I’m very happy that we were able to deliver that to you. Keep your requests coming: We’re listening!



Backer and aspiring photojournalist Scott Florence captured this breathtaking shot from Cherry Keep during the siege, showcasing the scale of battles our engine supports: Event Notice

MJ will be at Dragon Con this weekend in Atlanta. If you’re going to be in the area, be sure to stop by and see him. I hear that Andrew may be going as well! The event runs Aug. 29th – Sept. 2nd and you can get all the details about it at their website: https://www.dragoncon.org/



Community Q&A

This section is where we gather unique questions from the community and answer them for you.



I thought this would be a fun one to print up since it came up in one of the streams with MJ a few months back and I thought you all would enjoy hearing the answer, especially since Odulvic was very patient about pursuing an answer for the question! ;-)



Odulvic: A long time ago, in a[n] office far, far away, I once asked MJ if there was a hidden meaning to the CSE logo, to which MJ said yes and he might share it with us one day. Is this the day we are looking for?



MJ: There’s potentially two meanings to the City State logo. Many years ago, after EA and I parted ways, I thought what would be cool would be to set up another game studio -- what a surprise! Thought about where to do it; how to do it. And the idea of setting up a studio in Asia came up. And a company that I had worked with in the past thought that would be a good idea as well, so once my non-compete with EA ended, I actually started discussions for that. After all, you know, I’m so big and scary, I needed an NCA from EA. So I entered into those negotiations. *sigh* Nine months later, unfortunately, I pulled out of the negotiations. Things were taking way too long, and I really wanted to get back to making games and I’d already blown a year because of the non-compete. And then, you know, remember it was eight months, nine months on the negotiations. The government that we were negotiating with was of course… drumroll (one of the only city-states in the world): Singapore. And so I thought what a great name for a studio in Singapore; I was kind of shocked that nobody else had thought of that, but they hadn’t, and so City State Entertainment was gonna be its name.



Now, other people have told me that they thought that maybe I had another reason for that name. And that it was a reference to my time in EA. And how there was a quote (by a gentleman I won’t name, not because I have anything against him, but because I try to be very polite when it comes to these things) that all the studios in EA were like city-states, and this was a retort to that -- and I simply left that alone. And so some people think that that’s a slight and subtle dig at EA, which it actually isn’t. The first reason for the name -- and the main reason -- was because I was in negotiation with Singapore. I love Singapore; I had a fantastic visit there, and I met some great folks from the government, and I thought that could be really cool. Loved that, and I still do. I thought Singapore was just amazing. And you know, when it all fell through, I still liked the name; therefore, City State Entertainment.

What’s up (with the servers), Doc?

For diagnostic purposes, we collect tons of operational data about the state of our servers. We have plenty of dashboards around the office to tell us all about specific aspects in very fine detail. But one thing we didn’t have readily available was a simple at-a-glance view of the state of all our various systems. There used to be one around, but it was a bit opaque in terms of its presentation of information.



Personally, I like to be able to see exactly what’s going on from a high level, especially since I’m often managing a number of servers simultaneously during testing. So for my purposes, I addressed this lack of visibility late last year by creating a simple terminal-based status dashboard that became invaluable to me. It would tell me which zones were up and what maps they were on, show various channel metadata info, and even the status of connections between certain servers. Very useful!



As time went on and others saw this tool over my shoulders, I was tasked with creating a new app based upon it, but with a much more visual and interactive look to it. I call it GlanceView and it’s based on the same idea. The app is written in Python and the setup is fairly simple: One thread gathers info from various data sources which it collates into a single JSON stream, then we emit that data via an API running on another thread to any connected clients, whether they are web-based or in the terminal. Over time, I look forward to adding more features to GlanceView and making it even more useful to the team!



Thank you!



And thus concludes this month’s edition of CMSphere! I’ll be attending PAX West on Friday, so if you happen to see me there, say hi! Thanks for participating in our playtests, for taking the time to provide detailed feedback in your Forum posts, and for just generally being a supporter of what we’re doing. It’s all extremely helpful to us, and we can’t thank you enough. State of the Build -by Max Porter Hey folks, in this section I pull some of the highlights from our Top Tenish lists in the past month. The highlights of the highlights, if you will! This should give you a summary of some of the biggest pieces of work that we have focused on in the month of July, and a sense of where we’re at!



Gameplay: (8/9/2019) - Tech – Gameplay: Matt and Christina added support for items that react when a player collides with them. This should be the first step in getting traps into the game.

Matt and Christina added support for items that react when a player collides with them. This should be the first step in getting traps into the game. (8/16/2019) - WIP – Tech – NPC Behavior: This week, Spidey worked on a new objective component, which allows the server to track objectives and instruct NPCs where to go. This should help the NPCs in the point capture scenario do something constructive, instead of just being mindless targets.

This week, Spidey worked on a new objective component, which allows the server to track objectives and instruct NPCs where to go. This should help the NPCs in the point capture scenario do something constructive, instead of just being mindless targets. (8/16/2019) - Tech – Physics: This week, Colin added support for parent/child relationships on server-side physics actors. This will let us create triggers that spawn relative to another entity and report collisions to that entity. We can use this to create items that add status effects when players get close to them.

This week, Colin added support for parent/child relationships on server-side physics actors. This will let us create triggers that spawn relative to another entity and report collisions to that entity. We can use this to create items that add status effects when players get close to them. (8/23/2019) - Tech – Abilities: Anthony cleaned up null references and bad data in our defs, so all of our CSVTests pass again. Some of our ability data (and related stuff like item scripts) had small problems like Null descriptions or names, and a few even had wrong IDs (which would have had gameplay implications downstream). We created tests that try to detect some of those, and Christina fancied them up to be more aggressive in finding problems.

Anthony cleaned up null references and bad data in our defs, so all of our CSVTests pass again. Some of our ability data (and related stuff like item scripts) had small problems like Null descriptions or names, and a few even had wrong IDs (which would have had gameplay implications downstream). We created tests that try to detect some of those, and Christina fancied them up to be more aggressive in finding problems. (8/23/2019) - Tech/Art – Traps and Dragons: Joe assisted Christina this week by providing some simple assets and animation to test the functionality of traps. He also worked with Mike D. to test whether we could add animations to that really old, and very ugly, dragon model we’ve had flying overhead. Verifying this latter functionality works will allow us to create various ambient animated models.

The Big Server Linuxification: (8/2/2019) - WIP – Tech – Servers: Colin and Wylie (With some Andrew support) continued to work on switching our servers to Linux this week. Wylie converted the City State memory library so that it is compatible with the Linux server, and Colin changed how the game server runs embedded native servers (physics, proxy, and building). It now executes the native code using p/invoke instead of C++/CLI. This will let us run the embedded native servers on Linux, leading to lower server costs.

Colin and Wylie (With some Andrew support) continued to work on switching our servers to Linux this week. Wylie converted the City State memory library so that it is compatible with the Linux server, and Colin changed how the game server runs embedded native servers (physics, proxy, and building). It now executes the native code using p/invoke instead of C++/CLI. This will let us run the embedded native servers on Linux, leading to lower server costs. (8/9/2019) - WIP – Tech – Servers – Linuxification: Andrew has made a lot of progress on the Linuxification front. He has got all the projects rebuilt through user proxies, which is one of CU’s biggest scaling points, and is now working on the physics side of things. As a reminder, this work, and the following Linux-related items, will help us cut server costs.

Andrew has made a lot of progress on the Linuxification front. He has got all the projects rebuilt through user proxies, which is one of CU’s biggest scaling points, and is now working on the physics side of things. As a reminder, this work, and the following Linux-related items, will help us cut server costs. (8/16/2019) - WIP – Tech – Servers: Wylie and George have converted more code from Microsoft’s standard to the stricter C++ standard, which is key to supporting different compilers. Up next is work to support non-standard features on Linux, which are typically OS features like IO, threading and system resource management. The reason for our switch to Linux is to reduce our overall server costs.

Wylie and George have converted more code from Microsoft’s standard to the stricter C++ standard, which is key to supporting different compilers. Up next is work to support non-standard features on Linux, which are typically OS features like IO, threading and system resource management. The reason for our switch to Linux is to reduce our overall server costs. (8/23/2019) - WIP – Tech – Linuxification: This week, Colin finished converting the NPC server to .Net core. This was a necessary step in our ongoing Linuxification of the servers, and will help us save money on server costs.

This week, Colin finished converting the NPC server to .Net core. This was a necessary step in our ongoing Linuxification of the servers, and will help us save money on server costs. (8/23/2019) - WIP – Tech – More Linuxification: This week, Wylie continued work on Linuxification. He replaced Windows code with “portable” code, that can perform the same task on different operating systems.

This week, Wylie continued work on Linuxification. He replaced Windows code with “portable” code, that can perform the same task on different operating systems. (8/23/2019) - Wip – Tech – Even More Linux: One of the major components of getting our system to run and compile on Linux is our unique parallel structure. George focused on this work in order to assist the other engineers’ ongoing work. Feature and Tools Work: (8/2/2019) - WIP – Tech – Knockback: This week, Matt continued working on improving knockback, but ran into complications in the interaction with player movement. Luckily, we had planned to make improvements there as well, but it will take more time and careful thought before we’ll see the improvements. Making player movement feel responsive and lag-free in a networked server-authoritative game is quite a challenge!

This week, Matt continued working on improving knockback, but ran into complications in the interaction with player movement. Luckily, we had planned to make improvements there as well, but it will take more time and careful thought before we’ll see the improvements. Making player movement feel responsive and lag-free in a networked server-authoritative game is quite a challenge! (8/2/2019) - WIP – Tech – Audio: Spidey made some new audio performance improvements this week. Now the game only generates audio objects for entities that are within audible range, which reduced the amount of active audio objects in a siege scenario from ~2600 down to ~400. This greatly improves client audio performance and profiling overhead. dB’s work just got much easier!

Spidey made some new audio performance improvements this week. Now the game only generates audio objects for entities that are within audible range, which reduced the amount of active audio objects in a siege scenario from ~2600 down to ~400. This greatly improves client audio performance and profiling overhead. dB’s work just got much easier! (8/2/2019) - WIP – Tech – Trigger Volumes : Caleb has been refining the way trigger volumes are integrated with the ability system. He has added event forwarding, which allows a trigger volume to forward its collision events to its parent entity and script parameters, which allows content designers to craft simpler scripts and reuse them. This work will allow us to do more interesting things gameplay-wise.

: Caleb has been refining the way trigger volumes are integrated with the ability system. He has added event forwarding, which allows a trigger volume to forward its collision events to its parent entity and script parameters, which allows content designers to craft simpler scripts and reuse them. This work will allow us to do more interesting things gameplay-wise. (8/9/2019) - WIP – Tech – NavMesh: Lee continued on his quest to bring pathing to the game via the NavMesh. Mark showed this off earlier in the week, following through with our promise that our NPCs would not remain dumb as rocks. This week, Lee worked on 3D-ification of the NavMesh/pathplanner to handle pathing on surfaces above other surfaces, such as ramparts and stairs. He also doubled the speed of the vertex welder (part of the mesh simplifier system) and improved/fixed the algorithm for obstacle detection for the NavMesh, adding data for heights to the obstacles.

Lee continued on his quest to bring pathing to the game via the NavMesh. Mark showed this off earlier in the week, following through with our promise that our NPCs would not remain dumb as rocks. This week, Lee worked on 3D-ification of the NavMesh/pathplanner to handle pathing on surfaces above other surfaces, such as ramparts and stairs. He also doubled the speed of the vertex welder (part of the mesh simplifier system) and improved/fixed the algorithm for obstacle detection for the NavMesh, adding data for heights to the obstacles. (8/9/2019) - WIP – Tech – Design Tools: Bull worked on a tool that will make it easier to load and configure data in spreadsheets. Our designers will be able to use this for versioning and rapid iteration.

Bull worked on a tool that will make it easier to load and configure data in spreadsheets. Our designers will be able to use this for versioning and rapid iteration. (8/9/2019) - WIP – Tech – Tools: We’re working on a tool to automate starting and tearing down Shards. We made a web frontend, and are making it smarter about the order in which Instances are started up, waiting for connection to be established, users logged in, server running, etc. An added output with error reporting helps us with troubleshooting.

(8/16/2019) - WIP – Tech – Tools – Visual Debugging: This week, Matt worked on a system to let other engineers send visual debugging information like shapes, lines, and text from within server-side gameplay and NPC code. We had the ability to do this for some specific systems already, but this will be a lot more versatile. While no one outside the team should ever actually see any of this, Backers will get to enjoy abilities hitting the right targets and NPCs walking to the right places.

This week, Matt worked on a system to let other engineers send visual debugging information like shapes, lines, and text from within server-side gameplay and NPC code. We had the ability to do this for some specific systems already, but this will be a lot more versatile. While no one outside the team should ever actually see any of this, Backers will get to enjoy abilities hitting the right targets and NPCs walking to the right places. (8/23/2019) - WIP – Tech – NavMesh: Lee continued on his quest to get proper NPC pathing into the game. He converted Navmesh and pathplanner to understand 3D coordinates. This is the first major step to getting the navmesh and pathplanner to deal with multiple layers and elevations in our world, and allow NPCs to path on structures that are stacked on top of each other, such as battlements and towers.

All Kinds of Art: (8/9/2019) WIP - Tech - Tools: Matt and Rob spent a good deal of time fixing up some long-outstanding issues with our editor tools. This has made artists’ lives easier when working in the editor, and should help us speed up a lot of Art and Design tasks. As we move forward, we should be able to do more faster, particularly Rob’s work on improved placement of assets in the world editor.

Matt and Rob spent a good deal of time fixing up some long-outstanding issues with our editor tools. This has made artists’ lives easier when working in the editor, and should help us speed up a lot of Art and Design tasks. As we move forward, we should be able to do more faster, particularly Rob’s work on improved placement of assets in the world editor. (8/16/2019) Art - Concept - Draugr Armor Variations: Michelle created several armor part variations to help add more variation to these models. A pile of these guys coming at you will probably be pretty intimidating, when added later in production.

Michelle created several armor part variations to help add more variation to these models. A pile of these guys coming at you will probably be pretty intimidating, when added later in production. (8/23/2019) Art - Concept NPCs: I can confidently say we have quick concept artists. This week, we completed over eight pages of concept art primarily focused on what we’re calling magic-using Draugar. Now the hard part is figuring out which ones we might like to see in CU down the road!

I can confidently say we have quick concept artists. This week, we completed over eight pages of concept art primarily focused on what we’re calling magic-using Draugar. Now the hard part is figuring out which ones we might like to see in CU down the road! (8/23/2019) Tech/Art - Traps and Dragons: Joe assisted Christina this week by providing some simple assets and animation to test the functionality of traps. He also worked with Mike D. to test whether we could add animations to that really old, and very ugly, dragon model we’ve had flying overhead. Verifying this latter functionality works will allow us to create various ambient animated models.

Joe assisted Christina this week by providing some simple assets and animation to test the functionality of traps. He also worked with Mike D. to test whether we could add animations to that really old, and very ugly, dragon model we’ve had flying overhead. Verifying this latter functionality works will allow us to create various ambient animated models. (8/23/2019) - WIP – Art – Procedural Materials: This week, we focused on some procedural materials for props, such as boxes and barrels. The ongoing goal of this work is to provide a consistent material library for artists to use, that ideally requires less hand painting than we’ve previously had to do. Obviously this cuts down on the time to create new art assets, while making it easier to not only tweak the textures later, but also create variations faster.

This week, we focused on some procedural materials for props, such as boxes and barrels. The ongoing goal of this work is to provide a consistent material library for artists to use, that ideally requires less hand painting than we’ve previously had to do. Obviously this cuts down on the time to create new art assets, while making it easier to not only tweak the textures later, but also create variations faster. (8/30/2019) Art - Weapons: We created several new weapons this week. Check out the update for images. We’ll add these in later when we finalize the crafting model for weapons and armor.

We created several new weapons this week. Check out the update for images. We’ll add these in later when we finalize the crafting model for weapons and armor. (8/30/2019) Art - Armor: We created a couple of new helmets, which you can also check out in the update! Just like with the swords the final work will be committed dependent upon the crafting model. Final Note -by Max Porter Thanks for reading Unveiled number fifty-eight! As always, I hope you’ve enjoyed reading this newsletter as much as I enjoy putting it together. I’m hoping for more good weather coming up, but we’ll see! Looking forward to more progress, anyhow. Stay cool, and that that’s all for now -- Max out!