As for C#, an AOT compilation would also lead to similar protection as C++. Unfortunately, that doesn't seem to be working yet. Alternatively, there are tools (Obfuscator) that make code unreadable, making it more difficult to gain insights from it.

Of course, everything remains unencrypted in RAM (easy to get out) after unpacking. #C++ offers the best protection, as it can only be converted back into readable code with a great deal of effort when stripped. It might therefore be worthwhile to move certain parts of the game code to C++.

There is an export encryption feature, but it has long since been cracked. This is because the structure and position of the key are always the same in the export. This can only be achieved by modifying the engine and the export templates generated from it.

This can easily be done at any time in an existing project. When creating new projects, I would create all classes and data types in C# so that they are equally available in both spheres, i.e., GDScript and C#.

🙏

I simply follow my personal gaming habits, and these are increasingly shifting towards handheld devices. I actually like the Switch too, but it's a damn Ford Knox and you have to sell your soul to get in. Valve makes my life much easier, and the devices are good too.

Yes, and I quite like using that feature at home. However, it can be annoying on long train journeys, for example, if a game completely maxes out the handheld's processing power. And of course, there's also a bit of sporting ambition involved in optimizing my own game 😜

And yes, the way I currently calculate the polygons is certainly a very inefficient way. It's likely that much more performant methods can be found using vertices meshes and shaders. But I'm surprised that GDScript delivers such good performance. I hadn't expected that.

reaction and placing sprites in the line
#godot #gamedev #pixelart