Mobile Game Scaling Optimization: Architektur von Städten für über 1 Mio. Concurrent Player

Jeder Multiplayer-Entwickler kennt den Moment, in dem die Architektur seines Mobile Games unter der Last zusammenbricht. Man entwirft eine weitläufige, beeindruckende urbane Umgebung. Man testet sie lokal mit 10 simulierten Clients, und der Build läuft mit makellosen 60 FPS. Dann verschiebt man das Ganze in eine Live-Umgebung mit 1.000 Concurrent Playern, die sich auf dem zentralen Platz drängen. Innerhalb von Sekunden stürzen Low-End-Android-Geräte aufgrund von Out-Of-Memory (OOM) Exceptions ab, iOS Jetsam killt aggressiv die Applikation und die CPU-Last des Dedicated Servers schießt auf 100 %, während er versucht, die Network Replication für Tausende überlappender Entities zu berechnen.

Wenn man ein Mobile MMO oder ein groß angelegtes Open-World-Spiel entwickelt, das Millionen aktiver Nutzer unterstützen soll, kann man sich nicht auf die Standard-Defaults der Engines verlassen. Mobile Hardware unterliegt striktem Thermal Throttling und harten Memory Caps (was das Spiel auf Mid-Range-Geräten oft auf weniger als 2 GB nutzbaren RAM beschränkt). Gleichzeitig muss der Server dichte Player-Cluster verarbeiten, ohne in die Knie zu gehen.

Echte Mobile Game Scaling Optimization erfordert einen Drei-Säulen-Ansatz: aggressives Spatial Partitioning auf dem Server, rücksichtsloses Memory Management auf dem Client und eine Distributed Backend Architecture, um das enorme Verbindungsvolumen zu bewältigen. In diesem Step-by-Step Tutorial schlüsseln wir exakt auf, wie man Großstädte für mobile Plattformen architektonisch aufbaut.

Step 1: Server-Side Spatial Partitioning

Der fundamentale Feind der Server-Performance in Massive Multiplayer Games ist das O(N²)-Problem. Wenn der Server in einer Schleife jeden Spieler prüft, um dessen Distanz zu jedem anderen Spieler zu ermitteln (um festzustellen, wer Netzwerk-Updates benötigt), skaliert die Mathematik katastrophal. 100 Spieler erfordern 10.000 Distanzprüfungen pro Tick. 1.000 Spieler benötigen 1.000.000 Prüfungen. Bei einer Server-Tickrate von 30 Hz entspricht das 30 Millionen Prüfungen pro Sekunde.

Um dies zu lösen, müssen wir Spatial Hashing (oder ein Grid/Quadtree-System) implementieren. Durch die Aufteilung der Stadt in ein logisches Grid prüfen Spieler die Netzwerkrelevanz nur noch gegenüber Entities in ihrer aktuellen Zelle und den unmittelbar angrenzenden Zellen. Dies reduziert den O(N²)-Albtraum auf einen O(1) Grid-Lookup, gefolgt von einer stark eingeschränkten lokalen Prüfung.

