Update: I realized after posting that my first potential solution was wrong, so I have added the actual solution i want to try at the very end of the post.

I am writing posts at this speed mainly so I can have a record of my own thoughts and learning speed, and hopefully, these posts help someone, somewhere, at some time.

So in the last post, I talked about how I was having a hard time reconciling my data with Game Maker 2’s method for object handling. I have the data which represents a populated universe, so I have the structure, but the structure is large and deep so I have two options: hand-design everything, or let the system build it from the data. I remarked that GM2 has a way to create new “rooms” from code, but that just makes the rooms; populating them and getting them functional is not included.

I went out for a walk and during that time came up with two possible solutions that I think would work well, assuming that I understand GM2 well enough to be able to do this.

The first option was to play a shell game. After you start a new game we pick a major hub system to start you in. This room is generated from the Big Bang data — new room, instantiated star, planets, stations, and jump gates. Once you want to move to another system, you click on a jump gate, and this happens:

1. We record the ID of the system you want to jump to.
2. On the way out, we use the room end event to write the system state to the save game file, and then delete the room.
3. We send you to a “holding room” which basically plays an animation of you “jumping”. While there, we take the new system ID, look up the data, and build a NEW room with the star, planets, stations, and jump gates where we need them
4. We then transition you out of the holding room and into the new room.

This would work, I believe, but there are issues, specifically that writing rooms in code means that we don’t have access to the room’s events, I think. So we wouldn’t be able to fire off create or room start or room end.

Instead, I came up with this doozy of an idea: the tablecloth removal trick. We’d still set up a new game the same way as we do in the previous example, with one small change: the “room” that we put you into is pre-built but empty, so we only use the data to instantiate the star, planets, stations, jump gates, etc.

1. We record the ID of the system you want to jump to.
2. On the way out we use the room end event to save the state of that system to the save file. We also delete all contents.
3. You are sent to the “holding room” same as before. We use this time to rebuild your original room using the data of the destination system.
4. We then transition you out of the holding room and into the newly populated but original room.

On its face, this has loads of benefits, the largest being that the room is completely responsible for loading and saving itself. In the create script we look to the game manager for the ID of the system we need to build and then build it. On the way out, the room would save itself to the save game file. We can also test this room by instantiating objects in there and just running it before we build the create event script, so we would know that it works. This approach only requires (at least) three actual rooms in the game: the main menu, the game room, and the “holding” room (aka the “loading screen”).

I’m going to aim for the second method and test it out. Right now I have the game manager generating a new universe each time I run the game, so I can just pick a system and store the ID in the manager, then call the destination room’s create event before sending the user there. I’d need a holding room, and could then prototype some event scripts for loading and saving the room state.

Here’s the addendum. Rather than create and destroy a whole new room in code, what I would do is create a template room in the room editor. I could work with the event scripts that I want, and test objects in that room for functionality. When I want to use that room, I would use the room duplication function to copy that empty template (with scripts) and instantiate the objects from the data. On the way out, the state would be saved, and when the player is in the holding room, we would destroy that room instance and duplicate a new version of the template. If this works, I suspect it would be cleaner than if I tried to wipe out a single room every time because…what if that didn’t work? Now I have 2x the contents and I don’t have the time or patience to clean up after a violation of interstellar physics.