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



Welcome to our end-of-May newsletter! It has certainly been another month chock-full of progress and there’s lots, as always, to talk about! Whether you’re interested in our tech, our sieges, our mage classes, gameplay, or any of a host of other developments on Camelot Unchained®, this month has something that might catch your attention!



For example, and speaking of mages, look at the new ability components, which we showed on stream with JB and Ben--check out that presentation here! It’s been a rainy spring here at the East Coast CSE office, storms sweeping by to bring new growth in the summer. Time for May flowers after the April showers, right? And we’re looking forward to the fruits of our efforts paying off in the development of the great game we’ve promised both you and ourselves that we’ll make.



Storms, you say? Water, you say? Here’s what we showed for the Wave Weaver: And not to be outdone, the Flame Warden’s ability components: And the Druid’s ability components as well! We ran tests, we worked on doors and on both existing and new siege weapons and abilities and lots of other things, we listened to feedback, and moved forward on innumerable other aspects of the game. You can read about Ben’s plans and thoughts on game balance in his Dose of Design article presented below, or get to know one of our less-often-seen devs, Matt, in an interview that Brian, our Community Manager, transcribed! That’s followed up with a bunch of updates collected in the State of the Build by yours truly from all our weekly news emails this past month. Should make for a good read, wherever your interest lies!



In addition to this progress, we have continued to make a big effort to live up to what we consider 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.



Thanks for reading, folks! And 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-fifth 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 Perfecting Balance

One of the biggest concerns for players in PvP-centric games is how well the game will be balanced. Poor balance unfortunately results in some classes or factions being overplayed due to being considered overpowered, while others get neglected and relegated to obscurity. This only lasts of course until the developers release a balance patch, which throws players’ understanding of what is good and bad into chaos, forcing them to relearn a lot of the essentials for how to approach combat. When developers make changes to improve the balance of the game, it often does get better, but it almost never gets perfect, so further changes are made, on and on indefinitely for the lifetime of the game.



Why can’t developers ever seem to get balance right? Sure, some games have better balance than others, but it never seems to be perfect, as even the most tightly tuned e-sports games continue to get balance patches month after month. The answer is that complex systems are fundamentally impossible to balance.



For example, let’s assume we have two characters, and with all things considered, they have the same effective health and do perfectly equal DPS. Assuming no drastic divergence in difficulty to play, we could likely call this balanced. The challenge comes in when we start making things more complicated. What if one of the characters has ranged attacks and the other has melee attacks? Assuming this is the only difference we add to this example, how much health and/or damage do we need to add to the melee character in order to achieve perfect balance? The answer of course, is that it depends. In areas of the environment where characters can stay far apart, we would have to add a lot of health and/or damage to the melee character for them to be able to compete, while in areas with lots of cover and limited line of sight, the amount would have to be much less.



When it comes to designing for situations like this, the starting point is just a guess. Maybe the starting number is 20% or 40% or whatever intuitively feels right, so that gets plugged in and that’s where testing begins. Initially, we might play the game a little bit and find our first guess was far out of line, or it might actually seem we guessed pretty well. This starts a process of iteration where we make changes, test, and make changes again, hopefully in smaller and smaller increments, until we’re happy enough to reach a stopping point.



This is all before anyone else gets a chance to test the balance. Once testing starts involving other people, either other developers at the studio, or outside testers, feedback tends to start driving attention. “The squeaky wheel gets the grease” as they say, which is fairly accurate, at least at first, as the most obvious balance problems tend to be called out the loudest and most frequently in initial testing, and therefore get addressed. Iteration then continues from here, involving an increasingly wider group of players, and getting more and more refined over time.



Sometimes this is as much balance as a game gets, but wherever possible, it can be incredibly helpful for designers to also leverage metrics. Recording real numbers from the game and compiling them into charts and graphs provides a far more objective view of the actual state of balance than anecdotal commentary. Metrics of course have their own problems, as the type of metrics you gather don’t always paint a perfect picture of what actually matters to players in the game. For example if you mainly rely on overall damage output as a metric, you may miss the possibility that one character’s burst damage potential gets them more kills, but if you also look at killing blows, you may overlook the amount of survivability a class uses to escape from fights and avoid being killed themselves.



It can safely be said that none of the typical tools used to balance games are good enough to ever achieve perfect results. Nor does the very nature of games with varied and complex mechanics lend itself to being perfectly balanced in any objective and universal way. For Camelot Unchained, however, we are doing some special and non-standard things, that will hopefully have a positive impact on how balance plays out.



