- PVSM.RU - https://www.pvsm.ru -

GameDev с нуля: От хакатона до собственной студии разработки игр. Часть 2

Делимся продолжением истории из жизни инди-разработчиков из IzHard [1]. Сегодня команда расскажет про события, которые с ними происходили после победы в международном конкурсе, а также про ошибки, которые они совершали в процессе развития.

GameDev с нуля: От хакатона до собственной студии разработки игр. Часть 2 - 1

Цикл статей «GameDev с нуля»

1. История команды:
1.1. От хакатона до собственной студии разработки игр: часть 1 [2], часть 2 [3].
1.2. Организация командной работы.
1.3. Loading…
2. Разработка игры:
2.1. Unity3D и векторная графика.
2.2. Loading…
3. Дизайн как идеология игры:
3.1. Как общаться с игроком без слов.
3.2. Loading…

Всем привет

Продолжаем цикл статей «GameDev с нуля» глазами команды IzHard [1]. В первой части [4] мы рассказали, как попали в игровую индустрию и победили в конкурсе Imagine Cup [5]. Во второй части расскажем о том, как пошли наши дела по возвращению домой, как расширилась наша команда, какие задачи мы поставили перед собой, что дают поездки на игровые конференции, почему получилось, что игру делаем так долго, и как резюме, наши ошибки, которые мы наделали будучи неопытными, и советы о том, как не стоит поступать.

Возвращение домой и приятные новости

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

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

Пополнение команды

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

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

В итоге, случайно наткнувшись на статью на Хабре [6], мы нашли человека, который в одиночку делает свою игру и разделяет наше видение дизайна: минимализм вплоть до цвета, необычный геймплей и отсутствие привычных для игрока элементов интерфейса. Удивительным было то, что концепт игры, описываемой в статье, оказался близок к изначальной идее OVIVO. И, недолго думая, мы связались с автором, а после предложили переехать в Санкт-Петербург и вместе делать наши игры.

GameDev с нуля: От хакатона до собственной студии разработки игр. Часть 2 - 2

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

Ошибка #1. Не стоит делать первой игрой игру мечты, если у вас нет опыта. Хочется сделать идеально, но без опыта очень трудно добиться желаемого результата. Из-за этого процесс разработки сильно затягивается и есть риск, что потеряется интерес к делу.

Начало разработки и генерация идей

Начать разработку мы решили с написания концепции всей игры и детального описания дизайн-документа. За шаблон документации взяли небезызвестную «Курочку Рябу».

Первые наброски для игры:

GameDev с нуля: От хакатона до собственной студии разработки игр. Часть 2 - 3

GameDev с нуля: От хакатона до собственной студии разработки игр. Часть 2 - 4

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

Видео, в котором мы обсуждаем идею.

Мы решили как-то ограничить нашу фантазию и придумали, так сказать, трех «китов», на которых основывается игра и направляет генерацию идей в нужном направлении. Три правила, которыми мы руководствуемся и сейчас (для нас это стало некой мантрой):

1. В игре только два цвета: чёрный и белый.
2. Полное отсутствие какого-либо текста.
3. Управление только тремя кнопками: вправо/влево и кнопка «прыжка».

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

Ошибка #2. Дизайн документ в виде текстового документа — абсолютно ненужная для небольшой команды вещь. Читать его никто не хочет, а процесс заполнения занимает много времени. Диздок — необходимый инструмент, но он должен быть удобен для прочтения и навигации, и очень важно содержать в нем чёткую структуру проекта. Для нас хорошей альтернативой стал способ ведения документации [7] с помощью менеджера задач.

Организация работы

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

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

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

Ошибка #3. К сожалению, в нашей команде не все смогли приучить себя к дедлайнам. А для некоторых корпоративные методы просто «неинтересные», чтобы их соблюдать.

Конференции

На протяжении всей разработки мы очень часто ездили на различные игровые мероприятия и конференции. Конечно, в основном нам хотелось просто путешествовать и знакомиться с людьми, общаться с профессионалами из геймдев-тусовки. Например, Microsoft спонсировала нам, как победителям Imagine Cup, поездку на PAX EAST в Бостоне, где мы попали на twitch и познакомились с Рами.

GameDev с нуля: От хакатона до собственной студии разработки игр. Часть 2 - 5

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

GameDev с нуля: От хакатона до собственной студии разработки игр. Часть 2 - 6

Очень полезный навык, который мы выработали на шоукейсах — это молчать пока тестируют вашу игру. Без подсказок игрок проходит игру, как если бы получил её дома, и тем самым демонстрирует в каких моментах у него возникают проблемы. Ещё ценнее, когда игрок высказывает все свои мысли. Так мы поняли, что в игре большой уровень сложности, а многие элементы непонятны и требуют доработки. Поэтому мы решили упростить многие моменты, сделали более гладкую кривую сложности и добавили туториал (о том, сколько раз мы переделывали туториал, можно отдельную статью написать).

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

Долгая разработка и отказ от издательства

Изначально, после Imagine cup, мы договорились, что игра для нас станет обучающим проектом. Поэтому первое время мы изучали возможности Unity и по мере продвижения разработки придумывали улучшения для нашей игры. Кстати, вот так выглядел первый уровень игры во время Imagine Cup.

GameDev с нуля: От хакатона до собственной студии разработки игр. Часть 2 - 7

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

В конце концов мы нашли способ — использовать в Unity векторную графику (об этом будет отдельная статья). Проект стал весить мегабайты вместо гигабайт, и это позволило без проблем создавать билды для мобильных платформ.

Сейчас первый уровень игры выглядит вот так.

GameDev с нуля: От хакатона до собственной студии разработки игр. Часть 2 - 8

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

Ошибка #5. Качественное планирование и знание всех этапов разработки (от генерации идей до продвижения) на начальных этапах поможет сэкономить время в будущем.

Эпилог

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

На текущий момент игра OVIVO [8] находится на финальном этапе разработки: мы тестируем уровни, исправляем баги, готовим материалы для прессы. Запланированный месяц выхода игры — май. Параллельно мы будем продолжать делиться своим опытом. В следующих частях мы опишем техническую составляющую игры, более подробно расскажем про этапы разработки и юридические вопросы, которые встают перед инди-разработчиком.

Надеемся, что статья была вам полезна и с радостью ответим на ваши вопросы. Всем спасибо!

Автор: Microsoft

Источник [9]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/microsoft/248916

Ссылки в тексте:

[1] IzHard: https://aka.ms/habr_323676_1

[2] часть 1: https://habrahabr.ru/company/microsoft/blog/321872/

[3] часть 2: https://habrahabr.ru/company/microsoft/blog/323676/

[4] первой части: https://aka.ms/habr_323676_2

[5] Imagine Cup: https://aka.ms/habr_323676_3

[6] статью на Хабре: https://aka.ms/habr_323676_4

[7] способ ведения документации: https://aka.ms/habr_323676_5

[8] OVIVO: https://aka.ms/habr_323676_6

[9] Источник: https://habrahabr.ru/post/323676/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best