Как создаются игры. Основы разработки для начинающих игроделов

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

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

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

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

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

• Подготовка производства (препродакшн)

– Идея

– Концептирование

– Прототипирование

– Вертикальный срез

• Производство (продакшн)

– Горизонтальный срез

– Альфа

– Бета

• Релиз

– Поддержка

– Развитие проекта (если это предполагает его бизнес-модель)

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

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

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

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

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

Идея

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

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

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

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

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

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

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

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

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

Ограничения платформ и жанров намного менее значительны. Например, компании, занимающиеся разработкой условно бесплатных игр для мобильных устройств и соцсетей, ограничены не механиками, а бизнес-моделями. Это может быть и гонка, и головоломка, и RPG – неважно, главное, чтобы идея обещала, что цена трафика и оставляемые игроком в игре деньги сойдутся. Добиться этого можно довольно большим количеством методов, относящихся к понятию «развитой меты», о которой мы уже говорили. Соответственно, главным вопросом концепции для такой компании будут именно механики метагейма и устройство игровых циклов, а не одного только основного игрового процесса.

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

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

Еще одним не менее важным ограничением является сама возможность реализовать игру. Тут речь идет о доступных для разработки проекта ресурсах – как финансовых, так и человеческих. Сам вопрос ресурсов на этом этапе выглядит довольно странно, ведь проработка идеи часто ведется именно для того, чтобы получить финансирование на ее реализацию, и тут вроде бы есть возможность сказать: «Будут деньги – сделаем большую игру, не будет – сделаем маленькую». Но получение финансирования так не работает – деньги дают на вполне конкретный проект, и тут все зависит от того, в каких условиях идет эта проработка идеи.

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

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

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

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

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

Итак, мы определились с ограничениями, но откуда брать саму идею? Тут у нас есть всего два пути, где можно искать вдохновения: наши собственные пристрастия и подсказки рынка. И первый вариант не сильно отличается от второго. В любом случае мы можем обратиться к аналитическим инструментам, чтобы понять перспективы идеи. Если, конечно, наша разработка не является хобби, которое позволяет сказать: «Я так хочу!» Разница лишь в том, что в первом случае, когда мы уже знаем, какую игру хотим делать, мы сразу сталкиваемся с ограничениями – наша игра может оказаться в очень тяжелой с точки зрения рынка группе: много конкурентов либо очень маленькая аудитория. Второй же вариант, когда мы еще не определились с конкретной игрой, будет означать, что мы будем выбирать идею среди тех игр, которые будут наиболее перспективными из доступных нам по необходимым для реализации проекта навыкам или финансовым ресурсам.

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

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

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

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

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

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

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

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

Концептирование

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

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

Прежде всего декларируем основные характеристики будущей игры (с примерами).

• Жанр игры: шутер с открытым миром, многопользовательский гоночный симулятор, match-3 с сюжетом.

• Сеттинг и графический стиль: 2D-стимпанк, 3D-риал-лайф, темное фэнтези с 3D-уровнями и 2D-персонажами.

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

• Предполагаемая аудитория: пол, возраст, страна.

• Платформа, для которой будет разрабатываться игра: PC, консоли, мобильные устройства, социальные сети, VR.

• Игровой движок: Unity 3D, Unreal Engine, Godot.

• Дополнительные системообразующие программы и сервисы: Blender, Photoshop, Firebase, Azure, Play Fab.

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

• Каким образом игра будет издаваться: самостоятельно или через издателя.

• Каким образом игра будет распространяться: цифровая дистрибуция и/или продажа на физических носителях.

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

Дальше следует развернутое описание идеи.

• Описание игровых механик: какие механики будут в игре, какие ресурсы, игровые циклы.

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

• Краткое содержание сюжета (если он будет): описание основных персонажей и основных сюжетных поворотов.

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

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

• Сравнение с конкурентами: финансовые показатели конкурентов и какое-то преимущество, которое будет у нашего проекта по сравнению с проектами конкурентов.

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

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

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

