15

Как стать продюсером в геймдеве

Всем привет!

Продолжаем разговор по списку тем:

1) Что такое русский геймдев и надо ли вам в него попасть на самом деле

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

3) Вы попали в геймдев - что дальше? Лучшие практики, чтобы работать долго и счастливо.

4) Ожидания vs реальность. Чем на самом деле занимаются геймдизайнеры, программисты, проджект менеджеры, художники и продюсеры.

5) Как стать продюсером в геймдеве.

Как стать продюсером в геймдеве Gamedev, Разработка, Игры, Текст, Длиннопост

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


Неправильные (но рабочие) способы


1) Имея какой-нибудь управленческий опыт (или даже только желание), вы можете просто откликаться на вакансии продюсера. Бывает, что в некоторых стартапах люди, отвечающие за найм, сами не очень разбираются в предмете и получить работу можно, произведя нужное впечатление на собеседовании. Попытка не пытка - и рано или поздно проскочить на позицию продюсера получится.

2) Вы можете устроиться по знакомству - если какой-то ваш товарищ/родственник/бывший одноклассник занимает в геймдеве достаточно высокую позицию, чтобы нанять вас даже без опыта работы.


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


Правильный способ


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


Когда у вас будет в наличии несколько лет опыта работы геймдизайнером, возможны различные варианты:


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


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


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


Чем можно заполнить резюме продюсера, если у вас нет опыта работы продюсером


В резюме нужно включить ваш прежний рабочий опыт, относящийся к геймдеву. При этом стоит подчеркнуть моменты, в которых вы проявляли инициативу или частично выполняли продюсерские функции. Управление младшими геймдизайнерами, если вы работали главным геймдизайнером проекта, постановка и контроль выполнения задач, успешное внедрение каких-либо решений, которые вы предлагали по своей инициативе, релиз и отслеживание показателей проекта, работа с аналитикой.
Если вы твердо решили стать продюсером - не бойтесь откликаться на вакансии. Прямо сейчас эту должность занимают множество работников с худшей подготовкой, чем у вас. Не опускайте руки из-за отказов. Ходите по собеседованиям, присматривайтесь, какие требования работодатели предъявляют к продюсерам. Не сдавайтесь и рано или поздно работа продюсера будет вашей.

Какие личностные качества вам потребуются


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

Развивайте стрессоустойчивость. В работе продюсера много нервов - подробнее об этом ниже.


Точно ли вы хотите стать продюсером?


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

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


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


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


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


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


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


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


Почему продюсеров не всегда увольняют, если они перескакивают с одного провального проекта на другой?


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


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


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


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


5) Допустим, 20% продюсеров являются действительно хорошими специалистами, а остальные - плохими или средними. Но беда в том, что 20% крутых специалистов не могут делать 100% работы по продюсерскому направлению в русском геймдеве. Если всех плохих продюсеров уволить, то значительный пласт работы будет некому делать. При этом надо понимать, что хорошие продюсеры - не всегда сразу хорошие, а часто вырастают с опытом из плохих и средних. Не-увольнение подающего надежды продюсера после провала проекта может быть хорошим вкладом в будущее компании.


В заключение


Вот мы и закончили. Благодарю всех, кто следил за статьями и участвовал в обсуждениях! Надеюсь, эта информация будет полезной (или хотя бы развлекательной) для кого-нибудь. Прошу прощения за задержку последней статьи - готовил игру для участия в конкурсе инди-игр Indie Cup и готовил страницу игры  в Steam.

Удачного всем карьерного пути в геймдеве!

Дубликаты не найдены

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

Блин, прям, описан мой рабочий день. Ну, хоть в 5 часов можно пообедать спокойно (нет). Что там про вакансии - хватит 2+ года управления на банковских проектах?

раскрыть ветку 5
0

Да, шанс проскочить на должность продюсера у вас есть. Но я очень рекомендую сначала год поработать геймдизайнером, посмотреть на процессы изнутри. Иначе вы скорее навредите себе и людям, чем справитесь с работой.

раскрыть ветку 4
0

Я как раз про геймдизайнерские позиции. Достаточно пОлно описано, почему старт с продюсера есть некоторое зло.

раскрыть ветку 3
Похожие посты
150

Магическая Gothic по-русски - или рассказ о RPG SpellMaster The Saga

Вначале было слово, и слово было... Тетриандох?)

Всем привет, сегодня мне бы хотелось рассказать вам об находящейся в разработке отечественной игре SpellMaster The Saga. Данная игра представляет собой одиночную ролевую игру с видом от третьего лица в мрачном фэнтезийном сеттинге. Основным источником вдохновения для разработчиков является Gothic 2: Ночь Ворона.
Разработкой игры занимается маленькая инди-команда Spellbook Creations, основанная бывшими разработчиками Life is Feudal: Forest Village. SMTS разрабатывается на UE4.

Особенности игры:
+ Открытый, мрачный и недружелюбный мир
+ Ночи, полные опасностей и монстров
+ Возможность построить с нуля собственную магическую академию-цитадель и набрать в неё учеников
+ Широкие возможности по комбинированию заклинаний и их эффектов между собой
+ Нетривиальная система прокачки главного героя

Прямо сейчас поиграть в SpellMaster The Saga пока ещё нельзя, но можно подписаться на нас в нашей группе вк и добавить игру в вишлист в Steam, чтобы ничего не пропустить.
Страница игры в Steam: https://store.steampowered.com/app/1247100/SpellMaster_The_S...

Будем рады обратной связи и поддержке от разработчиков и любителей классических ролевых игр!

Магическая Gothic по-русски - или рассказ о RPG SpellMaster The Saga RPG, Компьютерные игры, Ролевые игры, Gothic, Indiedev, Gamedev, Разработка, Открытый мир, Видео, Длиннопост
Магическая Gothic по-русски - или рассказ о RPG SpellMaster The Saga RPG, Компьютерные игры, Ролевые игры, Gothic, Indiedev, Gamedev, Разработка, Открытый мир, Видео, Длиннопост
Магическая Gothic по-русски - или рассказ о RPG SpellMaster The Saga RPG, Компьютерные игры, Ролевые игры, Gothic, Indiedev, Gamedev, Разработка, Открытый мир, Видео, Длиннопост
Магическая Gothic по-русски - или рассказ о RPG SpellMaster The Saga RPG, Компьютерные игры, Ролевые игры, Gothic, Indiedev, Gamedev, Разработка, Открытый мир, Видео, Длиннопост
Магическая Gothic по-русски - или рассказ о RPG SpellMaster The Saga RPG, Компьютерные игры, Ролевые игры, Gothic, Indiedev, Gamedev, Разработка, Открытый мир, Видео, Длиннопост
Магическая Gothic по-русски - или рассказ о RPG SpellMaster The Saga RPG, Компьютерные игры, Ролевые игры, Gothic, Indiedev, Gamedev, Разработка, Открытый мир, Видео, Длиннопост
Показать полностью 6
35

Оптимизация Unity проектов

Я не являюсь гуру-профессионалом, но думаю многим начинающим пригодиться эта информация по оптимизации Unity проектов на примере моей игры Last Floor.
Оптимизация Unity проектов Gamedev, Игры, Компьютерные игры, Разработка, Оптимизация, Unity, Steam, Длиннопост

