Developer Blog #5 - The Engine of Astronimo š
Hello again! Iām Jimmy, Lead Programmer on the project and today we are diving into the technical details of the engine that powers Astronimo.

Formally the engine has no internal name, however it is jokingly referred to as āJimgineā as its a collection of code that started when I was in University and since then with a major team effort has snowballed into what weāve got today.
From there the game is layered on top, entirely in C++ to reduce the amount of technical complexity involved in integrating other scripting languages.
[h3]A few quick stats.[/h3]
The codebase is around ~160k lines of C++ code making up 99% of the engine + editor + game + tooling. External libraries make another ~300k lines, used for a variety of things from image loading to editor ui.
All in all, the project footprint is actually pretty small and something we aim to keep, given that we only have a small team of mostly generalist programmers working on the game.
[h3]But why make our own engine?[/h3]
This has to be my most asked question by every developer who has interacted with this project. āWut ⦠why the heck would you make your own custom engine, you crazy!ā

On reflection, I think itās a little of the following; arrogance, naivety and luck. I hoped we would have more control over what we made, less reliance on tooling out of our control and ultimately freedom to make the project into whatever we wanted. Also management somehow agreed, ha! Given how long this project has taken us, Iām not so sure they would again though ā¦
I actually think a custom engine panned out pretty well in many respects.

There are definitely some downsides though.
[h3]How we load a level[/h3]
For the main campaign, the solar system is really just one GIANT scene. Devs can fly to any part instantly, drop a character in and start playing. Most devs have their own little clusters of planets for testing things in there too. Pretty neat!

In most other projects I have worked on there are scene files describing the layout of every object. This makes collaboration very painful as only one person can edit said scene at a time. We took a different approach here, making every object in the solar system its own file instead. So if I move a rock somewhere, the only file I need to save and commit is the file representing that rock.
These objects are called .wob files, which stands for World Object and also because wob is an amusing word.
Behold my skills as a professional translator of rock wobs!
Wobs for both the main game and custom player made worlds are then packaged up into big container files, making it much more efficient to distribute on Steam and upload to the Steam Workshop.
[h3]Rendering[/h3]
Given the small team size, our renderer would probably not be considered an astounding technical feat of engineering. However itās got some cool things going for it!

Itās a DX11 renderer with a relatively thin shim around it for swapping to other graphics APIās. We originally supported OpenGL, but ended up transitioning away due to driver issues. Our shaders are actually still all in glsl, and we convert them over to hlsl on import.
Drawcall/Material info is packed into large buffers and then we invoke DrawIndexedInstanced to batch many drawcalls together. Skinning is a dynamic branch in vertex shaders and does not affect the batches.
Textures/Meshes are packed into pools on demand as the camera moves around the world so we are constantly streaming resources up.
For global Illumination we use a voxelization technique.
3 voxel clipmap layers are rendered out, covering most of the camera frustum.
Each frame we voxelise the scene into 3d textures, then gaussian blur / filter them. We run a lighting pass, rendering at half resolution that raymarches against the filtered voxels and produces indirect lighting. We then upscale and mix this with the main render pass. This concept is a little old now, with all the fancy new ray-tracing features beginning to take over the industry. It has a few annoying artifacts I would love to address one day if we get the chance.
Fin
I could ramble on about this engine forever, but I will spare you for now! Working on this project has been an amazing learning experience and it is immensely satisfying to see what we have managed to build from the ground up. Even more so I am looking forward to seeing what utter insanity you can come up with in the custom world editor on release!
Astronimo will be released in Early Access this year. Add it to your wishlist now!
Join the official Coatsink Discord Server.
Follow Astronimo on Twitter.

