Рубрика развивается при поддержке
Gamedev
Sergey Rukosuev
6838

Ошибки молодых разработчиков: колонка основателя 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-стилистикой.

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

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

Wikipedia

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{ "author_name": "Sergey Rukosuev", "author_type": "self", "tags": ["\u043e\u043f\u044b\u0442","\u0438\u043d\u0434\u0438","long"], "comments": 25, "likes": 52, "favorites": 13, "is_advertisement": false, "subsite_label": "gamedev", "id": 3911, "is_wide": false, "is_ugc": true, "date": "Sun, 29 Jan 2017 13:19:52 +0300", "is_special": false }
Проект в сеттинге киберпанка
Вакансия Game Designer
я с вами!
0
25 комментариев
Популярные
По порядку
Написать комментарий...
2

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

Ответить
0

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

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

Ответить
1

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

Ответить
2

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

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

Ответить
1

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

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

Ответить
0

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

Ответить
1

Хороший вопрос.

Изначальная идея проекта - это RPG на стыке онлайн и офлайн решений (PvP, PvE, Торговля) но мы решили сосредоточиться пока на одиночном прохождение. Всё упирается в ресурсы.

Время и аналитика покажут, на сколько это было правильным решением.

Ответить
2

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

Ответить
0

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

Ответить
0

Долго думал над тем, откуда появился ваш вопрос.

Из предыдущего опыта, на котором заработали.

Ответить
1

Спасибо за статью аж напомнило меня лет 15 назад

не очень понял за счет каких финансов ведется проект собственные средства или все таки есть инвестор ?

Ответить
0

Всё это время разрабатывали на свои средства.

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

Ответить
0

о) а можно как нить (в личку например) узнать что за условия в среднем )

Ответить
1

Отличная статья, спасибо!

Ответить
1

Сережа, верю в вас! Удачи! :)

Ответить
0

Спасибо )

Ответить
0

Интересно, спасибо
Большая у вас команда?

Ответить
1

Благодарю за отзыв!

В основной состав входят 7 человек. Всего в разработке задействовано 13.

Ответить
0

Я так понял, что вы хотите выходить на iOS, а еще где?
Или уже вышли где-то? Игра ориентирована на мобилки?

Ответить
1

Софт-ланч на iOS.Отполируем, доработаем, оптимизируем и уже тогда на Android.

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

Ответить
1

понятно, удачи!

Ответить
0

Разработка европейского продукта с рядом важных решений под Азию повысит шансы на продажи (заработок) в этом регионе.

А можно тут поподробнее?

Ответить
0

вы получите ранний и оперативный фидбек на ваши идеи

В каком виде должны быть оформлены идеи, чтобы получить на них _полезный_ отзыв/совет от другого разработчика?

Если у Вас был опыт выдачи фидбека: На что давался такой фидбек? Какие детали/части игры обсуждались?

Ответить
0

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

Ответить
0

В каком виде должны быть оформлены идеи, чтобы получить на них _полезный_ отзыв/совет от другого разработчика?

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

Если у Вас был опыт выдачи фидбека: На что давался такой фидбек? Какие детали/части игры обсуждались?

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

Ответить

Прямой эфир

{ "jsPath": "/static/build/dtf.ru/specials/DeliveryCheats/js/all.min.js?v=05.02.2020", "cssPath": "/static/build/dtf.ru/specials/DeliveryCheats/styles/all.min.css?v=05.02.2020", "fontsPath": "https://fonts.googleapis.com/css?family=Roboto+Mono:400,700,700i&subset=cyrillic" }