Что будем оптимизировать:


Звуковые файлы

Для звуковых эффектов нужно использовать wav файлы 44кгц, обязательно в моно формате (Или ставить галочку Force To Mono. Для музыкальных треков оставить стерео). Quality лучше всего оставить 100.


Для ускорения загрузки сцены лучше поставить галочку Load In Background, кроме звуков которые воспроизводятся сразу при старте сцены.


Материалы

Тут все просто - меньше материалов в Unity, больше статики и будет больше FPS Игры.


Свет

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


По возможности запекаем свет, на неподвижных объектах должен стоять флаг Static, в некоторых местах можно использовать реалтайм без теней.

Вообще настройка света и отражений в Юнити это тема для отдельной статьи.


Модели

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

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

Нужно убрать все возможные полигоны которые игрок никогда не увидит, это уменьшит количество проходов отрисовки кадра и уменьшит размер тестуры (или повысит ее детализацию).


Различные мелкие модели лучше объединить в наборы и использовать одну текстуру, это сократит количество материалов в Юнити и в целом очень хорошо скажется на итоговом FPS игры.

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

Оптимизация Unity проектов Gamedev, Игры, Компьютерные игры, Разработка, Оптимизация, Unity, Steam, Длиннопост

Развертка

Заполнять квадрат текстуры нужно по возможности максимально плотно но при этом оставляя отступы (8-16 пикселей для текстур 2к), чтобы при меньшем размере текстуры не было артефактов.


Одинаковые элементы складывать в кучу и сдвигать на 1 пункт за пределы координат (Это позволит избежать артефактов при запекании Normal и Ambient Oclusion карт).


Текстуры

Следует избегать больщих текстур 8-4к, лучше всего разместить модель на сцене и в редакторе Юнити постепенно уменьшать размер текстуры до появления мыла.


Большинство моделей с хорошей разверткой влезают в текстуру 1-2к без мыла.

Так же нужно упаковать текстуры Metallic и Smoothness в один файл для страндартного рендера. (R-Metallic, G-Пусто, B-Пусто, A-Smoothness). Для рендера HDRP будет другая техника упаковки текстур.


Для уменьшения размера билда используем сжатие CrunchedDX1 для обычных текстур и CrunchedDX5 для текстур с альфаканалом.


Код

Избегайте операций в Update, следите за нагрузкой CPU, пишите хороший код ;)

Оптимизация Unity проектов Gamedev, Игры, Компьютерные игры, Разработка, Оптимизация, Unity, Steam, Длиннопост

Итого у меня получилось:

Размер билда: 586Мб.

Строк кода: 5219

Моделей: 321

Текстур: 512

Звуковых файлов: 122

Музыкальных треков: 5 штук общей длительностью 25 минут.

Площадь локации: 10878 м2


Надеюсь мой опыт поможет вам сделать хорошую игру.


Страница игры в Steam: https://store.steampowered.com/app/1251300/Last_Floor/

Показать полностью 2
52

Как сделать турбо-тоннель эффект в Unity с помощью Particle System

Я не знаю, как назвать такой эффект: дыра, пещера, турбо-тоннель, wormhole или, может, пищевод, но результат выглядит так:

Как сделать турбо-тоннель эффект в Unity с помощью Particle System Unity, Туториал, Визуальные эффекты, Gamedev, Разработка, Гифка, Видео, Длиннопост

Для реализации этого эффекта подойдёт практически любой игровой движок: мой первый вариант был сделан ещё на флеше. Здесь же расскажу на примере Unity (Version 2019.2.4f1).

Я добавил такой эффект во вступительном ролике и тизере своей игры про атаку вирусов на иммунную систему «Listeria Wars».

ПОШАГОВАЯ РЕАЛИЗАЦИЯ


Создание сцены


Я использовал 2D темплейт при создании проекта, но можно использовать и 3D. В любом случае понадобится ортографическая проекция в настройках камеры и сплошной чёрный фон.

Как сделать турбо-тоннель эффект в Unity с помощью Particle System Unity, Туториал, Визуальные эффекты, Gamedev, Разработка, Гифка, Видео, Длиннопост

Создание материала


Для Particle System понадобится материал со спрайтом тоннеля. Я нарисовал вот такую картинку, не особо заморачиваясь, так как эффект динамичный и мало кто успеет оценить вашу невероятную детализацию. Но всё, конечно, на ваш вкус. Изначально спрайт был красный, но для динамического цвета стоит перевести его в черно-белый режим.

Как сделать турбо-тоннель эффект в Unity с помощью Particle System Unity, Туториал, Визуальные эффекты, Gamedev, Разработка, Гифка, Видео, Длиннопост

Закидываем наш спрайт в папку для спрайтов в Assets и создаём новый материал Tunnel Wall (создаём папку Materials, по ней кликаем правой кнопкой мыши → Create → Material). В настройках выбираем шейдер Mobile/Particles/Alpha Blended (в старых версиях Unity Particle/Additive). Затем в Particle Texture кликаем по нашему спрайту тоннеля.

Как сделать турбо-тоннель эффект в Unity с помощью Particle System Unity, Туториал, Визуальные эффекты, Gamedev, Разработка, Гифка, Видео, Длиннопост

Добавление основной Particle System


Добавляем в сцену пустой объект и называем Tunnel. В него мы будем помещать все необходимые партиклы и контроллеры. Кликаем правой кнопкой мыши и выбираем Effects → Particle System, который назовём Tunnel Wall по аналогии с именем спрайта. Начинается самое интересное! Настройка и эксперименты.


Основная суть данных настроек — это поочерёдное появление стенок тоннеля с последующим увеличением, где каждый последующий партикл находится за предыдущим. За счёт этого и получается эффект движения вперед по тоннелю.


Renderer

* Material: Tunnel Wall;

* Sort Mode: Oldest in Front;

* Max Particle Size: 5 (для возможности увеличения спрайта на размер больше, чем на пол экрана, где 5 — это разрешение экрана * 5).


Основные (Появляются при клике на хедер настроек, если скрыты)

* Start Lifetime 2.5 (Время жизни партикла, так же определяет скорость увеличения);

* Start Speed: 0 (Скорость не нужна);

* Start Size: 100 (Зависит от размера спрайта, выбираем на глаз, регулируем вместе с Size over Lifetime);

* Start Rotation: от 0 до 360 (Выбираем Random Between Two Constants, крутим партиклы как хотим);

* Start Color: Выбираем на вкус, если спрайт Tunnel Wall чёрно-белый. Осторожно, со слегка оранжевым цветом турбо тоннель рискует превратиться в задний проход;

* Gravity modifier: 0.02 (Партиклы будут слегка падать, задаём немного динамики в движении);

* Simulation Space: World (Мы будем двигать точку создания партиклов, чтобы не перемещалась вся конструкция, ставим World);

* Max Particles: 10 (Смотрим итоговое количество партиклов в панели Particle Effect и устанавливаем столько же).


Emission: Rate over Lifetime: 4 (на вкус)


Shape (форма, которая спавнит партиклы)

* Shape: Circle;

* Radius: 0.05 (Чем меньше радиус, тем более ровными получаются стенки. Выбираем на вкус).


Color over Lifetime

