Обработка боевых эффектов в разработке игр
Вы можете использовать [selectionLimit], чтобы ограничить выбор, например:
В приведенном выше примере вы можете выбрать только два элемента.
См. Следующий пример stackBlitz
3 ответа
То, что вы называете «спецэффектами», раньше называлось «модификаторами», но в настоящее время популярный в MMO термин «баффы». Справиться с ними так же просто или так сложно, как вы этого хотите, учитывая, что вы можете выбрать, насколько универсальность вы хотите дать на каждом этапе.
По сути, каждый аспект системы обычно хранит список модификаторов, которые к нему применяются, и вы можете запросить их по запросу. Обычно есть только несколько модификаторов, которые применяются к любому игроку в любой момент времени, поэтому это не проблема - возьмите статистику игрока и любые модификаторы, передаваемые навыками / заклинаниями / чем угодно, добавьте любые модификаторы, полученные от изношенного оборудования, затем добавьте что-либо, передаваемое рассматриваемым оружием. Если вы предложите здесь стандартный интерфейс (например, sumModifiersTo (attributeID)), который используется субъектами, элементами, местоположениями и т. д., то реализация этого может быть быстрой и простой.
Обычно объекты «эффекта» будут содержаться в сущности, к которой они относятся: у субъектов есть список эффектов, а предметы, которые они носят или используют, имеют собственный список эффектов. Если эффекты явно активированы и / или ограничены по времени, вам решать, где вы хотите их хранить - например. если у вас есть волшебные зелья или другие расходные материалы, их эффекты должны быть добавлены к Актеру, а не к (предположительно уничтоженному) предмету.
Не поддавайтесь соблазну попытаться заставить эффекты изменять атрибуты актера на месте, поскольку вы быстро обнаружите, что атрибуты легко «дрейфуют», если вы не убедитесь, что все добавления и удаления выполняются в соответствии с правильным протоколом. Это также значительно усложняет обход некоторых модификаторов позже. например. Представьте себе магический щит, который защищает только от другой магии - вы можете передать какой-то предикат вашей функции суммирования модификаторов, который игнорирует определенные типы эффектов для этого.
Take a look at the book, Head First Design Patterns, by Elisabeth Freeman. Specifically, read up on the Decorator and Factory patterns and the method of programming to interfaces, not implementations. I found that book to be hugely effective in illustrating some of the complex concepts that may get you going on this.
Hope this helps to point you in the right direction.
На первый взгляд я бы сказал, что отдельные воюющие стороны (игрок и NPC) играют определенную роль в определении их боевых характеристик (т. Е. Значения брони, числа попаданий, диапазона повреждений и т. Д.) ) с учетом всех модификаторов, применимых к этому комбатанту. Таким образом, боевая система не пытается выяснить, дает ли класс персонажа бонус к броне, влияет ли магическое оружие на поражение и т. Д.
Но я бы ожидал, что сама боевая система сделает это. находиться вне отдельных комбатантов. Что он будет брать информацию об атакующем и желаемом типе атаки, а также о цели или наборе целей и разрешать это.
На мой взгляд, такая модель отражает то, как мы на самом деле вели бой в карандашных и бумажных ролевых играх. DM спросил каждого игрока о деталях его или ее персонажа, а затем провел бой, используя эту информацию в качестве входных данных. То, что он работает в реальном мире, предполагает, что это довольно гибкая система.