Welcome, Prospectors, to a brand new edition of Weeks Apart, our once weekly dev blog/newsletter for all things Dawn Apart! We know it has been a few weeks since the last update but we were really busy working on some cool features (most of which we cannot share quite yet) and - today’s topic - increasing the overall performance of our little automation game.
One question we get a lot on Steam and social media when we share footage of massive factories, terraformable voxel terrain and large-scale destruction is “will Dawn Apart run on lower-end PCs?”. And we want to assure you that it definitely will. Knowing that frame rate slowdowns and technical hiccups are a huge turn-off for fans of the base-building/automation genre, we are going the extra mile in ensuring that everyone - from players with high-end rigs to owners of laptops that have a few years under the belt - will have a good time automating, optimizing, and fighting on Aurora.
But before we go into the nuts and bolts of making factory building a much smoother experience, we want to once more plug our
Discord channel. Joining the growing community comes with perks: exclusive access to the very first demo of Dawn Apart this summer; being able to follow the development almost in real-time and last but not least weekly live streams of our dev team meetings ('Witchcraft Wednesdays') in which we
drop truthbombs, discuss
the intricacies of hit points and delight each other with
merry tales and jests.
[previewyoutube][/previewyoutube]
While we continue to work on and implement gameplay features (especially combat, which we will reveal soon in a separate blog post) we want to make Dawn Apart run faster, but certain aspects of how we've organized data and processes made it difficult for us to do so efficiently. That's why for the last two sprints we put on our deerstalker hats, played Sherlock Holmes, and identified two culprits that were slowing down the overall experience.
[h3]Speeding up Jobs[/h3]
For starters, we improved the performance of something called the VoxelGpuUploadSystem. As you may have guessed this is a system that handles uploading graphics data for voxels. One big issue we found was with how the system managed its memory. Previously, whenever it needed to add some data to a list of available free memory, it just slapped it on the end of the list and then sorted the entire list afterward. This sorting process was slowing things down a lot.
But lo and behold we found a solution: Instead of adding new items to the end of the list and sorting afterward, we're now using a smarter method called "binary insert." This means whenever we add something to the list, it is put in the right place from the start, so the list is always sorted. Because of this change, the time it takes for the VoxelGpuUploadSystem to do its job during certain intense moments (like when loading or unloading chunks of data) has dropped from 35 milliseconds (ms) to just 3ms. That's a big improvement!
[h3]Less memory for terrain voxels[/h3]
In addition, we found a way to use much less space to store information about the resources in the terrain. Initially, for terrain voxels, we stored information about the type of resource, the quantity of that resource, and whether it had been changed recently. As you can imagine, this took up A LOT of space.
So we had to make a big change. Instead of storing the quantity of each resource, we now just have a chance for the resource to be destroyed when it's being used. So essentially, we only keep track of whether the resource has been affected, not how much is left. So now we only need 8 bits (like 8 tiny pieces of information) to store the resource type and whether it's been changed. This means we can store information for up to 127 different types of resources, which is more than enough for our needs. In the end we reduced the required memory for terrain resources by a factor of 12 from 96 bits down to only 8 or one single byte!
There are a lot of voxels in the ground.Additionally we tackled a large rework that targeted general voxel data. In the same vein we took the memory required per voxel from 4 bytes down to 2. Instead of allowing for almost infinite voxel materials we store a palette of up to 256 materials per unique voxel object meaning we can pack any voxel’s material id into a single byte. We have some additional functionality we wanted, like scuffed and HOT VOXELS, so we added another run of 8 bits which we can pack with attribute data per voxel. It might not sound significant, but when you are dealing with millions of voxels, reducing the memory usage by half is actually huge and helps alleviate bottlenecks both on the CPU and GPU.
Overall these are just some of the steps that we're taking to ensure that when you'll finally land on Aurora to mine Lucrum and build factories the experience will be as polished as possible (even on a potato PC). In fact, we're currently looking into three additional optimization approaches (lazy loading, greedy meshing, and a voxel palette rework) but they are best explained in another blog post. See you soon here on Steam
or on Discord!
This guy (let's call him Hopper) looks like he traded his job as a barista at a coffee shop in Portland for the much more lucrative (and dangerous) gig of extracting Lucrum on Aurora. 
Leaving your home to colonize a distant planet can be a hair raising experience.