Должен ли щит быть его собственной сущностью, которая отслеживает местоположение игрока? Это может затруднить реализацию фильтрации повреждений. Это также размывает границы между присоединенными компонентами и объектами.
Изменить: я думаю, что не достаточно "автономного поведения" для отдельной сущности. В этом конкретном случае щит следует за целью, работает на цель и не переживает цель. Хотя я склонен согласиться с тем, что в концепции «объекта-щита» нет ничего плохого, в этом случае мы имеем дело с поведением, которое прекрасно вписывается в компонент. Но я также сторонник чисто логических сущностей (в отличие от полноценных систем сущностей, в которых вы можете найти компоненты 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
Вы можете видеть, что это довольно гибко, хотя это потребует тщательного планирования при проектировании взаимодействия компонентов, так как вам нужно будет определить, в какой части конвейера обработки сообщений установлены обработчики сообщений компонента.
Имеет смысл? Дайте мне знать, если я могу добавить больше деталей.
Редактировать: относительно нескольких экземпляров компонентов (два компонента брони). Вы можете либо отслеживать общее количество экземпляров только в одном экземпляре объекта (однако это убивает состояние каждого компонента) и просто продолжать добавлять обработчики событий сообщений, либо убедиться, что ваши контейнеры компонентов заранее допускают дублирование типов компонентов.