Ich habe sehr lange an der Entwicklung von Archivements gefeilt, da sie mich doch sehr angemacht haben. Die umsetzung an sich stellte sich aber als schwierig da. Es war ein ennormes Patching von nöten, was Dann letzten ende folgenden Spielaufbau bewirkt:
Spiel starten -> Titelbild wird übersprungen -> Ladebildschirm wird aufgerufen -> Enterdruck wird simuliert -> Spielstand 1 wird geladen.
Das alles läuft schnell am anfang ab, so dass der Spieler davon nix mit kriegt, erst dann erreicht der spieler das Titelmenü.
Im Spiel selbst wird folgendermaßen gespeicher:
Selbstgebautes Speichermenu, welches
für slot 1 die variabeln 100-199 /
für slot 2 die variabeln 200-299 /
etc
benutzt und die mit den Spielstandrelevanten variabeln 0-99 überschreibt.
Danach wird wieder mit schwarzem screen auf die Titelmenükarte gesprungen, dass echte speichermenü aufgerufen und enter simuliert.
ob der spieler das spiel nun weiterspielt oder auf dem titelmenü bleibt wird durch einen switch abgefragt, der von mir aus auf stelle 100009 liegt, sprich nicht spielstandrelevant ist
Das Laden funktioniert dann praktisch anderstrum, variabel 0-99 werden durch die auf 100-199 gespeicherten überschrieben.
Der vorteil daran:
eigenes Lade/speichermenü möglich,
kontrolliertes speichern möglich (wenn ersteller will nur 1 slot verfügbar)
archivements einbaubar (die auch um variabel 100009 rumliegend gespeichert werden, und vom geladenen spielstand unabhängig sind)
Nachteile:
AEP-Patch, was ein eigenes Titelmenü mit sich führt
Tastendruck simulation muss auch durch patches eingebaut werden
ein haufen fork- und variabelarbeit für das eigene Speicher/Lademenü
Ein Spielstand muss beim verschicken des Spiels vorhanden sein, am besten mit jungfräulichen variabeln
würd mich freuen, wenn jemand noch ne einfachere lösung hätte, wobei ich die schon recht funktionell und dynamisch finde. Das Ganze könnte auch zu einem technikdiskuss führen, Aber so im Allgemeinen:
Archivements/unlockcontent = Genial
Zitieren
