Представляю вашему вниманию ПК порт мобильных игр Orcs & Elves! Оригинальные игры выходили в середине 2000-х для платформ j2me и BREW. Первая часть так же была выпущена и на Nintendo DS. Порт уже умеет работать с DS версией, но на данный момент, поддержка DS не завершена.
Мой порт использует сильно модифицированный движок id tech 3 как основу для клиента. Логика орков скомпилирована в .qvm/.dll и раскидана по соответствующим папкам
Логика орков взята из гитхаб репо реверс инженеринга BREW версий от George Gorzhiyev, он в скором времени так же выпустит свои нативные порты OE и OE 2
Помимо ванильного пошагового режима, добавлен экспериментальный режим со свободной камерой и ходьбой в двух вариациях;
Возможность настроить размер HUD'а, а так же убрать нижнюю полосу софтбара;
Через консоль, сглаживание через oe_hwFilter 1
Скриншоты:
Первые орки с софтбаром
Без софтбара
Без софтбара, а так же, режим со свободным осмотром камерой
Вторые орки с софтбаром
Без софтбара и со свободным осмотром камеры
Игра хоть и старая и мало кто про неё уже помнит (А кто-то может даже и не знает), но довольно таки интересная, по этому данный шедевр от id Software явно заслуживает внимания.
В следующем посте расскажу про нативный порт второй части для Symbian
Для ЛЛ: в двух словах не описать, длиннопост уж очень большой :)
Сегодня всё чаще можно услышать мысль о том, что раньше мобильные игры были лучше. В какой-то степени это правда: ранние Java-игры отличались отсутствием доната и сервисной модели монетизации, логической завершенностью большинства тайтлов, а также экспериментами с новыми жанрами. И всё это в рамках крайне ограниченных возможностей Java-телефонов. В этой статье я хотел бы рассказать о трудностях мобильной разработки образца 2005 года с конкретными примерами тех или иных решений, так что если вам интересно — добро пожаловать под кат!
Содержание:
Предисловие
Реалии разработки
Как игры работали «изнутри»?
Что стало с J2ME
Заключение
❯ Предисловие
Пожалуй, мобильный гейминг как класс зародился в самом начале двухтысячных годов. В какой-то момент, производители телефонов смекнули, что помимо задач обработки GSM-стека, у чипсета остаётся достаточно процессорного времени для обработки второстепенных задач, благодаря чему в телефонах начал появляться дополнительный функционал: к примеру — игры. И хотя первой мобильной игрой был клон Тетриса в Hagenuk MT-2000 1994 года выпуска, на практике игровые перспективы в телефонах увидели только в 2000 году, когда компания Sun выпустила спецификации стандартов CLDC 1.0 и MIDP 1.0.
Siemens SL45i — один из первых телефонов с поддержкой Java-приложений.
Дело в том, что в те годы телефоны работали на целом зоопарке самого разного железа и операционных систем. За год-два в телефонах одного производителя могло измениться всё: та же Motorola внезапно перешла с кастомной GSM-платформы на базе m68k в StarTAC'ах на стандартный TI HERCROM с ядром ARM7TDMI в телефонах линейки Talkabout, параллельно развивая свою собственную архитектуру M-Core в устройствах для CDMA-сетей. А Siemens, к примеру, использовали процессоры разработки Infineon под названием E-Gold, построенные на собственной архитектуре C166s, которые уже через несколько лет заменили на S-Gold'ы, построенные на ядре ARM926EJ-S. Для решения этой проблемы, компания Sun предложила миниатюрную Java-машину с набором стандартизированных API и свободным SDK, которые в теории позволяли легко разрабатывать программы, не зависящие от конкретного телефона. И имя этой машине — KVM (Key Virtual Machine), а мобильный профиль назвали J2ME (Java 2 MicroEdition).
Сердце Siemens M55 — тот самый процессор Infineon E-Gold
Набор API в первых телефонах с поддержкой Java был небогатым и состоял из CLDC — базовой инфраструктуры языка, и MIDP — набора классов для работы с «железом» устройства. Присутствовали пакеты для работы с дисплеем и создания простенького интерфейса (lcdui), примитивной работы с сетью (microedition.io), а также хранения данных (rms). При этом основная инфраструктура языка во многом была совместима с обычной Java версии 1.3 — то есть были классические потоки, коллекции (Vector, Stack, Hashtable — и это ещё не дженерики), генератор псевдослучайных чисел, исключения и даже минимальная рефлексия (Class.forName и Class.newInstance). Однако у CLDC 1.0 был один неприятный нюанс — он не поддерживал Float вообще ни в каком виде, из-за чего классы при компиляции проходили верификацию и дополнительную оптимизацию специальной утилитой — preverify.
Это весь java.util в CLDC 1.0. Сравните с современной реализацией этого пакета :)
И по правде сказать, этого набора API было слишком мало для разработки хоть сколь либо серьезных приложений и игр. Объём RMS был жёстко ограничен несколькими килобайтами, графическое API не умело рисовать кусочки изображения из атласов и использовать полупрозрачность, а о воспроизведении звука вообще можно было не мечтать. И это было справедливо для моделей 2001 года выпуска, но уже в 2002 начали появляться куда более продвинутые устройства с цветными дисплеями, полифонией и большим объёмом памяти. Каждый производитель начал реализовывать своё собственное API, из-за чего стали плодится отдельные версии приложений адаптированные для разных телефонов — Opera Mini S40 128x128, Gangstar SE 176x220, Prince Of Persia Mot 128x160...
Nokia 3300 2003 года выпуска. Один из первых телефонов с поддержкой Nokia API.
Но MIDP 1.0 был отнюдь не бесполезен как может показаться на первый взгляд. Именно под него разрабатывались первые версии Opera MIni, Jimm и самые первые Java-игры. Клон Pac-Man на SGH C100 как раз один из таких.
Однако уже в 2002 году появилась спецификация MIDP 2.0, которая привносила возможность воспроизведения звуков и музыки, проверки подписи приложений, а также продвинутое API для отрисовки графики и работы с расширениями. Несмотря на готовность спецификации, первые телефоны с поддержкой MIDP 2.0 появились только в 2003 году — это была Nokia 6600, а также Siemens S55/M55. И вот с Siemens'ами была небольшая загвоздка — их реализация MIDP 2.0 была обернута в отдельное Siemens API и не была на 100% совместима с Sun'овской, настоящая поддержка появилась лишь через год — в 2004 году. Остальные же производители продолжали использовать MIDP 1.0, включая Sony Ericsson (T610), Samsung (C100) и модели Nokia на платформе S40.
А уже в 2004 году, J2ME стала по настоящему популярной платформой. Появились сторонние лицензируемые реализации Java-машин и MIDP — Esmertec JBed и Aplix JBlend, на телефонах стала возможной отрисовка 3D-графики в реальном времени благодаря M3G и Mascot Capsule, а также начали появляться первые AA-игры от Gameloft — как, например, тот же самый Asphalt. Sun пошли ещё дальше и умудрились уговорить ARM на реализацию отдельного набора инструкций для ускорения JVM — Jazelle. Это, вероятно, первый и последний пример, когда JIT реализовывается не на уровне VM, а на уровне ISA процессора...
И на первый взгляд может показаться, что у Java банально не было конкурентов, однако это не так. Как раз таки конкурентов у J2ME было сразу три. Первый — это платформа Mophun, которая представляла из себя игровой движок с очень быстрым программным растеризатором 3D-графики и собственным C-подобным скриптовым языком. Заточен он был исключительно под игры и на нём вышло несколько очень крутых, на момент выхода, игр. Например, Lock'n'Load:
Mophun провалился как раз из-за ориентира только на игры. Насколько мне известно, API для других целей там просто не было. Второй платформой была ExEn от французской компании In-Fusio, которая также позволяла писать приложения на Java, но имела больший ориентир на игры. Однако её можно было найти только в французских (Alcatel One Touch, Sagem) и нескольких японских телефонах, а также у неё было жёсткое DRM, что помешало ей стать «народной». Чуть позже, In-Fusio начала предлагать ExEn как один из пакетов для «обычных» JVM, но платформа прекратила существование уже в середине 2000-х...
Alcatel One Touch 535 — один из немногих телефонов с поддержкой ExEn. Давно хочу себе подобный Alcatel поковырять, но почему-то не попадались ни разу.
А третьей платформой был BREW от компании Qualcomm. И по правде сказать, он был куда круче любой JVM — ведь предлагал писать полностью нативные программы на C, используя всю потенциальную мощность устройства. Но Qualcomm не был бы Qualcomm'ом, если бы не ограничил использование BREW только на телефонах с собственными чипсетами и RexOS, а также не отгородил всё отвратительным DRM. Впрочем, это тоже можно простить, ведь Qualcomm уже тогда был доминантном и двигателем прогресса телефонов, поскольку уже в 2004 году разработал и интегрировал собственный 3D-ускоритель. Но это уже совсем другая история...
Сейчас такая графика может показаться смешной, но в те годы видеоускоритель Defender3D творил чудеса. Игра с очень неплохой графикой и в 25-30 FPS на обычном кнопочном телефоне?! Невиданно!
Так что J2ME благодаря усилиям производителей телефонов и самой Sun стала по настоящему народной платформой. SDK был доступен абсолютно бесплатно и для всех, предлагалась отличная документация с множеством примеров программ, а приложения можно было ставить и отлаживать откуда угодно и как угодно, прямо как на Android. И это стало одной из проблем...
❯ Реалии разработки
Как и сейчас, в те годы мобильными играми в основном занимались небольшие команды. Условно был программист, который недавно постиг Java, перейдя на него с Delphi или C++, пару художников, которые рисовали всю графику в игре, а также отдельный звуковик, в задачи которого входило написание midi-музыки и иногда таких же midi-эффектов. Магазинов ассетов и соответственно ассет-флипа как класса ещё не существовало, поэтому всё в игре делали своими руками «как умели». Наверное одним из лучших примеров таких студий будет харьковская NetSoftware, известная своими играми серии «Бункер 3D»:
Что такое ассет-флип?
Сегодня у двух самых популярных движков — Unity и Unreal Engine, есть собственные магазины с ресурсами для игр. В них можно купить как обычные модели, текстуры и саундпаки, так и целые уровни вместе с шаблонами игр. Ассет-флипом называются те игры, которые либо построены на базе популярного шаблона игр (помним бесчисленные низкокачественные шутеры с всякими Ultimate FPS Controller или «симуляторы вождения» на базе Edy's Vehicle Phyiscs?) с минимальными геймплейными изменениями относительно шаблона, либо игры с собственной логикой и геймплеем, которые неизменно используют уже готовые уровни.
Свастику мы осуждаем, а вот авторов из NetSoftware хвалим за крутейший 2.5D-рейкастер, который шустро бегал даже на слабых телефонах и в отличии от оригинального Wolfenstein поддерживал стены под углом, а также объёмные «пропы».
И вот, ребята разработали игру и хотят заработать денюжку на её продаже. Тогда ещё возможности самиздата не было, а также не существовало монетизации за счёт рекламы и донатов (кроме немногочисленных MMORPG), поэтому игры продавались по цене примерно в 3-4$ напрямую, а покупка осуществлялась отправкой СМС на... да вообще любой номер! Магазинов было просто куча, ни о каком едином сторе (кроме Samsung Fun Club, портала Nokia и Sony Ericsson) и речи не было, а каталоги Java-игр можно было найти в женских журналах, в ТВ-рекламе и даже на сайтах ОпСоСов (Оператор Сотовой Связи)! После отправки СМС, пользователь получал ссылку на WAP-сайт, откуда он мог скачать jad-файл игры (дескриптор с описанием приложения), после чего телефон докачивал соответствующий jar. И всё это без скриншотов, без возможности возврата средств, ориентируясь исключительно на обложку игры и известное название...
Насколько мне известно, небольшие команды чаще всего шли к издателям по типу Qplaze, NetLizard (Украина) и Herocraft (Россия), которые и занимались налаживанием контактов с таким ворохом каналов распространения, а также реализацией биллинга с «антипиратской защитой». Дело в том, что помимо «слепой» покупки игры также были популярны Shareware-игры: играешь 90 секунд бесплатно, затем игра просит отправить СМС для получения кода активации и если пользователь соглашается — то получал полную версию игры. И вот тут то модель распространения давала сбой: Java ведь компилируется в байткод, и даже после обфускации его можно превратить в читаемый и относительно собираемый исходный код. Путём простого патчинга байткода биллинга (того самого окошка «оплатите игру") можно было "вылечить игру от жадности" и выложить куда-нибудь на seclub, sefan, spaces или tegos версию с "таблэткой":
А ведь были ещё и телефоны, которые jad-файл могли не только сразу установить, но и скачать в память телефона — причём вместе с jar. И вот тут активизировалось сарафанное радио: один купил игру, скинул другу (нередко за пирожок в столовой, кэшбек же), тот скинул своему другу, а он залил на wap-сайт... короче пиратство было настолько распространено, что я даже в теории не могу предположить сколько там упущенной прибыли :)
STALKER Mobile — одна из самых желанных 3D-игр на телефоны нулевых.
А ещё был хорошо налажен конвейер копирования успешных идей. Однако если сейчас в основном копируются свежие геймплейные идеи гиперказуальных игр, то тогда пытались один в один скопировать целые игровые вселенные. Вспомнить только Gameloft с её AAA-играми по мотивам GTA (Gangstar), Need for Speed (Asphalt) и даже Call of Duty (Modern Combat). В СНГ же такой фирмой была NetLizard, которая в основном делала упор на популярные игровые вселенные и постсоветский колорит (Ликвидатор ЧАЭС — её разработка). Кроме того, не было никаких особых ограничений на распространение эротических и даже порнографических игр — и они свободно распространялись даже в журналах (с особо сочными описаниями)!
На первый взгляд эти тайтлы могут показаться трешачком или славджанком, однако на практике это были вполне годные игры, пусть и с глупым, кликбейтным описанием.
❯ Как это работало?
Однако пожалуй самое интересно это то, как мобильные игры тех лет работали «под капотом». Ведь в отличии от современных устройств, на кнопочных телефонах нельзя было разгуляться с абстракциями, раскидываться аллокациями на куче, и даже использование floating-point арифметики было нежелательным. Более того, многие разработчики намеренно отказывались не только от любых абстракций, но и просто от концепции классов или стандартных паттернов организации сцены/состояний, предпочитая создавать God-объекты для целых игр. В одном классе мог быть код и обработки состояний (меню, игра), и загрузки уровней, и отрисовки, и обработки логики. Нередко отказывались даже от стандартных коллекций типа Vector и структур данных, предпочитая реализовывать статические пулы-массивы с данными для каждого игрового объекта. Как бы это забавно не звучало в контексте Java, но чаще всего использовали процедурный подход программирования:
Это главный класс игры «Ликвидатор ЧАЭС» весом в 56КБ, который сочетает в себе вообще всю логику игры. Как вам такое?
На первый взгляд может показаться, что программисты были просто неопытными и писали «как умели». Однако на практике это была одна из фундаментальных оптимизаций: во первых, статические пулы с примитивными типами данных избегали дорогого боксинга (управляемые контейнеры над примитивными типами. int - Integer, float - Float). Использование структур было не всегда оправданным из-за относительно высокой цены аллокации (а в J2ME они всегда на «куче», в отличии от .NET. Засовывать мелкие объекты в Eden-space те JVM ещё не умели) и примитивности GC. А во вторых, в некоторых JVM верификация почему-то выполнялась не при установке приложения, а при первой загрузке класса ClassLoader'ом. И процесс верификации мог заметно затормозить приложение, при этом съев ещё немного памяти для данных о загруженном классе.
Другое дело — классы из системных пакетов. Они всегда загружены и обычно являются тонкими прослойками к native-реализациям методов.
Ведь когда мы говорим о Java-телефонах, то чаще всего имеем ввиду не топовые Symbian-смартфоны у которых было 2МБ и более хипа, а о бюджетных кнопочных устройствах по типу Nokia 6060 или Samsung C3010, где хипа едва-ли был 1 мегабайт, а порой и вообще ~500КБ. И в это пространство нужно уместить всё: графику, уровни, звуки с музыкой и конечно код игры. Поэтому разработчики и шли на такие ухищрения. Кроме того, как раз тот самый верификатор был занозой в заднице любителям абстракций: даже если движок игры технически позволял использовать Nokia API на S40 телефонах, Sony Ericsson API на SE и обычный MIDP 2.0 на Samsung'ах, Java-машина при установке может просто прервать процесс сообщением «класс не найден»...
Чтобы примерно понимать с каким железом приходилось иметь дело программистам из нулевых, давайте рассмотрим спецификации бюджетного Samsung SGH-E250 образца 2006 года:
Процессор: NXP PNX5230 с одним ядром ARM946E-S, работающим на частоте до 130МГц. В 2007 году уже чаще встречалось более мощное ядро ARM926EJ-S, которое работало на частоте до 208МГц.
Память: 16МБ оперативной, из которых Java-приложениям было доступно около 1.5МБ, а также 32МБ постоянной. Для Jar-приложений было строгое ограничение — 250КБ.
Дисплей: 128x160 TFT-TN, 16-битный.
Поддерживаемые API: JSR75, JSR85, JSR120.
Не то чтобы железо было уж очень слабым, но не стоит забывать о том, что телефоны были многозадачными и под приложения отдавалось отнюдь не всё процессорное время, а итоговая производительность сильно зависела от порта Java-машины на конкретный телефон.
Nokia 6060 — типичный бюджетник, на который ориентировались при разработке игры.
Второй проблемой была графика и разные разрешения экрана. В качестве основного формата изображений, в J2ME был выбран png из-за простоты реализации загрузчика, высокой lossless-компрессии, а также свободности Zlib. Формат png в своей основе подразумевает 32х-битный формат цвета с 4-мя компонентами: R, G, B и A. A — это альфа-канал или степень прозрачности пикселя, и вот с ней у многих телефонов были проблемы. Дело в том что примерно до 2006 года, многие телефоны не умели альфа-блендинг (т.е полноценную полупрозрачность) вообще, из-за чего представляли прозрачность либо как 0 (пиксель прозрачный), либо как 1. Если в игре предполагались полупрозрачные поверхности (например стекла или параллакс-фоны), то для некоторых телефонов их приходилось заменять дизерингом или вообще делать упрощенную, менее красочную версию:
Вам кажется что куб полупрозрачный, однако на практике часть его фрагментов — полностью прозрачные, а часть — нет. Это частый стилистический прием, актуальный как в играх 90-х, так и сейчас.
Вы никогда не задумывались, почему современные 2D-игры не зависят от разрешения экрана и выглядят одинаково сочно как на 4K-дисплее, так и на 720P экране бюджетного смартфона? Секрет прост: современные игры используют в качестве системы координат не пиксели, как это делали многие старые релизы (не только Java, но и консольные/ПК), а метры (сантиметры, что угодно). С развитием мобильных GPU, 2D стало частным случаем 3D и теперь все двухмерные элементы — это просто плоские 3D-треугольники. А поскольку растеризатору совершенно не важно какой треугольник ему «скармливают» и при нанесении текстуры/спрайта он оперирует исключительно алгоритмами фильтрации (которые включают в себя масштабирование) — мы можем видеть идентичную картинку с идентичным уровнем масштабирования на любом устройстве:
Один из моих Just for fun-проектов — игра про оборону от зомби в стиле Crimsonland. Выглядит одинаково как на смартфонах с 720p дисплеями, так и 240p.
На ретро-телефонах всё было по другому. Чаще всего у устройств не было не то что FPU, даже аппаратного деления в процессоре зачастую не было. Поэтому любая floating-point арифметика эмулировалось программно, а умножение/деление были очень дорогими, из-за чего система координат в играх обычно была целочисленной, а результаты любых тригонометрических функций были посчитаны заранее для всех углов поворота объекта. Конечно никто не мешал реализовать масштабирование и поворот (т.е умножение на 2x2 матрицу) на fixed-point арифметике, но учитывая что процессор можно было положить на лопатки несколькими десятками небольших спрайтов, разработчики всегда использовали классический блиттинг — то есть прямое копирование изображений на экран без масштабирования, поворота, блендинга и других операций. Именно поэтому в таких играх чаще всего не было автоматического масштабирования, а каждая версия игры несла в себе свой пак ресурсов:
По возможности многие разработчики старались использовать API от производителей телефонов. Дело в том, что нативное API зачастую предоставляло возможность проигрывать куда более качественную MMF-музыку (Samsung), заметно быстрее отрисовывать 2D-графику (Nokia UI API) и получить доступ к фишкам по типу мультитача и даже звонкам! Например DirectGraphics в Nokia UI API поддерживал поворот на фиксированный угол и возможность «бесплатной» отрисовки изображения в нативном пиксель-формате (RGB565), благодаря чему Nokia UI реализовывали и другие производители — например Sony Ericsson:
Ну и конечно стоит упомянуть 3D на телефонах нулевых, благо там был целый зоопарк различных API. Пожалуй самым первым был легендарный Mascot Capsule, который использовался в телефонах Sony Ericsson и Motorola, и представлял из себя очень быстрый софтварный растеризатор, который позволял выдавать графику уровня PS1. Помимо растеризатора затененных и текстурированных треугольников, Mascot Capsule также предоставлял «собственный» формат текстур (bmp), моделей (mbac), и анимаций (mtrac), математическую библиотеку, а также поддерживал примитивный скиннинг. Однако главной особенностью было то, что в целях экономии памяти, Mascot Capsule не поддерживал Z-буфер и вручную сортировал треугольники по отдаленности к наблюдателю, из-за чего иногда можно было увидеть Z-fighting, характерный для игр с PS1:
V-Rally — одна из игр на движке Abyss Engine от Fishlabs. На нём же потом сделали Galaxy on Fire и Deep3D, и это один из немногих примеров использования абстракций в Java-играх.
Второе API появилось в 2004, называлось M3G (Mobile 3D Graphics) и использовалось практически везде... кроме телефонов Samsung до 2010 года. И вот здесь есть важный момент: во первых, M3G это спецификация и реализаций этого API было много. Референсная, насколько мне известно, была построена на базе OpenGL ES 1.1, в то время как большинство производителей использовали проприетарные реализации на базе кастомных софтрендеров. А во вторых — M3G это не просто растеризатор треугольников, а граф сцены с собственной древовидной структурой объектов. И разработчикам предлагалось строить логику как раз поверх этих самых Node'ов — что идёт вразрез с моими словами о максимальной примитивности и линейности логики игр тех лет. Поэтому большинство разработчиков использовали M3G, если говорить очень условно, как «Unity» тех лет — создавали уровни в 3d Max, загружали их в игру, создавали какие-то объекты и управляли их компонентами (трансформация, материал и т.п.) также, как в Unity:
По уровню графики, M3G позволял добиться довольно неплохих результатов. Ниже игра Rally 3D Nokia, которая по совместительству является Java-портом одноименной игры с Mophun:
Что-то так защемит в груди...
Третьим API был JSR239 — OpenGL ES, которому не суждено было стать популярным на Java-телефонах. Дело в том, что его поддерживали только телефоны Sony Ericsson и только после 2008 года, а также несколько устройств от BlackBerry. Несмотря на то что ES 1.1 Nokia реализовала в своих Symbian-смартфонах ещё в 2006 году (из-за появления устройств с 3D-ускорителями от PowerVR), этот стандарт никогда не был реализован в Java-машине... Зато он оказался реализован в самой первой версии Android, благодаря чему там до сих пор есть пакет javax.microedition.khronos.opengles!
А некоторые разработчики шли во все тяжкие и реализовывали программные 3D-растеризаторы прямо на Java, которые ещё и умудрялись очень шустро работать! Понятное дело что под капотом они были простыми и сильно упирались в филлрейт, однако популярная в своё время игра Left2Die как раз использовала свой собственный программный растеризатор, благодаря чему работала даже на телефонах Samsung:
❯ Судьба J2ME как платформы
До 2010 года, J2ME продолжала оставаться самой популярной программной платформой для телефонов. Её поддержку добавляли и в простые телефоны, и в смартфоны, а сама платформа продолжала обрастать функционалом и новыми пакетами. Sun (уже почти Oracle) вместе с производителями телефонов успела представить третью версию профиля MIDP в 2009 году, и выпустить новую версию SDK, но уже в 2010 году платформа начала стремительно сдавать позиции...
Одна из причин падения J2ME
И этой причиной был Android. Дело в том, что в своё время, ОС от Google умудрилась полностью перевернуть мир смартфонов, представив систему с довольно неплохим и логичным API, современным подходом к разработке приложений и открытостью к производителям смартфонов. И что самое интересное, весь юзерспейс Android'а был написан на Java, что сильно упростило переход уже существующих Java-разработчиков на смартфоны. Были разработаны библиотеки-слои совместимости с MIDP для упрощения портирования, были организованы конкурсы среди разработчиков приложений, а к 2010 году появились первые Android-смартфоны по цене менее 10.000 рублей (~300$), что заметно ударило по популярности обычных Feature-фонов и кнопочных смартфонов. J2ME прожила примерно до 2014 года, пока производители всё ещё предустанавливали её в теперь уже ставшие бюджетными кнопочные телефоны. Большинство разработчиков перешли к разработке для iOS и Android, и лишь Gameloft время от времени радовала нас новыми релизами, пока в 2014 платформа окончательно не умерла...
Затем на место Java-телефонов пришли устройства с KaiOS, которые тоже успели кануть в бытие, а теперь, как бы это забавно не звучало, продвинутые кнопочные телефоны работают на Android. И что самое забавное — в свежих LTE-кнопочниках на чипсетах Unisoc просто нереально крутые ТТХ по сравнению с той же Nokia N73: 64 мегабайта DDR2-оперативной памяти, гигагерцовый ARM-процессор на ядре Cortex-A7, поддержка инструкций NEON... Но никакой возможности запуска сторонних приложений. Это очень грустно.
❯ Заключение
Вот такой была разработка мобильных игр в далёких нулевых годах... От многообразия аппаратных платформ, форм-факторов и операционных систем мы пришли к доминированию iPhone и Android, а от полной открытости к пользователю — к закручиванию гаек «открытой мобильной операционной системы» её же разработчиком. Но факт остаётся фактом — разработка в те годы была куда более ламповой, душевной и, что интересно, предлагала куда больше игр с уникальным геймплеем...
А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.
Если вам понравилась статья и вы хотите меня поддержать, у меня есть Boosty, а также виджет на Пикабу ниже. А ещё мне можноотправить какое-нибудь интересное железо: устройства на WinCE/WinMobile, китайские кнопочники, китайские подделки на iPhone/Samsung из начала 2010-х, игровые консоли, ретро-ПК железо - всё это я очень люблю и порой пытаюсь поднять даже нерабочие гаджеты :) Всем огромное спасибо!
Это распаковщик и запаковщик ресурсов мобильных J2ME RPG игр от id Mobile. Первая версия имеет полную поддержку Doom RPG и частичную Orcs & Elves и Orcs & Elves II.
В будущем планируется полноценная поддержка всех остальных игр серии RPG и встроенный редактор ресурсов.
Проект полностью бесплатный и с открытым исходным кодом. Распространяется по лицензии AGPL-3.0.
Друзья! А вы помните, какими были мобильные игры в 2000-х годах? Помните, как разработчики умудрялись уместить целые миры в устройство с небольшим дисплеем, аппаратной клавиатурой, весьма слабым железом и парой сотен килобайт памяти? Но задумывались ли вы, как в своё время работали эти сами игры «под капотом»? В сегодняшней статье-ретроспективе предлагаю вспомнить мобильный геймдев нулевых и узнать, как же работали 2D Java-игры, какие API были доступны и что из себя представлял средний телефон тех лет! Интересно? Тогда добро пожаловать под кат!
❯ Предисловие
Пожалуй, геймдев всегда был одной из самых интересных сфер программирования. Множество нестандартных задач, возможность применить профильные математические и алгоритмические познания, а также огромный простор для архитектов в продумывании архитектуры будущей игры, ведь, например, в больших студиях комплексные и большие игры обычно очень сложные и нередко тянут за собой целый пласт легаси-кода и наработок чуть ли не из 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 для «сырых» картинок не в нативном-формате, может быть медленно), примитивов (линии, прямоугольники, овалы), текста и… всё! Например, картинку можно было нарисовать вот так:
При этом с шрифтами вопрос был отдельный: у каждого устройства был свой набор поддерживаемых шрифтов и свои фишки, о которых клиентская программа даже могла и незнать: например поздние телефоны поддерживали сглаживание шрифтов (что дико лагало на устройствах типа 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-канал, куда я публикую различные мысли и советы по ремонту и программированию под гаджеты прошлых лет, подсъемы с новых видосов и всегда актуальные ссылки на новые статьи!
Этого красавца подарил мне читатель с Пикабу, за что ему большое спасибо! Девайс сдали в утиль, после неудачной попытки ремонта в СЦ в середине нулевых. Последний раз телефон использовался до поломки, ещё в 2006 году - 18 лет назад!
Считайте, что это своеобразный анонс подробного длиннопоста об аппаратном оживлении этого красавца, на манер статьи о N-Gage! Помимо ремонта, мы посмотрим на этот девайс подробнее, посчитаем ключи загрузчика, накатим патчи и эльфлоадер - эдакий ретро-моддинг из нулевых! И это будет не единственная статья про Siemens...
Ах, золотые времена кнопочных телефонов от Nokia, Siemens и Sony Ericsson до исконно брутальных Motorola! Каждое смс сообщение на латинице вмещало до 140 символов, а на кириллице — всего 70, что ставило нас перед крепким орешком: учиться искусству сжатого слога или переходить на транслит?
Отправляя "телеграммы" через SMS, многие сокрушались: "За что мне такая наказуха?" И тут на сцену выходит спаситель — не, не Бэтмен, а Аська! Этот мессенджер был почти святым Граалем экономической эффективности в эпоху дорогущих SMS-пакетов. Стоимость GPRS-трафика против стоимости SMS делала Аську чуть ли не фолиантом для экономистов!
IRC? Да, это как ретро-игры на приставках: круто, но не для каждого. А Аська была тем местом, где "Ищу тебя" звучало как опция поиска контактов, а не начало стихотворения. Вычислить единомышленника можно было по городу, увлечениям, да и вообще, это было почти как знакомство в трамвае, только виртуальное.
"Трава была зеленее", а сервера быстрее, но не все сказки имеют счастливый финал. OSCAR, душа и сердце Аськи, сказал свое "Прощай" в 2018-м. Jimm и его братья были унижены и заброшены, их часы ударили... или не совсем?
С тех пор без сделан гениальный фикс на сервере по авторизации и все дорогие нам клиенты "поднялись", словно Феникс из пепла, и готовы послать звонкие "Здрасьте!" между QIP на компе и Jimm на Sony Ericsson k750i без правок в самих клиентах!
Стоит ли оживлять археологические находки? Да ради бога, если вам нравится этот винтажный вкус. Напоминаю, это не только забава, но и милая экономия для тех, кто до сих пор платит за каждую SMS как за капучино в центре Парижа. Попробуйте и убедитесь: Аська на Nokia — это не просто реликт прошлого, это декларация ностальгического стиля!
Дело было одним весенним вечером 2012 года. Тогда я как обычно собрался скоротать время за парой-тройкой интересных игр и неожиданно обнаружил новую игру, которую в принципе не устанавливал. Игра рассказывала о приключениях дракона, который бродит по каким-то не очень жизнерадостным пейзажам. Поначалу я не очень её оценил и посчитал слишком мрачной, играя тогда в более яркие игры. Но всё-таки что-то меня тогда зацепило и немного походив по сайтам, я узнал, что это была так называемая «обрезка», уже сам скачал полную версию и с удовольствием прошёл её за один вечер. А после прохождения подумал, откуда она вообще появилась у меня на телефоне. Тогда я вспомнил, что днём ранее как раз одолжил телефон другу с которым давно общался, значит он и поставил. На следующий день, спросив, что это за игра такая, я узнал о целом списке подобных игр. Так я познакомился с серией игр о Спайро.
Чем меня заинтересовала эта игра. Первое - это потрясающие саундтреки, созданы они очень атмосферными, что очень помогает погрузиться в мир игры. Настолько зацепили, что после прохождения достал их из игры и сохранил на карту памяти, под настроение переслушиваю даже сейчас.
Второе - это красивое оформление. Детально нарисованные уровни, с возможностью эффектного разрушения некоторых деталей и потайные комнаты радуют глаз. Сами фигурки драконов также качественно прорисованы, так что при управлении ими, движение и прыжки не ощущаются неестественными.
Третье - это сами миры. В игре можно побродить по катакомбам, дикому лесу, городу драконов и выжженным землям, то бишь, миру лавы. Сама идея игр состоит в том, что есть множество миров, в которых можно побывать и эти миры интересно исследовать. Будучи подростком не играющим в компьютерные игры, эта идея мне очень понравилась.
И четвёртое - это сам лор, прописанная вселенная игры. Кому-то он может показаться примитивным, мол драконы и фэнтези стилистика, ничего нового в этом нет. Но на тот момент это был первый фэнтези мир, который меня заинтересовал, поэтому я с удовольствием прошёл и другие игры серии.
В целом, я рад, что случайным образом когда-то сыграл в эту игру. Благодаря ей мне довелось узнать о целой серии потрясающих игр с фиолетовым драконом и побывать во множестве миров, поэтому эта часть является для меня особенно ценной. Потому и решил её порекомендовать, быть может кто-то также узнает для себя что-то новое и интересное.
Ну и скриншоты, конечно же. Название: The Legend of Spyro: Dawn of the Dragon
Друзья, все мы (по крайней мере те, кто родился до 2005 г.) помним переходный момент, когда появились первые мобильники. Интернет нам тогда ещё не был так хорошо доступен, как сейчас, мощности девайсов были небольшими (хотя уже в разы превышали мощности тех же первых из доступных нам компьютеров, таких как ZX Spectrum). Например, телефоны Siemens C75, ME75 имели частоту процессора в 124 МГц, против 3,5 МГц на Z80. Тем не менее, многие идеи этих игр были взяты ещё со времен Денди и Спектрума (некоторые из них являются прямыми аналогиями). Однако для нас, уже не заставших Спектрум и его предков в былом их величии, эти игры всё равно запомнились и отпечатались в памяти. Предлагаю вспомнить 10 игр, которые в своё время занимали первые места в топах различных сайтов (а их было много - вспомнить Tegos, Konon (RuGame), Spaces, Waper, SeClub и другие (многие из них уже закрыты, остальные ещё доживают свой век. Также некоторые из этих игр можно было купить в журналах или с помощью тетрадок (школьники помнят). Друзья, расчехляем KEmulator. Внимание! Все права на игры принадлежат их авторам. Я лишь делаю обзор. Часть скриншотов взята с интернета.
1. Galaxy on Fire 2 (а также его предки GoF 1 и Deep 3D). Производство: FishLabs. 2009 год и ранее.
Серия 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 не сохраняли (хотя были и такие модели - на них можно было игры и не покупать - ставилась симка с нулевым балансом, а потом код можно было подсмотреть в "не отправленных" сообщениях).
О мобильных 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 и до новых встреч.
