Чи повинен щит бути власною сутністю, яка відслідковує місцезнаходження гравця? Це може ускладнити здійснення фільтрації пошкоджень. Це також неначе розмиває лінії між приєднаними компонентами та об'єктами.
Редагувати: Я думаю, що для окремої сутності недостатньо «автономної поведінки». У цьому конкретному випадку щит слід за ціллю, працює для цілі і не переживає ціль. Хоча я схильний погоджуватися, що в понятті "щитовий об'єкт" немає нічого поганого, в цьому випадку ми маємо справу з поведінкою, яка добре вписується в компонент. Але я також прихильник суто логічних сутностей (на відміну від повномасштабних систем сутностей, в яких можна знайти компоненти Transform і Rendering).
Чи повинен щит бути компонентом, в якому розміщені інші компоненти? Я ніколи не бачив і не чув про щось подібне, але, можливо, це звичайне явище, і я просто ще недостатньо глибокий.
Бачити це в іншій перспективі; додаючи компонент, додаються й інші компоненти, а після видалення додаткові компоненти також втрачаються.
Чи повинен щит бути лише набором компонентів, які додаються до програвача? Можливо, з додатковим компонентом для управління іншими, наприклад, щоб вони могли бути видалені як група. (випадково залиште після себе компонент зменшення шкоди, тепер це було б весело).
Це може бути рішенням, воно сприятиме повторному використанню, однак воно також є більш схильним до помилок (наприклад, про проблему, про яку ви згадали). Це не обов'язково погано. Ви можете дізнатись нові комбінації заклинань із спробою та помилками :)
Щось інше, що очевидно для тих, хто має більш складний досвід?
Я збираюся трохи допрацювати.
Я вважаю, ви помітили, як деякі компоненти повинні мати пріоритет, незалежно від того, коли вони були додані до об'єкта (це також відповість на ваше інше питання).
Я також припускаю, що ми використовуємо комунікацію на основі повідомлень (заради обговорення, це лише абстракція щодо виклику методу на даний момент).
Щоразу, коли компонент щита "встановлений", обробники повідомлень компонентів щита приковані до конкретного (більш високого) порядку.
Handler Stage Handler Level Handler Priority
In Pre System High
Out Invariant High
Post AboveNormal
Normal
BelowNormal
Low
System Low
In - incoming messages
Out - outgoing messages
Index = ((int)Level | (int)Priority)
Компонент "stats" встановлює обробник повідомлень "пошкодження" в індексі In / Invariant / Normal. Щоразу, коли надходить повідомлення про "пошкодження", зменшуйте HP на його "значення".
Досить стандартна поведінка (будь-яка природна стійкість до пошкоджень та / або расові риси, як би там не було).
Компонент щита встановлює обробник повідомлень "пошкодження" за індексом In / Pre / High.
Every time a "damage" message is received, deplete the shield energy and substract
the shield energy from the damage value, so that the damage down the message
handler pipeline is reduced.
damage -> stats
stats
stats.hp -= damage.value
damage -> shield -> stats
shield
if(shield.energy) {
remove_me();
return;
}
damage.value -= shield.energyquantum
shield.energy -= shield.energyquantum;
stats
stats.hp -= damage.value
Ви можете бачити, що це досить гнучко, хоча це потребує ретельного планування при розробці взаємодії компонентів, оскільки вам доведеться визначити, в якій частині оброблювачів подій компонентів протоколу обробки повідомлень встановлені.
Має сенс? Повідомте мене, чи можу я додати більше деталей.
Редагувати: стосовно кількох компонентів (два компоненти броні). Ви можете або відстежувати загальний кількість екземплярів лише в одному екземплярі сутності (однак це вбиває стан компонента), і просто продовжувати додавати обробники подій повідомлень, або переконайтеся, що контейнери компонентів дозволяють заздалегідь дублювати типи компонентів.