Не на все вопросы получится ответить без определенного опыта. Не все ответы удовлетворят тех, кто эти вопросы будет задавать. Это нормально. И все же чем больше игра, чем больше людей над ней будет работать, чем больше денег вам будет нужно от инвесторов, тем больше будет вопросов и тем серьезнее придется продумывать ответы на них. Потому что варианты «Я так хочу», «Хочу попробовать реализовать эту механику» или «Мне интересен жанр» уже не подойдут. Все нужно будет обосновать.

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

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

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

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

Прототипирование

К этапу прототипирования мы можем прийти в разной степени подготовленности.

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

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

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

• выдвижение гипотезы;

• первичная документация и исследование;

• прототипы отдельных механик;

• прототип игры.

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

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

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

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

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

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

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

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

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

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

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

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

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

Таким образом мы получаем некие коэффициенты роста цены каждого уровня относительно предыдущего или относительно первого уровня. Естественно, нам нужно убедиться в том, что эти коэффициенты работают на всех постройках. Некрасивые, некруглые числа и разница в коэффициентах для разных построек легко объясняется тем, что разработчик оригинальной игры округляет цены до тысяч. При желании мы можем даже выявить формулу, по которой эти коэффициенты рассчитываются: например, (0,5 + 0,1 × (N – 1)) × N, где N – это номер уровня постройки, начиная со второго. Но исследования следующих деревень покажут, что коэффициенты не меняются ни от постройки к постройке, ни от деревни к деревне, а значит, их можно принять за константы.

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

С ценой первых уровней каждой из построек можно поступить примерно так же: делением.

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

Эта цифра оказывается очень близка к корню игры – основе ее баланса и всей идеи, а значит, простого коэффициента там, скорее всего, не получится. Нам необходима формула роста. Придется потратить какое-то время, чтобы собрать всю необходимую информацию для ее выведения: цены первых уровней первых построек, например для первых десяти уровней: 60 000, 101 000, 180 000 и так далее.

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

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

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

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

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

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

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

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

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

Сама проверка механики необязательно должна выливаться в написание кода. Мы можем проверить ее, например, в виде настольной игры. Особенно если нашей задачей является проверка того, насколько механика интересна, а не какова возможность ее реализации. Такая настольная игра может быть сделана буквально «на коленке»: можно взять бумагу из тетради или принтера, нарисовать карту, вырезать карточки действий и персонажей. Генератор случайных чисел в виде игрального кубика можно взять из другой настольной игры или найти в интернете.

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

Итак, нам нужно немножко поработать руками.

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

• У нас будет набор карточек с персонажами с разными случайными характеристиками. Карточки мы вырежем из той же бумаги, напишем на них имена персонажей, нарисуем портреты и распишем характеристики. Кому-то достанется +2 на сортировку стекла, кому-то +5 на управление погрузчиком и т. п. Мы можем сделать с десяток таких карточек и ограничим игрока правилом, что из персонажей он может взять только троих случайных. Двух можно поставить в зону сортировки, а одного на разгрузку.

• Мусор у нас будет в виде фишек – клочков бумаги с разными обозначениями: С – стекло, Б – бумага и т. п. Таких фишек нам нужно штук 50.

Дальше идет сам игровой процесс.

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

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

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

– Уже здесь можно немного задуматься над балансом игры. Игроку в начале хода может прийти и одна единица мусора, и шесть. Иногда игроку будет приходить меньше мусора, чем он может перевезти, а иногда больше. Тогда мусор начнет накапливаться в зоне разгрузки. В среднем d6 будет давать значение 3,5. Соответственно ставить на разгрузку персонажа с навыком меньше 4 довольно рискованно.

• В зоне сортировки мусор можно раскрыть и перевернуть. Сортировщики работают примерно по тому же принципу, что и погрузчик: игрок может переместить столько мусора, сколько очков есть у персонажей, находящихся в зоне сортировки. Если у нас есть два персонажа: на 2 очка стекла и 3 очка стекла – значит, суммарно за ход игрок может отсортировать 5 единиц стекла.

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

