Simulação militar: como a Skyral simula agentes autônomos

Quando vi a notícia no Olhardigital.com.br sobre o Exército britânico usando um videogame para prever batalhas, minha primeira reação não foi “uau, que inovação militar” — foi “finalmente alguém está admitindo que simulação digital de cenários complexos virou commodity de game engine”. Na minha experiência com projetos de IA e visualização, o que a Skyral faz em Riga, na Letônia, é a mesma arquitetura que muita startup de smart city e logística tenta montar há anos, mas travando em três problemas clássicos: custo, escala e qualidade dos agentes simulados.

O que está por trás da tecnologia Skyral

A Skyral nasceu da Improbable Worlds Limited, que é uma empresa britânica conhecida pelos motores para jogos大规模 (em escala massiva). O diferencial técnico deles — e isso é o que interessa para nós, devs — é a capacidade de simular dezenas de milhares de agentes autônomos em um mesmo ambiente virtual coerente, com física, propagação de eventos e persistência de estado.

Quando você roda um jogo convencional, o motor (Unity, Unreal, Godot) cuida de alguns milhares de entidades no máximo em tempo real. Para ir além disso, você precisa de:

• Distribuição geográfica do estado — sharding espacial, semelhante a um banco NoSQL particionado por região do mapa.
• Sincronização de eventos com garantia de entrega — cada explosão em uma rua afeta a percepção dos agentes em um raio de 200m.
• Comportamento emergente — não é script por NPC; é simulação social onde cada civil decide fugir, ficar ou hostilizar com base em variáveis locais.

Isso é, na essência, o mesmo problema que empresas como a AnyLogic, a Simudyne e a Prayag tentam resolver para o mercado financeiro e logística. A Skyral só pegou o mesmo stack e empurrou para o nicho de defesa.

Por que o contrato de £2 bilhões faz sentido técnico

O valor assusta, mas olhando do ângulo de engenharia, ele se justifica. Segundo o Olhardigital, o consórcio vencedor vai apoiar o treinamento das forças britânicas. Treinamento militar tradicional custa caro porque consome munição real, combustível de veículo, tempo de tropa em campo e, principalmente, coloca vidas em risco. Uma simulação digital permite rodar 1.000 variações do mesmo cenário pelo custo de uma única operação física.

O detalhe que pouca gente comenta: o Ministério da Defesa britânico não comprou apenas um “jogo bonito”. Comprou a infraestrutura de simulação persistente. O mesmo ambiente virtual que roda o treinamento hoje pode ser usado amanhã para planejamento operacional, depois para análise de aquisição de equipamento e por fim para pós-mortem de missões reais. É o mesmo conceito de digital twin que a indústria de manufatura já usa — só que aplicado a cidades inteiras.

Na Prática: como construir um agente de multidão realista em Python

Para vocês terem ideia da complexidade do que a Skyral faz, vou mostrar um esqueleto mínimo de agente social usando mesa (framework de simulação baseada em agentes em Python). Não é o mesmo motor da Improbable, mas a arquitetura conceitual é equivalente.

import random
from mesa import Agent, Model
from mesa.time import RandomActivation
from mesa.space import MultiGrid

class Civil(Agent):
    def __init__(self, unique_id, model, panic_threshold=0.7):
        super().__init__(unique_id, model)
        self.panic_threshold = panic_threshold
        self.stress = 0.0
        self.alive = True

    def step(self):
        # Eventos sensoriais: explosão, tiro, sirene
        perceived_threat = self.model.local_threat(self.pos)
        self.stress += perceived_threat * 0.1

        if self.stress > self.panic_threshold:
            self._flee()
        else:
            self._wander()

        # Morte por excesso de stress (modelo simplificado)
        if self.stress > 1.0:
            self.alive = False

    def _flee(self):
        # Move para a célula vizinha com menor ameaça
        neighbors = self.model.grid.get_neighborhood(
            self.pos, moore=True, include_center=False
        )
        if not neighbors:
            return
        safest = min(neighbors, key=lambda c: self.model.local_threat(c))
        self.model.grid.move_agent(self, safest)

    def _wander(self):
        possible = self.model.grid.get_neighborhood(
            self.pos, moore=True, include_center=False
        )
        if possible:
            self.model.grid.move_agent(self, random.choice(possible))

class UrbanScenario(Model):
    def __init__(self, width, height, n_civils, n_threats):
        self.grid = MultiGrid(width, height, torus=False)
        self.schedule = RandomActivation(self)
        self.threats = set()

        for i in range(n_civils):
            a = Civil(i, self)
            x = self.random.randrange(width)
            y = self.random.randrange(height)
            self.grid.place_agent(a, (x, y))
            self.schedule.add(a)

        for _ in range(n_threats):
            self.threats.add((
                self.random.randrange(width),
                self.random.randrange(height)
            ))

    def local_threat(self, pos):
        # Soma a ameaça dos eventos num raio de 3 células
        radius = 3
        x, y = pos
        threat = 0
        for tx, ty in list(self.threats):
            if abs(tx - x) <= radius and abs(ty - y) <= radius:
                threat += 1
        return threat

    def step(self):
        self.schedule.step()

