Replikation - Woran Muliplayer Spieler in der Realität scheitern - oder auch nicht - Cheating

Replikation. Ich habe hier schon des öfteren über Replikation geschrieben und warum es das Herzstück eines Multiplayer Spiels ist - und warum ein Spiel daran zerbricht oder nicht. Um mich nicht immer wieder zu wiederholen fasse ich es hier zusammen. Wie schon zuvor - ich könnte ein Buch darüber schreiben und habe das überlegt - aber auch hier will ich euch die Kosten für ein Buch sparen und versuche mich kurz zu fassen.

1. Was ist Replikation und warum ist es so wichtig?

OK um es kurz zu machen - der Grund nennt sich Cheating. Cheating - also "Schummeln" ist schon älter als Videospiele - das gab es sicherlich schon vor tausenden von Jahren als die ersten Spiele aufkamen. Spiele haben regeln und wer sie bricht ist Schummler. Vor 500 Jahren waren es vielleicht gezinkte Würfel oder so. Heute in Videospielen sind es eher Tools und Programme die den Spielablauf manipulieren. In Single Player Spielen ist das nicht so schlimm - wenn ihr euch im allerersten Doom von 1993 im Single Player unendlich Gesundheit oder Munition verschafft habt dann war das Spiel vielleicht ein bisschen langweiliger für euch aber OK - das stört ausser euch niemand.
Heute spielt man gerne Muliplayer und wenn jemand in "Counter Strike" unsterblich ist dann ist das für die ehrlichen Spielernicht nur frustrierend - es zerstört das Spiel und führt dazu daß ein Spiel für ehrliche Spieler sinnfrei ist und sie aufhören zu spielen. Bei kostenlosen Spielen vielleicht nur ärgerlich - wenn ihr dafür bezahlt habt - eine Zumutung und Betrug!!!

Was hat Replikation damit zu tun? In UE4 bestimmt Replikation welche Werte im Spiel wie festgehalten und übertragen werden.

Bewegung und Gesundheit sind so typische Werte die repliziert werden. Ja in den meisten Ballerspielen seht ihr die Gesundheit des Gegners und klar wenn er sich bewegt oder schiesst. Doch wie geht das im Detail und wie setzt man das um? Was ist ein Client und was ist ein Server und wer repliziert wohin? Kommen wir zum nächsten Kapitel...

2. Client Server Konzept - wer hat die Hosen an?

Traditionell gibt es einen Server - bei guten Spielen vom Betreiber gestellt -der hat die Hosen an und bestimmt praktisch alles. Aber was hat das mit Replikation zu tun und wer repliziert wohin?
Grundsätzlich seit ihr wenn ihr ein Online Spiel zockt der Client, sozusagen der "Kunde", der grosse Server ob nun von Rockstar, Origin oder Bethesda der "Server", also der "Betreiber". Klar der "Server" sagt wo es lang geht, ob ihr noch in einer Partie mitmachen könnt oder ob es schon "voll ist". Der Server hat die Hosen an, der sagt wo es langt geht. Aber was hat das mir Replikation zu tun?
Bei UE4 ist der fatale Punkt - das bestimmt ihr. Hier könnt ihr alles falsch machen oder alles richtig. Wichtig ist es zu verstehen daß der Server das sagen hat.
Replikation kann vom Client aus gehen -alsovom Spieler oder vom Server. Klar der Server soll das sagen haben - aber kann der alles machen? Wenn der Client nur Zuschauer ist -ja.Aber er Client will ja auch spielen, also muß er schon was replizieren. und hier beginnt die Denkarbeit.

3. Was repliziert der Client? Best practices

Klar erstmal denkt man es macht Sinn alles vom Client zu replizieren. Bewegung, Gesundheit, evtl welche items er hat. Aber genau hier setzt ein Cheater an. Ihr repliziert gesundheit an den Server? Toll ein Cheater repliziert immer 100% Gesundheit. Auch wenn euer Spiel das nicht hergibt - der Cheater baut ein programm um den Speicherbereich zu manipulieren der die Gesundheit festhält und überschreibt es immer mit 100%. Schon ist man unsterblich. Macht das Spiel viel einfacher. Und alle ehrlichen Spieler beissen ins Keyboard weil man den Typ nie abknallen kann.

