anpera.net
https://anpera.homeip.net/phpbb3/

[PHP] Cheatschutz in Browsergame
https://anpera.homeip.net/phpbb3/viewtopic.php?f=12&t=5020		 Seite 1 von 1
Autor:  Harthas [ Fr 16 Okt, 2009 07:15 ]
Betreff des Beitrags:  [PHP] Cheatschutz in Browsergame
Guten Morgen miteinander.

Ich schreibe dieses Thema hier in der Computer-Sektion, da es mit LotGD eig. nur indirekt zu tun hat.
In den letzten Tagen sind mir immer mehr Ideen zu einem Browsergame durch den Kopf geflogen (Inhalt tut hier nichts zur Sache). Um diese wirren Geister dann auch etwas zu beruhigen hatt' ich mir einiges notiert, einige Abläufe gezeichnet, Datenstruktogramme gezeichnet, u.s.w.

Dann ist mir allerdings plötzlich die Aktualisierungsproblematik in den Sinn gekommen. Und ich stutzte.
Was ist die Aktualisierungsproblematik (Aus meiner Sicht), erklärt an einem LotGD-Beispiel:
- Spieler kommt in Waldspecial
- Spieler erhält Gold im Waldspecial
- Spieler aktualisiert die Seite immer und immer wieder, um jedes Mal mehr Gold zu erhalten
Natürlich funktioniert dieses Beispiel nur, wenn da nicht der Navigationsschutz vorhanden wäre.

Nun gefällt mir dieser Ansatz aber nicht wirklich. Ich wollte das irgendwie loslösen und einen neuen Weg gehen.

Nun meine Frage an euch: "Hatte jemand bereits ebenfalls mit dieser Problematik zu kämpfen, und fand einen für Ihn ertragbaren Weg, oder zumindest eine Idee / einen Vorschlag?"

Ich habe auch schon einen Ansatz - Er sollte funktionieren, scheint mir aber noch etwas aufwendig (Untenstehend einige meiner Ideen dazu)
Harthas hat geschrieben:
- Bei jeder Aktion wird eine gewisse Art von Event generiert und in die Tabelle geschrieben.
- Diese Aktionen sollen einen eindeutigen Namen besitzen (bsp: house_id_1_to_2 um ein haus auf stufe 2 zu bauen).
- Wenn die Seite aktualisiert werden sollte wird erst kontrolliert, ob bereits ein solches Event vorhanden ist, oder bereits aufgerufen wurde ( Man kann ein Haus nicht 2 Mal auf Stufe 2 ausbauen ),
wenn dem nicht so ist, wird das Event hinzugefügt
- Diverse Event-Kategorien ( Ausbau, Forschung, Armee, Ausbildung, u.s.w. )
- Wenn ein user nun eine Seite aktualisiert, werden seine Handles überprüft, ob eines davon seine Gültigkeit erreicht hat ( Für jede Handle-Kategorie kann ein spezielles Skript geschrieben werden).
Ist ein Handle inzwischen ungültig ( BSP: Hausbauzeit ist abgelaufen ) so wird ein weiteres Skript aufgerufen um die Resultate auszuführen ( BSP: Hausstufe 1 erhöhen ).

- Ablauf an Hausausbaue
- Benutzer klickt auf Haus ausbauen
- Kontrolliere, ob das Haus überhaupt vorhanden ist und diesem Spieler gehört.
- Kontrolle, ob das Handle bereits vorhanden ist und nur 1x vorhanden sein darf. Wenn ja -> Abbruch
- Wenn nein -> script_requirements soll ausgeführt werden. Wenn dieses nicht true zurück gibt -> Abbruch
- Wenn true -> Handle haus_ausbaue_id_1_zu_2 wird in DB geschrieben
- Beim nächsten Benutzerklick
- Alle Handles des Benutzers werden ausgelesen ( closed=false)
- script_duration wird ausgeführt ( Für jedes andere Skript ). Gibt dieses false zurück -> passiert nichts
- Bei true -> script_result wird ausgeführt
- Handle closed wird auf true gesetzt.


Wäre natürlich super, irgend etwas von irgend jemandem zu hören.

