Do you know how to access the ROM directly? I doubt it. That means you have
three four five viable methods at your disposal when using Game Maker:
- Create everything in the IDE and then disable all layers not required initially (or disable all layers entirely and then activate as needed). Con: Eats up a ton of RAM
- Store all tile mapping in arrays; leave rooms blank. In a Room Start event, loop through an array and add the tiles in. Con: Eats up RAM, requires writing the arrays, slow
- Store all tile mapping in binary files; leave rooms blank. In a Room Start event, load a file into a buffer, loop through the buffer and add the tiles in. Con: Even slower, but less RAM
- Make a script return an array of the desired tile mapping; leave rooms blank. In a Room Start event, call the script then loop through the passed array. Con: Slow as 2, but less RAM
- Or, you know, just make duplicate rooms and go to the burnt-out room when the game-changing event has occurred. Con: Eats as much RAM as 1, but fastest option
I'm used to GM8 and GMS1 more than GMS2, so point 4 never occurred to me until now. That may actually be the best option if you want to generate the tiles every time you visit the room. The thing to keep in mind here is the difference between conserving memory and conserving time. The more RAM something requires, such as putting all variants of the room into one or more rooms using the IDE, the faster it's going to be to make those changes. Multiple rooms is far and away the fastest option, since deactivated instances and layers still get processed to a degree, so multiple rooms cuts out that facet of multi-layering event outcomes. Using binary files is the slowest method due to having to first read the file into RAM, copying the RAM into the buffer, then reading the buffer (which is on par with reading an array if done properly). Point 4 is the ideal array method if you are using GMS2, since the array data will only be temporary and thus not linger in the RAM. Since points 1 and 4 are viable only in GMS2, it seems clear to me that they're the best alternatives shy of point 5.
In any case, all 5 points share one thing in common -- they all require an unneeded pile of codes and hidden stuff that never gets touched again. Whether it's data stored in the PROM itself, inside external files, in an array, or just pre-existing rooms, it's all hidden and unused data that only gets touched when it needs to get touched.