• создаем новую версию;

• тестируем;

• получаем отклик;

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

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

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

На этом этапе у нас пока еще нет ничего, кроме механик. Нет графики, звуков.

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

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

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

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

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

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

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

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

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

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

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

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

Вертикальный срез

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

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

Может показаться что данный этап ничем не отличается от непосредственного производства игры, но это немного не так. Здесь важно помнить, что производство – это конвейер. И он не терпит экспериментов, потому что это будет нарушать его работу, приводить к простою, за который придется платить, а бюджет не резиновый. Чтобы конвейер нормально работал, он должен быть очень хорошо отлажен. Должно быть известно, из каких этапов состоит производство отдельных элементов игры, сколько времени занимает каждый этап, сколько нужно произвести отдельных деталей для создания целого объекта – той же игровой локации, например.

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

Чтобы настроить конвейер, нам потребуется провести эксперимент и попробовать реализовать все элементы игры хотя бы в единственном экземпляре, чтобы замерить реальное время, необходимое для производства каждого из этих элементов. Идея заключается в том, чтобы получить хотя бы один уровень игры (если игра состоит из уровней), но финального качества. Со всеми необходимыми ассетами – персонажами и предметами – и выверенными параметрами.

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

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

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

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

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

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

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

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

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

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

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

• Если мы делаем гоночную игру, то нам необходимо сделать буквально одну машину и одну трассу – ведь противники могут ездить на той же машине.

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

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

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

Практически все элементы игры можно так или иначе сгруппировать по процессу производства, свойственному именно этому элементу. Он есть у отдельных предметов на уровне, у персонажей, даже у графической части работы над ними. Процесс, свойственный производству какой-то группы элементов игры, называется пайплайном (pipeline – «трубопровод»). Однако это не просто путь из точки А в точку Б.

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

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

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

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

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

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

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

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

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

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

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

Производство

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

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

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

Второй вариант принято называть игрой-сервисом (game as a service, GAAS). Этот вариант подразумевает, что игра может выйти на рынок в минимальном виде и будет дополняться и развиваться в случае успеха выпущенной версии. Подобный метод разработки и выпуска игр особенно распространен на мобильном рынке, но также потихоньку завоевывает рынки игр для РС и консолей.

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

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

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

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

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

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

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

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

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

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

Только не стоит увлекаться придумыванием новых механик – наша игра должна устояться уже во время работы над вертикальным срезом, и рассеивание внимания на непредусмотренные вещи может привести к тому, что проект не будет готов в должной степени к планируемой дате релиза. И тут таится другая угроза: переработки или кранчи, как их еще называют. Это очень печальная практика, связанная с провалом в планировании и менеджменте проекта. Для того чтобы этого не происходило, следует внимательнее относиться к сотрудникам и задачам, над которыми они работают, ведь осталось совсем немного до самого важного этапа – релиза.

Релиз и поддержка

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

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

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

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

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

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

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

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

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

Однако может так случиться, что этапы релиза игры для мобильных устройств не достигают показателей, необходимых для продолжения работы над игрой. Рекламный трафик может оказаться слишком дорогим, а оптимизация имеющихся механик – недостаточно эффективной. И в этом случае появится необходимость закрыть проект, прекратить его развитие и поддержку, несмотря на уже набранную аудиторию. Чем раньше проблемы будут выявлены, тем больше возможностей у нас будет их исправить или успеть начать новый проект, который может оказаться более удачным. В западной культуре существует поговорка «fail fast, fail often», которую можно перевести как «проваливайся быстро и часто», чтобы поскорее прийти к успеху.

Документация

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

• Бизнес-документация (описательная документация) – набор базовых документов, разрабатываемых на этапе концептирования проекта. Они предназначены для описания будущей игры и создания понятного ее образа. В основе этого набора документов находится концепт-документ, но может быть разработана еще группа документов типа вижена (vision – «видение») и питча (pitch – «презентация»). Описание игры, которое будет составлять эти документы, должно быть достаточным для понимания сути и перспектив игры даже неспециалистом. Эта документация ложится в основу всего проекта, становится его фундаментом и, соответственно, не должна меняться в процессе работы.

• Функциональная документация – это основная часть нашего дизайн-документа. Ее суть заключается в перечислении и описании игровых механик, компонентов, функций, фичей (feature – «особенность») и интерфейсов. Эти описания должны покрывать все элементы, из которых будет состоять игра, но при этом они могут разрабатываться и уточняться последовательно по мере необходимости. Основа диздока должна быть разработана еще на этапе прототипа. Сами описания должны быть достаточными для того, чтобы ответственные за распределение задач люди могли самостоятельно составить техническое задание для исполнителей.

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

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

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

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

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

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

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

1. Подготовительный этап

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

• Создание концепции – более детальное описание того, как идея должна быть встроена в игру, каким образом будут достигнуты поставленные цели.

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

• Финализация концепции – в соответствии с появившимися на предыдущем шаге сомнениями и новыми данными.

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

• Финальная оценка – определение трудозатрат, рисков и ценности идеи для проекта.

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

2. Производство

• Разработка дизайн-документации фичи – создание описания механики, персонажей, макетов и схем.

• Разбивка фичи на отдельные задачи (декомпозиция) – определение списка задач, которые необходимо выполнить для реализации фичи в полном объеме, и оценка времени на их выполнение.

В рамках одной фичи задачи могут делиться на взаимосвязанные логические блоки, для работы над которыми могут понадобиться очень разные навыки: арт, дизайн, программирование. В методике управления Agile эти блоки называются User Story (пользовательские истории, в данном случае это тоже производственный термин) и описывают буквально, что должен увидеть или иметь возможность сделать пользователь в результате окончания работы над этим блоком.

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

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

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

• Производство – собственно, выполнение задач, связанных с фичей.

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

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

3. Постпродакшн

• Анализ эффективности идеи – смогла ли она достичь поставленных изначально целей или нет.

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

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

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

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

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

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

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

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

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

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

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

• Механика – отобразить окно пользовательского соглашения. В окне будет область для текста, кнопка для выбора языка и кнопки отказа и подтверждения.

– По умолчанию текст и надписи на кнопках должны отображаться на английском языке.

– Если текст не будет умещаться в пределах окна, то должен отображаться скроллбар и, соответственно, должна быть возможность прокрутить текст вниз.

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

– Список языков должен браться из базы локализации игры.

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

– При нажатии на кнопку отказа происходит выход из игры.

– При нажатии на кнопку подтверждения происходит переход к следующему действию в соответствии со схемой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструменты

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

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

Для работы с текстами есть три инструмента разной сложности и распространенности.

• Программы типа Word, входящего в пакет MS Office, и его аналоги для работы с файлами, хранящимися на компьютере. Этого вполне достаточно при работе над игрой в одиночку, но надо помнить, что хранить файлы на компьютере небезопасно. Компьютер может сломаться и уничтожить труд всей жизни. Документация игры – это сложная структура, описывающая множество переплетенных друг с другом объектов, и работать с этой структурой в рамках одного или нескольких отдельных файлов может быть не очень комфортно.

• Сервисы типа Office 365 и Google Drive позволяют работать с файлами онлайн. Это удобно для работы в небольшой команде и позволяет иметь доступ к файлам в любое время с любого устройства, а также безопасно по сравнению с хранением файлов на своем компьютере. Но это также несет некоторые риски: требует подключения к интернету и ставит в зависимость от аккаунта в сервисе, который может стать по тем или иным причинам недоступным.

• Бизнес-приложения, предназначенные для отдельного ведения документации, или являющиеся частью более сложного комплекса сервисов. К первым относятся такие сервисы, как Notion и Confluence, – эти сервисы позволяют вести документацию в структуре, похожей на «Википедию». Есть также бесплатные сервисы для этого. Подобная структура значительно удобнее работы с отдельными файлами. Она позволяет создавать автоматические шаблоны разделов и ссылки внутри документов, а также часто имеет более глубокую интеграцию с сервисами, предназначенными для менеджмента проектов.

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

Единственным серьезным недостатком бизнес-приложений является то, что они крайне редко имеют достаточно развитый редактор таблиц уровня Excel (для работы с локальными файлами) или Google Sheets (для работы с файлами онлайн). Без табличного редактора практически невозможно ни рассчитывать баланс, ни хранить характеристики предметов. К сожалению, из-за этого недостатка часто необходимо вести работу с несколькими различными программами и сервисами одновременно.

Очень важной частью работы над документацией является создание различных схем – визуализация алгоритмов. И для этих целей могут использоваться как встроенные в текстовый редактор инструменты рисования, так и внешние. В профессиональном пакете MS Office есть программа Visio, а в комплексе Google Drive доступен сервис Diagrams.net.

Системы менеджмента довольно тесно переплетены с сервисами ведения документации. Эти системы могут значительно отличаться по возможностям и целям.

• Trello – лишь один из множества, но необычайно популярный сервис для управления проектами по методике SCRUM или KANBAN. Он позволяет работать с доской, на которой можно наблюдать за статусом тех или иных задач, находящихся в разработке. Сама система Trello позволяет делать любые доски, распределяя задачи по приоритетности, типу, исполнителю и т. п.

• К более сложным системам относятся такие сервисы, как Asana и Jira. Они позволяют провести разделение на отдельные проекты внутри одного аккаунта, а также вести более сложную структуру работы с отдельными задачами. Начиная с объединения отдельных задач в группы пользовательских историй и фичей (например, задача создания монстра, для которой требуется работа дизайнера, художника и программиста) и заканчивая созданием собственных пайплайнов внутри сервиса (мы можем настроить автоматическую передачу задачи в тестирование при ее завершении или автоматическую передачу персонажа художнику по текстурам после завершения работы над моделью). В этом случае возможности контроля и автоматизации процессов на проекте практически бесконечны. Более того, Jira имеет прямую интеграцию с сервисом Confluence, так как они являются частью одной экосистемы.

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

Вопрос движка – самый сложный из всех в индустрии цифровых развлечений. Кетчуп или майонез? Кошки или собаки? Unity 3D или Unreal Engine?

Фаворитами гонки игровых движков на сегодняшний день являются Unity 3D и Unreal Engine. Традиционно считается, что первый выбирают инди-разработчики и те, кто собирается делать игру для мобильных устройств. Второй же считается выбором художников и тех, кто собирается делать игру для PC и консолей. Хотя и на Unity 3D делают игры для PC и консолей, и Unreal Engine используют инди-разработчики.

В современном мире огромное множество движков. Некоторые из них имеют специфические ограничения. Какие-то движки изначально стоят баснословных денег, другие предназначены для создания только 2D-игр. Есть Game Maker, Godot и даже RPG Maker, предназначенный исключительно для создания классических 2D ролевых игр. Многие компании в итоге приходят к разработке собственных движков, которые потом становятся открыто доступны другим разработчикам, как Defold, созданный компанией King, прославившейся своими играми в жанре match-3. Но, конечно же, на этом движке можно делать не только match-3-игры.

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

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

Для написания кода программ так же, как и для создания документации, необходима специальная программа – среда разработки (Integrated Development Environment, IDE). Тут выбор не такой большой, как среди других сервисов, но он может серьезно повлиять на работоспособность, так как каждая среда разработки имеет особенности, свой набор подсказок, автогенерацию программного кода, набор горячих клавиш.

• Visual Studio – среда разработки от компании Microsoft, поддерживающая работу со всеми распространенными языками программирования. Существует бесплатная версия, имеющая некоторые ограничения.

• VS Code – тоже среда разработки от компании Microsoft, имеющая широкую поддержку дополнений, позволяющих работать со множеством языков программирования для множества игровых движков. VS Code бесплатный.

• Программы от компании Jet Brains имеют отдельные IDE для разных языков программирования, а также надстройки для Visual Studio. Не имеют бесплатных версий.

• Xcode – среда разработки компании Apple, которая предоставляет инструменты для создания приложений для устройств и операционных систем компании Apple. Она платная и запускается только на компьютерах с OS X.

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

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

• Табличные редакторы – это привычные нам Excel (входящий в комплект MS Office) и Google Sheets (входящий в комплект Google Drive). В основе табличных редакторов находится система формул, которая позволяет генерировать, масштабировать и распределять данные в удобном для работы виде.

• Программы – это либо разработанные специально для нашей игры алгоритмы, позволяющие проверить или создать математическую модель, либо сервисы, позволяющие создавать алгоритмы управления ресурсами: например, сервис Machinations.io.

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

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

• Среди отдельных программ можно отметить Adobe XD, Axure и Balsamiq.

• Из онлайн-сервисов можно обратить внимание на сервисы Figma и Sketch. Одним из главных преимуществ онлайн-сервисов является возможность совместной работы над макетами.

Среди инструментов для работы с двухмерной графикой есть безоговорочный лидер – компания Adobe с ее знаменитыми программами Photoshop (для растровой, пиксельной графики) и Illustrator (для векторной графики). Но существует довольно много альтернатив, в том числе бесплатных: например, Gimp. Очень популярны также Paint Tool Sai, Krita и Clip Studio Paint.

Для создания анимации в 2D с использованием методики скелетной анимации можно использовать программу Spine.

Для работы с трехмерной графикой есть инструменты универсальные и предназначенные для работы над отдельными аспектами 3D-графики.

• Универсальные инструменты – это программы компании Autodesk: Maya, 3ds Max, а также Cinema 4D, бесплатный Blender и другие. Эти программы позволяют заниматься и созданием моделей, и текстурированием, и анимированием.

• Для создания моделей и текстурирования существуют отдельные довольно популярные инструменты: Substance Painter 3D, Substance Designer, Marvelous Designer, 3D Coat, ZBrush и другие.

• Некоторые программы для работы с 3D-графикой имеют довольно глубокую интеграцию с популярными игровыми движками: например, Houdini.

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

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

Самой распространенной системой контроля версий на сегодня является Git. Можно запустить Git на собственном сервере, например в офисе, либо воспользоваться услугами других сервисов типа уже упомянутых GitHub, GitLab, Azure и BitBucket (который имеет прямую интеграцию с уже упомянутыми Confluence и Jira). Существуют и другие системы контроля версий, например Plastic SCM, который, в свою очередь, имеет прямую интеграцию с движком Unity 3D и отличается от Git тем, что позволяет работать в том числе с тяжелыми файлами графических и звуковых ассетов.

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

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

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

Самые простые варианты на сегодня – это PlayFab от Microsoft и Unity Gaming Services от Unity. Эти сервисы непосредственно предназначены для создания игр и позволяют автоматизировать множество функций типа начисления энергии или подбора противников для PvP-арены. Более сложные сервисы: Firebase от Google, Azure от Microsoft и AWS от Amazon – они дешевле в обслуживании, но требуют больше времени и навыков для разработки.

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

Самые крупные компании часто предоставляют и сервис-аналитики, и сервис-рекламы, так как аналитика помогает этим компаниям лучше работать с рекламой. Подобное сочетание есть и у Google, и у Facebook. Также собственные сервисы аналитики и рекламы есть у движка Unity 3D. Но есть множество сервисов, предоставляющих либо аналитику, либо рекламу. У всех есть преимущества и недостатки.[4]

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

Одним из главных преимуществ современных движков типа Unity 3D и Unreal Engine являются магазины ассетов к этим движкам. Там можно найти почти все что угодно: модели, анимации, звуки, готовые системы и проекты, позволяющие без написания дополнительного кода создать игру. Также хорошим источником ассетов является сервис Humble Bundle, где продающиеся ассеты обычно не привязаны к какому-либо игровому движку.

У компании Adobe есть сервис Mixamo, который можно использовать как источник анимаций.

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

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

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