Engine determination… The first step with some overthinking.

Okay. I have a plan. I have a working prototype. I have a story I’m dying to tell. So naturally, the next logical step is to spend a lot of time second-guessing my tools.

Let’s talk about it.

What I’m Actually Making

My first commercial game is a narrative-driven, first-person dungeon crawler RPG. In my style. My soul poured into it.

My biggest inspiration is the Shin Megami Tensei series. Those games are philosophical, dark, and strange in the best possible way… commentary on society, demons, ritual, the nature of humanity. Heavy stuff wrapped in incredible design. But here’s what I keep noticing: not many people are making first-person dungeon crawlers anymore. The last one I played outside of SMT was Spike Chunsoft’s Zanki Zero, which was fantastic … Spike Chunsoft almost always is. But both Zanki Zero and SMT share a lot of the same DNA, the same tropes, the same bones.

I want to expand on those bones. I think the genre has so much more room to breathe than it’s been given. Good story. A battle system that’s actually fun. Environments that are genuinely interesting to look at. That’s the goal. (Side note: if you’ve never played Shin Megami Tensei: Strange Journey on the DS, stop reading this and go fix that. Some of my all-time favorite environments in any game, ever. Incredible stuff.)

The Engine Problem

Here’s where I’ve been spinning my wheels. I have a working prototype… dialogue system, movement, battle system… built in Construct 3 about a year ago. I was genuinely proud of it. Construct 3 is a visual editor, event-sheet based, and you don’t even need to write code if you don’t want to. It let me focus on design instead of plumbing, which is exactly what I needed to get something off the ground.

The problem is that Construct 3 is fundamentally a 2D engine that happens to support 3D imports. And for a dungeon crawler where the environments need to feel alive and distinct… no repetitive textures, no getting turned around because every hallway looks the same… that’s a real limitation. Lighting is a nightmare. Dynamic details are a nightmare. Rooms want to be right angles. 3D in Construct 3 is still somewhat experimental even now, and I can feel the ceiling getting closer the more I push on it.

So. What else is out there?

Unity and Unreal: No.

I refuse. Both of them are completely bloated for what I’m trying to make. They’re massive 3D engines, which means I’d be fighting them in the opposite direction from Construct … instead of wrangling 3D into a 2D engine, I’d be wrangling 2D assets and GUI work into a 3D engine. Not worth it. Overkill. Moving on.

Godot: This Is Probably It.

Godot keeps calling my name. I’ll be honest… I wrote it off for a long time as the trendy meme engine, the thing people talked about without actually shipping anything. I was wrong. Really good games have come out of the Godot community and the engine has earned its reputation. I’ve made some simple things in it as tests and while my experience is still limited, GDScript is basically Python with a different hat on. I know Python. The syntax clicks.

More importantly: Godot has a full 3D editor AND a full 2D editor. I can build detailed 3D environments and layer in 2D sprites, UI elements, and everything else exactly the way I want. The two worlds can coexist cleanly. That’s exactly the workflow I need for this game.

The one thing giving me pause is the learning curve. I don’t have deep Godot experience yet. Is taking a week or two to properly dive in going to kill the project’s momentum? My gut says no. My gut says a week of investment now saves months of fighting the wrong tool later. But it’s still a mental hurdle.

Love2D: The Wildcard

Love2D is fast, lean, and genuinely fun to work in. It uses Lua, which makes prototyping feel almost effortless. I’ve built things with it before and never once wanted to throw my computer out a window. That’s high praise!

But Love2D is an open framework, not a full engine, and my target is Steam… Windows, Mac, Linux. I’d be responsible for a lot of the scaffolding myself. Commercial viability is a real question mark. I haven’t ruled it out entirely, but I haven’t convinced myself either.

MonoGame: Maximum Power, Maximum Pain

MonoGame would give me the most control of anything on this list. The most optimization potential. It’s a framework, not an engine… you build what you need, exactly how you need it, and nothing extra exists to get in your way. For a commercial product it’s rock solid.

The catch: you have to build your engine before you can build your game. Slow. Methodical. Purposeful. Every system from scratch.

And here’s the thing I have to be honest with myself about: I am not a planner. I have a story. I have a vision. I do not have every detail mapped out on a spreadsheet, and I never will. I work best when I’m designing, building, discovering. Organic. Natural. Putting me in MonoGame would mean weeks of groundwork before I get to make anything that feels like a game. Would that kill my momentum? Probably. Would it kill my spirit? Possibly. I have to respect that about myself.

So. Where Does That Leave Me?

Godot. My eye keeps coming back to Godot.

GDScript feels like home. The engine can do everything I need. The community is strong and getting stronger. There’s no licensing headache waiting for me if the game actually sells. And the week or two I’d spend getting properly comfortable with it isn’t procrastination… it’s foundation work.

I know myself well enough to know that once I pick something, I need to commit to it. No mid-project engine swaps. No “maybe I should port this.” Pick it, plant your flag, and build. I have a story to tell and I want to tell it, and the only way to do that is to stop evaluating and start creating.

I’m going to look back on this post after the game ships and laugh at myself for agonizing over this. I already know it. But this is step one, and I haven’t taken it yet. You can’t start a journey without that first step.

Time to step.

— Anders