Разработка игры для развития памяти под Android (C++, Qt)
Накидал очередную игрушку под Android. Поделка оказалась играбельной, выложил на маркет и решил написать статью о процессе разработки. Вообще, на habrahabr есть куча статей в стиле «моя первая игра под Android», но зачастую [1,2]:
Я решил исправить эти недочеты в своей статье. Код я писал на С++ и использовал библиотеку Qt.
Содержание:
Краткая история разработки
Раздел не содержит технических деталей, но прочитав его вы возможно сэкономите время.
2 года назад у одного первоклассника я увидел так называемые «графические диктанты» — на листе в клеточку стоит начальная точка и даны указания на подобии «две клетки направо, одна — вниз, …». Школьник выполняет рисунок по этим подсказкам и если все сделает правильно — на листе получается какой-нибудь жираф или песик. Мне это понравилось (и детям их нравится рисовать), однако расстраивало то, что диктанты эти надо постоянно распечатывать — я решил сделать такую же штуку для компьютера и телефона.
Через час штуковина для Android, на которой можно было рисовать по клеточкам была готова, еще через пару часов в приложение загружались уровни, которые запускались последовательно друг за другом. Тут выявилась основная проблема — графические диктанты направлены на развитие у детей не только навыка счета клеточек, но (главное) — мелкой моторики при рисовании линий. То-есть вне зависимости от того, как качественно все будет реализовано — игра будет бесполезной, т.к. от тыканья пальцем по экрану моторика не развивается. Я отложил «проект» на пол года, а затем пришла мысль доработать приложение с уклоном на развитие памяти.
Все было быстро написано, потом долго рефакторилось. Затем, игра была заново спроектирована (мне нужен был пример для статьи «Процесс разработки программного обеспечения ICONIX» [3]. При этом я нашел ряд недочетов в коде, что-то поправил и вот, выкладываю: ссылка на скачивание игры с Google Play.
Снимок игрового экрана
Изначально планировалась игра для детей, но оказалась не такой простой (не уверен что дети потянут).
Технические детали и повторно-используемый код
Исходный код игры можно взять с репозитория.
О процессе проектирования прочитать в статье «Процесс разработки программного обеспечения ICONIX» [3], хотя исходный код не совсем соответствует диаграммам.
При написании своей предыдущей игры я сделал очень простое меню в Qt Designer[6]. Меню было не удобным, на этот раз я сделал лучше, при этом постарался сделать код удобным для повторного использования. Среди прочего — меню перестраивается с учетом ориентации телефона (горизонтальная/вертикальная). Код меню и пример использования можно взять в репозитории, а нечто типа документации я поместил в заметку: Меню для телефона. Скролл пальцем. QGraphicsScene [7].
Также, почти в любом приложении должна отображаться справочная информация для пользователя. В прошлой игре вместо справки я реализовал демо-игру (с подсказками), а на этот раз использовал более универсальное решение, которое подойдет почти всем. Справка отображается в html-формате. Опять же, код — в репозитори, а описание — в заметке: Вывод справки в html формате [8].
H Написание игры под Android на C++ с помощью MoSync в черновиках
Примерно в декабре 2012 появилось острое желание спрограммировать самому игрушку для Андроида. Чтобы хоть она не падала и не была медленной и (сильно) убогой.
Дня два я просматривал табличку с возможными вариантами средств разработки. Требования — бесплатность, Андроид и Си-плюс-плюс. Я выбрал MoSync.
А теперь для желающих — подробно:
В 2011-ом у меня был миниатюрный опыт разработки для мобильных устройств на JavaScript-e.… Ну как разработки… точнее — реанимации сдохшего и заброшенного проекта. Опыт крайне неудачный, он надолго отбил интерес. А вначале был культурный шок от осознания: то есть я буду писать убогие игры (т.е. крайне далёкие от Starcraft-a и похожих), для людей, которые согласны заплатить две моих зарплаты за девайс, на котором можно будет играть только вот в такое убожество…
В декабре 2012 ситуация немного изменилась: в нашем «районном универсаме» появились дешёвые планшеты; я посмотрел количество скачивания популярных игр на GooglePlay, плюс у меня началась ломка от трёх месяцев без программирования — и я решился.
Первые шаги прошли легко: скачать и поставить студию MoSync, скомпилить программку-пример, порадоваться, что удалось запустить её в эмуляторе.
Ещё через какае-то время удалось запустить её на планшете.
Дальше был первый большой шок: дебаг программы в эмуляторе — он работал не всегда, и крайне непредсказуемо… Значения для переменных показывались не всегда правильные, формулы не поддерживались, содержание сложных структур не показывалось, и вообще программа иногда ломалась — не из-за кода, как выяснилось после бессонных ночей, а просто из-за глючного режима дебага.
Спасал только вывод информации на консоль.
Во-первых мне хотелось пальцами погонять картинки по экрану — то есть познакомиться с главным достоинством планшетов — самым удобным интерфейсом — тачскринистым. Выяснилось, что функций для вывода графики немного (функция круг/окружность вообще «самопальная») и что картинки (битмапы) я выводить (пока) не умею. Но самое главное — если вести пальцем по экрану планшета — была задержка, и похоже — это была проблема Андроида или тач-экрана.
А дальше началось «сделай сам».
Мне пришлось (и я это сделал) создать несколько Engine-ов. То есть, если я хотел добавить в проект какую-то «фичу» (фишку, примочку — особенность), мне нужно было знакомится с ней, изучать как её спрограммировать и вставить правильно, и какие у неё возможности. Дальше с этими «фичами» мне было удобнее работать через её Engine, при необходимости я изменял его… (без наследования, каюсь)
Первым был создан «Screen-Engine» — меня категорически не устраивало делать программу под какой-то конкретный размер экрана — я хотел работать с виртуальным экраном, а как его вывести на реальный — проблема Screen-Engine-а. Так же он конвертировал касание пользователя к экрану в виртуальные координаты, делал scroll (прокрутку виртуального экрана по меньшему реальному), pinch-zoom-in и pinch-zoom-out (изменение масштаба двумя пальцами). Это заняло больше всего времени — примерно месяца 3-6 — включая такие примочки, как замирание если аппликация не активна (чтоб не жрать батарейку и процессорное время зря) и показ пользователю определённых мест — «смотри: это — карта, отсюда начинаешь ты, а враг — примерно во-о-он там».
Далее поляки выпустили FreeCiv (бесплатная версия Цивилизации) под Android, и я проверил, будет ли у меня так же всё тормозить, если я буду отрисовывать карту «стратегии» из тайлов… Результат мне понравился, я решил обязательно вернуться к этой теме, но позже.
Затем (это был апрель-май, год назад) я решил выпустить игру попроще, ибо запутался в формулах тригонометрии и кинематики… Поскольку близкие во всю играли в Филлер, я решил делать его — будут проверять-тестить. (Надежды не оправдались.) Дабы не выпускать «ещё один HelloWorld», нужно было придумать, чем моя игра будет выделятся. Я решил, что раз это на Си — а значит работать будет быстрей, чем Ява (минусующим: это сугубо моё личное мнение) — то это будет нефиксированный размер экрана, поле — больше, чем у «конкурентов», какая-то анимация, и более «умный» ИИ.
Плюс я почувствовал, что нужна более простая игра, чтобы создать и проверить, «обкатать» все будущие Engine-ы — было похоже, что их понадобится немало.
Вторым Engine-ом стал Multi-Language-Engine. Он смотрел локаль (страна-язык мобильного устройства), загружал нужный язык (если не было — тогда дефолтный) и делал конвертации: UTF-8 (Multi-Byte-String) в Unicode и обратно — дело в том, что на экран игры (где отрисовка графики) нужно было выводить в Юникоде, а в менюшки — в UTF-8.
Так же Multi-Language-Engine формировал сообщения с параметрами — типа «у вас xxx дерева, yyy камня и zzz золота», для английского — «You have xxx wood, yyy stone and zzz of gold», и так — для всех поддерживаемых языков.
В начале выяснилось (после нескольких бессонных ночей), что Кхмерский язык не поддерживается — у шрифтов эмулятора и девайса нету букв для этого языка — ни в Юникоде, ни в UTF-8.
В конце выяснилось, что язык Хинди (а их 600-700 миллионов человек) не загружается корректно в UTF-8 (там более 4 байт на символ), но всё хорошо, если загружать его в Юникоде — т.е. мне повезло, что разрабатывал этот «языковой движок» для загрузки из обоих кодировок.
Дальше была работа с менюшками и диалогами — выяснилось (после долгих бессонных), что в MoCync элементы диалогов (виджеты) нужно не стирать, как в Си++, не обнулять, как в Яве, а оставлять нетронутыми — только тогда система их корректно сама… утилизирует.
Мне не понравилось, что у чек-бокса нажимается только кнопка, а не плюс ещё вся фраза, как в Виндах — пришлось писать своё…
Я не нашёл нормального элемента для набора числа — пришлось не только делать «своё», но ещё и добиваться, чтоб он был определённой ширины; какой — не знаю, узнаю кода он будет показан — от шрифта зависит…
Последними элементами по желанию были «рамочка вокруг чего-скажут» и горизонтальная линия (в принципе, та же рамочка, но на всю ширину).
После всех этих нововведений диалоги и менюшки перестали корректно уничтожаться, но эти было не критично — тихо висели в памяти.
AudioEngine — пляски с бубном продолжаются. Потому, что выяснилось, что не все функции MoSync корректно работают. Разработчики MoSync перестали отвечать и исправлять ошибки, потому что MoSync обанкротился. Но поскольку сил и времени уже было вложено много, то… Результат: громкость каждого звука не регулируется, но зато их можно не только останавливать и проигрывать, но даже ставить на паузу — это нужно, если аппликация не активна. Добиться этого удалось склеив стабильную версию библиотек студии «3.3.1» и «ночного билда с фиксом». Правда при этом аппликация перестала билдиться в Debug (отладочном) режиме. Но… он слегка полезен только запуская аппликацию в эмуляторе, а звуки и менюшки-диалоги в эмуляторе не работают — только на реальном устройстве.
Причина создания AudioEngine — автоматическая загрузка звуковых ресурсов, их более удобное проигрывание (и прочие функции), автоматические пауза (если аппликация не активна) и resume (возобновление проигрышей звуков), автоматическая работа с памятью — освобождение памяти звуков, что больше не используются; возможность проигрыша одного и того же звука одновременно более одного раза.
«Ёжики кололись и плакали, но продолжали. »
Я решил добавить не просто стены, а лабиринт — спасибо пользователю aivanov за публикацию его генератора лабиринтов aivanov.com/maze-generator/ — я его использовал.
Затем, чтобы играть стало ещё интересней, я добавил «fog of war» (туман войны), чтобы… интриговать пользователя «а туда ли я иду» в случае лабиринта, и «а далеко ли идут эти слепленные ячейки одного цвета» при выборе цвета.
После этого пришлось переделывать анимацию, дабы неизведанные ячейки «открывались» красиво; отдельно пришлось поработать с рамками вокруг ячеек; к сожалению, этого стало почти не заметно после того, как были сделаны картинки=битмапы на ячейки.
Дальше — не так интересно: составление, сохранение-загрузка и отрисовка «Таблицы лучших результатов», и картинки=битмапы на ячейки.
Вначале я их сделал такими, как хотел год назад — задумывая этот проект:
Результат (после года работы) мне не понравился, конечный вид:
Разработка приложений для Android с C#
Monodroid и Monotouch это фреймворки от xamarin, которые дают возможность разрабатывать приложение на языке C# для Android и iOS соответственно. Так как это относительно новая технология информации в интернете не слишком много (за исключением офф сайта и большого количества тем на stackoverflow.com), на русском языке же я не нашел никаких туториалов и информации вообще.
Что бы устранить это недоразумение решил написать небольшой туториал о том как начать разрабатывать приложения под мобильные платформы при помощи этих фреймворков. В этой статье я рассмотрю только Monodroid.
Что нужно для начала разработки?
1) Visual studio C# версии professional и выше (пойдет и крякнутая)
2) Сам фреймворк (а он, в свою очередь установит за нас и джаву, и виртуальную машину и все остальное)
Запустив после установки всего необходимого студию мы заметим новые типы проектов для создания: 
Выбираем Android Application. Будет создано несколько стандартных директорий: 
В папке Assets хранятся все используемые программой файлы аля видео, звуков, хтмл файлов и т.д. Изначально в ней ничего нет кроме текстовика с описанием самой директории и для чего она нужна.
В папке Drawable нужно размещать файлы изображений, используемые программой.
Папка Layout содержит файлы графического интерфейса.
В папке Values различные параметры, которые можно создавать и загружать при работе приложения (к примеру можно запомнить логин и пароль туда).
После создания пустого проекта мы можем его скомпилировать, нажав F5 — откроется настройки виртуальной машины с выбором устройства на котором запускать тест программы. Если подсоединить свой девайс на андроиде со включенной функцией отладки по USB (это в настройках, вкладка «для разработчика») то можно запустить и потестить непосредственно на нем. Очень советую проводить тесты на реальном устройстве т.к. многие тач элементы нельзя протестировать на виртуалке, к тому же, лично у меня на виртуальной машине приложение развертывается довольно долго. Между компиляцией и запуском на виртуалке проходит около минуты.
По умолчанию мы имеем кнопку, при нажатии на которую будет выведено сколько раз мы кликнули по оной. Попробуем сделать что-нибудь поинтереснее.
Откроем файл интерфейса и попробуем его поменять.
Снизу 2 вкладки- просмотр кода интерфейса и самого интерфейса. Справа- различные компоненты.
Сразу скажу: пользоваться встроенной формоклепалкой это не для слабонервных. Она на столько лагуча и делает не то, что ожидаешь что просто ужас. Вместо этого можно пользоваться сайтом droiddraw.org после составления интерфейс там и нажатие на кнопку Generate можно скопипастить код во вкладку кода и все будет ок.
А в прочем, самый лучший способ это создавать интерфейс из кода, посредством формул исходя из соотношений разрешения экрана. Без этого нормальный интерфейс, привлекательно смотрящийся на всех экранах создать сложно.
Однако, пока пойдем по простому пути.
Есть несколько типов расположения объектов на экране- типов слоев. При этом многие из них могут содержать друг друга и уживаться вместе. Рассмотрим из них:
1) LinearLayout — каждый элемент ниже предыдущего.
2) RelativeLayout — каждый элемент находится по отношению к предыдущему (к примеру, можно задать параметр находиться слева от кнопки1, снизу от текстбокса, в отступе в 40 пикселей снизу от кнопки 2 и т.д.
Настройки каждого компонента у нас в окне свойств- все довольно привычно, а сами свойства схожи с винформ элементами.
Создав более или менее привлекательный интерфейс его надо как то запустить.
Для этого существует Activity. По умолчанию у нас файл с названием Activity1, в котором класс- наследник от класса Activity.
Строка над объявлением класса-
[Activity(Label = «AndroidApplication1», MainLauncher = true, Icon = «@drawable/icon»)]
описывает заголовок окна приложения, иконку и узнает запускать ли эту активити при запуске приложения.
Из основной автозапускаемой активити можно запустить любую другую. После автозагрузки данной активити после старта приложения мы загружаем интерфейс строкой SetContentView(Resource.Layout.Main);
Для получения доступа к любому элементу мы должны воспользоваться функцией FindViewById<>(); при присвоении экземпляру класса таго элемента, который нам нужен. Конкретно в нашем примере мы видим строчку
«MyButton» это название кнопки, посмотреть его можно при создании интерфейса во вкладке код.
Посредством простой конструкции Button button = FindViewById(Resource.Id.MyButton);
мы можем работать с кнопкой и обрабатывать все действия с ней. В данном случае обработчик клика выглядит так:
Спроектировав и написав приложение мы моем скомпилировать apk файл посредством перехода во вкладку построение и нажатии кнопки Package for android. В папке проекта появится 2 файла, один из которых подписан автоматической подписью- его мы и можем использовать для установки па устройство.
На этом, думаю, этот краткий туториал можно закончить. В будущем скорее всего напишу подобный туториал по портированию и разработке на iOS.
Опыт разработки аркады под Android на С++ и Qt
Космос сам себя не наложит
Предпосылки
Я, как и многие программисты, выбрал эту профессию, потому что в детстве играл в компьютерные игры и мечтал их разрабатывать. Как только я научился более-менее писать код, который может компилироваться без синтаксических ошибок, я, конечно, стал делать всякие глупые игры, которые показывал всем друзьям и знакомым. Но время шло, и оно заставило заниматься совершенно другими вещами, работать над проектами, которые, мягко говоря, серьезней, чем игры. И так продолжалось последние несколько лет. А изначальные желания никуда не делись, исчезло только свободное время.
Давно хотел сделать какой-нибудь проект под Android, а, как известно, основная масса проектов разрабатывается на Android SDK и Java, а NDK рекомендуют использовать только в “критичных по скорости” местах и не делать на нем все целиком.
Но кому нужны все эти рекомендации и правила, когда есть Qt? Java я не знаю в той степени, которую считаю достаточной для качественной разработки игры, и изучать мне ее не хотелось, зато у меня имеются в запасе знания C++. После нескольких тестовых проектов на Qt под Android я понял, что на нем вполне можно разработать полноценное приложение, да еще и перенести его на другие платформы. Так же, посмотрев видео Shia LaBeouf — Just Do it, стало понятно, что я обречен это сделать.
Итак, я хочу рассказать про опыт разработки игры под Android на Qt 5.5.1 и С++.
Внезапно, захотелось сделать игру про нечто, падающее в пещеру, контуры которой меняются со временем. Первоначально предполагалось сделать двухмерную игру с графикой в рисованном стиле. В дальнейшем все перетекло в трехмерную игру с видом сверху. Был написан генератор пещеры, который позволял создавать слои с контурами. Как рассчитывать столкновения с стенами пещеры и как превратить их в трехмерную модель? Можно было долго думать и выдумать что-нибудь невероятно классное, но я пошел обходным путем и сделал воксельную геометрию мира. Расчет столкновений и вывод на экран стали заметно проще, но ценой того, что игра стала похожа на майнкрафт. Я не растерялся и сделал её еще больше на него похожей, добавив модель персонажа из него же. Так и сформировался вид и концепция игры.
Первая версия генератора пещеры (архивное фото)
Приступая к разработке игры, я не ставил себе цель заработать на ней, как многие, а хотел просто начать свой проект и довести его до конца. Поэтому игра должна быть бесплатная (кто у меня ее купит?), но все-таки с минимальным количеством рекламы.
Графика
Средства
Для реализации игры я выбрал QOpenGLWindow, а пользовательский интерфейс пришлось велосипедить самому.
Обновление кадров было реализовано по сигналу frameSwapped(), который генерируется после swapBuffers. Использование этого сигнала позволяет достичь большей плавности смены кадров, чем при использовании таймеров.
Для расчета анимации мне требовалось посчитать время кадра. Для этого я использовал сначала QTime, что было плохой идеей, так как этот класс считает немонотонное время, а на мобильном устройстве часто происходит корректировка времени, что приводило к попаданию в прошлое или будущее, в зависимости от ухода часов на устройстве. Также разрешение изменения этого класса ограничивается миллисекундами, что недостаточно для плавной анимации при нестабильном фпс.
Поразмыслив и обратившись к документации, я решил использовать класс QElapsedTimer, который старается использовать монотонное время и имеет разрешение до наносекунд.
Текстуры и интерфейс
Для первых версий и отладки текстуры были позаимствованы временно из майнкрафта, как и какой-то скин персонажа. Первая версия интерфейса представляла собой серые квадратные кнопки и была сделана за вечер, а переработка заняла целый месяц.
В качестве дизайнера был выбрал мой друг. Плюсами такого выбора является то, что этому дизайнеру можно доверять, а минусами — то, что он не является дизайнером — он автомеханик.
В дальнейшем мы нарисовали оригинальные текстуры для нескольких уровней и сделали текстуры персонажей.
Процесс рисования “красивого” интерфейса и персонажей оказался довольно длительным. Пока дизайнер пытался выдавить из себя нового персонажа или кнопку, мне ничего не оставалось делать, кроме как продолжать оптимизировать код.
Текстура уровня представляет собой большой атлас всех блоков и вмещает в себя 32 куба со стороной 16 пикселей. При таком подходе при рисовании слоев не требуется постоянно переустанавливать текущую текстуру, а можно рисовать весь уровень, используя вершинные буферы за несколько вызовов.
Проблема возникла в крайних пикселях блоков, которые являются смежными с другими блоками. При округлении текстурных координат стали появляться артефакты в виде полосок на краях блоков. Эту проблему я решил путем добавления каждому блоку окантовки шириной в один пиксель, дублирующую пиксель края блока. Такой своеобразный CLAMP_TO_EDGE.
К сожалению, при таком подходе я не смог использовать mipmap для уровня, т.к. текстурные координаты в вершинном буфере должны учитывать это смещение на один пиксель, а при создании текстуры уменьшенной детализации это смещение становится меньше, и мне бы пришлось использовать различную геометрию уровня в зависимости от степени детализации. Я решил с этим не заморачиваться, т.к. сама текстура уровня всего 256х256 пикселей, и особого выигрыша в производительности билинейная фильтрация не принесла бы, а принесла бы лишь дополнительные сложности в реализации.
Еще хотел заметить, что хотя блоков и всего 32, но в свойствах уровня я задал возможность расставлять блоки повернутыми на 90, 180 и 270 градусов, а также анимацию переключения между текстурой блока, что позволило разнообразить визуальную составляющую игры. Хотя, анимацию я применил только на одном из уровней для создания эффекта вращения вентиляторов.
Шейдеры
В Qt имеются удобные классы для работы с шейдерами. Я использовал QOpenGLShaderProgram. Этот класс позволяет добавлять вершинные и фрагментные шейдеры, компилировать их, линковать, устанавливать uniform и attrubute. Сам по себе класс является просто оберткой над множеством вызовов OpenGL и, соответственно, не является полноценным объектом, в том понимании, что работу класса можно нарушить, используя вызовы GL напрямую между вызовами этого класса.
Удобно то, что класс автоматически добавляет define таким образом, что шейдер ES компилируется нормально и на десктопе и на мобильном устройстве. Это относится в первую очередь к спецификаторам точности, которые на десктопе превращаются в ничто.
Мне пришлось написать отдельные шейдеры для игрового мира, включающие освещение и анимацию некоторых блоков, шейдер для персонажа и шейдеры интерфейса.
Бар хп\щит
Этот бар я решил реализовать шейдером, сначала мне это показалось очень странной идеей, но в конце концов я ее принял как неизбежное и реализовал таким способом:
Итог всего этого — если вы планируете использовать шейдеры в мобильной игре, проверяйте их на самых распространенных моделях графических ускорителей. Если шейдер компилируется и работает у вас на компьютере, это еще не означает, что он будет работать на телефоне вашего соседа. Новый Vulkan API должен решить проблему с различными компиляторами шейдеров и привнеси порядок в этот безумный мир, но это дело будущего, а сегодня имеем то, что имеем.
Звуки
Поиск
Звуки — это вообще отдельная песня. Их можно записать самому, что довольно трудоемко и требует наличия нормального микрофона и слуха (не наш случай). А можно найти желанные звуки в интернете.
Искать звуки желательно с лицензией Creative Commons 0, дабы не указывать авторство для каждого звука, коих может быть несколько десятков. Может показаться, что найти нормальный free звук довольно тяжело, и оно так и есть. Проблема не в том, что их мало, напротив, — их очень много, большинство из которых ужасны. Поиск звука — процесс, в котором надо переслушать очень-очень много звуков и выбрать из них самые подходящие.
Средства
В Qt для вывода звуков существуют классы QSound, QSoundEffect, QAudioOutput и QMediaPlayer. В первых версиях я использовал QSoundEffect для вывода эффектов и QMediaPlayer для вывода звуков. Но, как оказалось, все они не подходят.
Все эти недостатки привели к тому, что после добавления звуков в игру появились ощутимые проседания FPS при воспроизведении звуков и музыки.
Решением стал отказ от этих классов и использованием для звуков библиотеки SFML. Очень простая и легковесная библиотека, похожая на SDL. Удобные классы для работы с графикой, звуком, устройствами ввода. Эта библиотека не умеет работать с mp3 (лицензия, все дела), но зато умеет многое другое. Я использовал для эффектов и музыки формат ogg.
Вывод по звукам
Для использовании в приложении, где звуки являются чем-то необязательным, Qt-шные родные классы подходят. Для разработки игр — совсем нет. Лучше и проще использовать SFML.
Реклама в приложении
Для рекламы я использовал уже готовую реализацию AdMob под Qt — QtAdMob.
Сперва был добавлен только один маленький баннер в меню, но в дальнейшем образовалось межэкранное объявление.
Занятно, что межэкранное объявление, находясь даже в загруженном состоянии, появляется с некоторой задержкой. То есть появилась необходимость блокирования пользовательского интерфейса в момент появления рекламы и восстановление после ее закрытия. При этом, библиотека не позволяла отловить моменты, когда объявление показано и закрыто. Данный функционал библиотеки я допилил в версию под Android. Версию под ios трогать пока не стал, за неимением возможности проверить работоспособность.
Аналитика и статистика
Выкладывая первую версию на Play Market, я понадеялся на статистику в консоли разработчика. Но, как оказалось, статистика активных пользователей завязана на Google Analytics и не работает, пока в приложении не включишь трекер аналитики. А та статистика, что доступна, приходит с задержкой более суток и рассчитывается по тихоокеанскому времени. Такое положение дел не позволяет понять, как же твои действия влияют на скачивания. Поэтому я дополнил класс activity из QtAdMob, который наследуется от QtActivity функциями инициализации аналитики и функциями отправки событий игры. Примеры кода не привожу, т.к. все прекрасно описано в документации.
В события я вынес нажатие всех кнопок интерфейса, возникновение некоторых игровых ситуаций, открытия и разблокировки персонажей с уровнями.
Благодаря сбору всей этой статистики я могу сидеть за ноутбуком и наблюдать в реальном времени, как в Бразилии кто-то запустил игру, не смог пройти первую миссию, вышел и, вероятно, удалил игру.
Еще, если верить статистике,- мы сейчас чемпионы по нашей игре.
Про Google Play
Консоль разработчика сама по себе довольно удобный инструмент, но функционал статистики и рекламы завязан на другие аккаунты.
Чтобы полноценно разрабатывать приложение самому, необходимо как минимум иметь аккаунты AdWords, AdSense, AdMob, Google Analytics. При этом между ними устанавливается связь. Все эти аккаунты — отдельные продукты Google и имеют различную техническую поддержку и настройки. Также стоит заметить, что аккаунт AdMob требует наличия аккаунтов AdWords и AdSense. При этом все эти аккаунты могут быть привязаны в единственном экземпляре к основному аккаунту Gmail. Но, как показала практика, во всем этом можно запутаться с самого начала, потому что ты открываешь один сервис, он тебе предлагает создать новый аккаунт в другом, тот в третьем и так далее.
Я каким-то магическим образом так, что сотрудник техподдержки не смог объяснить произошедшее, создал 2 аккаунта AdWords и привязал их к одной почте, при этом привязав один аккаунт к консоли разработчика, а другой к AdMob (об этом я не знал).
На один аккаунт я закинул 500р, чтобы проверить рекламную кампанию. В попытках разобраться с этим и следуя советам техподдержки, я перенес один из аккаунтов на “левую” почту и закрыл сам себе доступ к нему. Все это привело сначала к неработоспособности обоих аккаунтов с моей почты, затем, при повторных отключениях и подключениях самого себя, работоспособность вернулась. Но, как выяснилось, перестал работать AdMob. Так как AdMob мне был важнее тех 500р, пришлось провести всю эту процедуру заново, попутно молясь о том, чтобы я не потерял доступ вообще ко всему, вернуть работу AdMob. И конечно, те 500р остались висеть на не подключенном аккаунте.
Так что, аккуратнее с этим.
Перевод
В игре
Игровое меню мы перевели на 2 языка — русский и английский. Выбор языка игры осуществляется по системной локали. Если в системе русский язык — то игры на русском, во всех остальных случаях — на английском.
Для осуществления переводов текстовой информации в Qt существует встроенный механизм, приводящийся в исполнения классом
Все строки, которые необходимо перевести, передаются в функцию QObject::tr(), для классов, не являющихся наследниками QObject можно использовать функцию QApplication::translate и для строк, объявленных в массивах макросы QT_TRANSLATE_NOOP, QT_TR_NOOP.
Но это только полдела. Необходимо создать сами переводы, что производится программами lupdate и lrelease. Первая собирает информацию из исходного кода, содержащего эти функции и макросы, и создает Xml файл с информацией для перевода.
Вторая собирает из xml файла бинарный файл qm, который загружается непосредственно в QTranslator.
Мы использовали в качестве переводимых строк что-то вроде тегов, которые затем переводили на английский и русский. Например, “#GameOverText” переводится в “Игра закончена”. Сделано было так, чтобы не было необходимости менять исходный код, чтобы что-то по-другому написать, а затем еще и менять все переводы, т.к. для lupdate это уже другая строчка.
На маркете
В Google Play мы пошли по самому простому пути: написали текст на русском — закинули в гугл-переводчик — перевели на английский, подкорректировали. А затем английский текст перевели на самые распространенные языки тем же самым гугл-переводчиком. Забавно, что один из вариантов описания содержал фразу “Окунись в подземелье с головой”, которая, пройдя весь этот пусть переводов на китайском, означала “Прыжки в пещере на голове”. Мы так и оставили, потому что раз они нам на АлиЭксперессе перлы выдают, так и мы не будем отставать.
Заключение и планы
В заключение хочу сказать, что процесс разработки этой игры был и является одним из самых интересных занятий, принес нам огромное удовольствие и опыт, которым я скромно делюсь в этой статье. Разработка велась в свободное время, после работы и ночью, с августа этого года. Потрачены деньги были только на аккаунт разработчика и пару тысяч на рекламу, так что я не расстроюсь, если нам эта игра принесет чуть менее, чем ничего.
Дальнейшие планы зависят от того, как люди будут реагировать на наше творение. Судя по отзывам, довольно неплохо, но судя по скачиваниям и удалениям, хочется сходить за веревкой в ближайший магазин хозтоваров. Вероятно, игра получилась довольно сложная, и у нас явный недостаток рекламной деятельности
Мы планируем перенести игру под ios, но этому мешает отсутствие яблочной техники и 100$ в год, а так же пугает перспектива общения на эльфийском Objective C.
Я надеюсь, что это не последняя наша игра, есть множество новых идей, которые я буду стараться воплотить в жизнь, учитывая полученный опыт. Эта игра — первый блин, комом он или нет — судить не мне.
Предвосхищаю комментарии по поводу того, что это можно было сделать проще и быстрее, используя готовые движки, привлекая дизайнеров и издателей. Отвечу на это, что мы желали пройти путь джедаев-разработчиков с начала и до конца, своими силами, дабы окунуться в это с головой.