Das ist ja echt ärgerlich. Hab irgendwie noch nicht gerafft wie man Bilder an den eigenen Post anhängt. Hab ein Diagramm hochgeladen, aber das wurde danach prompt von der Forensoftware gelöscht.
Egal, dann eben in Textform:
Was ich mit dem Diagramm eigentlich zeigen wollte, ist welche Methoden in welcher Reihenfolge aufgerufen werden. Das ist in einem fertigen Spiel nicht immer so leicht herauszufinden und erschwert natürlich die Fehlersuche, wenn dir gar nicht klar ist, warum welche Methode wann aufgerufen wird.
Das ganze Spiel beginnt im "Main" Script mit der Zeile
rgss_main ist eine Funktion der RGSS die sagt: Führe den Codeblock einmal aus. Drückt der Spieler dabei die F12 Taste, wird der Codeblock von neuem ausgeführt (ergo, das Spiel neugestartet). Ist also erstmal nicht so wichtig. Wichtig ist: SceneManager.run wird ausgeführt.
Als nächstes guckst du also was SceneManager.run macht.
Okay, SceneManager.run ruft zuerst DataManager.init auf. Die Definition dazu findest du im Script "DataManager". Kurz zusammengefasst: DataManager.init liest die Datenbank des Makers ein (die Datenbank sind alle Einstellungsmöglichkeiten die du im Maker hast, wenn du F9 drückst, z.B. Helden, Monster, Items etc.). Danach werden alle Game-Objekte angelegt. Kleiner Exkurs: Alle Game-Objekte haben einen Klassennamen der mit Game_ anfängt. Sie enthalten den aktuellen Zustand des Spiels. Du kannst dir leicht merken: Alles was in einen Spielstand abgespeichert werden muss (was beim Neuladen also wieder verfügbar sein muss) ist Teil eines Game-Objektes. Denn nur Game-Objekte werden gespeichert. Dem gegenüber gibt es Daten-Objekte. Daten-Objekte fangen alle mit RPG:: an, z.B. RPG::Actor. Sie enthalten die statischen, unveränderlichen Inhalte, die du im Maker definiert hast. Sie müssen nicht im Spielstand abgespeichert werden, weil sie konstant für alle Spielstände sind. Kleines Beispiel: RPG::Actor enthält für jedes Level die zugehörigen Lebenspunkte. Game_Actor enthält die tatsächlichen Lebenspunkte des Helden, mit Inbegriffen also auch Lebenspunkte die man durch Trinken eines Zaubertranks o.ä. erhält. RPG::Actor enthält den Namen des Helden in der Datenbank. Game_Actor enthält den tatsächlichen Namen des Heldens (der sich im Spiel z.B. durch Umbenennung ändern kann). Darum macht es Sinn für dein Minispiel eine Klasse Game_Memory anzulegen, die die veränderlichen Zustände deines Memory-Spiels enthält (welche Karten liegen auf dem Tisch, welche Karten wurden gezogen, wie viele Punkte hat der Spieler usw.).
Zurück zum Spielfluss: Nach dem Aufruf von DataManager.init wird mit
die erste Scene angelegt und in die Variable @scene gespeichert. first_scene_class ist eine Methode, die die Klasse zurückgibt mit deren Scene das Spiel beginnen soll (z.B. Scene_Title). @scene ist eine Variable, welche die aktuelle Scene des Spiels beinhaltet.
Danach kommt
Achtung: Das ist eine Schleife. Die Methode @scene.main wird jetzt solange ausgeführt solange die Variable @scene nicht nil ist. An diesem Punkt befinden wir uns in der Hauptschleife des Spiels. Jetzt wird immer @scene.main aufgerufen, bis das Spiel beendet wird. Das Beenden des Spiels geschieht durch den Aufruf von SceneManager.exit. Wenn du in die Methodendefinition guckst, siehst du, dass diese Methode einfach die Variable @scene auf nil setzt (und damit die Schleifenbedingung verletzt, wodurch die Schleife abbricht).
Jede Scene-Klasse im Spiel erbt von Scene_Base. Wenn du wissen willst was @scene.main macht schaust du also am besten erstmal dort hinein:
Zuerst wird Scene_Base#start aufgerufen. Danach Scene_Base#post_start. Dann kommt wieder eine Schleife: Solange die Hauptscene nicht geändert wird (du also nicht SceneManager.call oder SceneManager.exit aufrufst) wird die Methode Scene_Base#update aufgerufen. Wird die Scene beendet, so werden pre_terminate und terminate_aufgerufen.
Was hat es mit dem start und post_start bzw. pre_terminate und terminate auf sich? Hier geht es darum einen Übergang zwischen zwei Scenen zu erzeugen. Wenn du z.B. von der Map ins Menü wechselst, so geht das nicht abrupt, sondern die Map wird langsam ausgeblendet und das Menü wird langsam eingeblendet. start zeichnet den neuen Bildschirm der neuen Scene. post_start erzeugt den Übergang. Wenn du post_start überschreibst und eigenen Code einfügst, so wird dieser erst ausgeführt, nachdem die Scene eingeblendet wurde. Alles was in start steht wird ausgeführt, bevor die Scene eingeblendet wird. Dasselbe gilt für pre_terminate und terminate. In terminate wird der Bildschirm eingrefroren, so dass die nächste Scene gezeichnet werden kann. Alles was in pre_terminate reinkommt, wird noch sichtbar für den Spieler bevor die Scene ausgeblendet wird.
In der Regel brauchst du post_start und pre_terminate nicht.
Zuletzt noch update: update ruft erstmal nur update_basic auf. update_basic zeichnet den Bildschirm neu und fragt Tastatureingaben ab. update_basic brauchst du nicht überschreiben. In der Regel überschreibst du update und rufst als allererstes super auf um Scene_Base#update aufrufen (die dann update_basic aufruft).
Nochmal zusammengefasst:
1. Spiel startet mit SceneManager.run
2. Dieser ruft in einer Schleife immer wieder @scene.main auf
3. Diese führt start aus um sich zu initialisieren
4. und danach update in einer Schleife (solange die Scene existiert) auf
5. wird die Scene beendet ruft sie vorher noch terminate auf
Schreibst du eine eigene Scene so überschreibst du 3 Methoden: start, update und terminate. Alle drei überschriebenen Methoden sollten als allerersten Aufruf ein super enthalten, um die gleichnamige Methode der Superklasse aufzurufen. Eine Scene sollte den Ablauf eines Scriptes koordinieren. Sie regelt im Grunde genommen drei Elemente: Das Zeichnen aller Grafiken, Abspielen von Soundeffekten/Musik und das Abfragen von Tastatureingaben. Wird der grafische Teil sehr komplex, lagert man ihn in der Regel nochmal in eine eigene Klasse aus.
Die Spieldaten und Spielmechanik schreibt man in eine eigene Klasse. In der Regel nennt man sie Game_XYZ, z.B. Game_Memory. Hier kommt alles rein was einen Zustand deines Scriptes darstellt, der in einem Spielstand abgespeichert werden muss. In einem Memory-Spiel wären das: die Karten auf dem Spielbrett, die Karten auf der Hand des Spielers. Eine Instanz dieser Klasse packt man dann in eine bestehende Game_XYZ Klasse, z.B. Game_System. Danach kann man darauf z.B. mit $game_system.memory zugreifen.
Ich weiß nicht wie dein Code gegenwärtig aussieht. Aber ich vermute mal das dein Problem noch darin liegt zu erkennen, welcher Code in Game_Memory und welcher in Scene_Memory gehört (du nennst letztere Memory, aber es ist besser eine Scene Klasse mit dem Prefix Scene_ anfangen zu lassen).