Abstraindo estados de animação do sistema de entidades


8

Recentemente, comecei a projetar um Game Engine usando o paradigma do sistema de entidades, ou seja, tendo entidades como uma agregação de componentes e sistemas que implementam o jogo real. Considerando que tive dificuldades em vários aspectos, o que mais me preocupa é a abstração / modularidade dos vários componentes / sistemas. Especificamente, digamos que o meu Playertenha vários estados de animação, por exemplo. Walking, Sleeping, Jumping, E um tipo de Opponententidade tem vários (não necessariamente os mesmos) estados, bem como, por exemplo. Walking, HidingEtc.

Como devo projetar o mecanismo, para que ele lide com os vários estados (animação) de cada tipo de entidade? Deveria haver diferentes sistemas de animação para cada tipo de entidade? Devo usar sinalizadores que sinalizem o sistema de animação para renderizar a entidade correta? Além disso, posso evitar o uso de enumerações "codificadas" nas várias poses? Percebo que um sistema de script provavelmente poderia ajudar, mas tenho quase certeza de que existe uma solução mais simples.

Respostas:


4

Não para sistemas diferentes para cada tipo, isso reduz muito a divisão de responsabilidades.

Isto é o que estou fazendo no meu projeto pessoal atual:

Existem muitas maneiras de lidar com o estado, mas você provavelmente precisa de uma que faça sentido para os seres humanos, ou pelo menos uma ponte entre humano e código. Você precisa pensar no sistema de animação como um grande liquidificador em vez de um estado discreto; por exemplo, você passa do modo inativo para o lento, adicionando 50% de caminhada ao sistema e depois adiciona 100% de execução.

Externo ao sistema de animação, você pode usar seqüências de caracteres para tornar o trabalho com o sistema agradável e fácil para scripts e códigos. Internamente ao sistema, você cria um mapeamento entre essa sequência e os dados da animação , isso pode ser feito com um armazenamento de valores-chave como um mapa de hash (para evitar enumerações tornando os dados da animação no armazenamento) ou com uma sequência de caracteres para enum pesquisa se você gosta de trabalhar dessa maneira. É tudo uma questão de gosto nesse ponto. Eu prefiro o valor-chave, pois ele pode ser totalmente direcionado por dados de arquivos XML ou INI.

Para lidar com tipos diferentes, você pode, na camada do sistema, criar conjuntos de mapeamentos de animações para que o conjunto para "minion" e "run" para o "minion" sejam diferentes do conjunto para "run" e "female player" tipo.

Em resumo: o sistema de animação é genérico e você possui apenas um sistema; o mundo exterior precisa de uma interface amigável; o mundo interno precisa mapear estados genéricos para tipos de entidade.

E minha lista de coisas que quero fazer, mas ainda não se enquadram no meu design:

TODO : mapeando a velocidade do movimento para o tipo de animação automaticamente, em vez de o programa principal saber sobre "andar" versus "executar", o sistema de animação pode converter "mover na velocidade x" para a animação adequada.

TODO : animações divididas, como rastreamento de cabeça e tronco de forma transparente.

TODO : animações de reação (como levar um soco na cara) manipuladas pelo sistema e não pelo programa principal.


Então, você sugere usar alguns ifdentro do sistema de animação; Eu era cético em relação ao uso de dicionários de strings (em C ++), em termos de memória. Depois de ler hoje sobre as hashtables, acho sua resposta bastante simples. Com relação à parte do 'liquidificador': "adicionar 50% de caminhada" significa substituir algumas molduras pelas da 'caminhada' em 50% das vezes?
Petermer

Mistura é um termo bastante comum em animação, significa literalmente que você mistura duas (ou mais) animações básicas para obter a saída final. No exemplo de 50%, estou assumindo uma mistura de 50% "Idle" e 50% "Walk", o que produziria um passeio de meia velocidade adiante. Dessa forma, você pode variar continuamente o movimento de "Ocioso" para "Caminhar" e depois "Executar". Mais tarde, a mistura permitirá que você faça coisas como torso inferior correndo enquanto o tronco superior está disparando uma arma ou acenando para alguém, etc ... Se o seu mecanismo de animação não suportar a mistura, use isso como uma maneira de pensar sobre isso e não uma regra.
Patrick Hughes

11
FYI: preocupar-se com a memória de seqüências de caracteres em seu programa nesse estágio é perda de tempo, isso é chamado de "otimização prematura" e geralmente é uma má idéia. Posteriormente, se as strings realmente estiverem causando uma carga enorme, elas poderão ser transformadas em números curtos de CRC para reduzir consideravelmente todas, à custa da facilidade de depuração e de uma etapa extra no processo de criação.
Patrick Hughes
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.