Ottimizzazione dello Scaling nei Mobile Game: Architettare Città per oltre 1 Milione di Concurrent Players

Ogni sviluppatore Multiplayer conosce l'esatto momento in cui l'architettura del proprio mobile game cede. Progetti un ambiente urbano vasto e dettagliato. Lo testi localmente con 10 client simulati e la build gira a 60 FPS costanti. Poi, la pubblichi in un ambiente live con 1.000 Concurrent Players ammassati nella piazza centrale. In pochi secondi, i dispositivi Android di fascia bassa crashano a causa di eccezioni Out-Of-Memory (OOM), iOS Jetsam killa aggressivamente l'applicazione e la CPU del tuo Dedicated Server schizza al 100% nel tentativo di calcolare la replicazione di rete per migliaia di entità sovrapposte.

Quando si costruisce un MMO mobile o un grande open world progettato per supportare milioni di utenti attivi, non ci si può affidare ai default dell'engine. L'hardware mobile presenta uno stretto thermal throttling e limiti di memoria rigidi (spesso limitando il gioco a meno di 2GB di RAM utilizzabile sui dispositivi di fascia media). Contemporaneamente, il server deve gestire cluster densi di player senza soccombere.

Raggiungere una vera ottimizzazione dello scaling nei mobile game richiede un approccio a tre pilastri: uno Spatial Partitioning aggressivo sul server, una gestione della memoria spietata sul client e un'architettura Backend distribuita per gestire l'enorme volume di connessioni. In questo tutorial passo-passo, analizzeremo esattamente come architettare città su larga scala per piattaforme mobile.

Step 1: Server-Side Spatial Partitioning

Il nemico fondamentale delle performance del server nei giochi Massive Multiplayer è il problema O(N²). Se il tuo server itera su ogni player per controllare la distanza rispetto a ogni altro player e determinare chi necessita di aggiornamenti di rete, il calcolo scala in modo catastrofico. 100 player richiedono 10.000 controlli di distanza per tick. 1.000 player ne richiedono 1.000.000. Con un tick rate del server di 30Hz, si parla di 30 milioni di controlli al secondo.

Per risolvere questo problema, dobbiamo implementare lo Spatial Hashing (o un sistema Grid/Quadtree). Dividendo la città in una griglia logica, i player controllano la propria Network Relevancy solo rispetto alle entità nella loro cella corrente e in quelle immediatamente circostanti. Questo riduce l'incubo O(N²) a una lookup sulla griglia in O(1), seguita da un controllo locale pesantemente vincolato.

Implementare una Spatial Hash Grid (Esempio in C#)

Ecco un'implementazione altamente efficiente di una Spatial Hash Grid 2D in C# che puoi adattare per Unity, Godot (via C#) o un server Backend personalizzato per gestire la prossimità delle entità senza iterare sull'intero stato del mondo.

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>>();
    }

    // Converte una posizione nel mondo in una coordinata della griglia
    private Vector2Int GetCellCoordinate(Vector3 position)
    {
        return new Vector2Int(
            Mathf.FloorToInt(position.x / _cellSize),
            Mathf.FloorToInt(position.z / _cellSize)
        );
    }

    // Aggiunge o aggiorna la posizione di un player nella griglia
    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);
        }
    }

    // Recupera tutte le entità nelle immediate vicinanze (9 celle)
    public List<uint> GetEntitiesInProximity(Vector3 position)
    {
        List<uint> nearbyEntities = new List<uint>();
        Vector2Int centerCell = GetCellCoordinate(position);

        // Itera attraverso la griglia 3x3 attorno al 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;
    }
}

Incanalando la logica di replicazione di rete attraverso GetEntitiesInProximity, il tuo server calcolerà le distanze esatte solo per le poche decine di player attivamente vicini tra loro, riducendo drasticamente il carico della CPU e permettendo al server di gestire comodamente migliaia di Concurrent Players nella stessa istanza.

Step 2: Network Interest Management

Anche se lo Spatial Hashing risolve il collo di bottiglia della CPU del server, rimane il problema della banda. Le reti mobile (4G/5G) sono intrinsecamente instabili, soggette a jitter elevato e presentano rigide limitazioni di banda. Inviare dati per 50 player vicini a ogni tick saturerà il socket buffer del client mobile, portando a desync estremi.

L'Interest Management (o Network Relevancy) è la pratica di dare priorità a cosa viene inviato sulla rete. Un player a 2 metri di distanza impegnato in uno scontro a fuoco richiede 30 aggiornamenti al secondo. Un player a 40 metri che cammina in una strada diversa ha bisogno solo di 2 aggiornamenti al secondo.

