As some people might have noticed, our YouTube dev log series has stopped popping up. This is not in any way because we have stopped working, but rather because Simon, who creates these dev logs, has been busy helping a client of ours with a few IT projects. Getting these videos qualitative enough to meet our standards takes a full day each, which is time that can be spent on the development of the game instead. Because of this, we want to start a series of a more light weight blog here, in text format, to make sure you are kept up to date on all the stuff we are up to.
Since our last video devlog in late january, a lot of stuff has happened. The end of January was great, as we had some very successful posts on Imgur & Reddit. Doing this PR work took quite a lot of time, but we are now very confident in that there is hype for this game, which is a feeling well worth what we invested and more.
We can very clearly see that our efforts has an effect on the community size. Here is a graph showing our discord users from november to the end of february. We went viral on imgur 25th and 29th of january, which is obvious in the graph. Team morale is also somewhat tied to this dataset, and it was very clear that we had a surge of ecstasy right about here as well!
So, what about the game?
Most of february went to bringing in money to the game, which ment we did an app project for another company. However, during Mars, we have been hard at work with the engine layer that will make sure the game runs well, and is easy to develop and maintain.
We have been doing loads of things, like implementing our own optimized collision system with wall sliding, refactoring system architecture, implemented vehicles, and just general cleanup. However, there are two major changes that will affect you guys directly, namely Entity Component System (ECS) and XML-based mod support. This blog I will talk about ECS.
Entity Component System (ECS)
ECS is a way of structuring data in a way which makes it much more efficient to do specific operations on a large amount of entities (in our case, for example zombies). The fundamental problem with regular Object Oriented systems, is that there is very little order to how you access data from memory. When you ask your computer to get data you are working with, it will place it in something called a cache. The cache is a box of sorts which contains all the data the computer is currently working with. The box can only contain a set amount of data, so if you switch back and forth between many different chunks of data, you have to change the content of the box all the time. Changing the content of the box takes a lot of time & effort from the computer, which means it will have less time to do the stuff it is supposed to do. ECS makes sure that the system does all the work it needs to do on the chunk in the box before it switches to a new one, which minimizes the time it uses on swapping the content of the box (which is called a ”cache miss”).
Here we can see an illustration of how the data gets organized in classical Object Oriented approach vs. data oriented approach (ECS).
Memory layout in Classic Object Oriented approach
Same memory layout in Data Oriented approach
Source & cred. Highly recommended reading if you wish to further enlighten yourself on the topic:
Unity has created the fundamentals of a ECS system integrated directly into the engine, which is what we are using. Another major advantage of using this compared to the regular use of Object Oriented GameObjects, beside what described already, is that it doesn’t allocate new memory for every creation of a new object. This means spawning and despawning hundreds of thousands of objects can be done in a single frame, without any frame drops. With the regular GameObject system an operation like this would freeze the game for several seconds even on high end systems. It also enables us to make better use of multiple processor cores (multithreading).
So, what does this all mean to you as a player? First of all, it is an amazing performance increase client side. We are running code on tens of thousands of objects each frame without even denting performance. Running movement updates on a large horde of zombies would take 5 ms (milliseconds) with the old system (about ⅓ of our processor “budget” for 60 fps), while it now takes 0.05 ms with ECS. Another huge win is that we can now spawn/despawn objects at will without performance loss, which is awesome considering we are loading and unloading the world dynamically as you move around it.
Performance test profiling ~3000 individually animated entities on the move. Everything running in well below 1 ms, which is 1/16 of the processor ”budget” for a frame.
Next blog we will head into details on the XML-based system we now use for content creation, and what it will mean for the game, as well as future modding support!