* Я выставил такие настройки для плавного появления и менее плавного ухода

Как сделать турбо-тоннель эффект в Unity с помощью Particle System Unity, Туториал, Визуальные эффекты, Gamedev, Разработка, Гифка, Видео, Длиннопост

Size over Lifetime

* Размер должен увеличиваться примерно по экспоненте, но не с самого нуля

Как сделать турбо-тоннель эффект в Unity с помощью Particle System Unity, Туториал, Визуальные эффекты, Gamedev, Разработка, Гифка, Видео, Длиннопост

Результат на текущий момент

Как сделать турбо-тоннель эффект в Unity с помощью Particle System Unity, Туториал, Визуальные эффекты, Gamedev, Разработка, Гифка, Видео, Длиннопост

Другие партиклы


По аналогии я добавил другие частицы в виде клеток и вен. Расписывать подробно не буду, так как работу я проделал примерно аналогичную — настройки отличались лишь слегка. Следует учесть, что частицы должны быть поверх стен. Для этого необходимо задать Order in Layer в Renderer. Ещё я использовал Velocity over Lifetime, с этим тоже можно поиграться. Ну и добавил виньетку. Получилось так:

Как сделать турбо-тоннель эффект в Unity с помощью Particle System Unity, Туториал, Визуальные эффекты, Gamedev, Разработка, Гифка, Видео, Длиннопост

Немного динамики


Простым перемещением объекта Tunnel мы получим нелинейный тоннель. Добавим компонент Mover к Tunnel и удивимся результату

using UnityEngine;
public class Mover: MonoBehaviour {
public float rangeX = 2;
float rangeY = 1.5f;
public float timeDelimiterX = 4f;
public float timeDelimiterY = 3f;
void Update() {
transform.position = new Vector3(
Mathf.SmoothStep(-rangeX, rangeX, Mathf.PingPong(Time.time / timeDelimiterX, 1)),
Mathf.SmoothStep(-rangeY, rangeY, Mathf.PingPong(Time.time / timeDelimiterY, 1)),
0
);
}
}
Как сделать турбо-тоннель эффект в Unity с помощью Particle System Unity, Туториал, Визуальные эффекты, Gamedev, Разработка, Гифка, Видео, Длиннопост

Так же в коде можно менять каждый из параметров. Цвет, плавное вращение, скорость, да всё что угодно. Вот пример динамического света. Добавляем компонент и прикручиваем наши партиклы к аргументам.

using UnityEngine;
public class Colorizer: MonoBehaviour {
public ParticleSystem tunnelWall;
public ParticleSystem cellBig;
public ParticleSystem cellSmall;
public ParticleSystem cellVessel;
void Update() {
Color color = new Color(
Mathf.SmoothStep(1, 0.5f, Mathf.PingPong(Time.time / 10f, 1)),
Mathf.SmoothStep(0, 1, Mathf.PingPong(Time.time / 15f, 1)),
Mathf.SmoothStep(0, 1, Mathf.PingPong(Time.time / 5f, 1))
);
var tunnelWallMainSettings = tunnelWall.main;
tunnelWallMainSettings.startColor = color;
var cellBigMainSettings = cellBig.main;
cellBigMainSettings.startColor = color;
var cellSmallMainSettings = cellSmall.main;
cellSmallMainSettings.startColor = color;
var cellVesselMainSettings = cellVessel.main;
cellVesselMainSettings.startColor = color;
}
}
Как сделать турбо-тоннель эффект в Unity с помощью Particle System Unity, Туториал, Визуальные эффекты, Gamedev, Разработка, Гифка, Видео, Длиннопост

Залипательно!


Весь код и ассеты тут: Github


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


Страница игры в Steam: https://store.steampowered.com/app/1183010/Listeria_Wars/

Добавляйте игру в вишлисты!

Показать полностью 9
93

Ожидания vs реальность. Чем на самом деле занимаются геймдизайнеры, программисты, проджект-менеджеры, художники и продюсеры

Всем привет!

Продолжаем разговор по списку тем:


1) Что такое русский геймдев и надо ли вам в него попасть на самом деле

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

3) Вы попали в геймдев - что дальше? Лучшие практики, чтобы работать долго и счастливо.

4) Ожидания vs реальность. Чем на самом деле занимаются геймдизайнеры, программисты, проджект менеджеры, художники и продюсеры.

5) Как стать продюсером.

Ожидания vs реальность. Чем на самом деле занимаются геймдизайнеры, программисты, проджект-менеджеры, художники и продюсеры Игры, Длиннопост, Текст, Разработка, Gamedev

На этот раз поговорим о пункте №4 - Ожидания vs реальность. Чем на самом деле занимаются геймдизайнеры, программисты, проджект менеджеры, художники и продюсеры.


Многие новички попадают в корпоративную разработку игр, не имея четкого представления о том, чем именно занимаются представители различных профессий в геймдеве. Что часто приводит к неприятным столкновениям с реальностью и разочарованиям. Цель данного текста - хотя бы немного ознакомить людей, которые хотят попасть в геймдев (или недавно попали), с реальным положением дел, чтобы они примерно понимали, что их ждет. В графе "Ожидания" я буду писать наиболее частые представления о профессиях, которые я встречал со стороны людей, находящихся вне корпоративного геймдева.


1) Чем занимаются геймдизайнеры.


Ожидания:

Геймдизайнер - творец, придумывает игровые миры, фонтанирует креативностью, взаимодействует с дружной командой творческих единомышленников.


Реальность:

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


Чем может быть занят геймдизайнер:


- Составление ТЗ (технического задания) на какую-то новую запланированную фичу в игре. Требуется подробно и понятно расписать, как будет работать фича, рассмотреть все неочевидные нюансы работы фичи, чтобы у программистов осталось минимальное пространство для неверных толкований.

- Составление ТЗ для художников + поиск рефов (референсов). ТЗ для художников - все то, что нужно знать художникам, чтобы корректно нарисовать контент. Какие действия предмет/персонаж будет выполнять в игре, какая у него предыстория (если есть), какие анимации в будущем для него запланированы. Поиск рефов - поиск в интернете и прикрепление к ТЗ картинок, которые помогут задать направление работе художника, дадут стилистический ориентир.

- Левел-дизайн - проектирование и сборка новых уровней, локаций.

- Генерация текстового контента для обновлений игры - написание квестов, сценариев ивентов, текстов акций.

- Интеграция контента для грядущего обновления игры - заведение новых квестов, акций, уровней.

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

- Поддержка проекта и внесение правок. Часто многие вещи после добавления в игру нуждаются в исправлении или перенастройке - правки баланса, графики, текстов, отключение неактуального контента. Если у компании есть живые выпущенные проекты - геймдизайнеры регулярно тратят время на их поддержку.

- Расчет, анализ и перерасчет баланса игры.

- Анализ проектов конкурентов.

- Анализ внутренних проектов, составление предложений по улучшению их показателей.


Работа геймдизайнера является креативной, но при этом геймдизайнер должен быть способен выдавать нужный контент даже, когда у него нет творческого настроения или вдохновения. При этом мало быть просто креативным и трудолюбивым, надо еще отвечать потребностям проекта и руководства. Например, задание - написать к понедельнику 160 реплик для персонажа. Вы написали 200 (отличных на ваш взгляд) реплик, но ваш руководитель пропустил в проект только 40. Будет считаться, что к назначенному сроку вы написали только четверть реплик.


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


2) Чем занимаются художники


Ожидания:

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


Реальность:

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


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


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


Часто результат вашей работы будут оценивать люди, не имеющие отношения к рисованию - продюсеры и геймдизайнеры.


Значительную часть работы будут составлять вещи, которые вы не умеете рисовать/не рисовали раньше/не хотите рисовать.


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


3) Чем занимаются программисты.


Ожидания:

Проектировать и строить игровую реальность в окружении профессионалов. Строить изящные и продуманные структуры.


Реальность:

Шанс получить возможность спроектировать и накодить проект с нуля весьма невелик (особенно первые года 2 работы). В большинстве случае вам придется включаться в уже существующие проекты, разбираться с чужим кодом - наследием программистов, которые работали на проекте до вас.

Часть времени всегда будет неизбежно тратиться на фикс багов.

Часть - на объяснение геймдизайнерам и продюсерам, почему невозможно реализовать те или иные фичи.


Если у компании есть активные выпущенные проекты:


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

- на носу объявленное игрокам обновление, а какой-то функционал еще не готов или тестировщики нашли баг за 2 часа до релиза.


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


А еще начальство может прийти и сказать, что передумало - и вам придется удалять/откатывать/переделывать функционал, который вы делали последние 2 недели (предварительно согласовав все с этим же начальством). Тоже не редкая ситуация.


4) Чем занимаются проджект-менеджеры (ПМ).


Ожидания:

Управляют проектом!


Реальность:

Заводят задачи в тасктрекерах. Следят за тем, чтобы другие сотрудники (например, арт-лиды и лиды-программисты) заводили задачи корректно, в соответствии с внутренними стандартами компании. Отслеживают состояние задач по проектам, выявляют аномалии - например, задачи, на которые затрачивается слишком много времени. Деятельность ПМ может значительно отличаться в разных компаниях. Бывают ситуации, когда ПМ является кем-то вроде секретаря, который просто присутствует на собраниях команды и печатает таски под диктовку продюсера, следит за оформлением задач - т.е. минимально на что-то влияет. Бывает и обратная картина, когда ПМ не только оформляет таски, но и:


- следит за рабочим временем сотрудников, кто сколько тратит времени на задачи.

- помогает организовать взаимодействие разных отделов (геймдизайнеры, художники, программисты).

- участвует в процессе найма и увольнении членов команды.


Хотя такие рабочие функции уже частично пересекаются с продюсерской деятельностью, но это не редкость. Бывает, что в отдельных компаниях ПМ частично выполняет продюсерские функции, продюсер частично выполняет функции ПМ или продюсер и ПМ совмещены в одном сотруднике.


5) Чем занимаются продюсеры.


Ожидания:

Командуют всеми, делают из игры то, что им хочется.


Реальность:

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


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


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


- Продюсер отвечает за бюджет и сроки разработки. Какие фичи проект может себе позволить, к каким последствиям это приведет, сколько человек и с какими зарплатами задействованы на проекте - ответственность продюсера.


- Продюсер отвечает за формирование команды - т.е. принимает решение о найме или увольнении сотрудников.


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


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


Подробнее про нюансы работы продюсеров и почему их не всегда увольняют, если они перескакивают с одного провального проекта на другой - в следующей статье. Спасибо за внимание!

Показать полностью
74

Поиск пути в играх. Алгоритм поиска пути A*

В своё время долго и упорно разбирал различные алгоритмы поиска путей для различных задач. Сейчас, во время отпуска, решил сделать доброе дело и поделиться накопленными знаниями.


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


Надеюсь, что это будет кому то полезным.

92

Что такое русский геймдев и надо ли вам в него попасть на самом деле

Всем привет!

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


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

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

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

- повысить свою информационную видимость (что будет полезно для релиза моей игры в будущем) - если материал найдет отклик у читателей.


Список запланированных для освещения тем:

1) Что такое русский геймдев и нужно ли вам в него на самом деле.

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

3) Я попал в геймдев - что дальше? Лучшие практики, чтобы работать долго и счастливо.

4) Ожидания vs реальность. Чем на самом деле занимаются геймдизайнеры, программисты, проджект менеджеры, художники и продюсеры.

5) Как стать продюсером.


В этой публикации мы начнем с первой темы - что такое русский геймдев и надо ли вам в него попасть на самом деле.

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


Что такое русский геймдев и почему вам в него, возможно, не надо:


1) Большинство приходящих в геймдев новичков вдохновлены любимыми играми детства (или чем-то современным). Реальное положение дел таково, что вы с высокой вероятностью не будете работать над подобными проектами. Русский геймдев преимущественно ориентирован на мобильные и социальные игры. Синглплеерные игры с сильным сюжетом, цепляющим за душу игровым экспириенсом - нет, здесь заняты не этим. Матч-3, фермы для женщин 30+, коллекционные карточные баттлеры - примерно этим занят русский геймдев. Игры рассматриваются не как произведение искусства, а как продукт. Работа в геймдеве - это проявление креативности только 10% времени. Остальное - анализ рынка, показателей продукта, и рутинная работа.


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


3) Работа в геймдеве - работа в команде. Придется забыть об уникальности своих идей и своей исключительности - многие яркие творческие одиночки не могут нормально перенести этот момент. Надо быть способным воспринимать критику своих идей, уметь договариваться, помогать другим членам команды, думать в первую очередь о качестве продукта, а не о своем эго.


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


5) Если вы сторонник нормированной рабочей недели - для вас также неприятностью станут неизбежные и регулярные переработки. Если у компании есть выпущенный проект, требующий постоянных контентных обновлений - переработки неотъемлемая часть работы. Например, надо успеть доделать ивентовый релиз к новому году, чтобы приурочить событие к конкретной дате. Или, внезапно, в 2 ночи может быть найдена критическая ошибка, которая позволяет игрокам получать ресурсы бесплатно. В таких ситуациях компания несет значительные материальные потери пока проблема не устранена, и как-то считается само собой разумеющимся, что все причастные будут работать столько, сколько нужно, чтобы устранить кризис. Обычно в таких условиях остаются люди, получающие удовольствие от работы, знающие, на что идут - недовольств по поводу переработок практически не встречал.

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

Надо четко понимать:

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



Какие реальные положительные моменты работы в корпоративном геймдеве:


1)  Если вы находитесь на распутье и выбираете, в какой сфере лучше построить карьеру. Без ложных ожиданий и фантазий - геймдев весьма хороший вариант. Сейчас много геймдев-компаний, где устройство по ТК РФ и белая зарплата. Но переехать, скорее всего, придется в Москву или Петербург - чтобы всегда иметь под рукой соответствующие предложения о работе, в других городах России корпоративный геймдев развит только мелкими вкраплениями.


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


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


4) Получение опыта - посмотреть на самые различные ситуации с самыми разными проектами. Делая игры сами - вы едва ли сможете получить такое количество опыта и знаний.


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


6) Наличие рядом крутых специалистов, у которых можно перенять опыт.


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


В итоге:

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

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

Показать полностью
116

Разработка искусственного интеллекта из искусственного идиота в пошаговой тактической игре

