Постепенно интересы разработчика отходят от непосредственного создания игр и начинают концентрироваться на достижении определенных бизнес-показателей: количестве регистраций, активных игроков, возвращаемости, среднего дохода с игрока, различных конверсиях из одной группы пользователей в другую. Чем сильнее специалист, тем сложнее его удержать или привлечь. В ход начинают идти различные привлекательные предложения разделить финансовую ответственность за разрабатываемую игру с руководством компании или инвестором. Разделение финансовой ответственности подразумевает и разделение финансовых достижений. Соответственно, меняются и цели, ведь теперь непосредственно от действий специалиста зависит его собственное финансовое благополучие, которое больше не ограничено рамками зарплаты.
Конечно, и на более низких ступенях иерархии разработчиков от действий человека зависит его благополучие. Но простому исполнителю достаточно выполнять свою работу, чтобы получать зарплату. Если он работает хорошо, то, будет ли у него работа, зависит не от него, а от того, кто принимает решения, связанные с бизнесом (в том числе решение уволить лентяя, например). А это уже собирательный образ продюсера, от решений которого зависит не только то, будет ли у него зарплата, но и будет ли она у зависящих от него людей.
Индивидуальные разработчики сразу находятся на этом уровне, независимо от имеющегося у них опыта, так как сразу несут финансовую ответственность за результаты своей работы.
Софтскиллы
Про методики работы над дизайном игры и работу с игровыми движками можно найти довольно много обучающих материалов. Но есть набор навыков, которым хорошо бы обладать, но которому при этом нельзя научиться в учебном заведении или на каком-нибудь курсе. И тут речь пойдет о софтскиллах (soft skills) – умении общаться и работать в коллективе.
Обычно это понятие связано со всем тем, что традиционно оказывается на дне резюме и кочует от одного соискателя к другому без особых изменений: коммуникабельность, стрессоустойчивость, упорство. Это, конечно, важно, но далеко от тех вроде как второстепенных навыков, которые необходимы разработчику и дизайнеру игр. Не говоря уже о том, что коммуникабельность – навык социальный, он просто необходим, если разработкой игры занимается целая команда, а умение четко выражать свои мысли – это навык еще более универсальный. Он пригодится не только для того, чтобы объяснить что-то другому участнику разработки, но и для того, чтобы потом не ломать голову над собственноручно написанной документацией.
Разработка игры, как и любого другого продукта, – это процесс придания физической формы некой задумке. Наша игра получается из арта, программного кода, настроек предметов и персонажей. Но прежде чем мы все это получим, нам надо как-то объяснить исполнителям, что именно мы хотим получить. Помочь объясниться должна документация, но она не бывает идеальной, поэтому-то она может только помочь, а не решить все проблемы. В результате и к дизайнеру игры, и к документации предъявляется ряд требований.
Документация должна быть четкой, дизайнеру хорошо бы знать, что именно он хочет видеть и как это должно работать. Разработка игры – процесс довольно длительный, и даже если мы будем работать над игрой в одиночку, документация поможет нам не забыть, что и для чего мы делаем и как мы видели это изначально. Основа документации может быть написана буквально за несколько дней или даже часов и в дальнейшем будет только обрастать деталями, необходимыми команде для четкого понимания задач. Но степень необходимой проработанности документации также зависит от команды, ее знаний и опыта. В хорошо слаженной команде дизайнер не будет тратить на документацию больше времени, чем необходимо, но эту грань необходимого надо сначала выработать. В процессе разработки в изначальной идее что-то может измениться, и эти изменения должны быть задокументированы, чтобы не путаться самому и не путать других членов команды. Документация не должна допускать разночтений и вариантов толкований.
Так как над игрой может работать много разноплановых специалистов, у них будут не только разные задачи, но и в целом разные цели. Разные вещи будут для них главными. Для программистов важно описание алгоритма поведения персонажа, для художников – описание его внешнего вида, для сценаристов – описание характера. Если мы сложим все эти описания в одну кучу, две трети информации для каждого из специалистов будут лишними. Поэтому описания должны быть разделены. Как? Есть много вариантов, каждый из которых имеет право на жизнь в зависимости от устройства команды. Тут-то и должны пригодиться коммуникационные навыки, чтобы узнать, какой именно метод структурирования данных будет наиболее комфортен для всех.