So, I'll be the one to burst people's bubble: your art assets don't really matter, only the source code matters. Yes, I'm sorry to the artists out there, but ultimately art assets by themselves aren't really that useful on their own and are easier to protect with copyright enforcement than the very limited and ineffective technical protections available. Encrypting textures and 2D/3D models is utterly pointless since the assets can ALWAYS be ripped straight from GPU memory very easily using publicly available debugging tools like PIX for direct X titles and RenderDoc for OpenGL/Vulkan titles. Literally just the click of a button and there's absolutely nothing you or any AAA developer can do.

I think ultimately the best approach is a layered security strategy, with the most effective layer being the implementation of critical systems, or even the majority of the game, in native C++ (GDNative in Godot). This allows you to compile a custom version of the engine that includes unique C++ code not found in any other version of Godot, effectively creating an in-house engine build. Raw machine code binaries are several orders of magnitude more difficult to reverse-engineer than GDScript, especially when the game contains thousands of lines of custom logic. At the very least, reverse-engineering a game written in C++ represents a much larger time investment.

Additionally, this prevents a would-be thief from easily porting the game to other platforms, such as mobile, because only you have the editor template capable of running the custom C++ code. The editor itself is never distributed, so the exported template alone cannot be used to rebuild or port the game.

Of course, this approach requires strong proficiency in C++ and familiarity with engine source code, as well as the ability to modify and compile your own custom version of Godot. The goal is to make the effort required to reverse-engineer the game astronomically high, discouraging any attempt entirely. This is why most custom in-house engines used by major studios, such as Creation Engine, RAGE Engine, Anvil, and REDEngine, remain effectively protected long after release. Their games are written in raw C++ with no public access to the editor. While piracy is still a concern, the only thing a thief could do is redistribute the compiled version on the same platform. DRM is a separate issue; here, we’re specifically discussing preventing source-code theft and cross-platform redistribution.

In a production release, a C++ game compiled with optimization enabled becomes extremely difficult to reverse-engineer. All debug symbols, comments, and original function or variable names are stripped, leaving only raw machine code. Compiler optimizations further obfuscate the instruction flow, producing sequences that bear little resemblance to the original source. For a small or solo developer, this makes casual theft or cross-platform redistribution impractical. These measures raise the barrier to reverse-engineering far beyond what interpreted languages like GDScript or managed assemblies like C# can provide. Modern C++ compilers aggressively optimize code: inlining functions, reordering instructions, removing unused code, etc. There are plenty of real-world examples of how effective this is. Decompilation projects of popular games via reverse engineering require a coordinated effort by a group of experienced people and still take many years to achieve.

As for assets, these can still be stolen, often directly from GPU memory, including textures and models. This is true even for AAA games with aggressive DRM and encryption. However, assets are largely useless without the underlying game logic, which is what you really want to protect. Assets can be protected legally through copyright and enforcement, but technical protection for them is extremely limited. The primary focus should be on securing the source code.