В тактических играх ИИ очень важен. Если ИИ видится как «искусственный идиот», то игру может спасти потрясающий мультиплеер, сюжет, атмосфера и графика (это неточно). Решение очевидное: делай хороший ИИ, в чём тут могут быть проблемы?

Разработка искусственного интеллекта из искусственного идиота в пошаговой тактической игре Игры, Компьютерные игры, Разработка, Искусственный интеллект, Gamedev, Мобильные игры, Браузерные игры, Гифка, Видео, Длиннопост

В деталях. Ниже описаны мои шаги по конструированию сильного ИИ с характером. Не супер сильного [1], но способного быстро отработать локально в прожорливом браузере любого средне-слабого ПК. Мною применён подход экспертных систем с использованием набора эвристик и мутаций. Описаны 15 шагов постепенного преображения ИИ, каждый из шагов можно пощупать.

Краткое описание


В подопытной браузерной игре ИИ основан на генерации множества возможных состояний — результатов выполнения текущего хода. (Из-за игровой специфики и удобства эти результирующие состояния в статье называются то сценариями хода, то стратегиями ИИ — в зависимости от контекста). Затем сценарии хода подвергаются мутациям. По полученным сценариям вычисляются оценки «успешности». Самая успешная и выполняется компьютерным игроком.


Например, генерируются три стратегии:


1. Бежать оголтело всем вперед и атаковать всех, кто подвернётся под руку. Очки итогового состояния: 37000 баллов.

2. Атаковать лучниками с безопасного расстояния, а остальные прячутся по углам. 45000 баллов.

3. Всем отступить, сгруппироваться и попрятаться от врагов. Если можно при этом ранить какого-нибудь врага с безопасного расстояния, то атаковать. 18000 баллов.

В этом случае будет выбрана 2-я стратегия.

Разработка искусственного интеллекта из искусственного идиота в пошаговой тактической игре Игры, Компьютерные игры, Разработка, Искусственный интеллект, Gamedev, Мобильные игры, Браузерные игры, Гифка, Видео, Длиннопост

Ну вроде всё стандартно. Не совсем.


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


Правила игры


У игрока и у ИИ изначально по углам выдаются по 6 одинаковых юнитов. Каждая команда ходит по очереди всеми юнитами сразу. Варианты хода каждого юнита:

- пропустить ход;

- передвинуться и пропустить;

- передвинуться и атаковать (можно и иногда нужно атаковать своих).


Игровое поле и состав команды генерируется процедурно (то есть случайно, но с проверками на проходимость и приемлемую «тактичность»). Типы юнитов:

1. Боец F, юнит ближнего боя с самой большой живучестью, уроном и мобильностью. Эдакий танк+дамагер.

2. Лучник A, самый низкий урон, зато атака на расстоянии 1-7 по прямой линии.

3. Колдун W, умирает с одного удара бойца, зато атака на расстоянии 1-5 по прямой линии насквозь по всем юнитам.


Игровое поле всегда размером 10*10.


Возможные поля на карте:

- Земля — не накладывает никаких ограничений.

- Стена — через неё нельзя ни прострелить, ни пройти.

- Вода — через неё нельзя пройти, но через неё может стрелять лучник (огненный маг не может).

Разработка искусственного интеллекта из искусственного идиота в пошаговой тактической игре Игры, Компьютерные игры, Разработка, Искусственный интеллект, Gamedev, Мобильные игры, Браузерные игры, Гифка, Видео, Длиннопост

Игра полностью детерминирована, то есть в ней нет элемента случайности (шанс попадания 100%, никаких критических уронов и т.п.). Также это игра с полной информацией, то есть соперники всё знают о состоянии войск друг друга в любой момент времени. Как в шашках.


ИИ сильнее мясного игрока, но у последнего на первом уровне есть фора в виде одного юнита. На 3-ем у игрока наоборот хандикап в одного юнита и победить гораздо сложнее (у меня около 15% побед на этом этапе). Затем идёт более рандомная версия Игра+.


Изначально был разработан другой план игры в виде «качелей» как в турнирной таблице, но в конце разработки я отказался от него, как от слабомотивирующего. Смысл был в том, что если какая-то команда проигрывает, то на следующей карте ей даётся +1 юнит, и так максимум до 10 против 6. Если и потом команда умудрялась проиграть, то её юнитам увеличивались характеристики.


Игра разработана на нативном javascript: на div-ах и css-стилях, и это было самое неудачное решение из возможных [2]. Это браузерная игра. Движок не использовался. Единственная цель проекта — создать сильного компьютерного игрока «с характером» и возможностью изменения этого характера (расчетливые киборги, агрессивные орки, коварные эльфы, глупые зомби).


Для уменьшения «компьютерного стиля» у противника были применены некоторые хитрости:

- Игрок после своего хода не ждёт, пока ИИ подумает над своим ходом. Враг «сразу» начинает делать свои передвижения (в действительности это иллюзия).

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

- ИИ умеет использовать коварные приманки, чтобы навязать бой (тут всё по-честному).


И что тут сложного?


Сперва может показаться, что тут все просто: можно просто перебрать все варианты всех ходов и выбрать наилучший. Но очень скоро становится очевидным, что всё очень даже непросто.

Полный перебор невозможен из-за эффекта комбинаторного взрыва [3], который заключается в том, что по мере роста числа проверяемых элементов в сценариях сложность вычислений растет по экспоненте. Далее опишу, что это значит в моей конкретной игре.


Во-первых, т.к. на каждом ходу юниты команды ходят все сразу, то возможна разная их очередность. А при 6 юнитах в команде таких комбинаций становится 720 (1*2*3*4*5*6). Если юнитов будет больше, то комбинаций будет вообще огромное количество (при 7 — 5040, при 8 — 40320...). Если не учитывать максимального исхода, то игрок рискует распробовать удовольствие в ожидании очередного хода на 5-10 минут (а если он упорный, то задержка дорастёт и до миллионов лет, не каждый вытерпит). Именно из-за этой характеристики мой ИИ в начале боя менее эффективен, чем в конце. Ведь ближе к концу половина команды уже погибла.

Разработка искусственного интеллекта из искусственного идиота в пошаговой тактической игре Игры, Компьютерные игры, Разработка, Искусственный интеллект, Gamedev, Мобильные игры, Браузерные игры, Гифка, Видео, Длиннопост

Во-вторых, каждый юнит может передвинуться в разные точки карты. Бойцы с дальностью передвижения 4 могут походить на 1-41 разных позиций. У магов и лучников с их передвижением в 3 возможное число ходов равно 1-25. Например, состав команды может быть: 4 бойца, 1 маг и 1 лучник. Итого разных комбинаций ходов по данному пункту мы получаем: 41*41*41*41*25*25 = 1766100625. В действительности из-за взаимных пересечений и непроходимой местности комбинаций будет меньше, но в редкой ситуации «разбегания по карте» число комбинаций будет приближаться к этому числу.


В-третьих, каждый юнит после передвижения может пропустить ход или атаковать в одном из 4 направлений. То есть имеем по 5 возможных завершающих действий на юнита. Всего комбинаций: 5^6 = 15625.


Итого комбинаций: 720 * 1766100625 * 15625 = 19868632031250000.

Разработка искусственного интеллекта из искусственного идиота в пошаговой тактической игре Игры, Компьютерные игры, Разработка, Искусственный интеллект, Gamedev, Мобильные игры, Браузерные игры, Гифка, Видео, Длиннопост

И в каждой валидной комбинации надо будет рассчитать баллы результирующего состояния. В оценочную функцию входят: эмуляция передвижений, атака, нанесение урона, гибель юнитов и подсчёт оставшихся хитпоинтов у выживших. Конечно, число комбинаций завышено, т.к. в реальных условиях вариативность будет уменьшаться за счёт границ и препятствий на карте, однако это всё равно будет неподъёмное число комбинаций. А всё это происходит ведь в обычном браузере.


Как же сделано?


Чтобы решить подобную задачу, был использован эвристический подход, обобщённый алгоритм которого можно описать так:

1. Сгенерировать разные сценарии на основе заранее прописанных стратегий (~20 штук).

2. Пока есть время, проводить мутации сценариев, оставляя наиболее выгодные.

3. В конце выбрать сценарий с наибольшей оценкой.

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

5. Повторить для оставшихся юнитов с пункта 1.


Эвристический метод — это метод, который может сработать (по Макконнеллу [4]). Подробнее и строже в Википедии [5].


Ключевые моменты в этом алгоритме: генерация сценариев, мутации и правильная оценка выгодности состояния. В каждом из этих пунктов используются свои собственные локальные эвристики. Тем не менее, там где можно, использовались алгоритмы с гарантированным оптимальным результатом, например, А* для поиска пути [6].


Использованный мною эволюционный подход нельзя назвать полноценным генетическим [7], т.к. от него я использовал только мутации и выживание «сильнейшего», а коэффициенты влияния отдельных эвристик настраивал вручную. Алгоритмов формирования популяций и скрещиваний не применялось. После мутации выживает только один: либо мутант, либо родитель.

Разработка искусственного интеллекта из искусственного идиота в пошаговой тактической игре Игры, Компьютерные игры, Разработка, Искусственный интеллект, Gamedev, Мобильные игры, Браузерные игры, Гифка, Видео, Длиннопост

Нейронные сети [8] мною не использовались из-за особенностей задачи. Во-первых, из-за сложности их успешной реализации в условиях постоянно меняющейся среды (появление новых механик, навыков, способностей). Во-вторых, из-за сложности в их контролируемой персонализации (если захочется сделать два поведения: стремительного Суворова и осторожного Кутузова [9]).


Эволюция искусственного идиота в искусственный интеллект


0) Сначала у ИИ были введены только 3 стратегии со случайными ходами. {Сложность игры #0}. Оценка состояния была просто случайным числом. И так как ИИ не единственный элемент разработки, мне пришлось довольно долгое время мириться с поведением сумасшедших рыбок.


1) Затем в расчёты оценки стратегии были добавлены проверки оставшихся юнитов и их жизней у ИИ и у игрока. {Сложность игры #10}. За мертвого юнита команде начислялось 0 баллов. За полностью здорового Х баллов (например, 100 000 за бойца F, 70 000 за лучника A, 85 000 за колдуна W). За раненого начислялись 50% от основной ценности, а оставшиеся 50% пропорционально оставшимся жизням от максимальных. Благодаря этому ИИ было выгоднее добивать врагов, а если он мог только ранить, то он выбирал противников с меньшим числом жизней — более уязвимых.


Случайные ходы стали более осмысленными — ИИ иногда давал сдачи.


2) Затем была добавлена более осмысленная стартовая стратегия:

max_agro — все солдаты бежали максимально ближе к врагам и старались нанести как можно больше урона. {Сложность игры #20}. Одна стратегия использовала изначальный порядок ходов юнита, вторая ходила ими в обратном порядке.


ИИ стал вести себя так, как ведёт себя самый примитивный искусственный идиот в тактических играх. И довольно часто именно такой ИИ в тактических играх и используется. Он популярен из-за своей надежности и простоты. Такой даже может победить — но очень редко.


Именно на это похоже поведение ИИ в провальной игре Master of Monsters – Disciples of Gaia, из-за чего в неё банально скучно играть [10].

Разработка искусственного интеллекта из искусственного идиота в пошаговой тактической игре Игры, Компьютерные игры, Разработка, Искусственный интеллект, Gamedev, Мобильные игры, Браузерные игры, Гифка, Видео, Длиннопост

3) Дальше были добавлены стратегии, учитывающие возможный урон от врагов при передвижениях, и выбирающие те ходы, которые приводили к наименьшей опасности — желательно нулевой. {Сложность игры #30}. И ИИ сразу же стал сверх трусливым, избегающим любой близости с противником — лучше уж сбежать, чем атаковать и ранить, ведь противник может дать большей сдачи!


Поэтому в оценке состояний стал тоже учитываться возможный урон врагу. Штрафные баллы от потенциального урона от врагов стали вычисляться с уменьшающим коэффициентом 0.20 (коэффициент постоянно перенастраивался). Это заставляло ИИ при выборе между атакой или бегством избирать агрессивный вариант, поскольку он приносил в 5 раз больше баллов, чем бегство. Но ИИ всё равно надолго остался трусливым, ведь чтобы попасть в такую ситуацию выбора, враг уже должен быть в досягаемости, а сам ИИ при таких оценках никогда не подставит себя первым под удар. То есть не пойдёт на сближение. Конечно, игрок будет чувствовать себя обманутым, ведь у ИИ бесконечный запас терпения и он может убегать от опасности вечно, вынуждая игрока к агрессии.


Следует отметить, что подобные вычисления возможного урона очень длительны без использования кэша. Один полный просчёт стратегии без оптимизаций изначально занимал 700 миллисекунд. А у меня ведь ограничение на весь ход одним юнитом ~4000 мс! После оптимизаций и отработавших кэшей это время уменьшается до 20 миллисекунд при очень похожих стратегиях (к сожалению кэш невозможно просчитать весь заранее из-за эффекта комбинаторного взрыва, поэтому 20 мс достигаются не всегда).


Поэтому когда я внедрял технологию расчета с прогнозированием на несколько ходов вперёд, то время расчетов для глубины только в 2 хода (врага и ИИ) занимало уже +700 миллисекунд. В этом случае применяют оптимизацию с отсечением «слабых» веток. Если для этого пользоваться хоты бы примитивной стратегией max_agro, то увеличение времени было +30 миллисекунд и кэширование эту разницу почти не уменьшало (т.к. позиция на карте была совершенно новой).


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


4) Следующие стратегии были направлены на расширение изначального разнообразия стратегий:

far_attack_and_hide — юниты стараются атаковать как можно дальше от противника, а если не атакуют, то прячутся от любой атаки.


close_group_flee — юниты отступают подальше от боя и группируются как можно ближе друг к другу. Если можно при этом безопасно атаковать врага — атаковать.