Aber Gut was repliziert man dann? Goldene Regel? Nur die TASTATUR (Und Maus) Eingaben des Client. Nur das!!! Niemals mehr. Der Server kennt die Gesundheit des Spielers. Der Spieler schiesst? Dazu repliziert er die aktuelle Position und den Winkel. Hat er getroffen? Der Server errechnet das! Der Server zieht dann Gesundheit vom Gegner ab. Im Grunde wird alles vom Server festgehalten und replizieren tut der Client nur die Eingaben die er macht, also 3.5 Sekunden "W" gedrückt gehalten um vorwärts zu laufen, dann das Fadenkreuz 63 Grad nach Links gedreht und linke Maustaste gedrückt und zu schiessen. So ungefähr. Mehr repliziert der Client nicht!!!

4. Reicht das? Mehr cheats?

Ja das reicht an Client Replikation. Welche Items der Spieler hat, welche davon aktiv sind, wieviel Gesundheit, ob er getroffen hat usw - das repliziert alles der Server. Was ein Gener an Items spawnt wenn er stirbt, was der Spieler tatsächlich einsammelt usw - alles Server Sache. Vom Client - nur Eingaben! Ist das sicher? Nein!!!!! Hier braucht es sogenannte Plausi Prüfungen. Ist die Eingabe plausibel? z.B. dreht sich der Spieler schneller als das mit der besten 1200 dpi optical Mouse möglich ist? Dann ist es evtl. ein Aimbot - also ein Programm daß das Fadenkreuz des Spielers immer in Richtung des Kopfes eines Gegners dreht. Ob man hier automatisch den Client bannt wegen cheating oder nur einen Alarm auslöst bleibt einem selber überlassen, aber klar auch hier gibt es noch Material für Cheater. Wenn der normale Spieler maximal 120 Eingaben pro Minute macht und da ist plötzlich einer der 500 überschreitet dann ist das vielleicht ein Cheater? Hier muß man nicht direkt einen Ban aussprechen sondern erstmal im Beta Test Werte sammeln - können das Spieler legitim überschreiten? Hat vielleicht einer eine neumodische Maus oder Tastatur die solche Werte zulässt? Hier braucht es Fingerspitzengefühl - aber Cheater kann man evtl überführen wenn solche Werte total aus dem Ruder laufen.

5. Fazit?

Siehe Punkt 3. Repliziert man nur ds notwendigste vom Client ist man auf der sicheren Seite. Hat man nur Eingaben zu replizieren stehen auch die härtesten Cheater mit leeren Händen da. Je weniger der Client repliziert desto weniger Angriffspotential. Früher dachte man oft "Lass den Client mehr replizieren, dann ist der Server weniger busy und ich kann mehr Leute darauf spielen lassen." Führt aber nur zu mehr Cheatern und zu regelrechten Kriegen zwischen Admins und Cheatern. Die regulären Spieler sind hierbei die Verlierer - und die bezahlen ja für das Vergnügen.

Ja ich sehs auch mehr als Diskussionsgrundlage. Es ist ja auch absichtlich kurz gefasst und bietet viele Punkte zum disutieren.

In der Praxis gibt es extrem wenige Spiele die tatsächlich nur den Input der Clients an den Server replizieren und alles andere dem Server überlassen - an unkritischen Stellen kann man ja aus Gründen der Performance davon abweichen.

Aber man sieht auch daß Unternehmen die mehrere hundert Millionen Dollars schwer sind diesen Artikel nicht gelesen haben und sich so mit den üblichen Cheatern rumärgern - zum beispiel Fallout 76 - hier sind auch nach X patches immer noch "Item dupings" möglich - was natürlich gar nicht sein darf.

Auch gehe ich hier gar nicht drauf ein wo die Replikation Sinn macht und wo man sie ggf. ersetzen oder weglassen kann. Wir hatten ja hier vor ein paar Tagen die Diskussion - ich meine man muß eine 1000 kmH schnelle Gewehrkugel die man eh nicht sehen kann nicht wirklich replizieren oder gar darstellen - hier reicht z.B. ein (oder mehrere) line traces.

