Vollständige Version anzeigen : Wettbewerbe
Nun denke ich seit einiger Zeit natürlich auch darüber nach, wie ich mein Spiel so aufbauen kann, dass man einerseits zwar alle möglichen Möglichkeiten hat, das Spiel zu modifizieren, andererseits aber bei einem Wettbewerb sicherstellen möchte, dass eben gerade nichts modifiziert worden ist, um vergleichbare Savegames einander gegenüberstellen zu können.
Dazu ist mir dann folgende Idee eingefallen. Bitte denkt mal darüber nach, ob das wirklich wasserdicht ist, oder ob ich da was wichtiges übersehen habe...
In einem Savegame speichert man zunächst einmal natürlich immer ein komplettes Bild des aktuellen Zustands aller Objekte im Spiel ab, also was ist wo gebaut, wo ist welcher Läufer gerade und wohin geht er, wo befinden sich welche Güter, und so weiter. Dieser Teil ist natürlich nicht fälschungssicher, denn hier könnte man einfach irgendwelche Bytes verändern und damit den Zustand manipulieren. In den existierenden Spielen wird das dadurch entschärft, dass die Savegames in einem geheimen Format gespeichert sind, man also nicht weiss, welche Bytes was bedeuten. Rein theoretisch wäre es aber möglich, hier was zu fälschen. Bei Caesar IV haben sie einen zusätzlichen Check eingebaut, der die Korrektheit gewisser Files prüft, was aber dummerweise dazu führt, dass man gelegentlich als Mogler bezichtig wird, obwohl man entweder nichts verändert hat oder vielleicht einen für den Spielablauf unbedeutenden Parameter...
Nun ist die Idee, ein Log mitzuschreiben, das alle Aktionenen des Spielers mitschreibt, die für das Spiel relevant sind. Als zum Beispiel: Baue diese Sorte Haus dahin, zu dieser Spielzeit. Alles, was mit Anzeige oder Menüklicken zu tun hat, Änderungen der Spielgeschwindigkeit oder Pause, wird nicht mitgeschrieben. Damit enthält ein solcher Spielstand zwei Teile: Den Log, und den abschliessenden Zustand. Mit dem Log sollte sich nun das Spiel nachfahren lassen (das muss aber nicht in Echtzeit geschehen, sondern sollte auch in maximaler Geschwindigkeit funktioneren, also insbesondere auch komplett ohne grafische Anzeige), und dann kann man am Ende den gespeicherten Zustand überprüfen. Stimmt das überein, dann wird das Save akzeptiert, wenn nicht, hat der Spieler irgendwo gemogelt.
Damit das so funktioniert, muss natürlich die Simulation des Spiels so gut funktionieren, dass sich das Spiel tatsächlich mithilfe des Logs nachfahren lässt, ich denke aber, dass ich das hinbekomme. Die nette Eigenschaft ist, dass man nach Belieben alles modifizieren kann, was mit der reinen Anzeige zu tun hat, ohne dass dies bei der Prüfung zu Buche schlägt...
Modifizieren und Savegame-Fälschen sind aus meiner Sicht noch zwei verschiedene Dinge.
Solche Einstellungen wie Spielgeschwindigkeit, Menüfarbe, sonstige Anzeigeoptionen würde ich gar nicht in der eigentlichen Save-Datei speichern, sondern eher in einer Konfigurationsdatei für das Spiel.
Falls doch beides in einer Datei steht, bestünde noch immer die Möglichkeit, nur den einen Teil, also die eigentlichen Save-Daten auf Veränderungen zu überprüfen, nicht aber den Teil, der Anzeige-/Spieleinstellungen beinhaltet.
Andere Veränderungen aber, wie das Hinzufügen neuer Gebäude oder Fußgänger oder Waren oder Bedürfnisse der Bewohner (...), kurz: alles, was modifizierbar sein soll, um das Spiel vielfältig zu machen, sollen ja, wenn ich dich richtig verstehe, nicht vorgenommen worden sein (schließlich soll eine Wettbewerbsaufgabe zwecks Vergleichbarkeit von allen mit dem selben Spiel gelöst werden). Das bedeutet, dass es in diesen Einstellungen durchaus auf jedes Byte ankommt. Einstellungen, die sowieso jeder Spieler für sich vornehmen soll, müssen ja auch in der Szenario-Datei der Wettbewerbsaufgabe nicht codiert sein.
Weil diese Datei (oder dieser Datei-Teil des Speicherstandes?) keine Veränderung erfahren soll und nie anders als mit dem Spiel geöffnet wird (nichteinmal überschrieben werden dürfte er), kann sie ruhig nach Caesar IV-Manier geprüft werden (ohne jetzt das Spiel oder den Check-Algorithmus zu kennen ;) ).
Was bleibt, ist die Frage, wie man Veränderungen im Sinne von Fälschungen in den Spielständen feststellen kann.
Der Vorschlag, jede Spieleraktion zu protokollieren und zur Überprüfung den kompletten Spielverlauf zu simulieren, ist eine relativ wasserdichte Möglichkeit.
Vorsichtig sein muss man dabei allerdings, was alles gespeichert und was allein vom Simulationsprogramm übernommen werden soll. Wird zu viel gespeichert, spart das wahrscheinlich Simulationszeit, macht aber das System fälschungsanfälliger (vorausgesetzt wieder, der Cheater weiß, welche Bytes wofür stehen), weil leichter durchschaubar, wenn nicht gerade viele zusätzliche Abfragen vorgenommen werden (in der Art "sendet das Gebäude dann tatsächlich, wie hier gespeichert ist, um Spielzeit xxxxxxxx einen Fußgänger aus?", "hat Kleinkleckersdorf wirklich gerade ein Geschenk über ). Wenn zu wenig gespeichert wird, kann es leichter sein, dass das Simulationsprogramm eine andere Entscheidung trifft als das Spiel zuvor und ein eigentlich ungefälschtes Ergebnis wird abgelehnt. Besonders, wenn Zufallswerte an "Entscheidungen" des Programms beteiligt sind, passiert das leicht mal.
Der Nachteil wäre, dass einige Zeit für die Simulation gebraucht würde (vielleicht handelt es sich um eine umfangreiche Mission, die auch schon mehrere Abende Computerspielen verschlungen hat - in dem Fall wäre auch die Simulation zeitaufwändig), was entweder beim Laden stören würde (je nachdem, wann die Prüfung stattfindet) oder aber denjenigen, der dadurch alle beim Wettbewerb eingesandten Saves überprüfen möchte, viel Zeit kosten würde.
Ein positiver Nebeneffekt dieser Überprüfung wäre natürlich, dass man in jedem Fall das Spiel nochmal ansehen kann und dadurch aus den Spielen anderer lernen oder eigene Fehler entdecken kann.
Die Frage ist, ob der Aufwand nötig ist oder ob es nicht ausreicht, einen Speicherstandsteil - den mit ergebnisrelevanten Informationen - z.B. durch zusätliche Prüfbytes fälschungssicher(er) zu machen. - unbedeutende Einstellungen können ja von der Prüfung ausgenommen werden. Würde das nicht reichen, gerade in Anbetracht der Tatsache, dass 100%ige Fälschungssicherheit sowieso nie erreicht werden kann?
Ich hoffe, in diesem ewig langen Erguss erster Gedanken findet sich irgendetwas, das weiterhilft ;)
An welcher Stelle soll denn die Prüfung/Simulation vorgenommen werden? (Beim Spieler beim Save-Laden, beim Wettbewerbsveranstalter nach Einsenden des Saves,...?)
Savegame ist nicht gleich Szenario. Die für das Spiel relevanten Dateien, und dazu gehören insbesondere alle Skripte, die Dinge laden oder ein Szenario starten, sowie Trigger und so weiter, werden nicht im Savegame mitgespeichert. Hier ist es also nötig, zu prüfen, ob der erreichte Spielstand plausibel ist. Diese Prüfung macht nur derjenige, der die eingereichten Spielstände für einen Wettbewerb testet, um Mogelversuche zu entdecken und auszuschliessen. Für das normale Spiel sollte vermutlich nicht einmal das Log mitgeschrieben werden, weil jeder Spieler selbst entscheiden können soll, ob und was er für sich modifiziert, einfacher macht oder schwieriger, oder vielleicht gerade ein Addon vorbereitet. Es geht mir in dieser Frage also ausschliesslich um die Prüfbarkeit von Savegames im Rahmen von Wettbewerben.
Ach ja, und es ist natürlich klar, dass man genau so viel Infos ins Log schreibt, dass die Simulation das Spiel nachvollziehen kann. Die Entscheidungen, die die Simulation dann in jeder Situation trifft, müssen letztlich mit dem übereinstimmen, was der Spieler auch gesehen hat. Wie schon gesagt, so ganz einfach ist das sicher nicht, ich denke aber, dass ich das hinbekomme.
Danke noch für's mitdenken!
Bitte, gern.
In dem Fall ist es natürlich so, dass die Simulation genau dann von dem Spielverlauf abweicht, wenn irgendeine Datei so weit modifiziert wurde, dass sich am Ergebnis etwas ändert, also in genau allen Fällen, die entdeckt werden sollen.
(Ich halte die Variante trotzdem noch für aufwändig, aber schließlich bin nicht ich der Prgrammierer. Ich würde durch irgendeine Funktion dafür sorgen, dass einer Szenariodatei durch das, was darinsteht, ein Schlüssel zugeordnet werden kann und den mit abspeichern (zur Sicherheit vllt. an unterschiedlichen Stellen unterschiedlich vershlüsselt). Dann bei jedem Laden und Spielen überprüfen, ob die vom Spiel verwendeten Einstellungen denen entsprechen, die das Save erfordert. Und nach Einsendung nachschauen, ob der Schlüssel im Save zu der Szenario-Datei passt, die die Aufgabe war. Fälschungssicherer ist allerdings dein Vorgehen, das muss ich zugeben.)
Um zum Schluss noch einmal auf die ursprüngliche Frage zu antworten: Ich sehe keine Möglichkeit, dieses System auszutricksen.
Wenn man versucht, das nur mit bestimmten Checksummen (Schlüsseln) zu machen, ergibt sich ein Problem, das genauso schwierig zu lösen ist: Man muss nämlich nicht nur die Files lesen und die Checksummen berechnen, sondern auch dafür sorgen, dass die Files sich während des Spiels nicht ändern (was man im Allgemeinen durchaus zulassen möchte) bzw. eine Kopie im Speicher verwendet wird, die zu Programmbeginn geladen wurde.
Die Sache ist aber die: Ich möchte das Spiel so bauen, dass man Skripte auch noch modifizieren kann, während das Spiel läuft. Das ist zum Beispiel interessant für Leute, die Szenarien bauen und dann bestimmte Sachen in einem Trigger ausprobieren wollen. Man möchte da nicht jedesmal das Spiel neu starten, um eine Änderung zu testen. Auch möchte man im Allgemeinen ein bestehendes Savegame mit geänderten Files weiterspielen können, aber eben nicht in einem Wettbewerb. Von daher bin ich gar nicht erst tiefer in diese Verschlüsselungsmaterie eingedrungen...
Es gibt natürlich einen Weg, auch das von mir vorgeschlagene Verfahren auszutricksen, allerdings erfordert das tiefere Kenntnisse von Hacking und Debuggen, die entsprechenden Tools, und wenn ich die Prüfung ein bisschen dezentral hinschreibe, eine Menge Detektivarbeit. Anders gesagt, steht der Auswand in keinem Verhältnis zum erzielbaren Nutzen. :hehe:
Während des Wettbewerbs sollen die Skripte nicht verändert werden.
Zu anderen Zwecken schon. Das kann ich gut nachvollziehen.
Aber die Überprüfung muss ja auch nur bei Wettbewerbsaufgaben stattfinden, sodass man zu Beginn eines Spiels/Szenarios angibt/mitspeichert, ob geprüft werden soll. Und dass, für den Fall, dass man eine Wettbewerbsaufgabe hinterher noch zu irgendwelchen Testzwecken verwenden möchte, dieser Schutz nur durch Aufgeben des Spiels abgeschaltet werden kann. In anderen Worten: es für diesen Fall eine Funktion "Ohne Wettbewerbseinstellung laden" gibt, die Laden erlaubt, aber durch Verändern der Werte im Save entsprechende Authentizitätsprüfungen fehlschlagen ließe. Tester könnten nach Herzenslust herumspielen, aber das Veränderte nicht mehr zum Wettbewerb einschicken.
Vom Ergebnis her lässt sich wohl mit beiden Methoden ungefähr das Gleiche erreichen, bei der einen mit etwas weniger Rechenaufwand, bei der anderen etwas sicherer (per Hacking... lässt sich sowieso alles irgendwie aushebeln, das meinte ich ja oben mit der nicht erreichbaren "100%igen Fälschungssicherheit").
....tiefere Kenntnisse von Hacking und Debuggen, die entsprechenden Tools, und wenn ich die Prüfung ein bisschen dezentral hinschreibe, eine Menge Detektivarbeit. Anders gesagt, steht der Aufwand in keinem Verhältnis zum erzielbaren Nutzen .....
Eben. Ich denke das trifft im Kern die eigentliche Basis deines Threats :
Es gibt bei der Verbreitung von CB's - anders als bei Shootern - kaum eine nennenswerte Gruppe von Leuten, die sich für einen Wettbewerb die Mühe machen würden, es sei denn, es gibt richtig was zu gewinnen.
Wir haben jetzt in unserem Wettbewerb rund 1500 Saves bekommen, von denen ganz offensichtlich 11 "beschummelt" waren. Und für die Vorbereitung und auch schon das schlichte erstellen von attraktiven Szenarien geht sehr viel Zeit für das erforschen der Strukturen drauf.
Nee, ich würde mir wirklich die Mühe aufwändiger Schutzmaßnahmen sparen, es gibt in der CB Szene niemanden der sich jetzt wirklich hinsetzt und stundenlang rumfummelt - wirklich sundenlang. Eine Prüfsumme hier oder da, aber sonst...........
omnibus
1500 ist ja eine ganze Menge. Wow!
Nun, ich denke ja auch nicht, dass sich hier viele Leute finden, die gezielt an einem Spiel herumfummeln, um sich in einem Wettbewerb einen Vorteil zu verschaffen. Der Punkt ist ein bisschen ein anderer: Da das Setup des Spiels praktisch komplett aus Skripten besteht und damit im Klartext offen liegt, und die später im Spiel auszuführenden Trigger genauso funktionieren, d.h. als Klartextskripte im Verlaufe des Spiel geladen und ausgeführt werden, ist es furchtbar einfach, in einen Spielverlauf einzugreifen und ihn zu verändern. Das ist ja auch gewollt: Einerseits möchte ich eine Standardinstallation haben, mit der man einfach spielen können soll, andererseits hoffe ich, dass sich einige Spieler finden werden, die sich an den Skripten zu schaffen machen, um Dinge zu verändern, zu verbessern und vor allem: zu erweitern. Solche Erweiterungen kann ich dann ggfs. in die Standardinstallation mit aufnehmen, jedenfalls ist das die Idee dabei. Es soll also möglichst einfach sein, die Skripte zu verändern und zu erweitern. Damit ist es natürlich auch sehr einfach, sich ein Wettbewerbsspiel ein bisschen einfacher zu machen... daher meine Überlegungen zu Plausibilitätsprüfungen...
Wie auch immer, Danke für's mitdenken! Habe letztes Wochenende einen grossen Schritt dahin getan, bessere Fehlermeldungen aus den Skripten zu erzeugen, so dass man einen guten Hinweis darauf bekommt, was falsch ist, wenn es irgendwo hakt oder eine Prüfung zuschlägt. Jetzt schaue ich mal zu, dass ich noch einen Schritt weiterkomme, dann gibt es wieder eine Probierversion.
vBulletin v3.5.0, Copyright ©2000-2009, Jelsoft Enterprises Ltd.