So, What's the Downside to Using a Game Engine to Build Your Apps?
So last time, dear reader, we talked about why I chose to build my Vault application and, indeed, my whole ARCANA Suite in Godot, a game engine. We talked about open-source, about having a framework that understands better what it is you're trying to build, using that framework to solve other problems you're having with it, and the challenge of doing the project itself. Those are all net positives that were really important to me when I decided to take this project on. Now let's talk about the cons. Because there ARE cons, and if you're thinking about doing this for your own projects, you probably ought to know them.
Oh, and right off the bat... if you've run into these issues and others and have found better solutions than I did: 1) I would love to hear them, and 2) forgive me the simplicity. This was and still is all very new to me.
Con, the first: Threading
Godot’s threading model works, but it’s not optimized for heavy I/O. Parsing a directory structure with hundreds of thousands of files or generating thumbnails for ten thousand images; either of these are big, big tasks. Godot HAS a Thread class, and it gets the job done, but threading for file system operations is not as robust as it would be in another stack. This lack of “robustness” was something I had to work around quite a lot.
Examples of various thread functions in my asset-inferrer process
I had to design Vault’s bulk import so that the heavy lifting (the asset-type inference engine that figures out what each file actually is) runs on a worker thread with zero scene tree access. It’s not as clean as it would be in a framework built for this kind of thing.
Con, the second: File Formats
Second: file format support. Godot handles the common game formats natively — PNG, JPG, OGG, WAV, GLTF, GLB, etc. But when you need something Godot doesn’t support, you end up hunting. GIF support? Nope. HTML rendering? Nuh-uh. I spent days evaluating and integrating GDExtensions for things that would be a simple npm install. Godot’s ecosystem is growing, but it’s not as deep as other architectures. For a solo developer, that hunting is time I didn't have to spend. However, on the opposite end, when you find the right extension, it works very, VERY well. It's just the trick of finding a component that works that's the hard part.
Security
This is the mind-killer. Godot’s default export format, the PCK file, is stupid easy to break apart. Tools like GDRE Suite can extract your whole-ass binary in seconds, no special skills required. The Slay the Spire 2 team recently dealt with this, having watched their whole game be completely decompiled and analyzed just a short time out from their release. And that was a game that constituted one of THE BIGGEST launches on Steam. Certainly the biggest Godot release yet. What was I going to do against that?!
I spent weeks down the rabbit hole of protection tools. The solution I landed on is a two-layer approach. Layer 1 is gdMaim, an export plugin that intercepts scripts during the export process and renames every user-defined identifier: function names, variable names, class names, signals, enums, you-name-it, to meaningless strings. Your code runs just the same but a decompiled binary doesn't give anyone much info.
Layer 2 in the process is Godot-Secure, which patches the Godot engine source itself. It changes the PCK file format header from the standard “GDPC” to custom headers. It also does things like modifying the key derivation and baking a security token into the engine binary. These adjustments make the PCK unreadable even if someone manages to extract the AES key from the binary. The two layers work together: gdMaim protects what the code does and Godot-Secure prevents access to the code.
This is all great, you say, so what’s the big deal? Well… NONE of this is beginner-friendly.
Here is just a short list of the things I had to figure out in order to get this working:
gdMaim requires you to compile custom export templates from source.
Godot-Secure requires you to patch the Godot engine itself and compile a custom engine binary.
The PCK encryption key has to be set in Project Settings, and the encryption include filters have to be configured per export preset.
And then there’s a gotcha I discovered the hard way: GDExtension native libraries cannot be loaded from inside an encrypted PCK. You gotta copy them ALONG with the exported binary. So every export has to include the three main addons: gdMaim GDBC library, the godot-sqlite binary, the godot-gif extension, into the right subdirectory structure next to the executable.
In a web stack or a compiled language like Rust, this is different (or at least I assume so, not being a Rust developer, myself). I chose Godot not knowing this would be a thing, but like most dev things at the start, I thought it would be something that wouldn’t be too hard to solve.
But I didn’t know how much time I’d spend on it. The hardest thing about it to deal with is the realization that all that work may still have been for nothing. Any committed pirate who REALLY wants to do it can break your app open, despite all the work I've done to secure it. No solution is foolproof and this solution is better than most but that is a hard realization to swallow. It’s been a bit of a gut punch, and I’m still honestly worried about the thought of my hard work going into some knockoff application.
Building
In something like Electron or Tauri, you write the code once and build for Windows, Mac, and Linux from one setup. In Godot, you build for each OS separately. And each one needs its own validation, whether that be code-signing or something else. I can’t just run one command and get three installers output for me.
For Vault, I have two export presets, one for Linux and one for Windows. The Linux preset uses a custom template compiled from source with Godot-Secure baked in. The Windows preset uses the same custom template, but the encryption-include filters are different. For example, Linux encrypts *.bbcode files, Windows doesn’t. And there’s no macOS preset at all, because notarization requires an Apple Developer account that I just can’t afford right now.(And, if I’m being 100% honest, I don’t think the Mac development side is quite populous enough for me as a solo developer to be worth the effort. I’m hoping that changes in the future!)
After export, I run a packaging script that creates the distribution directory structure. It copies the binary, the GDExtension native libraries — godot-sqlite, godot-gif, gdMaim’s GDBC — into the right subdirectory tree next to the executable, then zips the whole thing. The Linux script is automated. The Windows process is manual.
And there’s ANOTHER gotcha: the Godot editor rewrites export_presets.cfg every time you open the Export dialog, so any paths you set by editing the file directly get cleared. You have to set everything through the dialog UI.
It’s more work, but the end result is a robust application that does everything I hoped it would do for less than 100MB of space and SIPS RAM unless you need it to chug.
So Would I Do It Again?
Yeah. Yeah, I would. All the things I mentioned in the previous devlog turned out to be really key for me in this whole experience. The UI experience IS good. The game-dev alignment is real. The open-source philosophy matters to me in particular. The challenge was worth it. And the cons ARE solvable. They’re just more work than I expected. But, that’s the nature of game dev, right? Or just development in general? Solving problems constantly, especially the problems YOU create.
If you’re thinking about building an app in Godot, don’t expect it to be easier or better than some other systems out there. But do expect it to be more fun, if you’re willing to put in the work.
As always, keep your heads down and your elbows up. Keep pushing forward, no matter what.
- Plasmatix, Plasmatix Digital Media
arcanagds.com
Discussion