In der Praxis lässt man auch die Clients Bewegungen bzw. Standort replizieren - sogenannte "Speed hacks" oder "fly hacks" (Spieler rennt 100 kmh schnell/Spieler fliegt umher obwohl er es theoretisch gar nicht kann) kann man auch durch Plausi Prüfungen abfangen ("Ist der Spieler schon mehrere Sekunden in der Luft? --> Potentieller Cheater) und dann automatisiert an Admins melden oder gar bannen.

Wie gesagt - in der Praxis geht man einen Kompromiss ein zwischen "Spieler repliziert nur Eingaben" und "Spieler repliziert alles", aber daß man sehr vitale Dinge wie "Meine Gesundheit" oder "seltenes Item spawnt gerade" nicht den Spieler replizieren lässt wurde hier schon klar...

Jo, ich denke am cheating zerbrechen viele Multiplayer Spiele - man kann ja auch nicht endlos viele Admins und mods da reinkloppen weil das echt teuer ist und die auch nicht immer alles mitbekommen.

Letztlich muß man den Mechanismus verstehen - eigentlich wäre es fast schon am besten man hat selber mal gecheatet oder versteht die Hintergründe wenigstens verdammt gut. Wenn man ein Multiplayer game erst mal "fertig" hat und in die Welt verteilt ist es echt schwer daran viel zu ändern - es gibt nix schlimmeres als wenn dein ganzes Spiel auf Funktionen basiert die für Hacker angreifbar sind. Siehe Fallout 76 und das duping problem und andere cheats - man kann halt nicht alles mit Geld und admins erschlagen.

Hmmm, klares "jein"...

OK Replikation ist ja eigentlich ganz einfach ausgedrückt das "übertragen von Werten auf entfernte Systeme". Sowäre mein Wording. "Authorative client/Server networking" mag ich als Begriff nicht. Authorative - heisst wörtlich "Der das sagen hat". Wenn der CLient was zum server repliziert ist der client in dem Moment streng genommen "authorative".

Mit geht es mehr darum hier eine awareness zu schaffen warum das manchmal dumm ist und man sich wirklich wirklich viel Gedanken darüber machen sollte. Grundsätzlich - wer repliziert (Client oder Server) ist authorative - der hat die Hosen an! Hat der Client die Hosen an gibt das miest dem hacker/Cheater sofort ein grinsen aufs Gesicht da es genau das ist was ausgenutzt wird. Ürigens nicht mal immer absichtlich - viele Item dupes entstehen einfach durch lag und unüberlegtes replizieren der "ich sammel das gerade ein" action auf dem client. So einfache Konzepte daß ein Item intern immer einen unique identifier - wenn auch temporär - haben sollte gehören mit in solche Überlegungen um den Verbleib eindeutig zu gestalten.

Was ich an Replikation schwierig finde - ohne geht es nicht. Aber hier kann man die meisten Fehler machen. Unüberlegte Replikation ist des Multiplayers Tod. Ich kann nicht für jedes Spiel das perfekte Konzept bieten - das geht aus einem kurzen Artikel nicht, nicht mal aus einer 3 bändigen Bücherreihe. Aber ich schreie hier "achtung Falle" und wenn es nur ein paar Leute dazu bewegt sich damit auseinanderzusetzen und etwas zu googeln, andere Artikel zu lesen und kritisch über das Thema nachzudenken - dann hat dieser Artikel exakt den zweck erreicht den ich gewünscht habe.

Gerne kannst du deine Gedanken teilen. vertraulich per PM - oder auch hier. Ich bin manchmal zu direkt und kein guter DIplomat aber wer mich kennt nimmt nicht jeden Satz so ernst. Von daher kannst du auch offen immer mit mir diskutieren. Ich verspreche nicht mit jedem einer Meinugn zu sein und sag mal was dummes - aber das ist ja gut, wir sind ja alle Menschen und darum mag ich auch Foren. Ich freu mich auf deine Meinung.

Sorry aber das stimmt gar nicht. Wie ich schon in Punkt 2 beschrieben habe "das bestimmt ihr". Der programmierer legt fest wer was wohin replizieren kann.

Und natürlich verändert der Client stets den Zustand des Spiels - sonst wäre ernur Zuschauer (Gibts auch - "Spectator".

In einem einfachen Ballerspiel wird die Bewegung deines Spielers von deinem Client an den Server repliziert, dieser repliziert das zu allen clients. Klar gibt es da auch Ausnahmen - wir haben ja noch gar nicht über relevancy und priority gesprochen, auch nicht über "has authority", owner usw, aber lassen wir das der EInfachheit mal weg.

Wenn dein Spieler ein "Character" ist dann hat er die UE4 character movement component und die repliziert standardmäßig erst mal die Bewegung an den Sever (Und dieser an die Clients). Punkt. Das ist erst mal eine einfache replikation die fast jeder in UE4 schon mal in Multiplayer benutzt hat.

Jetzt gibt es wirklich viele Blueprints in denen du Variablen replizierst und erst mal ist das ziemlich sicher weil die allermeisten erst mal auf dem Server laufen. Klingt sicher. Falle? Hmmm...

RPC ist so eine klassische Falle.

Du wirst jetzt vielleicht schreien "RPC aufrufen ist NICHT replikation" und hast erst mal grundsätzlich recht - repliziert der RPC aber etwas ist es eine "indirekte replikation" und die sind genau so gefährlich.

Meist greift der Anfänger in Unwissenheit unnötig zum RPC um eine Aktion auf dem Server auszulösen - vermeintlich sicher da es ja der Server verwaltet - und bringt so schöne Ansatzpunkte für Cheater und Hacker. Oft fragt ein Anfänger sowas wie "Ich will dynamit legen und das wird nicht repliziert" und bekommt zur Antwort "Ja mach das sicher, musst du auf dem Server ausführen". Da liegt dann ein RPC nahe wenn man mal googelt wie man ne FUnktion auf dem Server aufruft. Replizieren ist ja dann einfach. Klassiker ist sowas wie: Ich mach ne Plausi Abfrage - hat der Spieler noch mehr als 0 Dynamit? Ja --> Leg ne Stange Dynamit ab. Ist die Plausi Abfrage nicht im RPC drin sondern der RPC ein doofer "Spawn dynamit an der Spieler Position" . Und schon hast du nen Hacker der unendlich Dynamit hat und eine Spur davon hinter sich herzieht.

Ehrlich bei Anfängern sind verdammt viele RPC unsicher da sie oft nicht Plausi Prüfungen beinhalten sondern nur die eigentliche Action. Und klar Hacker rufen RPC auf die normal nicht aufrufbar sein sollten.

Ganz schlimme Beispiele ist "replicated to server" und "switch authority remote", du glaubst nicht wie oft ich das schon gesehen habe bei so Dingern wie "use medipack" oder "pickup item".

Man darf Leute die sowas falsch machen nicht "dumm" nenen, da sind viele Dinge die du für gesunden Menschenverstand hälst aber das sind sie nicht weil es halt Programmierung ist. Du kannst nicht erwarten daß jemand der beim debugging/testen keine Probleme hatte darauf kommt daß etwas "unsicher" ist wenn er sich noch nie damit auseinandersetzen musste.

Das mit der 1200 DPI Maus war nur als Beispiel gedacht, Ziel ist es letztlich einfach Dinge festzustellen die ein Spieler nicht mit menschlichen Mitteln bewerkstelligen kann.

Das mit dem errechneten Wert bringt dir meiner Meinung nach nix weil der errechnete Wert - auch wenn du ihn nicht explizit in eine Variable schreibst - natürlich im Memory vorhanden ist und so an die entsprechende Funktion übergeben wird. Ja jemandem der dein Programm mit Assembler editieren will machst du es einen Hauch schwerer, aber Cheat engine wird das nicht jucken.

scue4 ist ein nettes Plugin das dir hilft Vollidioten abzuwehren die Cheat Engine runterladen und mal rumprobieren - aber gegen echte Cheater hilft es nichts.

Ich hab früher bei Maple Story gecheatet und die haben unsummen ausgegeben für Hack Shield was im Hintergrund lief. Das Ding hat Ressourcen gefressen, das Spiel langsamer gemacht und sauviel Geld gekostet und die mussten das permanent updaten. Aber klar die echten Cheater haben sich die Source von Cheat Engine genommen, das entsprechend umgeschrieben, Cheat Engine im Prozess eines anderen users (Admin) laufen lassen und Maplestory als Prozess eines unprivilegierten users. Da hat Maplestory mal gar nix von der Cheat Engine gesehen. Später gab es dann auch Packet editing auf Gateway ebene, also das einfach die gesendeten pakete an den Server entsprechend manipuliert wurden, damit konnte man dann sogar tolle Dinge machen die mit dem normalen Client gar nicht gehen, zum Beispiel Pakete schicken um nen User vom Server zu schmeissen usw.

Was ich sagen will - du kannst machen und treiben was du willst - auf dem Client selber - der wird von nem hacker verwendet und die machen alles möglich was du nicht willst. Wenn da nicht der Server "Die Hosen anhat" wird der vom Client nach Strich und Faden veräppelt. Hacking kannst du zu 100% nur am Server stoppen, am Client kannst du es bestenfalls etwas erschweren.

Wenn jemand den Server selber hostet dann kann er ihn auch selber manipulieren. Aber solange der Vanilla Server sicher ist und von jemandem gehostet wird der nicht hackt dann ist der schon mal auf der sicheren Seite.

Wegen Health und so - meist kannst du eh nicht nach "100" suchen weil da oft Fliesskomma Werte die gerundet sind verwendet werden oder es werden Nachkommastellen abgeschnitten usw. Bei Cheat Engine ist ja das tolle daß du auch nach geänderten Werten suchen kannst, dauert natürlich wesentlich länger, aber man kommt schon immer dahinter in welchen Variablen und Speicheradressen sich die Health (oder wasauchimmer) versteckt.