J2me

❯ Предисловие

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

Но помимо десктопных и консольных игр, существуют и мобильные игры, которые в последние 5 лет вплотную приблизились к уровню AAA на консолях (привет порту GRID, AC Mirage, RE4 на мобилки). А ведь ещё 15-20 лет назад мы играли на кнопочных телефонах с небольшими дисплейчиками, которые в свое время подарили нам множество эмоций и кайфа от прохождения этих самых игр, несмотря на простенькую графику, не особо комплексный геймплей и относительно простой левел-дизайн. Продвинутые мобильные геймеры играли уже на Symbian-смартфонах и WinMobile-коммуникаторах (да, в какой-то момент времени, устройства на WM были весьма перспективными), но чаще всего — на Java-телефонах Nokia, Sony Ericsson, Siemens и, конечно-же, Samsung с LG!

По правде сказать, игры на смартфонах — тема отдельная, например на Symbian был полноценный телефон-игровая консоль Nokia N-Gage, о которой я писал отдельный материал, а о разработке игры под Windows Mobile я относительно недавно написал отдельную статью. У смартфонов обычно было несколько больше ресурсов: шустрее процессор, значительно больше памяти доступной игре, а также возможность запуска нативного кода, но и игры для них было разрабатывать значительно сложнее.

Зато о том, как работали игры на Java-телефонах информации практически нет и этот недостаток нужно исправлять, ведь это была одна из первых попыток унифицировать формат приложений на телефонах вне зависимости от архитектуры их процессоров и ОС на борту. Недавно я писал о том как работали 3D-игры на Java-телефонах, но там затрагивалась только 3D-часть без 2D, звука, обработки ввода и иных модулей, без которых игра не может работать!

❯ Каким был телефон?

В середине 2000-х годов, обычно телефон представлял из себя девайс в корпусе моноблок/раскладушка/слайдер и «флип» с весьма большим цветным дисплеем, одним/двумя (привет Motorola E398) динамиками и несколькими аппаратными кнопками. В зависимости от ценового сегмента устройства, обычно менялся корпус, разрешение и размер дисплея, а также материалы, из которого был изготовлен девайс. При этом у многих больших вендоров были собственные программные платформы — у Nokia это был S40, у Sony Ericsson своя, у Samsung и LG тоже свои.

В среднем, характеристики телефонов были следующими:

• Процессор: ARMv4/ARMv5 на частоте ~100-200МГц. Есть исключения — Siemens E-Gold работал на базе архитектуры C166, а платформа Motorola работала на 66МГц (что и объясняет небольшую тормознутось).

• ОЗУ: ~8Мб SDRAM. Эта память распределялась под все нужды системы, в том числе и обработку GSM, Java и пользовательский интерфейс. Java-приложениям было доступно ~1Мб ОЗУ.

• Постоянная память: в среднем ~10-30Мб, плюс возможность расширения памяти за счет MicroSD или MS Pro Duo (Sony Ericsson).

Казалось бы, не густо. На самом деле вполне достаточно, учитывая все ограничения телефонов тех лет. Но почему именно Java?

Ещё в начале нулевых, когда прогресс развития телефонов шёл семимильными шагами, перед разработчиками телефонов встал вопрос, какой формат для программ выбрать, дабы привлечь как можно больше разработчиков на рынок мобильных приложений. Очевидно, что нативные программы на C/C++ точно не подойдут (разные архитектуры, большие отличия в платформах), поэтому нужна была виртуальная машина с собственным байткодом. Вариантов было несколько: Mophun, некая корейская виртуальная машина (точного названия, увы, не помню и инфы очень мало) и, конечно-же, Java с JVM. Со временем именно J2ME стала стандартом благодаря оптимальной скорости работы, хорошему и простому API и низкому порогу входа.

❯ Какие API существовали?

Несмотря на то, что игры под кнопочные телефоны писались на Java, набор API и поддерживаемых пакетов отличался от обычной JVM на ПК, которую использует, например, Minecraft. Всего существует три профиля — J2SE (Android и ПК), J2EE (серверы и энтерпрайз) и J2ME (встраиваемая электроника и телефоны). Однако сам по себе J2ME делится ещё на два стандарта — CLDC/CDC (набор поддерживаемых фишек языком — например, ранние телефоны не поддерживали float) и MIDP (набор поддерживаемых телефоном фишек — работа с дисплеем, проигрывание звуков, доступ в сеть и обработка ввода — всё это часть MIDP). За всё время существования было две версии MIDP — 1.0, которая была весьма ограничена в возможностях (например, нельзя было развернуть игру на весь экран) и использовалась с 2001 по ~2003 год и MIDP 2.0, которая использовалась вплоть до кончины J2ME.