Mit herzlichen Grüssen,
Louis / Harthas
Autor:  Auric [ Fr 16 Okt, 2009 11:34 ]
Betreff des Beitrags:  Re: [PHP] Cheatschutz in Browsergame
Hi Harthas,

ich bin kürzlich bei der Recherche nach einem Mailinglisten-System auf ein sehr interessantes Prinzip gestoßen: Die Implementierung von Abläufen direkt als FSM (Finite State Machine / Endlicher Automat).

Das man Probleme damit Modellieren kann war mir auch schon klar, aber mit der richtigen Herangehensweise lässt sich daraus ein praktisches Vorgehen für die Implementierung selbst ableiten. Einzige Vorausseztung: Das Sytem muss in der Lage sein, einen Funktionsaufruf ablegen und aus einer Variable heraus starten zu können (Das Projekt, von dem ich die Idee habe, arbeitet mit Python). Das kann man in PHP ja über Strings (wie die db_wrapper), Objekte oder ab 5.3 auch direkt als Lambda-Ausdruck machen (was wohl das eleganteste wäre).

Der Ablauf wäre nun wie folgt:
Für einen User werden stets eine bestimme Menge an Zuständen bereit gehalten, üblicherweise in einer Datenbank. Die kann z.B. seine Position sein.
Jeder Zustand ist jedoch eine Funktion (oder ein Objekt bzw. eine Referenz darauf)
Die Aktion, die der User zu tun wünscht, wird nun als Parameter übergeben, der von der FSM als Transition/Übergang interpretiert wird. Ist dieser gültig, was in der Zustandsfunktion entschieden wird (etwa durch ein switch-case mit default zum Bewerten unzulässiger Transitionen), wird dieser Ausgeführt. Dabei gibt er (üblicherweise über innere Methodenaufrufe) alle weiteren Informationen an das System weiter, die dieses für die Verarbeitung und Ausgabe braucht. Schlussendlich gibt er einen neuen Zustand zuück, der dann den bisherigen überschreibt und so einen "Schritt" darstellt.
Bei der nächsten Aktion wird nun von diesem Zustand aus weiter gearbeitet.
Bei Fehlern kann beliebig verfahen werden: Wiederholung, Rücknavigation, Besondere Ausgabe/Strafe etc.

Damit kann man mit sehr geringem Speicheraufwand recht präziese den Handlungsraum bestimmen, der noch zulässg ist. Um dein Beispiel mit dem Gold auf zu greifen:

Kommt der User in das Waldspecial, so wird sein z.B. sein Waldspecial-Zustand auf die Funktion gesetzt, die dieses Waldspecial repräsentiert. Dieses liefert initial auch die validen Reaktionen darauf, also die Navs. Wenn der User einen solchen gültigen Weg durch anklicken wählt, wird ganz normal verfahren. Wenn er nun etwas Gold bekommt, wird bei der Ausführung, die auch seinen Kontostand beeinflusst auch sein Zustand weiter gesetzt. Drückt er auf wiederholen, so wird ein eigentlich valider Parameter an die falsche Funktion gesendet und das Fehlverhalten so bestimmbar. Dementsprechend könnte er einfach wieder in den Wald zurück geworfen werden, abhängig von dem, was die derzeit aktive Zustandsfuntion vorgibt (was in diesem Fall nach Abschluss des Specials wieder der Wald wäre).


Ich hoffe, meine Ausführungen waren verständlich. Ansonsten empfehle ich sehr die Seite http://lamsonproject.org, auf der ich dieses System zum ersten mal gesehen habe.

Auric
Autor:  Nightborn [ Do 22 Okt, 2009 10:33 ]
Betreff des Beitrags:  Re: [PHP] Cheatschutz in Browsergame
Du beschreibst gerade das Prinzip der "allowednavs" =)

Zumindest seh ich keinen großen Unterschied.

Die Zustände wirklich fein (also schrittkettenartig) zu definieren wäre ein komplettes rewrite aller Modifikationen + des Cores. Da wird direkt einfach in der Session rumgeschrieben ohne wrapper. $session['user']['...'] ... kein getUser($id) oder wo ich per Interface dazwischenkomm.

Nach allowednav gibts die "restorepage", also den vorherigen Zustand/angezeigten Zustand.
Seite 1 von 1 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/