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

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

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

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

* * *

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

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

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

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

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

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

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

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

* * *

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

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

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

Софтскиллы

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

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

УМЕНИЕ ЧЕТКО ИЗЛАГАТЬ СВОИ МЫСЛИ

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

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