Hello, and welcome to the 8th devlog for Red Dust Colony. Last time we were in the middle of bugfixing following the private release of a demo on our Discord server. I'm happy to say that the game is much more stable now, with the last build receiving no crash or bug reports. With the base of the game stabilized we can move forward, add more content, polish what we have and improve the overall gameplay.
Procedural map generation
One of the first things that we wanted to rework was the way maps are generated. We'd like to provide multiple types of maps each with their own styles and intricacies and what we had until now wasn't powerful enough to handle everything.
The current system was something developed early on as a temporary solution and while it has served us well until now, some of the issues were starting to surface. Let's go over the basics of map generation first and then see how it fit in the old system vs how it fits in the new one.
First of all, map data is expressed as a 3-dimensional grid, where every cell contains information about what kind of tile it contains. The possible tiles currently are regolith, iron, copper, ice or none. We plan on adding a few more types in the future. In order to create this data, we create a 2-dimensional grid where every point contains the height of the terrain. This is commonly referred to as a height map.
To do this we use something called Perlin noise. By itself it doesn't look that interesting but if we apply it multiple times in a row it generated mountain-like formations.
This data is then adjusted a bit so we have a flat base ground.
Finally, we take this heightmap and use it to create the 3-dimensional grid where every cell is filled if it's under the height defined by the heightmap. The following animation shows individual slices on the vertical axis.
For resources generation, we use something called cellular automata. In simple terms, this helps us create natural-looking clusters of resources by following simple rules about how materials group together. This algorithm takes a randomly initialized grid, and then for each cell, it determines if the cell should be filled or not based on a rule. This step is applied multiple times in a row. The most basic rule we use is to count the neighbouring cells that are filled. This is how it looks like when the rule is applied multiple times in a row:
In the end this generates pockets of filled cells which we use as iron, copper or ice. All this data is then combined in a final grid that contains all the necessary information. This animation shows individual slices on the vertical axis, where red is regolith, blue is iron and green is copper.
The old system
Before, we had a system where all the steps from above could be combined together in a visual editor. This allowed us to change and tweak the generation without having to change any code.
Unfortunately, due to initial time constraints, the interface only allowed configuring this in a tree like structure instead of the ideal graph structure. Another huge problem in the original implementation was performance related. All of this was running on a single CPU core even though each cell in all these steps can be calculated independently of eachother.
The new system
In order to solve all the problems from the old system, the new one was redesigned from the ground up. First of all, the editor now works with graphs where every step from before is a node. These nodes can be combined in any number of ways, allowing to use the results of a node in multiple places, something that was not doable before. This is how the same map generation from before looks like in the new system:
Before, if we wanted to see how the terrain looks in game, we'd do some tweaks and start the game. While this works, it's not exactly fast to iterate on. In order to resolve this issue, we added a secondary panel to the editor where results can be previewed almost in realtime.
From a performance point of view, the gains have been incredible. The new system distributes the work seamlessly across all CPU cores available while also taking advantage of a technology called Burst which makes code written in a specific way run much faster. If the map data generation used to take 3-4 seconds for the biggest map before, an equivalent configuration now takes around 80 milliseconds. What this really means for players is faster loading times when starting new games and the ability to generate larger, more diverse maps without long wait times.
With the system being so flexible now, adding more types of nodes was trivial. All this allows us to make new types of maps now, like canyons and craters. These maps are all created with this system:
Looking Ahead: Our Development Timeline 🚀
As many of you know, we initially targeted a 2024 release. This was an optimistic release timeline from when we thought we could get everything ready by the end of the year. From the demo we've learnt that we're not quite there yet and at the end of the day, we will only release the game when it's ready. We realize that this might not be the news you were hoping to hear but we hope you understand that we care deeply about the game and want to do right by it.
We're updating our Steam page to show "Coming Soon" rather than 2024, but rest assured that development is proceeding steadily. Our focus remains on delivering the best possible experience, supported by the invaluable feedback from our community.
We are continuously developing the game with the involvement of our amazing Discord community, which have been helping with play-testing the private demo that will continue to be updated as we're improving things. Thank you to all our Discord friends that have been following along, playing and giving us so much helpful feedback! 🖖🏼
If you'd like to join us in our journey, join the Discord server and we'll let you know when we're ready to have you try the game.