Olá a todos! Hoje vamos dar uma olhada rápida nos bastidores de algumas das tecnologias que sustentam o motor gráfico do Hytale, com foco específico em um dos frameworks que anunciamos recentemente: Flecs — um sistema de componentes de entidade (ECS) leve e poderoso.

Há algum tempo, falamos sobre nossa  decisão de reformular o motor gráfico de Hytale , migrando de um servidor Java e um cliente C# para a construção de ambos em C++. Havia muitos motivos para essa mudança: queríamos garantir que pudéssemos lançar o jogo em múltiplas plataformas; queríamos melhorar o desempenho em dispositivos com especificações mais modestas; e queríamos construir um motor gráfico robusto o suficiente para que pudéssemos atualizar e manter o jogo no futuro.

O ECS é uma das muitas ferramentas que utilizamos para alcançar esses objetivos. Neste post, vamos discutir por que escolhemos o Flecs como base do ECS para o novo motor gráfico do Hytale e como, exatamente, ele nos ajuda a atingi-los.

Mas antes de nos aprofundarmos muito no Flecs em si, precisamos dar uma olhada no ECS — o padrão de sistema de componentes de entidade.

DE UMA SIGLA DE TRÊS LETRAS PARA OUTRA

O conceito de ECS não é exatamente novo, nem tão incomum no desenvolvimento de jogos como era há alguns anos. Mesmo assim, pode parecer complexo e desconhecido para quem o encontra pela primeira vez. Para discuti-lo adequadamente, precisamos contextualizar o conceito de ECS dentro do escopo do desenvolvimento de jogos.

Grande parte do desenvolvimento de jogos tradicional se baseia no modelo consagrado de programação orientada a objetos (POO), ou em arquiteturas de entidade-componente (ou ator-componente!).  A programação orientada a objetos  é predominante no desenvolvimento de software em geral e decompõe problemas em estruturas familiares que podem ser analisadas como objetos. Você pode ter um tipo de objeto Personagem abrangente que fornece a lógica do jogo comum a todos os Personagens, que é então herdada ou especializada por um objeto Jogador, vários objetos NPC e quaisquer outros tipos que possam ser considerados Personagens.

Esta árvore pode se tornar muito larga.

A arquitetura de entidade-componente nos aproxima do ECS (Entidade-Componente) e é a principal arquitetura usada por muitas engines de jogos populares, como Unreal e Unity. Nesse paradigma, temos entidades — unidades individuais como um ‘jogador’, um ‘NPC’, uma ‘cadeira’ — e componentes — uma combinação de dados e funcionalidades que podem ser anexadas a essas entidades. Cada entidade é composta por vários componentes. Se você está familiarizado com Programação Orientada a Objetos (POO), o paradigma de entidade-componente se baseia fortemente no princípio de ‘ composição em vez de herança ‘. Por exemplo: um jogador pode ter uma posição no mundo, a capacidade de ler entradas do controle e um inventário; um NPC também tem uma posição, pode ter um inventário e possui alguma forma de lógica comportamental; nossa cadeira, infelizmente, tem apenas uma posição.

Até que você adicione lógica comportamental a ele e ele se torne uma criatura [ aviso: isso é apenas para fins de demonstração! ]

De imediato, torna-se evidente  o quão libertadora essa estrutura pode ser para a criação de mods . Ela não apenas facilita funcionalidades altamente orientadas a dados por meio da configuração de ativos, onde a simples alteração dos componentes anexados a um NPC ou objeto resulta em comportamentos marcadamente diferentes, como também permite, teoricamente, a criação de funcionalidades completamente novas sem a necessidade de mexer no código existente. Com uma linguagem de script, você pode criar e adicionar seu próprio componente e anexá-lo às entidades nas quais deseja executar esse comportamento. Uma variedade de possibilidades se abre.

Uma entidade pode ser composta de muitas maneiras diferentes!

Mas isso ainda não é ECS. ECS — sistema de entidade-componente — pega esses conceitos e os aprimora. Enquanto no modelo de entidade-componente a funcionalidade (por exemplo, métodos e funções) reside dentro do próprio componente, o ECS desacopla essa funcionalidade dos dados e do estado que processa. Em vez de cada componente ter sua própria lógica de atualização interna, temos sistemas que combinam entidades com conjuntos definidos de componentes e agem sobre eles. Isso significa que, com o ECS, ainda desbloqueamos a mesma capacidade de compor entidades a partir de diferentes componentes, mas o desacoplamento resulta em uma arquitetura de dados e lógica significativamente mais eficiente para o hardware e, portanto, com melhor desempenho. Muitos dos detalhes sobre como o ECS alcança esses benefícios de desempenho são altamente técnicos, mas basta dizer que envolve aproveitar a arquitetura da CPU, estruturar os dados de forma compacta para se beneficiar de sua localidade nos padrões de acesso e usar esses padrões de acesso para paralelizar o máximo de lógica possível.

Os sistemas podem ser compatíveis com qualquer combinação de componentes.

ECS NO MOTOR LEGADO

Sabíamos que queríamos migrar para uma arquitetura ECS mesmo enquanto ainda estávamos desenvolvendo o motor de jogo legado, devido ao aumento de desempenho e escalabilidade que ela nos proporcionaria, além de sua afinidade natural com nossa abordagem orientada a dados para construir e configurar entidades e atores do jogo. Como resultado, desenvolvemos nossa própria implementação em Java do conceito e começamos a integrá-la em todo o servidor legado. Na época, não tínhamos um equivalente para o cliente C#, o que significava que nossa implementação era estritamente para o servidor.

Parte desse trabalho envolveu a refatoração de aspectos da lógica existente para seguir o padrão ECS, mesmo enquanto começávamos a desenvolver novas funcionalidades em paralelo. Aprendemos muitas lições durante esse período, principalmente que implementar um framework ECS robusto e de alto desempenho do zero é uma tarefa incrivelmente desafiadora e demorada. Existem inúmeras variações de ECS, cada uma com seus próprios benefícios e desvantagens, mas todas exigem um profundo conhecimento e especialização técnica para serem executadas com alto padrão. Além disso, Java nem sempre é a linguagem de programação mais eficiente, e fizemos muitas concessões e escolhas de design devido às suas peculiaridades.

Mesmo assim, nossa implementação incipiente do ECS proporcionou benefícios de desempenho notáveis, juntamente com uma nova abordagem para a arquitetura do sistema que incorporava os princípios do design orientado a dados que desejávamos alcançar. Se feito corretamente, poderíamos facilitar para os modders o fornecimento de dados que influenciariam o comportamento do jogo praticamente sem nenhum conhecimento técnico.

UMA BASE SÓLIDA PARA UM NOVO MOTOR

Quando reiniciamos o mecanismo, sabíamos que queríamos continuar usando o ECS, mas também que queríamos estender isso ao cliente, garantindo que colheríamos os benefícios em todos os aspectos possíveis. Sabíamos também que nossa mudança para C++ significaria que poderiam existir outras estruturas disponíveis — estruturas que não precisaríamos construir e manter nós mesmos, com recursos de ponta que expandiriam os limites do paradigma.

Após avaliarmos todas as opções disponíveis, optamos pelo Flecs — um framework ECS altamente refinado, escrito e mantido por um especialista em ECS:  Sander Mertens .

De imediato, ele nos dá acesso a uma variedade de recursos comuns à maioria das implementações de ECS, além de excelente desempenho e compatibilidade multiplataforma. Por ser escrito inteiramente em C com uma API em C++, é significativamente mais rápido do que qualquer implementação em C# ou Java poderia sonhar em ser, permitindo-nos aproveitar ao máximo sua implementação inteligente de paralelização e multithreading. Outro benefício óbvio é que não precisamos mantê-lo nós mesmos — o Flecs é testado em produção, recebe atualizações e correções de bugs frequentes e, com seu conjunto abrangente de testes, podemos ter relativa certeza de sua estabilidade.

Mas talvez o aspecto mais atraente tenha sido o amplo conjunto de recursos que vão além do que um framework ECS tradicional oferece, proporcionando uma flexibilidade que eleva o ECS a um novo patamar. Um exemplo disso é o conceito de “relacionamentos”. Assim como os componentes, os relacionamentos são dados que podem ser associados a uma entidade, mas esses dados são usados ​​para conectar uma entidade a outra. Um relacionamento pai-filho é um bom exemplo disso, onde uma entidade de jogador pode ter uma entidade de câmera como filha, que a segue. Outro exemplo poderia ser ainda mais literal: a Entidade A curte a Entidade B. Usando essa estrutura, podemos facilmente executar consultas como “encontre todas as entidades que curtem a Entidade B” ou “encontre todas as entidades que a Entidade B curte”.

Em muitos aspectos, um ECS é semelhante a um banco de dados, e o Flecs aproveita ao máximo esse fato. O mecanismo de regras subjacente é uma ferramenta poderosa que suporta consultas de dados de diversas maneiras, desde simples correspondências entre sistemas (por exemplo, um sistema que atualiza o crescimento de plantações com base em vários componentes conectados) até buscas complexas para lógica de jogo ou depuração (por exemplo, encontrar todos os NPCs que portam espadas e são agressivos com o jogador). Além disso, o mecanismo de compartilhamento de componentes nos permite criar um tipo de ator base, como um Personagem, e definir que um NPC ou um Jogador é um Personagem, dando-nos acesso à herança no estilo OOP, mas otimizada para se beneficiar das vantagens do ECS.

Por vezes, algumas dessas funcionalidades podem ser difíceis de compreender, como costuma acontecer ao aprender uma arquitetura completamente nova. Mesmo assim, uma vez compreendidas e dominadas, elas proporcionam ferramentas extremamente poderosas para o desenvolvimento de jogos.

PENSAMENTO MAIS RÁPIDO

Para concluir, vamos examinar um exemplo disso. No passado, introduzimos um aprimoramento para os NPCs de Hytale chamado  Avaliador de Ações de Combate . Trata-se de uma estrutura projetada para permitir que os NPCs tomem decisões mais inteligentes e “imprecisas” sobre qual ataque usar e em qual alvo usá-lo, com base em uma série de entradas altamente configuráveis. Embora originalmente implementado no motor gráfico legado, ele foi projetado para ser orientado a dados desde a sua concepção, com cada entrada individual conectada de maneira semelhante aos componentes em um ECS (Sistema de Controle de Eventos).

Embora cumprisse seu propósito admiravelmente no motor gráfico legado e fornecesse NPCs de combate que, por vezes, podiam ser confundidos com jogadores humanos, limitações tiveram que ser impostas devido ao seu potencial impacto no desempenho geral do jogo. Afinal, permitir que NPCs tomassem decisões “imprecisas” com base em uma quantidade enorme de dados de entrada em um ambiente de programação orientada a objetos significa uma carga de processamento significativa — uma que nosso motor gráfico pré-ECS baseado em Java não estava equipado para suportar. Assim, executávamos o avaliador de ações de combate apenas em intervalos irregulares. Isso poderia significar que evitaríamos qualquer potencial lentidão do servidor causada por um grande número de NPCs em combate ativo, mas também significava que eles tomariam decisões mais lentamente no geral — lentas o suficiente para serem perceptíveis ao jogador.

Com o Flecs, nossas opções de design de jogabilidade não são tão limitadas por preocupações de desempenho. Ao redesenhar a estrutura interna seguindo os padrões ECS e fazendo amplo uso dos recursos do Flecs, chegamos a um equivalente que não precisa mais processar esses dados de maneira tão ineficiente. Em vez disso, podemos agrupar de forma inteligente todas as consultas que verificam informações específicas e paralelizá-las, resultando em tempos de processamento muito mais rápidos e eliminando a necessidade de limitações artificiais na frequência de avaliação. Enquanto no mecanismo legado realizávamos nossas verificações sequencialmente (priorizando as mais custosas para que pudéssemos encerrar mais cedo se falhassem!), agora todas podem acontecer simultaneamente, com o mecanismo de consultas do Flecs cuidando do trabalho pesado.

Em essência, isso significa que os NPCs podem pensar mais rápido — reagindo às mudanças no ambiente e em seus arredores de forma muito mais ágil do que jamais poderiam no motor gráfico anterior.

PARA O FUTURO

Em última análise, isso apenas arranha a superfície do que é possível com Flecs e ECS. Muitas outras partes do motor oferecem oportunidades interessantes para otimização em torno do ECS, desde o banco de dados de ativos até a geração de mundo em etapas, e à medida que tanto o Flecs quanto o motor Hytale continuam a evoluir, esperamos que as possibilidades só aumentem.