Как стать автором
Обновить

Комментарии 18

Такая долгая подводка к фразе: «Давайте юзать behavioural tree» и на самом интересном месте оборвать статью. Вы бы хоть в кратце рассказали как с этими деревьями в Юнити работать

Стейтмашина — это моб с одним свойством (то самое состояние).

А вот если мы используем несколько свойств (BOOL ЗанятВДиалоге и так далее), то переходами из состояния в состояние (такое свойство мы тоже сохранили!) мы управляем гибко и адекватно, не раздувая количество состояний и переходов.

Я прямо сейчас пишу большое дерево поведения для проекта и BT ни разу не панацея. Да, ряд плюсов имеется, но Боже упаси реализовывать такую дуру для каких нибудь аркад да roguelike. Отсутствие Transition замещается NodeState, с которым конечно проще работать, но потребуется написать и распихать не один декоратор. С разделяемыми ресурсами проблемы остаются, вообще главное отличие дерева - его высокий уровень абстракции и масштабируемости, и из-за этого отличия местами приходится накостыливать по полной, либо 2 вариант - дерево имеет тонну зависимостей, и при каждой новой фиче разработчик умывается своей кровью.

Так обычно деревья решений руками никто не делает, их тренируют на датасетах как и любые другие ml-модели. Только зачастую не одно дерево, а совокупность, через bagging или boosting.

В данном контексте термин Behaviour Tree не имеет ничего общего с ML BT. Это просто дерево принятия решений, ветвление на стероидах.

У bt, по сравнению с dt немного другой порядок перебора и выполнения, но это такое же ветвление на стероидах.

Не знаю что там в ML, но в контексте геймдева BT имеют вполне стандартизированный вид и семантику

Остальное уже - терминологические прения :)

Простите, а вы сейчас точно про геймдев говорите? Тут речь о игровом ии, а не о ml-моделях.

Думаю, меня смутила терминология. Речь сверху идет про desicion tree, а не behavior tree. В decision tree состояний, как таковых нет. Если нам нужна альтернатива fsm, то это будут именно behavior tree из ml.

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

Заголовок провокационный, но не соответствует содержанию.
Рекомендация то не про FSM в целом, а про использование их для ИИ.

Так и не понял, почему State Machine не может быть вложенной ( и как следствие иметь глобальные переходы между состояниями) и почему невозможно параллельное выполнение состояний (даже не совсем понял, что это такое. Если к игровому объекту привязано 2 разных State Machine , можно ли считать это параллельным?) ?

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

С абстрактной точки зрения, что SM, что дерево - оба графы, с разными свойствами. Не понимаю, почему один из них по древним заветам ситхов низведен до абсолюта НИКОГДА-не-использования.

SM может быть вложенной, что происходит довольно часто, и может быть в теории параллельной, хотя я с таким на практике не встречался.

Тут автор просто в инфантильной манере пытается сказать, что конкретно для задачи проектирования поведения AI в играх подходит лучше BehaviourTree, тк у него нет как такового состояния (спойлер есть). Если коротко и упуская детали о том, что автор не сказал, то хоть БТ и дерево, но принцип его работы в многократном проходе по графу каждый раз вычисляя то самое состояние. Есть отличная статья для понимая силы БТ. Не знаю можно ли кидать тут ссылки на другие источники, поэтому просто погугли “BehaviourTree ProjectZomboid”

Ну и конечно же даже для AI можно использовать СМ, если в вашем контексте она подходит наилучшим образом, также в случае сложных поведений АИ можно использовать комбинации стейтмашины и БТ, как например это сделано в последних FinalFantasy. Автор просто не очень опытный парень, а статьи пишет)

StateMachine NPC это не сугубо AnimatorController в юнити. От этого, видимо, и пошла казуистика данной темы. И BehaviourTree никак не заменит StateMachine. Суть StateMachine - как раз, наделить и ограничить NPC теми действиями, которые подобают контексту, равно как и заглушить те, что не подобают. И задать ограниченные правила перехода состояний. В правильно составленной StateMachine как раз, персонаж квеста не убежит нечаянно воевать, он будет в состоянии: "я зачитываю квест". И не перейдет в смерть, потому этого перехода не предусмотрено из состояния.

Ну мб это просто я не так понимаю BT, а чем оно собственно отличается от FSM с переменными и функциями?

Отличается очень многим, как минимум своей структурой и способом выполнения.
FSM - граф состояний и переходов. В момент времени состояние (стейт) одно.
BT - дерево условий и действий. В минимальном наборе идёт Sequence (И) и Selector (ИЛИ), а также действия (через них же сделаны условия), который возвращают статусы (Success, Failure, Continue). Выполняется сверху вниз слева направо до первого Failure/Success статуса.

С машиной состояний у тебя будут условные стейты Chase, Attack, Wander, где внутри будут проверки, последовательности действий и прерывания. Дальше внутри или отдельно от стейтов будет логика переходов между ними.

С деревом у тебя будет рут с Selector от которого идёт Sequence с условиями и действиями атаки, потом Sequence с условиями и действиями погони, потом Sequence блуждания.
То есть логика будет формально та же, ты можешь выразить те же самые состояния, но дерево будет каждый кадр пересчитываться, действия могут возвращать Continue и выполняться в течении времени, могут прерываться по каким-то условиями и переходить к менее или более приоритетным действиям, могут выполняться параллельно.
Выглядит и работает это как более читаемое нагромождение if-else с маленькими функциями.

А в F.E.A.R. какая система используется?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации