Комментарии 9
Мне вот интересно, для описаний коллективного поведения монстров используется этот же подход на основании индивидуализированного поведения или, условно, «надмозг», управляющий группой?
Как минимум для поиска пути может быть сущность наподобие Crowd в фреймворке поиска пути Recast & Detour. Она отвечает за то, чтобы мобы катились по коридорам к одной цели, не сталкиваясь друг с другом в пространстве.
В штуках а ля Overlord и всяких RTS, где можно перемещаться группой, да, обычно задаётся лидер и остальные ищут путь поблизости. Ещё можно посмотреть как делается механизм убегания от столкновений на примере боидов.
Не совсем понятно, в чём же преймущество представления поведения такими деревьями по сравнению с кодом? Все эти сиквенсы, селекторы и пр. соответствуюи цикалам, if-ам итп. При этом для очень простого поведения может быть и есть выигрыш у дерева (можно обмануть гейм-дизанера, сказав ему, что не надо учиться программировать), а для очень сложного и разветвлённого я вижу проблему: мы в индустрии научились как-то худо бедно управлять сложностью, выраженной в строчках кода, а для логики выраженной в нарисованных графах и деревьях - кажется не очень.
проверочное слово: "ймущество" (простите).
Меньше времени на обучение нужно, научить людей писать код намного затратнее, чем выдать им удобные инструменты для аи и обучить делать БТ
Сериализация и динамика. Ифы в коде не посериализуешь и от редактора не отделишь, в отличие от BT. Динамический фидбэк на изменения получается заметно короче, что ускоряет цикл разработки. ГД не дерутся на мечах, в ожидании когда новый if попадёт в бандл.
Визуальное представление и отладка - за счёт визаульного представления проще отлаживать, приоритезировать ноды и комбинировать поведение. Опечаток меньше опять же.
Сложные ветки вполне себе абстрагируются в более крупные ноды, так что проблем это вызывать не должно. Аналогично оборачиванию в функцию.
Ну для этого придумана всякая Lua: она не выкомпилировывается в граните, есть динамика, изменять скрипт можно быстро и подхватывать на лету. Вот насчёт визуального представления, мне кажется это ловушка: всё хорошо выглядит, пока у вас есть совсем немного узлов, а когда их много - начинается боль. По моему личному опыту (я не из геймдева, я больше сталкивался с графическими дизайнерам различных "workflow"), такие "графические языки программирования" делают разработку якобы простой, пока ваша логика простая, и может быть охвачена целиком быстрым взглядом на графическое представление. Но когда она становится сложной, начинается боль.
Вы правы, можно построить иерархическую структуру и "схловывать" ноды в более высокоуровневые, но "опыта контроля за сложностью" наработано больше для простых текстовых программ. Не факт, конечно, что большинство дизайнеров персонажей обладают этим опытом, но всё же.
В добавок, при написании AI-логики кодом вы получаете преимущества plain text кода: сравнение версий, diff-ы, патчи, итп
Сериализуется оно тоже обычно в текстовое представление - джсон там или те же луа таблицы, так что контроль версии меньшая из проблем.
Для геймдизайна сложно искать именно программиста, даже на Lua. И это не говоря за ту фрустрацию, когда что-то случайно сломалось из-за невнимательности или кривого порядка операций. На одной из прошлых работ в итоге большинству ГД было проще настраивать связи в админке (как в БД - открыл таблицу, создал запись, накидал данных, закоммитил), чем писать всё то же самое на луа, которое потом собиралось из админки и прилетало на сам клиент игры.
Хочешь сделать интересного монстра, думай как монстр