Si una Entidad no tiene un 'tipo' explícito (por ejemplo, jugador) y es simplemente una colección de componentes, ¿cómo identifico las entidades en las que mis sistemas deberían y no deberían estar trabajando? Por ejemplo, en un juego de Pong, la paleta y la pelota chocan con los límites de la ventana. Sin embargo, los sistemas de manejo de colisiones para cada uno serán diferentes, por lo tanto, un sistema no debe manejar entidades del tipo incorrecto.
void PlayerCollisionSystem::update(std::vector<Entity *> entities) {
typedef std::vector<Entity *>::iterator EIter;
for (EIter i = entities.begin(); i != entities.end(); ++i) {
Entity *player = *i; // How do I verify that the entity is a player?
// Get relevant components.
PositionComponent *position = player->getComponent<PositionComponent>();
VelocityComponent *velocity = player->getComponent<VelocityComponent>();
SpriteComponent *sprite = player->getComponent<SpriteComponent>();
// Detect and handle player collisions using the components.
}
}Tanto el jugador como la pelota comparten los mismos tipos de componentes relevantes para el manejo de colisiones, pero sus implementaciones del sistema serán diferentes.
Si tengo un contenedor de todas las entidades del juego, ¿cómo identifico tipos específicos de entidad sin heredar Entityo incluir una variable miembro como std::string type, en cuyo caso, una entidad ya no es simplemente una colección de componentes?
fuente
Un sistema solo es útil si es útil. Si un sistema donde una entidad es "simplemente una colección de componentes" es menos útil que un sistema donde una entidad es principalmente una "colección de componentes", entonces haga eso .
Deje de intentar hacer sistemas "puros" y concéntrese en hacer buenos que hagan lo que necesita. Use componentes hasta que los componentes ya no sean útiles para usted. Entonces usa algo más.
Ya has pasado más tiempo pensando en esto de lo que merece.
fuente
Si desea dar a las entidades un tipo explícito, la forma más fácil es definir una variable de tipo en la clase de entidad. Solo mantenga el patrón CE siempre que sea útil.
De lo contrario, el tipo está implícito a través de los atributos del componente. Por ejemplo, el componente de física tendría un atributo para móvil frente a estacionario. El sistema entonces sabe cuándo chocan dos móviles (pelota y paleta). Del mismo modo, puede tener atributos sobre cómo debe responder el sistema de colisión. ¿Solo detiene el objeto o lo refleja? Mirar los atributos debería darle una idea de lo que es la entidad, pero debería ser irrelevante. Los sistemas no deberían necesitar saber con qué tipo de entidad están trabajando, se les debe dar suficiente información utilizando los componentes que se les proporcionan.
Finalmente, puede agregar un componente adicional que contenga un tipo, pero, al igual que al agregar un tipo a la entidad, terminará escribiendo una gran cantidad de código específico de tipo, lo que anulará el propósito del sistema de la CE.
fuente
Una entidad es un conjunto de componentes. No puede asignar etiquetas ordenadas a un conjunto aleatorio. Renunciar a las restricciones de tipo es el precio de la gran flexibilidad.
Por supuesto, puede tener clases de entidad especiales (tipificadas) que imponen restricciones a los componentes.
Idealmente, los componentes son independientes. Entonces, la solución a su problema sería llamar al manejo de colisiones en cada subcomponente, en orden. En aplicaciones reales hay interdependencias y problemas de pedido. Si ese es el caso, necesita algo de lógica de 'despachador' en cada método de la clase Entidad.
fuente