Overriding della Network Relevancy (Esempio C++ in Unreal Engine)

In Unreal Engine, puoi prendere il controllo di questo aspetto effettuando l'override della funzione IsNetRelevantFor. Questo ti permette di eseguire il culling del traffico di rete in modo aggressivo basandoti sulla line-of-sight e su scaglioni di distanza.

bool ACityPlayerCharacter::IsNetRelevantFor(const AActor* RealViewer, const AActor* ViewTarget, const FVector& SrcLocation) const
{
    // 1. Sempre rilevante per noi stessi
    if (RealViewer == this || ViewTarget == this)
    {
        return true;
    }

    // 2. Calcola la distanza al quadrato (più veloce della distanza esatta)
    const float DistanceSquared = FVector::DistSquared(SrcLocation, GetActorLocation());

    // 3. Distanza di culling assoluta (es. 10.000 unità = 100 metri)
    const float MaxRelevancyDistSq = 100000000.0f; 
    if (DistanceSquared > MaxRelevancyDistSq)
    {
        return false;
    }

    // 4. Frequenza di aggiornamento di rete dinamica basata sulla distanza
    // Se sono lontani, abbassiamo la frequenza di invio dei dati
    if (DistanceSquared > 25000000.0f) // 50 metri
    {
        NetUpdateFrequency = 2.0f; // 2 aggiornamenti al secondo
    }
    else
    {
        NetUpdateFrequency = 30.0f; // 30 aggiornamenti al secondo
    }

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

Scalando la NetUpdateFrequency dinamicamente in base alla distanza, puoi ridurre la banda in uscita del server di oltre il 70%, preservando il piano dati mobile del giocatore ed evitando picchi di latenza.

Step 3: Limiti di Memoria Client e Asset Streaming

I server hanno molta RAM; i telefoni cellulari no. Un iPhone 13 ha 4GB di memoria unificata. Il sistema operativo iOS ne riserva tipicamente circa 1,5GB - 2GB. Il tuo gioco deve rientrare interamente nel footprint rimanente di 2GB. Se carichi un'intera città su larga scala in memoria tutto in una volta, l'OS terminerà istantaneamente l'applicazione.

Per sopravvivere in questo ambiente, la tua città deve essere suddivisa in chunk e caricata in streaming asincrono.

• Hierarchical Level of Detail (HLODs): Invece di renderizzare 50 singoli edifici in un isolato distante (che comporterebbero 3.000 Draw Calls), devi eseguire il bake dell'intero isolato in una singola mesh statica con un texture atlas unificato. Questo riduce le Draw Calls per la geometria distante da migliaia a esattamente una.
• Sistemi di Addressable Asset: Non usare mai riferimenti rigidi (hard references) nei tuoi data asset primari. Se un player spawna nel Distretto A, il client dovrebbe usare il caricamento asincrono (es. Addressables di Unity o PrimaryAssetLabels di Unreal) per scaricare o caricare solo le texture e le mesh richieste per il Distretto A. Il Distretto B deve essere rimosso rigorosamente dalla RAM.
• Compressione delle Texture: Affidati esclusivamente ad ASTC (Adaptive Scalable Texture Compression) per il mobile. Consente footprint di blocco altamente variabili, offrendoti un controllo granulare sulla memoria rispetto alla qualità visiva per ogni singola texture.

Step 4: Architettura Backend Distribuita e Server Sharding

Una metropoli massiva non può girare su una singola macchina fisica. Quando si progetta una città in scala MMO, il mondo deve essere fisicamente diviso tra più istanze server (shard o nodi). Quando un player attraversa un ponte dal Nodo Downtown al Nodo Slums, la connessione del client e lo stato del mondo devono passare senza interruzioni tra due processi server completamente diversi.

Costruire tutto questo autonomamente richiede la configurazione di cluster Kubernetes orchestrati da sistemi come Agones, il database sharding con Redis per passare lo stato del player tra i nodi server e load balancer UDP personalizzati per handover di connessione fluidi. Progettare questo sistema in modo robusto, affinché i giocatori non perdano oggetti durante la transizione, è un'impresa enorme: facilmente 4-6 mesi di lavoro DevOps dedicato per un team di ingegneria senior.

Se non gestisci correttamente le code RPC e le scritture sul database durante questi passaggi, incapperai inevitabilmente in corruzioni dello stato. Abbiamo precedentemente trattato le meccaniche per risolvere il problema di replicazione RPC in Unreal Engine che corrompe i tuoi stati, e quegli stessi principi si applicano direttamente agli handover spaziali tra i nodi server.

È qui che le soluzioni di piattaforma brillano. Con horizOn, questi servizi Backend ad alta concorrenza, la sincronizzazione del database in tempo reale e le orchestrazioni dei Dedicated Server sono pre-configurati. Invece di consumare il tuo runway architettando e debuggando regole di networking Kubernetes, puoi concentrarti strettamente sulla costruzione dei loop di gameplay della tua città e sulle ottimizzazioni client.

Best Practices per il Worldbuilding di Città Mobile

Per garantire che la tua città scali perfettamente fino a milioni di utenti totali mantenendo frame rate elevati su dispositivi economici, attieniti rigorosamente a queste regole architetturali:

1. Aggressive Instance Pooling: Non usare mai Instantiate() o SpawnActor per oggetti transitori come veicoli, pedoni o proiettili durante il gameplay. Le CPU mobile soffrono pesantemente per l'allocazione di memoria e la Garbage Collection. Effettua il pre-warm degli object pool durante la schermata di caricamento e riciclali continuamente.
2. Texture Atlasing per gli Isolati: Le Draw Calls sono il principale killer delle GPU mobile (che si affidano al Tile-Based Deferred Rendering). Combina le texture di tutti gli asset stradali generici (bidoni, panchine, lampioni) in un unico grande texture atlas. Questo permette all'engine di effettuare il batch del rendering di centinaia di props in una singola Draw Call.
3. Budget Rigidi di Polycount per Chunk: Imponi limiti severi. Un singolo chunk di città mobile (es. un'area di 100x100 metri) dovrebbe idealmente rimanere sotto i 300.000 triangoli visibili. Affidati pesantemente alle normal maps piuttosto che alla geometria grezza per simulare i dettagli architettonici.
4. Implementare la Server-Side Hibernation: Far girare un Dedicated Server per una città massiva dove l'80% della mappa è attualmente vuoto è la via più veloce per mandare in bancarotta il tuo studio. Hai bisogno di una gestione aggressiva delle istanze, traendo ispirazione dalla proposta di ibernazione per l'ottimizzazione dei server di Fortnite per spegnere le coordinate della griglia inattive e risvegliarle istantaneamente quando un player si avvicina.
5. Disaccoppiare le Collisioni dalla Visual Mesh: Non usare mai mesh visive complesse per i calcoli di collisione lato server. Il server dovrebbe interpretare la città solo come una serie di primitive low-poly (box, capsule, sfere). Questo mantiene minimo il footprint di memoria del server e i calcoli fisici sotto il millisecondo.

Errori Comuni da Evitare

• La trappola dell'RPC Flooding: Gli sviluppatori spesso attivano Remote Procedure Calls (RPC) da server a client per effetti visivi (come una scintilla che scaturisce da un incidente d'auto). Non farlo. Il server dovrebbe replicare solo lo stato dell'auto (es. bIsCrashed = true). Il client dovrebbe osservare indipendentemente questo cambiamento di stato tramite un OnRep/property hook e attivare il VFX della scintilla localmente. Questo risparmia enormi quantità di banda di rete.
• Memory Leak nelle transizioni di zona: Quando rimuovi un chunk di città tramite streaming su mobile, assicurati di forzare la Garbage Collection o di scaricare manualmente gli asset bundle. Se lasci anche solo pochi Megabyte di texture orfane in memoria ogni volta che un player si sposta tra le zone, subirà inevitabilmente un crash dopo 20 minuti di gioco.

Conclusione

Raggiungere una vera ottimizzazione dello scaling nei mobile game è un gioco di equilibrio. Richiede di lottare per ogni megabyte di RAM client, regolare rigorosamente la Network Relevancy e distribuire il carico del server su nodi Backend scalabili. Implementando Spatial Hashing, frequenze di aggiornamento dinamiche e asset streaming asincrono, puoi costruire città massive e vive che girano fluidamente anche su hardware mobile di qualche anno fa.

Tuttavia, costruire l'infrastruttura scalabile per gestire migliaia di connessioni simultanee e handover tra server senza interruzioni è spesso più difficile che costruire il gioco stesso. Pronto a scalare il tuo Backend Multiplayer senza l'incubo DevOps? Prova horizOn gratuitamente o consulta la documentazione API per vedere come gestiamo l'architettura ad alta concorrenza out-of-the-box.

---

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