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

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

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

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

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

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

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

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

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

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

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

Какие компании делают игры

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

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

Получается, что есть два варианта: работать на себя или на какую-то компанию.

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

У самостоятельной работы есть три пути:

• создание игры в свободное от основной работы или учебы время;

• создание игры в одиночку или в микрокоманде;

• создание собственной компании.

Каждый из этих вариантов имеет свои плюсы и минусы, а также некоторый набор необходимых условий.

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

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

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

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

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

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

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

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

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

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

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

• компании, работающие на прибыль;

• компании, работающие на рост;

• компании, работающие на освоение.

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

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

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

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

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

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

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

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

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

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

Продюсирование

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

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

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

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

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

И самое главное, любому начинанию, проекту, игре необходим даже не лидер, а человек, несущий ответственность принятия решений. Тот, за кем будет последнее слово во всех возможных спорах, как творческих, так и касающихся бизнеса. Без такого человека проект будет воплощать собой басню «Лебедь, Рак и Щука» с самыми печальными для него и участников последствиями.

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

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

Итак, перед продюсером стоят три задачи:

• найти проект;

• найти команду;

• найти финансирование.

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

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

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

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

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

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

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

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

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

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

Гейм-дизайн

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

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

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

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

Гейм-дизайнер отвечает за правила игры и ее содержание.

Список задач, которыми занимаются гейм-дизайнеры, довольно широк.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• визуальный дизайн;

• скриптование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

АРТ

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

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

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

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

Возьмем, например, работу 3D-моделлера. Создание 3D-модели подразделяется на несколько этапов.

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

• Создание модели – это, собственно, сама работа над задачей, обычно она проходит в 3D-редакторе или даже в нескольких в зависимости от сложности. На этом этапе важно точное воспроизведение референса или скетча.

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

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

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

– создание текстуры – этот процесс чем-то похож на раскрашивание фигурки или статуи;

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

– создание материала шейдера – это процесс по настройке материала объекта.

• Риггинг (rigging, rig – подстройка) – это подготовка объекта или персонажа к анимации. Обычно для модели создается «скелет», и настраивается влияние его «костей» на ту или иную часть модели, чтобы анимация в итоге выглядела естественно и реалистично.

• Анимация – это создание движения объекта или персонажа после того, как риг готов.

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

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

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

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

• 2D-художники рисуют иконки, изображения персонажей, объектов и фонов, если игра двухмерная.

• 3D-моделлеры (скульпторы) делают трехмерные модели персонажей и объектов, если игра трехмерная. Также они могут заниматься созданием модели игрового уровня по собранным левел-дизайнерами макетам.

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

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

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

– Покадровая анимация, как в классической мультипликации.

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

– Кукольная анимация, в которой используются фигурки персонажей, например из пластика или пластилина.

– Ротоскопия, когда аниматор обрисовывает снятых на видео персонажей.

– Анимация на костях, в которой для анимирования персонажа используется скелет.

– И наконец, для анимирования персонажей можно использовать технологию захвата движения – motion capture.

• GUI-художники (graphical user interface – «графический пользовательский интерфейс») – это узкопрофильные художники, которые умеют делать красивые и понятные интерфейсы: обрисовывать то, что спроектировали специалисты по игровому UI/UX. Также художники по интерфейсам должны знать технические особенности реализации интерфейсов в игре: как интерфейсы вставляются в игру, на чем можно сэкономить ресурсы и так далее.

• Технические и FX-художники (FX, effects – эффекты) – художники по спецэффектам, шейдерам и постпроцессингу.

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

– Шейдеры – различные эффекты, связанные с материалами: то, как различные материалы отражают, рассеивают и преломляют свет.

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

• Технические помощники выполняют нехудожественные работы, связанные с работой художников, например выгрузкой 3D-моделей, созданием палитр двухмерных объектов или сборкой интерфейсов. Слово «помощник» не означает, что работа низкоквалифицированная. На самом деле она тоже требует значительного опыта и глубоких технических знаний.

Программирование

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

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

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

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

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

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

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

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

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

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

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

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

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

• Специалист по клиенту занимается реализацией игровой логики и визуализации игрового процесса на стороне запускаемой у игрока программы.

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

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

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

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

Контроль качества

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

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

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

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

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

Менеджмент

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

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

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

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

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

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

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

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

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

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

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

Маркетинг и продуктовая аналитика

Работа над игрой как над продуктом состоит не только из собственно разработки этого продукта, но и из его продажи. Продажа продукта – это целый комплекс мероприятий, о котором мы поговорим отдельно. Объединяет этот комплекс слово «маркетинг». И да, маркетингом должен кто-то заниматься.

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

Работа с комьюнити и служба поддержки

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

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

Однако в большинстве случаев комьюнити-менеджеру нужно сформировать само сообщество с нуля. Для этого нужно обладать навыками медиаменеджмента (SMM – Social Media Manager), хорошими коммуникативными навыками и, самое главное, – знанием аудитории и контента.

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

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

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

Бухгалтерия и юриспруденция

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

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

Ступеньки карьеры разработчиков игр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Софтскиллы

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

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

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

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

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

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

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

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

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

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

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

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

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

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