Делимся продолжением истории из жизни инди-разработчиков из IzHard. Сегодня команда расскажет про события, которые с ними происходили после победы в международном конкурсе, а также про ошибки, которые они совершали в процессе развития.
Цикл статей «GameDev с нуля»
1. История команды:
1.1. От хакатона до собственной студии разработки игр: часть 1, часть 2.
1.2. Организация командной работы.
1.3. Loading…
2. Разработка игры:
2.1. Unity3D и векторная графика.
2.2. Loading…
3. Дизайн как идеология игры:
3.1. Как общаться с игроком без слов.
3.2. Loading…
Всем привет
Продолжаем цикл статей «GameDev с нуля» глазами команды IzHard. В первой части мы рассказали, как попали в игровую индустрию и победили в конкурсе Imagine Cup. Во второй части расскажем о том, как пошли наши дела по возвращению домой, как расширилась наша команда, какие задачи мы поставили перед собой, что дают поездки на игровые конференции, почему получилось, что игру делаем так долго, и как резюме, наши ошибки, которые мы наделали будучи неопытными, и советы о том, как не стоит поступать.
Возвращение домой и приятные новости
Итак, после того как мы вернулись в Питер и сделали себе перерыв длиной в месяц, нам предстояло решить главную задачу — доделать игру и выпустить её.
Уже в начале осени у нас появился заинтересованный издатель — компания Nekki. Они предложили нам неплохие условия, на которых мы полностью брали на себя разработку продукта, а все вопросы маркетинга и продвижения оставались им. Это был отличный вариант — не отвлекаться от разработки и спокойно делать игру. Мы заключили устную договоренность с Nekki о сотрудничестве и принялись за дело.
Пополнение команды
Нам очень хотелось сделать игру с необычным сюжетом. Вся команда фанатела от игры Journey и мечтала сделать что-то похожее — с глубоким философским сюжетом и «молчаливым» геймплеем. Мы взяли в команду нарративного дизайнера, который также занимался ещё и маркетингом в нашей команде.
Также мы поняли для себя, что понадобится программист с хорошим знанием Unity, поскольку очень много времени уходило на исследование движка и его возможностей. Предложений было много, но мы медлили с ответом. У многих ребят был хороший опыт в разработке, но нам хотелось найти человека, который был бы так же одержим игрой, как и мы.
В итоге, случайно наткнувшись на статью на Хабре, мы нашли человека, который в одиночку делает свою игру и разделяет наше видение дизайна: минимализм вплоть до цвета, необычный геймплей и отсутствие привычных для игрока элементов интерфейса. Удивительным было то, что концепт игры, описываемой в статье, оказался близок к изначальной идее OVIVO. И, недолго думая, мы связались с автором, а после предложили переехать в Санкт-Петербург и вместе делать наши игры.
Так команда из трёх превратилось в пять: программист, графический дизайнер, художник, нарративный дизайнер и геймдизайнер. Этим составом мы и решили сделать игру мечты.
Ошибка #1. Не стоит делать первой игрой игру мечты, если у вас нет опыта. Хочется сделать идеально, но без опыта очень трудно добиться желаемого результата. Из-за этого процесс разработки сильно затягивается и есть риск, что потеряется интерес к делу.
Начало разработки и генерация идей
Начать разработку мы решили с написания концепции всей игры и детального описания дизайн-документа. За шаблон документации взяли небезызвестную «Курочку Рябу».
Первые наброски для игры:
Концепт написали сразу, а диздок наполнялся по ходу разработки. В основном этим описанием занимались геймдизайнер и нарративщик, а в брейншторминге участвовала вся команда. С этого началась первая проблема — каждый хотел что-то придумать и добавить это в игру. В итоге на обсуждения уходило слишком много времени.
Мы решили как-то ограничить нашу фантазию и придумали, так сказать, трех «китов», на которых основывается игра и направляет генерацию идей в нужном направлении. Три правила, которыми мы руководствуемся и сейчас (для нас это стало некой мантрой):
1. В игре только два цвета: чёрный и белый.
2. Полное отсутствие какого-либо текста.
3. Управление только тремя кнопками: вправо/влево и кнопка «прыжка».
Это очень сильно помогло отсеять лишние идеи и повернуть мысли в нужном направлении. Так мы избавились от лишних механик, проблем с локализацией и четко определились с визуальным стилем игры.
Ошибка #2. Дизайн документ в виде текстового документа — абсолютно ненужная для небольшой команды вещь. Читать его никто не хочет, а процесс заполнения занимает много времени. Диздок — необходимый инструмент, но он должен быть удобен для прочтения и навигации, и очень важно содержать в нем чёткую структуру проекта. Для нас хорошей альтернативой стал способ ведения документации с помощью менеджера задач.
Организация работы
Когда концепт был написан и команде было дано общее видение игры, мы приступили к разработке. Изначально все роли были чётко распределены и, казалось, что каждый сам знает, что делать. Однако вскоре выяснилось, что некоторые задачи делаются излишне долго, команде не очевидна их приоритетность, а многие задачи приходится переделывать из-за несогласованности. К тому же Unity регулярно выпускала патчи, и команде нужно было быть постоянно в курсе обновлений.
Для согласования работы мы стали проводить ежедневные митинги, чтобы каждый знал кто чем занимается и какие задачи на неделю более приоритетны и чего ожидаем увидеть через месяц. Так мы плавно перешли к принципам гибкой методологии разработки и стали устанавливать спринты. Если кто-то пропускал митинг, то геймдизайнер выписывал задачи в менеджер задач и устанавливал приоритетность и сроки.
В конце концов, мы пришли к тому, что диздок представляет собой набор задач в таск менеджере. И каждую неделю вместе выбираем какие задачи наиболее приоритетны и выкладываем их в другую доску, чтобы не путать со всем пулом задач. На их решение определяем дедлайны (обычно неделю), и если не укладываемся, то переносим нерешенные задачи на следующую неделю. Если задача слишком сложная или занимает много времени на решение, то забиваем на её.
Ошибка #3. К сожалению, в нашей команде не все смогли приучить себя к дедлайнам. А для некоторых корпоративные методы просто «неинтересные», чтобы их соблюдать.
Конференции
На протяжении всей разработки мы очень часто ездили на различные игровые мероприятия и конференции. Конечно, в основном нам хотелось просто путешествовать и знакомиться с людьми, общаться с профессионалами из геймдев-тусовки. Например, Microsoft спонсировала нам, как победителям Imagine Cup, поездку на PAX EAST в Бостоне, где мы попали на twitch и познакомились с Рами.
Была ещё одна большая польза от мероприятий — мы всегда шоукейсили игру и получали ценный фидбек непосредственно от игрока. Сначала мы скептически относились к шоукейсам, мол, время отнимает и нет особого в них смысла. Но когда тесты показали, что в игре полно пробелов, мы кардинально поменяли свое мнение.
Очень полезный навык, который мы выработали на шоукейсах — это молчать пока тестируют вашу игру. Без подсказок игрок проходит игру, как если бы получил её дома, и тем самым демонстрирует в каких моментах у него возникают проблемы. Ещё ценнее, когда игрок высказывает все свои мысли. Так мы поняли, что в игре большой уровень сложности, а многие элементы непонятны и требуют доработки. Поэтому мы решили упростить многие моменты, сделали более гладкую кривую сложности и добавили туториал (о том, сколько раз мы переделывали туториал, можно отдельную статью написать).
Ошибка #4. Не стоит злоупотреблять частыми выездами на конференции, поскольку это очень отвлекает от процесса разработки и отнимает немало времени на подготовку. Однако, не стоит разрабатывать игру в полной изоляции и бояться показать её на публике. Плейтесты очень важны практически на всех этапах создания игры — они дают возможность выбрать верный курс разработки. В идеале нужно научиться балансировать так, чтобы основные ресурсы тратились именно на разработку, но и не забывать о тестировании и общении с коллегами.
Долгая разработка и отказ от издательства
Изначально, после Imagine cup, мы договорились, что игра для нас станет обучающим проектом. Поэтому первое время мы изучали возможности Unity и по мере продвижения разработки придумывали улучшения для нашей игры. Кстати, вот так выглядел первый уровень игры во время Imagine Cup.
Мы несколько раз переписывали функциональную часть проекта, поскольку старые механизмы не соответствовали новым требованиям геймплея. Аналогично с графикой — использование растра слишком «грузило» проект. В нашем случае это было очень критично, поскольку вся игра была чёрно-белая. К тому же графика — это интерактивный элемент. Персонаж взаимодействует с каждым углом платформы, и нужно найти баланс в точности отрисовки графики и построения физических свойств.
В конце концов мы нашли способ — использовать в Unity векторную графику (об этом будет отдельная статья). Проект стал весить мегабайты вместо гигабайт, и это позволило без проблем создавать билды для мобильных платформ.
Сейчас первый уровень игры выглядит вот так.
Однако перелопачивание проекта и частые конференции привели к постоянным срывам сроков. Мы не успевали завершить свои задачи в том виде, в каком хотелось, и часто приходилось делать «заглушки» в игре. Для продвижения издателю были нужны видео-ролики, промо материалы, работа с сайтом и так далее. Времени на разработку приходилось уделять меньше, а жертвовать качеством игры очень не хотелось. В итоге мы решили отложить вопрос с издательством Nekki и сосредоточиться на разработке.
Ошибка #5. Качественное планирование и знание всех этапов разработки (от генерации идей до продвижения) на начальных этапах поможет сэкономить время в будущем.
Эпилог
За прошедшие два года мы многому научились, и, несмотря на множество ошибок и затянувшуюся разработку, мы всё равно получаем кайф от нашей работы. Нам очень нравится то, что мы делаем, и мы советуем всем, кто смотрит в сторону геймдева — пробовать.
На текущий момент игра OVIVO находится на финальном этапе разработки: мы тестируем уровни, исправляем баги, готовим материалы для прессы. Запланированный месяц выхода игры — май. Параллельно мы будем продолжать делиться своим опытом. В следующих частях мы опишем техническую составляющую игры, более подробно расскажем про этапы разработки и юридические вопросы, которые встают перед инди-разработчиком.
Надеемся, что статья была вам полезна и с радостью ответим на ваши вопросы. Всем спасибо!
Автор: Microsoft
