Ich werde dir heute zumidest noch diese Frage beantworten können. (um den Generator kümmer ich mich evtl morgen.^^)

@ Topic:
Das ist eben die Problematic des "Simulierens" eines unendlich großen Raumes. Wie genau hast du die Grids erstellt? Mit den GM internen Grid funktionen oder ist das ein selbstgescriptetes Grid?
Mir viele da im moment nur die Möglichkeit ein alle Blöcke in Realtime immwerwieder neu nach dem Raster auszurichten. Ist aber überhaupt nicht Performanceschonend. (und langsam noch dazu.)
Eigentlich könntest du das Wirklich so mit dem ausrichten der Objekte in Echtzeit machen, aber wenn dein Vorhaben "größer" ist, und dir die Performance sehr wichtig ist, dann kommst du damit schnell an die grenzen.
(Falls ich das mit dem Verschieben der Map gesagt habe, tut es mir leid. Ich beschäftige mich eben laufend mit solchen Themen und habe jeden dritten Tag wieder eine neue Idee wie man sowas Umsetzen könnte. XD )



Wenn du das tatsächlich einen "unendlich großen Raum" simulieren möchtest, musst du diie herangehensweise überdenken.
Man könnte z.B: versuchen die Minecraft Map-Speicherungsengine nachzubauen. (hab mir das selber schonmal überlegt.) Sprich: die Map in "Chunks" teilen.

Wir nehmen z.B: einen 512 x 512 pixel großen Raum (nur als Beispiel XD) dies entspricht 32* 32 Blöcken (1 Block ist 16*16 Pixel groß)
Dieser Raum ist 1 Chunk.
Nun generieren wir die Map im Raum selber. Der Spieler bewegt sich nun im Raum, und die Kamera folgt ihm. Ist im moment nichts besonderes.
Jetzt kommt der Trick: man generiert außerhalb des Rooms, links und Rechts jeweils 1 weiteres Chunk.
Nun machen wir es so dass wenn der Player z.B: den Raum links verlässt um in den Linken chunk zu wandern, wird der Inhalt im mittleren Chunk gelöscht wird und der Inhalt des Linken chunks dafür reingeladen wird.
Den Spieler selber müssen wir dabei nun in den Raum ganz Rechts in die selben höhe positionieren.

verstehst du was ich meine? Die Inhalte der Chunks werden sozusagen wie bei einem Filmstreifen jeweils nach links und Rechts verschoben. Je nachdem wohin der Player wandert.
Dabei muss man den Player natürlich im Raum auf der gegenüberen Seite positionieren, damit ihm auch vorgegaukelt wird dass er in den neuen Chunk "reingewandert ist." (sonst würde er sich am ende des neuen Chunk befinden.)

Dies kann man dann versuchen so zu optimieren, dass der Gamer garnichts von den Sprüngen im Raum mitkriegt.

