Otimização de Escalonamento em Mobile Games: Arquitetando Cidades para 1M+ de Jogadores Simultâneos

Todo desenvolvedor Multiplayer conhece o momento exato em que a arquitetura do seu mobile game racha. Você projeta um ambiente urbano vasto e detalhado. Você o testa localmente com 10 clientes simulados, e a build roda a perfeitos 60 FPS. Então, você a envia para um ambiente de produção com 1.000 jogadores simultâneos aglomerados na praça central. Em segundos, dispositivos Android de baixo custo sofrem hard-crash devido a exceções de Out-Of-Memory (OOM), o iOS Jetsam encerra agressivamente sua aplicação, e o uso de CPU do seu Dedicated Server atinge 100% enquanto tenta calcular a replicação de rede para milhares de entidades sobrepostas.

Ao construir um MMO mobile ou um mundo aberto de grande escala projetado para suportar milhões de usuários ativos, você não pode confiar nos defaults padrão da engine. O hardware mobile possui thermal throttling rigoroso e limites rígidos de memória (muitas vezes limitando seu jogo a menos de 2GB de RAM utilizável em dispositivos intermediários). Simultaneamente, seu servidor deve lidar com aglomerados densos de jogadores sem ceder.

Alcançar uma verdadeira otimização de escalonamento em mobile games requer uma abordagem de três pilares: particionamento espacial agressivo no servidor, gerenciamento de memória implacável no cliente e uma arquitetura de Backend distribuída para lidar com o enorme volume de conexões. Neste tutorial passo a passo, vamos detalhar exatamente como arquitetar cidades de grande escala para plataformas mobile.

Passo 1: Particionamento Espacial no Server-Side

O inimigo fundamental da performance do servidor em jogos multiplayer massivos é o problema O(N²). Se o seu servidor percorre cada jogador para verificar sua distância em relação a todos os outros jogadores a fim de determinar quem precisa de atualizações de rede, a matemática escala catastroficamente. 100 jogadores exigem 10.000 verificações de distância por tick. 1.000 jogadores exigem 1.000.000 de verificações. Com um tick rate de servidor de 30Hz, são 30 milhões de verificações por segundo.

Para resolver isso, devemos implementar Spatial Hashing (ou um sistema de Grid/Quadtree). Ao dividir a cidade em um grid lógico, os jogadores apenas verificam a relevância de rede contra entidades em sua célula atual e nas células imediatamente circundantes. Isso reduz nosso pesadelo O(N²) para uma busca O(1) no grid, seguida por uma verificação local pesadamente restrita.

Implementando um Spatial Hash Grid (Exemplo em C#)

Aqui está uma implementação altamente eficiente de um Spatial Hash Grid 2D em C# que você pode adaptar para Unity, Godot (via C#) ou um servidor de Backend customizado para gerenciar a proximidade de entidades sem percorrer todo o estado do 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;
    }
}

Ao rotear sua lógica de replicação de rede através do GetEntitiesInProximity, seu servidor apenas calcula distâncias exatas para as poucas dezenas de jogadores ativamente próximos uns dos outros, reduzindo drasticamente a carga de CPU e permitindo que seu servidor lide confortavelmente com milhares de conexões simultâneas na mesma instância.

Passo 2: Gerenciamento de Interesse de Rede (Interest Management)

Mesmo com o Spatial Hashing resolvendo o gargalo de CPU do servidor, você ainda tem um problema de largura de banda (bandwidth). Redes móveis (4G/5G) são inerentemente instáveis, propensas a alto jitter e possuem limitações estritas de largura de banda. Enviar dados de 50 jogadores próximos a cada tick inundará o socket buffer do cliente mobile, levando a desyncs extremos.

O Interest Management (ou Relevância de Rede) é a prática de priorizar o que é enviado pela rede. Um jogador a 2 metros de distância envolvido em um combate requer 30 atualizações por segundo. Um jogador a 40 metros de distância caminhando em uma rua diferente precisa de apenas 2 atualizações por segundo.

