GamedevForge

Остаемся в зоне комфорта

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

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

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

• Any State. Этот синий квадратик в аниматоре знаком любому юнитисту. Проводя стрелку от него, мы показываем, что в это состояние можно перейти из любого другого. Чтобы не рисовать 20 стрелочек к 10-му состоянию, мы нарисуем 10, а одиннадцатую проведем от Any state. И все хорошо, пока мы не решим, что из какого-то состояния мы все таки не хотим переходить в это новое…
  Говоря о нашем NPC. Хотим мы ему добавить для смерти отдельное состояние (может наконец-то раскошелились на анимацию не из mixamo и хотим ею похвастаться). Мы решаем “ну умереть он может когда угодно, значит можно сделать переход из any state. Все классно, только вот NPC давал герою квест во время диалога и теперь во время болтовни он может умереть и закончить сюжетную арку на 10 часов раньше. Поэтому придется все таки провести еще 10 стрелочек.

• Hierarchical state machine (HSM). Кому-то тоже знаком из аниматора как “вложенная стейт машина”. Если часть состояний одинаково связана с остальной частью стейт машины, то вполне резонно можно выделить ее в свою внутреннюю SM. Таким образом из 90 стрелок мы можем убрать условно половину. Но все снова идет по одному месту, когда часть таких состояний все таки должна иначе работать с внешней стейт машиной…
  Вернемся к NPC. Мы решаем, что все его мирные действия (поесть, поспать, поболтать) достойны того чтобы лежать отдельно от его боевых навыков. Убираем их отдельно и смотрим на похорошевший граф состояний… Ах да, он все еще сюжетный квест дает, но вместо диалога убежал сражаться… Тогда распаковываем обратно и рисуем обратно 40 стрелочек…

• Слои.
  - Понимаешь, стейт машины, они как лук
  - Воняют? Доводят до слез?
  - Нет, слои. У лука есть слои и у стейт машины есть слои.
  Ставьте лайки, если узнали отсылку))
  Если какое-то действие может выполняться независимо от части остальных, то его можно вынести в отдельный слой. По своей сути, это такая же стейт машина, работающая параллельна, но в этом же внешнем контексте. Она смотрит на те же данные и меняет состояния по тем же самым триггерам, что и основная SM. Но точно также все ничего до тех пор, пока ее параллельность абсолютна. Что как правило не так…
  Геймдизайнер поиграл в скайрим и решил что наш NPC тоже может разговаривать во время некоторых действий. Например, он может делать это сидя за столом. Мы создаем отдельный слой для стейт машины, в котором есть только состояния общения. Но ведь персонаж не может уйти из-за стола, пока разговаривает. Тем более когда дает сюжетный квест. Да и разговаривать он может далеко не всегда. Что нам тогда приходится делать? Все равно опосредованно соединять наши стейт машины. Состояние общения должно точно знать что происходит в остальной логике персонажа. И та в свою очередь должна ждать, пока голова договорит. В итоге это даже хуже остальных костылей. Мы не только зазря пытаемся оптимизировать поведение, а еще и прячем зависимости состояний внутрь самого контекста игрока.

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

Боимся и поджимаем хвост

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

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

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

• Вложенность (не просто так оно деревом называется)

• Глобальные переходы между состояниями, как следствие из этого

• Параллельное выполнение состояний

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

Итог

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

В остальном достаточно одного небольшого проекта. Ему не надо быть красивым или даже ультра качественно написанным. Но в нем должно быть:

• отсутствие базовых ошибок и косяков, за которые прям зацепиться глаз. Никаких FindObjectOfType и десятков синглтонов, вызываемых из одного класса. Никаких бесполезных комментариев как по коду, так и “для себя на будущее”. На самом деле, комментарии - довольно сложная тема, иногда они могут быть и нужны. Если интересно подробнее узнать, где их писать/не писать и как это делать, можно посмотреть у великого Сергея Немчинского. Для наших целей достаточно правила “любой комментарий может быть кодом”. Если внутри метода есть сложная часть, которую захотелось прокомментировать, то вынесите ее в отдельный метод с нужным названием. И по аналогии с любым другим комментарием.

• соблюденный кодстайл. Нейминги, отступы, аккуратные небольшие легкочитаемые классы. Ревьюверы - тоже люди (звучит как лозунг для какого-нибудь митинга), им приятнее будет читать хорошо оформленный код вместо мешанины из кривого нейминга

