Game-Backend-Scope: Was Sie vor einer Aufwandsschätzung klären sollten

Warum Backend-Schätzungen danebenliegen

„Was würde ein Backend für unser Spiel kosten?“ ist eine berechtigte Frage, auf die es keine ehrliche Antwort gibt, solange einige Punkte nicht schriftlich festgehalten sind. Zwei Studios können dieselben Begriffe verwenden – Lobby, Accounts, dedizierte Server, LiveOps – und Projekte meinen, die sich im Aufwand und in den monatlichen Infrastrukturkosten um eine Größenordnung unterscheiden.

Eine Schätzung wird irreführend, wenn sie Lücken stillschweigend mit Annahmen füllt. Geht aus dem Briefing nicht hervor, wer die Server nach dem Launch betreibt, kalkuliert ein Anbieter eine Übergabe und ein anderer ein Jahr Support. Werden Spieler pro Match und gleichzeitige Nutzer nicht getrennt, dimensioniert ein Angebot einen einzelnen Serverprozess und ein anderes eine ganze Flotte. Beide Zahlen wirken präzise, keine beschreibt Ihr Projekt.

Dieser Artikel geht die Informationen durch, die eine Game-Backend-Schätzung am häufigsten verändern – in der Reihenfolge, in der sie sich unserer Erfahrung nach am leichtesten festlegen lassen. Am Ende finden Sie eine ausfüllbare Briefing-Tabelle und eine kurze Checkliste, die Sie durchgehen sollten, bevor Sie etwas an einen Partner schicken – auch an uns.

Wenn das Netzwerkmodell selbst noch offen ist (Authority, dedizierte oder Listen-Server, Prediction), beginnen Sie mit der Frage, wie man eine Multiplayer-Architektur plant. Der Backend-Scope hängt von diesen Entscheidungen ab.

1. Beschreiben Sie das Spiel und den Weg der Spieler

Beginnen Sie bei den Spielern, nicht bei der Technologie. Halten Sie Schritt für Schritt fest, was ein Spieler vom Start des Spiels bis zum Ende einer Session tut:

• Meldet er sich an oder spielt er anonym?
• Tritt er Freunden in einer Party bei, wählt er aus einer Serverliste oder drückt er nur auf „Spielen“?
• Wie lange dauert eine typische Session oder ein Match, und was passiert danach?
• Was muss beim nächsten Start des Spiels noch vorhanden sein?
• Was geschieht, wenn die Verbindung mitten im Match abbricht?

Dieser Ablauf ist der wertvollste Input für einen Backend-Entwickler, denn jeder Schritt braucht entweder einen Service – oder bewusst keinen. Ein Koop-Spiel, in dem vier Freunde gegenseitig ihren Sessions beitreten, führt Spieler auf einem ganz anderen Weg ins Match als ein kompetitiver Shooter, der Fremde nach Skill und Region zusammenbringt. Der aufgeschriebene Ablauf macht außerdem Fehlerzustände sichtbar – volle Server, Versionskonflikte, abgebrochene Verbindungen –, die ein definiertes Verhalten und damit Aufwand erfordern.

2. Ziehen Sie die Grenze zwischen Echtzeitserver und Backend

Online-Spiele bestehen meist aus mehreren Schichten: dem Spielclient, einem Echtzeit-Gameserver, der das Match simuliert, Anwendungsservices für Sessions, Spieler und persistente Daten, einer Datenbank sowie dem Monitoring, das dem Betrieb zeigt, was passiert. Die Schätzung hängt stark davon ab, wo Sie die Grenzen zwischen diesen Schichten ziehen.

Hilfreiche Fragen:

• Welcher Zustand ist innerhalb des Matches autoritativ und existiert nur, solange das Match läuft?
• Welche Daten müssen das Match überdauern, und wer schreibt sie – der Gameserver, der Client oder ein Service?
• Gibt es überhaupt einen dedizierten Server, oder hostet ein Spieler bzw. ein Relay die Session?
• Wer verantwortet derzeit den Echtzeit-Netcode, und gehört er zum Scope?

