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.

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.