Вашим играм не нужна State Machine

Сегодня я, наконец, расскажу, почему игровой ИИ, основанный на машине состояний (State Machine или просто SM), это ленивое подобие ИИ и не должно видеть свет в любом не пет-проекте.

Меня все также зовут Миша, я программирую больше 7 лет, последний год плотно занимаюсь игровым искусственным интеллектом, реализовывал его во всех возможных вариациях. А также успел увидеть немало говнокода со стейт машинами, где его довольно просто можно было бы избежать. Также, конечно же, веду телеграм канал, где рассказываю еще больше о разработке, карьере в геймдеве и прогреваю на менторство.

Конечно, всегда можно сказать “да вот у меня элементарнейшее поведение, там нечего выделываться с ИИшными фреймворками” или “у меня жанр Idle, там мобы просто выполняют последовательность действий”. Но давайте вспомним цикл жизни практически любой игры. Да, мы делаем сначала core-фичи, только основной набор действий для мобов. Но как долго это длится? Как долго наши мобы из айдлеров не начинают менять поведение на ходу. Например, когда не могут что-то выполнить или когда просто хотят порадоваться просмотренной рекламке?

В такие моменты мы и понимаем, насколько были ленивы, выбрав машину состояний. Ведь у нее квадратичная сложность увеличения количества поведений. И еще все вместе вспоминем, что граф для состояний в наших стейт машинах ориентированный и умножаем количество на 2. То есть, 2 состояния - 2 стрелочки между ними, 5 состояний - 20 стрелочек, 12 → 132 и так далее.

Конечно, все мы следуем великой мантре “работает - не трожь!”. Поэтому как бы сильно ни стреляла нам по ногам эта стейт машина, мы остаемся с ней до победного (иногда) конца.

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

Рассмотрим их на примере NPC или условной RPG игры. Наш моб умеет некоторые действия типа: общаться с главным героем, ходить на работу, есть, спать, сражаться.

P.S. изначально примеры могли быть разнообразнее, но мне понравилось как один жалкий сюжетный квест портит абсолютно всю машину состояний. Очень разрушительный сюжет получается)

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

И не надо далеко ходить, чтобы понять главную альтернативу нашей стейт машине - Behavior Tree или Дерево Поведений. То, что по умолчанию есть в Unreal и то, что и было использовано в альтернативу сжигающей себя стейт машине. То, что возвело противников из серии Halo в пример остальным игроделам.

Посмотрим на “фичи”, которая она предлагает из под коробки. Заметьте, ИЗ ПОД КОРОБКИ, для этого не надо наворачивать сову на глобус как мы делали с NPC:

Конечно, нельзя не забывать и про Utility AI. Он больше подойдет в случае когда состояний много и нам не хочется выстраивать связи между ними (вспомните Sims). Хотя выбор между подходами для написания ИИ посвящена целая отдельная статья.

Не бойтесь выходить из зоны комфорта и искать новые решения для стандартных проблем! И НИКОГДА НЕ ИСПОЛЬЗУЙТЕ STATE MACHINE ДЛЯ ИГРОВОГО ИИ!!! И конечно же подписывайтесь на мой канал и обращайтесь за менторством, если до сих пор не нашли работу в геймдеве) Спасибо!