Before a single line of code got written for Habitat, I spent a lot of time — probably more than I'd like to admit — exploring various game engines. Here's the honest walkthrough of that decision, including the engines that didn't make the cut and why.

Images are links.

I had briefly considered Unreal or Unity as primary options but rejected them, and it wasn't because they aren't capable — they obviously are, more capable than almost anything else out there. But I'm a solo developer, and both engines come with a scale and complexity that's built for teams, not one person juggling code, art, sound, and level design simultaneously. At one point I did actually attempt to learn Unreal's Blueprints visual scripting system, but I just couldn’t get it to click. Both engines just had so many features – features I would never need for the game I was envisioning.

Godot is a genuinely impressive engine, and it's hard not to respect what the open-source community has built. But from what I could tell, it really shines as a 2D engine first — its 3D performance seemed to slow down noticeably once things got more complex, which is a real concern for a game like Habitat with full 3D environments, creatures, and physics all running at once. To be fair, I’d not experimented with the latest-and-greatest version of Godot, so things might have improved on the 3D side. But there was also the consideration that you needed to script your Godot projects in its own unique scripting language. I really didn’t want to spend time learning a scripting language that could only be used in one place.

I looked at S2ENGINE HD too, from Profenix Studio, and ultimately passed on it for a few reasons. Its scripting system, called GameMachine, is a node-based visual system built around State, Event, and Action concepts was considerably more elaborate and involved than I wanted to take on and documentation is sorely lacking. On top of that, the editor UI itself felt extremely cluttered, exposing just about every function and feature to the end-user. And, fairly or not, the visuals felt like they were starting to show their age next to more modern engines.

GameGuru MAX is built on the Wicked Engine, which is a full-featured game engine. However, the developers of MAX had decided early on to limit what features are actually available to the end user, which ended up feeling too restrictive for what I wanted to build. Development also moves very slowly — things that other engines with similarly sized teams accomplish in a much shorter timeframe can take years to arrive in MAX. And while the GameGuru MAX system is one of the easiest to use to get a simple game up and running quickly, it has some severe issues that ensured it could not be a contender for a serious project. For example, creating your final standalone game can sometimes have scripts that don’t work for some reason or even missing assets.

Flax stayed on my radar the whole time, not as a first choice but as a deliberate backup plan. It's a genuinely modern, capable engine, C#-based rather than Lua, and free until a game earns real money. If Leadwerks ever became a dead end, Flax was where I'd go — I never wanted to be without an exit strategy.

What ultimately won me over was a combination of things. Technically, it's genuinely impressive for its size: a deferred renderer, brush-like CSG meshes that make level blockouts fast and intuitive, and a scripting workflow where attaching a script to an entity is as simple as a single click. It has its own fully integrated Lua editor built right into the tool, and the whole UI live-updates as you work — change a script to expose a new parameter, and it just appears in the properties panel immediately, no restarting the editor required. Not only that, but Leadwerks has a simple, but effective prefab system, allowing me to easily create re-usable ‘chunks’ to speed up my level design workflow.

Beyond the technical side, a Lua-based scripting workflow clicked for me in a way Blueprints never did, and the visual Flowgraph system suits how I think as an artist. Just as important — Josh, the develop of Leadwerks, is active on his own Discord, quickly answering questions and providing frequent information about updates and plans for the engine. Before committing further, I actually stress-tested the engine myself rather than taking anyone's word for it — maxing out every graphics setting at high resolution and confirming it held up well under real load. That mattered more to me than any marketing claim.

Leadwerks is genuinely fun to work in and I think that matters a lot when you’re deep into game development.