Devlog #11 · Controladores adaptativos

Um servidor de MMO não pode tratar carga leve e carga pesada da mesma forma.

Uma cidade vazia e um evento com 300 jogadores num spot são cenários radicalmente diferentes. Quando a carga aumenta, o servidor precisa reagir antes que o tick quebre — não depois.

Histerese: reagir com calma, não com pânico

Controladores com histerese observam métricas de carga por alguns ticks antes de agir. Um pico de 1 frame não ativa proteção. Uma pressão sustentada acima do limite por tempo suficiente ativa. Quando a situação melhora por tempo suficiente, o sistema volta ao normal — sem oscilar entre estados.

Dois controladores entraram primeiro:

→ Controlador de tick: pode reduzir temporariamente a frequência do servidor em sobrecarga extrema. Degradação controlada em vez de travamento.

→ Controlador de orçamento de entidades: reduz o raio de interesse de observadores que estão recebendo entidades demais. O jogador recebe menos entidades distantes; o servidor alivia a fila de replicação.

Por que isso importa

Eventos grandes, cidades cheias e spots disputados são os cenários que definem se um MMO é jogável em escala. Essa camada é o que permite que esses cenários existam sem o servidor simplesmente morrer.

Bench / validação
— Soak Phase 10: 1h / 100k entidades / controlador ativo
— 1 ativação, 1 recuperação, 2 transições no soak
— Overhead combinado dos controladores: p50 100 ns por tick
— RSS: 122.4 MiB → 132.1 MiB (+7.95% — dentro do limite de 10%)

Próximo: bot client — como simulamos jogadores antes dos jogadores chegarem.