Eine häufige Quelle für Überraschungen ist es, „das Backend“ als eine einzige Sache zu behandeln. Netcode-Arbeit innerhalb des Matches (Authority, Prediction, Replikation) und Services rund um das Match (Sessions, Deployment, Persistenz, Monitoring) erfordern unterschiedliche Kompetenzen und werden am besten getrennt geschätzt – auch wenn ein Partner beides übernimmt.

3. Listen Sie die Services auf, die Sie wirklich brauchen

Erstellen Sie eine einfache Liste der benötigten Services und markieren Sie jeden als zum Launch nötig, später nötig oder nicht nötig. Typische Kandidaten:

• Session-Erstellung, Lobbys, Partys und Serverallokation
• Build, Containerisierung und Deployment des dedizierten Servers
• Versionierte Verträge zwischen Client und Backend
• Spieler-Accounts und Authentifizierung
• Progression, Inventar und In-Game-Ökonomie
• Analytics und LiveOps-Tools
• Monitoring, Logs, Alerts und Incident-Runbooks

Notieren Sie bei jedem Punkt, ob Sie einen bestehenden Plattform-Service erwarten oder einen individuellen Service für nötig halten. Die Integration eines bewährten Plattform-Services ist meist kleiner und günstiger im Betrieb als ein Neubau, die Wahl hängt aber von Session-Modell, Daten und Kostenrahmen ab – ein Assessment kann das vor der Implementierungsschätzung klären.

Seien Sie bei Accounts, Progression, Ökonomie und LiveOps besonders konkret. Diese Bereiche bringen Verantwortung für Sicherheit, Datenschutz und Balancing mit sich, und ihr Umfang schwankt stärker als jeder andere Teil eines Backends. Ein einzeiliges „Wir brauchen eine Ökonomie“ kann einen Währungszähler bedeuten oder einen vollständigen Katalog mit Käufen, Gutschriften, Rollbacks und Betrugsabwehr. Behandeln Sie jeden dieser Bereiche als eigenen Scope-Punkt, nicht als Häkchen.

4. Persistenz und Datenmodell

Alles, was eine Session überdauern muss, braucht einen Ort, einen Eigentümer und einen Lebenszyklus. Vor einer Schätzung muss ein Partner wissen:

• Was gespeichert wird: Profil, Freischaltungen, Inventar, Match-Ergebnisse, Einstellungen, nutzergenerierte Inhalte.
• Wer schreibt: ein vertrauenswürdiger Gameserver, ein Backend-Service oder der Client (günstiger zu bauen, aber deutlich schwerer abzusichern).
• Wie oft: einmal am Ende des Matches, bei jedem aufgesammelten Gegenstand oder kontinuierlich.
• Was niemals verloren gehen oder doppelt entstehen darf, zum Beispiel gekaufte Gegenstände.
• Personenbezogene Daten: was Sie erheben, wo die Daten gespeichert werden dürfen und wie Sie Löschanfragen bearbeiten.
• Migration: Gibt es bestehende Spielerdaten, die übernommen oder kompatibel gehalten werden müssen?

Schreibhäufigkeit und Vertrauen sind die beiden Antworten, die die Schätzung am stärksten verändern. Daten, die ein Server am Ende eines Matches schreibt, sind eine überschaubare Anforderung; Daten, die der Client jederzeit ändern kann, erfordern Validierung, Konfliktbehandlung und einen Audit-Trail.

5. Externe Integrationen

Jedes externe System bringt Aufwand mit sich, der leicht unterschätzt wird: Dokumentation lesen, seine Fehlerfälle behandeln, gegen seine Sandbox testen und mit seinen Änderungen Schritt halten. Listen Sie jede Integration mit ihrem Zweck auf:

• Plattform- und Store-Services (Identität, Freunde, Berechtigungen)
• Bestehende Backend-Plattformen oder Game-Services, für die Sie bereits bezahlen
• Hosting-Anbieter und Server-Orchestrierung
• Tools für Zahlungen, Analytics, Crash-Reporting, Kundensupport oder Anti-Cheat
• Ihre eigenen bestehenden Services, falls vorhanden