Implementierung eines Spatial Hash Grids (C#-Beispiel)

Hier ist eine hocheffiziente Implementierung eines 2D Spatial Hash Grids in C#, die für Unity, Godot (via C#) oder einen benutzerdefinierten Backend-Server adaptiert werden kann, um Entity-Proximity zu verwalten, ohne den gesamten World State zu durchlaufen.

using System.Collections.Generic;
using UnityEngine;

public class SpatialHashGrid
{
    private readonly float _cellSize;
    private readonly Dictionary<Vector2Int, HashSet<uint>> _grid;

    public SpatialHashGrid(float cellSize = 50f)
    {
        _cellSize = cellSize;
        _grid = new Dictionary<Vector2Int, HashSet<uint>>();
    }

    // Convert a world position to a grid coordinate
    private Vector2Int GetCellCoordinate(Vector3 position)
    {
        return new Vector2Int(
            Mathf.FloorToInt(position.x / _cellSize),
            Mathf.FloorToInt(position.z / _cellSize)
        );
    }

    // Add or update a player's position in the grid
    public void UpdateEntityPosition(uint entityId, Vector3 oldPosition, Vector3 newPosition)
    {
        Vector2Int oldCell = GetCellCoordinate(oldPosition);
        Vector2Int newCell = GetCellCoordinate(newPosition);

        if (oldCell != newCell)
        {
            if (_grid.ContainsKey(oldCell))
            {
                _grid[oldCell].Remove(entityId);
            }
            
            if (!_grid.ContainsKey(newCell))
            {
                _grid[newCell] = new HashSet<uint>();
            }
            _grid[newCell].Add(entityId);
        }
    }

    // Retrieve all entities in the immediate vicinity (9 cells)
    public List<uint> GetEntitiesInProximity(Vector3 position)
    {
        List<uint> nearbyEntities = new List<uint>();
        Vector2Int centerCell = GetCellCoordinate(position);

        // Loop through the 3x3 grid around the player
        for (int x = -1; x <= 1; x++)
        {
            for (int y = -1; y <= 1; y++)
            {
                Vector2Int cellToCheck = new Vector2Int(centerCell.x + x, centerCell.y + y);
                if (_grid.TryGetValue(cellToCheck, out HashSet<uint> entitiesInCell))
                {
                    nearbyEntities.AddRange(entitiesInCell);
                }
            }
        }

        return nearbyEntities;
    }
}

Indem Sie Ihre Logik für die Network Replication über GetEntitiesInProximity routen, berechnet Ihr Server nur noch die exakten Distanzen für die wenigen Dutzend Spieler, die sich tatsächlich in der Nähe befinden. Dies reduziert die CPU-Last drastisch und ermöglicht es dem Server, Tausende von Concurrents in derselben Instanz mühelos zu verarbeiten.

Step 2: Network Interest Management

Selbst wenn Spatial Hashing den CPU-Bottleneck des Servers löst, bleibt das Problem der Bandbreite. Mobile Netzwerke (4G/5G) sind von Natur aus instabil, anfällig für hohen Jitter und unterliegen strikten Bandbreitenbeschränkungen. Das Senden von Daten für 50 nahegelegene Spieler in jedem Tick wird den Socket-Buffer des Mobile-Clients überfluten, was zu extremen Desyncs führt.

Interest Management (oder Network Relevancy) ist die Praxis, zu priorisieren, was über das Netzwerk gesendet wird. Ein Spieler in 2 Metern Entfernung, der in ein Feuergefecht verwickelt ist, benötigt 30 Updates pro Sekunde. Ein Spieler in 40 Metern Entfernung, der eine andere Straße entlangläuft, benötigt nur 2 Updates pro Sekunde.

Overriding Network Relevancy (Unreal Engine C++ Beispiel)

In Unreal Engine können Sie die Kontrolle übernehmen, indem Sie die Funktion IsNetRelevantFor überschreiben. Dies ermöglicht es Ihnen, den Netzwerkverkehr basierend auf Line-of-Sight und Distanz-Tiers aggressiv zu cull-en.

bool ACityPlayerCharacter::IsNetRelevantFor(const AActor* RealViewer, const AActor* ViewTarget, const FVector& SrcLocation) const
{
    // 1. Always relevant to ourselves
    if (RealViewer == this || ViewTarget == this)
    {
        return true;
    }

    // 2. Calculate squared distance (faster than exact distance)
    const float DistanceSquared = FVector::DistSquared(SrcLocation, GetActorLocation());

    // 3. Absolute Cull Distance (e.g., 10,000 units = 100 meters)
    const float MaxRelevancyDistSq = 100000000.0f; 
    if (DistanceSquared > MaxRelevancyDistSq)
    {
        return false;
    }

    // 4. Dynamic Network Update Frequency based on distance
    // If they are far away, we lower how often we send data
    if (DistanceSquared > 25000000.0f) // 50 meters
    {
        NetUpdateFrequency = 2.0f; // 2 updates a second
    }
    else
    {
        NetUpdateFrequency = 30.0f; // 30 updates a second
    }

    return Super::IsNetRelevantFor(RealViewer, ViewTarget, SrcLocation);
}

Durch die dynamische Skalierung Ihrer NetUpdateFrequency basierend auf der Distanz können Sie die Outbound-Bandbreite des Servers um bis zu 70 % reduzieren, was das Datenvolumen des Spielers schont und Latency-Spikes verhindert.

Step 3: Client-Side Memory Limits und Asset Streaming

Server haben reichlich RAM; Mobiltelefone nicht. Ein iPhone 13 verfügt über 4 GB Unified Memory. Das iOS-Betriebssystem reserviert davon typischerweise etwa 1,5 GB bis 2 GB. Ihr Spiel muss vollständig in den verbleibenden 2 GB Platz finden. Wenn Sie eine gesamte Großstadt auf einmal in den Speicher laden, wird das OS die Applikation sofort beenden.

Um in dieser Umgebung zu bestehen, muss Ihre Stadt in Chunks unterteilt und asynchron gestreamt werden.

• Hierarchical Level of Detail (HLODs): Anstatt 50 einzelne Gebäude in einem entfernten Stadtblock zu rendern (was 3.000 Draw Calls verursachen würde), müssen Sie diesen gesamten Block in ein einziges Static Mesh mit einem vereinheitlichten Texture Atlas baken. Dies reduziert die Draw Calls für entfernte Geometrie von Tausenden auf genau einen.
• Addressable Asset Systems: Verwenden Sie niemals Hard References in Ihren primären Data Assets. Wenn ein Spieler in Distrikt A spawnt, sollte der Client asynchrones Laden verwenden (z. B. Unitys Addressables oder Unreal Engine PrimaryAssetLabels), um nur die für Distrikt A benötigten Texturen und Meshes zu laden. Distrikt B muss konsequent aus dem RAM entfernt werden.
• Texture Compression: Verlassen Sie sich bei Mobile ausschließlich auf ASTC (Adaptive Scalable Texture Compression). Es ermöglicht hochvariable Block-Footprints und gibt Ihnen granulare Kontrolle über Memory vs. Visual Quality auf Texturebene.

Step 4: Distributed Backend Architecture und Server Sharding

Eine riesige Metropole kann nicht auf einer einzigen physischen Maschine laufen. Bei der Entwicklung einer Stadt im MMO-Maßstab muss die Welt physisch über mehrere Server-Instanzen (Shards oder Nodes) verteilt werden. Wenn ein Spieler eine Brücke vom Downtown-Node zum Slums-Node überquert, müssen seine Client-Verbindung und sein World State nahtlos zwischen zwei völlig unterschiedlichen Server-Prozessen übergeben werden.

Dies selbst zu bauen erfordert das Aufsetzen von Kubernetes-Clustern, die durch Systeme wie Agones orchestriert werden, Database Sharding mit Redis zur Übergabe des Spielerstatus zwischen Server-Nodes und benutzerdefinierte UDP Load Balancer für nahtlose Handoffs. Dies robust zu gestalten, damit Spieler während des Übergangs keine Items verlieren, ist ein massives Unterfangen – locker 4 bis 6 Monate dedizierte DevOps-Arbeit für ein Senior Engineering Team.

Wenn man die RPC-Queues und Datenbank-Writes während dieser Handoffs nicht korrekt handhabt, kommt es unweigerlich zu State Corruption. Wir haben bereits die Mechanik zur Behebung des Unreal Engine RPC Replication Issues behandelt, und genau dieselben Prinzipien gelten direkt für Spatial Handoffs zwischen Server-Nodes.

Hier glänzen Plattform-Lösungen. Mit horizOn sind diese High-Concurrency Backend-Services, Real-Time Database Syncs und Dedicated Server Orchestrations vorkonfiguriert. Anstatt Ihr Budget für die Architektur und das Debugging von Kubernetes-Netzwerkregeln aufzuwenden, können Sie sich voll und ganz auf die Gameplay-Loops Ihrer Stadt und die Client-Optimierungen konzentrieren.

Best Practices für Mobile City Worldbuilding

Um sicherzustellen, dass Ihre Stadt reibungslos für Millionen von Nutzern skaliert und gleichzeitig hohe Frameraten auf Budget-Geräten beibehält, halten Sie sich strikt an diese Architekturregeln:

1. Aggressive Instance Pooling: Verwenden Sie niemals Instantiate() oder SpawnActor für transiente Objekte wie Fahrzeuge, Fußgänger oder Projektile während des Gameplays. Mobile CPUs kämpfen schwer mit Memory Allocation und Garbage Collection. Befüllen Sie Object Pools bereits während des Loading Screens vor.
2. Texture Atlasing für Stadtblöcke: Draw Calls sind der primäre Killer für Mobile GPUs (die auf Tile-Based Deferred Rendering setzen). Kombinieren Sie die Texturen aller generischen Street Props (Mülleimer, Bänke, Straßenlaternen) in einem einzigen großen Texture Atlas. Dies ermöglicht es der Engine, das Rendering von Hunderten von Props in einem einzigen Draw Call zu bündeln.
3. Strikte Polycount-Budgets pro Chunk: Setzen Sie harte Limits. Ein einzelner Mobile City Chunk (z. B. ein Areal von 100x100 Metern) sollte idealerweise unter 300.000 sichtbaren Triangles bleiben. Setzen Sie verstärkt auf Normal Maps statt auf rohe Geometrie, um architektonische Details zu simulieren.
4. Implementierung von Server-Side Hibernation: Einen Dedicated Server für eine riesige Stadt zu betreiben, in der 80 % der Map derzeit leer sind, führt schnell zum Bankrott Ihres Studios. Sie benötigen aggressives Instance Management, inspiriert vom Fortnite Server Optimization Hibernation Proposal, um inaktive Grid-Koordinaten herunterzufahren und sie sofort aufzuwecken, wenn sich ein Spieler nähert.
5. Entkopplung von Collision und Visual Mesh: Verwenden Sie niemals komplexe Visual Meshes für serverseitige Kollisionsberechnungen. Der Server sollte die Stadt nur als eine Serie von Low-Poly-Primitiven (Boxen, Kapseln, Sphären) verstehen. Dies hält den Server-Memory-Footprint minimal und Physikberechnungen im Sub-Millisekundenbereich.

Häufige Fallstricke (Pitfalls)

• Die RPC-Flooding-Falle: Entwickler lösen oft Server-to-Client Remote Procedure Calls (RPCs) für visuelle Effekte aus (wie Funken bei einem Autounfall). Tun Sie das nicht. Der Server sollte nur den Status des Autos replizieren (z. B. bIsCrashed = true). Der Client sollte diese Statusänderung unabhängig über einen OnRep/Property Hook beobachten und den VFX lokal auslösen. Das spart enorme Mengen an Netzwerkbandbreite.
• Memory Leaks bei Zonenübergängen: Wenn ein Stadt-Chunk auf Mobile gestreamt wird, stellen Sie sicher, dass Sie die Garbage Collection aktiv erzwingen oder Asset Bundles manuell entladen. Wenn Sie jedes Mal, wenn ein Spieler zwischen Zonen wechselt, auch nur ein paar Megabyte verwaiste Texturen im Speicher lassen, wird das Spiel unweigerlich nach 20 Minuten abstürzen.

Fazit

Echte Mobile Game Scaling Optimization ist ein Balanceakt. Man muss um jedes Megabyte Client-RAM kämpfen, die Network Relevancy strikt regulieren und die Serverlast über skalierbare Backend-Nodes verteilen. Durch die Implementierung von Spatial Hashing, dynamischen Update-Frequenzen und asynchronem Asset Streaming können Sie massive, lebendige Städte bauen, die selbst auf jahrealter Mobile Hardware flüssig laufen.

Die Entwicklung einer skalierbaren Infrastruktur, um Tausende von Concurrent Connections zu routen und nahtlose Server-Handoffs zu verwalten, ist jedoch oft schwieriger als das Spiel selbst. Bereit, Ihr Multiplayer Backend ohne DevOps-Albtraum zu skalieren? Testen Sie horizOn kostenlos oder werfen Sie einen Blick in die API Docs, um zu sehen, wie wir High-Concurrency-Architekturen out-of-the-box handhaben.

---

Quelle: Designing Large-Scale Mobile Game Cities: Production, Optimization, & Worldbuilding Expertise