Теоретически, появление J2ME должно было стандартизировать игры на телефонах разных производителей… но был нюанс — ведь функционал телефонов рос как на дрожжах, разрешение дисплеев тоже, у телефонов появлялась собственная память и файловая система, возможность подключения к интернету и Bluetooth и появился целых ворох API…

Несмотря на то, что игры по большей части были одинаковыми (или почти одинаковыми) на всех кнопочных телефонах, тем не менее набор поддерживаемых API каждым устройством значительно отличался. Вероятно, вы помните как многие игры подразделялись не только на версии для разных разрешений дисплея, но и на версии для каждого производителя отдельно: Nokia, SE, Samsung и т. п. Для реализации каких-то особых фишек (например, быстрая отрисовка изображений с регулируемой прозрачностью) требовалось использовать пакеты, неподдерживаемые в базовом профиле MIDP. И подобные пакеты делились на два типа — JSR и Vendor-specific пакеты.

JSR — это расширения-спецификации (то есть просто описание классов без какого либо кода), которые вносились в специальную базу Java community process и формально стандартизировались среди всех нормальных производителей телефонов. Среди таких JSR есть и поддержка 3D-графики (JSR184 — M3G, JSR239 — OpenGLES Bindings for J2ME), и доступа к файловой системе устройства (JSR75), и возможность использования Bluetooth для реализации мультиплеера (JSR82). Говоря простыми словами, это опциональные «фишки», которые могли быть доступны на каких-то телефонах, а на каких-то не поддерживались и соответственно игры, которые их используют, в большинстве случаев просто вылетают с ошибкой (однако особенно «умные» игры используют рефлексию и определяют поддерживается ли та или иная функция с помощью метода Class.forName).

Vendor-specific пакеты обеспечивали очень крутой функционал, характерный не просто одному производителю телефонов, а зачастую даже одной линейке телефонов на определенной платформе. На SE такие пакеты практически не использовались (кроме, конечно, Mascot Capsule), а вот на Nokia постоянно (Nokia UI, Nokia S40 API), позволяя на изначально «слабеньких» s40-телефонах рисовать в буфер дисплея напрямую, а также отрисовывать треугольники, рисовать полупрозрачные картинки и выполнять некоторые другие операции, недоступные на других телефонах. У Samsung, же, например, в свое время была поддержка MMF-звуков в мобильных играх, что в начале и середине 2000х годов было просто нереально крутым, даже несмотря на другие ограничения корейских телефонов.

❯ Графика

Возможности по отрисовке графики на кнопочных телефонах были не сказать что сильно широкие, но тем не менее позволяли легко реализовать графику уровня SNES или даже PlayStation 1. Например, в отличии от современных смартфонов, мы не могли использовать шейдеры, умножить спрайт на цвет (дабы придать ему другой оттенок) и даже использовать аффинные трансформации (поворот, скейлинг) — исключительно полупрозрачные спрайты даже без возможности плавно «растворить» спрайт путем изменения его альфы! Поэтому многие разработчики шли на «хак» и предварительно рисовали в редакторе 8-16 положений одного спрайтов с разным углом поворота, дабы потом выбрать нужный в зависимости от физического угла поворота в градусах!

Для графики использовался пакет javax.microedition.lcdui, в котором были классы для построения нативного интерфейса (выглядело так себе на большинстве телефонов), а также механизм фреймов (Form, Canvas).

Для игр же предлагался Canvas и GameCanvas, которые позволяли развернуть поверхность для рисования на весь экран и предлагали инстанс объекта Graphics, который сразу предоставлял механизм двойной буферизации! В свою очередь, Graphics предоставлял методы для отрисовки спрайтов (Image и drawRGB для «сырых» картинок не в нативном-формате, может быть медленно), примитивов (линии, прямоугольники, овалы), текста и… всё! Например, картинку можно было нарисовать вот так:

getGraphics().drawImage(img, 0, 0, Graphics.LEFT | Graphics.TOP);

При этом с шрифтами вопрос был отдельный: у каждого устройства был свой набор поддерживаемых шрифтов и свои фишки, о которых клиентская программа даже могла и незнать: например поздние телефоны поддерживали сглаживание шрифтов (что дико лагало на устройствах типа Nokia Asha), но что самое забавное — шрифты не могли быть произвольного размера, лишь 3х типов (один из них — моноширинный) и 3х размеров (маленький, средний, большой). Немудрено, что многие вендоры реализовывали свои рендереры битмапных шрифтов, которые точно будут нужного разработчику размера.

Но откуда же грузить картинки? Для этого, в Java был использован встроенный механизм открытия ресурсов из JAR: никакого кэша, никаких OBB, все нужные данные сразу в пакете с игрой. Да, это накладывало некоторые ограничения: например на телефонах Samsung долгое время было ограничение ~250Кб на приложение, зато было просто и портативно. Выглядело это вот так:

InputStreamReader reader = new InputStreamReader(getClass().getResourceAsStream('/img.png");

Или в случае картинок так:

Image image = Image.createImage("/img.png");

Всё очень легко и понятно, согласитесь?

❯ А звук?

Помните диалог «включить звук» при запуске почти каждой игры? Конечно же помимо графической части, в каждой игре должен быть и звук! И с его реализацией были свои нюансы: ведь в MIDP 1.0 звук поддерживался только с помощью Vendor-specific API (то есть его вообще могло и не быть, зато на телефонах Samsung поддерживался MMF, что, как я уже и говорил раннее, было очень круто).

MIDP 2.0 уже стандартизировал нормальный протокол для общения с мультимедийной подсистемой устройства с помощью пакета javax.microedition.media, в котором было три класса: Player (собственно, сам звук или музыка), PlayerListener (прослушиватель событий от плеера) и Control для управления различными параметрами воспроизведения (громкость, тональность и, вероятно, прочие расширения от производителей типа эквалайзера).

Конечно-же набор поддерживаемых форматов был невелик, но почти все устройства хотя-бы поддерживали wav (для коротких эффектов) и midi (для музыки), на ранних телефонах ни о каком mp3 и речи не шло (именно в Java-приложениях). При этом на некоторых телефонах, насколько мне известно, не было возможности воспроизводить одновременно звуки и музыку из-за отсутствия программного или аппаратного микшера. Интерфейс для воспроизведения звуков был один: мы создаём Player с помощью метода createPlayer, которому передаём адрес нужного ресурса и проигрываем его. Это мог быть как и трек на удаленном сервере (стриминг поддерживался не везде), так и в ресурсах программы:

InputStream is = getClass().getResourceAsStream("/music.wav");
Player player = Manager.createPlayer(is, "audio/x-wav");

player.prefetch();
player.start();

Так почему-же в большинстве игр на телефонах тех лет были midi-мелодии вместо wav? Всё дело в размере и ресурсах: во первых, midi-мелодия на пару минут может весит пару десятков килобайт. Помните «бумер.mid», «europa.mid» и другие известные тогда файлы? Эти треки весили совсем немного благодаря тому, что в отличии от оцифрованных сэмплов (т.е аналоговых данных с микрофона), вес которых зависит от разрешения, наличие стерео и частоты дискретизации, midi оперировали лишь наборами инструментов: что где и когда нужно проиграть. Во вторых, в Java-телефонах был ограниченный объем памяти, а heap мог быть менее 1 мегабайта, поэтому загрузка даже небольшого wav-файла могло быть крайне проблематичным на таком устройстве. Поэтому выкручивались как могли!

Но в целом, аудио-возможности были хорошими. Java-игры славились весьма неплохим звуковым сопровождением для уровня телефонов, явно не хуже GBA.

❯ Мультиплеер! Давай про мультиплеер!

Вероятно многие читатели помнят, что локальный мультиплеер в Java-играх был зачастую Must-have: возможность игры с друзьями по «локалке» собирала все лавочки и подоконники в школах на переменах в жёстких баталиях на бипланах, или, например, в матчах CS для Java!

И для реализации мультиплеера у Java было довольно немало возможностей: в первую очередь, это наличие полноценных TCP-сокетов и Http-подключений с помощью класса Connection. Да, были некоторые ограничения (например на Nokia нельзя было установить TCP-соединение на порт 80 в обход встроенного клиента Http), но тем не менее даже через GPRS можно было создать с кем-то матч и попробовать поиграть, а чуть позже, к 2009 году, в РФ уже появился +- стабильный 3G и можно было поиграть в игры с достаточно быстрым и стабильным интернетом! Но интернет был дорогой, да и смысл ради сессионного матча подключаться к интернету, когда есть Bluetooth?

Появление Bluetooth в телефонах значительно расширяло возможности телефонов в обмене информации на короткой дистанции. Конечно и до этого уже был ИК-порт, который позволял передавать файлы на относительно низкой скорости, но у него была не самая большая стабильность, да и далеко не все можно было успеть перекинуть за время школьной переменной (и не все давали свой телефон «на урок»). Появление OBEX и возможности передачи файлов друг-другу через беспроводной канал дало возможность скидывать музыку и игры прямо на уроке, что было очень круто и позволило некоторым школьникам с флэшкой или телефоном с большим объемом встроенной памяти даже торговать контентом и скидывать, например, эротику за пирожок или школьную пиццу (я застал когда она уже стоила около 10 рублей — весьма немало!). Особо красноречивые ребята умудрялись уболтать друзей себе скидывать весь контент, что был у них на телефонах и становились центром внимания с новым крутым треком — я и сам в некоторой степени таким был (у меня была флэшка на 2 гигабайта!).

Но помимо возможности обмена файлами, Bluetooth также поддерживал некоторые профили: например, подключение к наушникам или протокол L2CAP/RFCOMM для установки соединения клиент-сервер между устройствами, которое и использовалось в Java-играх. Именно оно позволяло сделать один телефон сервером (хостом), а другому — клиентом, который подключается к серверу и они инициируют сессию игры!

❯ Проблемы мультиплатформенности

На бумаге все было хорошо: Java-машина была стандартизированной, поддерживаемые профили тоже и по идее игры и программы должны без проблем запускаться на большинстве Java-телефонов. Но как-бы не так: проблемы с кроссплатформенностью имели место быть. Начиная от упомянутых выше Vendor-specific API и версиями MIDP, заканчивая… как это ни странно, разрешениями экрана.

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

Во времена Java-телефонов, зависимость от разрешения дисплея была критичной и поэтому игры для «не того» разрешения либо выходили за экран, либо наоборот — выглядели слишком маленькими и игрались в небольшом окошке. Многие вероятно вспомнят как устанавливая игру для малого разрешения дисплея, можно было заметить как шлейфом уезжают спрайты за виртуальный экран и остаются на белом фоне…

Небольшие проблемы были и с обработкой ввода. И если резистивные тачскрины поддерживались еще в MIDP 2.0 с помощью обработки определенных событий, то с мультитачем (во времена Asha и поздних телефонов Samsung) было уже сложнее. Другой вопрос что даже коды кнопок почему-то не унифицировали, из-за чего возникало деление на Samsung, Sony Ericsson и Nokia: разработчики J2ME предполагали что смартфоны будут в разных форм-факторах и предоставили лишь механизм для унификации «игровых» кнопок. Таким образом, некоторые игры, собранные под телефоны конкретного производителя могли не реагировать на нажатие кнопок клавиатуры из-за отличающихся кодов клавиш.

❯ Заключение

Друзья! Вы, вероятно, думаете что если телефоны с поддержкой J2ME больше не производятся, значит и коммьюнити уже «всё»? Как-бы не так: после моих статей мне продолжают писать читатели и спрашивать детали реализации тех или иных техник или игровых механик! Да, энтузиастов мало, но они есть, как и у ретро-компьютеров: например, спектрума, или консолей типа NES… А значит наше дело будет жить и Java-телефоны с их играми останутся в наших сердцах, а Java-телефоны останутся на скрижалях истории! Берегите своих кнопочных красавцев и восстанавливайте по возможности, благо пока-что даже корпуса на популярные модели кнопочных телефонов найти относительно легко.

Надеюсь, сегодняшний материал вам был интересен, писал его специально так, чтобы было понятно даже тем читателям, которые не пишут код или знакомы с программированием поверхностно. Подписывайтесь на мой Telegram-канал, куда я публикую различные мысли и советы по ремонту и программированию под гаджеты прошлых лет, подсъемы с новых видосов и всегда актуальные ссылки на новые статьи!

Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!

С тех пор без сделан гениальный фикс на сервере по авторизации и все дорогие нам клиенты "поднялись", словно Феникс из пепла, и готовы послать звонкие "Здрасьте!" между QIP на компе и Jimm на Sony Ericsson k750i без правок в самих клиентах!

Стоит ли оживлять археологические находки? Да ради бога, если вам нравится этот винтажный вкус. Напоминаю, это не только забава, но и милая экономия для тех, кто до сих пор платит за каждую SMS как за капучино в центре Парижа. Попробуйте и убедитесь: Аська на Nokia — это не просто реликт прошлого, это декларация ностальгического стиля!

Серия GoF, как и производитель игр FishLabs, запомнились многим геймерам тогдашних мобильных платформ. Те, у кого телефон мог потянуть эти игры (а это были Nokia 60 серии, SE K750, K800) не могли не получить удовольствие, впервые запустив на своём телефоне какое-либо детище от этой компании. Обусловлено было это следующим: производителей мобильных 3D игр под телефоны было немного (т.к. производство игр под JSR-184 требовало немалых умений со стороны программистов). А FishLabs ещё и освоили API "Mascot Capsule", которое позволяло ускорять и качественно воспроизводить модели на телефонах Sony Ericsson. Тем самым они заняли непревзойдённую нишу, можно сказать, лучших мобильных 3D разработчиков.
Механика самой игры не нова - она копирует игру Elite, что вышла аж в 1984 году и была портирована под различные платформы тех лет (Commodore 64, ZX Spectrum и др.). Для нас, java-геймеров, не имевших какой-либо альтернативы, игра была своего рода "Mass Effect" но только под мобильные платформы. Геймплей и открытый мир игры позволяет многое. Что уж говорить - обзор этой игры уже был на pikabu, да и лучше всего самим установить KEmulator и переиграть её. К тому же, когда закрывалась компания FishLabs, они разрешили бесплатно загрузить свои детища (но только как потребителю, модифицировать их всё равно не одобряется). Хотя мы, как мододелы (команда JMODS) любили их модифицировать - добавлять новые модели, менять текстуры и т.д. и даже создавали специальный софт, который мог перекодировать эти текстуры под игру (привет Виктору Мельнику "aNNiMON").

2. Серия игр Gangstar 3 : Miami Vindication (а также его предки Gangstar 2, Gangstar 1). Gameloft. 2010 и ранее.

Gangstar был своего рода адаптацией известной в то время ПК-игры GTA San Andreas и Vice City, однако, геймплеем скорее напоминал GTA 1 и GTA 2). Задачи все те же: устраивать перестрелки, угонять автомобили, выполнять задания. Можно устраивать погромы, разборки с копами, проходить сюжетку - в общем всё как в полномасштабной версии (за тем лишь исключением, что графика - своего рода плоское 2D). Кстати говоря, коды и читы тоже были, набирались просто циферками и мы ими делились друг с другом.
Игра была издана компанией Gameloft - одним из крупнейших в то время издателей под мобильные платформы. Игры этой компании можно было купить в журналах, как и других крупных издателей (таких как EA, NetLizard и др.). Также часто имела место "предустановка" демо-версий игр от Gameloft, защищённых ключом (впоследствии нужно было выкупить игру у компании, отправив SMS и получив ответку с кодом для разблокировки).
Интересный факт: игры компании Gameloft имели разблокировку по своим алгоритмам, а вот многие игры инди-издателей имели такой способ блокировки: игра сама себе генерировала ключ, после чего он записывался в RMS (память игры), а затем отправлялся на короткий номер, с которого в ответ приходила SMS с тем же самым ключом (т.е. игра как бы изначально уже имела этот ключ, но он был скрыт в блоке памяти). На эмуляторе этот ключ можно узнать, открыв RMS, а вот телефоны в то время отправленные SMS не сохраняли (хотя были и такие модели - на них можно было игры и не покупать - ставилась симка с нулевым балансом, а потом код можно было подсмотреть в "не отправленных" сообщениях).

3. Might & Magic 2 Mobile. Gameloft, Ubisoft. 2007

О мобильных RPG можно рассказывать много. Общие принципы подобных игр всегда одинаковы и не изменились ещё с самых первых игровых консолей. Данная же игра занимала первые места в топах J2ME ввиду своей проработки и качества, а так же известного среди компьютерных геймеров бренда - всё потому, что разработкой занималась компания Ubisoft Mobile, которая выкупила права на разработку мобильных игр данной серии. Игра цепляет, прежде всего, качеством графики и звука, своей динамичностью и живописностью представленных пейзажей. Также она содержит интересные головоломки, перемежающиеся с традиционным RPG-геймплеем. Но игра проходится как сюжетка один раз, "на одном дыхании". Желания потом к ней возвращаться не возникает.
Кстати, игры от Gameloft, EA и прочих крупных издателей редко модифицировались, причины этому следующие - жесткая обфускация всех игр (т.е. шифровка кода), так как игры были жестко коммерческие, да и в целом линейно вшитый в код сюжет, в который вносить правки смысла не было.

4. Worms 2011 Armageddon. EA и Team 17. 2011 год. Были и ранее.

Червяки. Что тут сказать. Эта игра была выпущена практически на всех возможных мобильных платформах и консолях. Среди J2ME игр её выделяло следующее: популярность среди школьников, соответственно первые и самые дорогие места на тетрадках (там были своего рода VIP-места, игры на которых стоили в 2-3 раза дороже остальных). Помешательство на серии игр Worms в те времена достигало небывалых масштабов (вспоминается тот же клон ВК - игра "Вормикс"). Проработанные боты и большой арсенал позволяли часами рубиться в игру, пока не сядет телефон. Игра - чистая коммерция, выпущена компанией EA в 2011 и была одним из последних крупных проектов под j2me (далее разработчики начали перебираться на Android). А мододелы же либо ушли в свои проекты, либо просто потихоньку разбежались кто куда.

5. Micro Counter Strike. M3GWorks. 2008.

Невероятно! Micro.. Counter Strike! Модная тогда "контра" прямо на телефоне. Не играл в неё только ленивый. Ну или тот, у кого на телефоне не было поддержки JSR-184 :D. В самой игре можно было бегать, стрелять по боту или по другу (была даже криво реализованная поддержка игры по Bluetooth).
Пару слов о разработчике: M3GWorks, наравне с FishLabs, были пионерами строения 3D игр на телефоны. Только специализировались они на 3D шутерах от первого лица, и работали, как ни странно, только на M3G. Их движок был задействован во многих играх компании ("Quake Plus 3D", "Break Shock"). Также движок неплохо поддавался моддингу. Меняли текстуры, делали моды а-ля "CS 1.6 mobile". Особо проскилованные мододелы умудрялись менять даже карты (нужно было создать карту в 3D редакторе, например, Blender 3D, затем подогнать и экспортировать с помощью специального плагина).
Пару слов о игровом движке: написан он был столь криво, что работал на разных телефонах совершенно непредсказуемо. По сути он не имел ограничения FPS - его ограничивал сам телефон, в попытках вычисления графики (обычно он варьировался от 3 до 12 в зависимости от модели телефона). В движке нельзя поворачивать камеру вверх-вниз (вертеть головой). Поэтому уровни были преимущественно в одной плоскости, а там где были перепады (например, Quake Plus) был реализован топорный автоприцел на соперника по высоте. А при включении игры по Bluetooth скорость ещё и проседала вдвое. Но, тем не менее, альтернатив не было - играли и в ус не дули. За счет реализации только на M3G игра шла на достаточно широком объеме телефонов, однако, на некоторых шла настолько топорно, что когда её продавали в тетрадке, она хоть и была в "VIP-зоне", была сноска мол пойдет нормально только на единичных моделях, потом не жалуйтесь).

