Идентификация типов объектов в системе компонентов

Если объект не имеет явного «типа» (например, игрока) и представляет собой просто набор компонентов, как я могу определить объекты, над которыми мои системы должны и не должны работать? Например, в игре Понга лопасть и шар одновременно сталкиваются с границами окон. Тем не менее, системы обработки столкновений для каждого будут разными, поэтому система не должна обрабатывать объекты неправильного типа.

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.
  }
}

Оба игрока и мяч используют одни и те же соответствующие типы компонентов для обработки столкновений, но их системные реализации будут разными.

Если у меня есть контейнер всех игровых объектов, как определить конкретные типы объектов без наследования Entity или включая переменную-член, такую ​​как std::string type, и в этом случае объект больше не просто набор компонентов?

9 голосов | спросил Garee 10 J0000006Europe/Moscow 2013, 14:31:47

4 ответа


19

Ответ Николь Болас прямо, но отступая и глядя на вашу проблему издалека: вам действительно не нужен тип объекта.

Вам нужно только заботиться о том, «имеет ли объект компонент X» или нет, и ваша проблема в том, что вы неправильно определили X. Если два объекта ведут себя по-разному, то дают им разные компоненты или просто помещают на компонент логический флаг, если он ведет себя по-разному для разных конфигураций объектов. Используйте систему компонентов для принятия решений о поведении, а не типа «тип». В этом весь смысл использования компонентов.

Вам полностью разрешено иметь компонент ---- +: = 2 =: + ---- и отдельный PaddlePhysics компонент /система, если они ведут себя по-разному. Или вы можете разбить компоненты на более гранулированные части, так что у вас есть компонент BallPhysics, который имеет только Ball и Bounce, который как StopAtBoundary и Ball, если часть поведения достаточно сложна, чтобы оправдать совместное использование кода. Или вы можете просто создать компонент Paddle, который имеет логический флаг PongPhysics установить Bounces для true и Ball для false , Вы даже можете создать базовый компонент Paddle, а затем получить этот компонент, чтобы получить WallCollision, который добавляет дополнительное поведение, необходимое там.

ответил Sean Middleditch 10 J0000006Europe/Moscow 2013, 22:01:40
15

Система полезна, если она полезна. Если система, где объект является «просто набором компонентов», менее полезна, чем система, в которой объект в основном «набор компонентов», затем сделать это .

Остановите попытки создания «чистых» систем и сосредоточьтесь на создании хороших , которые делают то, что вам нужно. Используйте компоненты, пока компоненты больше не будут полезны для вас. Затем используйте что-то еще.

Вы уже потратили больше времени на размышления об этом, чем он заслуживает.

ответил Nicol Bolas 10 J0000006Europe/Moscow 2013, 17:42:56
4

Если вы хотите предоставить сущности явным типом, самый простой способ - определить переменную типа в классе сущности. Используйте только шаблон EC, если он полезен.

В противном случае тип подразумевается через атрибуты компонента. Например, физический компонент будет иметь атрибут для мобильных и стационарных. Система тогда знает, когда сталкиваются две мобильные машины (мяч и весло). Аналогично, вы можете иметь атрибуты того, как система столкновения должна реагировать. Просто остановите объект или отразите его? Рассмотрение атрибутов должно дать вам представление о том, что такое сущность, но это должно быть неуместно. Системе не нужно знать, к какому типу сущности, с которым они работают, им должна быть предоставлена ​​достаточная информация, используя предоставленные им компоненты.

Наконец, можно добавить дополнительный компонент, который содержит тип, но, как и при добавлении типа к сущности, вы в конечном итоге написали много специфического для типа кода, победив цель системы EC.

ответил MichaelHouse 10 J0000006Europe/Moscow 2013, 17:53:16
0

Сущность - это набор компонентов. Вы не можете назначать аккуратные метки произвольному набору. Отказ от ограничений типа - это цена за большую гибкость.

Конечно, у вас могут быть специальные (типизированные) классы сущностей, которые налагают ограничения на компоненты.

Идеально компоненты независимы. Таким образом, решение вашей проблемы будет состоять в том, чтобы вызвать обработку столкновений по каждому подкомпоненту в порядке. В реальных приложениях существуют взаимозависимости и проблемы с упорядочением. Если это так, вам нужна логика «диспетчера» в каждом методе класса Entity.

ответил Karl 14 J0000006Europe/Moscow 2013, 18:26:46

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132