ECS orientado a dados: propriedade e iteração antes dos rótulos de arquitetura

Comece pelo trabalho a ser feito

Uma arquitetura entity-component-system (ECS) é útil quando facilita a organização dos dados e do processamento do jogo. O rótulo, por si só, não promete velocidade nem simplicidade. Comece por uma operação executada com frequência: identifique os campos que ela lê, os campos que ela escreve e as entidades que de fato precisam dessa operação.

Identidade, dados e sistemas

As entidades fornecem a identidade, os componentes associam dados às entidades e os sistemas operam sobre combinações selecionadas de componentes. O Flecs documenta esses papéis e os sistemas orientados por queries. [1] O armazenamento por arquétipos agrupa conjuntos de componentes iguais; o Unity Entities guarda esses dados em chunks, e mudanças estruturais podem mover entidades de um grupo para outro. [2] Outras estratégias de armazenamento de ECS fazem compromissos diferentes.

Exemplo prático

Considere uma atualização ilustrativa para 20000 faíscas em movimento. Cada uma exige posição e velocidade de três componentes, e cada componente é representado por um float de 4-byte. O volume de dados do movimento é 20000 × 6 × 4 = 480000 bytes.

Um registro monolítico hipotético de 128 bytes por faísca ocuparia 2560000 bytes, incluindo campos sem relação com o movimento. Esses cálculos de volume de dados não estabelecem o tráfego real de cache nem um ganho de desempenho: alinhamento, padding, ocupação dos chunks e padrões de acesso continuam importando. O que eles justificam é testar se o laço crítico consegue percorrer arrays compactos de Position e Velocity sem seguir ponteiros por objeto.

Defina o sistema de integração para ler Velocity e escrever Position. Um sistema de tempo de vida é responsável pela expiração. Enfileire as remoções para um limite documentado de mudança estrutural, em vez de invalidar a travessia em andamento. A renderização pode ler as posições resultantes depois que a dependência necessária for concluída.

Fluxo de trabalho prático

Mapeie as leituras e escritas dos sistemas antes de agendar trabalho em paralelo. Dois sistemas que escrevem no mesmo componente exigem uma ordem de execução ou uma partição segura. Handles estáveis de entidade devem sobreviver à movimentação do armazenamento; endereços de componentes mantidos em cache podem não sobreviver. Especifique quando as queries e as referências precisam ser atualizadas.

Mantenha os campos de alta frequência perto da operação que os utiliza e separe os dados volumosos e pouco usados quando as medições justificarem. Examine a quantidade de arquétipos, a ocupação dos chunks, o custo das mudanças estruturais e as consultas aleatórias. Uma relação entre entidades que salta repetidamente para áreas de armazenamento sem relação pode dominar o custo de uma atualização que, fora isso, seria linear.

Compromissos e validação

Adicionar e remover componentes não é gratuito em todo ECS. Muitas combinações minúsculas de componentes podem fragmentar a carga de trabalho, enquanto um componente gigante pode fazer sistemas não relacionados tocarem dados em excesso. Escolha a granularidade com base na propriedade dos dados e no acesso medido, não numa regra segundo a qual cada valor escalar mereça um componente.

Compare cenas representativas com comportamento idêntico e inclua criação, destruição e transições. Avalie o custo total do frame e a memória, não apenas o melhor laço interno. Em um jogo pequeno, com objetos muito individualizados, pode ser razoável usar objetos convencionais em paralelo com uma simulação em massa gerenciada pelo ECS.

Fontes

[1] Flecs quickstart — Sander Mertens e colaboradores do Flecs.

[2] Archetype concepts — documentação do Unity Entities.