Дальше немного отклонимся от вершины топа и вспомним несколько игр, которые почему-то запомнились именно мне, хотя наверное, многие были с ними знакомы.

6. Gothic III The Beginning. Handy-Games GmbH и JoWood. 2008.

Вот эта игра очень мне запомнилась. Gothic 3 Mobile - хотя других частей под телефон не было. Хоть в то время я и не имел доступа к ПК и был мало знаком с сеттингом Готики, игра всё равно оказалась для меня (как неподготовленного игрока) весьма неплоха. Она является типичной RPG, как и уже упомянутая Might & Magic. Однако, выполнена она достаточно атмосферно, можно даже сказать "лампово". Особо примечательны следующие моменты: специально проработанный сюжет, пересекающийся с таковым для ПК-версии. Оригинальная музыка Кая Розенкранца также из ПК-версии, переложенная в MIDI-варианте (от этого звучит не менее интересно, к тому же, MIDI-партитуры уже содержат ноты, поэтому можно было наиграть эту музыку на пианино). Графика и RPG часть весьма проработана. Единственный минус - не очень большая длительность - проходится также на одном дыхании.
Также были интересные баги, которыми мы делились в java-журналах типа CheMax и других. Например, если тебя убивал более сильный противник, но при этом успеть открыть хранилище (бочку или сундук), то экран смерти не выводился, но противник "отставал" от тебя и уходил гулять по уровню. После этого можно было прямо из сундука выпить несколько зелий здоровья и убежать с уровня, пока враг возвращается чтобы убить игрока повторно.