The most significant difference you should definitely be aware of when it comes to balance in Camelot Unchained, is that not all classes are intended to be equally powerful when fighting one another. Most games, when they approach balance, start out with the intention of making every character equally good in a 1v1 duel against every other character. For Camelot Unchained, on the other hand, not only are all classes not equally effective in 1v1, but classes are also given intentional advantages against some opponents, and disadvantages against others. Mechanically, this is implemented with things like damage types and resistances, and various buffs and debuffs that affect some classes much more significantly than others.



The intent behind this is to establish a much more rock-paper-scissors state of balance, than one where every class is on relatively equal footing. In theory, this would make it very hard to create a tier list for Camelot Unchained, because whatever the top class is considered to be, has at least one opposing class that has them at a significant disadvantage. And so, if there ever is a sort of ‘flavor of the month’ class that is seen as overpowered and starts to get overplayed, a countermeasure should already be available, as players of opposing Realms can choose to shift toward the classes that counter the enemies they tend to meet, and reach a state of relative balance in terms of each Realm as a whole.



One big advantage to this approach from a design perspective, is that balance doesn’t have to be perfect. If you’re striving for perfect balance, even a tiny difference can tip the scales to one side or the other, but if you’re striving for deliberate imbalance, as long as A is strong against B, it doesn’t matter nearly as much exactly how strong, as long as A is also weak against C, and so on.





This isn’t to say that even with our approach, balance will ever seem perfect. There will definitely be balance changes over the course of the rest of beta testing, leading up to launch and beyond. Hopefully however, these changes will have to be a lot less frequent and substantial than in some similar games which don’t take this approach to the way they handle balance.



Right now, Camelot Unchained is very much in the early stages when it comes to balance. Abilities for all the existing classes have had to be re-implemented as of the recent improvements to the ability system. Some ability components still haven’t been implemented due to limitations, or at least aren’t fully functional to meet their intended design, as programmers continue to improve the code support for the ability system and ability effects.



In the midst of all this, we are in the process of doing a first pass on class balance, by going through each class one by one, testing all of their components in many different combinations, and ensuring each class meets the basic goals set out for them. Once this has been finished internally, we will be running more frequent balance focus tests, where our Backers can come in and take a look at how well each class performs, and offer their feedback and suggestions, not only as to what is balanced, but what would make each class more fun to play. We look forward to seeing many of you in these upcoming tests, and hope to share some deeper insights into what the game looks like with the rest of you who have been actively following the game, once we’ve finished some of the outstanding work and can really demonstrate an early view of what combat in CU will eventually become. Developer Quote “Being able to destroy a 9.4M block building, in real-time, with progressive damage and block-by-block destruction networked across all the players is a pretty big deal. So you can take that for what it’s worth. :)” -- Mark Jacobs Developer Spotlight -by Brian Ward Interview with Matt Meehan

I took a few minutes this week to catch up with developer Matt, who just finished a cross-country move and is now enjoying life from a secret, remote cabin in the woods.



Brian: What is your role at CSE?



Matt: I am a programmer and I tend to do a lot of behind-the-scenes kind of end-to-end plumbing work a lot of the time, occasionally with exciting big things like the first pass of Siege Engines and Building Placed Objects. A little bit of [the] jack-of-all-trades, generalist kind of thing.



Brian: How did you get into programming? Have you always worked in game dev?



Matt: I did not start out in game dev. I had a longstanding dream of getting into [that] from when I was very young and was playing things like Warcraft 2, which I played in a computer lab at school. But I initially started out in more enterprise software [when] I went to Microsoft. I actually started out as an SDET, which [stands for] Software Development Engineer in Test, so I was writing test cases and things when I first got started professionally.



[B]efore that, in college, I worked on a campus website thing professionally, so I had a college programming job. My first industry job was less game, more enterprise-focused. I only got into games two — maybe three — years before I joined CSE. I’ve been here for two years, so it’s been like five now. And I had first worked on a little, mobile Age of Empires game at Microsoft, and that was the first game that I ever really worked on professionally.



Brian: Talk about previous projects that you’ve worked on. You mentioned work at Microsoft.



Matt: Going way back, when I first joined Microsoft, I was working on a part of the .NET Framework that was a server and client communication stack. And so I had a background in networking and data-driven services. When I made the decision to get into games, there was a position on the server side for a mobile Age of Empires game, and I was able to make a transition to that even though I didn’t have any game development experience; I had service development experience. And so I was kind of able to make this transition based on that skillset and then over the course of working on that game — shipping that game, supporting that game in production — that studio was growing and we were actually going to make some Unreal [Engine] games and so I started getting experience with client stuff.



