alexprey:

Когда в варе делал диалоговую систему, не хватало её интеграции со стандартными триггерами и поэтому все диалоги приходилось писать ручками или тоже самое с HLL, все элементы надо было прописывать ручками.

Да, да.. Кстати в своем проекте я использую это в том числе для диалоговой системы - условие появления ветки, действие при выборе ветки и тому подобные. Как было описано выше, можно подключить редактор в нужном месте и, выбрав конкретно что нужно (например, только условия), работать с ним.

EfReeZe, за производительность вот смотри
Падение производительности будет значительное при мелких операциях (они кстати и не должны быть основой сценария). Почему: все данные, аля int, bool и прочие оборачиваются в класс для того чтобы их можно было сохранить и в случае чего подменить например функцией или ссылкой которые возвращают этот тип. Создание класса - довольно-таки не быстрая операция. Однако это происходит при срабатывании триггера и дальнейшие вычисления уже 1 к 1 с реальным кодом (так как дальше и идет реальный код).
Во всех остальных случаях использование редактора сценариев выгодно по нескольким причинам:

1. Это качественная вещь для работы со временем
2. Нативный код будет нагружать сборку и если проект большой, то единичный случай оформлять кодом ну просто дико. То есть для больших проектов больше выгоды от использования - скажем поговорил по квесту в рпг с кем-нибудь, надо выполнить последовательность - закрыть опеределенный квест, дать предметы, передвинуть собеседника, взорвать дом, проиграть анимацию - да что угодно - нативный код сюда не подставишь. А такая система это то что нужно (в этой гибкости и есть прямое назначение).
3. Падение производительности это такие мкс, что пользователь даже при тысяче таких ничего не почувствует.
4. При нормальной работе с действиями, единственная задержка - вызов под рефлексией. То есть мы можем вызвать любую функцию - только вызов самой функции через рефлексию будет чуть дольше (меньше чем мкс), а то что произойдет внутри функции - это уже нативный код,

Соответственно встает выбор:

• Описывать нестандартные сценарии через натив и иметь мусор в коде
• Использовать систему сценариев с незначительной потерей производительности при вызове (в остальном это те же наши куски кода, как я сказал выше)

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

А вообще эта штука делает то, чем ее наполнишь.

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

lentinant, кому что, лично меня от блок схем просто выворачивает. Когда их становится много то это имхо больше напоминает кашу, а не порядок. + я разрабатываю то что нравится и нужно лично мне, иначе и запала делать не появится, так что в этом плане как-то так :)