Sobrescrevendo a Relevância de Rede (Exemplo em C++ para Unreal Engine)

Na Unreal Engine, você pode assumir o controle disso sobrescrevendo a função IsNetRelevantFor. Isso permite filtrar (cull) o tráfego de rede agressivamente com base na linha de visão (line-of-sight) e camadas de distância.

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

Ao escalar sua NetUpdateFrequency dinamicamente com base na distância, você pode reduzir a largura de banda de saída do servidor em mais de 70%, preservando o plano de dados móveis do jogador e evitando picos de latência.

Passo 3: Limites de Memória no Client-Side e Asset Streaming

Servidores têm muita RAM; celulares não. Um iPhone 13 possui 4GB de memória unificada. O sistema operacional iOS geralmente reserva cerca de 1,5GB a 2GB disso. Seu jogo deve caber inteiramente nos 2GB restantes. Se você carregar uma cidade inteira de grande escala na memória de uma só vez, o SO encerrará instantaneamente a aplicação.

Para sobreviver nesse ambiente, sua cidade deve ser dividida em chunks e carregada de forma assíncrona (streamed).

• Hierarchical Level of Detail (HLODs): Em vez de renderizar 50 prédios individuais em um quarteirão distante (resultando em 3.000 draw calls), você deve fazer o bake de todo esse quarteirão em uma única mesh estática com um atlas de textura unificado. Isso reduz as draw calls para geometria distante de milhares para exatamente uma.
• Sistemas de Addressable Assets: Nunca use referências diretas (hard references) em seus assets de dados primários. Se um jogador nasce no Distrito A, o cliente deve usar carregamento assíncrono (ex: Addressables do Unity ou PrimaryAssetLabels do Unreal) para baixar ou carregar apenas as texturas e meshes necessárias para o Distrito A. O Distrito B deve ser rigorosamente removido da RAM.
• Compressão de Textura: Dependa exclusivamente de ASTC (Adaptive Scalable Texture Compression) para mobile. Ele permite footprints de blocos altamente variáveis, oferecendo controle granular sobre memória vs. qualidade visual em cada textura.

Passo 4: Arquitetura de Backend Distribuída e Server Sharding

Uma metrópole massiva não pode rodar em uma única máquina física. Ao projetar uma cidade em escala MMO, o mundo deve ser fisicamente dividido em múltiplas instâncias de servidor (shards ou nós). Quando um jogador atravessa uma ponte do Nó do Centro para o Nó da Periferia, sua conexão de cliente e estado de mundo devem ser transferidos de forma transparente entre dois processos de servidor completamente diferentes.

Construir isso por conta própria exige a configuração de clusters de Kubernetes orquestrados por sistemas como Agones, sharding de banco de dados com Redis para passar o estado do jogador entre os nós do servidor e load balancers UDP customizados para transferências de conexão contínuas. Projetar isso de forma robusta para que os jogadores não percam itens durante a transição é uma tarefa hercúlea — facilmente 4 a 6 meses de trabalho dedicado de DevOps para uma equipe de engenharia sênior.

Se você não lidar corretamente com as filas de RPC e gravações no banco de dados durante essas transferências, inevitavelmente encontrará corrupção de estado. Já cobrimos anteriormente a mecânica de corrigir o problema de replicação RPC do Unreal Engine que quebra seus estados, e esses mesmos princípios se aplicam diretamente às transferências espaciais entre nós de servidor.

É aqui que as soluções de plataforma brilham. Com o horizOn, esses serviços de Backend de alta concorrência, sincronizações de banco de dados em tempo real e orquestrações de Dedicated Servers já vêm pré-configurados. Em vez de gastar seu tempo arquitetando e depurando regras de rede no Kubernetes, você pode focar estritamente na construção dos loops de gameplay da sua cidade e nas otimizações de cliente.