There was a re-org that moved around all of our stuff and I ended up leaving Microsoft by choice. And I joined a small studio in Bellevue called DropForge as a prototyper. We had a prototyping team and we built something like six to eight really quick and fun prototype games in Unity and so I did that for a while and then I was here. So I’m still dying to ship a game where I’ve made a real contribution to the game itself. The fact that I’ve been getting to work on a lot of our client-side stuff here has been really rewarding for that reason, because I know that when Camelot Unchained ships, I’ll have actually, really done some client-side game work, as opposed to server backend-y stuff.



Brian: Where are your fingerprints on Camelot Unchained? What are your most vital contributions?



Matt: I’ve gotten to do a lot of tweaking of other stuff that was already there, so it’s hard to point at one thing and say, “oh yeah, that was all mine.” But when we needed to add Siege Engines — they’re kind of like a Player, and kind of like an Item — and so somebody had to go through and change the way a bunch of those systems worked to make them support what we needed them to do for Siege Engines. So I’ve had a little bit of a hand in a lot of different places. I basically put C.U.B.E. back together, but I didn’t really design any of that.



I guess the one thing is like the way the Coherent integration works. I had a lot of control over how I put that together and the way that threading works. It’s basically lock-free all throughout how the game communicates out to the UI, and so I had a lot of control over that; George kind of let me run wild there. That’s probably the one thing that I’ve had the most sort of significant fingerprint on, if you will, is the way that that layer is setup.



Brian: What’s it like to make an MMO?



Matt: It is hard to make an MMO. I think a lot of people — I mean I [played] MMOs; I played WoW for years. I don’t think I ever really realized how much more difficult it is than making a traditional single-player game. It’s all the problems of an open world game plus all the problems of a competitive, networked, fast-paced kind of game. We’re real-time, we’re open world-ish, where we’ve got massive scale to deal with. It’s just everywhere you look, it’s like harder than it would be if you weren’t trying to do it.



And then on top of that, Camelot Unchained is trying to break all these established norms around: How many players can you get on the screen? Can you do player-based buildings? And all the other things. Oh, you know — server-based physics? Sure, let’s do that!



Brian: What do you think is probably most unexpected that you’ve found during the process of [making an MMO] compared to when you started? What would be the thing going into it that you didn’t realize?



Matt: The biggest thing has been how many people it takes to really put something together. When you’re just building little client-only type games you still need art and everything, but you can realistically do something yourself. For an MMO, there aren’t enough hours in the day for you to have a hand on everything. Even something like Siege Engines, where I had kind of hammered it through from end-to-end, there was stuff that got tossed over to Christina and to [other] people because it’s a big thing and there’s a lot of moving parts.



Brian: What has been your biggest challenge and your greatest success?



Matt: So the greatest challenge has tended to be that we’re a small company. I came from Microsoft, so I was used to having a lot of people to spread work around and to bounce ideas off of. Having sort of really strong — you know like bumpers in a bowling alley?



Brian: Sort of guardrails.



Matt: Guardrails, yeah! Safety nets or various things. We’re like an indie studio trying to make this very difficult thing, and there’s so much individual-driven decision making. Getting it to a point where I was comfortable doing that took some time and was a challenge. And quite frankly, learning the codebase. There were years of work before I showed up, and having to just sort of dive in and pick the pieces up is quite a lot to take on sometimes. You probably started a little bit after I started on Building Mode, but I had never really seen what Building Mode looked like before it got handed to me, so I had to simultaneously figure out: How did the code work? But also, what the hell did it do? What the hell should it do?



Brian: Any secret plans for upcoming features that you can discuss? What would you like to work on next in the game?



Matt: There’s a lot of really cool stuff happening right now around Siege Engines, and Items, and Doors, and all this other kind of cool stuff that I’ve been largely having to help from a distance with because I’ve been so busy with the Building Placed Objects work. I’m kind of excited that maybe when I wrap this up a little bit, I can get back to helping out with that. There’s also some cool UI stuff coming with the custom Ability Bars and that kind of thing that I would actually like to see that actually land. There’s a handful of things that are really exciting, but I don’t necessarily like to be the guy doing the flashy thing; I like to do mostly support stuff in the background.



Brian: When not programming, what do you like to do for fun?



