design architecture game-engine entity-system entity-component-system

design - Diseño de motor de juego basado en componentes



architecture game-engine (8)

He estado estudiando el diseño de motores de juegos (específicamente centrado en los motores de juegos 2d, pero también aplicable a los juegos en 3D), y estoy interesado en cierta información sobre cómo hacerlo. He escuchado que muchos motores se están moviendo a un diseño basado en componentes en la actualidad en lugar de a la tradicional jerarquía de objetos profundos.

¿Conoce algún buen enlace con información sobre cómo se implementan a menudo este tipo de diseños? He visto cómo evoluciona su jerarquía , pero realmente no puedo encontrar muchos más con información detallada (la mayoría de ellos parece decir "usar componentes en lugar de una jerarquía", pero he descubierto que se necesita un poco de esfuerzo para cambiar mi forma de pensar entre los dos modelos).

Cualquier buen enlace o información sobre esto sería apreciado, e incluso libros, aunque se preferirían enlaces y respuestas detalladas aquí.



Artículo interesante ...

He tenido una búsqueda rápida en google y no he encontrado nada, pero es posible que desee revisar algunos de los comentarios. Parece que mucha gente ha intentado implementar una demostración de componentes simple, es posible que desee echar un vistazo a algunos de ellos para inspirarse

http://www.unseen-academy.de/componentSystem.html
http://www.mcshaffry.com/GameCode/thread.php?threadid=732
http://www.codeplex.com/Wikipage?ProjectName=elephant

Además, los comentarios en sí parecen tener una discusión bastante profunda sobre cómo podría codificar un sistema de este tipo.


En este contexto, los componentes me suenan como porciones de tiempo de ejecución aisladas de un motor que pueden ejecutarse simultáneamente con otros componentes. Si esta es la motivación, entonces es posible que desee ver el modelo de actor y los sistemas que lo utilizan.



Investigué e implementé este último semestre para un curso de desarrollo de juegos. Esperamos que este código de ejemplo pueda señalarle la dirección correcta de cómo podría abordar esto.

class Entity { public: Entity(const unsigned int id, const std::string& enttype); ~Entity(); //Component Interface const Component* GetComponent(const std::string& family) const; void SetComponent(Component* newComp); void RemoveComponent(const std::string& family); void ClearComponents(); //Property Interface bool HasProperty(const std::string& propName) const; template<class T> T& GetPropertyDataPtr(const std::string& propName); template<class T> const T& GetPropertyDataPtr(const std::string& propName) const; //Entity Interface const unsigned int GetID() const; void Update(float dt); private: void RemoveProperty(const std::string& propName); void ClearProperties(); template<class T> void AddProperty(const std::string& propName); template<class T> Property<T>* GetProperty(const std::string& propName); template<class T> const Property<T>* GetProperty(const std::string& propName) const; unsigned int m_Id; std::map<const string, IProperty*> m_Properties; std::map<const string, Component*> m_Components; };

Los componentes especifican el comportamiento y operan en las propiedades. Las propiedades se comparten entre todos los componentes mediante una referencia y se obtienen actualizaciones de forma gratuita. Esto significa que no hay grandes gastos generales para el paso de mensajes. Si hay alguna pregunta, intentaré responder lo mejor que pueda.


Parece que hay una falta de información sobre el tema. Recientemente implementé este sistema, y ​​encontré un muy buen Powerpoint de GDC que explicaba los detalles que a menudo quedan bastante bien. Ese documento está aquí: Teoría y práctica de la arquitectura de componentes de objetos de juego

Además de ese Powerpoint, hay algunos buenos recursos y varios blogs . PurplePwny tiene una buena discusión y enlaces a otros recursos. Ugly Baby Studios tiene un poco de discusión sobre la idea de cómo los componentes interactúan entre sí. ¡Buena suerte!


Si bien no es un tutorial completo sobre el tema del diseño de motores de juegos, he encontrado que esta página tiene algunos buenos detalles y ejemplos sobre el uso de la arquitectura de componentes para juegos.


Actualización 2013-01-07 : Si desea ver una buena combinación de motor de juego basado en componentes con el enfoque superior (en mi opinión) de programación reactiva, eche un vistazo al motor V-Play . Se integra muy bien QTs QML funcionalidad de enlace de propiedad .

Hicimos algunas investigaciones sobre CBSE en juegos en nuestra universidad y recopilé algo de material a lo largo de los años:

CBSE en la literatura de juegos:

  • Arquitectura del motor del juego
  • Juego de programación Gems 4: un sistema para administrar el juego Entidades del juego
  • Juego de programación Gems 5: Gestión de objetos basada en componentes
  • Programación del juego Gems 5: A Genérico Component Library
  • Juego de programación Gems 6: Sistema de componentes de objetos de juego
  • Desarrollo de juegos orientados a objetos
  • Architektur des Kerns einer Game-Engine und Implementierung mit Java (alemán)

Un ejemplo muy bueno y limpio de un motor de juego basado en componentes en C # es el marco del juego Elephant .

Si realmente desea saber qué componentes se leen: ¡Ingeniería de software basada en componentes! Definen un componente como:

Un componente de software es un elemento de software que se ajusta a un modelo de componente y se puede implementar y componer de forma independiente sin modificaciones de acuerdo con un estándar de composición.

Un modelo de componente define estándares específicos de interacción y composición. Una implementación de modelo de componente es el conjunto dedicado de elementos de software ejecutables necesarios para admitir la ejecución de componentes que se ajustan al modelo.

Una infraestructura de componentes de software es un conjunto de componentes de software interactivos diseñados para garantizar que un sistema o subsistema de software construido utilizando esos componentes e interfaces satisfarán especificaciones de rendimiento claramente definidas.

Mis opiniones después de 2 años de experiencia con CBSE en juegos pensados ​​son que la programación orientada a objetos es simplemente un callejón sin salida. Recuerde mi advertencia mientras observa que sus componentes se vuelven cada vez más pequeños, y más como funciones empaquetadas en componentes con una gran cantidad de gastos generales inútiles. Utilice la programación funcional-reactiva en su lugar. También eche un vistazo a mi nueva publicación en el blog (que me llevó a esta pregunta al escribirla :)) sobre Por qué cambié de la arquitectura del motor de juego basado en componentes a FRP .

CBSE en papeles de juegos:

CBSE en los enlaces web de juegos (ordenados por relevancia):