• только доделанный функционал, никаких костылей и заглушек для “на потом, когда руки дойдут”

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

Во время обучения за подобный проект мы беремся уже параллельно с выходом на рынок. В тот момент, когда ученик уже точно имеет все необходимые навыки как по C# и Unity, так и по прохождению собеседований. Почему именно тогда, а не раньше:

• опыт написания целиком собственного играбельного решения и понимание, что не так уж это и сложно, сильно помогает ментально. Сразу сбрасывается этот губительный майндсет, мол "вот они то настоящие программисты, а я так... только по туториалам умею". И чем эта позиция будет актуальнее на момент собеседований, тем лучше)

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

О чем должен быть такой проект:

• Это должна быть небольшая, законченная игра. Не надо пытаться в одного делать новую GTA или Assassin’s creed. Оно и не получится, да и потенциальный лид, заглянувший в проект, увидит только человека который не может оценить свои силы и берет на себя слишком много.

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

• Скорее всего, ты не дизайнер, но постарайся сделать визуал не сильно всратым) Для UI возьми любой пак с понравившимися тебе спрайтами. Если кор часть в 3д, то также постарайся подобрать модели в одном стиле хотя бы. Поставь хоть какой-нибудь свет на сцену

• Используй разумное количество популярных фреймворков. Затащи в проект DI (Zenject или VContainer), при необходимости, добавь UniRx. Для процедурных анимаций добавь в проект щепотку DoTween’а

• Знай и понимай каждое принятое на проекте решения. Чтобы на условный вопрос “а почему используешь MVP, а не MVVM” было хорошее объяснение вместо “ну мне показалось так лучше будет/ну он вроде проще/ну я за UniRx не шарю”

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

У себя на вместе с выходом этой статьи объявлю небольшой конкурс. Кидайте в комментарии сюда, а лучше к посту, анонсирующему эту статью на моем канале, свои пет-проекты или тестовые. В зависимости от их количества и качества я в прямом эфире посмотрю 3-5 самых, на мой взгляд, интересных!

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

В поисках подходящего “источника вдохновения”, на мои глаза в очередной раз попались мемы про альтушку с госуслуг. И, оказалось, что они - идеальный кандидат. Посудите сами: мем довольно устоявшийся, известный (в кругах нашей целевой аудитории), долго не утрачивает свою “актуальность”. Да что там и говорить, даже я почти превратился с скуфа, которому бы не помешала такая альтушка (хорошо, что моя жена не читает DTF).

Немного о сюжете:
“В светлом будущем вопрос выбора жизненного спутника - уже давно решенный вопрос. И не решенный не кем-то там, а самим правительством страны! Теперь государство с любовью и заботой возьмет на себя трудности и ответственность подбора той единственной.

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

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

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

Теперь немного о геймплее:

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

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

Ближайшие планы на проект:

1. В ближайшее время планируем сделать тизер трейлер и привлечь внимание еще большей аудитории к нашему проекту.

2. После этого доделаем прототип и обкатаем его на наших подписчиках на Boosty

3. Затем учитывая полученный фидбек, будем готовить вертикальный срез. Он уже пойдет в Steam и, может быть, другие площадки.

Особенности разработки:

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

Следить за проектом, поддержать его и поучаствовать в развитии (получив при этом бонусы и дополнительные контент) можно на Boosty
В более пассивном режиме смотреть новости по его разработке можно в телеграм-канале.

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

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

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

• Трудозатраты - потребуются долгие сотни и тысячи часов чтобы обучить такой ИИ даже двигаться в нужную сторону. Даже при ускоренных симуляциях и многих обучаемых агентах одновременно. Ведь ему нельзя напрямую говорить “иди туда”, надо давать “награды”, если он идет куда следует. Правильная и сбалансированная выдача которых тоже довольно не тривиальная задача для всего что сложнее “змейки” или Flappy Bird. Что уже и говорить про интеллект для пошаговых тактик по типу XCOM, стратегий по типу Civilization или Crusaders Kings или про шутеры с хорошим ИИ по типу Killzone или FEAR (могли бы быть другие примеры, но я просто выбрал любимые игры. Напишите в комментарии свои любимые игры или игры с хорошим на ваш взгляд ИИ).

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

