Ich nehme stark an dass die Informationen über persistente Räume im Ram gespeichert werden. (Dafür andere Speichermedien wie die Festplatte zu verwenden würde rein aus performancesicht keinen Sinn ergeben.)
Bei solchen Situationen wirst du (wenn du es wirklich richtig machen möchtest) auf ein eigenes System setzen müssen. Sprich: Du hast nur einen Raum in dem das Spiel läuft.
Das ganze Memory management (erstellen zerstören von tiles/Instanzen, etc...) wirst du selber handhaben müssen. Es ist zwar ein größerer Aufwand rein vom Programmieren her gesehen, aber es erlaubt dir genau solche limitationen zu umgehen. Das letzte was du haben möchtest ist irgendein Memory-leak der auf die Funktionsweise des GMs zurückzuführen ist.

Müssen tut es das natürlich nicht. Du musst aber bedenken dass einige Designentscheidungen die beim entwickeln des GMs vorgenommen wurden (ich rede hier von alten GM versionen deren Design auch in Studio übernommen wurde wie eben Drag&Drop, das Step-event und das Room konzept) nie wirklich mit komplexen Projekten so harmonieren wie mit einfachen.

Was ich damit sagen möchte ist, dass wenn du in komplexere Gewässer durchstößt es auf jedenfall besser ist wenn du enige der Aufgaben die der GM normalerweise übernimmt, selbst in die Hand nimmst. Beim Room konzept beispielsweise kann man nie wissen wie der GM die Ressourcen handhabt wenn man den raum wechselt. (Alles verschteckt sich hinter den API aufrufen und da wir den Source-code nicht ansehen können, wissen wir nicht wie sich das auf technischer ebene verhällt.)

Bei einfachen Spielen mag das noch kein Problem sein, aber sobald du riesige Welten umsetzt welche in Rooms aufgeteilt wurden und dahinter noch ein Quest-system läuft (+ wenn du auf den Speicher/Ressourcenverbrauch achten musst), ist das eine ziemlich gefährliche angelegenheit im dunkeln zu tappen. Es genügt nur eine einziges nicht beachtetes Verhaltensmuster des GMs oder ein Update was die implementierung einer Funktion im Background ändert und du kannst unter Umständen probleme mit deinem Code bekommen wenn dieser sich zu sehr auf die API aufrufe des GMs verlässt. Das einzige was du dann machen müsstest ist eigene GM-spezifische Workarounds für solche Probleme zu programmieren welche meistens Katastrophal ausfallen (aus Code-management sich gesehen.)

Ich habe beispielsweise einmal nach einem Update Bugs im kollisionssystem bekommen, da sich mein Code auf die instance_activate und deactivate funktionen verlies welche am anfang jedes steps aufgerufen wurden. Ein Update hat die implementierung dieser geändert (die funktionen waren teilweise um 1 step verzögert und es gab "zwischenstufen" bei denen alle instanzen komplett deaktiviert waren, obwohl ich nach instance_deactivate sofort instance_activate aufgerufen habe) was dann zu unerwarteten Ergebnissen bei der Kollisionserkennung geführt hat. (Als ich zum debuggen die Kollisionsobjekte gezeichnet habe, konnte man das regelrecht als hochfrequentes flackern wahrnehmen...)
Ich habe das dann zwar behoben (auf eine ziemlich konfuse art und weise welche immernoch vom GM abhängig ist) aber das hat mich wiedermal daran erinnert wieso ich meistens versuche meine Codes GM-unabhängig zu machen.

Aber ja, könnte sein dass dies für dich weniger relevant sein wird. Ich bin mittlerweile daran gewöhnt Projekte mit einer größeren Codebasis zu haben bzw. an solchen zu arbeiten, wodurch ich schon im vornerein darauf achte den Code halbwegs clean und engine-unabhängig zu halten.

Wofür dann der Roomeditor wenn ich alle Instanzen/Tiles hinprogrammieren soll.

Für Prototyping zwecke ist er an sich gut geeignet, aber er ist garantiert nicht die Stärke des GMs.
Ich weiss nicht ob sich in den letzten monaten da was getan hat (ich nehme mal an nicht) aber sachen wie depth-ordering von Tiles oder die auswahl von mehreren Instanzen funktionierte einfach nicht. Selbst das simple Rotieren von Instanzen ist nicht intuitiv umgesetzt. (Es funktioniert, aber ziemlich umständlich.)

Ich mein, wenn man einen Room erstellt, mit den Tiles ein Haus oder sonstwas plaziert und man dieses dann verschieben wollen würde (da sich z.B: das Mapdesign geändert hat) kann man diese Tiles nicht einfach alle auf einmal "auswählen" und gleichzeitig verschieben. Man kann die nur einzeln löschen und an einer anderen stelle manuell wieder plazieren. (Zumindest fand ich damals keine Möglichkeit dies zu tun...) War schon ziemlich... anstrengend...


Ich habe 1-2 mal versucht den Room editor bei einem Projekt zu verwenden. Nach den erfahrungen die ich mit diesem (von der Benutzung her) gemacht habe + die ganze Sache mit den "Behind the Scenes" Zeug des GMs in das wir keine Einsicht haben, habe ich seither auf diesen verzichtet. (Ausserdem kann ich den für 3D Projekte auch nicht sinnvoll verwenden. )

Aber ja, jedem das seine. Wenn du mit dem Editor zurechtkommst, ist das ja auch in Ordnung. Ich teile nur meine Erfahrungen und eventuelle Tipps mit.