This is the first in a mini series about the 3D voxel-based game world. I skimmed over the concept in the first devlog, and the idea of this series is to cover interesting technical details and design decisions.
Note that these posts only document the design at the time of writing; I foresee plenty of churn and restructuring in the future, but that doesn't necessarily invalidate the previous designs as incorrect, just that my requirements changed.
First of all, I want to describe my high-level aspirations for the game world. As above, it is 3D and voxel-based.
The 3rd dimension brings a great deal of technical challenges and extra gameplay considerations, which I feel definitely belong in this simulation-targeted game. RimWorld has gotten away quite successfully with only 2 dimensions and simpler game mechanics than Dwarf Fortress, but as mentioned in the vision and goals post, I want to strive for ridiculous depths of simulation rather than commercial success.
Blocky voxel mechanics fit this genre of game with destructible terrain very well, and can be visually pleasing as RimWorld has shown, so this is the obvious choice for me. Space Engineers employs smoother, polygon-based voxels that work well with a 3D camera, but I don't think this would work well from a top-down-only perspective.
In the current implementation, the up and down arrow keys move the camera up and down in the game world by a single, discrete slice of blocks (or Z-level for DF fans), as can be seen below.
High voxel granularity
The scale of voxels to entities is still undecided, but I'm thinking 1 block will be around 1 foot/30cm. On a scale between Terraria (tiny blocks) and Minecraft (huge cubic metres), it will definitely be closer to the Terraria end.
This will allow for a reasonable level of detail in world mechanics - building insulation and aesthetics, for example. Instead of building walls out of a single layer of wood or stone blocks, I want it to be possible to build up layers of e.g. bricks on the outside, insulation within the wall, and a fancier material on the inside.
Finite planet surface
The game world is limited to a distinct/unique procedurally generated planet, where the explorable space is enormous but not infinite. Circumnavigating the planet should be an ambitious but attainable task, and players with the nerve (and time) will eventually find themselves back where they started1.
Because of this constraint, there can be many passes during initial generation to produce interesting global features that would be a lot harder in an infinitely expanding Minecraft-esque world, such as:
- Latitude affecting the environment, i.e. colder near the poles, warmer near the equator
- Distinct continents and oceans
- Realistic mountain ranges/rivers flowing towards oceans (to some degree2)
In contrast to the limited planet surface, there should be no (unreasonable) limit in the vertical axis. Mountains should pierce the heavens, oceans should plunge to bone-squishing depths, and mining should eventually lead to the planet's core (or until it's too hot for anything to survive).
Realising this ambitious goal of generating and simulating a massive game world is assuredly not a simple task, which is the main motivation for this devlog series. Posts in the future will cover:
- 3D voxel grid data structures for optimal cache coherence
- Procedural planet generation
- Continent placement
- Biome allocation
- Global feature placement (e.g. mountain ranges)
- Regional and local feature placement (e.g. trees in forests)
- Ridiculous (but fearless™️) concurrency for terrain generation/loading/modifying
The last 6 months (since Nov 2020) have been slow for writing while I've been busy implementing half of the above, which I can finally start documenting. Stay tuned for a slew of deep technical dives!
There's infinite scope for realism here, which could include accurate weather (moisture, cloud formation, precipitation), erosion, volcanoes, etc. Maybe even to the depths of Dwarf Fortress by simulating the rise and fall of civilisations over centuries. ↩