Хочу создать свою игру! С чего начать?

Виталий Агафонов, руководитель продукта Nau Engine

Почти любой геймер хоть раз мечтал создать собственную игру. Чтобы всё как у любимых студий, только лучше. Вот только большинство таких произведений не доживает не то что до релиза — даже до стадии продакшена. С чего же стоит начать работу над проектом мечты? Советует Виталий Агафонов, руководитель продукта Nau Engine.

Почему планирование необходимо

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

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

Отсутствие плана — одна из самых больших ошибок при создании игры. Да и вообще в любой работе.

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

Что такое питч и зачем он нужен

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

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

Вот что необходимо в первую очередь зафиксировать, начиная работу над игрой:

  1. Основы игры: жанр, кор-геймплей, основной игровой цикл — во что, собственно, будет играть пользователь. Например, «исследование уровней и сражение с врагами холодным оружием с видом от третьего лица» или «пошаговая 4Х-стратегия про строительство империи со сменой исторических эпох».
  2. Уникальные преимущества, которые отличают этот проект от других. Они должны объяснять, чем наша игра будет лучше конкурентов, чем она будет выделяться. Например, в ней может быть прорывной искусственный интеллект противников на основе нейросетей или одновременная поддержка десяти тысяч игроков на одном сервере.
  3. Сеттинг: что, как и где происходит в игре. Потому что космический шутер с пришельцами и шутер в декорациях окопов Первой мировой могут быть очень похожи с точки зрения механик и технологий, но быть очень разными в плане визуала и атмосферы.
  4. Внешние циклы. К примеру, ядро сессионного шутера вполне очевидно (бежим, стреляем, пытаемся захватить флаг или, скажем, набить побольше фрагов до истечения времени). Но помимо этого базового цикла игрок занят чем-то ещё: он продвигается по дереву технологий, открывает новых персонажей, оружие, способности и участвует в прочем мета-геймплее. Всё это важно учитывать заранее.
  5. Референсы. Любая игра на что-то похожа: идеями, механиками, сеттингом, героями, атмосферой. Все эти отсылки очень полезно зафиксировать, чтобы во время работы над проектом можно было сравнивать промежуточные результаты с первоисточниками, от которых мы отталкиваемся. Плюс, через сравнение банально проще объяснить, какую именно игру мы делаем. Скажем, Starfield легче всего описать одной фразой как «Fallout 4 в космосе». Четыре слова отвечают на множество вопросов о разработчике, технологиях, основах геймплея и других важных аспектах проекта. 
  6. Монетизация. Понимать, как мы будем извлекать из игры прибыль, нужно ещё до начала разработки. Будет это, например, коробочная модель или free-to-play с микротранзакциями? А может, вообще полностью бесплатный проект для тренировки навыков? От ответа на эти вопросы зависит очень многое. Потому что, скажем, система прокачки, длина игровой сессии и другие элементы кор-геймплея будут по разному строиться в платных и условно-бесплатных проектах.

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

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

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

Первые шаги

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

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

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

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

Как научиться делать игры? Ответ прост: надо делать игры. Собственный опыт и ошибки зачастую значимо ценнее, чем советы со стороны. 

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

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

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

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

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

Что будет, если делать по-другому

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

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

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

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

Результат Oxide легко списать на отсутствие опыта. Но проблемы возникают и у опытных команд. Нельзя не вспомнить невезучую Anthem от известной и уважаемой BioWare. Когда разработчики принимались за этот проект, они планировали создать ни много ни мало «Боба Дилана от мира видеоигр» — что-то поражающее воображение, игру-сервис на многие годы.

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

Другой хрестоматийный пример — Fable. Авторы обещали «лучшую RPG всех времён»: с растущими в реальном времени деревьями, по-человечески разумными героями-конкурентами под управлением ИИ, живым миром, который полностью меняется в зависимости от действий игрока. Причём о новых функциях своего детища сами разработчики зачастую узнавали из прессы: глава разработки Питер Молиньё позже признался, что придумывал фичи прямо во время интервью. В итоге вышла хорошая игра, которая, однако, имела мало общего с обещаниями, за которые мсье Молиньё извиняется до сих пор. 

Или вспомним Kingdoms of Amalur: Reckoning. Изначально разработчики исходили из одних тезисов, но по мере развития проекта принимали решения, которые с ними конфликтуют. Получился кадавр, кое-как сшитый из двух разных частей: классической одиночной RPG и MMO. С одной стороны — интригующая завязка, интересная ролевая система и бодрая боёвка на уровне хорошего слэшера. С другой — огромный, но пустой мир, в котором нечего делать, простоватый сюжет, не самые сообразительные NPC, море однообразных почтовых квестов и постановка на уровне первой Gothic. Это в 2011 году и под руководством Кена Ролстона, создателя Morrowind и Oblivion! 

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

Ну и как обойти стороной No Man’s Sky! Небольшая независимая команда пыталась работать сразу во все стороны, а в итоге вышел сыроватый продукт, в котором обещаний было больше, чем функционала. Реальной физике небесных тел, толковому взаимодействию между игроками и эпическим сражениям звёздных флотов здесь места не нашлось, всё это осталось где-то в пресс-релизах. Потом пришлось много извиняться, а игру доделывать — авторы полируют её до сих пор. Этого можно было бы избежать, если бы у создателей изначально было чёткое видение проекта, план, соответствующий их возможностям, и набор основополагающих тезисов.

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

***

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

Оставьте комментарий

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

20 − 3 =

Прокрутить вверх