18 May

CoE Development Update: May 2023

By Caspian

Greetings Elyrians!

Welcome to the May 2023 Monthly Development Update for Chronicles of Elyria & Kingdoms of Elyria! I'd like to express my heartfelt appreciation for your continued support and interest in CoE. Your feedback and engagement have been invaluable, and I am excited to share this month's progress.

As part of the new Monthly Development Update, I'd love to give you a quick rundown of what's in store. Just click the links below to head directly to the sections that pique your interest:

  1. Progress Update
    a. Scope review
    b. Itemized list of completed work
    c. Detailed information on progress
  2. Introducing new format & 2nd monthly blog post
  3. What's Up Next

Progress Update

Scope Review

Taking a look at our Scope document each month is super important! It provides a comprehensive overview of our MMORPG development progress and helps communicate how the previous month's work fits into the larger picture. At the highest level, CoE's scope looks like this:

Recently, I've centered my efforts around what is traditionally called an Entity Component System (ECS), which we'd previously called our "DECS," denoting its distributed nature. After a month of intensive research and development, I've adopted a new name for it—our "DECAS," or Distributed Entity Component Actor System. Here's what the DECAS scope listing looks like:

As you can see, our concurrent systems execution, repositories synchronization, and support for a centralized entity service, which were mainly initiated this month, still have some ways to go. I'll delve deeper into this month's work on the DECAS in an upcoming blog post.

Itemized list of completed work

Over the past month, I've made significant progress in the following areas:

  1. Enhancing the efficiency of our Spatial Partitioning System
  2. Incorporating Hardware Instancing within the Medium Renderer
  3. Adding support for scaled terrain and preparing to run the world as a distributed system
  4. Further enhancing our existing ECS
  5. Undertaking research into Actor Systems and Concurrent/Distributed Systems

Detailed information on the progress

At the month's start, my aim was to implement our ServiceHost and Server Networking Layer. I soon realized, however, that our existing Entity Component System (ECS) was ill-equipped to support the asynchronous interactions necessary to incorporate our ECS into the service host of a distributed system.

I can't overstate the importance of the ECS. It forms the backbone of our game engine, underpinning all features and game data. Successfully integrating the ECS within a ServiceHost depends on its ability to function safely in an asynchronous environment. This compelled me to dedicate most of the month investigating various concurrent and distributed system architectures. Additionally, I conducted a series of small-scale experiments to gain a deeper understanding of the issues.

While researching, I also made progress on our ECS and some recently implemented systems. First, I optimized the Spatial Partitioning System by adding caching and object pooling. This resulted in noticeable performance improvements. I added an FPS counter to Medium to showcase the difference and measured the relative framerate for updating and rendering 10,000 entities without the optimizations. Here are the results:

And now, look at the world rendering and updating similar 10k entities after the updates. You'll notice that the framerate increased from the typical 41 FPS to about 48 FPS. That's almost a 20% improvement in performance!

Next, I questioned how much of our framerate was due to the ECS and various systems, such as gravity, collisions, and movement, versus just rendering 10k entities. To investigate this, I implemented hardware instancing within the OpenGL renderer in Medium. The results were impressive - the framerate experienced yet another boost!

As you can see, the FPS has now increased to approximately 60 FPS. It may be higher, as I have vsync enabled on a 60 Hz monitor, which limits the framerate to 60 FPS.

Around this point, I returned my focus to implementing the concurrent execution model. To prepare, I decided to scale the 512m x 512m map up to 1024m x 1024m. That means I could fit four (2x2) 512m maps within the new area. Furthermore, if I were to divide this by "high ground" and "low ground," I could segment the world into eight separate 512 x 512 x 512 regions—perfect for distributing across eight distinct servers.

The first step was to move the terrain downward to reduce the number of unnecessary octree calculations. For reference, here's an image of the previous 512x512 terrain in the middle of the octree.

Here you can see the grid after I lowered it to below the middle of the octree. Dropping the terrain resulted in fewer octree partitions being created at both the top and bottom of the octree.

Next, I stretched the grid from 512m to 1024m. You can see the difference in size between the previous 512m grid and the new 1024m grid in this image.

After expanding the grid to 1024m, I had to tweak the terrain system to support different "terrain resolutions." Before this, the server-side terrain system only supported 1m per vertex terrain, meaning 512 height samples could be taken across and deep on the map with a 512x512m grid. However, to scale the terrain to 1024x1024, I needed to account for a 2m distance between each vertex. You can see the results below after implementing the terrain resolution functionality. It's worth noting that the camera position is the same as in the previous screenshots - the terrain is now just twice as long along the X and Z axes.

You'll notice that the framerate remained steady at around 60 FPS despite drawing all the octree boxes. This is because doubling the space between each entity along the X and Z axes when we increase the size of the terrain reduces the chances of collisions and the number of partitions in the octree, ultimately improving performance and framerate.

To recalibrate, I increased the number of entities to 20k instead of 10k. As you can see in this image, with octree boxes being drawn and the movement systems disabled, the framerate has dipped to roughly 36 FPS.

As a final step in preparing the map to be distributed across eight different servers, I doubled the height of the terrain. This allowed it to occupy all eight root partitions of the octree (both above and below the midline). This image shows Medium running with the performance improvements implemented this month, the scaled terrain, and all systems enabled again.

As you can see, we are now running at approximately 30 FPS with 20k entities. This is slightly less than the 41 FPS we had at the start of the month, but it's important to remember we were only running with 10k entities then. With the recent improvements, we can now run with 10k entities performing physics, movement, and collision detection at a steady 60 FPS minimum - a gain of at least 20 FPS!

It's worth noting that many games have hundreds of thousands, and in some cases, even millions of entities. However, the majority of these entities are stationary. In fact, at any given moment, only a limited number of entities are actively moving and performing calculations such as gravity and collision detection. These entities are comprised of the characters and creatures within the game.

Assuming that 25% of the moving entities are characters and 75% are creatures, our current implementation can support 5k player and non-player characters and 15k creatures, all simultaneously moving within the game world. This is all being executed on a single desktop PC, excluding the upcoming concurrency work I will be completing.

Introducing new format & 2nd monthly blog post

I am happy to announce a new format I will be adopting starting this month to improve communication with our community. This decision stems from the valuable feedback I've received from community members who have expressed interest in differing aspects of our game's development.

I recognize that some community members are primarily interested in keeping track of our progress, while others are eager to learn more about the technical aspects of developing an MMO. Being an engineer, an avid learner, and a teacher, I have a tendency to include more information than necessary (or desired) in our current blog format.

To address these concerns, I will be replacing our current monthly blog post with two distinct types of posts. The first will be Monthly Development Updates, focusing solely on the work completed over the previous month. The second will be a new Developer Blog, which will offer a closer look at the technical challenges I've faced, the learnings that occurred, and other topics of interest to those who want to learn more about the technical and/or business side of game development.

This new format is designed to provide maximum value to all of Soulbound's current and future community members. It will enable me to tailor my content to specific interests while still providing updates on our progress. The Monthly Development Updates will continue to be released on the 2nd Tuesday of each month as before, and the new Developer Blog will be released on the 4th Tuesday of each month, providing deeper insights into the development process.

I look forward to sharing both my progress and learnings with you all through these new formats.

What's Up Next

Looking ahead to June, I'll be wrapping up the work that I began on the Distributed Entity Component Actor System (DECAS). That will allow for fully concurrent execution of the game's features and feature areas and prepare the game engine to be hosted inside a distributed set of game servers.

After that, I'll redirect my focus to the server networking layer to get CoE and KoE back to functioning MMOs. In next week's Developer Blog, I will provide more information about this month's work on the Distributed Entity Component Actor System.

I want to extend my heartfelt thanks for continuing to stay engaged with our updates and development progress. As you saw from the scope review at the beginning, the work on the DECAS is nearly complete. Once the Server Networking layer is in place and I can confirm that everything functions seemlessly, my primarily focus will shift to the Server-Side Game engine. This will involve implementing features such as AI support systems, followed by a heavy push of the CoE and KoE game mechanics.

While the delivery of KoE will happen "When it's ready," and I won't be announcing any specific release date yet, I'm super excited about what's been achieved this year and what's on the horizon! Things are progressing nicely, and I can't wait to share more updates with you all. Stay tuned for more exciting news!

As always, I truly appreciate your continued support and encouragement as I realize our vision for Chronicles of Elyria and Kingdoms of Elyria.

Pledged to the Coninued Development of the Soulborn Engine and the Chronicles of Elyria,