I see this kind of poor add-on “hygiene” alot, but I thought Godot flagged when this happened in the install dialog and you can uncheck anything that’s outside of the addon folder. I’m pretty sure that now the damage is done you can just delete any non-code or non-resource files it added. Maybe do a commit before doing so, but it should be OK. If the addon has a license file (which is recommened in the Godot docs), it should only ever be in the addon folder itself and only pertains to the addon.

I have an add-on that will help with game state like locked doors and stuff. You an find it in the Godot asset library as Game State Saver Plugin. If installed directly from the Godot editor, you’ll get a watered down demo with the add-on. But a more extensive example can be obtained by downloading the entire repository. That full demo has a locked door, switches that affect things in other level scenes and remember their state, and more.

As for a more flexible, extensible system for inventory I would look into custom resources. You can add things to the custom resource like an inventory texture, display name, and other info about an inventory item. Then you can use an exported property array and add the items as needed. You can even save the individual resources as resource files for easy reuse and updating later.

Now how to connect a custom resource to the save system is something I have not gotten around to doing, so I can’t say exactly how that would work right now.

Hope this helps!

Very interesting. I was thinking about doing this, but went the Defold route instead. Defold is much smaller out of the box than even these results, but the sacrifices in functionality are pretty severe and the editor and engine are, shall I say, cantankerous. I may have to circle back to trying this at some point for my web games. Thanks for the post!

I checked it out but haven’t completed the goal yet. It’s pretty good. The simple tutorial in the beginning is enough to get started and after a few restarts, I figured out what to watch out for. It does a good job building tension having to check and sometimes recheck things as you go.

I think the camera needs some smoothing or something. It’s not too bad, but doesn’t seem smooth to me.

The biggest issue is the download size. 1 GB and so far I’ve seen the same hall with mostly identical robots. (I got to level 7, btw. So, maybe that’s the reason.) I see a lot more in the project files, so maybe this game is meant to be much larger. But even so, why is it so big? The pck file once the download is unzipped is 2 GB!

I’ve thought about this problem creating a system to save game state. The issue with assigning a UUID works until you have dynamic scenes added to the game at runtime. The nodes in those scenes will all have the same UUID. In the end I ended up just using the paths and saving the fact that the scene that data is being saved for is dynamic. Then the system sees this and re-instances the scene and adds it back to the tree. (A slight adjustment to the path must be made as Godot will create nodes with the at (@) symbol in them, but you can’t do that yourself.)

You can see this in action at my demo repo on github.

GDQuest has some demos that may be applicable here. I’ve found four looking through the list at https://www.gdquest.com/tools/: Godot 2D Builder (simulation demo), Godot 2D Rhythm Game, 2D Space Game (top-down space mining demo), Godot 2D Platformer, and Godot Open RPG. Looking through their github some of these appear to only be Godot 3 though.

You don’t have Autoplay checked for the AudioStreamPlayer[2D|3D] node, do you? (Sorry for the obvious question, but we out here on the net never know.)

So, it seems spawn_objects needs a reference to hexgrid? Then you can export a property in the spawn_objects script that takes a reference to hexgrid. And then from the map scene, you set that reference as it has both as children. In Godot 4 you can use “@export var hexgrid: HexGrid” (this assumes you give the hexgrid node script a class_name of HexGrid.) In Godot 3 I think there’s a bit more to it as the export is “export var hexgrid:NodePath” (note no @ symbol in Godot 3) and then later you have to use the NodePath to get the node like this “onready var _hexgrid:HexGrid = get_node(hexgrid)” (note the onready here means the get_node call will happen just before the call to func _ready()) You could do the get_node call in func _ready(), but I like the onready better because it makes any code in the ready function that much simpler.

That’s just how I would do it given what I think I know. Now that you have these ideas, you can play with them and decide what you like best. Hope it helps!

Signals are the same as events. It’s just a different name. So, use signals to let other nodes/code know when something has happened (or is about to). It would only make sense to use a signal here if the values were changing and you wanted to let other nodes know about it. Like index_transform_changed(new_value).

I’m not sure what the tiles are for, but they’re probably part of a collection or board of some kind. I would make this board it’s own scene and have the board manage things. It could also make available transforms and indexes to other nodes, but that seems like something that would be best encapsulated within the board node itself. Then have the board get references to the children is controls via get_node, or using the $ syntax, etc.