indigo

Mmh, muss man sich da bei den gängigen Systemen wie Inform oder TAM drum kümmern? Ich dachte, dass macht der Interpreter (oder es ist Bestandteil der Library oder wie auch immer...).

Die unterschiedliche Größe der Savegames wird daher kommen, dass Variablen zu Bereichen, die der Spieler noch nicht betreten hat, auch nicht gespeichert werden müssen.

http://www.textadventures.de/

indigo

Ally:

indigo

Nö, es reicht, wenn Du weißt, wo er herkommt.

Mal angenommen, Du hättest eine Routine zum Speichern, die die Variablen nach Räumen sortiert speichert. Die Routine überprüft, ob der Spieler im betreffenden Raum schon gewesen ist und speichert ihn gegebenenfalls ab.

Beim Wiederherstellen versetzt man das Spiel in den Urzustand und lädt alle Räume nach, die der Spieler schon besucht hatte.

Das alles schreibe ich, ohne eine Ahnung zu haben, wie die gängigen Speicherfunktionen in TAM oder Inform eigentlich arbeiten.

Aus rein fachlichem Interesse: Martin, wie macht TAM das?

Zusätzlich sollte man vielleicht noch das Inventar des Spielers mit abspeichern... :roll:

Das klappt meiner Meinung nach nicht oder nur schlecht, da sich ja auch in Räumen, die man noch nie betreten hat, schon etwas ändern kann: Schalte im Flur die Sicherung aus, und der Kühlschrank gibt den Geist auf - selbst, wenn die Küche noch nicht betretbar (abgeschlossen) ist.

Außerdem funktionieren viele Variablen in meinen Adventures raumunabhängig.

Au Mist, ich wußte doch, dass ich was übersehen habe!

Die T.A.M. speichert wie Ally in seinen früheren Programmen die Daten zu jedem Raum und Objekt und die globalen Variablen ab. Deshalb dürften abgespeicherte Spielstände für ein Spiel immer dieselbe Größe haben. Eigentlich werden diese Daten in einem bestimmten Format in den Speicher geschrieben, um sie für Undo zur Verfügung zu haben. Beim Speichern wird dann dieser Speicherbereich einfach auf eine Datei geschrieben.

Aus dem Bemühen, diese Dateien klein zu halten, sind einige eigenartige Konzepte entstanden: Die Aufteilung der Raumverbindungen in (unveränderliche) Räume, Antworten und Wege, zum Beispiel: Da die Raumverbindungen nicht abgespeichert werden, kann man variable Verbindungen nur mit Ausführungsblöcken realisieren. Zuweisungen, wie "sei Tempel.W Geheimgang" funktionieren nicht. Ein weiteres Speicherplatzsparkonzept ist die Trennung von Objekten und Dekos: Obwohl beide eigentlich gleich sind, werden nur Objekte abgespeichert. Das ist leider eine Stolperfalle, siehe http://www.martin-oehm.de/tag/fragen.html#vardeko

Die z-Maschine macht es ähnlich: Der gesamte dynamische Speicher wird auf die Datei geschrieben. Das Format ist dem Interpreter überlassen, so dass ein gespeicherter Spielstand nicht unbedingt zwischen Interpretern kompatibel sein muss.

Die meisten Interpreter benutzen aber ein Format namens Quetzal (Kein Vogel, keine Währung, sondern das selbstbezügliche Akronym Quetzal Unifies Efficiently The Z-Machine Archive Language, http://www.gnelson.demon.co.uk/zspec/quetzal.html)..) Dieses Format macht das, was Walafrid schon vermutet hat: Es speichert nur Veränderungen zum Urzustand ab, der ja sowieso für den Neustart irgendwo im Speicher abgelegt ist. Das macht die Dateien relativ klein, da nur wenige Daten im dynamischen Speicher (der bis zu 64k groß sein kann) tatsächlich verändert werden und es macht die Spielstände von Interpretern unabhängig.