7. Gravity Defied. Codebrew Software. 2004

Gravity Defied, она же среди мододелов "GDTR". Игра весьма нехитрая и весит мало. Думаю, видели её так или иначе все, кто сталкивался с платформой. Суть очень проста - нажимая клавиши, маневрируешь по линейному уровню физической связкой из двух колёс, не допуская переворачивания. Модов на неё было очень много, хотя и модифицировать особо нечего - были редакторы уровней (как под ПК, так и на самой java), менялись скины мопеда, ставились картинки на фон или трек. Вот, в принципе, и всё. Модно было выпускать моды типа "2000 треков" или мультиигровки на эту тему. Особо хитрые моды могли занять недели прохождения. Думаю, многие помнят фишку, или баг, когда можно было отъехать задом в начало карты и упасть с обрыва, после чего пролететь под картой и уровень засчитывался, как пройденный. Опытные трекмейкеры ставили до старта высокую стену, на которую невозможно заехать, чтобы избежать такого варианта прохождения.

8. Heroes Lore : Wind of Soltia. Hands-on mobile. 2008.

Игра от Корейцев - известных RPG-мейкеров. Графика простенькая - но мне лично игра запомнилась хорошо проработанной RPG-системой (есть прокачка, бафы, улучшения оружия, крафт и другие черты, присущие качественным RPG). Также у игры был интересный сюжет, который так и остался незаконченным. Особенность сюжета - можно было пройти игру за трёх различных персонажей, при том, в определённом порядке - за первый заход ты "знакомишься" с миром (игра за Ронина), затем показывают его тёмные стороны (игра за Рею) и в конце уже "результирующий" взгляд со стороны (игра за Арамора). При том, события переплетаются между собой. Такая подача в мобильном RPG была весьма новаторской, а потому игра и сыскала популярность.
Кстати говоря, продолжения игры под тем же брендом выпускались и на J2ME, и на консолях того времени, однако, сюжет оригинальной игры так и остался незаконченным, что печально.

