As we’re moving a lot of our tooling from GDScript to Assembly, we decided to release a lot of our tool libraries as open-source. Don’t worry, we’re not going anywhere; we’ll still be using Godot but coding more often in Assembly than GDScript. Even with our Assembly engine, we still make use of many of these tools. They’re simple, quick, easy to use, and we’re always updating them with new functions or better ways to do something.
Of particular note is our cipher library. It contains only a single tiny function that will obfuscate the contents of a string and restore it to normal when given an obfuscated string. It’s not super 2048-bit encryption, we acknowledge, but it’s really useful for hiding the contents of a save game file, making cheating far harder. It’s also useful for hiding the contents of any text file so they can’t be looked at in the exported Godot package. Granted, there is no way you’re going to stop someone intent on hacking your project, but for someone who just wants to hack the save game file to give themselves more gold, why shouldn’t we make it a little harder?
Hope these tools are helpful, and who knows we might learn some better way of doing something as well. They’re available on the ‘Open Source’ page of our website. There is also a complete puzzle game project and other releases available.
Nice tools. I did a number of the things you did in your Sound Manager when I first made my Sound Plugin. Specifically the polyphony and pitch shifts. However those can both be handled sans code now using the correct AudioStream or AudioStreamPlayer, and they’re a lot easier to manipulate in the editor.
Thanks, personally I prefer not to expose things or manage them in the editor, I know I’ll get yelled at and it seems counter intuitive, but if I want an extra sound file, or to play it without pitch shifting, I just drop a new sound in the audio directory and say true or false when calling play. Also I have no requirement to add a AudioStream or AudioStreamPlayer to the scene. I just make my sound play script global / singleton (whichever is the correct word) and it handles it all automatically. Also this method is scene independent so sounds keep playing when changing scenes..
As for things playing between scenes, that’s what my Music autoload does. It manages one for the pause screen and one for the game. But the more I make games in Godot, the more I realize that following the architecture of using nodes makes sense. They handle a lot of memory management stuff. But, based on where you are, I think you’ll just have to see for yourself. For me, it broke down when I made my first Metroidvania game.
That’s cool, we each have our own preferred way of doing things. Naturally as a long time assembly coder, I like procedural programming, not that fond of, though I understand it very well, of OOP. My very first job in IT was writing assembly language compilers. The love of that sort of coding has always stuck with me.
For me / us we like our Godot scenes as simple and as sparse as possible, most everything else is handled by the assembly engine. Only those strictly required nodes make it into a scene, with only a couple of functions to handle Assembly ↔ Godot events.
Our current project is a big game and all that is in the scene tree is two TextureRects and one Panel.
I use that sound manager and most of those tools as autoload’s as well, if needed at all..
Fair enough. You’re basically using Godot as a set of complex drivers. You’re definitely not the typical user. I’m interested to see what you come up with.
Yay!! Thanks for that! Someone finally got it! Yes we have our own in-house game engine we developed, called Droofus, oddly enough but it was hard to maintain video card drivers and compatibility with all the different hardware out there. We only use it for in-house experimentation now.
With Godot being open source we can tie directly into the game engine and let it handle all the video calls and driver issues, it also means we can support far more platforms than we ever could on our own.
Don’t get me wrong, writing and using your own game engine is lots of fun, but also a nightmare and a huge task to maintain and keep up to date with all the video card tech..
Yes It’s so simple it’s amazing, you give it a normal string and it returns an obfuscated one, and also the other way round, and you basically have to do nothing. Great for making config or game save files a lot more difficult to hack.
Cool go for it. I’m glad you find it useful. One little tip I’d give is don’t encrypt while developing only enable it for release, also it’s handy to have a starting tag in your file, if you use:
if dataFromFile.begins_with("your-tag") == true:
#not encrypted
else:
#encrypted
You can tell whether you need to de-encrypt or not
Very cool. Good tips. I was basically thinking of making it a boolean toggle in the Autoload. If it’s on, encrypt everything going to disk. But it makes sense to not encrypt if you’re in the editor or debug mode.
We just get a lot of people freaked out that their game is the next big thing and the haxxz0rs are going to be after them and want to encrypt everything. This might be enough for some people so that the average player can’t edit their saves.
Yes, I’ve seen those discussions a lot and I really don’t get it, if someone is really intent on hacking your game nothing is going to stop them. Encrypting the save game file though is an easy way to discourage your general player from being able to cheat.