Formally the engine has no internal name, however it is jokingly referred to as āJimgineā as its a collection of code that started when I was in University and since then with a major team effort has snowballed into what weāve got today.
From there the game is layered on top, entirely in C++ to reduce the amount of technical complexity involved in integrating other scripting languages.
[h3]A few quick stats.[/h3]
The codebase is around ~160k lines of C++ code making up 99% of the engine + editor + game + tooling. External libraries make another ~300k lines, used for a variety of things from image loading to editor ui.
All in all, the project footprint is actually pretty small and something we aim to keep, given that we only have a small team of mostly generalist programmers working on the game.
[h3]But why make our own engine?[/h3]
This has to be my most asked question by every developer who has interacted with this project. āWut ⦠why the heck would you make your own custom engine, you crazy!ā

On reflection, I think itās a little of the following; arrogance, naivety and luck. I hoped we would have more control over what we made, less reliance on tooling out of our control and ultimately freedom to make the project into whatever we wanted. Also management somehow agreed, ha! Given how long this project has taken us, Iām not so sure they would again though ā¦
I actually think a custom engine panned out pretty well in many respects.
- We get to ship the editor tools to players! So fingers-crossed, you guys can get way more creative and nutty with the engine that we could ever dream of.
- Iteration times for building in the editor are FAST. You try this for yourself in the games World Editor. Once the world has initially loaded, you can instantly drop characters in/out to test your level. Designers are very happy with this when constructing planets!
- Code iteration times are pretty fast. For many code changes we can recompile and hotload in

There are definitely some downsides though.
- Hardware issues and GPU drivers are an absolute pain and timesink. An uncountable set of permutations of annoying ways the game can crash for different people with different hardware setups on different versions of Windows, looking at different monitors on different refresh rates at different times of day using different peripherals with different network setups and different GPU drivers. It's truly mind bending madness sometimes.
- VFX team have had a rough time. A very custom renderer of little resemblance to any major engine, missing any niceties like shader graphs/fully featured particle systems, alongside dealing with a crazy inter-planetary coordinate system means itās been tough going. They still absolutely smashed it though!
[h3]How we load a level[/h3]
For the main campaign, the solar system is really just one GIANT scene. Devs can fly to any part instantly, drop a character in and start playing. Most devs have their own little clusters of planets for testing things in there too. Pretty neat!

In most other projects I have worked on there are scene files describing the layout of every object. This makes collaboration very painful as only one person can edit said scene at a time. We took a different approach here, making every object in the solar system its own file instead. So if I move a rock somewhere, the only file I need to save and commit is the file representing that rock.
These objects are called .wob files, which stands for World Object and also because wob is an amusing word.

Wobs for both the main game and custom player made worlds are then packaged up into big container files, making it much more efficient to distribute on Steam and upload to the Steam Workshop.
[h3]Rendering[/h3]
Given the small team size, our renderer would probably not be considered an astounding technical feat of engineering. However itās got some cool things going for it!

Itās a DX11 renderer with a relatively thin shim around it for swapping to other graphics APIās. We originally supported OpenGL, but ended up transitioning away due to driver issues. Our shaders are actually still all in glsl, and we convert them over to hlsl on import.
Drawcall/Material info is packed into large buffers and then we invoke DrawIndexedInstanced to batch many drawcalls together. Skinning is a dynamic branch in vertex shaders and does not affect the batches.
Textures/Meshes are packed into pools on demand as the camera moves around the world so we are constantly streaming resources up.
For global Illumination we use a voxelization technique.

Each frame we voxelise the scene into 3d textures, then gaussian blur / filter them. We run a lighting pass, rendering at half resolution that raymarches against the filtered voxels and produces indirect lighting. We then upscale and mix this with the main render pass. This concept is a little old now, with all the fancy new ray-tracing features beginning to take over the industry. It has a few annoying artifacts I would love to address one day if we get the chance.
Fin

I could ramble on about this engine forever, but I will spare you for now! Working on this project has been an amazing learning experience and it is immensely satisfying to see what we have managed to build from the ground up. Even more so I am looking forward to seeing what utter insanity you can come up with in the custom world editor on release!
Astronimo will be released in Early Access this year. Add it to your wishlist now!
Join the official Coatsink Discord Server.
Follow Astronimo on Twitter.