Как сделать игру на j2me
Просто о сложном: Как создаются игры для мобильных телефонов J2ME? Часть 1. Программист
С вопросом, вынесенным в заголовок публикации, редакция MForum.ru обратилась к специалистам компании Media Mobile. Читайте увлекательный рассказ о том, «как это делается» и что нужно знать тому, кто собирается заняться разработкой игр для мобильников.
Хотя простенькую игрушку для своего мобильного может написать едва ли не любой программист, для создания и продвижения полноценной игры для мобильного устройства, телефона, смартфона или КПК требуется целая команда:
В двух статьях, которые MForum предлагает вашему вниманию, мы остановимся на работе программиста и художников.
Что же нужно знать и уметь, чтобы начать писать приложения для мобильных устройств? Прежде всего, отметим, что в мире для программирования мобильных устройств чаще всего используется так называемая платформа Java, точнее ее версия специально для мобильных устройств Java 2 Micro Edition (сокращенно J2ME). Особенность этой платформы в том, что она обеспечивает, до определенной степени, так наываемую «переносимость приложений» между мобильными устройствами, отличающимися аппаратной и программной начинкой. Разработала эту платформу компания Sun. Почему Java называют платформой, а не языком программирования? Потому, что выполняя Java-программу, мобильное устройство сначала компилирует исходный текст программы в промежуточный код, его еще называют байт-кодом. Этот код, по задумке разработчиков, является платформо-независимым, т.е. его должно быть способно исполнить любое устройство, поддерживающее Java, выполняя закодированные команды с помощью интерпретатора Java. J2ME позволяет использовать концепцию платформы Java для портативных устройств, т.е. написанная для одного устройства программа, в теории должна годиться и для множества других устройств, где также реализована поддержка J2ME.
Для работы в каких устройствах разработана J2ME? Как правило, это мобильные телефоны, смартфоны и КПК, т.е. устройства на базе 16-ти или 32-разрядных микропроцессоров, объем памяти которых составляет не менее 160 Кб. Устройства должны соответствовать конфигурации Connected Limited Device Configuration (CLDC), подразумевающей сохранение таких концепций Java, как переносимость кода в любое время и в любое место, гибкость размещения, безопасную работу в сети и устойчивость кода. Необходимой составляющей J2ME CDLC является облегченная Java Virtual Machine(JVM), называемая K Virtual Machine (KVM). KVM разработана для ограниченных по ресурсам сетевых устройств, имеющих небольшой объем памяти.
Программировать можно вручную, например, в обычном блокноте или в отладчике, но для удобства программистов созданы и успешно применяются так называемые IDE (интегрированная среда разработки), специальные инструменты, в которых писать исходный код гораздо удобнее. На данный момент таких продуктов достаточно много, но самые известные NetBeans, IDEA, Eclipse. Каждая имеет свои достоинства и недостатки, о которых узнаешь в процессе работы.
Программисту под J2ME следует помнить, что в его распоряжении весьма ограниченные «аппаратные» ресурсы, так что остро стоит проблема оптимизации программного кода, в основном, приходится оптимизировать расход памяти под загружаемые ресурсы (особенно картинки). Но и исполняемый код может занимать слишком много места. Для «тяжелых случаев», когда требуется «ужать» чересчур большой jar-файл с кодом программы, используются (еще одно жаргонное слово, не пугайтесь!) «обфускаторы» (ProGuard – самый известный), они позволяют значительно уменьшить размер jar-файла. В некоторых случаях помогает более сильное архивирование содержимого jar-файла с исправлением jad-файла.
Раз уж мы заговорили о средах разработки, можно упомянуть, что тестеры для проверки работоспособности приложений зачастую используют не сами устройства, а эмуляторы соответствующих моделей телефонов. Такие эмуляторы обычно выпускает производитель телефонов. Увы, как правило, работают эмуляторы не совсем так, как работали бы реальные мобильные устройства, например, если приложение работает на эмуляторе, то не факт, что оно запустится на реальном телефоне, и наоборот. На сайтах для разработчиков ПО, можно найти не только эмуляторы, но также спецификацию для мобильных устройств и многое другое.
Вот список ресурсов, которые можно сравнить с «настольной книгой» для разработчика программ на J2ME.
Для российских разработчиков ресурсов крайне мало. Отметим тематические форумы:
У вас есть вопросы к авторам материала по теме «программирование на J2ME»? Спрашивайте в форуме под статьей, а мы попробуем получить ответы у специалистов компании MediaMobile.
Грязные трюки мобильной разработки от J2ME до Android
Сколько помню разработку игр для мобилок, всегда приходилось изобретать какие-то ухищрения, чтобы все достойно работало. Сталкивались с этим 15 лет назад, когда писали игры еще под черно-белые телефоны, сталкиваемся и сейчас. Уверен, что огромный набор подобных трюков существует в разработке игр для десктопов и, тем более, консолей. Но я занимаюсь именно мобилками, поэтому речь пойдет о них.
Самый грязный трюк в разработке под J2ME – поставить внутрь основного цикла игры один общий try-catch.
В результате любой exception перехватывается внутри цикла. Кадр обрабатывается не до конца, но игра не падает — как ни в чем не бывало начинает обсчитываться следующий кадр. Никаких вылетов.
Побочный эффект – зависание игры, если проблема совсем серьезная и возникает на каждом кадре.
Каюсь, один раз пришлось воспользоваться этим методом. Как у всех бывает, сроки поджимали, а баг отказывался находиться.
Трюк, к которому приходилось прибегать практически в каждом проекте – это вызов двух апдейтов логики на одну отрисовку.
Обновления объектов в зависимости от времени кадра мы старались не использовать, так как операции с флотами отнимали много процессорного времени. Поэтому в тот момент, когда сложность логики и количество объектов в кадре вырастали так, что телефон не справлялся, мы запускали два апдйта подряд. Чаще всего это происходило еще до финальной балансировки игры, так что ни на что особо не влияло.
Почему в таких случаях просто не менять баланс, увеличив расстояния, преодолеваемые объектами за кадр? В первую очередь, наверное, из-за коллизии. Для перемещений объектов на большие дистанции пришлось бы писать более сложную логику коллизий, что сказалось бы на производительности. Также логика при движении на большие расстояния иногда давала сбои, и ее пришлось бы усложнять. Ну и в целом, отрисовка занимала гораздо больше времени, чем обработка логики даже в двойном объеме, так что это было проще всего.
Еще одна проблема, с которой приходилось сталкиваться на J2ME, – размер памяти. Причем как оперативной памяти, так и поставки самого билда. Экспериментальным путем было установлено, что достаточно много можно сэкономить, уменьшив количество классов. Как итог, вся игровая логика лежала в одном классе. Все данные были разложены по массивам. В одном из них лежал тип объекта, в другом – тип его логики, в третьем – стэйт логики, в четвертом и пятом – X и Y координаты и т.д. В комплекте шел цикл с большим свитчем по типу объекта, который все это крутил. Никаких динамических выделений и удалений, меньше промахов по кэшу. Работало достаточно шустро. Еще пару классов для меню, спрайтов, тайлового бэкграунда, основного цикла игры. В результате вся игра занимает меньше десяти java-классов. К счастью, ни один мой знакомый «правильный» Java-разработчик, никогда этот код не видел.
В ранних версиях BREW напрочь отсутствовало API для работы с экраном напрямую. А те функции для отрисовки, которые предоставляла система, были очень медленными. Пришлось найти буфер экрана самим. Для этого мы залили весь экран красным цветом, создали пустой спрайт (или как он там у них назывался) и от его адреса сканировали память в обе стороны. Перемещались на количество байт немного меньшее, чем площадь экрана. Если находили похожее сочетание, заливали экран другими цветами и при помощи пары вычислений находили формат пикселей, начало буфера экрана и есть ли отступ после каждой строки. Все занимало меньше секунды, игрок не успевал ничего заметить. Ясное дело, что обновление всего этого процесса на экран мы не включали.
iOS (WoT Blitz)
Самое жесткое, с чем пришлось столкнуться в iOS – это необходимость расчистки памяти во время запуска игры. В силу некоторых обстоятельств мы не стали использовать для всех аллокаций свой пул памяти с кастомными аллокаторами. Но наш расход памяти временами подбирался к отметке в 300 мб, что не очень хорошо сказывалось на стабильности приложения на слабых девайсах. Настоящие проблемы начались с выходом iOS 7 или 8. Ось стала иногда «ошибаться» и закрывать Blitz в моменты пиковой нагрузки на память, хотя было видно, что остаются висеть другие, менее приоритетные приложения (скайп или почтовый клиент). После дополнительного исследования мы выяснили, что iOS очень не любит выделения большого количества памяти за один тик. Но если выделять память постепенно, то можно перевалить далеко за наши лимиты без опасения быть закрытым.
Перераспределять выделение памяти на проекте, в который уже играют сотни тысяч игроков, долго и очень опасно. Поэтому мы приняли немного иное решение. На старте игры мы постепенно, кусками по 10 мб, выделяем память до объема, необходимого игре при пике нагрузки. А потом сразу всю ее и очищаем. Занимает это все меньше секунды. А в логе видно, как ось закрывает другие приложения. Таким вот хитрым способом мы исправили падения игры при пиковой нагрузке на память.
Одним из серьезных недостатков мобильных GPU является медленная отрисовка полупрозрачной геометрии. А в игре позарез нужны кусты и деревья. И как можно больше. Дело осложнялось и тем, что у нас есть снайперский режим, в котором игрок наблюдает все происходящее прямо из прицела танка, в хорошем приближении. Временами филлрейт в кустах и деревьях переваливал за 10 экранов полупрозрачной геометрии.
Для кустов решение было достаточно простым, и придумали его даже не программисты, а художники. Мы ввели ближний лод, который включался практически вплотную к кусту и состоял из одного билборда, плоскости всегда повернутой к игроку. Это дало возможность относительно безболезненно засесть в кустах и даже выцеливать вражеские танки.
С деревьями дело оказалось немного сложнее, так как они могут быть повалены на землю в любом направлении. Для них мы создали специальный шейдер, который включался, когда игрок находился очень близко к дереву. Этот шейдер-садовник обрезал все лишние ветки дерева, оставляя только три ближайшие к камере. Из-за того, что ближние ветки заслоняют практически весь обзор, игрок не замечает отсутствие остальных. А вот GPU очень даже замечает.
Я бы не сказал, что данные решения полностью избавили нас от проблем, но они однозначно позволили добавлять на карту хоть какую-то растительность в приемлемом количестве.
С той же проблемой в снайперском режиме мы столкнулись при создании эффектов. Снайперский режим плюс какие-то партикловые эффекты вблизи камеры – и счетчик FPS гарантированно замрет на отметке 10 (меньше просто не позволит движок). Решение было сходное с кустами, хоть технически далось намного сложнее. Мы ввели уровни детализации для частиц. И на самом ближнем лоде избавились от всего лишнего (например, выстрел выглядит как просто вспышка). В результате при максимальном приближении остаются только самые необходимые эффекты. Как не парадоксально, но наш дальний лод эффектов более детализирован, чем ближний.
Интересная история вышла с сервисом регистрации пользователей. Он был написан под старшего брата и без зазрений совести отправлял куски JavaScript в надежде, что клиент это все запустит, а уже этот JavaScript сформирует следующий http-запрос. Оказалось, мобильный web view для этих целей не очень подходит. В нашем случае его нужно делать скрытым, а на внутренних тестовых сервисах он спрашивал у пользователя подтверждение на подключение. Вдобавок это все необходимо было крутить в отдельном потоке. Времени было мало, а заказать переделку сервиса регистрации в требуемые сроки – практически нереально. И нам пришлось на своей стороне парсить приходящие от сервера скрипты, формировать на их основании следующие запросы, отправлять в сервис. Позже было пару фиксов, которые позволили немного стандартизировать этот процесс. Звучит странно, но до сих пор работает.
Android (WoT Blitz)
Работая над Android-версией нам пришлось искать много нетривиальных решений, но вряд ли они достойны статьи. Есть одна действительно забавная штука, которую нам пришлось применить для проведения тестов производительности. Дело в том, что в процессе боя, или нескольких боев, многие Android-устройства успевают нагреться, частота процессора автоматически снижается. Что ведет к понижению FPS. А результаты ежедневных тестов производительности нам очень хотелось видеть более-менее стабильными. После исследования ситуации мы пришли к выводу, что после каждого теста необходимо перезагружать устройство. Телефон успевает остыть и одуматься, а мы получаем достаточно предсказуемые результаты. Это никоим образом не отменяет плейтесты, на которых QA проверяет играбельность и качество сборок, но дает возможность заметить какие-то изменения в производительности устройства и принять меры.
А еще у нас есть свой скайп-бот, который собирает билды, обновляет сервера, следит за состоянием транка и юнит тестов, и назначает программистов на ревью кода. Но это уже совсем другая история.
Если у вас есть какие-то вопросы, либо вы готовы поделиться своими мобильными лайфхаками – пишите комментарии, обсудим.
Hello World
Я решил создать первый урок по языку J2ME, на нём написаны все приложения на телефоны с Java.
Я раньше здесь был под ником Misha, выложил здесь 1 статью по vb6, но мой аккаунт теперь не существует.
Итак начнём создание привет мира:
1)скачиваем этот архив, распаковываем и устанавливаем.
2)скачиваем, распаковываем, устанавливаем.
3)и опять скачиваем, распаковываем и устанавливаем.
2. Я сейчас буду показывать как делать проект в компьютерной среде, но потом выложу как работать с мобильной. Заходим в папку, где установлена последняя программа (например «C:WTK2.5.2»), открываем папку BIN, находим программу ktoolbar.exe и запускаем (можете поставить ярлык на неё, это и есть та самая среда программирования!)
полюбовавшись окном нажимаем «New Project», делаем как у меня:
нажимаем «Create Project», появляется большое окно, кликаем слева «Required», опять делаем как у меня:
Остальное пока не буду объяснять, нажимаем «ок» и видим такое окно:
Дальше сохраняем этот файл, переходим обратно в среду программирования (WTK), и нажимаем «Build», компилятор напишет, если есть ошибки, сверьтесь с моим кодом или скачайте исходник (rar):
4. открываем адрес, который написал компилятор, и там будет готовое приложение! Его можете переносить в телефон, это думаю вы сами разберётесь)
в этом окне нажмите Enter, и ваше первое приложение запустится!
оно пока только выводит «Hello world!», но этого для начала достаточно.
И не забывайте соблюдать регистр букв!
Пишите в комментариях если есть вопросы.
P.S. зацените моё приложение на этом языке (в архиве rar):
там, конечно много ошибок, и много не доработано, но я над ним работаю сейчас. Приложение мультискринное, но картинки у меня делятся по размеру экрана (например фон раб. стола), я засунул картинки 128х160, чтобы пошло у всех, картинки растягиваются + меньший размер будет
Чукченька, уроки пишут, пишут, а не создают.
Самое интересное происходит при запуске приложений, и вот тут пользователям дозволено выбрать как параметры экрана, так и его ориентацию, а также размеры шрифтов, их цвет и прозрачность.
Что касается управления, то оно редактируемое. Виртуальные кнопки можно перемещать по экрану, масштабировать или вовсе спрятать с дисплея. Причём существует дополнительная настройка, позволяющая скрывать только какие-то отдельные кнопки, а не всю клавиатуру целиком. К редактированию, кстати, у меня есть претензия: если в некоторых игрушках редактор работает хорошо, а результат изменений видно сразу, то в других, к примеру, в Doom RPG, для того, чтобы увидеть результат изменения, приходится сначала нажать на соответствующий пункт меню настроек (завершение редактирования), а затем ещё и тапнуть по экрану. Нужно ли писать, что результат таких манипуляций с клавишами может быть непредсказуем? В версии 1.2.9 приложение имело только индивидуальные настройки для каждой Java-программы, но в 1.3.0, как и обещал автор, появились шаблоны, что значительно упростило настройку клавиатуры в проблемных J2ME. По сути, пользователь теперь просто заходит в игру или программу, в которой корректно видны изменения, а затем сохраняет раскладку и использует её везде, где это возможно.
Примеры запущенных игр:
Другой момент: иногда удобнее использовать такую клавиатуру, которая схожа по расположению кнопок с реальными геймпадами.
То есть хочется увидеть комфортные стики, D-pad и дополнительные кнопочки, но в этом случае стоит прибегнуть к помощи сторонней виртуальной клавиатуры. Неплохим примером такой «клавы» служит софт GameKeyboard:
Настройки у GameKeyboard довольно гибкие, другое дело, что для некоторых игр, скорее всего, придётся менять назначение виртуальных кнопок. Я же рассмотрю настройку на примере игры Doom RPG.
Итак, в GameKeyboard правильнее всего будет выбрать клавиатуру, состоящую из клавиши D-pad (крестовина) и шести режимных кнопок, примерно как на скриншоте ниже.
Всё остальное можно убрать с экрана, либо добавить кнопки на своё усмотрение. В любом случае, предлагаемого мной набора будет вполне достаточно для комфортного прохождения. Действия, которые стоит прежде всего назначить на кнопки:
3. Клавиша 9, которая отвечает за пропуск хода. В Doom RPG иногда бывает полезно стоять на месте, чтобы соперник сам проявил инициативу и вышел на удобную для игрока позицию.
Для создания макроса нужно знать, какая кнопка за что отвечает и какое цифровое обозначение у этой кнопки. Пытаясь найти макрос для софт-клавиш, я набрёл на эту картинку:
Проблема в том, что в моём случае эти макросы не сработали то ли из-за игр, которые были написаны под определённые модели телефонов, то ли по каким-то другим причинам. Нажатие на кнопки, на которые были назначены макросы, ни к чему не приводило. Именно в Doom RPG войти в меню можно и без софт-клавиш, но открыть быстро карту уровня уже не получится. Впрочем, я ведь планировал играть не только в Doom.
Вот и всё! Полноценная удобная клавиатура, в которой нет ничего лишнего, для Doom RPG готова. На усмотрение пользователя остаётся то, какая именно виртуальная кнопка будет отвечать за различные действия. Осталось только в настройках J2ME Loader скрыть стандартную клавиатуру, чтобы она не мешалась, а вызвать или убрать GameKeyboard можно нажатием на физическую кнопку увеличения громкости. Созданная мной раскладка идеально подошла не только для всей серии Doom RPG (сюда ещё отношу Orcs & Elves и Wolfenstein RPG), но и ещё как минимум для одной моей любимой игрушки под названием Stranded. Для других игр могут потребоваться иные или дополнительные кнопки (например, для мобильной версии Bioshock нужна клавиша «0» (ноль), без которой не подобрать предмет), но принцип работы GameKeyboard + всегда и везде одинаков.
Такой аналог клавиатуры, как GamePad, является бесплатным, и у него аккуратнее сделаны кнопочки, но на этом его преимущества перед GameKeyboard + заканчиваются. В функциональном плане один из героев сегодняшнего обзора куда предпочтительнее, несмотря на его низкую оценку в маркете. Подозреваю, что некоторые пользователи просто не разобрались, что да как настраивается, но, правда, и разработчик мог бы не забрасывать и улучшить своё творение, сделав управление более удобным.
Почти во всех найденных играх пригодится виртуальная клавиатура, так как J2ME игры и программы обычно не оптимизированы под сенсорное управление, но есть и исключения, разумеется. Одним из таких исключений является специальная версия Wolfenstein RPG Touch, в которой после запуска в J2ME Loader управление осуществляется путём нажатий на экран без использования дополнительных клавиатур.
Рассмотрю, пожалуй, вопрос о том, какое разрешение лучше выставить и какую ориентацию экрана использовать. Разрешение обычно указывается в названии файлов, и, выставляя параметры, нужно отталкиваться именно от этих цифр, особо не пытаясь понизить или повысить значения. Почему? Просто нередко результат может оказаться таким:
Иногда же получается на удивление достойный результат, как в случае с Flexis Extreme. Возможно, игра на самом деле рассчитана на большее разрешение, чем это заявлено, либо я о чём-то не знаю.
Для вертикальной ориентации подходят значения 240*320, а для горизонтальной лучше переключиться на 320*240 (то есть поменять цифры местами), что J2ME Loader позволяет сделать.
Игры с большим разрешением смотрятся более достойно, как в примере с Assassin’s Creed: Brotherhood (360*640), которая, к тому же, имеет отличное сенсорное управление.
Ещё с помощью браузеров вполне можно сёрфить по всемирной паутине. Правда, это сомнительное удовольствие, хотя Opera mini тоже пробуждает ностальгию.
Со звуком же в играх обычно всё в порядке, в том числе и с музыкой, да и виброотклик присутствует. Java J2ME Runner воспроизведение звуковых файлов даётся куда сложнее.
Во всех протестированных мной играх работали сохранения, что позволяет продолжить прохождение в любой момент после выхода из игрушек. Без этого, на мой взгляд, любые эмуляторы потеряли бы свою привлекательность. При этом в любых программах и играх через настройки эмулятора можно сбросить все сохранённые данные.
Удобно также то, что ярлыки любых игр и софтинок можно вынести на рабочий стол, для их быстрого включения.
На этом всё. Надеюсь, что мой рассказ, как и тот софт, о котором я в нём написал, поможет вам заново открыть огромное количество J2ME игр и программ. А быть может, мир Java для вас окажется чем-то новым, неизведанным? Если так, то тем даже интереснее.