In June we entered a small game called Graveyard Orbit in the June NextFest. It was our attempt at making a fun space mining incremental with actual build choice and not a random skill tree. Anyways, we really liked the mechanic and vibe of the demo, but the structure that you mine in the demo was smaller: a couple of thousand tiles. For the actual game we wanted to have a parade of structures from that small up to 250k tiles. The game is meant to be more satisfying than challenging, in the vein of Powerwasher but in space. So if people dug the mechanic we wanted them to have some beefy structures to make their way though as it goes.
The demo for NextFest was made in Godot and it worked really well at that scope. The three of us have been using Unity professionally for 15 years but really love what Godot is doing and wanted to experiment a little. But as NextFest ended we realized we wanted to double down on the game with better FX and still hit those big structure goals with reasonable performance. That was a big concern.
Here is the trailer for that Godot version for context:
https://youtu.be/9otz9z1lUzY
It only took a week or two to set up a performance test in Unity. For this one we switched to 3D, still sorta presented in 2D or 2.5D, but with 3D we had all the optimization, our library of asset store FX, and experience on our side. The results of the test were pretty clear, so then we took the plunge and completely rebuilt the game, this time in Unity and in 3D. After 2 months we have a new demo and are very happy with the results.
Beyond performance, a real risk for me was losing some of that “demo magic” and vibe we had with the Godot version. I had spent two months in the Godot version building an aesthetic with pixel art and 2D graphics. By the time NextFest came around, I was really happy where we landed and how the game felt.
The vibe and feel of a game can be such an elusive factor. We spend hours working on mechanics with barely any visuals. We have to cling to some vague notion of the final game in our heads that is always changing. Which is why when you land on something you like, it's easy to get precious with it. Sometimes the results feel like a happy accident that you don't want to screw up. In our case we could save that Godot version as a fallback and start a new Unity project trying to recreate what we had. I think forcing ourselves to rebuild something but better or improving something we are already satisfied with requires us to breakdown the elements of what made whatever we liked so special.
We have game jams to help us practice iterations for the whole game dev cycle but the stakes of that can be low. I think refining, rebuilding, and iterating on something we already like gives us the same benefit of practice but with much more precision and craft because the degree of difficulty and stakes are so much higher.
Anyways, I thought this might be helpful to those considering a rehaul of their game for whatever reason. It can be risky with the work involved but if your instincts are telling you something has to change then I think it’s good to trust your gut and at least give it a try. Our only risk really was that two week experimentation time. We could’ve easily not been happy and went back to finishing the Godot version in limited way. I’m very glad it worked it out.
Also, for the Godot fans out there, I am one of you. I blame my issues with Godot more on my ignorance and unfamiliarity with the platform than Godot’s actual capabilities. In the end our own experience and library of assets in the Unity ecosystem were just as big a factor.
Here are some specifics we got out of the switch.
- Structures at the size we wanted. Our biggest one is 250k hex tiles. In Unity that's one instanced draw with per-instance colors through a property block and it just runs. Some caveats on that below.
- Going 3D while still playing top-down. Real lights, URP bloom for the neon look, and we could finally use a VFX pack we'd already paid for instead of hand rolling every effect.
- UI Toolkit. The base has 7 station screens plus a whole ship builder. Doing all of that in UXML/USS with one shared console frame was way faster than what we had before, once we got past the weird parts.
- The new Unity CLI. Recompiles, play mode, builds for Steam, itch and our Mac test builds all run from the terminal. One project, three targets, no clicking through the build window.
- Web builds. Because the performance was much smoother it became possible to attempt a build for the web for places like itch. Only the demo size structure but still.
A few hiccups, mostly from the web build. More details here because I just finished the web one yesterday.
- WebGL 2 has a 16KB uniform block limit. GPU instanced variants of some asset store shaders blow past it, and the failure mode is nothing. Objects just don't draw. Turn instancing off on those materials.
- Browsers reject fullscreen requests that aren't from a click, and inside itch's embed Unity turns that rejection into a big error popup. Don't apply a saved fullscreen pref at boot on web.
- With the default exception setting, a null ref on web is a WASM trap, not a logged exception. A player lost an 80% run to that. Full without stacktrace fixed it.
The newer demo is live now if you want to give it a spin:
https://store.steampowered.com/app/4654120/Graveyard_Orbit/
https://anchorheadgames.itch.io/graveyard-orbit