{Сложность игры #40}.


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


5) Затем настало время мутаций. {Сложность игры #50}.

Алгоритм мутаций был очень простой:

- при переборе выбранных стратегий создавалась одна копия стратегии;

- в этой копии производилась мутация хода;

- если ход становился невалидным, то он исправлялся до хоть какого-нибудь валидного по одной из стандартных стратегий;

- вычислялись баллы мутировавшей стратегии;

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


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


Сначала был реализован самый примитивный тип мутации: от 1 до 3 движений заменялись на случайные, порядок ходов оставался прежним. За одну итерацию расчетов в среднем на каждую стратегию создавалось ~5-15 мутаций. При этом в среднем каждая пятая мутация была более выгодной и заменяла стратегию родителя.


6) Эвристика приманки. {Сложность игры #60}.

Эта эвристика повторяла ту тактику, с помощью которой я выманивал ИИ на атаку одним юнитом, чтобы перебить его по одному. Этому трюку удалось научить и ИИ.


Для этого в функции вычисления баллов за состояние стратегии проверяется, соответствует ли текущее состояние ситуации приманки:

- Только один солдат ИИ может быть атакован;

- Только один враг может атаковать вылезшего юнита;

- Юнит компьютерного игрока после этой атаки обязательно должен выжить;

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


Эффект оказался отличным: игроку становится легче начинать бой самому. При этом чаще всего игроку всё равно выгоднее «повестись» на эту приманку, так как после ответной атаки он сможет навалиться на ИИ всем своим отрядом (это если он разумно сгруппируется предварительно). А там уже всё решат грамотные локальные тактические решения.

Разработка искусственного интеллекта из искусственного идиота в пошаговой тактической игре Игры, Компьютерные игры, Разработка, Искусственный интеллект, Gamedev, Мобильные игры, Браузерные игры, Гифка, Видео, Длиннопост

7) Потом мне стало бросаться в глаза, что бойцы ИИ постоянно разбегаются как тараканы. {Сложность игры #70}. Также солдаты могли забиться в угол или зайти в тесные тоннели, в которых ИИ сильно терял в своей эффективности перебора возможных атак.

Поэтому в оценочную функцию были добавлены эвристики оценки расстояний между юнитами и рельефа карты со следующими предположениями:


- Чем ближе союзники друг к другу «в среднем» — тем лучше (юниты реже стали разбегаться по разным частям карты).

- Чем ближе солдаты ИИ к в солдатам врага «в среднем» — тем лучше (мне нужен был наступательный ИИ).

- Чем больше максимальное расстояние между любой парой союзников, тем хуже. При этом расстояние в 4 не штрафуется, а всё что больше — штрафуется по экспоненте (это прекратило вытягивание солдат в уязвимые шеренги).

- Если солдат ИИ не может добежать и атаковать врага как минимум за 2 хода, то его надо штрафовать (это заставляет его наступать, но не подставляться самому под атаку).

- Если в радиусе 2 шага от солдата слишком много блокирующих позиций, то штрафовать его (реже стали забегать в тоннели).

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


8) Затем пришло время расширения стратегий. {Сложность игры #80}. Я не мог добавить полный перебор возможного порядка ходов юнитов, но я мог сделать перебор их ходов по типам: боец, лучник, колдун. Поэтому появились стратегии последовательности ходов, вида W_A_F: сначала ходят все колдуны, потом все лучники, потом все бойцы.


Таким образом добавилось 6 новых стратегий: W_A_F, W_F_A, A_W_F, A_F_W, F_A_W, F_W_A. Они не решили всех проблем, но заметно улучшили качество игры.


9) У меня были мутации, но толку от них было мало. {Сложность игры #90}. В основном они улучшали слабые стратегии, а удачные улучшались редко. Поэтому мутации были доработаны и каждый раз срабатывал один из случайных типов мутации:

- От 1 до 3 движений заменялись на случайные, порядок ходов оставался прежним (старый способ);

- Поменять местами порядок ходов двух случайных юнитов. Действия их оставить прежними, даже если они не оптимальны. Если ход повторить невозможно, то он пересоздаётся случайно одной из обычных стратегий до валидного состояния;

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


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


10) Затем были добавлены еще полуслучайные стратегии. {Сложность игры #100}. Порядок ходов генерировался случайно, а сами ходы выбирались по следующим принципам (по уменьшению их важности):

- нанести максимальный урон;

- получить как можно меньший урон в ответ;

- стать как можно ближе к врагам.


Заметного улучшения тут я не увидел, но проект уже перешел в ту стадию, когда каждое улучшение приводит к менее заметным воспроизводимым эффектам.


11) Мне надоели вопиющие ошибки ИИ, когда он при атаке своим колдуном сильно задевал моих солдат, но при этом ранил своих союзников. {Сложность игры #110}. Хотя перед этим он вообще-то мог походить ими и убрать их с линии огня. Поэтому была создана жёстко сгенерированная стратегия с ручными проверками:


- если есть колдун, то найти место, откуда он нанесет максимальный урон;

- если в этом месте или по пути удара есть союзники — запомнить их;

- сначала ходят все союзники, которых запомнили, и они не могут становиться на зарезервированные колдуном позиции (то есть освобождают дорогу);

- ходит колдун;

- ходят оставшиеся юниты.


Стратегия легко описывается на словах, но заморочно для её программирования.


12) Иногда юниты "убегали в кусты" прямо перед началом боевых действий. {Сложность игры #120}. В результате этого, когда начинался обмен атаками, то один или даже два юнита могли оказаться слишком далеко от военных действий и не помогали союзникам. Если это случалось, то я почти гарантированно выигрывал у ИИ. Если не случалось, то я чаще проигрывал. Избавлялся от этого я вводом новой эвристики по оценке результирующих баллов у стратегии. Для каждого юнита проводилась проверка:


1. Если юнит в этот ход атаковал, то он получал +1500 баллов.

2. Если не атаковал, то подсчитывались позиции, с которых враги смогут наносить урон союзникам. Продолжать подсчет, если таких позиций будет больше 0 (N > 0).

2.1. Если юнит не может достать и ударить ни по одной позиции (n = 0), то он получает штраф -1000 баллов.

2.2. Если юнит может достать до всех позиций, то он получает +1200 баллов.

2.3. Если юнит может атаковать до некоторых позиций, то он получает +(n/N)*1000 баллов.


Это позволило сильно улучшить «сплоченность» юнитов ИИ. К сожалению, начали появляться случаи «одного дезертира», когда в проигрышной ситуации один из раненых юнитов предпочитал прятаться за спинами своих товарищей вместо того, чтобы внести свою лепту, атаковав врага. Это нелепо выглядело, когда у компьютера остаётся всего 2 юнита, а у игрока 3 или даже больше. Дополнительная исправляющая эвристика представляет собой следующее правило:


IF ("у ИИ меньше юнитов, чем у противника" AND "у ИИ не больше 3 юнитов")
THEN "за каждого дезертира начислить сценарию штрафные баллы"

13) Под конец ввода стратегий их набралось уже под 25 штук. {Сложность игры #130}.


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


14) Примерно в начале была ещё интересная доработка. Изначально оценка ценности сценария вычислялась как разница сумм баллов:


Итоговые_баллы = Баллы_ИИ - Баллы_игрока

Но спустя несколько улучшений я вспомнил, что это не самое лучшее решение, т.к. тогда для ИИ будут одинаковыми ситуации «2 солдата против 1 одного солдата» и «4 солдата против 3 солдат». Поэтому баллы стали вычисляться как отношение:


Итоговые_баллы = Баллы_ИИ / Баллы_игрока

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


