Resumen de estados de animación del sistema de entidades

Recientemente comencé a diseñar un Game Engine usando el paradigma del Sistema de entidades, es decir, tener entidades como una agregación de componentes y sistemas que implementan el juego real. Mientras que he tenido dificultades en varios aspectos, lo que más me preocupa es la abstracción / modularidad de los diversos Componentes / Sistemas. Específicamente, digamos que my Playertiene varios estados de animación, por ejemplo. Walking, Sleeping, Jumping, Y un tipo de Opponententidad tiene varias (no necesariamente los mismos) estados, así, por ejemplo. Walking, HidingEtc.

¿Cómo debo diseñar el motor, para que maneje los diversos estados (animación) de cada tipo de entidad? ¿Debería haber diferentes sistemas de animación para cada tipo de entidad? ¿Debo usar banderas que señalen al sistema de animación para representar la entidad correcta? Además, ¿puedo evitar el uso de enumeraciones "codificadas" para las diferentes poses? Puedo ver que un sistema de secuencias de comandos probablemente podría ayudar, pero estoy casi seguro de que hay una solución más simple.

animation entity-system

— Petermer
fuente

No a los diferentes sistemas para cada tipo, eso está reduciendo la división de responsabilidad demasiado bien.

Esto es lo que estoy haciendo en mi proyecto personal actual:

Hay muchas formas de manejar el estado, pero probablemente necesite una que tenga sentido para los humanos, o al menos un puente entre humanos y código. Debe pensar en el sistema de animación como una gran licuadora en lugar de uno de estados discretos, por ejemplo, pasa de inactivo a caminar lentamente agregando 50% de caminata al sistema y luego agrega 100% de carrera.

Externo al sistema de animación, puede usar cadenas para hacer que trabajar con el sistema sea agradable y fácil de escribir y codificar por igual. Internamente en el sistema, usted construye un mapeo entre esa cadena y los datos de animación , esto se puede hacer con un almacén de valores clave como un hashmap (para evitar enumeraciones por completo al hacer que los datos de animación sean el almacén) o con una cadena para enumerar busca si te gusta trabajar de esa manera. Todo es cuestión de gustos en ese momento. Prefiero el valor-clave ya que puede estar totalmente basado en datos desde archivos XML o INI.

Para manejar diferentes tipos, puede, en la capa del sistema, crear conjuntos de mapeo de animaciones para que el conjunto de "minion" y "run" para el "minion" sea diferente del conjunto de "run" y "female player" tipo.

En resumen: el sistema de animación es genérico y solo tiene un sistema; el mundo exterior necesita una interfaz amigable; el mundo interior necesita mapear estados genéricos a tipos de entidad.

Y mi lista de cosas que quiero hacer pero que aún no encajan en mi diseño:

TODO : asigna automáticamente la velocidad de movimiento al tipo de animación, de modo que en lugar de que el programa principal sepa sobre "caminar" versus "correr", el sistema de animación puede convertir "moverse a velocidad x" en la animación adecuada.

TODO : divide las animaciones como el seguimiento de la cabeza y el torso de manera transparente.

TODO : animaciones de reacción (como recibir un puñetazo en la cara) manejadas por el sistema y no por el programa principal.

— Patrick Hughes
fuente

Entonces, sugiere usar un par de if's dentro del sistema de animación; Anteriormente era escéptico sobre el uso de diccionarios de cadenas (en C ++), en cuanto a memoria. Sin embargo, después de leer hoy sobre las tablas hash, su respuesta me parece bastante simple. En cuanto a la parte de 'licuadora': ¿significa "agregar 50% de caminata" significa reemplazar algunos cuadros por los de "caminar" en el 50% del tiempo?

— Peter

Mezclar es un término bastante común en animación, literalmente significa que combina dos (o más) animaciones base para obtener la salida final. En el ejemplo del 50%, supongo una combinación de 50% "Inactivo" y 50% "Caminata" que produciría un paseo de media velocidad hacia adelante. De esta manera, puede variar continuamente el movimiento de "Inactivo" a "Caminar" y luego "Correr". Más tarde, la combinación le permitirá hacer cosas como hacer que el torso inferior funcione mientras el torso superior dispara un arma o saluda a alguien, etc. Si su motor de animación no admite la combinación, use esto como una forma de pensarlo y no una regla

— Patrick Hughes

FYI: preocuparse por la memoria para las cadenas en su programa en esta etapa es tiempo perdido, eso se llama "optimización prematura" y generalmente es una mala idea. Más adelante, si las cadenas realmente ESTÁN causando una gran carga, se pueden convertir en números CRC cortos para reducirlos considerablemente, a expensas de la facilidad de depuración y un paso adicional para su proceso de compilación.

— Patrick Hughes