Hail Elyrians!
As the leaves transition from their summer greens to autumn hues of reds and yellows, so too are the intrepid adventurers here at Soulbound Studios transitioning from their previous adventure to their next. Which means it's time for our adventure completion blog post. Before jumping in, feel free to familiarize yourself with the goals we set for ourselves at the beginning of Adventure 0.4.0 by checking out the Intro Blog as well as the Update Blog. Once you're done, or if you're just too eager to see how things turned out, then settle down with some warm apple cider or some hot tea and read on!
While there's certainly no shortage of screenshots or concepts below, as I sat down to write this completion blog I did note an unusual absence of any pictures or illustrations of the systems and gameplay we've been working on in 0.4.0. I mean, we've got plenty of pictures we can show of the environments we're building, items we've created for crafting, farming, and other systems (many of which we use for our Thursday Shinies), but there's still a notable lack of images and videos of new gameplay from this release.
In truth, the lack of images is a symptom of our approach to game development and not due to any lack of progress. But even still, I felt like an explanation was due that helped readers understand just how much progress was made in 0.4.0 and just how important that work was. The best way to explain where we are in development right now is through an analogy.
Building a game like Chronicles of Elyria is a lot like designing and building a new car. Back in 2015 when we first started talking about Chronicles of Elyria, it was a lot like sharing the spec sheet for CoE. We talked about the major systems, how powerful the engine would be, what kind of mileage people should expect from the game, etc.
But just like with cars, people quickly wanted to see what the game was going to look like. So we spent time working on the body of the game. In MMO terminology, that's the client. It's the part people can see and what many people use to compare one game to another. Back then we worked on a lot of prototypes involving the client. This included prototypes and demos of our aging & dynamics systems, our world interaction system, weather, combat, crafting, parkour, and a few others. All of which were designed to test out ideas and player reception, by showing the "exterior" of the game. But, in our car metaphor, those were all scale models. They showed what the car would look like, but they were built on temporary chassis that needed to be replaced before real forward progress could be made.
Of course, we knew we'd eventually need to road test the game so we started development of our powertrain. In MMO parlance, that would be our back-end server architecture. In fact, the vast majority of 2017 was spent building our drivetrain. This work continued over into the first part of 2018 as we began work on other major components of the powertrain. But even still, we didn't have a functioning game yet. There's just more to a car than the powertrain, the steering wheel, and the body.
And that's what Release 0.4.0 was all about. It was about manufacturing all those other parts that make up a car. Breaking from the analogy, release 0.4.0 was really about building base implementations of the various game systems necessary to have a functioning game. Now, due to our unique approach to software development, those systems were all built in isolation from the main game as part of a smaller manufacturing process. At first that may sound silly. But consider that automobile companies don't build their parts into the cars. They manufacture and test their parts separate from the vehicles, and then assemble them together afterwards. The same goes for us. That, incidentally, is the reason why, in spite of all of the design and engineering completed in 0.4.0, there's little we can actually show yet. We've got a lot of independent parts that still need to be assembled into a larger product.
While I don't want to steal the thunder of the 0.5.0 introductory blog post coming later this week, this is precisely what 0.5.0 is all about. Release 0.5.0 is about assembling the parts we've just created and seeing how it all looks when put together. In short, completion of 0.5.0 gets us to where we finally want to be; able to show off the game as a functioning product, and not just a set of independent, disconnected parts.
With all that said, 0.4.0 did allow us to implement several new systems, as well as iterate on some existing ones. Let's take a deeper look at what systems we touched in 0.4.0.
While we had originally planned to launch pre-Alpha with nothing but walking and talking (and then gradually introducing new features), we decided after completion of 0.3.0 that the world felt too sparse, and the mechanics too thin to provide any real value from testing. After all, what kind of feedback can the alpha testers provide if there's nothing to give feedback on? So in 0.4.0 we aimed at getting implementations of as many Alpha 1 features as possible, as well as iterations on a few other established features. These base implementations aren't final, mind you, as there would be little value in the pre-Alpha if we weren't willing to iterate on, and make changes to, the initial releases. But they still provide a base implementation we can get feedback on.
A lot of new systems were worked on in 0.4.0. But here's an overview of the work done on some of the most important ones.
Artificial Intelligence
While we had more or less completed the design of our NPC and creature AI, we had only implemented one-off actors to fulfill specific roles. In release 0.4.0, we began implementation of a more general goal-based, need-based AI system, complete with a node-graph authoring system to allow us to customize NPC behaviors without having to go all the way into code. If we play our cards right, this node-graph AI system will be the same system and interface used by players to script their own OPCs, post-launch. While there's still a lot of iteration left on this system, and a lot of clean-up before it can be put in the hands of players, here's a quick glance at a fun node-graph we made to handle an NPC interaction scenario.
Crafting Stations
While we already had a blacksmithing demo and working system prior to 0.4.0, this release saw implementation of a new framework for quickly developing new crafting stations. The end-result is tighter integration with our world-interaction system and a deeper understanding of how stations will work; both from a design and engineering standpoint. The integration with world-interaction and survival also allowed us to create a few non-crafting stations, such as wells and water fountains, as well as fire pits, tents, and bedrolls for keeping warm.
Family Narrative
Although we had worked on character creation in the first few releases of CoE, we had skipped the family system and focused on creating wards. In Release 0.4.0, we began work on character creation utilizing the family narrative system. This is a series of background prompts and historical narrative that players will go through during character creation that allows them to both filter the world for matching families, as well as set their starting values for skills and attributes. More work remains on this system, but it provides the groundwork for character creation with families.
Personal Destiny System
Not to be outdone, we also worked on the personal destiny system in 0.4.0. It was already thoroughly designed, but in this latest release we implemented our first iteration of the mechanics which allows us to take the year, month, and day of a character's birth and generate the set of conflicts and unique story arcs the character might experience in their lifetime. The Personal Destiny system ties in heavily with our dynamic story engine and will continue to get love in 0.5.0 as we work further on dynamic story-telling.
Souls
Similar to the Personal Destiny System, we already had a design for Souls but hadn't previously connected it to anything. Which is to say, while you could pick a soul during character creation, it didn't bring with it the skill ramps, etc. Now, it does.
Identities
Moving outside of character creation again, we also did work on Identities in 0.4.0. This ties in heavily with so many systems that while it's not particularly complex by itself, it's a cornerstone that needed to be implemented before many other systems could be started. With 0.4.0 out of the way, many other systems now think about your character in terms of their identity, not some absolute character ID. As a result, it's possible to swap between your main identity or an alternate identity, changing the way you interact with NPCs and contracts.
Contracts
Speaking of contracts, one of the first systems to use character Identities is the Contract System. Release 0.4.0 saw the first implementation of contracts as functional game elements that can be initiated, tracked, and completed. We also implemented a few of the starting clauses and conditions for completing a contract. Beyond implementation though, iteration work we did on the Skill System, combined with work on Knowledge and Gossip, did result in some pretty amazing changes to the Contract system. I'd like to go into more depth, but the recent changes in the Contract System really warrant a design journal all on its own.
Environment
Finally, while we had client-side weather effects before, we didn't have any server-side weather system. In release 0.4.0, we implemented a base version of dynamic temperature change, humidity, and weather patterns. This allows areas to change their weather dynamically over time, driven by a larger weather system. This of course ties into the survival system, which, while something we'd already begun, did see some additional functionality in Release 0.4.0.
In addition to the previous new implementations, some systems got additional functionality, while others got some re-design. Note that the ones that are undergoing a bit of a re-design don't necessarily have new implementations yet, but will during Release 0.5.0.
Survival Mechanics
Previously we had the basic survival mechanics in place. Characters had fatigue and energy, as well as hunger and thirst. But getting more hungry or thirsty, or getting more fatigued would only cause you to drop to 0 vitality. That was it. In Release 0.4.0 we added incapacitation and our first version of spirit walking. We also added several new survival mechanics such as a wounds and status effects, as well as homeostasis. As mentioned before, with the addition of dynamic temperature and things like fire pits, it's now possible to control your body temperature.
Skills
Skills continues to see some of the heaviest re-design in CoE. When we first proposed CoE we had the goal of making all actions a player could take require some combination of character skill and player skill. As you can imagine, this required the development of some artificial constraints and UI in order to make sure there were components of both player and character skill. But if you think about it, there are many different actions a player takes that could potentially require mostly character skill, mostly player skill, or no skill at all. And in some cases, even when no character or player skill is required, there's still some degree of character or player knowledge required. The recent changes are worthy of a new design journal, but 0.4.0 saw some significant streamlining and improvements to what we had previously described as our skill system. Stay tuned for a blog on skills, knowledge, and related mechanics.
Combat
Another system to see some significant re-design in 0.4.0 was our combat system. For those following along, we had an initial implementation of our combat system as early as the beginning of 2016. This combat system used a combination of techniques, combined with dodging, parrying, and deflecting, to create a combat system which was easy to learn but difficult to master. Success was based on timing and your ability to anticipate your opponent and counter effectively; much like more traditional fighting games. To show off the system, we took a version to our very first PAX East showing. But then in 2017, as we transitioned from technical demos and proofs of concept to an online game, we held off on re-integrating the combat system in our parkour demo so the high-adventure feeling of jumping from platform to platform and sliding down a zip-line could really shine. Instead, we implemented a slightly simpler combat system just to make sure the combat experience wasn't entirely missing.
But now we're working to re-integrate a variation of our original combat system into the game again. I say variation, because while we liked the overall feel and flow of combat, it lacked variety. Being based on combinations of solely left and right mouse clicks meant combat was always initiated one of two ways. This felt constrained, so in 0.4.0 we began implementation of a new system of combat utilizing dynamic stances that allow for a bit more variety. This work will continue in 0.5.0.
Knowledge
Finally, 0.4.0 saw the first draft functional design of the Knowledge and Gossip systems. This isn't high-level. This is down in the dirt details. Details about what type of information can be learned, how it's learned, and how information can be transferred to others. We even created a paper prototype game that allowed us to explore and demonstrate the ideas to other members of the studio. We began our first draft of the implementation system in Release 0.4.0, capturing and recording events your character witnesses for use in the knowledge store, but there's still so much more to implement here I put it in this section. But this feature area will get a ton more work done on it in 0.5.0.
In addition to work on the game itself, myself and Orlando spent time in 0.4.0 working on Map Voting. Map Voting is one of the events that people - myself included - have been anxiously waiting for. Once Map Voting begins players will get to take part in an historic event - selecting the world maps for the different servers. Something that, as far as I know, no MMO player has ever been able to do before. And once Map Voting ends, players will finally be able to see the lay of the land and biomes for their servers. Furthermore, with map voting out of the way, we'll be just a stone's throw away from Domain & Settlement Selection, which is one of the most anticipated pre-launch events we'll have.
With Domain & Settlement Selection, all those kingdoms, duchies, counties, and settlements that exist on the starting continents can finally be claimed by their sovereign! Players can start communicating with confidence which biome, tribe, and environmental effects best describes the experience they're offering other players. Furthermore, they can adequately plan for launch and begin recruiting in earnest.
Getting Map Voting out the door involves not only having maps to vote on, but a portal in which to vote in. While work on world generation continues, in 0.4.0 we all-but-finished the map voting portal. You'd previously seen the wireframes, then the graphical design. Below are some screenshots of the map-voting portal as it exists today.
So, I know what you're asking: "When is Map Voting?!" While we've got a date in mind now, I'll leave the exact announcement of when Map Voting begins for the 0.5.0 Intro blog coming out later this week. Because, you know, it's going to be during Release 0.5.0.
Thus far, I've mostly talked about what the engineering and design guilds have been up to, but the art guild has not been idle. Before I talk more about what the content team has been up to though, it's probably a good idea to provide a bit more information on our development approach.
Our approach to development is something I've referred to in the past as our Rope Bridge Philosophy. Which, while I won't go into great depth here, is about building thin vertical slices of our systems and solutions - in isolation - and then iterating on them quickly and frequently. Our implementations focus heavily on developing with SOLID design principles in addition to a couple of our own principles. In particular, we try to develop CoE in a way that allows for "Separation of Concern", "Iterate Where it's Cheapest," "Code by Necessity," and "Optimize Last." Of these principles, the first two are particularly relevant to what the art guild has been working on.
Separation of Concern
Separation of Concern from a SOLID design standpoint means making sure the code and systems we develop are only focused on a single responsibility. There are many benefits to this approach that can be found on the web, but we've taken it a step further. For us, Separation of Concern means being able to develop the game independently of one another, so that nobody on the team is ever blocked by the work someone else is doing. This means separating not only the client from the server, so they can be worked on independently, but also separating the engineering from the content. This is the primary reason we've been developing CoE with two separate clients; a high-fidelity, high polygon client you've come to know as the CoE client (so the content team can work separate from designers/engineers), and a low-fidelity, low-polygon client you've come to know as the Pre-Alpha Client or "VoxElyria" (so the design/engineering teams can work independently of the artists).
Iterate Where it's Cheapest
In addition to Separation of Concern, we also try to iterate where it's cheapest. This concept is again seen frequently in project management, as it makes logical sense to do R&D where it's least expensive; but we've taken it a step further with our development of dual clients. Whereas concept art allows you to iterate and discard ideas quickly before moving on to 3D models, and where 3D models can be iterated on and discarded before moving on to animations, our development of dual clients allow us to test and validate our functional requirements and designs while spending as little time on art and content as possible. Of course, what designs and features we can validate has changed over time as we've attempted to make the pre-Alpha more accessible to players, and as the need has arisen for us to be able to test more functionality.
When we first talked about our design methodology and rapid prototyping back in 2015/2016 we were talking about ElyriaMUD. The intention was for it to be a text-only RPG that would allow us to implement core game mechanics without having to worry about assets at all. Such an implementation requires the least amount of coupling between engineering/design and content you can possibly imagine. It actually allows us to test and explore new mechanics pretty quickly, and the simple nature of the implementation means even our designers can, using our chosen language of TypeScript, write and test new gameplay mechanics. I say "allows us to," because while nobody knew it, we did actually implement ElyriaMUD. ElyriaMUD has been in use even as recent as Release 0.4.0 to explore new functionality without having to involve the content team. Work done in ElyriaMUD can be implemented and tested, and then migrated over to one of the other clients. While we've never actually shown ElyriaMUD before, I figured now is as good of a time as any to share pictures of it. Here's a few below.
Now, while ElyriaMUD is great for rapid iteration of design and engineering, it's inaccessible to most players as it requires using text commands to invoke operations, doesn't have a map or any ways of identifying where you are (aside from mapping or memorizing rooms) and, while it's a great sandbox, would require additional time/energy to actually develop all the "rooms" required to make it feel like a playable game. For that reason, it's unlikely ElyriaMUD will ever be released to the public, even as part of a pre-Alpha. The other problem with ElyriaMUD is in the tradition of MUDs, it uses a concept of rooms rather than XYZ-coordinates, so it's impossible to test mechanics that require absolute positioning. As a result, functionality that requires an XYZ-coordinate position is typically implemented differently when moved from ElyriaMUD over to another client. In any case, the format being so unapproachable, as well as the lack of positional coordinates led us to shift publicly from ElyriaMUD to the idea of a 2D, top-down client.
While this was short-lived and only talked about briefly, we did create a client in early 2017 that was WebGL based and used voxels to create a top-down gameplay experience. This was the precursor to what became VoxElyria. It was created when we were planning to put as little graphical detail into the pre-Alpha as possible, and were okay with the same sprites being used for virtually everything. The "sprites", were actually created initially by the engineers using voxel models. Shortly after beginning work on the Elyria2D client, we decided to advance it forward into something which our Alpha backers could jump into. This necessitated a change from a top-down 2D-ish perspective to a more 3D, isometric view. We also improved the quality of our voxel models, etc. In any case, here's an animated GIF of Elyria2D.
While you've likely seen VoxElyria before, here's some screenshots we've shared in the past. As a reminder, the point of VoxElyria was to allow us to test and develop functionality as quickly as possible, while not having to rely on the content team to develop the assets. The design and engineering teams could quickly create their own low-quality voxel models and then test them in our WebGL based client.
However, as we were working on Release 0.3.0 a few things became clear.
First, while the voxel format allowed us to quickly create gameplay mechanics without concern for the assets, the mechanics weren't 1:1. For example, due to the camera position, several of the user experiences in CoE necessitated different implementations between CoE and VoxElyria. For example, combat, crafting, and world-interaction, arguably three of the most important systems in the game, had to be slightly different between VoxElyria and CoE.
Second, while the assets themselves could be created quickly, it prevented us from effectively visualizing some of the more advanced mechanics. For example, we couldn't easily animate the voxel models, so things that required animations were difficult to validate. Likewise, because they were voxel models, things like the equipment and layering system couldn't be effectively replicated in the VoxElyria client.
And finally, while we didn't have to use WebGL (and a web-based game-engine) for VoxElyria, it naturally evolved that way from Elyria2D. This meant that while the client-side implementation of the mechanics could be the same between CoE and ElyriaMUD, any features we wanted to test which required tighter client-integration would need to be either ported between the clients, or implemented twice.
We had a long conversation with the leadership, designers, and content team and decided there had to be a better way. To begin with, we recognized the value in having the low-poly, low-fidelity client, but we needed to make sure a few constraints were put in place. They were:
When all was said and done, we settled on keeping the idea of having low-poly assets, but moved back into UE4. And instead of developing voxel models, we decided to use low-poly meshes that can be developed even quicker than the voxel models we were using before. Of course, it comes at a cost to require the content team to develop assets for us, but the reality is, it's faster and more resource efficient to have the content team develop the assets than the designers and engineers, especially when it means we don't have to duplicate the UI/UX between the pre-Alpha client and CoE. It's also important to be flexible, and willing to reallocate work as necessary as our internal resources change. Fortunately, as you'll see below, our artist really enjoy working in the new client, and have gone wild creating amazing new content.
So with all that out of the way, the content team has been working on assets in Release 0.4.0 for our new pre-Alpha client. Since it's doesn't use voxels anymore, we couldn't really call it VoxElyria any longer. So we just call it Pre-Elyria, or "Prelyria."
When trying to decide what art style and what type of assets to use in Prelyria, we remembered how easy and how popular our cel-shaded artwork was as part of our animatics. It's important that we continue to keep the visual style of our pre-Alpha separate from the final launch anyways, so we decided that using a cel-shaded approach would be a good idea. We began with some concepts of what the art style would look like, which you can see here:
And then, we quickly moved onto to creation of the assets themselves. Which you can see below.
(Ignore the yellow thing in the sky in this screenshot. It's just a marker we use to measure distance)
Phew! Release 0.4.0 was one of our longest releases to date. But it was well worth it. What came out of Release 0.4.0 was a set of implementations for many, if not most, of the core system for our Alpha release that is ready to be integrated into the Prelyria client and "assembled" in Release 0.5.0. At the same time, we exited Release 0.4.0 with a brand new client and art style which not only allows us to develop gameplay just as quickly as before (quicker, actually), but also allows us to create a pre-Alpha experiences that are functionally closer to what the final game will be, allowing for more accurate feedback.
And finally, Release 0.4.0 saw us one step closer to Map Voting and the realization of Elyria as it will exist for the players.
Back at the beginning of Release 0.4.0 I said the next two releases (4 and 5) would be the two most important releases of our entire development process. And this is why. By the end of Release 5 we'll have finally gotten to where we want to be, at a point where we're finally able to show you the game we're creating as a single assembled, albeit incomplete, user experience. Stay tuned later this week for the Release 0.5.0 intro blog where we talk more about the work we'll be doing in 0.5.0, including the launch date for map voting!
Pledged to the continued development of the Soulborn Engine and the Chronicles of Elyria,
Caspian
