Version vom 7. Dezember 2011, 16:45 Uhr

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)

Wenn sich jemand berufen fühlt etwas dazu zu schreiben bitte. Leider habe ich in diesem Bereich nicht so den Plan, deshalb sollte hier jemand anderes mal übernehmen.--Koschi 15:12, 19. 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)

Wenn es recht ist werde ich den Teil mal 1 zu 1 (bis ...der erwarteten Stelle anfangen.) übernehmen (hört sich gut an) bzw. wenn du magst intergrier das selber.

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)

Neben den Buchstaben und Zahlen kann man auch Symbole zur Verschlüsselung der Information verwenden. Damit meine ich nicht nur Sonderzeichen, sondern auch Bilder. Ein Beispiel dafür stellen die Schlümpfe für SNES dar. Man musste als Levelcode die richtige Kombination von Schlumpfköpfen eingeben. Entsprechend könnten für das eigene Spiel andere symbole verwendet werden (wie gegenstände aus dem Spiel). --Sacaldur 12:46, 18. Nov. 2011 (CET)

Wie wäre es anstatt mit einer konkreten Zahl mit dem Satz "Deshalb sollte ein Level-Code nur so lang wie nötig und so kurz wie möglich sein!"? --Koschi 07:43, 23. 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)

Jo stimmt hatte ich vergessen diese strich ist nur intern.--Koschi 13:26, 18. Nov. 2011 (CET)

Fachbegriffe

Gibt es eigentlich irgend welche Fachbegriffe in diesem Zusammenhang z.B. für das "immer und überall" Speichern? Leider findet sich nicht viel über das Konzept der Speicherfunktionen im Netz. --Koschi 10:01, 19. Nov. 2011 (CET)

Nicht dass ich wüsste. Auf Englisch würde ich vielleicht "unconditional" sagen. Oder auf Deutsch vielleicht "freies Speichern"? --David Scherfgen 10:37, 19. Nov. 2011 (CET)

Vor- und Nachteile

Fallen euch Vor oder Nachteile ein die man Erwähnen sollte bei Abschnitt "Speicherpunkte" und "freies Speichern"?--Koschi 15:14, 19. Nov. 2011 (CET)

Nachteil beim völlig freien Speichern: der Spieler kann sich Schritt für Schritt durch schwierige Abschnitte des Spiels "durchspeichern". Das will der Spiele-Designer vielleicht nicht. Das geht halt nicht, wenn er nur an bestimmten Punkten speichern kann. --David Scherfgen 18:27, 19. Nov. 2011 (CET)

Es müssen, wenn der Spieler beim Laden an der gleichen Stelle wieder starten soll, weit mehr Informationen gespeichert werden. Neben den Koordinaten wären das auch die Zustände von Gegnern oder Sequenzen. Zudem kann der Spieler dadurch seinen Speicherstand ruinieren. Wenn er beispielsweise gerade eine Klippe runter gefallen ist und dabei einen alten Spielstand überschreibt, dann stirbt er immer nach dem Laden des Spielstands.

Andererseits muss man bei den Speicherpunkten darauf achten, dass diese auch gut platziert sind. Es sollten in deren direkten Nähe keine Gefahren lauern, die einen beim Laden töten. Außerdem dürfen sie nicht zu weit voneinander entfernt stehen, da sonst das Spiel zu schwer wird.

--Sacaldur 09:02, 21. Nov. 2011 (CET)

Vor allem solche Spiele, die dazu gedacht sind, dass man sie auch nur "mal eben ein paar Minuten" spielt, sollten häufig die Möglichkeit bieten zu speichern. --David Scherfgen 09:22, 21. Nov. 2011 (CET)

Nachteile XML

Dass bei XML ein Overhead auftritt steht außer Frage. Allerdings ist eine Redundanz nicht zwingend gegeben, da dies ganz darauf ankommt, wie die zu speichernden Daten strukturiert sind. Was ist mit den Redundanzen gemeint? --Sacaldur 09:12, 7. Dez. 2011 (CET)

Mit Redundanz meinte ich z. B., dass in einem schließenden Tag der Tag-Name noch einmal angegeben werden muss, obwohl das eigentlich überflüssig ist. --David Scherfgen 16:45, 7. Dez. 2011 (CET)

Version grundsätzlich mit speichern.

Ich denke es sollte noch darauf hingewiesen werden, dass man nach Möglichkeit immer eine Versions-Nummer mit speichert. Da man evtl. später noch etwas ändern können möchte und man für evtl. Probleme mit entweder einer einfachen Bedingung die Version prüfen kann oder man sich eine Art Konverter schreibt. Gerade bei einem eigenen Binärformat sehr hilfreich. --DaG 16:13, 07. Dez. 2011 (CET)