Autor |
Nachricht |
< "Innenleben" von Save/Restore/Undo? |
|
Verfasst am:
Mo, 2 Sep 2002 - 23:19
|
|
|
Kompassleser
Anmeldungsdatum: 25.08.2002
Beiträge: 142
|
|
Save/Restore/Undo -- wie genau macht man das eigentlich?
Als ich mich noch mit Pascal oder Basic herumgeschlagen habe, hab ich einfach den Inhalt sämtlicher im Spiel vorkommender Variablen in eine Datei geschrieben bzw. diese daraus zurückgelesen.
Aber schon die Tatsache, daß Savegames (bei ein und demselben Spiel) je nach Fortschritt unterschiedlich groß sind, suggeriert mir, daß dies von "richtigen" Programmierern nicht ganz so ...naiv... angegangen wird. Einen bestimmten RAM-Bereich zu speichern würde doch auch immer gleich große Dateien erzeugen.
Hm... bin irgendwie ratlos. (Hier bitte einen illustrierenden Smilie hindenken)
|
|
|
|
|
|
Verfasst am:
Mi, 4 Sep 2002 - 22:18
|
|
|
Abenteurer
Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig
|
|
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. |
|
|
|
|
|
Verfasst am:
Do, 5 Sep 2002 - 11:03
|
|
|
Abenteurer
Anmeldungsdatum: 26.08.2002
Beiträge: 238
|
|
|
|
|
|
|
Verfasst am:
Do, 5 Sep 2002 - 12:52
|
|
|
Kompassleser
Anmeldungsdatum: 25.08.2002
Beiträge: 142
|
|
Einen Vergleich mit dem "Rohzustand" beim Speichern kann ich mir auch vorstellen. (Wäre jedenfalls einfacher, als jede Veränderung "live" zu protokollieren?) Aber was passiert dann beim Wiederherstellen? Dann müßte ja jeder Wert "wissen", wo er her- bzw. hinkommt, was wiederum so ...umständlich klingt.
Ja, ChrW, den Ärger kann man sich mit den üblichen Autorensystemen natürlich sparen. Mich macht Unwissenheit nur so leicht nervös :roll: |
|
|
|
|
|
Verfasst am:
Do, 5 Sep 2002 - 18:04
|
|
|
Abenteurer
Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig
|
|
Ally hat folgendes geschrieben: | Aber was passiert dann beim Wiederherstellen? Dann müßte ja jeder Wert "wissen", wo er her- bzw. hinkommt, was wiederum so ...umständlich klingt. |
Nö, es reicht, wenn Du weißt, wo er herkommt. :wink:
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? |
|
|
|
|
|
Verfasst am:
Do, 5 Sep 2002 - 18:11
|
|
|
Abenteurer
Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig
|
|
Zusätzlich sollte man vielleicht noch das Inventar des Spielers mit abspeichern... :roll: |
|
|
|
|
|
Verfasst am:
Do, 5 Sep 2002 - 18:52
|
|
|
Abenteurer
Anmeldungsdatum: 25.08.2002
Beiträge: 416
Wohnort: Essen
|
|
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. _________________
|
|
|
|
|
|
Verfasst am:
Do, 5 Sep 2002 - 21:41
|
|
|
Abenteurer
Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig
|
|
Au Mist, ich wußte doch, dass ich was übersehen habe! |
|
|
|
|
|
Verfasst am:
Sa, 14 Sep 2002 - 12:30
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
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. _________________ Every silver lining has a cloud. |
|
|
|
|
|