Greetings Elyrians!
Welcome to the first Quarterly Update of 2022! We’ve got lots to talk about in this update, as there’s been great progress made on both Chronicles of Elyria and Kingdoms of Elyria. But, before we jump into the updates, let’s get the formalities out of the way.
If the separate callout of CoE and KoE feels surprising or unfamiliar to you, just know that we’re currently working on the land, settlement, and domain management mechanics of CoE, via one of the pre-Alpha experiences previously codenamed Kingdoms of Elyria. Since then, KoE has been promoted to a full-fledged, stand-alone, PC game. As its development still serves as a testing platform for the CoE mechanics and server development, it’s being provided for free to all CoE backers.
For more information on KoE and how we use pre-Alpha experiences, check out our Pre-Alpha Experiences design journal from 2017. For our production roadmap and our development strategy behind KoE, check out The Road Ahead. And finally, for some other KoE blog posts that are relevant to today’s update check out: A Closer Look at Gathering & Resources, Taking Stock: KoE Milestone 1 Retrospective, and the State of Elyria '21-'22 from January.
With that out of the way, let’s move on to talking about the Mid Alpha Test cycle, what’s been done in Q1, and what’s coming up in Q2 and beyond.
Quarter 1, 2022 began with a heavy focus on completing our M2 (Milestone 2) feature set and the completion of our Early Alpha Test, which was concluded the weekend of February 5th and 6th. This marked the end of the first of three Alpha testing phases for KoE and a significant step forward in CoE’s development.
Since February, we've been quietly working on the engineering, design, and art required for our M3 and M4 milestones and the launch of our Mid-Alpha Testing releases. This period of quiet focus has been good for the studio, as we've been able to make huge strides forward in the CoE/KoE engineering space, particularly in our platform development. While we enjoy getting feedback from, and engaging with, our Alpha Testers during the alpha test weekends, the two-week delivery cadence was brutal at times, preventing us from spending focused time on the much-needed migration and refactor of the Soulborn Engine from our previous Node.js framework, to the new .NET-based framework.
Up till now, we’d only been able to make small, iterative steps forward in that effort since the Early Alpha test began last July. But, with the break between testing phases we’ve had an opportunity to make huge advances in our core game engine, including porting most of our CoE backend to the new language and framework. Part of that porting and migration work has been to unblock our designer in his effort to make forward progress on our M3 and M4 milestone goals.
For a reminder of what all is included in the M3 and M4 milestones, check out the “State of Elyria ’21-’22” blog post linked above. The major focus of Q1 for both our designer and artist has been on our crafting and profession work, which will need to be completed by the end of Milestone 4. With that said, let’s dig into what each of the different team members have been working on this quarter.
Since February, our designer has made over 100 check-ins to our version control system, largely working on a combination of UI/UX and game data. When you’re working on something highly experiential, such as the adventuring mechanics of CoE, and especially during the earliest phases of development, the focus is generally on breadth, not depth. Some project management schools refer to this as a “thin vertical slice.” Others may recall I once wrote a blog post about our “Rope Bridge Philosophy.” Regardless of what you call it, the goals and meaning are the same.
In the beginning, the goal of any large game project is to mitigate risk by answering questions such as “do we have the skills to achieve this,” “is this technically possible”, and “will this be fun?” As an example, when working on the crafting mechanics for CoE we spent time building out a user experience for just a single crafting profession, blacksmithing, to ensure that our unique system of crafting was going to be entertaining. Then, we created a handful of techniques, patterns, and recipes, to ensure we understood how each of those worked together. We didn’t, at that point, fill in the details of every crafting pattern, technique, and recipe.
As another example, much of our early focus was on adventuring, which doesn’t require a complete understanding of the entire ecosystem of our world. So, we wrote the game data for enough flora, fauna, clothing items, tools, furniture, weapons, and armor, to ensure we knew what the process would look like and could generate a functional version of the world. But, for that stage of development, it was neither necessary or even desirable to understand EVERY flora, fauna, item, clothing, furniture, weapon, tool, or armor in the game. That is no longer the case.
When working on the land, settlement, and domain management mechanics for CoE, especially when players will be able to jump in and explore virtually every biome of Elyria, it suddenly becomes very necessary. Likewise, because citizens will exist in all biomes at once, it now becomes necessary to understand the relationship between every item in the game, its crafting process, and what resources are available to craft that item… in every biome of Elyria.
To that end, a significant portion of our design effort over the last quarter has been on identifying and creating data for every flora, fauna, and non-renewable resource in Elyria, all the crafting resources that can be obtained from them, and all operations that can be performed on them.
That starts out in a spreadsheet that looks like this:
This, in turn, gets combined with decisions on which tools are required to harvest or extract each primary resource and which tools and stations are required to process or refine those into secondary resources. All of that is then turned into flow charts like the following:
The above is an example of how an apple, a primary resource of an apple tree, can be turned into various types of consumables in CoE and KoE.
And this is an example of how the logs gathered from chopping down the same apple tree might be processed into crafting materials.
Next, the following shows how some of those crafting materials might be used to craft a few different components and potentially improved upon to create higher quality components.
And finally, the following shows how the different components from the previous flowchart might be combined into an item.
Creating similar diagrams for every possible item in the world is a ton of work in its own right, but in addition to that, during the process each and every one of those items, components, materials, resources, tools, and stations must be distilled down into data files (which we call data templates) which contain all the necessary static and dynamic data required for the item to be used and interacted with in the world. The more ways an object can be interacted with, the more data there is.
So how many of these templates currently exist for Elyria? Take a look:
With approximately 80 check-ins since the beginning of the year, I’ve likewise been extremely busy making progress on the engineering side of CoE. For the most part, my work this last quarter consists of movement on two different fronts.
First, Q1 began with a major gameplay push, necessary to bring our M2 milestone to a close. Part of that involved the implementation of new land, settlement, and domain management related mechanics, and part of that consisted of ongoing migration work; porting previously implemented functionality from our Node.js/TypeScript implementation of the Soulbound Engine to the .NET/C# implementation, which will be replacing the previous version in both KoE and CoE.
If you’re curious what types of gameplay functionality we’ve ported thus far, here’s an abbreviated, high-level list:
As for what’s new, most new work has thus far fallen into the areas of:
As previously mentioned, this period of focused development in between test phases has given me an opportunity to work on updating vital parts of our core platform. When we talk about our platform, we're talking about our proprietary game engine. In other words, everything our technical designer and I need to implement gameplay. This includes our ECS (Entity Component System), our serialization libraries, our libraries for interacting with our game data (templates), our data storage libraries, and all the supporting libraries for hosting and running systems and services. While I don’t want to spend too much time explaining what each of the above means, I do want to take a moment to describe just a bit more of what some of those are, and why they’re important to CoE and KoE.
First, our Entity Component System (ECS) is the heart of our entire game engine. It’s the life blood of our simulation. Our ECS is responsible for the creation, destruction, and management of all entities and entity data in the world, as well as the execution of all our game systems and features. Having an efficient ECS means the ability to maintain a stable simulation of 10’s of millions of dynamic entities in the world, and billions of static entities. Having a robust ECS system means implementing support libraries that make authoring new systems less complex and time consuming. While our ECS is now fully managed and implemented entirely in C#/.NET, I’d argue it has reached the point where it rivals the best commercial ECS’s on the market.
Next, efficient serialization of game data serves a few different purposes in a game engine like ours. First, it can be used to send messages over the internet to enable fast communication between various services and the game clients. It can also be used to save and load entity data from backups and cold storage, and of particular interest to KoE, it can be used for the saving and loading of saved games. This is the primary reason I’ve spent time on serialization over the last couple weeks.
In the Mid Alpha test and beyond, testers will be able to load one or more saved games which we ship with the client, each taking place in a different biome. At the start of the Mid-Alpha test, players will be able to test the Mixed Forest biome from before, as well as the newly added Shrublands and Taiga, with more biomes being added over time.
The final bit of platform development I’ve done over the last quarter has been porting the data template system from our previous Node.js implementation to our new .NET implementation. This is in service of allowing our designer to author our previously mentioned data templates.
In the Early Alpha test, our data was all authored and stored as Unity Scriptable Objects. This was convenient for quickly getting a small amount of data into the game, but as you saw from the video above, we’re now working with a vast amount of data! Authoring that data quickly and painlessly required a more streamlined solution. With the work complete, we can now author our game data using our own tools, in a way that supports data inheritance (multiple objects sharing a common set of game data), in a format that can be loaded by both our client and server.
While engineering work isn’t sexy (to most people), and there’s rarely flashy stuff we can show off when we talk about our platform, making forward progress on our ECS, serialization, and data authoring solution unlocks all kinds of new gameplay functionality.
Both our designer and I have spent no small amount of time over the last quarter in the service of the crafting system, which isn’t slated to be implemented until M4. While that might seem premature, the reality is that there’s just as many game assets that’ll need to be created for our crafting and gathering system as there are template files. That’s a ton of game assets!
To make sure our artist has plenty of time, we’ve been getting all the necessary design and engineering work done early, so he can spend from now until the end of M4 either acquiring or creating the necessary art assets, without fear of either being blocked, or blocking us.
If you recall the list of templates from earlier, as well as the flow charts, you quickly get a mental inventory of all the assets that need to be put in place. There is all the flora, fauna, items, tools consumables, wearables, weapons, structures, crafting components, resources, and materials for the entire world of Elyria! That includes similar analogues from multiple biomes!
While not all those assets are needed by the end of M4, we do want to have a complete set of at least the assets necessary for the biomes we’ll be shipping as part of the next Alpha test phase. To that end, below are some of the new, custom assets which have been created by our artist over the last quarter. Note that the wolf is put there for size comparison.
I wanted to take this opportunity, now that you’ve seen some of the assets we’ve been working on and have a better understanding of the number and scope of assets needed, to speak about a problem that exists within our industry and not just at Soulbound. I occasionally see people commenting on a studio's use of purchased assets, such as from the Unity Asset Store or the Unreal Engine Marketplace.
Sometimes these articles, blog post, or user comments are critical of a studio using purchased assets from an asset marketplace, implying their studio is somehow subpar or their game somehow inferior because they use store-bought assets. And, in other cases, you'll see studios being attacked for NOT using purchased assets, with statements that they're using their money unwisely, spending dollars for custom assets when store-bought assets would be good enough. This creates a sort of "damned if you do, damned if you don't" situation which isn't healthy for our industry, and indie studios in particular. So let me let you in on a little secret, and perhaps shed some light on the ignorance of either argument.
All assets are purchased assets.
It doesn't matter whether you're buying assets from an asset marketplace like the Unity Asset store, paying employee-artists to create custom assets for you, or splitting the difference and having outsourcing agencies create custom assets for you from base templates. In all cases, a studio is purchasing assets.
What changes is how much the assets cost, how quickly a studio can get their hands on the assets, what purpose the assets may be best suited for and - if the studio is particularly savvy - how important the asset is in immersing the players into their world.
Sometimes a studio is purchasing assets as stand-in or "Work In Progress” (WIP) assets, without the intention to leave those assets in for the final game. In these cases, purchasing cheap assets they can get their hands on quickly can unblock the design and engineering teams, while allowing the company to save their cash for the final assets.
Sometimes they are intended for the final game, but it's expected the asset won't be a major focus of the game, and so its origin is of little consequence. And sometimes, there's such a large volume of assets required that having everything made custom is cost prohibitive.
In our case, we've used store-bought assets from the beginning of CoE's development and continue to do so today, though for different reasons. Early on, our purchased assets were largely WIP pieces, designed as placeholder or stand-in assets. But we'd occasionally see a high-quality asset we'd need to make anyways, and in that case, it just made more sense to pick it up in a store than make it from scratch.
These days, we buy store-bought assets for an entirely different reason. As you saw earlier, CoE has thousands of different items that are used as crafting resources, tools, weapons, armor, furniture, cookware, and more. There's a massive number of things to make. Given the large volume of assets, and the small size of our team, it's simply impossible for us to deliver the game we want to deliver, in the time we'd like to deliver it in, without resorting to purchasing assets from a marketplace whenever the quality meets our standards, and those assets are unlikely to pull people out of the world we’re trying to create for them.
Before we close out this quarterly update, I wanted to talk to about what’s coming up in Q2, and a few things Alpha testers can expect when the Mid-Alpha test finally opens.
First, as we’ve been communicating via the Official CoE Discord and the Early Access forums, we have not yet set a start date for the Mid-Alpha test. However, we do expect it to fall within Q2. Once we have an official start date, we’ll post it to the Early Access forums, to our Discord server, to social media, to our Kickstarter page, and we’ll send another update via email. So, don’t be worried about missing the start of the Mid-Alpha test. When the next phase of alpha testing begins, we’ll make sure you know about it.
Second, when the Mid-Alpha does release, expect to find an updated launcher with faster downloads and more readable updates, as well as in-game bug fixes and the introduction of several new game system. Also, expect faster load times in the client, more optimized execution, and as previously mentioned, the ability to load into either the Mixed Forest, Shrublands, or Taiga biomes.
Third, because we’re going to have ongoing platform work throughout the course of M3 and M4, we’re going to continue to leverage the benefits that come with slightly longer intervals between testing weekends. So, for the Mid-Alpha test, we’ll be hosting alpha test weekends every four weeks instead of every two. Once the Mid Alpha test officially begins, we’ll post a calendar of the testing weekends to our website.
And finally, a quick reminder that the Mid-Alpha test will be open to all Alpha 2 backers, in addition to the Alpha 1 backers that were able to provide feedback previously. With that, we’re looking forward to an increase in activity in the Early Access forums, and more interaction between us and the testers.
That’s all for this update. Stay tuned for next quarterly update, July 12, 2022.
Pledged to the Continued Development of the Soulborn Engine and the Chronicles of Elyria,
-Caspian