Dieses System hätte den Vorteil dass das System nur beim rüberwandern in den anderen Chunk die teilmap neu ladet und die Blöcke sozusagen "verschiebt." (du willst es ja in echtzeit machen").


Ich hoffe ich bin hier nicht vom Thema abgeschweift und konnte dir einige anregungen zum Thema "infinite Maps" geben.
Außerdem hoffe ich noch dass mein "Text" hier nicht zu kompliziert war. Hab manchmal meine Probleme beim Ausdrücken von "Theorie"...
(PS: Ich weiss auch dass ich mich in letzter Zeit mit dem Thema "Minecraft" sehr viel beschäftige. Ich entschuldige mich falls mein geplappere einige hier stört.)

Puh... das ist eben schon eine etwas komplexere Aufgabe.
Evtl könntest du versuchen das mit dem unendlichen Raum fürs erste zu lassen und dich auf ein wesentliches Mapsystem zu fokusieren dass vielleicht nicht unendliche Maps simulieren kann, dafür aber ohne bugs und ohne Framerate Drops funktioniert.
Wenn du das schaffst hasst du die nötigen Grundkenntnisse um auch das thema "infinite Maps" zu bewältigen.

Ich habe auch mal klein anfgefangen und hätte mir solche sachen wie in solchen komplexeren themen mitzureden, nie zugetraut. (Ich habe noch nie in meinem Leben jemals ein Spiel fertiggestellt.)
Und trotzdem waren die etlichen Projekte die gescheitert sind nicht umsonst. Aus jedem Fehler habe ich gelernt.

Lass dich also nicht entmutigen. Ich würde dir empfehlen bei einem Projekt nicht gleich eine commerciell reife Engine zu basteln. (Hat bei mir nie funktioniert. Dadurch sind Projekte nur gescheitert.) Dass ist auch der größte Fehler von Leuten die noch nicht die nötige erfahrung haben. Mach es stattdessen Scheibchenweise. (Beispiel: Als erstes Jump& Run Engine die auch funktioniert. Dannach versuch die zerstörbaren Blöcke zu implementieren. Dann erst ein Map speicherungs system. Wenn das alles pipifein funktioniert, taste dich an die Infinite Maps heran.)

Und das sage ich dir nicht als eine Person die hier Leute niedermachen möchte. Im gegenteil. Ich weiss wie es ist wenn man irgendetwas großes umsetzen möchte und nicht genau weiss wie man das machen soll. Darum versuche ich dir jetzt auf deinen Weg einige tipps/Erfahrungen von mir mitzugeben damit du evtl. schneller zum "Pro-Programmierer" wirst.

(PS: Falls ich in Zukunft ne Infinite Maps engine hinbekomme, könnte ich sie dir ja zukommen lassen.)

mfg

LEWA

Vielleicht versteh ich nicht genug vom GameMaker, aber wofür soll man die Blöcke anstatt dem Player verschieben?
Eigentlich müsste der Raum ja sowieso "unendlich" groß sein, oder? Das was man als Raumgröße im Roomeditor angibt ist ja nur die max. Größe die man angezeigt bekommt, trotzdem sollte beliebig viel an Raum "da sein".
Bei x = 0 und y= 0 ist ja nicht Schluss, man kann doch auch seine Objekte im negativen Bereich platzieren, die Kamera folgt dem Spieler ja trotzdem...
Wenn man alle Objekte deaktiviert die ausserhalb des Views liegen dürfte das doch gar keine Probleme bereiten oder?
Die Blöcke statt dem Player zu verschieben erscheint mir unnötig aufwändig.

Einziges Problem was ich mir vorstellen kann:
Ein Überlauf des Wertebereichs wenn man zu weit ins Negative/Positive kommt.
D.h. entweder stürzt dann das Spiel ab (was ich nicht glaube) oder dein Player kommt auf der anderen Seite wieder rein.

Und genau das umgehe ich mit meinem Vorschlag. Mir war schon vorher bewusst dass der GM bei höheren Wertebereichen nicht mehr arbeiten kann.

Ich habe ja gesagt dass die Map in Chunks unterteilt wird. Und genau DAS ist der springende Punkt. Der GM muss dann nicht mit so hohen Koordinaten arbeiten.
Beispiel: Der Player befindet sich in einem Chunk. In diesem Chunk gibt es nun die "normalen" Koordinaten. (z.B: von 0 bis 255 in x und y richtung) wenn er nun in den Nächsten Chunk geht (z.B: bei der Koordinate x <= 0 ) ladet die Map nun den nächstgelegenen linken Chunk in den Chunkbereich, wo sich der Spieler befindet und löscht den alten. Dabei setzt man nun den Player auf die Koordinaten x = 254. (Um dem Spieler das weitergehen in der neuen Map vorzugaukeln.)

Um sich nun zu Orientieren wo der Spieler gerade ist, kann man nun einen "Chunk-Index" erstellen. 0 ist dabei der erte Chunk wo das Spiel beginnt. (Also wo der erste chunk generiert wird.) geht der Player nach links, ändert sich der Index auf -1. Wenn Rechts, dann +1.

Dadurch kann man viel größere Räume erzielen. Dies kann man noch optimieren um z.B:
es "World-Areas" gibt, in denen z.B: 16 Chunks drinnen sind. Dadurch gibt es wiederum keine Begrenzung der Variable für den Chunk index, da die "World Areas" immer 16 Chunks besitzen die mit dem Index 0-15 Addressiert sind.

Der Nachteil daran ist aber der, dass (wenn man dies weiter unterteilt und immer mehr verschachtelt) das identifizieren der Chunks immer aufwendiger wird, da der Chunk-Index allein nicht mehr ausreicht. Man muss nun die World-Area + den Chunk index benutzen um herauszufinden auf welchem Tei lder Map sich der Spieler befindet.

Versteht ihr alle worauf ich hinaus will?
Natürlich gibt es auch da eine begrenzung (der PC Hat keinen unendlich großen Speicher.) Jedoch erlaubt sie eine viel größere Welt (die durch vermehrtes Verschachteln extremst große Welten ermöglicht) wie wenn man nur mit Koordinaten arbeiten würde.

Ich entschuldige mich im Voraus falls ich mich "unverständlich" ausdrücke.

Du verstehst es richtig.

Kurz zur theorie:
mittig links und Rechts sind Chunks. Insgesamt wären es also 3.
Wenn du links rausgehst, werden sozusagen alle 3 Chunks nach rechts verschoben. (3 chunks nur deswegen, damit der Player am Rand des mittleren Chunks keine leere Fläche sieht.)
Wenn du alle 3 chunks nach rechts verschiebst, musst du das ganz rechte löschen. (da das nun überflüssig ist). Nun ist aber eine Lücke entstanden, da links kein Chum´nk mehr da ist. (wurde ja nach rechts verschoben.)
Also generierst du nun einen neuen chunk.
Dies passiert natürlich nur wenn der Spieler nach links oder nach rechts aus dem linken Chunk "rauswandert".

Soweit alles Klar?

Da der Spieler aber durch den Chunk links in den - bereich rauswandert (ist nicht das eigentliche Problem) und dann das linke chunk in die Mitte geladen wird, befindet sich der Player nun am linkem Ende des Chunks, obwohl er (logischerweise) rechts ankommen sollte. (Die chunks sind ja verknüpft. Wenn di links rauswanderst, und der Chunk verschoben wird, befindest du dich Plötzlich völlig woanders. Nähmlich am Ende des neu geladenen Chunks, obwohl du am Anfang sein solltest.)

Um das zu umgehen Prüfst du ob der den Chunk verlassen hast.
Also:

oder

Je nach der Richtung in der Man rauswandert.

Dabei setzt man den Spieler (wenn er links rausgeht) and das rechte ende des mittleren Chunks, und wenn man rechts rausgeht, an das linke Ende des mittleren Chunks.
Damit "Verschiebt" man den Spieler mit den Chunks, und er wird nicht aus dem Wertebereich des chunks rauswandern.

Verstehst du?

Da hast du recht. Das wären dann punkte die man so gut wie nur möglich Optimieren müsste.

Infinite Maps sind eben nicht leicht zu realisieren. Man könnte ja versuchen die View "mit" dem Player springen zu lassen und nicht erst während des Steps. (Also player + View gleichzeitig verschieben.) Dadurch könnte man diese "hänger" grundsätzlich eliminieren. Da hilft nur noch herumexperimentieren und selbst ausprobieren.

Dann hmmm. könnte man auch machen, aber dann gäbe es keine fest definierten linken, mittleren und Rechten Chunk.
Das wiederum würde (wie du bereits gesagt hast) bedeuten dass man beim Tastendruck alle Chunk immerwieder verschieben muss anstatt nur beim Chunkwechsel. (und unter "verschieben" wird das löschen und neuzeichnen der Chunks an einer anderen Position gemeint.)

Letztendlich ist das aber ebenso eine Möglichkeit und könnte auch funktionieren. Es kommt alles auf das zusammenspiel zwischen den einzelnen Komponenten deiner engine an.