Лого vc.ru

Как построить процесс разработки игры и оценить требуемые ресурсы

Как построить процесс разработки игры и оценить требуемые ресурсы

Роман Поволоцкий, партнер компании 2RealLife, принимавший участие в разработке таких проектов, как «Небеса», «Техномагия», «Легенда Драконов» и «Территория», рассказал ЦП о том, что такое продюсерский и производственный планы, как они помогают выстроить эффективный рабочий процесс и достичь взаимопонимания в команде.

Поделиться

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

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

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

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

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

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

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

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

Отдельное внимание надо уделить игровому дизайну, который должен следовать за бизнес-показателями проектов, в первую очередь за ARPPU и Retention. Не важно, какими аргументами пользуется руководитель проекта, продюсер или игровой дизайнер, не забывайте и не стесняйтесь задавать ему вопрос: как это улучшит бизнес-показатели проекта?

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

Общая схема производственного процесса

Дано: паспорт проекта

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

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

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

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

Есть немало споров о том, как угадать целевую аудиторию, но существуют определенные жанровые предпосылки для того, чтобы понять это, ведь если игра относится жанру экшен, то и аудитория будет состоять из мужчин до 30 лет, а если match-3, то, скорее всего, в неё будут играть женщины.

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

3. Формирование профилей пользователей также является важной задачей. Игроки не сразу осваивают игровой процесс, какая-то функциональность доступна им сразу после регистрации, а другая — спустя десятки часов игры. Нельзя же сразу давать игроку доступ во все игровые активности, потеряется ценность игрового прогресса!

Маркетологи должны понимать все нюансы прохождения, ведь то, чем игра встречает, не должно диссонировать с содержанием. Я часто встречал проблему красивых баннеров или лендингов, которые ведут на морально устаревший интерфейс браузерной игры. Пользователи «клюют» на красивые картинки, регистрируются, а затем, естественно, разочаровываются и уходят. На выходе — опять теряем деньги.

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

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

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

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

Дано: концепция

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

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

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

3. Существует определенная зависимость популярности проекта от сложности концепции. Чем сложнее описание, тем сложнее передать смысл игры до конечному потребителю. Возьмите любую популярную игру, и вы сможете объяснить её смысл в одном предложении.

Пример: Angry Birds — расстрел различными птицами с индивидуальными особенностями разнообразных укреплений из разных материалов, в которых прячутся злобные поросята, укравшие яйца у птиц.

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

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

Пример: карта игровой активности

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

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

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

5. Графические референсы являются крайне важным аспектом. Очень просто показать художнику изображение и сказать: «хочу не хуже». Перед началом проекта очень важно договорить о внешнем виде. Подойдет всё, что есть у лидеров сегмента, начиная от структуры интерфейса и заканчивая изображениями героев.

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

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

Дано: продюсерский план

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

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

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

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

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

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

В моей системе ценностей есть несколько конкретных назначений для разработки функциональности:

  • реализация базовой игровой активности;
  • улучшение параметров монетизации;
  • улучшение параметров возврата пользователей Retention;
  • увеличение аддиктивности и количества сессий (Sticky factor);
  • формирование стратегической цели для игрока;
  • улучшение параметров социализации (например, ввод нового боевого класса персонажа);
  • улучшение качества сервиса (например, уменьшение времени загрузки или размера клиента);
  • оптимизация производства (например, добавление CMS для заведения контента геймдизайнерами, а не программистами).

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

Решение: производственный план

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

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

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

Сотрудники понимают, что им предстоит делать, руководитель разработки получил приоритеты — теперь можно разбить проект на задачи и оценить объем с разработчиками.

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

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

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

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

Статьи по теме
Как рассчитать стоимость своего проекта для инвесторов – Дмитрий Калаев, ФРИИ19 ноября 2014, 10:53
Как оценить стоимость стартапа. Тайный мир бизнес-ангелов29 апреля 2014, 09:45
Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

Вот это я понимаю подход к делу. Жду в комментариях противников проектной документации и бизнес-ориентированности игровой индустрии.

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

Слушал этот доклад живьем на gds в минске.
Рынок игр остался единственной рубрикой, ради которой регулярно захожу на ЦП. Лайк)

Growth Hacks еще есть, отличная рубрика.

И еще новая потенциальная рубрика - "Срачи про такси", тоже оч интересная.

Надо поместить "Срачи про такси" в "Growth Hacks" и бесконечная рекурсия аннигилирует смм, сео и рекламные бюджеты стартапов.

Спасибо, крайне полезный материал.

Вопрос к Роману - к примеру, на данный момент iPhone 4s поддерживается, т.е. это вероятно требует оптимизации кода, арта, для достижения к примеру того же фпс приемлемого. Предположим через 3 месяца Эппл заявит что 4s не будет поддежриваться новой ios. Те ресурсы, и денежные вливания, которые были затрачены на разработку под 4s будут просто списаны?

0

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

Т.е. разработку нового проект нет смысла затачивать, под old style device, если ресурсы, требуемые на поддержания "умирающего" устройства не будут потенциально окупаться той аудиторией которая имеется в наличии на этом уст-во на данный момент?

0

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

А как быть с пользователями кто играл(и, возможно, платил) на устройстве которое перестало поддерживаться?

0

Прекрасная статья, спасибо автору и Цукеру за "Рынок Игр". Крайне полезная и вдохновляющая рубрика. Недавно начали делать игровой проект, учимся на своих ошибках, но стараемся перенять опыт матерых волков индустрии :) Скоро пришлем прототип на линч, не бейте сильно. А вообще, было бы очень интересно посмотреть на примеры документации реальных проектов, чтобы не изобретать велосипеды.

за статью Роман сам примет вашу благодарность, а от имени "Рынка Игр" - спасибо за оценку, примерно для этого ее и развиваем)

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

Цитата: "...описание всех ключевых объектов". Вот это вот все портит.

Автор как бы говорит нам: "Сначала мы спланируем всю игру на бумажке, а потом будем делать".
Получаем классический waterfall.
А как же итерации? Как же аджайл?
Хотя я не настоящий сварщик, может так и надо.

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

Agile это как ты работаешь над планом и собственно не отменяет важность его наличия

0

Роман, спасибо за отличную статью!

Есть несколько вопросов.

Почему учитываются именно ARPPU и Retention? Считаешь, что остальные параметры(например, конверсия) не так важны?

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

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

Спасибо!

0

Спасибо за статью Роман! поделитесь документацией - или шаблонами(рыбой). Огромное спасибо еще раз!

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

1. Важнейшим фактором является средний чек и, как следствие, рентабельность рекламы. Если вы покупаете пользователя по $5, очевидно, что ARPU должен быть выше, иначе реклама не приносит прибыль. Существуют методы удешевления траффика типа фичеринга, но в случае с проектом, именно Retention позволяет определить длительность потребления сервиса. Если у вас низкий показатель Retention, вам будет сложнее отбивать по деньгам проект. Все остальные показатели менее важны.
2. В рамках бюджета закладываются 30% риски, в которые должны уложиться все дефекты и доработки. Все остальное можно перекладывать на следующий производственный этап, включая серьезные доработки или добавление нового функционала. Если уж сильно хочется, можно заменить функционал из производственного плана на новый, но это крайне драматичная ситуация, приводящая к переоценке и возникновению препродакшена в производственном процессе, отрыв сотрудников от производства негативно влияет на качество сроков.
3. Краткосрочная: достигнуть определенного уровня развития, выполнить Х достижений, построить ратушу У уровня, пройти N глав карты мира.
Среднесрочные: вступить в клан, построить все здания, пройти все каесты, попасть в рейтинг чемпионов, победить в турнире.
Долгосрочные: победить в клановой войне, пройти все главы карты мира, стать лидером рейтинга, открыть все достижения.

Спасибо, видимо в статье опечатка и имелось ввиду ARPU и Retention.

0

Большое спасибо. Сам не так давно начал свою игру. Отдельное спасибо отделу "рынок игр" за советы.

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

Сейчас обсуждают
Максим Федоров

SEO творит дела ;)

Стеллаж «Сын съедает всю еду»: IKEA превратила поисковые запросы о проблемах в семье в названия товаров
0
Владимир Ростопчин

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

«Добро пожаловать в 2030 год»: член датского парламента о счастливой жизни без приватности и личных вещей
0
Андрей Суханов

Не только крупный бизнес двигается по "трендовым" мемам, но и мелочь за ними поспевает)
sweetbags.ru/news/vzhuh-jeto-kakaja-to-sumochnaja-magija

«Вжух»: реакция российских компаний на мем с котом и волшебной палочкой
0
Valentin Dombrovsky
Travelabs

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

«Вжух»: реакция российских компаний на мем с котом и волшебной палочкой
0
Показать еще