Greetings, everyone!
In February's update, I posted a video that showed the complete scope of CoE's development. To ship CoE, we need to complete every item on the list. Over the last month, I've spent time developing three areas of that scope document; one related directly to the game's development, one to community engagement, and one that combines both. Let's look at some images from the video I posted in February to get a visual sense of what I've been working on over the last four weeks.
In the Engineering breakdown, you can see that to ship CoE there is required work on the "Server Platform," the "Server-Side Game Engine," and the "CoE Website." While the order listed breaks them down by category, they must be completed in a different order.
Making progress on those in the correct order means moving forward with complete dependencies, gaining the necessary knowledge and learning as I progress, and minimizing the amount of scaffolding or throwaway work that must be done to reach the end. With that in mind, it may only sometimes be obvious why I'm working on what I am. Still, in all cases, the goal is to streamline the work in a way that reduces the total work involved, not necessarily which is the flashiest or demonstrates the most dramatic progress.
Over the last month, work has been done on each highlighted area in preparation for March & April. Looking into the Server-Side Game Engine, I've begun work on the "Spatial Partitioning Service."
Looking into the Server Platform work, you can see the items named "Service Host" and "Server Networking / Message Layer," which are coming up next.
The website breakdown includes the "Edge/Portal Server," "Website Platform & Rendering," "Discord Integration," and numerous feature libraries, all of which are either being worked on now or work on them is being prepared.
WARNING: Technical speak ahead. As everything I've worked on since the last update has been engineering, I can only speak to the progress if I get at least semi-technical. I've used as few buzzwords and technical jargon as possible. For the non-technical folks out there, I apologize in advance.
My most recent work has been in the Spatial Partitioning area. Server-Side spatial partitioning is one of the most critical elements currently missing from our backend. It was one of the significant blockers preventing us from releasing the first CoE Alpha Test and one of the main reasons we initially partnered with a third party to help develop our backend.
As a game simulation runs, there's a constant need to perform proximity, collision, and interaction checks worldwide. The more clients connected and the more dynamic objects in the world, the higher volume of checks that must be performed.
These types of checks are performed regularly by virtually every game system in the simulation. Here's a quick list of just some of the systems or services that need to perform such checks regularly:
In games with few interactable objects and limited places to move, it may be unnecessary to subdivide the world to perform such calculations. However, in games with many interactable objects or collisions, it becomes necessary to subdivide the world using one method or another to perform those calculations efficiently. Still, it can generally be performed as part of the same process running the game. In even larger game worlds, like Elyria, it's necessary to subdivide the checks across a distributed number of processes, each running on different servers.
Beginning two weeks ago, I started the architecture and early implementation of the Soulborn Engine's Spatial Partitioning System. The requirements include three main features.
First, the ability to quickly identify whether a point, sphere, or bounding cube (both axis aligned and oriented) is within proximity or collides with another sphere or bounding box.
Second is our "Aura" system. Like a standard Trigger System, it must notify other services when a new collision happens. The main difference is that, for time/space tradeoff, the Aura system keeps track of the static objects within each Aura and does not need additional calculations unless the Auras change.
And finally, the spatial partitioning system needs to be able to be split effectively into multiple processes as necessary, with quick recovery time if something should happen to one of those processes.
Now, we've had spatial partitioning systems in the past. But they have yet to be distributed and haven't been server-side authoritative. While the rest of the game mechanics in CoE are server-side authoritative, both the pre-Alpha implementation of CoE and KoE have always utilized the Unreal Engine and Unity physics and collider systems, respectively, to notify the server where the client's player was. The server would then record that and propagate that to the other clients. It's an excellent pre-Alpha solution but leads to speed hacks and other exploits that wouldn't work for an Alpha or beyond release.
The division between the client and server "sharing" responsibility for the player's position was always a headache. But with me finally implementing the server-side solution, it unlocks the ability to make forward progress in other game areas more quickly. I'll continue implementing the Spatial Partitioning System throughout the rest of March and post a video demo when I get it fully functional.
I said earlier that the Spatial Partitioning system was a critical component of our server-side game engine and one of the reasons we initially partnered with a third party. We also wanted to use a third party for their Service Host, which we had already previously replaced with our own. However, with our move from Node.js to .NET, I've also been preparing to port our Service Host.
A distributed application, whether using a Service Oriented Architecture (SOA) or a Microservice Architecture, consists of multiple services running in different processes, either on a single physical server or spread across multiple servers. Between each of those services are endpoints that must communicate with one another, networking code for establishing, monitoring, and securing network communication, and a set of network protocols that determine what messages travel between the processes and how they map to underlying service calls.
Rather than duplicate this functionality for each process, it is implemented as a single, reusable library called a Service Host. The Service Host is integral to any distributed application, including MMOs. It is the job of the Service Host to register a service on the network to enable service discovery, to subscribe to events and messages that the hosted service may care about, to communicate service health to the rest of the network, and, when a message is received, to forward it on to the service it hosts in a way that the service can understand.
While KoE: Settlements and KoE: Domains are single-player games, KoE: Online and CoE are not. So the Systems and Services we're writing need to be able to sit inside either a single-play game or an MMO backend, which means sitting inside a Service Host. Having a functional Service Host earlier rather than later means we can verify it on a small scale and reduce the overall development time between KoE: Domains and KoE: Online.
My work in the last week of February included preparing for the new Service Host. The original Service Host was written as part of our Node.js MMO architecture. However, like the System & Services libraries, the new Service Host is implemented with .NET 7. At the very least, I must port the existing functionality from Node.js to .NET 7. But porting is only one of the significant tasks, as I need to test and validate the Service Host by having it register sample services and handle incoming messages, ideally under realistic conditions. A Service Host is necessary to test the Spatial Partitioning System mentioned above under a distributed game architecture. Still, there's an even more immediate opportunity.
As I mentioned before, the Service Host hosts the service of virtually any kind of distributed application, whether that be an MMO or even a website. So even before testing the Service Host with the KoE backend services, I could implement and use the Service Host to host the various web services used in a microservice-based web server backend. Coincidentally, I had a website with a backend in dire need of refactoring.
While the last part of February and the first week of March were partially spent on the Spatial Partitioning System and the Service Host architecture, most of the time between our last development journal and now has continued to be spent on refactoring and rebuilding the CoE Website.
Although the website may seem like a relatively low priority, especially when compared to developing our game engine or gameplay mechanics, there are a few reasons to complete work on the website between now and the launch of KoE's Alpha 2.
First, our most significant operating cost remaining is AWS hosting fees. Currently, the website sits across three servers: a Linux server that hosts the v3 Node.js webserver, a tile server that serves map tiles, and a Windows ASP.NET webserver that does all of our dynamic content creation and interacts with our backend databases.
Because the .NET Framework isn't portable, we must keep both web servers or migrate one platform over to another. From a cost-cutting perspective, Linux is the more cost-effective operating system, as it is usable without license fees. Additionally, as .NET 7 (Core) is replacing .NET Framework as the technology's forward direction, moving all our backend servers to Linux lowers hosting fees and reduces future maintenance costs in both time and money. This is especially true given that our game engine is also being ported to .NET 7.
Second, during the first Alpha test of KoE in 2021, we needed more support on the website to encourage discussion. In particular, we couldn't notify people when a new forum post was posted to Early Access. The website also doesn't track which forum posts you've read nor inform you when someone has replied to your messages. I want to utilize the website's messenger service to support more notifications and use email more so people have better visibility into what's happening on the forums. All of these lead to a better experience for testers with Early Access.
Next, the website update was initially spearheaded by a desire to provide a means for the community to re-engage with one another on the Official CoE Discord. To do that effectively, I need to be able to enforce roles and limit access to restricted channels like the Alpha Testing channels, etc. Discord integration on the website allows us to do all of the above and roll out automated moderation tools to enforce behavior that meets our expectations for our shared community culture.
Again, while re-engaging with people on Discord or enabling the community to re-engage with each other may seem like a low priority, it directly supports our company's mission of creating experiences that fuel imagination and provide accessible, engaging, and meaningful interaction. And anything that aligns with our mission is a move in the right direction.
But all the above alone still wouldn't require me to do the website updates now as opposed to later in April or May. However, as mentioned in the previous section on the Service Host, working on the website refactor now provides all of this: lower costs and better engagement on the website and Discord, as well as a second interface and opportunity to test the new Service Host.
Putting aside the reasons I've been continuing to do work on the website's backend, here's a list of some of the work done on the website in February:
And that wraps up this update! Looking back at just four weeks of work, I recently find myself simultaneously proud of the work completed and frustrated. There are always more things I wanted to accomplish than I could achieve in such a short period. In particular, here are a few things I still need to do that were discussed in February's blog post:
In addition, I began work on the Spatial Partitioning System and the Service Host, which will be completed at the end of March or so. So while work began on them, they're not in a showable state yet, so I don't get the W for that.
In times like this, I have to remind myself that I'm just an individual now and that while I may still work to move mountains, I have to do it one stone at a time, with many trips back and forth.
As a final note for this update, I'm aware that repeated developer blogs discussing what was worked on without anything visual illustrating the work disappoints many folks. For others, including visual aids such as screenshots and video reaffirms that work is progressing. Both groups will be happy to know that this should be the last developer blog without anything visual to show. As I continue the game engine work, I will write a small demonstration to illustrate spatial partitioning. And after I return to writing gameplay mechanics, I'll once again be able to show off more regular gameplay videos.
This time next month, the mountain should be visibly smaller, both in terms of visual demonstration and in more items crossed off the scope document - if only by what a single individual can move.
Pledged to the Continued Development of the Soulborn Engine and the Chronicles of Elyria,
Caspian
