Multiplayer-Spiel planen: Was gehört zu Client, Server, Backend und Betrieb?

Warum „Multiplayer einbauen“ keine einzelne Aufgabe ist

Wenn ein Studio nach Multiplayer fragt, klingt das zunächst nach einem einzelnen Feature. In der Praxis sind es mehrere getrennte Verantwortungsbereiche, die an unterschiedlichen Orten laufen, auf unterschiedliche Weise ausfallen und oft unterschiedliche Verantwortliche haben:

• der Game Client auf dem Rechner des Spielers;
• der Echtzeit-Gameserver, der das Match ausführt;
• das Anwendungs-Backend, das alles rund um das Match abwickelt;
• der Betrieb: Build, Deployment, Überwachung und Aktualisierung all dessen.

Die meisten Scope-Überraschungen in Online-Projekten entstehen nicht in den Bereichen selbst, sondern in den Lücken dazwischen. Niemand hat entschieden, ob der Server oder der Client einen Treffer prüft, wer beim Matchstart einen Server zuweist oder was mit einem laufenden Match passiert, wenn ein neuer Build erscheint. Dieser Artikel geht die vier Bereiche nacheinander durch, gibt Ihnen eine Verantwortungsmatrix für Ihre eigene Planung an die Hand und endet mit den Entscheidungen, die Sie klären sollten, bevor Sie ein Angebot anfragen.

Der Game Client: Eingabe, Darstellung und Feedback

Der Client sorgt dafür, dass sich das Spiel für einen Spieler unmittelbar anfühlt. Er liest Eingaben, rendert die Welt, spielt Audio und Effekte ab und zeigt dem Spieler, was passiert. In einem Online-Spiel sendet er zusätzlich die Absichten des Spielers an den Server und setzt dessen Updates wieder zu einem flüssigen Bild zusammen.

Was der Client nicht sein sollte: die letzte Instanz für alles, was andere Spieler betrifft. Schaden, Punktestände, Inventaränderungen und Matchergebnisse lassen sich auf einem Rechner, den Sie nicht kontrollieren, leicht manipulieren. Die übliche Regel lautet: Der Client schlägt vor, der Server entscheidet.

Die wichtigste Ausnahme ist Prediction, und sie sollte eine bewusste Entscheidung sein, kein Standard. In schnellen Actionspielen wirkt es träge, vor jeder Bewegung der eigenen Figur oder jedem Schuss auf die Antwort des Servers zu warten. Der Client simuliert diese Aktionen deshalb lokal und korrigiert sich, sobald das autoritative Ergebnis eintrifft. Dieser Korrekturschritt, die Reconciliation, ist ein großer Teil der Netcode-Komplexität. Ein langsameres rundenbasiertes oder kooperatives Spiel braucht unter Umständen gar keine Prediction. Als Referenzpunkt: Bei VOXSYS, einem kompetitiven Mobile-VR-Shooter, den heutige Teammitglieder von Sourcegarden Studio in ihren früheren Rollen bei VR Storm Studio entwickelt haben, reduzierte ein Multiplayer-Framework mit clientseitiger Prediction die wahrgenommene Latenz im Kampf.

Typische Aufgaben des Clients:

• Eingaben erfassen und die Absichten des Spielers an den Server senden;
• Rendering, Audio, UI und unmittelbares Feedback;
• Prediction und Reconciliation für die Aktionen, die sich sofort anfühlen müssen;
• Interpolation anderer Spieler und Objekte zwischen Server-Updates;
• klarer Umgang mit Verbindungszuständen: Verbinden, Laden, Verbindung getrennt, Versionskonflikt.

Der Echtzeit-Gameserver: Autorität und Simulation

Der Echtzeit-Server besitzt die Wahrheit über das Match, solange es läuft. Er empfängt die Eingaben der Spieler, führt die Simulation aus, wendet die Spielregeln an und repliziert den resultierenden Zustand an alle verbundenen Clients.

Vier Fragen definieren diese Schicht:

• Autorität. Welches System entscheidet über welchen Zustand: Bewegung, Treffer, aufgenommene Gegenstände, Veränderungen der Welt? Die Autorität kann je System unterschiedlich sein und sollte für jedes System schriftlich festgehalten werden.
• Simulation. Was muss der Server selbst simulieren, und mit welcher Update-Rate? Ein Shooter mit Physik und veränderbarer Welt verlangt dem Server weit mehr ab als ein Kartenspiel.
• Replikation. Welcher Zustand geht an welche Clients, wie oft und mit welchem Budget? Bandbreiten- und Update-Budgets sind Designvorgaben, keine Implementierungsdetails.
• Regelvalidierung. Welche Client-Anfragen werden vor der Anwendung geprüft, und was passiert, wenn eine Prüfung fehlschlägt?