9. Серия Bobby Carrot (1,2,3,4,5 части). FDG Soft. 2008

Ещё одна игра от немцев. Игрушка вроде бы детская и весьма нехитрая. Продавалась в тех же тетрадках - задача в оригинальной игре - "собирать морковь" или "класть яйца". Имеется ввиду, что нужно пройти по клеткам головоломки в строго определённом порядке и заполнить при этом все ячейки - а назад ходить нельзя. Поэтому от игрока требуется подобрать такой порядок, чтобы собрать всю морковь и при этом вернуться на выход уровня живым и здоровым (не застрять и не наступить на шипы). Тем не менее, достаточно большой объем по уровням, интересный доп. контент и пасхалки делают игру весьма запоминающейся. К последней части игры был даже создан специальный сайт (Bobby Forever), на котором можно было ввести коды из игры и обменять их на контент-паки (картинки или мелодии). К этой части немцы подошли ответственно.

10. Stranded. Glu Mobile. 2006

На волне популярного в то время сериала LOST компания Glu Mobile (также один из крупнейших в то время издателей игр) решили выпустить свой вариант игры на заданную тему. По сюжету команда оказывается на заброшенном острове. Задача игрока - бегать, выживать, заниматься охотой, крафтом и, наконец, выбраться с проклятого острова. Хоть в игре и отсутствует возможность свободного строительства, но сама система сбора материалов и исследования открытого мира весьма привлекают. Игра порой даже пугает своей мистикой.
У игры есть продолжение - Stranded 2. На тему путешествия во времени. Подача тоже достаточно интересная.

В завершение хочется упомянуть также мобильную хоррор-сцену. Из неё запомнились две игры: Nowhere и серия Darkest Fear.

Nowhere выпущена в 2007 году компанией DeValley. Является образцовым примером мобильного хоррора. - Вот так надо! - сказал бы я, если бы меня спросили о том, как сделать качественный мобильный хоррор в то время. Здесь проработано всё: атмосфера, геймплейная часть, звуковое сопровождение, множество боссов. Игра очень увлекательна, хотя в то время от некоторых моментов действительно бросало в дрожь.
- Надпись на одной из карт "- Назад пути нет.."

Darkest Fear (части 1,2,3) - серия хоррорных головоломок 2006-2008 года. Сами головоломки нехитрые - нужно всего лишь перемещать и расставлять в правильном порядке предметы. Однако, сюжетная подача сделана весьма интересно, по сценарию можно было бы действительно снять неплохой хоррор-фильм. Этим она и запомнилась.

Итак, друзья, вот такой обзорчик вышел на те игры, что больше всего запомнились с мобильной эпохи. А эпоха эта всё дальше остаётся в прошлом, хотя мне есть много, чего о ней рассказать. Надеюсь, кто-нибудь узнал свою любимую игру и обязательно захочет перепройти на эмуляторе.
С вами был Kekovsky и до новых встреч.

С чего все началось

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

Позже я для себя открыл программу MidletPascal, которая позволила некоторые навыки использовать в настоящем программировании игр для j2me телефонов. И тут понеслось..

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

Итерации файл-менеджера, который был чем то вроде псевдо-ос. К последней версии даже замахнулся на создание скрипт-языка, но не осилил парсинг уравнений.

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

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

Убогая физика и отсутствие интерфейса, но на собственном движке. Был доволен как слон.

Случилось так что в одно время я заинтересовался созданием игры на мобильник чуть сложнее чем те угадайки которые я писал ранее.. и так вышло, что попробовать решил перенести майнкрафт в j2me под 2D графику (да, сейчас этих клонов пруд пруди, но мне казалось что я сделаю лучше, что возможно так и вышло)

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

Даже были попытки создать 3D движок, но дальше прототипа дело не зашло.

Однако как бы не было весело делать игру под старые мобильники, мне нужен был опыт в PC, и все же решился попытаться использовать появившийся тогда Unity3d

После десятков попыток создать что либо, у меня вроде вышло сделать копию той игры которую я делал в Delphi на OpenGL, с физикой и графикой стало получше, но ее я все равно не закончил - уровней было всего штук 5, а часть предметов в игре так и не заменил на нормальные вместо болванок.

Один из экспериментов - что то вроде выживания космонавта забытого в космосе. Выжить нужно было в течении 5 минут. На игрока постоянно воздействует нагрев от солнца, протечка кислорода и необходимость в подзарядке.

Об онлайн игре

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

Примитивная стилистика и попытка начать писать сетевой код, который я тогда еще не умел, но очень хотел сделать. Благо к тому времени я мало-мальски познакомился с C# и начал осваивать сетевой код.

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

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

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

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

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

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

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

О веб

Да, с появлением Canvas и HTML5 стало любопытно о том что можно сделать в браузере. Особо ничего не сделал кроме опять же "экспериментального" движка - надстройки над канвас и пару простецких демок на нем. Если интересно, они до сих пор живы, как первая так и вторая.

О настоящем времени

На данный момент я провел еще множество маленьких экспериментов, в которых пытался разобраться в том как оптимизировать игру и упростить себе жизнь. Довольно классным нововведением в Unity конечно стал новый UI который значительно облегчил создание интерфейсов, но это означает что ту же онлайн игру придется переделывать целиком заново, а к такому я пока не готов.

Сейчас же в плане мультиплеера понимаю довольно много, ибо работаю в небольшой компании и разрабатываю/поддерживаю самодельную CRM с множеством сотрудников и тысячами клиентов. Приобрел много навыков связанных с веб, но как по мне для игр этого мало.

The end

Как и писал в первом посте, все эти эксперименты привели к тому что я занимаюсь только экспериментами и на полноценные проекты давит эта вредная привычка.

Надеюсь вам было интересно мое повествование про жопорукого программиста.

P.S: В добавок к танкам

Начал я их уже как пару недель и занимаюсь на выходных, по возможности выкладываю ролики с тем что сделал на Youtube:

Первый ролик: https://youtu.be/UVl4udS7UmI

Второй ролик: https://youtu.be/H2kNM0W9c2A

И спасибо тем кто подписался, рад что вам интересно =)