Esse código roda em escala pequena (mil agentes) e é onde 90% dos projetos de simulação que já auditei travam. Escalar para dezenas de milhares exige mover o estado para fora do Python puro — geralmente para Rust ou C++ com bindings, e distribuir via actor model (Erlang/OTP ou Akka).

Comparação com engines comerciais

Perceba que a escala da Skyral/Improbable não é mágica — é engenharia de sistemas distribuídos aplicada ao domínio de simulação. É o mesmo desafio de escalar um matchmaker de jogo online para suportar milhões de sessões.

Erros comuns que devs cometem ao entrar nesse mercado

Quando aparece um projeto de "simulação urbana para prefeituras" ou "digital twin para logística", eu já sei que três coisas vão dar errado se a equipe não tiver experiência em games ou sistemas distribuídos:

1. Tratar agentes como dados, não como entidades com ciclo de vida. Civil morto não é deletado — é convertido em obstáculo, afeta fluxo de outros agentes, libera recursos de IA. Esquecer disso quebra a simulação inteira.
2. Subestimar custo de propagação espacial. Atualizar o estado de "percepção de ameaça" para 50k agentes a cada tick exige queries espaciais otimizadas (kd-tree, quadtree). Tentar fazer isso em loop duplo é suicídio de CPU.
3. Confundir visualização com simulação. Render bonito em Unreal não significa que a IA dos agentes é boa. Time de美术 e time de simulação são stacks completamente diferentes.
4. Ignorar validação contra mundo real. A Skyral usa ruas reais de Riga. Se você simula uma cidade sem dados reais de tráfego, fluxo de pedestres e densidade populacional, está fazendo um jogo, não uma ferramenta de decisão.

A última é a mais crítica. Segundo o Olhardigital, a Skyral reproduziu prédios, lojas e diferentes reações de moradores. Isso só funciona porque existe um pipeline de ingestão de dados urbanos — OpenStreetMap, dados de censo, imagens de satélite — alimentando o motor. Sem isso, vira demo de feira, não produto.

Implicações práticas para o desenvolvedor brasileiro

Esse mercado está mais próximo do que parece. O Ministério da Defesa do Brasil, as Forças Armadas e até órgãos como a Defesa Civil gastam milhões em simulação — mas compram de fora, geralmente dos EUA e Israel. Tem espaço, e muito, para uma empresa brasileira construir stack equivalente usando:

• Godot 4 como engine base (open source, GDScript performático, suporte a C#).
• Ray ou Anyscale para orquestração de simulação distribuída em Python.
• PostGIS para queries espaciais em dados urbanos.
• Hugging Face para modelos de comportamento social baseados em LLM.

O último ponto é onde a coisa fica interessante: dá para usar um LLM pequeno rodando local para gerar o "script de comportamento" de um civil genérico, em vez de codificar árvore de decisão manualmente. Eu já testei isso em protótipo e funciona surpreendentemente bem para diálogos e decisões de baixa criticidade.

FAQ — perguntas que devs reais fariam

Qual a diferença entre digital twin e simulação militar tradicional?
Digital twin é alimentado por dados reais em tempo (quase) real do sistema físico; simulação tradicional parte de cenários pré-fabricados. A Skyral combina os dois: usa dados estáticos da cidade (prédios, ruas) e dados dinâmicos injetados (explosões, movimentação de tropas) para criar cenários novos a cada execução.

Preciso de Unreal Engine para fazer isso?
Não. Para simulação pura (sem visualização AAA), Godot ou até um motor próprio em Rust/C++ resolve. Unreal entra quando o cliente exige render fotorrealista — o que custa caro de licenciar e manter.

Quanto custa um projeto desse na realidade?
Para um MVP de simulação urbana com 10k agentes, conte R$ 500 mil a R$ 2 milhões entre equipe sênior (6 a 12 meses) e infraestrutura cloud. Para chegar no nível da Skyral, multiplique por 100 e adicione 5 anos de P&D.

Vale a pena entrar nesse mercado no Brasil?
Na minha leitura, sim — mas não pelo cliente militar diretamente. O filão maior é o de smart city, planejamento de evacuação, seguros (modelagem de risco) e logística de última milha. O nicho militar valida a tecnologia, mas o retorno vem do civil.

IA generativa ameaça esse tipo de simulação?
Parcialmente. LLM ajuda a gerar comportamentos e diálogos, mas não substitui o motor de simulação de física e propagação de eventos. O que vai acontecer nos próximos 5 anos é IA generativa como camada de "roteirista" sobre o motor tradicional, não a substituição dele.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.