Існує безліч способів представити та реалізувати компоненти компонентів, але тут є пояснення одного із способів. Майте на увазі, що немає конкретного визначення архітектури об'єктів / компонентів / систем, тому це лише одна реалізація.
Я збираюся ввести аналогію для архітектур сутностей / компонентів / систем, яка може допомогти. Давайте подумаємо про сутність як про ключ.
Сутність
У ключів також є зуби (темно-синього кольору). Ключ зубів нашої сутності - це компоненти, які складають його. Ви можете розповісти особам окремо за їх посвідченням особи, навіть якщо вони мають однакові зуби. Отже, до чого кладуть ключі? Замки. Замки - це наші системи. Наприклад, система руху.
Система
Замок працює лише в тому випадку, якщо у нашого ключа є зуби як для позиції, так і для швидкості. Ця система обробляє лише сутності, які мають положення та швидкість. Існує кілька способів налаштування того, як ці системи розпізнають, які сутності обробляють, але одним із способів є використання long. Кожен біт зарезервований для типу компонента. Для нашого прикладу давайте припустимо 4-бітний тип замість 64-бітового. У нашому прикладі суб'єкт господарювання мав би всі доступні компоненти. Отже, це було б ключовим 1111. Тоді система шукає будь-яку сутність, яка має 11--. ( -Представнику все одно, адже рух не має значення, якщо є спрайт чи здоров'я). Він може перевірити сутність за допомогою простої ANDоперації. Тож наша сутність відповідає, якщо ((1111 & 1100) == 1100). Якщо я втратив вас там, ознайомтеся ще з приводу бітових операцій .
Як бачите, системи мають доступ до зовнішніх ресурсів. Вони можуть отримати доступ до часу, графіки, звуку тощо. Це просто маленькі процесори, які беруть по одній клавіші за один раз і обробляють дані. Ви бачите, що система руху займає швидкість, час дельта та положення; потім проводиться деякий розрахунок і зберігається результат у положення.
Ключі сутності створюються дуже просто. Ви можете їх додати або видалити за бажанням. Суб'єкт не хвилює, це лише спосіб згрупувати та утримувати компоненти. Компоненти не мають взаємозалежності. Найближчі компоненти взаємодіють один з одним, коли система працює над ними і використовує дані однієї для оновлення іншої, як наш приклад руху.
Давайте подивимось на іншу систему, яка допоможе закріпити ідею:
Це наша система малювання. Він шукає компоненти, які відповідають 1-1-. Ця сутність відповідає тому, що: ((1111 & 1010) == 1010)Крім того, ви можете бачити, що ця система виводить інформацію на екран, малюючи спрайт сутності у своєму положенні.
Добре, ще один. Давайте подивимось на іншу сутність і подивимось, як вона могла вписатися в наш приклад поки що.
Як бачимо, до цього об'єкта додано менше компонентів. Дивлячись на компоненти, які у нього є, схоже, що це може бути статичний предмет, як скеля. У нього просто є позиція і спрайт. Він не рухатиметься, і ніякі зміни в стані здоров'я не впливатимуть. Ця організація створила б ключ 1010. Отже, які системи працюють на цьому об'єкті? Давайте перевіримо:
Проти нашої системи руху:
((1010 & 1100) != 1100)Ні. Схоже, що система руху не переймається цією сутністю, оскільки в ній немає необхідних компонентів.
Проти нашої системи малювання:
((1010 & 1010) == 1010)Гей, це збіг. Цією сутністю керуватиме система малювання. Система малювання буде малювати спрайт у визначеному положенні.
Сподіваємось, ви зможете побачити, як легко було б зараз додати іншу систему, яка б приймала наші компоненти та працювала над ними. Дозвольте мені переконатися, що я вирішив ваші питання:
Що робити, якщо декілька систем потребують доступу до одного компонента? Де мають жити дані?
Зазвичай системи працюють одна за одною. Вони обробляють усі сутності, які відповідають їхнім вимогам, потім наступна система робить те саме і так далі. Дані живуть з сутністю. У системі не повинно бути нічого, що зберігається, це лише замок, який перетворюється, ключовим є те, де інформація залишається і переходить від блокування до блокування.
Як будуються сутності? Чи системи по суті пов'язані з компонентом? Якщо я хочу представити якийсь новий компонент, чи потрібно також вводити нову систему чи змінювати існуючу?
Суб'єкти - це просто сумки компонентів. Вони мають унікальний ідентифікатор та перелік компонентів. Системи прив’язуються до компонентів лише способом, описаним вище. Ви можете мати компоненти без систем, що працюють на них, але це зовсім безглуздо. Так само ви можете мати системи, які шукають компоненти, які не мають жодних організацій. Це менш безглуздо, адже вони, можливо, просто чекають створення об'єкта, який відповідає їхньому блокуванню. Отже, так, якщо ви вводите новий компонент, ви хочете створити систему, яка використовує цей компонент. Інакше ви просто додаєте зуби до свого ключа для блокування, якого не існує.
Якщо моя сутність є лише ідентифікатором, то як я можу знати, що мою сутність робота потрібно перемістити або винести та змінити таким чином в якійсь системі?
Я думаю, що я відповідаю на це ідеєю longключа, який визначає компоненти, що містяться в об'єкті. Ви знаєте, тому що ключ підходить до замка.
Фу! То був довгий пост! (Або принаймні так здається з мого великого монітора.)