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.