Всем доброго!


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



Ранние публикации можно прочитать тут:

> Часть 1
> Часть 2

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

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

С этим были связаны основные проблемы. Чтобы их нивелировать мы вывели несколько основных правил (многие из них освещались и не раз, но возможно для кого-то они станут новостью):

1) Коммит в репозитории делается после каждого плюс – минус значительного изменения;
2) Тестирование на «живых» устройствах проводится не менее трех раз в день, чтобы в случае чего можно было безболезненно откатить изменения;
3) Разработка ведется небольшими итерациями и продолжается только после полного теста небольшого кусочка;
4) Оптимизация – наше всё;
5) Билд для внешних тестировщиков не заливается раньше, чем выполнен внутренний полный тест и не убраны «жесткие баги»;
6) Глобальное обновление ни в коем случае не должно выходить перед праздниками и выходными.
7) Чем больше внешних тестировщиков – тем лучше;

Пойдем по пунктам:

Коммиты


Думаю, ни для кого не новость, что без контроля версии вести разработку категорически противопоказано. Если разработка ведется более, чем одним человеком – это смертельно опасно. После каждого изменения, которое влияет на механику или алгоритм игры необходимо сделать коллаборацию между всеми разработчиками. Я думаю каждый, кто вел разработку в таких условиях сталкивался с ситуацией, когда все разом залили изменения, что-то перестало работать, а в чем причина – неясно. Еще хуже – если понятно, что причиной нерабочей версии стали плоды целого рабочего дня разработчика и нужно откатывать все изменения назад. Менее неприятно, если причиной стал конфликт работы и просто нужно немного переделать. Идеально, если все видят изменения в режиме реального времени и знают, что в случае чего – максимальный откат назад будет минут в 10-15.

Физические устройства


То, что мы видим в среде разработки, бывает далеко от того, что мы увидим на устройствах. Если с ПК версией у всех всё плюс-минус одинаково, то с мобильными устройствами всё обстоит несколько иначе.

Некоторые пункты нужно будет калибровать «на глаз», некоторые оптимизировать и даже делать даунгрейд (этого тоже бояться не нужно).

Короткие задачи


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

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

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

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

Оптимизация


Я думаю, что объяснять зачем её делать не нужно. От себя хочу сказать, что оптимизировать всё и сразу тоже неправильно. В данном случае работает правило 20/80, когда 20% усилий приносят 80% пользы. Подходите к вопросу с умом.

Внутреннее тестирование и выходные


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

Кейс из жизни:


После фикса UI мы не заменили скрипт на кнопке запуска уровня.

Стандартная череда неправильных поступков (отмазка): Время было позднее, много чего было поправлено и добавлено, впереди выходные, да и вечер пятницы сказался на внимательности. В общем, как это всегда и происходит – кто-то не доделал, кто-то не проверил, имеем что имеем.

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

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

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

Аудитория


Для сбора аналитики пока что мы используем только Firebase и фидбек от тестировщиков. Это позволило нам оптимизировать игру под старые графические чипы и свести лаги к минимуму, по сравнению с первыми версиями. Чем больше устройств – тем полней картинка. Иногда мы связывались напрямую с человеком и оптимизировали игру именно под его устройство. На выходе получалось так, что вмести с этим устройством был ощутимый прирост и на других до этого проблемных девайсах.

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

P.S.


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

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

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

В ближайшее время в игре появятся endless уровни, новые уровни кампании и больше контента для прокачки.

Всем спасибо! Продолжение следует.

