Существует множество способов представления и реализации систем компонентов объектов, но здесь приведено объяснение одного из них. Имейте в виду, что нет конкретного определения архитектур сущностей / компонентов / систем, поэтому это всего лишь одна реализация.
Я собираюсь представить аналогию для сущностей / компонентов / систем, которые могут помочь. Давайте думать о сущности как о ключе.
Организация
Ключи также имеют зубы (темно-синий). Зубы нашего ключа сущности - это составляющие. Вы можете различать сущности по их идентификатору, даже если у них одинаковые зубы. Так во что вписываются ключи? Замки. Замки - это наши системы. Например, система движения.
Система
Замок работает, только если у нашего ключа есть зубцы как для положения, так и для скорости. Эта система обрабатывает только объекты, которые имеют положение и скорость. Есть несколько способов установить, как эти системы распознают, какие объекты обрабатывать, но один из них - это использование long. Каждый бит зарезервирован для типа компонента. Для нашего примера давайте предположим, что 4-битный тип вместо 64-битного. Наш пример сущности будет иметь все доступные компоненты. Так что это ключ будет 1111. Затем система ищет любую сущность, которая имеет 11--. ( -Представителю все равно, потому что движению все равно, есть ли спрайт или здоровье). Он может проверить сущность с помощью простой ANDоперации. Таким образом, наша сущность соответствует, если ((1111 & 1100) == 1100). Если я тебя там потерял, посмотри еще немного о побитовых операциях .
Как видите, системы имеют доступ к внешним ресурсам. Они могут получить доступ ко времени, графике, звуку и так далее. Это просто маленькие процессоры, которые принимают один ключ за раз и обрабатывают данные. Вы видите, что система движения принимает скорость, дельта-время и положение; затем делает некоторые вычисления и сохраняет результат обратно в позицию.
Ключи сущностей действительно легко генерируются. Вы можете добавлять или удалять их по своему желанию. Субъекту все равно, это просто способ группировки и хранения компонентов. Компоненты не имеют взаимозависимости. Наиболее близкие компоненты взаимодействуют друг с другом, когда система работает с ними и использует данные одного для обновления другого, как в нашем примере движения.
Давайте посмотрим на другую систему, чтобы помочь закрепить идею:
Это наша система рисования. Он ищет компоненты, которые соответствуют 1-1-. Этот объект соответствует, потому что: ((1111 & 1010) == 1010)Кроме того, вы можете видеть, что эта система выводит информацию на экран, рисуя спрайт объекта на его позиции.
ОК, еще один. Давайте посмотрим на другую сущность и посмотрим, как она может вписаться в наш пример.
Как видите, к этой сущности прикреплено меньше компонентов. Глядя на компоненты, которые у него есть, похоже, что это может быть статический элемент, похожий на камень. У него просто есть позиция и спрайт. Это не собирается двигаться, и это не будет затронуто никакими изменениями здоровья. Эта сущность выдаст ключ 1010. Итак, какие системы работают с этой сущностью? Давайте проверим:
Против нашей системы движения:
((1010 & 1100) != 1100)Нет. Похоже, система движения не заботится об этой сущности, потому что она не имеет необходимых компонентов.
Против нашей системы рисования:
((1010 & 1010) == 1010)Эй, это совпадение. Эта сущность будет управляться системой рисования. Система рисования нарисует спрайт в определенной позиции.
Надеюсь, вы сможете увидеть, как легко было бы добавить еще одну систему, которая бы использовала наши компоненты и работала на них. Позвольте мне убедиться, что я ответил на ваши вопросы:
Что если нескольким системам нужен доступ к одному и тому же компоненту? Где должны жить данные?
Как правило, системы работают одна за другой. Они обрабатывают все объекты, которые соответствуют их требованиям, затем следующая система делает то же самое и так далее. Данные живут с сущностью. В системе не должно храниться ничего, это просто замок, который поворачивается, ключ в том, где информация остается и перемещается от замка к замку.
Как строятся сущности? Связаны ли системы с компонентом? Если я хочу ввести какой-то новый компонент, нужно ли мне также вводить новую систему или модифицировать существующую?
Сущности - это просто мешки с компонентами. У них есть уникальный идентификатор и список компонентов. Системы привязаны к компонентам только так, как описано выше. Вы можете иметь компоненты без систем, которые работают на них, но это довольно бессмысленно. Точно так же вы можете иметь системы, которые ищут компоненты, которых нет у сущностей. Это менее бессмысленно, потому что они могут просто ждать создания объекта, который соответствует их блокировке. Так что, да, если вы представите новый компонент, вы захотите создать систему, которая использует этот компонент. В противном случае вы просто добавляете зубы к своему ключу для блокировки, которая не существует.
Если моя сущность - это просто идентификатор, как я могу знать, что моя сущность робота должна быть перемещена или визуализирована и, таким образом, изменена какой-либо системой?
Я думаю, что я отвечаю на это с идеей longключа, который определяет компоненты, содержащиеся в сущности. Вы знаете, потому что ключ подходит к замку.
Уф! Это был длинный пост! (Или, по крайней мере, так кажется с моего большого монитора.)