Zum Inhalt springen
  • 0

Multiplayer: Serverside oder Clientside Berechnung


 Teilen

Frage

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

5 Antworten auf diese Frage

Empfohlene Beiträge

  • 1

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. 

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0

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

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0

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

Link zu diesem Kommentar
Auf anderen Seiten teilen

Gast
Diese Frage beantworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

 Teilen

Fachinformatiker.de, 2021 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung