Я обновляю свой ответ, потому что многое не было ясно до комментариев. Пожалуйста, держись со мной, пока я объясняю свои мысли.
В общем, два ключевых аспекта, которые следует учитывать в любой конструкции, это сплоченность и сцепление . Мы все знаем, что нам нужна высокая когезия и слабое сцепление, чтобы иметь возможность создавать более многократно используемую и расширяемую конструкцию.
Таким образом, если мир должен управлять всем, это означает, что у него низкая сплоченность и тесная связь (потому что он должен знать и делать все). Однако это также тот случай, когда игровой объект должен делать все. Обновить его местоположение, визуализировать его текстуру и т. Д. И т. Д.
Что вас действительно интересует, так это создание систем, ориентированных на один аспект сущности. Например, игровая сущность может иметь текстуру, но Renderer будет отвечать за отображение этой текстуры на экране. Рендереру не важно, какие другие свойства у объекта.
Если пойти немного дальше, игровая сущность - это просто мешок свойств. Этими свойствами управляют системы, ориентированные на конкретные свойства. И именно здесь вступают в действие системы сущностей на основе компонентов (CBES), где свойства = компоненты.
В частности, CBES с системами (или подсистемами). Этот дизайн имеет тенденцию иметь несколько систем, которые ориентированы на конкретные компоненты объекта, не заботясь о том, какие другие компоненты есть у объекта. Кроме того, Системы связаны только с информацией, которая им необходима для обработки этих компонентов.
Давайте возьмем ваш пример. Так как ввод, куда перемещать объект, основан на контроллере игрока, у вас, вероятно, будет PlayerControllerSystem. Эта система, помимо всего прочего, будет контролировать PositionComponent объекта. В этом случае PlayerControllerSystem необходимо знать об уровне и PositionComponent. Если позже вы решите добавить обнаружение столкновений, вы создадите систему CollisionSystem, которая снова будет использовать положение сущностей, но на этот раз для вычисления ограничивающих рамок (или вы можете иметь BoundingBoxComponent, ваш вызов). Дело в том, что вы можете легко включать и выключать поведение (даже на лету), просто добавляя / удаляя компоненты. Таким образом, большее поведение означает, что больше систем манипулируют компонентами сущности, но все они находятся в четко определенном классе с низкой связью. Хотите сценарии? Добавьте ScriptComponent. BAM! Вы только что добавили возможности сценариев с 2 классами. Физика? Звук? Опять то же самое.
Итак, причина, по которой я защищаю CBES с подсистемами, заключается в том, что это идеально ОО и в целом простая в обслуживании / расширяемая система. Добавить поведение к объекту так же просто, как решить, какие данные нужны этому поведению и какие объекты нужны.
Для получения дополнительной информации о Компонентных Entity Systems с Подсистемами, есть отличная серия постов в блоге от T = Machine на Entity Systems - будущее разработки MMOG . Автор даже дошел до создания вики для сбора различных реализаций под названием Entity Systems Project.
Общим (и хорошо известным) постом о компонентных системах сущностей в целом является Evolve, ваша иерархия , создавшая систему для Tony Hawk Pro.
Наконец, если вы ищете библиотеку с примером кода, не идите дальше, чем библиотека Artemis . Артемида в основном на Java, но здесь есть порт на C # (который я сейчас использую в своем проекте XNA).
Actor
знать оworld
вообще?