¿Qué diseños hay para un sistema de entidad basado en componentes que sea fácil de usar pero flexible?

He estado interesado en el sistema de entidades basado en componentes por un tiempo, y leí innumerables artículos sobre él (los juegos Insomiac , el bastante estándar Evolve Your Hierarchy , T-Machine , Chronoclast ... solo por nombrar algunos).

Todos parecen tener una estructura en el exterior de algo como:

Entity e = Entity.Create();
e.AddComponent(RenderComponent, ...);
//do lots of stuff
e.GetComponent<PositionComponent>(...).SetPos(4, 5, 6);

Y si trae la idea de datos compartidos (este es el mejor diseño que he visto hasta ahora, en términos de no duplicar datos en todas partes)

e.GetProperty<string>("Name").Value = "blah";

Sí, esto es muy eficiente. Sin embargo, no es exactamente el más fácil de leer o escribir; se siente muy torpe y trabajando contra ti.

Personalmente me gustaría hacer algo como:

e.SetPosition(4, 5, 6);
e.Name = "Blah";

Aunque, por supuesto, la única forma de llegar a ese tipo de diseño es de vuelta en el tipo de jerarquía Entity-> NPC-> Enemy-> FlyingEnemy-> FlyingEnemyWithAHatOn que este diseño intenta evitar.

¿Alguien ha visto un diseño para este tipo de sistema de componentes que aún sea flexible, pero que mantenga un nivel de facilidad de uso? Y para el caso, ¿logra sortear el almacenamiento de datos (probablemente el problema más difícil) de una buena manera?

¿Qué diseños hay para un sistema de entidad basado en componentes que sea fácil de usar pero flexible?

Una de las cosas que hace Unity es proporcionar algunos accesos de ayuda en el objeto del juego principal para proporcionar un acceso más fácil de usar a los componentes comunes.

Por ejemplo, puede tener su posición almacenada en un componente Transformar. Usando su ejemplo, tendría que escribir algo como

e.GetComponent<Transform>().position = new Vector3( whatever );

Pero en Unity, eso se simplifica a

e.transform.position = ....;

Donde transformes literalmente un simple método auxiliar en la GameObjectclase base ( Entityclase en su caso) que hace

Transform transform
{ 
    get { return this.GetComponent<Transform>(); }
}

Unity también hace algunas otras cosas, como establecer una propiedad "Nombre" en el objeto del juego en lugar de en sus componentes secundarios.

Personalmente, no me gusta la idea de su diseño de datos compartidos por nombre. Acceder a las propiedades por nombre en lugar de por una variable y hacer que el usuario también tenga que saber de qué tipo es, me parece muy propenso a errores. Lo que hace Unity es que usan métodos similares como la GameObject transformpropiedad dentro de las Componentclases para acceder a los componentes hermanos. Entonces, cualquier componente arbitrario que escriba simplemente puede hacer esto:

var myPos = this.transform.position;

Para acceder al puesto. Donde esa transformpropiedad hace algo como esto

Transform transform
{
    get { return this.gameObject.GetComponent<Transform>(); }
}

Claro, es un poco más detallado que solo decir e.position = whatever, pero te acostumbras y no parece tan desagradable como las propiedades genéricas. Y sí, tendría que hacerlo de la manera indirecta para los componentes de su cliente, pero la idea es que todos sus componentes comunes de "motor" (renderizadores, colisionadores, fuentes de audio, transformaciones, etc.) tengan los accesos fáciles.

Sugeriría algún tipo de clase de interfaz para sus objetos de entidad sería bueno. Podría hacer el manejo de errores con la verificación para asegurarse de que una entidad contenga un componente del valor apropiado también en una ubicación para que no tenga que hacerlo en todas partes donde acceda a los valores. Alternativamente, la mayoría de los diseños que he hecho con un sistema basado en componentes, trato directamente con los componentes, solicitando, por ejemplo, su componente posicional y luego accediendo / actualizando las propiedades de ese componente directamente.

Muy básico en un nivel alto, la clase abarca la entidad en cuestión y proporciona una interfaz fácil de usar para las partes componentes subyacentes de la siguiente manera:

public class EntityInterface
{
    private Entity entity { get; set };
    public EntityInterface(Entity e)
    {
        entity = e;
    }

    public Vector3 Position
    {
        get
        {
            return entity.GetProperty<Vector3>("Position");
        }
        set
        {
            entity.GetProperty<Vector3>("Position") = value;
        }
    }
}

En Python puede interceptar la parte 'setPosition' a e.SetPosition(4,5,6)través de declarar una __getattr__función en Entity. Esta función puede recorrer en iteración los componentes y encontrar el método o propiedad apropiados y devolverlos, de modo que la llamada a la función o la asignación vayan al lugar correcto. Tal vez C # tenga un sistema similar, pero podría no ser posible debido a que está tipado estáticamente; presumiblemente no puede compilarse a e.setPositionmenos que e haya establecido la posición en la interfaz en alguna parte.

También podría hacer que todas sus entidades implementen las interfaces relevantes para todos los componentes que pueda agregarles, con métodos de código auxiliar que generan una excepción. Luego, cuando llama a addComponent, simplemente redirige las funciones de la entidad para la interfaz de ese componente al componente. Aunque un poco complicado.

Pero quizás más fácil sería sobrecargar el operador [] en la clase de entidad para buscar los componentes unidos por la presencia de una propiedad válida y volver que, por lo que se puede asignar a este modo: e["Name"] = "blah". Cada componente deberá implementar su propio GetPropertyByName y la Entidad llama a cada uno por turnos hasta que encuentre al componente responsable de la propiedad en cuestión.

Para ampliar la respuesta de Kylotan, si está utilizando C # 4.0, puede escribir estáticamente una variable para que sea dinámica .

Si hereda de System.Dynamic.DynamicObject, puede anular TryGetMember y TrySetMember (entre los muchos métodos virtuales) para interceptar nombres de componentes y devolver el componente solicitado.

dynamic entity = EntityRegistry.Entities[1000];
entity.MyComponent.MyValue = 100;

Escribí un poco sobre los sistemas de entidades a lo largo de los años, pero supongo que no puedo competir con los gigantes. Algunas notas de ES (algo desactualizadas y no reflejan necesariamente mi comprensión actual de los sistemas de entidades, pero vale la pena leer, en mi humilde opinión).

Veo mucho interés aquí en ES en C #. Echa un vistazo a mi puerto de la excelente implementación de ES Artemis:

https://github.com/thelinuxlich/artemis_CSharp

Además, un juego de ejemplo para que comiences cómo funciona (usando XNA 4): https://github.com/thelinuxlich/starwarrior_CSharp

¡Sugerencias son bienvenidas!

Decidí usar el excelente sistema de reflexión de C #. Lo basé en el sistema de componentes generales, más una mezcla de las respuestas aquí.

Los componentes se agregan muy fácilmente:

Entity e = new Entity(); //No templates/archetypes yet.
e.AddComponent(new HealthComponent(100));

Y se puede consultar por nombre, tipo o (si son comunes, como Salud y Posición) por propiedades:

e["Health"] //This, unfortunately, is a bit slower since it requires a dict search
e.GetComponent<HealthComponent>()
e.Health

Y eliminado:

e.RemoveComponent<HealthComponent>();

A los datos se accede nuevamente por propiedades:

e.MaxHP

Que se almacena en el lado del componente; menos gastos generales si no tiene HP:

public int? MaxHP
{
get
{

    return this.Health.MaxHP; //Error handling returns null if health isn't here. Excluded for clarity
}
set
{
this.Health.MaxHP = value;
}

Intellisense en VS ayuda a la gran cantidad de tipeo, pero en su mayor parte hay poco tipeo, lo que estaba buscando.

Detrás de escena, estoy almacenando Dictionary<Type, Component>y Componentsanulando el ToStringmétodo para verificar nombres. Mi diseño original usaba principalmente cadenas para nombres y cosas, pero se convirtió en un cerdo con el que trabajar (oh, mira, también tengo que lanzar en todas partes la falta de propiedades de fácil acceso).