Welcome to the new "Satus Saturday Summary" - the weekly post where we share the latest updates on our game and give you a peek into our development process.
We believe it's important to be transparent with you, our community, which is why we dedicate time each week to prepare this written presentation of our progress. It's a great way for us to get feedback from you and hold ourselves accountable for meeting our goals.
I know it's been a while since we've released any updates on our gameplay features, but that's because we've been hard at work on some fundamental building blocks of the game. These efforts will allow us to take the game to new heights and create gameplay experiences that were previously impossible. We've endured the tedious part of the process and are now picking up the pace of gameplay feature implementation. Thus, I am excited to share our journey with you and hope you enjoy our regular development blogs. Thanks for being a part of our community!
Today, we are going to talk about something fundamental to this game, the rendering of blocks. They make up most of the unanimated objects the player can place, destroy, and interact with. It is being done in a scalable and efficient manner.
Our ideas involve constructing this boundless stage by using blocks, in which players can immerse themselves in their own kingdom. We believe this approach strikes an optimal balance between replicating the fidelity of the real world and providing an enjoyable experience for players. Dividing the world into one-meter cubes offers sufficient detail while remaining manageable for players of all experience levels. We've also developed a more diverse block system, comprising four fundamental components: block shape, as well as three distinct textures for the base, middle, and top layers. With this system in place, we enable a combination of these four elements, allowing for a wealth of creative possibilities and enhanced customization for players.
Think of a "grimy, gilded marble wall", which will be broken down to "covered with dirt" for the top texture layer, "adorned with gold" for the middle texture layer, "marble as the primary material" for the base texture layer, and "wall" for the block shape. This provides more dynamism to the gameplay, allowing players to create more blocks as long as we can draw them at runtime.
However, not everything is easy with "just draw customizable blocks" because we are not drawing only a few; we are drawing millions of them. Doing something at such a scale requires some optimization, which sometimes includes compression and batching.
One thing I noticed that could account for a slower mesh generation speed was that the mesh took up too much space. This slows down the CPU memory access and the GPU upload, creating a performance bottleneck. By compressing that data down by a factor of 12 without compromising customizability, we see a smooth frame rate when terrain is changing and loading.
Batching means grouping multiple tasks together and processing them as a single unit to reduce the overhead associated with processing them individually. We do not generate mesh one block at a time but we manage them in 16 by 16 by 16 chunks. In order to take advantage of processing them at once, iteration speed is key. In this regard, different data structures are used to store the various block data in contiguous chunks of memory, allowing the CPU to do more work with less time spent reading from memory. This kind of practice is commonly used in game development, and we will see its benefit not only in the generation of terrain chunks but also in processing common game logic for the massive number of entities we plan to simulate.
In conclusion, while we've delved into the complexities of block rendering and optimization, there are many other fascinating aspects of game development that we have yet to explore. However, that is a topic for another day. Stay tuned for more insights into the game, and thank you for being a part of our journey. Let us know what you think about the game.
Comments