Хочу отметить, что все эти доработки вводились постепенно хоть и в указанном порядке, но многие из них улучшались, перерабатывались и исправлялись от багов в более хаотическом порядке. Реальных итераций было больше 100 штук.


Вот как играет финальный ИИ {Сложность игры #9999}:

ИИ ходит сразу, а не тратит время на раздумья


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


Основная технология быстрого хода — это предварительные вычисления во время простоя. Этот метод заключается в том, чтобы разбить процесс хода на 2 части: сами вычисления и показ анимаций результатов вычислений:


- вычисления хода первого юнита начинаются сразу же после хода игрока, пока еще вылетает окошко, что сейчас начнётся ход противника. А это целых 4 секунды, которые игроком не воспринимаются пустым ожиданием;

- вычисления второго и последующего ходов начинаются тогда, когда только начинается анимация хода прошлого юнита (то есть когда курсор ИИ только начинается своё движение). А время всех анимаций уже 4.5 секунды. Хотя правильнее это назвать не вычислением следующего хода, а улучшением уже выработанной прошлой стратегии и поиска новой, т.к. на каждой итерации рассчитываются ходы всей команды;

- при анимации ходов ИИ к двигающимся юнитам летает курсор ИИ, который притворяется, что он по ним кликает. Курсор летает максимально быстро, но чтобы оставалась комфортность слежения за ним. Более того, добавление курсора не только позволило увеличить запас времени вычислений с 2 секунд до 4.5, но и сделал просмотр хода компьютера более комфортным для человека;

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


Чтобы всё это не лагало в браузере и работало с достаточно стабильным FPS, расчёты производятся асинхронно воркером (Web workers) [11].


Этим я хотел избавиться от раздражающего окошка ожидания «Компьютер ходит». Такая неприятная плашка есть во многих хороших играх, например, в Xenonauts [12]. Я считаю, что мне удалось справиться с этой проблемой.

Разработка искусственного интеллекта из искусственного идиота в пошаговой тактической игре Игры, Компьютерные игры, Разработка, Искусственный интеллект, Gamedev, Мобильные игры, Браузерные игры, Гифка, Видео, Длиннопост

Таким образом, ИИ тратит на обдумывание своего хода всегда одинаковое время — независимо от его сложности. Очень любопытная особенность этого подхода в том, что чем сильнее у игрока компьютер, тем большее число мутаций ИИ успеет перебрать, а значит будет тем сильнее, чем мощнее компьютер игрока. Я сначала убрал данный эффект с помощью фиксации времени хода и предварительного подсчета скорости работы компьютера. Однако потом я убрал эту фиксацию, т.к. владельцам мощных компьютеров это позволит сразиться со «своим» компьютером, а не усреднённым.

Каков результат и в чём недостатки


Таким образом, получившийся компьютерный противник умеет достойно сражаться и хорошо пользуется любыми оплошностями игрока, а своих делает не слишком много. Тем не менее, я, зная все особенности его работы, хоть и с напряжением, но побеждаю его почти всегда (при равных условиях). А хотелось бы наоборот: чтобы даже зная о его особенностях, почти всегда ему проигрывать. ИИ далёк от идеала, поскольку используемый мною набор эвристик приводит к синергетическому наложению «ошибок моего восприятия» друг на друга. Вот эти ошибки:


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

2. Потеря эффективности (которая итак не идеальна) выработанных рабочих эвристик при переносе их на программный код. Например, моя человеческая эвристика «Юниты держатся рядом, но не слишком близко, чтобы избегать двойного урона от магов и не застрять в узких проходах». Эта эвристика помогает мне побеждать ИИ, но при обучении ею моего компьютерного оппонента, мне приходится качественное описание переводить в алгоритмическое с количественными оценками, и тут возможна потеря данных.

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

4. Жесткие временные ограничения и пошаговые улучшения выбранных стратегий приводят к тому, что первый ход всегда будет менее продуман. Это значит, что один неудачный первый ход может заблокировать очевидные более эффективные ходы остальных юнитов команды. Это выражается в том, что первый боец F вместо отхода может криво атаковать противника и потом его союзнику волшебнику W придётся ранить своего, чтобы добить противника.


Полноценные генетические алгоритмы вместо «подбора на глазок» скорее всего позволили бы подобрать более оптимальные коэффициенты в эвристиках. Но это уже задача для будущих полноценных проектов — не хочется надолго застревать с прототипом. Текущим ИИ я вполне доволен: он расчётливый, немного коварный, достаточно агрессивный и не позволит игроку победить себя в сухую (в действительности чрезвычайно редко позволит).


Дополнительные возможности


Подобный способ реализации позволяет добиться дополнительных бонусов в игровой разработке (во многом с точки зрения разработчика и его горящих сроков):


1. Появление новых механик в игре не разрушит силу компьютерного игрока, хотя и будет постепенно его ослаблять по сравнению с игроком. Это ослабление может компенсироваться вводом дополнительных эвристик. Чтобы это не приводило к прогрессирующим расходам ресурсов, применять эти новые эвристики можно только при наличии этих новых механик в текущем сражении.

2. Действительно интеллектуальные уровни сложности. Сейчас в основном уровень сложности определяет то, какие бонусы компьютерный игрок получит в качестве ресурсов (больше золота на старте или бонус в добыче) или как сильно его солдаты будут бить (+50% к урону). Это работает, но можно ведь сделать ИИ чуть менее умным просто постепенным отключением некоторых эвристик по мере уменьшения сложности.

3. В продолжении 2-го пункта можно создавать и разные расы/фракции компьютерных противников: у орков работают только агрессивные стратегии; у толп зомби только примитивные «бежать вперед и атаковать»; а у киборгов использовать всю мощь ИИ. Благодаря этому игроку перед нападением придётся оценивать не только числа у противников, но и их интеллектуальность.


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


Где пощупать


Вы можете протестировать силу этого ИИ в браузерке «AI tactical rumble. Test subject» бесплатно на площадках типа itch.io [13]. GET параметр ai (значения от 0 до 140 с шагом 10) позволит снизить сложность ИИ.


По моим ожиданиям победить ИИ на равных условиях Вам будет очень и очень сложно. Даже после привыкания к правилам игры. Я рекомендую рассматривать данную игру, как прототип, каковым она по сути и является (музыки, звуков и цены в ней нет).


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


Список литературы


1. DeepMind — статьи на Хабре.

2. HTML5 games: Canvas vs. SVG vs. div на stackoverflow.

3. Комбинаторный взрыв — Википедия.

4. Совершенный код Стива Макконнелла — Хабр.

5. Эвристические методы — Википедия.

6. A* — Red Blob Games.

7. Генетический алгоритм. Просто о сложном — Хабр.

8. Восемь потрясающих игр с искусственным интеллектом от компании Google — Хабр.

9. Очень кратко о Суворове и Кутузове.

10. Master of Monsters – Disciples of Gaia — обзор на IGN.

11. A Detailed Explanation of JavaScript Game Loops and Timing.

12. Xenonauts и долгий экран ожидания ИИ.

13. AI tactical rumble. Test subject — на itch.io.

Показать полностью 8 1
Похожие посты закончились. Возможно, вас заинтересуют другие посты по тегам: