В последнее время мобильные устройства активно развиваются. Увеличиваются мощности процессоров, улучшаются экраны. Все чаще они используются в качестве игровой платформы. Series 60 Developer Platform предоставляет программисту широкий спектр возможностей (API), которые могут использоваться для написания игр и делают операционную систему более гибкой. Однако небольшое разрешение экрана и неудобная клавиатура требуют определенного подхода к разработке игр.
Этот документ ориентирован на разработчиков, начинающих писать игры для Series 60 Developer Platform v1.0 и 2.0. Подразумевается, что вы имеете представление о программировании в C++ для Symbian OS, включая Active Objects, CleanupStack и идиомах. Приветствуются опыт разработки игр для других платформ.
В этой части Вы познакомитесь с особенностями платформы. Во второй части будет описана типовая структура игрового приложения для Series 60. В последующих частях будут рассмотрены различные API, которые могут Вам пригодится при разработке игр. В частности будет рассмотрено использование таймера, клавиатуры, графики, звука и сети. Будут приведены небольшие примеры.
К сожалению, архитектура мобильных устройств, используемых в качестве игровых платформ, включая смартфоны, позволяет прерывать выполнение любой программы и сообщать пользователю о различных системных событиях, например о входящем телефонном звонке. Приложение должно корректно обрабатывать такие ситуации. Кроме того, в распоряжении приложения находится достаточно ограниченный набор системных ресурсов (объем памяти, заряд батареи).
Большинство системных сообщений показывают пользователю свой диалог, называемыйglobal note. Этот диалог имеет более высокий приоритет, чем приложения. Поэтому он может всплыть во время выполнения вашей игровой программы.
Одним из самых распространенных системных событий является входящий звонок. Если Вам позвонили во время игры, она будет прервана и переведена на задний план, активизируется телефонное приложение. Все системные события имеют общую черту, используя которую можно отслеживать приложением и корректно обрабатывать системные события. Когда наступает системное событие, выполняемое приложение теряет фокус. Это приводит к вызову метода класса пользовательского интерфейса CAknAppUI::HandleForegroundEventL. Переопределив этот метод, вы можете перевести свою игру в режим паузы.
Ваша программа должна бережно относится к заряду батареи. Если запущенное приложение некоторое время не получает команд от пользователя, оно должно быть переведено в спящий режим. Это позволит минимизировать расход энергии. Если приложение продолжает работать, находясь на заднем плане, устройство не может перейти в спящий режим. Поэтому, когда игра переходит в режим паузы, все циклы должны быть блокированы, таймеры остановлены. Можно создать собственный таймаут для перевода игры в ее спящий режим. Например, если пользователь вызвал меню и долгое время ничего не делает, игру можно смело переводить в спящий режим. Приложение может получать сообщения от системного таймера о том что пользователь не проявлял активности заданный период времени. Для реализации этого подхода нужно использовать метод RTimer::Inactivity, описанный в e32std.h.
В работающих на аккумуляторах устройствах приложения должны быть готовы неожиданному завершению. Аккумулятор может разрядиться или пользователь может извлечь его из устройства. Это должно учитываться в приложениях, работающих с данными. Периодически необходимо выполнять автоматическое сохранение данных, чтобы пользователь после перезагрузки устройства смог восстановить их. Плюс ко всему, приложение должно быть готово к тому, что данные могут испортиться и будет необходимо загрузить одно из сохранений.
Не существует стандарта на размер экрана телефона. Разработчик должен иметь в виду, что его приложение будут запускать на устройствах с различным разрешением экрана. Ваше приложение должно адаптироваться под различные устройства. Не используйте жестко кодированную систему координат. Для того чтобы получить текущее разрешение экрана используйте CEikAppUi::ApplicationRect() и метод CWsScreenDevice::GetDefaultScreenSizeAndRotation.
Малый объем памяти не единственное отличие смартфонов от настольных компьютеров. Процессоры смартфонов намного слабее, лишь немногие устройства оснащаются графическими ускорителями (в момент написания статьи таких устройств еще не было). Также практически отсутствуют устройства с математическим сопроцессором, поэтому все сложные расчеты необходимо проводить в целых числах.
Экраны имеют ограниченную палитру и разрешение. Клавиатура неудобна, содержит мало клавиш, игровое назначение которых меняется от устройства к устройству, поэтому в игре пользователь должен иметь возможность самостоятельно настроить управление. Все эти ограничения сильно сказываются на подходе к написанию игр.
Управление памятью играет очень важную роль для мобильных устройств. Это касается как памяти, доступной приложению во время выполнения, так и размера самого приложения. Большинство Symbian OS и Series 60 устройств имеют не более 8 MB RAM памяти. Помимо RAM, смартфоны оснащаются и ROM памятью, где размещается предустановленный софт, данные установленных приложений, и записываемые системные файлы. Есть еще дополнительные съемные карты памяти, например flash карты (CF) или мультимедиа карты (MMC).
Главное правило использования RAM - вся занимаемая память должна быть как можно быстрее освобождена. Symbian OS эмулятор оснащен модулем, проверяющим память. Он добавляется по умолчанию ко всем приложениям, использующим графический интерфейс (GUI). Если приложение выйдет за рамки допустимой памяти, модуль сгенерирует исключительную ситуацию. Это позволяет избавится от многих ошибок уже на ранней стадии проектирования приложения. На целевом устройстве, ядро следит за памятью, используемой потоками, и автоматически очищает ее при завершении потока.
В Symbian OS каждый поток имеет собственный стек, который не может увеличиваться после запуска потока. По умолчанию размер стека равен 8 kB, поэтому использовать его нужно с большой осторожностью. Объем доступной стеку памяти в среде эмулятора и на реальном устройстве отличается. Размер стека на эмуляторе не фиксирован, поскольку в основе лежит использование windows стека. Это одна из причин по которой написанные Вами приложения должны обязательно пройти тестирование на реальном устройстве. Причем это тестирование нужно проводить уже на ранних стадиях разработки приложения. Причиной большинства ошибок, связанных с переполнением стека, является использование дескрипторов стека и рекурсий. Если обойтись без рекурсии никак нельзя, постарайтесь свести к минимуму число передаваемых параметров и локальных переменных.
Как правило, в играх, большую долю памяти занимают различные изображения. Наиболее действенным методом уменьшения размера изображений без изменения их количества является уменьшение числа цветов в палитре изображений. Symbian OS поддерживает 24-битные изображения, которые могут содержать 16777216 цветов, но фактически число доступных цветов ограничено возможностями экрана целевого устройства. Не стоит конвертировать изображения, ориентируясь на максимальные возможности экрана. Для небольших изображений, не содержащих мелких деталей можно без потери качества уменьшить число цветов палитры. Например, большинство спрайтов используют 8-битные изображения, а для файлов масок достаточно и одного бита.
Как и изображение, любые данные, используемые в игре (звук, музыка, видео) должны занимать как можно меньше места.
Перевод:aRix.