Boas Práticas para Worldbuilding de Cidades Mobile

Para garantir que sua cidade escale perfeitamente para milhões de usuários totais enquanto mantém altas taxas de quadros em dispositivos econômicos, siga rigorosamente estas regras arquitetônicas:

1. Pooling de Instâncias Agressivo: Nunca use Instantiate() ou SpawnActor para objetos transitórios como veículos, pedestres ou projéteis durante o gameplay. CPUs mobile sofrem muito com alocação de memória e Garbage Collection. Faça o pre-warm dos pools de objetos durante a tela de carregamento e recicle-os continuamente.
2. Atlas de Textura para Quarteirões: As draw calls são as principais assassinas de GPUs mobile (que dependem de Tile-Based Deferred Rendering). Combine as texturas de todos os props genéricos de rua (latas de lixo, bancos, postes) em um único grande atlas de textura. Isso permite que a engine processe o rendering de centenas de props em uma única draw call (batching).
3. Orçamentos Estritos de Polycount por Chunk: Imponha limites rígidos. Um único chunk de cidade mobile (ex: uma área de 100x100 metros) deve idealmente ficar abaixo de 300.000 triângulos visíveis. Dependa fortemente de normal maps em vez de geometria bruta para simular detalhes arquitetônicos.
4. Implemente Hibernação no Server-Side: Rodar um Dedicated Server para uma cidade massiva onde 80% do mapa está vazio no momento é o caminho mais rápido para levar seu estúdio à falência. Você precisa de um gerenciamento de instâncias agressivo, inspirando-se na proposta de hibernação para otimização de servidor do Fortnite para desativar coordenadas de grid ociosas e acordá-las instantaneamente quando um jogador se aproxima.
5. Desacople a Colisão da Visual Mesh: Nunca use meshes visuais complexas para cálculos de colisão no lado do servidor. O servidor deve entender a cidade apenas como uma série de formas primitivas low-poly (caixas, cápsulas, esferas). Isso mantém o footprint de memória do servidor mínimo e os cálculos de física abaixo de um milissegundo.

Erros Comuns a Evitar

• A Armadilha do RPC Flooding: Desenvolvedores frequentemente disparam Remote Procedure Calls (RPCs) do servidor para o cliente para efeitos visuais (como uma faísca saindo de uma batida de carro). Não faça isso. O servidor deve apenas replicar o estado do carro (ex: bIsCrashed = true). O cliente deve observar independentemente essa mudança de estado via um OnRep/property hook e disparar o VFX da faísca localmente. Isso economiza uma quantidade massiva de largura de banda de rede.
• Vazamento de Memória em Transições de Zona: Ao descarregar um chunk de cidade no mobile, garanta que você está forçando o Garbage Collection ou descarregando manualmente os asset bundles. Se você deixar apenas alguns Megabytes de texturas órfãs na memória cada vez que um jogador se move entre zonas, ele inevitavelmente sofrerá um crash após 20 minutos de jogo.

Conclusão

Alcançar uma verdadeira otimização de escalonamento em mobile games é um ato de equilíbrio. Requer lutar por cada megabyte de RAM no cliente, regular estritamente a relevância de rede e distribuir a carga do servidor entre nós de Backend escalonáveis. Ao implementar Spatial Hashing, frequências de atualização dinâmicas e streaming assíncrono de assets, você pode construir cidades massivas e vivas que rodam suavemente mesmo em hardware mobile de anos atrás.

No entanto, construir a infraestrutura escalonável para rotear milhares de conexões simultâneas e gerenciar transferências de servidor perfeitas costuma ser mais difícil do que construir o próprio jogo. Pronto para escalar seu Backend multiplayer sem o pesadelo de DevOps? Experimente o horizOn gratuitamente ou confira a documentação da API para ver como lidamos com arquiteturas de alta concorrência nativamente.

---

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