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

Страница 2 из 2

Испытание


Начало


После заморозки проекта 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]
 
  стр. 2 из 2  

Copyright © 2017 ООО "ДТФ.РУ". Все права защищены.

Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

Замечания и предложения отправляйте через форму обратной связи.

Пользовательское соглашение