Optimización de escalabilidad en Mobile Games: Arquitectura de ciudades para más de 1 millón de jugadores simultáneos

Todo desarrollador de juegos Multiplayer conoce el momento exacto en el que su arquitectura colapsa. Diseñas un entorno urbano inmenso y detallado, lo pruebas localmente con 10 clientes simulados y el build corre a unos impecables 60 FPS. Luego, lo lanzas a un entorno live con 1,000 jugadores concurrentes aglomerados en la plaza central. En segundos, los dispositivos Android de gama baja sufren un hard-crash debido a excepciones Out-Of-Memory (OOM), el Jetsam de iOS mata agresivamente tu aplicación y el CPU de tu Dedicated Server se dispara al 100% mientras intenta calcular la Network Replication de miles de entidades superpuestas.

Al construir un MMO para móviles o un mundo abierto a gran escala diseñado para soportar millones de usuarios activos, no puedes confiar en los valores por defecto del motor. El hardware móvil tiene un estricto thermal throttling y límites de memoria severos (restringiendo a menudo tu juego a menos de 2GB de RAM utilizable en dispositivos de gama media). Simultáneamente, tu servidor debe gestionar clusters densos de jugadores sin flaquear.

Lograr una verdadera optimización de escalabilidad en Mobile Games requiere un enfoque de tres pilares: un Spatial Partitioning agresivo en el servidor, una gestión de memoria implacable en el cliente y una arquitectura de Backend distribuida para manejar el volumen masivo de conexiones. En este tutorial paso a paso, desglosaremos exactamente cómo arquitectar ciudades a gran escala para plataformas móviles.

Paso 1: Server-Side Spatial Partitioning

El enemigo fundamental del rendimiento del servidor en juegos masivos Multiplayer es el problema O(N²). Si tu servidor recorre cada jugador para comprobar su distancia respecto a todos los demás y determinar quién necesita actualizaciones de red, el cálculo escala de forma catastrófica. 100 jugadores requieren 10,000 comprobaciones de distancia por tick. 1,000 jugadores requieren 1,000,000 de comprobaciones. Con una tasa de 30Hz en el servidor, eso supone 30 millones de comprobaciones por segundo.

Para solucionar esto, debemos implementar Spatial Hashing (o un sistema de Grid/Quadtree). Al dividir la ciudad en una cuadrícula lógica, los jugadores solo verifican su Network Relevance contra entidades en su celda actual y en las celdas circundantes inmediatas. Esto reduce nuestra pesadilla O(N²) a una búsqueda en grid de O(1) seguida de una comprobación local muy acotada.

Implementación de un Spatial Hash Grid (Ejemplo en C#)

Aquí tienes una implementación altamente eficiente de un 2D Spatial Hash Grid en C# que puedes adaptar para Unity, Godot (vía C#) o un servidor de Backend personalizado para gestionar la proximidad de entidades sin recorrer todo el estado del mundo.

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

Al canalizar tu lógica de replicación de red a través de GetEntitiesInProximity, tu servidor solo calcula distancias exactas para las pocas docenas de jugadores que están cerca entre sí, reduciendo drásticamente la carga de CPU y permitiendo que tu servidor maneje cómodamente miles de concurrentes en la misma instancia.

Paso 2: Network Interest Management

Incluso con el Spatial Hashing resolviendo el cuello de botella de CPU del servidor, sigues teniendo un problema de ancho de banda. Las redes móviles (4G/5G) son inherentemente inestables, propensas a un alto jitter y tienen limitaciones estrictas. Enviar datos de 50 jugadores cercanos en cada tick saturará el buffer del socket del cliente móvil, provocando desincronizaciones extremas.

El Interest Management (o Network Relevancy) es la práctica de priorizar qué se envía a través de la red. Un jugador a 2 metros de distancia participando en un combate requiere 30 actualizaciones por segundo. Un jugador a 40 metros caminando por una calle diferente solo necesita 2 actualizaciones por segundo.

Sobrescribiendo la Network Relevancy (Ejemplo en Unreal Engine C++)

En Unreal Engine, puedes tomar el control de esto sobrescribiendo la función IsNetRelevantFor. Esto te permite descartar agresivamente el tráfico de red basándote en la línea de visión y rangos de distancia.

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

Al escalar dinámicamente tu NetUpdateFrequency según la distancia, puedes reducir el ancho de banda de salida del servidor en más de un 70%, preservando el plan de datos móviles del jugador y evitando picos de latencia.

Paso 3: Límites de memoria en el cliente y Asset Streaming

Los servidores tienen mucha RAM; los teléfonos móviles no. Un iPhone 13 tiene 4GB de memoria unificada. El sistema operativo iOS suele reservar entre 1.5GB y 2GB de eso. Tu juego debe caber enteramente en los 2GB restantes. Si cargas una ciudad entera a gran escala en memoria a la vez, el SO terminará la aplicación instantáneamente.

Para sobrevivir en este entorno, tu ciudad debe estar dividida en chunks y ser cargada mediante streaming asíncrono.

• Hierarchical Level of Detail (HLODs): En lugar de renderizar 50 edificios individuales en una manzana lejana (lo que supondría 3,000 Draw Calls), debes "hornear" toda esa manzana en una sola Static Mesh con un Texture Atlas unificado. Esto reduce las Draw Calls de la geometría distante de miles a exactamente una.
• Addressable Asset Systems: Nunca uses referencias directas (hard references) en tus assets de datos principales. Si un jugador aparece en el Distrito A, el cliente debe usar carga asíncrona (ej. Addressables de Unity o PrimaryAssetLabels de Unreal) para descargar o cargar solo las texturas y meshes requeridas para ese distrito. El Distrito B debe ser eliminado rigurosamente de la RAM.
• Compresión de texturas: Confía exclusivamente en ASTC (Adaptive Scalable Texture Compression) para móviles. Permite un control granular sobre el equilibrio entre memoria y calidad visual para cada textura.

Paso 4: Arquitectura de Backend distribuida y Server Sharding

Una metrópolis masiva no puede ejecutarse en una sola máquina física. Al diseñar una ciudad a escala MMO, el mundo debe dividirse físicamente en múltiples instancias de servidor (shards o nodos). Cuando un jugador cruza un puente del Nodo Downtown al Nodo Slums, la conexión de su cliente y el estado del mundo deben transferirse sin interrupciones entre dos procesos de servidor completamente diferentes.

Construir esto por tu cuenta requiere configurar clusters de Kubernetes orquestados por sistemas como Agones, sharding de bases de datos con Redis para pasar el estado del jugador entre nodos y balanceadores de carga UDP personalizados para transferencias de conexión fluidas. Diseñar esto de forma robusta para que los jugadores no pierdan ítems durante la transición es una tarea titánica; fácilmente de 4 a 6 meses de trabajo dedicado de DevOps para un equipo de ingeniería senior.

Si no manejas correctamente las colas de RPC y las escrituras en la base de datos durante estas transferencias, inevitablemente te enfrentarás a la corrupción de estados. Ya hemos cubierto anteriormente la mecánica para solucionar el problema de replicación RPC en Unreal Engine que rompe tus estados, y esos mismos principios se aplican directamente a las transferencias espaciales entre nodos de servidor.

Aquí es donde brillan las soluciones de plataforma. Con horizOn, estos servicios de Backend de alta concurrencia, sincronización de bases de datos en tiempo real y orquestación de Dedicated Servers vienen preconfigurados. En lugar de gastar tu presupuesto diseñando y depurando reglas de red en Kubernetes, puedes centrarte estrictamente en construir los loops de gameplay de tu ciudad y las optimizaciones del cliente.

Best Practices para el Worldbuilding de ciudades en móviles

Para asegurar que tu ciudad escale sin problemas a millones de usuarios manteniendo un framerate alto en dispositivos económicos, sigue estrictamente estas reglas arquitectónicas:

1. Instance Pooling agresivo: Nunca uses Instantiate() o SpawnActor para objetos transitorios como vehículos, peatones o proyectiles durante el gameplay. Los CPUs móviles sufren mucho con la asignación de memoria y el Garbage Collection. Prepara los pools de objetos durante la pantalla de carga y recíclalos continuamente.
2. Texture Atlasing para bloques de la ciudad: Las Draw Calls son el principal asesino de las GPUs móviles (que dependen del Tile-Based Deferred Rendering). Combina las texturas de todos los props genéricos de la calle (papeleras, bancos, farolas) en un solo Texture Atlas grande. Esto permite que el motor agrupe el renderizado de cientos de props en una sola Draw Call.
3. Presupuestos estrictos de Polycount por Chunk: Aplica límites severos. Un solo chunk de ciudad móvil (ej. un área de 100x100 metros) debería mantenerse idealmente por debajo de los 300,000 triángulos visibles. Confía plenamente en los Normal Maps en lugar de la geometría pura para simular detalles arquitectónicos.
4. Implementar Server-Side Hibernation: Ejecutar un Dedicated Server para una ciudad masiva donde el 80% del mapa está vacío es el camino rápido a la bancarrota de tu estudio. Necesitas una gestión de instancias agresiva, inspirándote en la propuesta de hibernación para la optimización de servidores de Fortnite para desactivar coordenadas del grid inactivas y despertarlas instantáneamente cuando un jugador se acerque.
5. Desacoplar la colisión de la Mesh visual: Nunca uses meshes visuales complejos para los cálculos de colisión en el servidor. El servidor solo debe entender la ciudad como una serie de formas primitivas low-poly (cajas, cápsulas, esferas). Esto mantiene la huella de memoria del servidor al mínimo y los cálculos de física en milisegundos.

Errores comunes que debes evitar

• La trampa de la saturación de RPC: Los desarrolladores suelen lanzar Remote Procedure Calls (RPCs) de servidor a cliente para efectos visuales (como una chispa en un choque de coches). No lo hagas. El servidor solo debe replicar el estado del coche (ej. bIsCrashed = true). El cliente debe observar este cambio de estado de forma independiente mediante un hook de OnRep/propiedad y activar el efecto visual localmente. Esto ahorra una cantidad masiva de ancho de banda de red.
• Fugas de memoria en transiciones de zona: Al descargar un chunk de ciudad en móvil, asegúrate de forzar el Garbage Collection o descargar manualmente los asset bundles. Si dejas aunque sea unos pocos Megabytes de texturas huérfanas en memoria cada vez que un jugador se mueve entre zonas, inevitablemente sufrirá un crash tras 20 minutos de juego.

Conclusión

Lograr una verdadera optimización de escalabilidad en Mobile Games es un acto de equilibrio. Requiere luchar por cada megabyte de RAM en el cliente, regular estrictamente la Network Relevancy y distribuir la carga del servidor entre nodos de Backend escalables. Implementando Spatial Hashing, frecuencias de actualización dinámicas y streaming de assets asíncrono, puedes construir ciudades masivas y vivas que funcionen con fluidez incluso en hardware móvil con varios años de antigüedad.

Sin embargo, construir la infraestructura escalable para enrutar miles de conexiones simultáneas y gestionar transferencias de servidor sin interrupciones suele ser más difícil que crear el juego en sí. ¿Listo para escalar tu Backend multiplayer sin la pesadilla de DevOps? Prueba horizOn gratis o consulta la documentación de la API para ver cómo manejamos la arquitectura de alta concurrencia de forma nativa.

---

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