DTF.RU - Статьи [http://dailytelefrag.ru/articles/]

Как выжить малыми силами

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

http://dailytelefrag.ru/articles/read.php?id=76555


Об авторе


Азаров Сергей — в игровой индустрии с 2003 года, работал в компаниях Destiny Games и Step Creative Group, с 2006 года являюсь сотрудником «Нового Диска». В настоящее время занимаю позицию team leader'а, программиста Unity3D, ведущего гейм-дизайнера и технического аналитика.

Введение


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

Для помнящих, что такое Unity3D версии 2.1+, пояснять не надо с чем мы столкнулись, особенно если учесть, что все элементы игры мы писали без использования сторонних плагинов, включая GUI. В таких вот условиях мы подошли к середине лета 2009 года, кризис и падение экономики были в самом разгаре, наша разработка тормозилась, эффективность была хуже некуда, а сроки выпуска проекта приближались и грозили накрыть нас с головой. Закрывать на это глаза было уже невозможно, надо было что-то менять и менять радикально и кардинально.

Революция


Предпосылки изменений в системе трудовых взаимоотношений были заложены еще во времена работы в Step Creative Group, когда системный программист иногда отпрашивался работать дома с целью быстрее закончить особо важный элемент кода, что, соответственно приносило положительный результат. Однако, это было скорее исключением, чем системной закономерностью и было связано с жесткими дедлайнами в условиях ограниченного бюджета. В «Новом Диске» условия были комфортнее, а сроки разработки демократичнее и без овертаймов. Однако 2009 год все изменил. И то, что бродило в умах на подсознательном уровне, переросло в конкретные революционные веяния. Боевых действий конечно не велось, но определенные требования был выдвинуты. Команда программистов из трех человек, чтобы успеть все сделать по проекту, предложила переход на удаленную форму работы, в противном случае она не гарантировала соблюдения сроков и качества результата, даже с учетом овертаймов, и как итог, возможно, даже будет вынуждена покинуть компанию. К чести нашего тогдашнего руководителя он был прогрессивных взглядов и сдался без сопротивления, однако, чтобы успокоить умы других, мы были вынуждены согласиться на одно условие - оплата труда должна быть сдельной (по факту выполненных задач). Оглядываясь назад, можно смело сказать - это было мудрое решение, которое позволило как оценить перспективы для руководства, так и переломить офисный образ мышления у сотрудников.

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

Итогом нашей революции стало увеличение реальной производительности почти в 2 раза. В среднем без каких либо особых моральных и физических потрясений каждый программист работал по 7-9 часов чистого времени, что ввиду сдельной оплаты выросло в увеличение зарплаты на 10-15%. Вдобавок к этому мы смогли закончить помимо основного проекта (Ранетки. Game Live) еще два оутсорс проекта. К сожалению, из-за конфликта ведущего программиста и ведущего художника, первый уволился, несмотря на то, что инициатором революции был именно он. Свою роль, конечно, сыграли и не отлаженные процессы контентного конвейера, которые, как мне кажется, позволили возникнуть конфликту. В результате роль ведущего пришлось брать на себя. Все задачи по программированию были перераспределены на двух человек. Через полгода работы, когда все проекты были сданы, а новые задачи еще не были утверждены руководство предложило нам окладный вариант оплаты труда с сохранением работы из дома. Так завершился первый шаг на нашем пути к созданию распределенной команды, эффективность которой, только зарождалась.

Становление


Несмотря на тот факт, что проект «Ранетки. Game Live» в целом, вопреки скептическому настрою к нему со стороны команды, окупился и даже принес прибыль, кардинально наше положение это не поменяло, потому что четкого видения куда двигаться не было. Однако, задатки все же стали проявляться, особенно с появлением в Unity поддержки Android и iOS. Направление мобильных (или мультиплатформенных) игр выглядело достаточно перспективно, тем не менее, оно не находило отклика у руководства, к тому же в разработке у нас был социальный проект для сетей FB, VK и т.п., который через длительное время разработки был закрыт из-за разногласий с правообладателем. Данное событие и факт неопределенности начал давить морально на людей в офисе, команда стала сокращаться в размерах и потери в контентном отделе стали влиять на скорость разработки, программисты значительно опережали появление графических материалов (художники работали в офисе), начались простои.

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

В качестве первого проекта было предложено несколько вариантов концептов, как с механиками, еще не представленными в AppStore и Google Play, так и более предсказуемыми в плане аудитории и перспектив. Руководством был выбран вариант аркадного файтинга, который мы назвали Cyber Fist.

Picture_1.jpg

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

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

Picture_2.jpg

Что это нам дало:
  • в плане взаимодействия все более или менее понятно, альтернативу Skype найти сложновато, касательно премиум-аккаунта, то он необходим для проведения обучающих тренингов по новым технологиям, инструментарию и т.п. с возможностью трансляции экрана нескольким пользователям, которые, в свою очередь, могут сделать видеозапись этого процесса.
  • Использование Redmine это вопрос соотношения возможностей и цены - он бесплатный и при этом достаточно удобен и прост в освоении. Однако, нам пришлось потрудиться, чтобы приучить людей правильно им пользоваться, выработать, что называется, рефлексы.
  • Unity3D как среда разработки это вопрос удобства с позиции написания кода, все-таки C# проще, нежели С++ (по крайней мере для нашей команды), к тому же к этому времени движок оброс огромным количеством сторонних плагинов, которые сильно облегчали жизнь, чем мы незамедлительно воспользовались.
  • Что касается системы контроля версий, то здесь вопрос предпочтений и привычек команды. Использовать можно что угодно. Мы работали и с SVN и пробовали UAS и GIT, разницы нет для маленькой команды. Главное, чтобы система контроля версий умела рассылать уведомления о действиях, совершенных в репозитарии.
Все вышеописанное это логическое развитие, которое в целом не было для нас чем-то неожиданным, введение этих элементов упростило жизнь, но прирост производительности все же был недостаточным. Наибольший результат нам дало изменение режима работы и смена методологии разработки.

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

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

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

В итоге, все вышеописанные действия, позволили нам достаточно быстро (для команды из семи человек) получить первую игровую демо-версию проекта (напомню, это был Cyber Fist). Однако, усилиями вышестоящего руководства, проект, задумываемый как аркадный файтинг с F2P бизнес-моделью, превратился в ММО проект с кланами, командными сетевыми боями и клиентами под Web, PC и две мобильные платформы (Android, iOS). Такие объемы маленькая команда уже не могла потянуть, а расширяться нам не давали, в итоге проект остановили.

Picture_3.jpg

Несмотря на то, что нам не дали довести проект до конца, работа над ним позволила вскрыть еще ряд проблем в организации нашего pipeline'а, а также осмыслить и выработать стратегию по их преодолению. Кульминацией этого стал следующий набор изменений и условий, которые мы посчитали и считаем необходимыми для эффективного функционирования распределенной команды:
  • Инструментарий разработки было решено перевести на систему All-in-One. Все операции с контентом, настройками проекта, созданием билдов, написанием игровой логики, балансировки и т.п. должны были делаться в одном месте, причем в максимально простом и удобном виде, исключающим монотонную рутину. Извне создавались только исходные материалы, текстуры, модели, звуки, видео.
  • Необходимо стимулировать профессиональный рост сотрудников, особенно, если они сами желают развиваться в определенной области. А чтобы этот рост не пропадал впустую нужно ставить перед людьми сложные цели, к которым они будут стремиться и закреплять полученные знания.
  • Доверие членам команды есть критичный аспект эффективности команды. Естественно, здесь имеется ввиду доверие к человеку, как к профессионалу. Каждый в зоне своей ответственности должен отвечать своим профессионализмом. Из доверия рождается уверенность, что поставленная задача будет выполнена наилучшим образом без перманентного контроля со стороны team leader'a.
  • В свете вышесказанного проистекает основа основ в любой маленькой команде - важны люди, а не процессы, инструментарий, или что-то другое. Люди есть основа успешности, а профессионалы своего дела, ценны несоизмеримо. Именно поэтому их должны ценить, а они должны знать, что их ценят, это стимулирует их на дальнейшие развитие. Правило все заменимы — не работает в условиях небольших команд.
  • Насколько бы не было сильно доверие сотрудникам в профессиональном плане, если не бросать вызов их способностям, они деградируют. Нужно стараться ставить людей в такие условия, чтобы их способности максимально раскрывались. Эффект от преодоления подобных препятствий огромный - резкий скачок производительности, и повышение удовольствия от процесса работы.
  • Нужно избавляться от рутины (цикличные повторяемые действия), либо сделать так, чтобы она занимала минимум времени, либо работа такого характера была максимально облегчена за счет инструментария. Конечно, полностью исключить такие процессы нельзя, особенно когда приходится разрабатывать серию однотипных продуктов, однако, неприятный эффект можно и нужно сгладить. Уменьшение рутины дает команде возможность поднять качество за счет высвобожденного времени.
  • Необходимо уменьшить коммуникации в промежутках между итерациями. Собственно отсюда и вытекает условие доверия сотрудникам как профессионалам. Вмешательство в процесс работы исполнителя до того, как он представит результаты итерации, должно быть минимальным. Если этого не получается и приходится часто обсуждать промежуточные результаты, это значит, что назрела системная проблема. Нужно дать людям работать. Профессионал в зоне своей ответственности сам поймет что плохо, а что хорошо, что изменить, а что оставить.
  • Нужно минимизировать или вовсе избавиться от ситуаций изменения условий задачи в процессе работ над итерацией. Любые изменения должны происходить либо до ее начала, либо по ее завершению. Люди негативно реагируют, когда посреди работы им говорят, что теперь у задачи другие требования, и все что было сделано ранее, не подходит. В этом свете прототипирование и грамотный pre-production занимают ключевую роль в разработке.
  • Исправление ошибок на этапе тестирования необходимо осуществлять порциями. Ввиду мультизадачности каждого из членов команды, если выплеснуть на них весь список багов сразу, можно прийти к ситуации переполнения буфера входящих задач, от которого изначально мы избавились введением итеративной разработки.
В определенной степени вышеописанное некоторым читателям может показаться повторением известных истин. Однако, все же лучше иметь возможность практического подтверждения, что это работает. Наша команда пришла к этому через тернии и определенное, в целом немалое, время. И мы твердо можем сказать, что да, это работает и работает эффективно. Доказательством этого стал наш следующий проект, который поставил нас в достаточно жесткие условия и потребовал от нас аккумуляции всех ресурсов, в том числе скрытых.

Испытание


Начало


После заморозки проекта Cyber Fist, руководством было решено разрабатывать более простые игры. Как один из вариантов был предложен переход в сегмент детских проектов. После серии экспериментов с различными направлениями мобильных приложений в этой области, нам было решено отдать проект по «Машиным Сказкам». Однако, чтобы разработка была экономически выгодна (ввиду особенностей этого бренда), нам было поставлено одно условие: необходимо разрабатывать по 3 приложения в месяц, каждое из которых - это мультиплатформенная (PC, iOS) детская игра на основе одной серии мультсериала. Одна такая игра содержала в себе 12 мини-игр разного жанра, обыгрывающих ключевые моменты сюжета мультфильма.

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

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

Проблемы и решения


Как было сказано выше, в ходе подготовки в производству был выявлен ряд проблем, которые было необходимо срочно решать. В большей части все они касались разработки контента:
  • Поскольку игры были в 2D варианте, анимация для них должна была быть соответствующей. Реализация которых через кадровые секвенции оказалась совершенно неприемлемой из-за скорости разработки, использовать скелетную анимацию через 3Ds Max, тоже было неудобно. Аниматор катастрофически отставал от разработчиков графики для уровней, положение усугублялось из-за необходимости создавать много разных анимационных сцен для сюжета. Изначальный вариант использования Animation Timeline в Unity3D провалился из-за неудобства инструментария.
  • Ввиду того, что игры создавались на основе мультфильмов, то для разработки уровней были необходимы графические материалы от правообладателей. Из-за особенностей такого взаимодействия материалы поступали с сильным опозданием, да и то порой не в нужном объеме.
  • Использование классического цикла для разработки контента, когда сначала формируется эскизное представление уровней, сильно увеличивало конечное время его появления у программистов.
  • При полноценной разработке дизайн-документа, задачи художникам приходили недостаточно быстро, что также увеличивало время разработки.
Ранее мы сказали, что входным условием было производство трех игр в календарный месяц. Это означало, что в среднем на одну игру должно тратиться семь рабочих дней. В эту цифру мы и должны были уложиться, для чего пришлось:
  • Провести обширный поиск инструментария для анимирования 2D объектов через скелет, а затем обучить команду с ним работать. К счастью, таковой был найден, причем еще и в виде расширения для Unity3D. SmoothMoves оказался весьма удобным и простым в освоении, не без проблем конечно, но, тем не менее, его внедрение позволило ускорить анимационные работы в 3 раза.
  • Упростить документацию по игровому дизайну до минимально необходимого, так чтобы задачи художникам по разработке графики выставлялись как можно раньше. Работы по дизайну следующей игры начинались в конце работ предыдущей (за 3 дня). Целью этого было обеспечение безостановочной работы конвейера.
  • Отказаться от разработки эскизов
  • Запрос материалов от правообладателя производить за месяц до разработки игры. В случае, если материалов было недостаточно или их формат не подходил, дабы не производить повторный запрос, необходимые ресурсы забирались напрямую из Full HD версий мультфильмов.
  • Тестирование осуществлять за время, пока готовились материалы к первому уровню следующей игры (графика уровней и необходимые анимации).
  • Озвучивание осуществлять параллельно разработки игрового процесса.
  • С позиции программирования нужно разрабатывать по 2 игровых уровня в день. Ввиду того, что инструментарий необходимо было поддерживать и развивать, эти задачи делились в разном соотношении между двух программистов.
Для того, чтобы обеспечить последний пункт, нами был разработан специальный фреймворк, который позволял создавать игровою логику без непосредственного написания кода. Что из себя представляет данный инструментарий читайте далее.

Программный фреймворк


Идея создания среды, которая позволяла бы разрабатывать часть или всю логику без использования непосредственного написания кода, родилась у нас в процессе работ над проектом «Cyber Fist». Окончательно она сформировалась к началу работ над «Машиными Сказками».

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

Picture_4.jpg

Здесь:
  • Object Constructor – визуальная среда, позволяющая оперировать компонентами и экшенами и создавать из них логические цепочки.
  • Game Design Parameter – инструмент, позволяющий оперировать данными игровой логики вне инспектора Unity, эти данные помечались в коде, через специальные атрибуты. Фактически это позволяет разделить данные для функционирования игровой логики и данные, влияющие на баланс игрового процесса.
  • Sound Manager – инструмент для настройки звуков, используемых в игровых уровнях, которые потом использовались в Object Constructor через идентификаторы.
  • API – программный интерфейс, позволяющий создавать собственные компоненты и экшены, расширяя тем самым функционал Object Constructor. Сюда же включена система обмена сообщениями между компонентами игры, которая основана на типах данных. Подписка на события осуществлялась через атрибуты.
  • Component – программный элемент, реализующий ту или иную логику и предоставляющий интерфейс доступа к точкам событий (EventPoint). Например нужно передвинуть персонажа из точки А в точку Б. В ходе работы такой логики возникает ряд событий: персонажа разместили в точке А, пользователь нажал на кнопку, персонаж начал движение, персонаж достиг точки Б. В каждом из таких событий игрой могут быть совершены определенные действия, например, при начале движения нужно проиграть анимацию ходьбы и т.п.
  • Action - программный элемент реализующий действие, совершаемое над объектом логики. Action непосредственно привязывается к EventPoint'у, описываемому в компоненте и также сам может быть источником этих событий. Например, действие — проиграть анимацию, имеет точку события — анимация завершена.
Ниже представлены внешний вид фреймворка.

Picture_5.jpg

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

Итоги


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

В дальнейшем использование нашего уже настроенного и испытанного pipeline'a позволило нам реализовать в установленные сроки еще один проект — серия из трех игр по мультфильму «Белка и Стрелка. Лунные приключения». Несмотря на то, что качество проекта пострадало в виду малых сроков, с позиции поставленных условий он был выполнен вовремя. Каждая игра, состоявшая из пяти мини-игр, была реализована за три недели, включая игровой дизайн.

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

Будущее


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

Кстати, после завершения работ над «Машиными Сказками» мы полностью обновили наш фреймворк в сторону более мощной системы визуального программирования, добавили в него поддержку IAP, систему настраиваемой сборки приложения с использованием AssetBundle, перешли с ex2D на Unity Sprite, в качестве среды GUI добавили поддержку nGUI. Теперь наша система выглядит более «взрослой». В некотором смысле мы невольно повторяем то, что в Unreal Engine 4 называется BluePrint. Все это позволяет нам делать более сложные проекты, чем мы сейчас и занимаемся. Инструментарий теперь выглядит вот так.

Picture_6.jpg

Заключение


В заключении статьи хотелось бы подвести черту и сформировать общий список преимуществ описанного выше производственного процесса и в целом удаленной формы взаимодействия самой по себе. Что же дает переход к ней:
  • По производительности труда
    • Повышение до 2 раз
    • Близкую к 100% выработку 8-часового рабочего дня
  • По экономической составляющей
    • Снижение операционных расходов: электричество, вода, питание, офис, оборудование офисного места, интернет.
    • Для сотрудников из Москвы и области можно платить меньше в среднем на 10 тысяч рублей в месяц, которые они бы тратили на проезд, питание и т.п.
    • Сокращение фактического срока пребывания на больничном
    • Специалисты вне московской области стоят гораздо меньше, по части позиций можно значительно снизить ФОТ
    • Меньшие проблемы с поиском специалистов. Из-за низкой мобильности людей в России, выгоднее найти удаленного сотрудника из другого города, чем найти человека, готового переехать в офис.
  • Для сотрудников
    • Отсутствие контроля «за спиной»
    • График работы, соответствующий биоритмам
    • Больше времени для общения с семьей
    • Возможность уделять время развитию профессиональных навыков.
    • Улучшение морально-психологического состояния
Напоследок наша команда хотел бы пожелать всем побороть свой страх и предрассудки перед удаленной работой. Да, она несет в себе определенные риски, но тенденции развития игровой индустрии, так или иначе, приведут в скором времени к поиску способов сокращения издержек и повышения эффективности и описанный выше механизм позволяет это сделать.
[21.08.2014]

Copyright © 1999-2017 DTF Ltd. Все права защищены.
Замечания и предложения отправляйте по адресу team@dtf.ru