Этапы создания мобильного приложения

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

На связи студия Hairy Elephant! Расскажем наши этапы по созданию мобильных приложений под android.

Наш стек технологий

Unity3D  +  С#     — для разработки приложений
Google Docs          — для написания концепта
Hacknplan            — для распределения задач и учёта времени
Unity ad                 — для встроенной рекламы
Google Firebase   — для отображения статистики
Upmob                   — для раскрутки

Проработка идеи

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

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

  • целевой аудитории
  • жанра
  • основных механик
  • затратами в трудочасах

Затем наша команда собирается и обсуждает предложенный концепт. Необходимо понимать

  • Актуальность
  • Сложность
  • Риски

Если 3 этих сочетания не выходят за рамки мало\сложно\большие, то команда принимается за написание полноценного концепта продукта стадии MVP, где уже в первую очередь прописывается монетизация игры. Если у игры нет монетизации — у продукта почти нет шансов заработать.

 

Анализ рынка

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

  1. Как сочетаются механики. Возможно в похожей игре реализовали схожие механики, а значит можно узнать сработали ли они.
  2. Отзывы людей. Как говорилось выше, по отзывам игроков можно оценить проблемы и успехи реализованных механик
  3. Нагретость рынка. Если за несколько часов можно найти огромное количество (скажем, больше 10-50 игр) с похожими механиками или идеями, значит игра будет неактуальной и, скорее всего, её никто не заметит или будет только сравнивать. Поэтому нужно будет пересмотреть идею игры и её механику. Это очень полезный этап, так как он помогает сформировать более целостную игру со своими уникальными улучшениями и механиками.
  4. Среднюю цену/Количество установок. Данный параметр помогает понять, на основе чего формировать цену новой игры или на какое количество установок рассчитывать (хотя по итогу цифры могут разительно отличаться, даже игра будет скопирована полностью).

Кроме анализа рынка и приложений в Google Play хорошо важно понимать целевую аудиторию продукта. Один из основных параметров, который нужно учитывать — возраст вашей аудитории. Если вы делаете игру для детей, то игры наподобие хоррора/RTS/MMO не подойдут.

Детская игра, как и аркада, должны быть красочной, привлекательной и в то же время не очень сложной. Не стоит в аркаде использовать перенасыщенные 3d-модели или реалистичное окружение — оно тут ни к чему. Чтобы убедиться в этом, посмотрите современные мультики (я бы сам нарисовал такие за 1 бессонную ночь и бутылку).

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

Разработка

Если вы перешли к этапу разработки значит у вас должно быть:

  1. Прописанный концепт. Вы понимаете идею игры, особенности её механик, исключительность игры и отличие от конкурентов.
  2. Целевая аудитория. Вы понимаете, кому вы будете продавать свою игру и для кого вы её разрабатываете, в первую очередь.

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

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

Прежде всего важна иерархия и отчётность. У нас в команде действиями всех разработчиков руководит архитектор, которой продумывает всю структуру игры и разбирается в каждом вопросе разработки. За действиями всех художников и выполнением задач, следит гейм-дизайнер, который проверят отчётность и даёт прикурить, если какая-то задача не закрывается в срок. А так же решает спорные вопросы по реализации механик и стилистического оформления.

Почему важна отчётность?

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

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

Тестирование

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

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

 

Тестирование готового MVP

После того, как вы реализовали весь функционал у вас уже есть MVP, но помните: это не готовая игра — это альфа-версия. На этом этапе у вас есть базовые механики, модели и окружение (по возможности).

Сперва вам необходимо провести внутреннее (командное) тестирование. Оно займёт от 1 до 3х недель в зависимости от сложности мобильного инди-приложения. За это время вы своими силами отполируете механики и первоначальный баланс, добавите модели, картинки. Продумаете улучшения игры и работу над обновлениями. А также найдёте большое количество багов (возможно, вам даже удастся их исправить).

Затем вам нужно найти фокус-группу, которой вы дадите поиграть в свою игру после внутреннего тестирования. Фокус-группа выдаст мнение о вашей игре, поможет понять баланс сочетания механик и предложит их улучшения/исправления, выявит откровенно слабые моменты, а также поможет вам в нахождении новых багов. Оценка фокус-группы важна, ибо это уже сторонние пользователи, которые об игре ничего не знают. После анализа оценок и отзывов фокус-группы вы более детально сформируете следующие обновления и ожидания по просмотрам/скачиваниям

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *