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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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