Simular uma frota de robôs em um warehouse deixa de ser só “movimento no cenário” quando identidade, telemetria e interface passam a conversar em tempo real. A base dessa arquitetura combina Scriptable Objects para dados, um fluxo de eventos para comunicação e NavMesh para navegação, com alternância entre modo autônomo e controle manual.
Da malha CAD estática para agentes com identidade
O salto de um modelo CAD importado para um agente “vivo” passa por separar dados de comportamento. Em vez de enterrar tudo em componentes do GameObject, cada robô ganha um asset próprio que concentra seu estado: nome, modo de operação, status atual, variante ativa e telemetria de runtime como bateria, saúde e temperatura.
Essa separação facilita reutilização: vários robôs podem executar as mesmas rotinas, mas cada um mantém seus números e sua identidade isolados. Na prática, os Scriptable Objects funcionam como um arquivo por unidade, sem mover nada por conta própria.
Resumo da frota: um segundo Scriptable Object para o “todo”
Além do dado por robô, entra um Scriptable Object de fleet summary: média de bateria, quantos estão se movendo e a contagem por categoria (normal, warning, critical). Esse asset alimenta a barra superior da UI com números consolidados, mas segue a mesma regra: é apenas dados, não dirige comportamento.
Para o resumo se manter atualizado, um script dedicado roda continuamente, percorre a lista de robôs e recalcula os indicadores da frota. Assim, a interface recebe uma visão global consistente, sem depender de “gambiarras” em múltiplos pontos do projeto.
O backbone da comunicação: gerenciamento e eventos
Conectar dados e modelos exige um elo central. Um Robot Manager (singleton) descobre todos os robôs na cena ao iniciar, associa cada um ao seu Scriptable Object e guarda tudo em uma lista. A partir daí, dois eventos sustentam a comunicação do projeto: mudança do robô ativo (seleção) e alteração da lista (adição/remoção).
Esse padrão reduz acoplamento: outros sistemas apenas assinam eventos e reagem quando algo muda, em vez de ficarem consultando estado ou referenciando objetos diretamente. O resultado é um fluxo mais previsível entre simulação e UI.
Movimento autônomo: NavMesh e alvos aleatórios
Com identidade resolvida, entra o desafio de movimentação. A navegação usa NavMesh para delimitar as áreas caminháveis do warehouse. No modo auto, um script de movimento escolhe um alvo aleatório em uma lista, envia o agente até lá e, ao chegar, aguarda um tempo entre 1 e 3 segundos antes de selecionar o próximo destino.
A checagem de chegada considera distância restante, se o caminho ainda está sendo calculado e se o agente realmente parou. Esse conjunto de condições evita trocas de alvo prematuras e dá ao deslocamento um ritmo mais natural, com pausas que sugerem “atividade” em cada ponto.
Controle manual sem quebrar a navegação dos outros
A alternância para manual adiciona uma complicação: o robô controlado não pode virar um “fantasma” para os agentes autônomos. A solução envolve desativar o NavMesh Agent no manual e ativar um NavMesh Obstacle com carving. Assim, o robô abre um “buraco” na NavMesh ao se mover, forçando os demais a recalcularem rotas ao redor.
Ao retornar ao auto, o obstáculo é removido/desativado e o agente volta a navegar normalmente. Esse vai-e-volta mantém coerência espacial: o controle manual não destrói a simulação da frota, apenas muda as regras para aquele elemento no momento certo.
Automação de setup: prefab ganhando componentes ao receber dados
Para não transformar cada importação em um checklist interminável, um script de editor automatiza o setup do prefab. Ao vincular um Scriptable Object a um robô recém-importado (apenas mesh/CAD), o projeto adiciona automaticamente os componentes necessários: configurações de agente, presets de velocidade, rigidbody, collider, simulador de dados e controle de variantes.
Isso reduz erros humanos e acelera iteração, principalmente quando o pipeline envolve reimportar modelos com frequência. O prefab passa a “ganhar vida” no momento em que recebe seu pacote de dados.
Simulador de telemetria e variantes: estado que alimenta a UI
Um simulador de dados complementa a movimentação com variáveis típicas de operação: bateria drenando com deslocamento, degradação/avarias e mudanças de status (warning, critical, dead). Essas alterações são gravadas no Scriptable Object do robô e refletem na UI por meio de cards que mudam de cor e indicadores agregados no resumo da frota.
Já o sistema de variantes controla versões do robô (ou módulos) e seus comportamentos associados, habilitando e desabilitando partes relevantes quando a variante ativa muda. Isso mantém a lógica de visual e funcionamento centralizada em um componente, em vez de espalhada em botões e scripts soltos.
Fechamento: dados primeiro, comportamento depois, UI por assinatura
Essa organização cria um caminho claro: Scriptable Objects guardam identidade e telemetria, scripts conectam e executam comportamento, eventos distribuem mudanças, e a interface consome o estado atualizado sem precisar “adivinhar” o que acontece na cena. O resultado é uma simulação escalável, com robôs autônomos, controle manual consistente e UI reativa.
Fonte: Neriverso