Ошибки молодых разработчиков: колонка основателя Another Life

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

CEO Another Life Сергей Рукосуев в своей колонке для DTF рассказал о том, как разрабатывается Mentors, первая игра студии.

Ошибки молодых разработчиков: колонка основателя Another Life

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

Моя история в «окологеймдеве» началась в конце 2008 года с создания портала по игре «Аллоды Онлайн». Мы быстро набрали аудиторию, получили статус ведущего ресурса по посещаемости и узнали азы CM, PR и SMM.

Благодаря этому порталу я заочно познакомился Александром Мамзуренко (на тот момент — комьюнити-менеджером Nival) и устроился на работу в эту компанию. Последние два года я трудился в Pixonic на позиции руководителя отдела поддержки игроков и, впоследствии, — директора по комьюнити менеджменту и видеопродакшену (Head of CM & VP).

Ошибки молодых разработчиков: колонка основателя Another Life

О важности пре-продакшна и исследования рынка

Разработка Mentors началась в 2014 году командой из двух человек: программистом (архитектура, клиент, сервер, администрирование), незнакомым до того момента с Unity, и мною, комьюнити-менеджером с экспертизой в публичных отношениях, который взвалил на себя все остальные вопросы.

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

Идея нашлась достаточно быстро:

— Нам всегда нравился жанр Turn-based PvE RPG (пошаговые ролевые игры); *

— Мобильный рынок три года назад только начинал масштабироваться и в перспективе ближайших лет должен был показывать значительный рост;

— Free-to-play RPG (бесплатные ролевые игры со встроенным магазином) имеют огромный кусок пирога на этом рынке; **

— 3D-графика звучит круче, чем 2D. ***

На том и остановились. Пре-продакшн игры (базовая документация, концепт-документ) и параллельное изучение Unity получили зелёный свет. ****

При выборе вариантов опирайтесь на слабые и сильные стороны команды.

Ошибки молодых разработчиков: колонка основателя Another Life

Неверные решения:

* PvE RPG (ролевые игры, где игрок сражается против компьютерных оппонентов) требуют огромного количества контента. В костяке нашей команды не было ни 2D/3D-художников, ни аниматоров, ни VFX-специалиста (частицы, визуальные эффекты) и тем более универсалов.

** Чтобы претендовать на достаточные объёмы, нужно отлично изучить продукцию конкурентов, в особенности в Азии. Разработка европейского продукта с рядом важных решений «под Азию» повысит шансы на продажи (заработок) в этом регионе.

*** Производство 3D-контента обходится значительно дороже по ресурсам и требует больше времени, чем 2D, особенно для мобильных устройств (из-за железа). К тому же, это накладывает дополнительную работу по оптимизации.

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

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

Что такое MVP и почему это желательно знать

MVP (от англ. minimum viable product — минимально жизнеспособный продукт) — простейший работающий прототип продукта, которым тестируют спрос до полномасштабной разработки. Такой подход страхует предпринимателя от невостребованности конечного продукта и потери потраченных на разработку ресурсов.

Wikipedia

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

Ошибки молодых разработчиков: колонка основателя Another Life

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

В тот момент казалось, что документировать подобные моменты необязательно, параллельно приходилось решать другие проблемы. Также не было понятно, как правильно строить рабочие отношения с 2D- и 3D-художниками.

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

Ошибки молодых разработчиков: колонка основателя Another Life

Сейчас у нас есть:

— 400 высококачественных иконок для всех предметов вплоть до «середины» игры;

— 50 концептов противников;

— 30 моделей противников для пяти первых локаций;

— шесть различных локаций на модульной основе;

— трижды переработанная система умений для персонажей;

— трижды переделанный интерфейс;

— рабочий пайплайн по всему циклу разработки 3D-персонажей и игровых уровней;

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

Неверное решение:

Не стоит создавать «сталкера своей мечты» с 5 000 предметами, 250 рецептами крафта, 50 видами оружия, 30 огромными локациями, 10 разными классами, семью концовками и процедурно-генерируемым миром. Особенно, если это ваша первая игра.

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

В конечном итоге, зачем разрабатывать полноценную игру, если вы даже не уверены, будут ли в неё играть?

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

Ошибки молодых разработчиков: колонка основателя Another Life

Болевая точка — финансирование

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

Смета разработки более трёх раз пересчитывалась в большую сторону.** Это происходило из-за нехватки опыта и частичного непонимания того, как решать подобные задачи. Часто приходилось искать ответы наощупь, реже — просто бросать фразу «доберёмся и узнаем, как это сделать». Мы придумывали велосипед.

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

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

Ошибки молодых разработчиков: колонка основателя Another Life

Неверные решения:

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

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

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

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

Вместо итогов

3737
25 комментариев

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

2
Ответить

Благодарю за пожелание!

Делаем всё от нас зависящее.

Ответить

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

1
Ответить

Сейчас проблем с 3д уже нет. Потратили достаточно времени на изучение вопроса и оптимизацию.

В камере до 20к трисов, по отрисовкам 30-50 сетпассов, по текстурам 20 мб на уровень (последние активно реиспользуем).

2
Ответить

Вряд ли смогу дать развёрнутый ответ лучше, чем Сергей Галёнкин. По этому просто оставлю ссылку:

http://galyonkin.com/2014/11/10/10-priznakov-aziatskoy-monetizatsii/

1
Ответить

Понял. А пвп у вас не будет в проекте? А то все эти азиатские игры в основном на пвп ивентах монетизируются все-таки.

Ответить

Откуда вы узнали о повышении шансов на заработок если вы еще ничего не заработали ?

Ответить