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




architecture game-engine entity-system entity-component-system (8)

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):

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.


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.




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.


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!


Obtenemos variaciones sobre esta pregunta tres o cuatro veces a la semana en GameDev.net (donde el objeto de juego generalmente se llama una 'entidad') y hasta ahora no hay consenso sobre el mejor enfoque. Sin embargo, se ha demostrado que varios enfoques diferentes son viables, por lo que no me preocuparía demasiado.

Sin embargo, generalmente los problemas se refieren a la comunicación entre componentes. Rara vez la gente se preocupa por obtener información de un componente a la entidad: si una entidad sabe qué información necesita, es probable que sepa exactamente a qué tipo de componente necesita acceder y a qué propiedad o método necesita recurrir para obtener ese componente. los datos. Si necesita ser reactivo en lugar de activo, registre las devoluciones de llamada o configure un patrón de observador con los componentes para que la entidad sepa cuándo ha cambiado algo en el componente y lea el valor en ese punto.

Los componentes completamente genéricos son en gran medida inútiles: necesitan proporcionar algún tipo de interfaz conocida, de lo contrario, no tienen mucho sentido. De lo contrario, también puede tener una gran variedad asociativa de valores sin tipo y terminar con ella. En Java, Python, C # y otros lenguajes de nivel ligeramente superior a C ++, puede usar la reflexión para ofrecerle una forma más genérica de usar subclases específicas sin tener que codificar información de tipo e interfaz en los componentes.

En cuanto a la comunicación:

Algunas personas están asumiendo que una entidad siempre contendrá un conjunto conocido de tipos de componentes (donde cada instancia es una de varias subclases posibles) y, por lo tanto, solo puede tomar una referencia directa al otro componente y leer / escribir a través de su interfaz pública.

Algunas personas están utilizando publicación / suscripción, señales / ranuras, etc., para crear conexiones arbitrarias entre componentes. Esto parece un poco más flexible pero, en última instancia, aún necesita algo con el conocimiento de estas dependencias implícitas. (Y si esto se conoce en tiempo de compilación, ¿por qué no usar el enfoque anterior?)

O bien, puede poner todos los datos compartidos en la propia entidad y usarlos como un área de comunicación compartida (tenuemente relacionada con el sistema de pizarra en AI) en la que cada uno de los componentes puede leer y escribir. Por lo general, esto requiere cierta robustez ante ciertas propiedades que no existen cuando usted esperaba que lo hicieran. Tampoco se presta para el paralelismo, aunque dudo que sea una preocupación masiva en un pequeño sistema integrado ...

Finalmente, algunas personas tienen sistemas donde la entidad no existe en absoluto. Los componentes viven dentro de sus subsistemas y la única noción de una entidad es un valor de ID en ciertos componentes: si un componente de Rendering (dentro del sistema de Rendering) y un componente de Player (dentro del sistema de Players) tienen la misma ID, entonces puede asumir que el primero se encarga del dibujo del segundo. Pero no hay ningún objeto único que agregue cualquiera de esos componentes.





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