Kennzeichnen Sie, was bereits entschieden und was noch offen ist. „Für Sessions nutzen wir bereits Service X“ spart Konzeptarbeit, bringt aber Integrationsvorgaben mit; „Wir haben noch keinen Hoster gewählt“ fügt einen Evaluierungsschritt hinzu.

6. Lastannahmen: Spieler pro Session, CCU und Request-Last

Hier vermischen Schätzungen am häufigsten drei verschiedene Zahlen. Jede treibt einen anderen Teil der Kosten, deshalb sollten Sie sie getrennt angeben – als Spannen und Szenarien, nicht als Einzelwerte.

Spieler pro Session ist die Zahl der Spieler, die sich ein Match oder einen Raum teilen. Sie bestimmt die Kosten der Echtzeitsimulation: CPU und Speicher pro Serverprozess, Bandbreite pro Match und wie viel Optimierung der Netcode braucht. Sie ist überwiegend eine Designentscheidung. Bei Bad Goons, unserem eigenen Multiplayer-Shooter in Entwicklung, sind 64 Spieler ein Designziel: Es prägt die Architektur, ist aber keine gemessene Kapazität.

Gleichzeitige Nutzer (CCU) ist die Zahl der Spieler, die zum selben Zeitpunkt im gesamten Spiel online sind. Zusammen mit den Spielern pro Session bestimmt sie, wie viele Serverprozesse parallel laufen müssen – und damit Hosting-Kosten, Allokationslogik, Skalierungsregeln und wie schnell die Flotte auf Spitzen reagieren muss. Sie ist eine Marktannahme und meist die unsicherste Zahl im Briefing.

Backend-Request-Last ist die Zahl der Aufrufe, die Clients und Gameserver an Backend-Services richten, und wie sich diese Aufrufe ballen. Sie hängt vom Ablauf ab, nicht nur von der CCU: Logins zur Hauptzeit, Matchmaking-Anfragen, Schreibvorgänge am Match-Ende, Inventar-Updates, Reconnect-Wellen nach einem Ausfall. Sie bestimmt Service- und Datenbankkapazität, Rate Limits und Caching.

Veranschaulichendes Beispiel (keine Projektreferenz): Zwei Spiele mit ähnlicher erwarteter CCU können sehr unterschiedliche Backends haben. Im ersten verbringen Spieler lange Sessions in kleinen Koop-Räumen, und das Backend wird hauptsächlich zu Beginn und am Ende einer Session aufgerufen. Im zweiten enden kurze kompetitive Matches gleichzeitig auf vielen Servern, und jedes schreibt Ergebnisse und Inventaränderungen. Das zweite Spiel belastet Services und Datenbank weit stärker, obwohl die CCU gleich aussieht.

Legen Sie auch fest, was Sie von Lasttests erwarten. Ein Partner sollte Lastszenarien für Ihr Spiel definieren, sie messen und Ergebnisse sowie Grenzen berichten – statt eine Zahl gleichzeitiger Spieler zu versprechen, die nie getestet wurde.

7. Verfügbarkeit und Erwartungen im Fehlerfall

„Es muss immer laufen“ ist keine Anforderung, die sich schätzen lässt. Werden Sie konkreter:

• Welche Regionen müssen bedient werden, und ist die Latenz dort spielrelevant?
• Ist ein Wartungsfenster akzeptabel, und wie werden neue Versionen ausgerollt, während Matches laufen?
• Was sollen Spieler erleben, wenn ein Service ausfällt – eine Fehlermeldung, eine Warteschlange, Offline-Spiel?
• Wie schnell und zu welchen Zeiten muss jemand auf einen Incident reagieren?
• Gibt es einen Launch, einen Playtest oder ein Event mit festem Termin?

Jede höhere Verfügbarkeitsstufe bringt Redundanz, Tests und Betriebsprozesse mit sich. Die Antworten zeigen einem Partner außerdem, ob Graceful Shutdown, Versions-Rollout und Rollback ein Nice-to-have oder eine Launch-Voraussetzung sind.

8. Übergabe und Betrieb

