Multiplayer: Serverside oder Clientside Berechnung

[Alaric]

Ich bräuchte mal eure Einschätzung / Überlegungen:

Hobby-mäßig bastle ich oft an kleinen Spielen.
Nun stehe ich vor einer Frage die ich mir selbst nicht richtig beantworten kann:

Es geht um ein Multiplayerspiel - Strategie. Der Spieler kann also Agents auf einer Karte steuern.

Thema: Pathfinding.

Was macht mehr Sinn? Die Berechnung der Wege auf dem Server laufen zu lassen oder Clientseitig?

Auf dem Server könnte dann relativ hoher Aufwand erzeugt werden, gerade wenn 4 Spieler gleichzeitig a 200 Einheiten auf einer großen Karte durch die Gegend schicken. Natürlich kann man über Gruppenberechnungen etc optimieren aber dennoch bleibt da ein realtiv hoher workload auf dem server. So wäre die Berechnung aber auch steuerbar, sprich die Anfragen könnten gebuffert werden und nacheinander abgearbeitet werden.

Würde ich das Clientseitig machen, sprich ich teile nur mit Einheit A von Spieler B möchte nach Position C, würde das die Workload auf jeden Client schmeißen, aber der netcode wäre schlanker.

 

Wie würdet ihr dabei vorgehen? Ich hoffe ich konnte halbwegs formulieren, worum es mir geht.

[el_pollo_diablo]

Es kommt komplett auf das Spiel, dessen Genre und das Gameplay an.

Was Netzwerkprogrammierung im Bezug auf Spiele angeht, führt fast kein Weg an Glenn Fiedler und seiner Seite https://gafferongames.com/ vorbei. Dort wird mehr als anschaulich gezeigt, wie und vorallem warum man den Networkingpart umsetzen sollte und wie nicht. Auch die richtige Implementierung der Gameloop ist mehr als hilfreich.

Die von @Whiz-zarD angesprochene "Snapshot-Interpolation" kommt überwiegend in First-Person-Shootern zum Einsatz. Was die meisten Titel jedoch gemeinsam haben ist die Tatsache, dass mit der Grundlage UDP große Teile der TCP-Funktionsweise nachgebaut werden und zwar unter der Berücksichtigung von Spiel-Charakteristika und dem Ausnutzen von Spielmechanik zur Vermeidung von Verzögerungen und Komprimierung.

Im Bezug auf Pathfinding wird man früher oder später bei Recast & Detour ( https://github.com/recastnavigation/recastnavigation ) landen. Diese einfach zu integrierende und vorallem kostenfreie Library kommt auch in sehr vielen kommerziellen Titeln zum Einsatz.

Hier sollte man sich nicht von der von @lessbess angesprochenen "mächtigen Serverhardware" verunsichern lassen, denn außerhalb von großen MMO-Titeln ist das relativ vernachlässigbar. Generell sollte man jedoch niemals nur den Clients vertrauen und natürlich, wie auch bei allen Anwendungen auch, Plausibilitätsprüfungen durchführen und entsprechendend reagieren.

Für das angesprochene Gruppenverhalten, welches auch als "Flocking" bezeichnet wird, lege ich jedem interessierten Leser das Buch "Programming Game AI By Example" ( https://www.amazon.de/Programming-Example-Wordware-Developers-Library/dp/1556220782/ref=asc_df_1556220782 ) von Mat Buckland ans Herz.

Der Nachfolger des Buches geht dann ziemlich stark in die Thematik neuronale Netze und ähnliche Themen, welche zwar generell interessant, für die meisten Spielarten jedoch viel zu aufwendig sind. 

[Whiz-zarD]

Beispiel Source Engine:

Bei der Source Engine werden die Benutzereingaben an den Server geschickt und der Server simuliert die Welt und macht, je nach spielart, in einem bestimmten Takt Snapshots der Objekte und schickt diese Snapshots an die Clients. Auf den Clients wird also nicht der Pfad berechnet, weil dies Cheating ermöglicht, denn man könnte ja ein Pfad direkt durch eine Wand schicken. Die Benutzereingaben werden auch nicht einzeln zum Server geschickt, sondern als Paket im selben Takt, wie die Snapshot-Erstellung. Im Paket können also auch mehrere Benutzereingaben stecken.

Um den Traffic zu minimieren, wird auch keine TCP-Verbindung aufgebaut, sondern es werden UDP-Pakete verschickt. Außerdem wird auch nicht der gesamte Snapshot zum Client geschickt, sondern nur ein Delta. D.h. der Server kennt den Zustand der Clients und schickt den Clients nur die Änderungen. Also muss dann nur zum Anfang ein vollständiger Snapshot an die Clients geschickt werden und dann sind die Daten kleiner. Ähnlich wie bei einer Videokompression.

Da die Clients nur in bestimmten Abständen ein Snapshot bekommen und das Bild dadurch zu stottern beginnen könnte, wird zwischen zwei Snapshots interpoliert. D.h. die Animation zwischen zwei Snapshots wird auf den Client gerendert.

Also ja, dies benötigt eine hohe CPU-Last aber im Gegenzug wird ja auch nicht Audio und Video auf dem Server gerendert.

Weitere Informationen findest du hier: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

[lessbess]

Das ist eine Designentscheidung, die du selbst treffen musst. Grundsätzlich sind beide Ansätze machbar. Traditionell wird gerade bei Strategiespielen sicherlich die Clientvariante bevorzugt und es wird versucht so wenig wie möglich an den Server zu übertragen, um Latenzen möglichst gering zu halten und die Last eher auf den Clients zu lassen.

Gerade mit den Möglichkeiten der großen Rechenleistung und Skalierbarkeit in Clouds u.ä. hat der andere Ansatz aber auch durchaus seine Reize. Du könntest dann versuchen den Client quasi nur zur Darstellung und Benutzereingabe zu nutzen und alles andere auf dem Server zu machen ähnlich wie Stadia.

Für kleine Hobbyprojekte ist denke ich aber die erste Variante die bessere Wahl, da du erst mal keine mächtige Serverhardware brauchst und bessere Möglichkeiten für Offlinetests und ähnliches hast.

[Bitschnipser]

Nachteil, wenn ich Pathfinding am Client mache: Ist mein Rechner langsam, sind meien Einheiten langsam, also habe ich spielerische Nachteile?

Thema Latenzen: Wenn die Clients ihre Einheiten berechnen, müssen die Ergebnisse vom Spieler A erst zum Server und dann zum Spieler B geschickt werden => noch höhere Latenz

[afo]

Du kannst auch mal ein wenig beim IT Hare nachlesen: http://ithare.com/

Der stelt auch viele der Themen gut aufbereitet dar.