Optimierung der vollen Speicherung

Man kann die Vollständige Speicherung von Spielständen dahingehend erweitern, dass an bestimmten Levelanfängen festgelegt wird, dass die Änderungen in vorherigen Leveln nicht mehr berücksichtigt werden sollen. Das ist beispielsweise bei der Source-Engine möglich, sollte allerdings nur dann eingesetzt werden, wenn man mit Sicherheit nicht in ein vorheriges Gebiet zurück kommen kann. --Sacaldur 08:55, 17. Nov. 2011 (CET)

Ich merke schon das Thema ist ganz schön umfangreich. Leider habe ich vom Programm technischen noch nicht wirklich was in der Richtung geschrieben. Ich werde mal schaun wie weit ich komme und dann das ganze online stellen so das die anderen vielleicht mit mehr Erfahrung dann mitwirken können. oder soll ich es Gleich für alle zugänglich machen ? --Koschi 09:12, 17. Nov. 2011 (CET)

Da es ein Thema ist, welches zweifelsfrei für die Spieleprogrammierung erforderlich ist (auch wenn nicht für jedes Spiel), kannst du das machen. Wenn du der Meinung bist, dass du erst ein wenig "ungestört" daran Arbeiten willst, dann kannst du das auch machen. --Sacaldur 10:23, 17. Nov. 2011 (CET)

Speichermedien

Es sollte darauf eingegangen werden, worin (Dateiformat) die Spielstände gespeichert werden können. Vorstellbar wären: XML-Datei, YAML-Datei, Datenbank (beispielsweise mit SQLite oder Derby), andere/eigene textuelle Form oder andere/eigene binäre Form. Weitere Dateiformate fallen mir spontan nicht ein. Zudem sollte die Möglichkeit der Cloud erwähnt werden, auch wenn es für normale Hobbyprogrammierer wohl eher unsinnig wäre. --Sacaldur 08:58, 17. Nov. 2011 (CET)

Möglichkeit des Speicherns

In Spielen kann es ebenfalls der Fall sein, dass der Spieler nicht überall speichern können soll. Denkbar wären folgende Dinge:

• Überall ist das Speichern möglich
• Nur in bestimmten Gebieten ist das Speichern möglich
• In bestimmten Gebieten ist das Speichern nicht möglich
• Das Speichern ist nur an bestimmten Stellen möglich (in einem Hotel)
• Das Speichern kann nur dann durchgeführt werden, wenn das Spiel danach fragt (bei Super Mario World nach jedem Schloss oder Geisterhaus)

Diese könnten außerdem kombiniert verwendet werden und/oder in Kombination mit dem stehen, was gespeichert wird (Position des Spielers)

--Sacaldur 13:40, 17. Nov. 2011 (CET)

Oder man kann nur ein einziges Mal pro Level speichern. --David Scherfgen 14:46, 17. Nov. 2011 (CET)

Besonderheit Android

Eine Besonderheit stellen Spiele für android dar, da bei diesen das aktuelle Spielgeschehen teilweise ohne das zutun des Benutzers gespeichert werden muss, ohne dass dies für den Benutzer erkennbar ist. Im Gegensatz zu einem Autosave ist das erforderlich, da das Programm in den Hintergrund geraten kann und solche Programme können von Android nach belieben beendet werden, um Ressourcen frei zu räumen. Wenn das Spielgeschehen wieder aufgenommen werden soll, sollte der Spieler auch wieder an der erwarteten Stelle anfangen. Sollte im Tutorial zur Androidspieleentwicklung darauf eingegangen werden, dann sollte von hier aus zumindest darauf verwiesen werden. --Sacaldur 16:28, 17. Nov. 2011 (CET)

Level-Code

Ich fände es noch gut, eine Empfehlung zu geben, wie lang ein Level-Code sein sollte. Ich hätte jetzt gesagt so 10 bis 12 Buchstaben/Zahlen.--Koschi 09:15, 18. Nov. 2011 (CET)

Jo, viel länger sollte das nicht sein. Größenordnung 10 bis 20. Man muss auch darauf achten, dass die Buchstaben klar voneinander unterscheidbar sind (Probleme könnte es z.B. bei einem großen i vs. kleines L geben). Dann kann man ausrechnen, wieviel Bit an Informationen man unterbringen kann (+Prüfsumme). --David Scherfgen 09:30, 18. Nov. 2011 (CET)

Externe URLs

Mir ist aufgefallen, dass du (Koschi) die externen Links falsch setzt. Der senkrechte Strich | ist dort nicht erlaubt, weil er als Teil der URL interpretiert wird. Klick mal deinen Final Fantasy-Link an, dann siehst du es. Die anderen Links habe ich schon korrigiert. --David Scherfgen 09:31, 18. Nov. 2011 (CET)