"Превращает существо в золото. (если у существа меньше 100хп)"

проверка условий это отдельный вопрос, но суть примерно та-же - есть типы проверок и параметры

превращение в золото - зависит от того, какие требуются результирующие параметры, например можно фиксированное значение выдавать, можно по набору условий выдавать из списка возможных значений, а можно использовать какую-нибудь хитрую формулу

считаю что визуальная часть слушает события от логической и сама по себе знает что ей в том или ином случае делать, но по большому счету никто кроме здравого смысла не мешает и это запихнуть в эффекты

также для этого примера буду считать, что вознаграждение фиксированное, а проверка запаса здоровья делается на этапе каста способности - применить её на кого-то, у кого больше хп просто не даст и, соответственно, эффектам это проверять не нужно

получаем следующую цепочку эффектов:
1 несколько эффектов (список эффектов - эффекты 2 и 3)
2 получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - xxx)
3 нанесение урона (кол-во урона - xxx, цель - цель заклинания, фатальный урон - да)

предположим, что нам надо варьировать кол-во золота в зависимости от ряда условий, проверка по прежнему на совести способности

1. несколько эффектов (эффекты 2, 8 )
2. проверка нескольких условий (список условий - 3, 5, список эффектов - 4, 6, прерывать проверку после первой удачной - да, действие по умолчанию - 7) работает путем последовательной проверки объектов-условий и активации соответствующих им объектов-эффектов, если условие вернет true, можно обрвать после первого нахождения true, можно не обрывать, можно назначить эффект, который будет вызван, если ни одно условие не вернет true
3. условие типа "классификация цели" (цель - цель заклинания, ожидаемая классификация - механизм)
4. получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - 20)
5. условие типа "классификация цели" (цель - цель заклинания, ожидаемая классификация - растение)
6. получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - 5)
7. получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - 10)
8. нанесение урона (кол-во урона - xxx, цель - цель заклинания, фатальный урон - да)

предположим, что проверять подходит ли нам цель должны эффекты, а получаемое золото фиксировано

1. проверка условия (условие - 2, эффект при true - 3, эффект при false - нет)
2. условие типа "сравнение характеристик с константой" (цель - цель заклинания, характеристика - здоровье в %, операция - меньше или равно, значение - 10)

3 несколько эффектов (эффекты - 4, 5)

4. получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - xxx)
5. нанесение урона (кол-во урона - xxx, цель - цель заклинания, фатальный урон - да)

по остальным распишу позже, если еще будет интересно

И да и нет. Данные способностей задаются только в редакторе объектов и код на них никак не повлияет, но игрока можно обмануть - создать способность, которая ничего не делает и отлавливать её применение, после чего делать то, что нужно. Есть один нюанс - применить способность триггерно из воздуха нельзя, потому если нужно использовать в качестве составляющих своей способности какие-то из родных для движка, приходится создавать невидимого юнита, который получает приказ применить способность, после чего удаляется. Короче куча мороки - быстрее игру написать имея некоторые навыки и план, чем с нуля во всех нюансах разобраться.

Для сравнения, во втором старкрафте все намного веселей - то что я привел в качестве примера там выглядело бы почти так-же - как набор данных в редакторе данных и ни строчки настоящего кода.

upd: не знаю зачем я написал условие <=10% если заказ был <100хп чистыми, но суть та-же

DarkDes, в варкрафте3 можно было только менять характеристики уже существующих способностей или их копий. Кто хотел большего - использовал внутренний язык программирования jass.

В старкрафте 2 же это дело реализовано на порядок приятней, но и одновременно сложней. Не буду это расписывать - можно несколько дней убить и ничего понятней не станет.

Что касается придумок геймдизайнера - большая часть даже самых замысловатых способностей сводится к простейшим элементам - нанесение урона, наложение бафа, выбор объектов в области, запуск снаряда, взаимодействие с физическим движком, активация нескольких эффектов подряд, выбор одного из эффектов по условию, периодические действия и так далее. Причем этот список можно расширять по мере необходимости или дополнять уже существующие типы эффектов дополнительными параметрами.

Если хочешь, можешь сыграть роль геймдизайнера и придумать способность или даже набор способностей, а я распишу один из вариантов, как это можно было бы реализовать и какие бы базовые элементы для этого понадобились бы.

DarkDes, собственно, я отталкиваюсь от двух источников - то, как это реализовано в Starcraft2 у Blizzard и то, как это было реализовано в свое время у меня в небольшом приватном проекте.

У Blizzard этот механизм вобще вынесен на уровень данных и как устроен сам движок остается только догадываться, а в моей версии похожий механизм был реализован довольно криво и с тех пор я уже успел серьезно поменять свою спецификацию такого механизма, но практической реализации новой спецификации еще не делал.

Суть в том, чтобы разобрать все сложные эффекты на простейшие составляющие и реализовать возможность собирать составные эффекты из кусочков.

Да, кстати, хочу уточнить кое что - слово "эффект" в данном контексте стоит воспринимать как "действие", может так будет понятнее о чем речь.

Бафы это отдельная тема, по которой мне не так много чего есть сказать. Разделить их можно на три основные категории - периодические, постоянные и маркеры. Маркеры - ничего не делающие бафы, позволяющие динамически сохранить какую-то дополнительную информацию об объекте, периодические - вызывают по таймеру привязанный к ним эффект. Сложнее всего с постоянными - они напрямую зависят от того, как реализованы характеристики объектов. Помимо этого еще стоит учитывать что у бафов может быть длительность действия, а может и не быть, что бафы могут иметь не только основной эффект, но и, например, эффект, который запускается только при снятии бафа с цели.

При этом наложение бафа на цель и снятие бафа в обход его жизненного цикла делаются, естественно, не напрямую, а через соответствующий тип эффектов.

Doc, но не стоит и уходить в противоположную сторону спектра, со скатыванием в макаронный код и месяцами дебага и рефакторинга после малейшего изменения. Неоднократно был свидетелем ситуации, когда небольшие и не особо критичные баги откладывали на "никогда" т.к. их фикс требовал изменения пары строк в тех частях кода, которые "трогать нельзя" т.к. это ведет к необходимости пересборки буквально всех модулей проекта и астрономических объемах работы для QA.

Doc, дададада!

Теории это хорошо, только когда на большом проекте поймете, что уже слишком много AbstractSingletonProxyFactoryBean и ваще хоть и офигенно гибко, но вдвойне неудобно кодить, т.к. сущностей миллион и их надо постоянно создавать, связывать и прочее, поймети что на практике оно в основном неоч выходит! Проще надо быть, я щитаю. Тот же MVC не везде применим с точки зрения удобства кодинга и везде его пихать - скорее всего ошибка.

prog, ага, хорошая тема! Пока у меня мало типов взаимодействий, справляюсь напрямую, но в будущем скорее всего что-нибудь такое понадобится запилить.