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...

  • Klasse Text, Cheating ist echt eine nervige Sache. Macht jedes Spiel Kaputt..


    Beim Entwickeln eines Spieles muss ein Klar sein das es Doppelte Arbeit macht wenn es ein Multiplayer Spiel werden soll. Ich habe auch oft gezweifelt ob ich es überhaupt schaffe. Ich habe biss heute mein Spiel weiter entwickelt wobei ich oft an meine Grenzen gerate.


    Ich muss auch sagen, hätte ich es eher gewusst was auf mich zukommt hätte ich lieber ein Singleplayer Spiel erstellt.

  • 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.

  • Was du hier beschreibst ist nicht "Replication". Du beschreibst hier "Authorative Server/Client Networking".


    Im Grunde ist das was du schreibst aber schon richtig, die Terminologie nur nicht so ganz ...

    Auch ist es nicht die Lösung gegen Cheats, sondern nur die Lösung gegen die einfachsten Cheats. Trotzdem sehr wichtig, da man im Kampf gegen cheater nicht alle cheats verhindern kann, aber man kann es denen schwer machen und dies ist ein Schritt in die Richtung. Den nächsten Schritt hast du ja sogar schon erklärt, das wäre die Validierung/Plausibilisierung der Inputs, wenn sie den Server erreichen. Auch das deckt noch nicht alles ab, ich weiß auch nicht wie sehr das ein Anti-Cheat Artikel werden soll, denn danach geht es über Authorative Server/Client hinaus.


    Auch kommt dieser Ansatz mit seinen eigenen Problemen, die man unbedingt aufnehmen sollte und die Lösungsansätze dazu (z.B. diverse Lag Compensation Techniken).



    Ansonsten vielleicht mal die Struktur überdenken. Ich könnte ein paar detailliertere Kritkpunkte dahingehend geben, aber das sprengt den Thread. Ist es überhaupt erwünscht? Falls ja schicke ich dir eine PM.

    Trotzdem danke für die Mühe, mit etwas mehr Recherche, Quellen, besserer Form kann das ein hilfreicher Artikel oder eine Artikelreihe werden.

  • 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.

  • 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".

    Nicht wirklich. Der Client (bzw. in UE4 streng genommen sogar nur der Owner eines Objektes) kann ja in dem Konzept nur indirekt eine Eigenschaft/Zustand übertragen über einen Funktionsaufruf, und ob dieser Ausgeführt wird. Dann wird ja auf dem Server der Wert gesetzt, falls dieser es für i.O. hält.

    Client: "Hallo Server, kannst du den Wert auf X setzen?" (Aufruf der Relicated Function)

    Server: "Ich habe alles überprüft. Geht klar." oder "Nein" bis hin zu "Nix da! Tschüss du Cheater!" (Validation und Implementation der Replicated Function)


    Ein Client kann Anfragen senden, er könnte temporär lokal etwas verändern, aber der hat keinen direkten zugriff auf den "wahren" Zustand des Spiels.

  • 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.