Разработка игры в Unity3D

После завершения создания игры-головоломки на Unity и выпуска ее на Google Play и AppStore, появилось желание поделиться опытом и впечатлениями. И получить конструктивные замечания и предложения, если таковые возникнут

Командная работа


Итак, проект делался на Unity 4.5 Free усилиями 5 человек в свободное от работы и домашних забот время. Для организации командной работы мы использовали сервис Bitbucket — там как раз до 5 человек можно добавлять в проект бесплатно. Система контроля версий — Git. Насколько я понял, Unity PRO имеет свою систему контроля версий, но мы решили не покупать PRO и не хакать — юзали Free

Первой проблемой, с которой столкнулись, было довольно сложное сливание изменений, внесенных разными разработчиками. Файлы Unity проекта — формы, префабы и проч. — имеют свои своеобразные форматы, и как текстовые файлы не сливаются. В итоге мы просто разделили ответственность: более одного человека не правили одновременно одну форму или один префаб. Этого несложно добиться, если правильно распределять задачи. С файлами скриптов на C#, конечно, никаких проблем не возникло, их правили одновременно

Производительность


Проект решили делать в 2D. Итоговая картинка формируется из 3 слоев: подложка, тень от элемента и элемент

image

Тестируя потом игру на устройствах, мы обнаружили, что у нас очень низкие FPS — около 20, и безумное потребление батарейки. Выяснилось, что проблема в отображении полупрозрачного слоя теней. Их вроде не так много на уровне, но в Unity это совершенно убивает производительность

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

Выглядит он приблизительно так: есть словарик, где ключами служат различные анимации и действия пользователя. Каждому ключу ставится в соответствие целое число — счетчик. Анимация или действие инкрементирует счетчик, когда завершается — декрементирует. Когда по всем ключам счетчики==0, мы понижаем FPS:

Application.targetFrameRate = Constants.CountFPS_Min; // == 10, в нашем случае

Как только что-то происходит — мы аналогичным образом снимаем ограничение. После этого нехитрого фокуса мы забыли о проблемах с батарейкой

Подключение встроенных покупок (in-app purchases).Тестирование.


Для организации внутренних покупок мы используем плагин Soomla версии 1.5.3.

Как-то мы добавили в игру новую покупку — открытие 6 главы. Установили себе на телефоны, проверили, что все работает. Залили на Google Play. И получили кучу гневных отзывов! Почему? — потому что, как оказалось, при первой установке нашей игры, все покупки работают как надо. Но при обновлении игры, Soomla не подхватывала новую покупку, и пользователи наблюдали интересный баг с 6 главой. Возможно, дело в том, что Soomla кэширует на телефоне список покупок и при обновлении не находит новую…

Оказывается, что при любой модификации списка покупок необходимо изменять (инкрементировать) версию этого списка в нехитрой функции

int GetVersion() {return 1;}

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

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

Для себя проблему с тестированием мы решили так:

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

2) перед созданием релиза необходимо перепроверять ключи, необходимые для корректной работы плагина Soomla и других плагинов (например GoogleAnalytics, Google Games)

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

4) естественно мы в полной мере используем функционал для тестирования, предоставляемый на площадках разработчика

5) с большим вниманием относимся к жалобам пользователей. Мы понимаем, что мелочей не бывает.

***

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

Contact us

Email: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.
Skype: south-media.com
Phone: +7 903 4057009, +7 928 1260550
Top
Локальный сервер Денвер.
Установка Joomla на локальный сервер.