Matt: Well, tabletop gaming is a big one. PC and console gaming. The last game that I really sank my teeth into was Horizon Zero Dawn, which I was playing super late. I actually play a weekly tabletop game remotely with Max, Dave, Cory (formerly of CSE), and Max’s wife. So it’s been really fun to get to know those guys outside of work.



Also, my wife and I do a ton of volunteering with animal shelters. We’re huge into our pets and taking care of pets at shelters and things, so that takes up a lot of time too, but that’s very rewarding.



Brian: You recently moved into a cabin in the woods? Are you secretly a Luchorpán, and is it telling that you always have an in-game playtesting character ready to go named “CSE-Matt-TreeCreep”?



Matt: [laughing] So that was my default playtesting character for a while, because I really liked the funny name that I’d come up with. But I’m less a forest elf than a curmudgeonly hermit, so I don’t know which race matches that the best, but I did recently move to a rural area; enjoying it quite a bit. I was getting tired of my condo and looking in on the neighbors essentially all the time. Also, we couldn’t have a dog and now we have a dog. State of the Build -by Max Porter In this piece, I’ve put together a few of the weekly update Top Tenish items from the past month. As those are the highlights of a week, and these are some highlights on those, you might consider this the highlights of the highlights, or some of the significant updates from this month! As always, keep in mind that this is just a small selection from a much, much longer list!



Doors (5/3/2019) WIP – Tech – Doors: We have started work on doors that work as, well, doors. Besides basic animations and permissions, we’re also looking at the tech needed for portcullises and drawbridges and how they may interact with players unfortunate enough to be hit with them as they open and close.

We have started work on doors that work as, well, doors. Besides basic animations and permissions, we’re also looking at the tech needed for portcullises and drawbridges and how they may interact with players unfortunate enough to be hit with them as they open and close. (5/10/2019) WIP – Tech – Doors: This week, a good amount of work was done to bring doors into the game. Christina added a persistent state system for items, so we can remember when our doors are opened/closed, build simple-state machines, etc. This is all data-driven, so we’ll be able to use it for much more than just doors. She also added damage resistances for all our damage types to deployable items. This way you can have a door (or any deployable item) that is extra strong against ice attacks, for example, but maybe isn’t as strong against fire. She also worked on the gameserver side of animating doors, so they can open and close while Mike D is working on the client side ensuring the doors look good while animating.

This week, a good amount of work was done to bring doors into the game. (5/17/2019) WIP – Tech – Doors: The architecture is in place for a generalized notion of ItemEntities that can animate and have animated collision, of which doors will be the first working example. The connectivity between game server, physics server, and client is nearly done, such that next week we should have animation state changes propagating between each part of the system. This lays the groundwork for bringing the world to life with objects that can interact dynamically in a variety of ways, such as doors, drawbridges, animated item destruction, and more.

The architecture is in place for a generalized notion of ItemEntities that can animate and have animated collision, of which doors will be the first working example. The connectivity between game server, physics server, and client is nearly done, such that next week we should have animation state changes propagating between each part of the system. This lays the groundwork for bringing the world to life with objects that can interact dynamically in a variety of ways, such as doors, drawbridges, animated item destruction, and more. (5/24/2019) WIP – Tech – Doors: Christina now has doors animating based on a trigger through our scripting system, and we can now destroy doors. This work also supports the use of FX and animations, which will be more than a little handy when objects are destroyed! Mike D. is working on matching the physics shape to the animation of the visual object. This work will later allow us to do much more with player-interactable objects that animate!

Ability Builder (5/3/2019) Tech – Ability Builder: The ability builder is back! AJ and Christina have landed the new ability builder UI, and we have started our initial testing with our Internal Testers. We hope to get it into players’ hands next week!

The ability builder is back! AJ and Christina have landed the new ability builder UI, and we have started our initial testing with our Internal Testers. We hope to get it into players’ hands next week! (5/3/2019) WIP – Tech – Ability Book: Now that we have the ability builder, AJ is creating a place to store all the abilities that can be created. The ability book will be the repository for all your creations!

Now that we have the ability builder, AJ is creating a place to store all the abilities that can be created. The ability book will be the repository for all your creations! (5/24/2019) Tech – Ability Book: AJ and Christina have landed the first pass of the ability book (Hooray!) for initial internal testing. The ability book will be a player’s ability repository, where they can see the abilities they created, modify them, and later–once we add it–see their progress in leveling up components.

Siege Tech (5/3/2019) WIP – Tech – Movable Siege Engines: We have started working on making siege engines mobile. Players will be able to reposition siege engines, such as trebuchets, on the battlefield.