• Сложность в редактировании. Даже используя более продвинутые подходы, очень легко менять поведение персонажей - подкрутить кривую Безье в одном месте или отредактировать эффекты от действий и цели ИИ в другом. Но это не получится сделать так быстро с ML. Если вы, например, научили ботов в шутере атаковать как берсерков, не смотря на ранения, то сделать их более осторожными займет большое количество времени и итераций. Вспомните youtube с его жуткими алгоритмами - если вы посмотрели какой-то ролик на совершенно новую тему (например, музыкальное видео, хотя все остальное время смотрите подкасты и видео о программировании). То как долго вам придется игнорировать новые музыкальные видео, чтобы youtube наконец-то решил “ладно, видимо ему это и правда не нравится”. Повезет, если при этом он хотя бы не будет показывать тот единственный просмотренный ролик!

Поэтому реализации на самом деле “сложного” ИИ задача гораздо более объемная и невыгодная в сравнении с базовыми реализациями.

Во многих источниках выбор между подходом рисуют в виде прямой, над которой написаны все варианты в порядке “усложнения”. Вроде такого FSM → BT → Utility AI → GOAP. Но такой подход в корне не верен, так как не совсем понятно, что в таком случае есть “усложнение”. Ни один их этих подходов не является “сложным” в реализации. Но о том, в чем может заключаться сложность подхода поговорим немного позже.

В общем и целом, при выборе подхода надо ориентироваться на несколько составляющих:

• Количество действий/состояний персонажа (ходить, спать, стрелять и тд). Причем не только планируемых в ближайшую версию/спринт, а и планируемых в будущем. Чтобы не остаться со стейт машиной, в которой нужно проводить сотни стрелочек между действиями и помоги боже, если забудете хоть одну!

• Предсказуемость. Легко понять как будет вести себя персонаж, если у него черным по белому будет написано “если устал - иди спать”. Гораздо сложнее при этом смотреть на какие-нибудь формулы и анимационные кривые, которыми может выражаться “эффективность” для того чтобы “пойти поспать”. Если хотите меньше сюрпризов в его поведении, то смотрите в сторону FSM и BT. Если больше уникальности - GOAP и Utility AI.

• Горизонт планирования действий персонажа. Тут тоже все просто - при необходимости составления “стратегии” из действий двигаемся в сторону подходов, позволяющих это.

Теперь поговорим о “сложности” ИИ. До сих пор самым “сложным” игровым ИИ считается тот, который реализован в оригинальном F.E.A.R, выпущенном аж в 2005 году! Но сложность того ИИ заключалась не только в “поиске набора действий”, а в реализации дополнительных “фичей” поверх. Помимо них есть существуют еще обвесы для ИИ, такие как:

• Предсказание поведения игрока: “подожду игрока на левой дорожке, так как скорее всего он пойдет туда”

• Групповое поведение: “предупредим остальных, если игрок пойдет по левой дорожке”

• Динамически изменяемое поведение: “какие бы планы у нас ни были, если игрок пойдет по правой дорожке - побежим туда”

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

Поэтому в следующий раз, когда возьметесь за написании игрового ИИ, не будьте узколобым сторонником "легких" и "сложных" подходов - выбирайте с умом!

А теперь, когда мы немножко поговорили про матчасть игрового ИИ, по всем инфоцыганским законам сделаю небольшой прогрев)

Вот что оказалось самым забавным в моем поиске - это что ни один из туториалов не предлагает такую реализацию ИИ - реально “сложную” реализацию. Оно и понятно, игроки стали казуальными, даже в ААА. С каждой новой игрой от ubisoft, ютуб заполняется роликами, насколько же тупые у них боты. Поэтому в качестве серии роликов “для продвинутых” хочу сделать видео про написание не просто “ИИ написанный с помощью Х”, а сделать серию роликов про по настоящему “сложный ИИ”, который будет уметь делать все перечисленное и не только.

Поддержите лайками, если нравится идея или напишите что об этом думаете в комментариях на моем канале (я еще не настолько выжил из ума, чтобы читать их здесь)! Или предложите на каком игровом примере на это было бы интереснее всего посмотреть. Я пока что думаю о top down shooter, чтобы и пострелять можно было, но и чтобы при этом было видно издалека, как ведут себя боты.

BTW, новые ролики будут на все том же канале, где и все остальные!