Das Backend endet nicht, wenn der Code funktioniert. Jemand muss es deployen, beobachten und auf Probleme reagieren. Legen Sie fest:

• Wem Hosting- und Cloud-Accounts, Abrechnung und Spielerdaten gehören (in der Regel Ihnen als Auftraggeber).
• Wer die Services nach der Lieferung betreibt – Ihr Team, der Partner im Rahmen einer separaten Support-Vereinbarung oder eine Kombination.
• Welche Dokumentation Ihr Team erwartet: Architektur und Verträge, Deployment-Schritte, Runbooks für häufige Incidents, bekannte Grenzen, Kostentreiber der Infrastruktur.
• Welche Kenntnisse Ihr Team bereits hat, etwa Linux, Container oder den gewählten Cloud-Anbieter.

Wenn laufender Support erwartet wird, gehören Umfang und Reaktionszeiten ins Briefing. Sonst enthält eine Schätzung ihn stillschweigend und eine andere nicht. Was eine vollständige Serverübergabe umfasst, beschreibt unsere Übergabe-Checkliste für dedizierte Server.

Wie wir an diese Fragen herangehen

Unsere dokumentierte Produktionsarbeit ist in den Teilen des Backends am stärksten, die dem Match am nächsten liegen: Session- und Lobby-Integration, Deployment dedizierter Server, Client-Backend-Verträge, Monitoring und Übergabe. Bad Goons betreibt Unity-Headless-Builds auf autoritativen Linux-Servern mit containerisiertem Deployment, und diese Disziplin – reproduzierbare Builds, Health Checks, Logs, sicherer Versions-Rollout – prägt die obigen Fragen. Unser CTO hat außerdem in seiner früheren Rolle bei VR Storm Studio das Photon-basierte Multiplayer-Backend für den nach dem Release hinzugefügten Koop-Modus von Bean stalker entwickelt.

Accounts, Progression, Ökonomie und LiveOps scopen und bewerten wir projektbezogen – beginnend mit der Frage, ob ein bestehender Plattform-Service passt. Sind zentrale Annahmen noch offen, ist ein abgegrenztes Assessment meist der ehrlichere erste Schritt als eine vollständige Implementierungsschätzung. Was das umfasst, sehen Sie auf unserer Seite zur Game-Backend-Entwicklung.

Vorlage für Ihr Backend-Briefing

Übernehmen Sie diese Tabelle in Ihr eigenes Dokument und beantworten Sie, was Sie können. „Unbekannt“ ist eine gültige Antwort – sie zeigt einem Partner, wo ein Assessment nötig ist.

Checkliste vor der Schätzung

Bevor Sie ein Backend-Briefing an einen Partner schicken, prüfen Sie, ob es Folgendes enthält:

• Den Weg des Spielers vom Start bis zum Ende einer Session, einschließlich Verbindungsabbrüchen und Fehlern.
• Die Grenze zwischen Echtzeit-Gameserver und Backend-Services sowie die Verantwortung für den Netcode.
• Eine Liste der Services mit der Markierung Launch / später / nicht nötig – Accounts, Progression, Ökonomie und LiveOps jeweils einzeln beschrieben.
• Was persistiert wird, wer es schreibt, wie oft und welche personenbezogenen Daten betroffen sind.
• Jede externe Integration, gekennzeichnet als entschieden oder offen.
• Spieler pro Session, CCU und Backend-Request-Last getrennt, als Spannen oder Szenarien.
• Verfügbarkeitserwartungen: Regionen, Wartung, Rollout und Verhalten im Fehlerfall.
• Eigentum an Accounts und Daten, den Betrieb nach der Lieferung und die erwartete Übergabe.
• Feste Termine, den bestehenden Stack und einen Budgetrahmen.

Wenn mehrere Antworten noch „unbekannt“ lauten, sagen Sie es offen. Ein Partner, der ein kurzes Assessment vorschlägt, um diese Lücken zu schließen, liefert Ihnen eine brauchbarere Zahl als einer, der trotzdem das gesamte Projekt beziffert. Wenn Ihr Briefing fertig ist, können Sie es uns senden.