We have started working on making siege engines mobile. Players will be able to reposition siege engines, such as trebuchets, on the battlefield. (5/17/2019) WIP – Tech – Siege Movement: Spidey has completed the proof-of-concept for moving a siege engine around the battlefield. In this early iteration, players “push” a siege engine. We are working on the tech to add more player attach points, so multiple players can work together in order to move the engine rapidly across the terrain.

Spidey has completed the proof-of-concept for moving a siege engine around the battlefield. In this early iteration, players “push” a siege engine. We are working on the tech to add more player attach points, so multiple players can work together in order to move the engine rapidly across the terrain. (5/24/2019) WIP – Tech – Siege Controls: Spidey has now moved onto the next step of siege engines, which adds multiple control points to a siege engine. Our first use case he’s working on is the new battering rams! This will allow us to have several players working together to boost the engine’s performance, or perform different tasks such as loading, aiming, or driving.

Design (5/3/2019) WIP – Design – Various: Ben has been busy this week. He’s speccing out the framework for the entire game world terrain, designing how ships will work, and working on the design of doors and new siege engines with Mark and other members of the team.

Ben has been busy this week. He’s speccing out the framework for the entire game world terrain, designing how ships will work, and working on the design of doors and new siege engines with Mark and other members of the team. (5/10/2019) WIP – Design – World Map: This week, Ben finished setting up all the island zones for the world map. Once he receives a set of basic terrain mods to use, he will be able to do the blockout for each zone, marking where each biome goes for mountains, forests, etc.

This week, Ben finished setting up all the island zones for the world map. Once he receives a set of basic terrain mods to use, he will be able to do the blockout for each zone, marking where each biome goes for mountains, forests, etc. (5/17/2019) Design – World and Mages: Ben continued work on the world design, as well as his presentation on mages. If you have any questions about mages, start with our previously mentioned livestream HERE.

Ben continued work on the world design, as well as his presentation on mages. If you have any questions about mages, start with our previously mentioned livestream HERE. (5/24/2019) WIP – Design – Balance Pass: First off, let’s state that at this time nothing is, of course, final. This balance pass is meant to weed out any current/missed issues in the current abilities, and do some balancing to support keeping testing fun. So please, jump into our tests and let us know if you find anything that feels broken, and let us know on the forums!

Art Updates (5/3/2019) Tech - Animations System - Blend Curves: This added functionality is a fundamental need as a precursor to the variable timing functionality of our ability system. However, this can be used for all animations, allowing us to determine speed over time. An example would be taking a basic attack and switching up its timing to begin quickly and end slowly.

This added functionality is a fundamental need as a precursor to the variable timing functionality of our ability system. However, this can be used for all animations, allowing us to determine speed over time. An example would be taking a basic attack and switching up its timing to begin quickly and end slowly. (5/3/2019) WIP - Ability FX: Mike and dB are both working through various bugs with the improved ability system, making sure tags between abilities and FX line up and play the correct assets. Additionally, dB is working on improvements to the chaos magic SFX for the Druid.

Mike and dB are both working through various bugs with the improved ability system, making sure tags between abilities and FX line up and play the correct assets. Additionally, dB is working on improvements to the chaos magic SFX for the Druid. (5/10/2019) WIP - Art - Magic Mortars: Jon completed work on the TDD and Arthurian reskin of the magic mortar. These mortars, when complete, will allow players to launch volumetric smoke onto the battlefield. Players can then use this smoke as cover when attempting an attack or to obscure a retreat.

Jon completed work on the TDD and Arthurian reskin of the magic mortar. These mortars, when complete, will allow players to launch volumetric smoke onto the battlefield. Players can then use this smoke as cover when attempting an attack or to obscure a retreat. (5/17/2019) Art - Animation - Magic Mortars: Joe updated the magic mortars with small foot pedals that line up with the player animations and added a firing animation to the mortars themselves.

Joe updated the magic mortars with small foot pedals that line up with the player animations and added a firing animation to the mortars themselves. (5/24/2019) WIP - Art - Corpse Chuckers: Dionne has completed a modeling pass on all three Realm siege engines, and completed textures on Viking and TDD models. These should be in Joe’s capable hands next week to get an initial rigging and animation pass complete.

Dionne has completed a modeling pass on all three Realm siege engines, and completed textures on Viking and TDD models. These should be in Joe’s capable hands next week to get an initial rigging and animation pass complete. (5/31/2019) WIP - Mage Outfits: Tyler completed the last outfit’s LODs, audited all the others, and began the setup process for use in-game. Joe is wrapping up first pass rigging and weighting, hopefully by end-of-day today, so we can get these in for testing early next week.

Tyler completed the last outfit’s LODs, audited all the others, and began the setup process for use in-game. Joe is wrapping up first pass rigging and weighting, hopefully by end-of-day today, so we can get these in for testing early next week. (5/24/2019) Art - Battering Ram Concepts: We’ve completed some really cool designs for the first Battering Ram models which we’ll begin modeling next week! In the meantime, our engineers are testing their work with a simple rigged greybox model previously supplied by Art.

We’ve completed some really cool designs for the first Battering Ram models which we’ll begin modeling next week! In the meantime, our engineers are testing their work with a simple rigged greybox model previously supplied by Art. (5/24/2019) Art - Animation - 1-Handed Weapon Animations: Scott and Sandra finishished off the supporting work for one-handed maces, swords, spears, and daggers. These new animations will support the variable timing system, which is not yet complete, so the timing of these animations may feel off during initial testing. Ben is going to add these weapon types back into the game for testing next week.

Scott and Sandra finishished off the supporting work for one-handed maces, swords, spears, and daggers. These new animations will support the variable timing system, which is not yet complete, so the timing of these animations may feel off during initial testing. Ben is going to add these weapon types back into the game for testing next week. (5/24/2019) Art - Cow Ammo and Empath Gauntlet: Jon created materials for a live version and a dead version of a cow for our corpse chuckers. He’s also completed the Empath’s gauntlet, which will next need weighting and import.

Jon created materials for a live version and a dead version of a cow for our corpse chuckers. He’s also completed the Empath’s gauntlet, which will next need weighting and import. (5/24/2019) WIP - Art - SFX Various: dB has been working with new supporting code to get in some building destruction sounds based off material types. He’s also continued work on the Wave Weaver SFX, and when not working on those two items, is assisting Anthony to fix ability-related SFX bugs. End of the Month Misc: (5/31/2019) Tech - Visual Studio 2019: We migrated the entire engineering team (and our build system) onto Visual Studio 2019. We'd skipped Visual Studio 2017 entirely to avoid any downtime, so we were all still running with tools from 2015. That meant a big upgrade, with a lot of accumulated maintenance and dependencies that we'd put off, but we'd reached a point where the benefits outweighed that cost. The main benefit is that we can move the gameplay server to the new .NET Core 3 platform, which greatly improves performance. It also gets us a lot closer to moving many of our servers to Linux, which is much cheaper for cloud hosting.

We migrated the entire engineering team (and our build system) onto Visual Studio 2019. We'd skipped Visual Studio 2017 entirely to avoid any downtime, so we were all still running with tools from 2015. That meant a big upgrade, with a lot of accumulated maintenance and dependencies that we'd put off, but we'd reached a point where the benefits outweighed that cost. The main benefit is that we can move the gameplay server to the new .NET Core 3 platform, which greatly improves performance. It also gets us a lot closer to moving many of our servers to Linux, which is much cheaper for cloud hosting. (5/31/2019) WIP - Tech - Entity Movement: Colin is continuing his work on entity movement. When finished, this will let BPOs (Building Placed objects) such as torches and other items behave like rubble with the rest of the building pieces.

Colin is continuing his work on entity movement. When finished, this will let BPOs (Building Placed objects) such as torches and other items behave like rubble with the rest of the building pieces. (5/31/2019) WIP - Tech - Scenario Scripting: Caleb has finished porting our old scenario entities to the new scripting format in the ability system. Improvements to the ability system allowed us to author abilities using simple event/response definitions. That system was designed with reuse in mind. That forward planning is paying off as now the entities that run scenarios will use the same system, allowing us to do more complex scripting within scenarios!

Caleb has finished porting our old scenario entities to the new scripting format in the ability system. Improvements to the ability system allowed us to author abilities using simple event/response definitions. That system was designed with reuse in mind. That forward planning is paying off as now the entities that run scenarios will use the same system, allowing us to do more complex scripting within scenarios! (5/31/2019) WIP - Tech - Siege Engines: Spidey continued his work on multiple interaction points for siege engines, using battering rams as the initial test case. Our first battering ram has six attachment points for players to attach to and move the siege engine. Depending on which spot you occupy the physics will behave differently, like veering to the left if you are pushing from the front right position. The next phase will allow multiple players to interact with the battering ram, averaging their movement inputs to determine direction of input. Final Note -by Max Porter And that’s Unveiled number fifty-five! 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!