-Поиск по дневнику

Поиск сообщений в rss_rss_hh_new

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 17.03.2011
Записей:
Комментариев:
Написано: 51


С чего начать молодым разработчикам мобильных игр из России [Часть 3]

Вторник, 19 Сентября 2017 г. 14:49 + в цитатник
EgorHMG сегодня в 14:49 Разработка

С чего начать молодым разработчикам мобильных игр из России [Часть 3]

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



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



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

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

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

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

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

    Коммиты



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

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



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

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



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

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

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

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

    Оптимизация



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

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

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

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


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

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

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

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

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

    Аудитория



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

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

    P.S.



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

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

    В общем, кто решится на установку нашего творения — энжой и большая благодарность.

    Будем рады любому фидбеку.

    Ссылка на обновляемый билд бета тестирования в Google play 

    Всем спасибо!

    Продолжение следует.
    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/338242/

    Метки:  

     

    Добавить комментарий:
    Текст комментария: смайлики

    Проверка орфографии: (найти ошибки)

    Прикрепить картинку:

     Переводить URL в ссылку
     Подписаться на комментарии
     Подписать картинку