Tickless VS Dynamic Ticks

  • Harald besteht auf ein faires System, auch wenn der Ping sehr schlecht (>200 ms) ist. Ich finde das nicht so gut, denn jede Lösung um das zu kompensieren führt zu aufwändigeren APIs oder Logik für den Studierenden, die er implementieren muss. Somit geht der Charme eines tickfreien Systems verloren, dass z.B. im Vergleich zu jetzt den Studierenden von PreWait(), Wait() und Commit() befreien würde.


    Es gibt die folgenden Möglichkeiten:

    • Dynamische Ticks
      Es handelt sich praktisch um das System, wie bisher.
      Nachteil: Sehr komplex zu verstehen. Der langsamste Teilnehmer gibt die Geschwindigkeit vor, es muss sich aber nicht nur um Verzögerungen durch Netzwerklatenz handeln, sondern könnte sich auch um langsame Algorithmen handeln.
      Vorteil: Am Fairsten.
    • Ticklos
      Der Server generiert in festem Abstand Ticks. Z.B. 15 Ticks pro Sekunde. Diese Ticks werden aber nicht direkt an den Client gesendet, sondern der Client wird über Differenzen (Updates) informiert.
      Nachteil: Unfair bei hoher Latenz.
      Vorteil: Sehr einfach für Studenten zu implementieren.
    • StarCraft I hohe Latenz
      Der Server verhält sich so, wie StarCraft I, wenn es auf hohe Netzwerklatenz gestellt wird. Dabei werden alle Aktionen mit Latenz ausgeführt. Wenn wir z.B. von 15 internen Ticks pro Sekunde ausgehen würde der Connector bei sich im RAM vier Ticks vorhalten. Im Server werden vier weitere Ticks vorgehalten. Ein empfangener Befehl wird also 8 Ticks hinter dem aktuellen Live-Tick eingehängt. Zudem werden Netzwerk-Latenz und Co gemessen. Durch die ermittelte Netzwerk-Latenz wird dann der entsprechende Tick, den der Teilnehmer sehen müsste vom Connector zurück geliefert. Der Server ordnet auch entsprechend der gemessenen Latenz die empfangenen Befehle ein.
      Nachteil: Alle Anweisungen haben mehr als eine halbe Sekunde Latenz. Zudem kann dies mit einem modifizierten Connector "gehackt" werden, um die lokal zur Verfügung stehenden TIcks früher auszulesen oder um Zeitliche Informationen zu senden, die den Server veranlassen ein Kommando im neuesten Tick einzusortieren.
      Vorteil: Fair bei gleicher Spielgeschwindigkeit.

    Hat jemand noch eine Idee?

  • Ich bin generell für die Tickless Variante.


    Warum:

    - Ich glaube, dass die Variante motiviert besseren Code zu schreiben

    - Spaß der "alten Hasen" geht nicht kaputt wenn der Server (mal wieder) lagt

    - Der Code könnte auch einfacher zu verstehen sein, als die aktuelle Variante

  • Ich habe stark veränderliche Pings zwischen 60ms und 200ms. Bei Tickless-Betrieb kann ich damit keine zuverlässigen Aktionen ausführen.


    Ausregeln von Positionen wird dadurch schwer.


    Beim Schießen könnte man eventuell Kommandos "auf Termin" nehmen, also z.B. "Schieße bei Tick 74362 mit dem Schussvektor x"...

  • Ich finde Deine Internet-Situation extrem schrecklich.


    Und wenn man Dir eine VM zur Verfügung stellt, auf der Du dann arbeiten kannst?

    🤣 das löst sein Problem, jedoch nicht die allgemeine Situation😜. Grundsätzlich würde ich jedoch einen Ping von 60 - maximal 100 als normal bezeichnen.

    Jedoch ist der miserable Breitbandausbau (für Privatleute) in Deutschland ja allgemein bekannt.

    Grundsätzlich stehe ich dem tickbehaften System nicht so kritisch gegenüber. Jedoch sehe ich bei Netzwerkproblemen noch einen Vorteil beim ticketfreien Systen, da so Spielern eine größere Anzahl an verpassten Ticks erlaubt werden kann, und somit die Universen nciht mehr beschränkt sein müssen, darauf, dass der Anwender gerade einen schlechten Ping hat.
    Natürlich wird es dann schwieriger zu steuern, jedoch haut mich das Spiel nicht nach 1 sec raus, wenn ich mal für 3 sec einen höheren Ping habe.

  • Punkt 1:

    Wie wäre es mit einem fließenden Übergang? Der Server versucht nur eine gewisse Mindestanzahl von Ticks die Sekunde zu halten. Je nach Universumsgruppe ist dies dann anders (für den Einstieg geringer, in matches höher). Wer trotzdem zu langsam ist, dessen Anfrage "rutscht" in den nächsten Tick inkl einer Benachrichtigung "du hast x Ticks verpasst". Bei der Beurteilung von "langsam" könnte man auch zwischen Pingzeit und Verbreitungszeit der Clients unterscheiden und unterschiedlich tolerant reagieren (wobei man dies auch wieder Clientseitig zu seinen Gunsten manipulieren kann).

    Der Gedanke ist hierbei, dass bei manchen Universumsgruppen das total egal ist, wenn man im Gegensatz zu anderen Spielern hinterher hinkt (gerade am Anfang wenn man noch von daheim am Abend was macht, oder anderweitig Kleinigkeiten testet), die anderen aber nicht stören möchte ( dannyd ?). Bei Wettkämpfen oder speziellen PvP Universumsgruppen sind dann aber vermutlich alle vor Ort oder sich zumindest über den Wettkampf im klaren, weswegen auch eine bessere Reaktionszeit erwartet werden kann/langsame Reaktionen bestrafen möchte. Eine Toleranz für langsames Internet ist also je nach Universumsgruppen anders. Man könnte das dann auch je nach Universumsgruppen beliebig "scharf" stellen (was dann wieder wie tickless wirkt) ohne das man gleich gekickt wird, weil man (mal) zu langsam war.


    TLDR; Man setzt also einen Rahmen pro Universumsgruppe (einsehbar vor dem Betreten) und wer das nicht einhalten kann, verpasst ticks.


    Punkt 2:

    Die Komplexität der Implementierung mit PreWait(), Wait() und Commit() könnte man durch ein Callback-Interface auf Clientseite reduzieren/verstecken (bedingt aber Entkopplung durch Events, u.a. beim Scannen oder schießen). In etwa:


    Für den Einstieg reicht es alles in onTick() zu schreiben und die ganze Synchronisation zu ignorieren. Wer dann seine Reaktionszeiten verbessern möchte kann zusätzlich onPreWait() implementieren und letztendlich seine Aktionen in onTick parallelisieren.

  • Durch ein anderes Interface wird die Komplexität nicht genommen. Zudem gibt 's weitere Fragen: Wait auch ausführen, wenn die Ausführung von PreWait noch nicht fertig ist? Jede Methode pro Controllable oder nach was soll das gehen?


    Deutliche komplexitätsreduzierung geht nur durch entfernen von PreWait, Wait und Commit.


    Ich bin immer noch für statische Ticks. z.B. 15 pro Sekunde. Wenn dann muss das Spiel-Design so sein, dass das verpassen von 1-2 Ticks nicht so ins Gewicht fällt.