Комментарии (18)


  1. LenLord
    19.09.2017 16:22

    А бета-версия для ios-пользователей отсутствует?


    1. EgorHMG Автор
      19.09.2017 16:26

      Пока что занимаемся оптимизацией и контентом. Первые билды под iOS будут к середине октября.


  1. GarudaJI
    19.09.2017 16:50

    А чем европейские страны не угодили для бетки, Португалия в частности?
    This item isn't available in your country…


    1. EgorHMG Автор
      19.09.2017 16:54

      Планировали заливать постепенно при наличии локализации. Но для уважаемого GarudaJI
      сделал открытый доступ для Португалии. Приводите друзей.


      1. GarudaJI
        19.09.2017 17:20

        Спасибо, мое миниревью:
        + выглядит интересно
        + графика/анимация на уровне
        — не хватает туториала
        — не очевидно почему сбивание напитков, которые выбрасывает босс садит здоровье — можно добавить хоть взрывы какие-то раз уж это энергетик для супер удара
        — забрасывание героя мертвыми/спящими монстрами как-то имхо не очень — живыми/активными может повеселее будет


        1. EgorHMG Автор
          19.09.2017 17:25

          Спасибо за отзыв!
          Туториал — это пока что наше слабое место. Сейчас мы его прорабатываем и тестируем.
          Спасибо за коммент с боссом. В ближайшее время переварим анимацию и подачу.


  1. Lamaster
    19.09.2017 18:16
    -1

    Недавно появилась мысль включать запись микрофона на тестовых билдах и отдавать тестировщикам. В идеале при этом записывать экран.
    Так, при прослушивании «подопытных» можно выявить проблемы UX, отвалы на разных стадиях игры и просто неочевидности.
    Я бы хотел протестить эту методику самостоятельно, но пока что у меня нет собственного публичного проекта, готового для тестирования.
    Как вы относитесь к этой идее? Если будете проверять, было бы очень интересно узнать о результатах.


    1. EgorHMG Автор
      19.09.2017 18:19
      +1

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


      1. Lamaster
        19.09.2017 18:53

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


        1. GDXRepo
          19.09.2017 19:21
          +1

          Необъективное тестирование будет. Будет сильно съедаться заряд батареи, очень сильно понизится производительность (за счет записи экрана), не говоря о том, что даже при согласии человека на такое тестирование в микрофон может проскочить то, что он не захочет отправлять (может, он дома находится, или еще где, что уже относится к частной жизни). Да и далеко не каждый комментирует процесс тестирования вслух, это как раз исключение из общего правила (ну либо когда приложение настолько плохое, что без матов тестить не получается, но это тоже скорее исключение). Имхо, очень сомнительный вариант. Сбор обратной связи в виде просто вручную отправленных тестерами ошибок — этого более, чем достаточно, особенно если система обратной связи встроена прямо в приложение («потрясите телефон, чтобы отправить баг», и им подобные).


          1. EgorHMG Автор
            19.09.2017 19:38

            Абсолютно согласен по всем пунктам. Про аппаратную часть сразу даже не подумал почему то.


    1. Sol_Vento
      20.09.2017 11:17

      Для этого достаточно дать игру летсплейщикам и посмотреть прохождение. Как правило, их реакция на игру — это реакция «среднего игрока».


      1. EgorHMG Автор
        20.09.2017 11:23

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


  1. PoisonousJohn
    20.09.2017 13:01

    Вижу что вы очень серьезно относитесь к качеству и тестированию. По моему опыту ручное тестирование может выявить дай бог 10% багов.

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

    Успехов с проектом!


    1. EgorHMG Автор
      20.09.2017 13:04

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


      1. PoisonousJohn
        20.09.2017 13:06

        Я первое время тоже шел по пути «не хватает рук», но потом понял, что тестировать Unit-тестами всякую логику для meta-игры гораздо проще. Не каждый раз запускать игру и проверять. С геймплеем, конечно, все посложнее будет. Но это точно никак меня не замедлило, скорее наоборот.


        1. EgorHMG Автор
          20.09.2017 13:17

          Спасибо за совет! Может у вас есть практические идеи, как это можно организовать максимально эффективно? Был бы очень признателен.


          1. PoisonousJohn
            20.09.2017 15:50
            +1

            В целом, вся бизнес-логика мета-игры должна быть отвязана от Unity-классов. Тогда написать Unit тесты не составит проблем. Чтобы начать unit-тестить можно попробовать туторы от Unity.

            Идея в том, чтобы Unity был только прослойкой для вызова соответствующих методов. Тогда после написания бизнес-правил и unit-тестов, все что останется — привязать соответствующие вызовы из UI.

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

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

            Помимо Unit-тестов можно так же сделать интеграционные тесты. Например, я тестировал интграцию с facebook, получив руками токен, и запуская тесты, которые дергали разные API методы FB и проверяли, что наш код работает ок.

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

            Но в принципе, unit-тесты самый простой и быстрый способ.