Виталий Агафонов, руководитель продукта Nau Engine
Почти любой геймер хоть раз мечтал создать собственную игру. Чтобы всё как у любимых студий, только лучше. Вот только большинство таких произведений не доживает не то что до релиза — даже до стадии продакшена. С чего же стоит начать работу над проектом мечты? Советует Виталий Агафонов, руководитель продукта Nau Engine.
Оглавление
Почему планирование необходимо
План — это первое, что нужно для любой работы. Чем дальше он смотрит, тем лучше.
Многие игнорируют эту простую и очевидную вещь. Поначалу кажется, что без плана работать удобнее. Действительно, куда проще решать мелкие тактические задачи по одной и не смотреть на большую и страшную общую картину. Планирование требует времени и усилий. Но оно обязательно вознаграждается, если мы хотим пройти путь от любительской разработки по вечерам до публикации в Steam игры, которую увидят не только наши друзья и родственники.
Отсутствие плана — одна из самых больших ошибок при создании игры. Да и вообще в любой работе.
Со стороны может казаться, что работа геймдизайнера — синекура. Знай себе лежи на диване да придумывай игры. На самом деле это всё-таки работа, пусть и в креативной области. И она требует продуманного пути. В рамках каждого проекта есть несколько обязательных шагов, которые должны сделать разработчики.
Что такое питч и зачем он нужен
Прежде всего необходимо придумать игру. Её суть могут описывать разные документы, но на базовом уровне достаточно питча. Питч — это презентация, которая представляет игру публике, например, инвесторам. Этот документ в принципе обязателен для любого начинания как инструмент для очерчивания вводных, от которых отталкивается всё дело.
Часто, решая какую-то задачу, мы держим все договоренности и отправные точки в голове. Но что-то обязательно будет забыто, что-то — неправильно услышано или неверно понято. В конце концов, восприятие проекта просто может поменяться со временем. Это справедливо даже для соло-разработки. Что уж говорить про командную работу, неизбежно связанную со сложностями взаимодействия между разными людьми. Наличие зафиксированных договоренностей помогает им эффективно работать друг с другом.
Вот что необходимо в первую очередь зафиксировать, начиная работу над игрой:
- Основы игры: жанр, кор-геймплей, основной игровой цикл — во что, собственно, будет играть пользователь. Например, «исследование уровней и сражение с врагами холодным оружием с видом от третьего лица» или «пошаговая 4Х-стратегия про строительство империи со сменой исторических эпох».
- Уникальные преимущества, которые отличают этот проект от других. Они должны объяснять, чем наша игра будет лучше конкурентов, чем она будет выделяться. Например, в ней может быть прорывной искусственный интеллект противников на основе нейросетей или одновременная поддержка десяти тысяч игроков на одном сервере.
- Сеттинг: что, как и где происходит в игре. Потому что космический шутер с пришельцами и шутер в декорациях окопов Первой мировой могут быть очень похожи с точки зрения механик и технологий, но быть очень разными в плане визуала и атмосферы.
- Внешние циклы. К примеру, ядро сессионного шутера вполне очевидно (бежим, стреляем, пытаемся захватить флаг или, скажем, набить побольше фрагов до истечения времени). Но помимо этого базового цикла игрок занят чем-то ещё: он продвигается по дереву технологий, открывает новых персонажей, оружие, способности и участвует в прочем мета-геймплее. Всё это важно учитывать заранее.
- Референсы. Любая игра на что-то похожа: идеями, механиками, сеттингом, героями, атмосферой. Все эти отсылки очень полезно зафиксировать, чтобы во время работы над проектом можно было сравнивать промежуточные результаты с первоисточниками, от которых мы отталкиваемся. Плюс, через сравнение банально проще объяснить, какую именно игру мы делаем. Скажем, Starfield легче всего описать одной фразой как «Fallout 4 в космосе». Четыре слова отвечают на множество вопросов о разработчике, технологиях, основах геймплея и других важных аспектах проекта.
- Монетизация. Понимать, как мы будем извлекать из игры прибыль, нужно ещё до начала разработки. Будет это, например, коробочная модель или free-to-play с микротранзакциями? А может, вообще полностью бесплатный проект для тренировки навыков? От ответа на эти вопросы зависит очень многое. Потому что, скажем, система прокачки, длина игровой сессии и другие элементы кор-геймплея будут по разному строиться в платных и условно-бесплатных проектах.
Есть много примеров, когда разработчики сначала делали игру, а потом начинали придумывать, как её продавать. Такой подход почти никогда не работает.
- Аудитория. Необходимо чётко понимать, кто наш игрок, и почему он захочет играть в игру, которую мы создаём. Это влияет почти на все аспекты проекта. Например, аудитория классических 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! Небольшая независимая команда пыталась работать сразу во все стороны, а в итоге вышел сыроватый продукт, в котором обещаний было больше, чем функционала. Реальной физике небесных тел, толковому взаимодействию между игроками и эпическим сражениям звёздных флотов здесь места не нашлось, всё это осталось где-то в пресс-релизах. Потом пришлось много извиняться, а игру доделывать — авторы полируют её до сих пор. Этого можно было бы избежать, если бы у создателей изначально было чёткое видение проекта, план, соответствующий их возможностям, и набор основополагающих тезисов.
Всё это не значит, что базовые положения непоколебимы. Их можно и нужно подвергать критике и сомнениям. Но системно, стратегически. Если же мыслить только на уровне локальных решений, то вскоре мы получим кое-как слепленный ком конфликтующих между собой фич — несколько игр в одной. Причём ни одна не будет хорошей.
***
Все эти советы помогут сформировать осознанный подход к разработке. Именно осознанность — то обязательное условие, без которого невозможно создать успешный продукт. И не важно, что именно мы понимаем под успехом: много денег, первое место в топе скачиваний или собственное веселье. Главное, вы сможете пройти этот путь до конца и не споткнуться где-то на середине. А потом — начать всё с начала с новой игрой мечты.