Eine typische Architekturentscheidung an dieser Stelle ist die Wahl zwischen Dedicated Server, Listen Server (ein Spieler hostet) und Relay. Dedicated Server bieten das klarste Autoritätsmodell und schützen die Fairness, bringen aber einen Server-Build, Hosting und Betriebsaufwand mit sich. Diese Abwägung sollte zu Beginn ausdrücklich getroffen werden, weil sie den Umfang aller anderen Bereiche verändert.

Das Anwendungs-Backend: nur, was das Produkt wirklich braucht

Das Backend umfasst die Dienste rund um das Match: wie ein Spieler in ein Spiel gelangt und was nach dessen Ende erhalten bleibt. Hier wächst der Scope gern unbemerkt. Beginnen Sie daher mit dem, was das Produkt tatsächlich braucht, nicht mit einer Liste von allem, was ein Online-Spiel haben könnte.

Bereiche, die ein Backend abdecken kann:

• Identität: ob Spieler überhaupt Accounts brauchen oder ob die Plattformidentität ausreicht.
• Session-Ablauf: Sessions finden oder erstellen, Partys oder Lobbys, Serverzuweisung sowie die Übergabe von Serveradresse und Verbindungsdaten an den Client.
• Persistenz: welche Daten ein Match überdauern müssen, etwa Fortschritt, Inventar, Einstellungen oder Matchergebnisse.
• Integrationen: Plattformdienste, Analytics oder externe Backend-Plattformen.

Jeder dieser Bereiche bringt eigene Pflichten bei Sicherheit, Datenschutz und Wartung mit sich. Wo ein bewährter Plattformdienst einen Teil des Ablaufs bereits abdeckt, ist die Integration meist günstiger als ein Neubau; eigene Dienste lohnen sich dort, wo das Spiel sie wirklich braucht. Ein Prototyp benötigt unter Umständen nicht mehr als die Möglichkeit, einen Server zu starten und sich mit ihm zu verbinden. Wenn Ihre wichtigste offene Frage ist, wie groß diese Schicht sein sollte, geht unser separater Leitfaden zum Backend-Scope vor dem Angebot tiefer darauf ein, und die Seite zur Game-Backend-Entwicklung beschreibt, wie wir diese Dienste angehen.

Betrieb: Deployment, Observability und Fehlerbehandlung

Ein Dedicated Server, der auf dem Rechner eines Entwicklers läuft, ist noch nichts, was ein Team betreiben kann. Der Betrieb ist die Arbeit, die jede andere Schicht reproduzierbar und sichtbar macht:

• Build und Deployment: ein automatisierter Server-Build, ein Container oder Image, Konfiguration pro Umgebung und ein wiederholbarer Weg, Server zu starten und zu stoppen.
• Observability: strukturierte Logs, Metriken und Health-Signale rund um Sessions, Serverprozesse und Service-Aufrufe, damit sich eine Spielermeldung auf eine Ursache zurückführen lässt.
• Versionskompatibilität: eine Regel, welche Client-Builds sich mit welchen Server-Builds verbinden dürfen, und ein Rollout-Prozess, der laufende Matches nicht beschädigt.
• Fehlerbehandlung: Graceful Shutdown, Reconnect, volle Server, abgestürzte Prozesse und fehlgeschlagene Service-Aufrufe, jeweils mit definiertem Verhalten.
• Kapazität und Kosten: dokumentierte Annahmen darüber, wie viele Matches ein Server hosten kann und was die Infrastrukturkosten treibt, gemessen statt geschätzt.

Der Betrieb lässt sich leicht aufschieben, weil der erste spielbare Build ihn nicht braucht. Gerade deshalb fehlt er am häufigsten in Angeboten.

Eine wiederverwendbare Verantwortungsmatrix

Die folgende Tabelle ist eine Ausgangsvorlage. Die Spalte für die Verantwortlichen nennt eine Rolle, keine Kopfzahl: In einem kleinen Team kann ein Entwickler mehrere Rollen übernehmen. Das ist in Ordnung, solange die Schnittstellen zwischen den Bereichen explizit bleiben.

Wenn Sie eine Zelle nicht ausfüllen können, ist genau das meist der erste Klärungspunkt, nicht etwas für später.

Dieselbe Architektur als Ablauf

Der Reihe nach gelesen, greifen die Bereiche so ineinander:

1. Der Spieler startet den Client. Falls das Spiel es erfordert, identifiziert der Client den Spieler über das Backend oder die Plattform.
2. Der Client fragt beim Backend eine Session an. Das Backend findet oder reserviert einen Gameserver und gibt dessen Adresse und Verbindungsdaten zurück.
3. Der Client verbindet sich mit dem Gameserver, der vor der Aufnahme des Spielers die Versionskompatibilität prüft.
4. Während des Matches sendet der Client Eingaben, der Server simuliert und validiert sie und repliziert den Zustand zurück. Der Client sagt nur vorher, was vereinbart wurde.
5. Am Ende des Matches meldet der Server das Ergebnis an das Backend, das speichert, was erhalten bleiben muss.
6. Die ganze Zeit liefert jede Schicht Logs, Metriken und Health-Signale, auf die der Betrieb für Deployment, Monitoring und Updates zurückgreift.

Fragen, die das technische Design prägen

Die passende Architektur folgt aus einer Handvoll Produktentscheidungen. Es lohnt sich, sie vor dem ersten technischen Gespräch zu beantworten, auch wenn es nur näherungsweise ist:

Keine dieser Fragen braucht zum Start eine endgültige Antwort. Sie braucht aber eine ausgesprochene Annahme, denn ein Angebot ist nur so stabil wie die Annahmen, die daneben stehen.

Beispiel: Wie Bad Goons seine Systeme trennt

Bad Goons ist das aktuelle eigene IP von Sourcegarden Studio: ein teambasierter PC-Shooter auf einem Voxel-Schlachtfeld, das die Spieler während des Matches umgraben, zerstören und neu aufbauen. Das Spiel befindet sich in aktiver Entwicklung; die damit verbundenen 64 Spieler sind ein Designziel, keine gemessene Kapazität.

Seine Architektur behandelt die oben beschriebenen Bereiche als explizite Produktionssysteme:

• Client: ein Game Client in Unity 6.
• Echtzeit-Schicht: FishNet als Netzwerk-Framework, mit Prediction und Reconciliation.
• Simulation: eine Voxel-Simulation, deren Weltveränderungen mit jedem Spieler synchronisiert werden müssen – einer der Gründe, warum die Autorität auf dem Server liegt.
• Server: autoritative Dedicated Server, die Unity-Headless-Builds unter Linux ausführen.
• Betrieb: containerisiertes Deployment, bei dem Kapazität, Shutdown, Health, Logs und Versions-Rollout als spielrelevante Themen behandelt werden, weil das Verhalten der Infrastruktur laufende Matches direkt beeinflusst und darüber entscheidet, ob sich Spielermeldungen diagnostizieren lassen.

Es geht bei dem Beispiel nicht um den konkreten Stack. FishNet wurde für dieses Spiel gewählt; ein anderes Spiel, eine andere Plattform oder ein anderes Team kann ein anderes Framework rechtfertigen. Entscheidend ist, dass jede Grenze explizit ist, sodass Client, Server und Deployment getrennt gebaut, getestet und geändert werden können.

Checkliste für Auftraggeber: Was vor dem Angebot zu klären ist

Bringen Sie diese Antworten – oder Ihre derzeit besten Annahmen – in das erste Gespräch mit einem Multiplayer-Partner mit:

• Spielmodus und Session-Modell: Koop, kompetitiv oder persistent; Matchdauer; wie Spieler in ein Match gelangen.
• Spieler pro Session als Designziel und, falls vorhanden, eine erwartete Spanne gleichzeitiger Spieler.
• Autoritätsmodell: Dedicated Server, Listen Server oder Relay, und welche Aktionen der Server validieren muss.
• Prediction: Welche Spieleraktionen müssen sich sofort anfühlen, welche können auf den Server warten?
• Regionen und Latenzerwartungen Ihrer Zielgruppe.
• Plattformen und ob Crossplay erforderlich ist.
• Engine und bestehende Codebasis: Engine-Version, aktuelles Netzwerk-Framework und ob das Spiel von Anfang an für Multiplayer gebaut wurde.
• Backend-Bedarf: Identität, Sessions oder Lobbys, Persistenz, Integrationen und ein bereits genutzter Plattformdienst, falls vorhanden.
• Betriebsverantwortung: Wem gehören die Hosting-Konten, wer deployt, wer wird alarmiert, wenn ein Server ausfällt, und wird nach der Übergabe Support erwartet?
• Versionsregel: Wie müssen Client- und Serverversionen zusammenpassen, und wie erreichen Updates laufende Matches?
• Erwartungen an die Übergabe: Welche Dokumente, Builds und Runbooks braucht Ihr Team, um das Ergebnis zu übernehmen?
• Zeitplan, Meilensteine und Budgetrahmen, einschließlich dessen, was der erste Meilenstein beweisen muss.

Wenn mehrere dieser Punkte noch offen sind, ist ein fokussiertes Architektur-Assessment oder ein Risiko-Prototyp oft ein besserer erster Schritt als ein vollständiges Produktionsangebot. Solche Arbeit scopen wir im Rahmen unseres Angebots für Multiplayer Game Development.