5 min read

Releasing a 3D game with Godot Engine 🤖

My experience with the open source Godot game engine. A Postmortem of Trigger of Time, a short first-person adventure exploring time relativity. What I learned and you can learn too.

I made Trigger of Time, a short first-person adventure about time relativity. It’s not the biggest game, but still: 3D + first person + one big level… this kind of thing is not super common in Godot yet.

Trigger of Time on Steam
A vanished expedition. A forgotten underground city. Explore the echoes of a lost civilization in this short first-person adventure, and bend time to solve intricate puzzles woven into the ruins.

This post is my small postmortem. Many articles about Godot are very positive, and for good reasons. But I also want to share the less fun parts I encountered, without sugar coating. It’s not to say Godot is bad — I actually love it and I will keep using it 💙 — but to give a more real picture of what it feels like to release a full 3D game with it and how to mitigate issues.

Why I picked Godot 🏆

  • It’s flexible. Unreal felt too heavy and rigid when I wanted to prototype. Coming from a programmer background, Godot was faster to bend.
  • It’s lightweight. Loads fast, runs on laptops, small builds. I often work on the fly, not always at home, so that was amazing.
  • It’s open source. No Unity-style drama, just community driven. Most resources are still 2D focused, but it’s growing.
  • It’s “good enough” for my graphic goals. I did hit limits, but nothing that stopped me.
  • Runtime is just beautiful: I built mainly on Mac, tested on Windows, tried a bit on Linux. Everything worked. Switching back and forth with no issue. Pure joy.

So overall: it was the right tool for me. Also note I'm mostly solo, so no team workflow coverage. But now let’s talk about the pains.

💡
The game was made with 4.3 and 4.4. So info can be outdated. I'll try to update them as Godot gets updated.

C# (and my regrets) ⚡️

I picked C# because I came from Unity. It felt logical. But honestly… I regret it.

Two reasons:

  1. It is slow. Slow to setup, Slow to compile, slow to launch. Every little test became “wait a bit” and it killed my momentum.
  2. No profiling. At all. Godot 4.3 and 4.4 just didn’t have profiling for C#. I discovered this only when performance dropped, too late. Rider profiler works, but only for a short time unless you pay.

So yes, C# can be a bit faster in performance. But in practice, the slowdown of workflow was worse. My next games will be in GDScript. Easier, faster, update at runtime and profiling works out of the box.

Assets import 🐢

I modeled everything in Blender. Godot can import .blend files directly, so I used that. Big mistake.

The import was super slow and sometimes crashed. I also spent too much time checking/unchecking what to import. In the end I learned the hard way: keep working files separate from export files. Export to GLTF is the way. Blender Studio has a good workflow article about it here

Otherwise it worked well, no other issue, pretty easy to work with!

Crashes 💥

The editor crashed frequently. Probably average 2–3 times a day, sometimes 20 times a day. Opening a level, closing a file, importing an asset, whatever. My game is not a huge game, but the bigger it got, the more Godot editor was falling apart. The good news: newer versions are more stable, so keep your engine up to date.

Important: the built game never crashed once on testers. So at least the crash party is only for devs. 😅

Project corruption (the sneaky one) 💣

This one nearly killed my game. Godot sometimes corrupted or reverted my project files. Scenes, overrides, signal connections… just gone. No alert. No explanation. Just work disappearing.

I suspect nested scenes and @tool scripts made it worse, but I couldn’t find a clear cause. I opened an issue here, but since it’s hard to reproduce, it’s stuck.

If I didn’t use git versioning, my project would be destroyed forever. Please: set up versioning early. It saved me many times.

Also, thankfully Scenes in Godot are text based, so it's easy to edit and fix!

Editor pain 🤬

This one is simple: selection in 3D is unreliable. Sometimes you click something, it selects what’s behind, or not even on screen. There is no undo/redo for selection, which is painful when working with groups of objects. Gizmos also behave strangely, sometimes sending objects flying. They are also affected by post-processing (they blow up in the dark because my levels are low exposure).

Overhaul it's hard to make levels in Godot. I understand why most people making 3d games in Godot uses Blender, or other tool like Trenchbroom to create levels.

It’s not game-breaking, just patience-breaking. Blender feels way smoother on that front.

Encryption and piracy 🔐

At first I thought: “if someone wants to hack my game, let them. I started as a modder myself, I know the fun.” And I also think piracy can be a way to share culture.

But when release came closer, it was scary. Decompiling a Godot game is too easy. Like, one click and my entire source code and folder structure was open. My small codebase is something I reuse for all my games, so losing it would be a huge risk. Even worse: the game can be rebranded and resold. And it already happened.

Thankfully, Woto helped by forking Godot to get proper encryption. Without that, release would have been very stressful. So think about this early, don’t wait days before launch, like me.

Graphics 🎨

Godot can look beautiful, but you need to dig in. Everything in Trigger of Time was custom shaders, lots of light and volumetrics tweaking. Thanksfully shaders is a pleasure to work with in Godot.

I used all tricks in the book for optimization: LOD, script freeze, occlusion culling, distance fade of objects, shadows and lights. Lightmap baking was broken in 4.3 so I did not used it (better in 4.4 and 4.5).

One tricky thing: my game is very dark, so I had to fight with exposure. There is a handy EXPOSURE constant you can use in fragment shaders (not in the docs!), which saved me. Also FSR 2.2 does not work with low exposure.

Music and sound 🎵

Sound is crucial for me. I only used Godot’s built-in features, and it mostly worked. The new interactive music system is cool, but it misses a way to detect when a track ends, which caused me headaches.

I also feel Godot needs more advanced audio features (like sound occlusion, or per-sound DSP instead of per bus). Next time I’ll probably use a middleware solution.

Conclusion ✨

Making Trigger of Time in Godot was not “easy”. But I think no engine would have been easy. Game development is just demanding.

Godot 4 is not fully mature for 3D yet, but it’s getting better every month. And despite all the problems above, I’m grateful. My game exists because of Godot, and that’s amazing. Big thanks to all the devs working on it 🙏

If you’re making a game with Godot, I hope my story helps you avoid some traps. And if you’re hesitating: give it a try. Just remember to setup versioning before anything else 😉

If you made a 3D game in Godot too, I’d love to hear from you!