if-de :: Forum Foren-Übersicht
Autor Nachricht
<  "Innenleben" von Save/Restore/Undo?
Ally
BeitragVerfasst am: Mo, 2 Sep 2002 - 23:19  Antworten mit Zitat
Kompassleser
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)
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ChrisW
BeitragVerfasst am: Mi, 4 Sep 2002 - 22:18  Antworten mit Zitat
Abenteurer
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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Walafrid
BeitragVerfasst am: Do, 5 Sep 2002 - 11:03  Antworten mit Zitat
Abenteurer
Abenteurer


Anmeldungsdatum: 26.08.2002
Beiträge: 238

http://www.textadventures.de/

Zuletzt bearbeitet von Walafrid am Mo, 24 Feb 2003 - 17:34, insgesamt einmal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Ally
BeitragVerfasst am: Do, 5 Sep 2002 - 12:52  Antworten mit Zitat
Kompassleser
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:
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ChrisW
BeitragVerfasst am: Do, 5 Sep 2002 - 18:04  Antworten mit Zitat
Abenteurer
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?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
ChrisW
BeitragVerfasst am: Do, 5 Sep 2002 - 18:11  Antworten mit Zitat
Abenteurer
Abenteurer


Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig

Zusätzlich sollte man vielleicht noch das Inventar des Spielers mit abspeichern... :roll:
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Tanan
BeitragVerfasst am: Do, 5 Sep 2002 - 18:52  Antworten mit Zitat
Abenteurer
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.
_________________
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
ChrisW
BeitragVerfasst am: Do, 5 Sep 2002 - 21:41  Antworten mit Zitat
Abenteurer
Abenteurer


Anmeldungsdatum: 26.08.2002
Beiträge: 278
Wohnort: Leipzig

Au Mist, ich wußte doch, dass ich was übersehen habe!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Martin
BeitragVerfasst am: Sa, 14 Sep 2002 - 12:30  Antworten mit Zitat
Experte
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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Beiträge der letzten Zeit anzeigen:   
Alle Zeiten sind GMT + 1 Stunde (MEZ)

Nächstes Thema anzeigen
Vorheriges Thema anzeigen
Seite 1 von 1
if-de :: Forum Foren-Übersicht  >  Dies & Das

Neues Thema eröffnen   Neue Antwort erstellen


 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.



Kontakt: Administrator

Powered by phpBB and NoseBleed v1.05