Сегодня всё чаще можно услышать мысль о том, что раньше мобильные игры были лучше. В какой-то степени это правда: ранние Java-игры отличались отсутствием доната и сервисной модели монетизации, логической завершенностью большинства тайтлов, а также экспериментами с новыми жанрами. И всё это в рамках крайне ограниченных возможностей Java-телефонов. В этой статье я хотел бы рассказать о трудностях мобильной разработки образца 2005 года с конкретными примерами тех или иных решений, так что если вам интересно — добро пожаловать под кат!
Содержание:
❯ Предисловие
Пожалуй, мобильный гейминг как класс зародился в самом начале двухтысячных годов. В какой-то момент, производители телефонов смекнули, что помимо задач обработки GSM-стека, у чипсета остаётся достаточно процессорного времени для обработки второстепенных задач, благодаря чему в телефонах начал появляться дополнительный функционал: к примеру — игры. И хотя первой мобильной игрой был клон Тетриса в Hagenuk MT-2000 1994 года выпуска, на практике игровые перспективы в телефонах увидели только в 2000 году, когда компания Sun выпустила спецификации стандартов CLDC 1.0 и MIDP 1.0.
Дело в том, что в те годы телефоны работали на целом зоопарке самого разного железа и операционных систем. За год-два в телефонах одного производителя могло измениться всё: та же 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).
Набор API в первых телефонах с поддержкой Java был небогатым и состоял из CLDC — базовой инфраструктуры языка, и MIDP — набора классов для работы с «железом» устройства. Присутствовали пакеты для работы с дисплеем и создания простенького интерфейса (lcdui), примитивной работы с сетью (microedition.io), а также хранения данных (rms). При этом основная инфраструктура языка во многом была совместима с обычной Java версии 1.3 — то есть были классические потоки, коллекции (Vector, Stack, Hashtable — и это ещё не дженерики), генератор псевдослучайных чисел, исключения и даже минимальная рефлексия (Class.forName и Class.newInstance). Однако у CLDC 1.0 был один неприятный нюанс — он не поддерживал Float вообще ни в каком виде, из-за чего классы при компиляции проходили верификацию и дополнительную оптимизацию специальной утилитой — preverify.
И по правде сказать, этого набора API было слишком мало для разработки хоть сколь либо серьезных приложений и игр. Объём RMS был жёстко ограничен несколькими килобайтами, графическое API не умело рисовать кусочки изображения из атласов и использовать полупрозрачность, а о воспроизведении звука вообще можно было не мечтать. И это было справедливо для моделей 2001 года выпуска, но уже в 2002 начали появляться куда более продвинутые устройства с цветными дисплеями, полифонией и большим объёмом памяти. Каждый производитель начал реализовывать своё собственное API, из-за чего стали плодится отдельные версии приложений адапт��рованные для разных телефонов — Opera Mini S40 128x128, Gangstar SE 176x220, Prince Of Persia Mot 128x160...
Но 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-х...
А третьей платформой был BREW от компании Qualcomm. И по правде сказать, он был куда круче любой JVM — ведь предлагал писать полностью нативные программы на C, используя всю потенциальную мощность устройства. Но Qualcomm не был бы Qualcomm'ом, если бы не ограничил использование BREW только на телефонах с собственными чипсетами и RexOS, а также не отгородил всё отвратительным DRM. Впрочем, это тоже можно простить, ведь Qualcomm уже тогда был доминантном и двигателем прогресса телефонов, поскольку уже в 2004 году разработал и интегрировал собственный 3D-ускоритель. Но это уже совсем другая история...
Так что J2ME благодаря усилиям производителей телефонов и самой Sun стала по настоящему народной платформой. SDK был доступен абсолютно бесплатно и для всех, предлагалась отличная документация с множеством примеров программ, а приложения можно было ставить и отлаживать откуда угодно и как угодно, прямо как на Android. И это стало одной из проблем...
❯ Реалии разработки
Как и сейчас, в те годы мобильными играми в основном занимались небольшие команды. Условно был программист, который недавно постиг Java, перейдя на него с Delphi или C++, пару художников, которые рисовали всю графику в игре, а также отдельный звуковик, в задачи которого входило написание midi-музыки и иногда таких же midi-эффектов. Магазинов ассетов и соответственно ассет-флипа как класса ещё не существовало, поэтому всё в игре делали своими руками «как умели». Наверное одним из лучших примеров таких студий будет харьковская NetSoftware, известная своими играми серии «Бункер 3D»:
Что такое ассет-флип?
Сегодня у двух самых популярных движков — Unity и Unreal Engine, есть собственные магазины с ресурсами для игр. В них можно купить как обычные модели, текстуры и саундпаки, так и целые уровни вместе с шаблонами игр. Ассет-флипом называются те игры, которые либо построены на базе популярного шаблона игр (помним бесчисленные низкокачественные шутеры с всякими Ultimate FPS Controller или «симуляторы вождения» на базе Edy's Vehicle Phyiscs?) с минимальными геймплейными изменениями относительно шаблона, либо игры с собственной логикой и геймплеем, которые неизменно используют уже готовые уровни.
И вот, ребята разработали игру и хотят заработать денюжку на её продаже. Тогда ещё возможности самиздата не было, а также не существовало монетизации за счёт рекламы и донатов (кроме немногочисленных 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-сайт... короче пиратство было настолько распространено, что я даже в теории не могу предположить сколько там упущенной прибыли :)
А ещё был хорошо налажен конвейер копирования успешных идей. Однако если сейчас в основном копируются свежие геймплейные идеи гиперказуальных игр, то тогда пытались один в один скопировать целые игровые вселенные. Вспомнить только Gameloft с её AAA-играми по мотивам GTA (Gangstar), Need for Speed (Asphalt) и даже Call of Duty (Modern Combat). В СНГ же такой фирмой была NetLizard, которая в основном делала упор на популярные игровые вселенные и постсоветский колорит (Ликвидатор ЧАЭС — её разработка). Кроме того, не было никаких особых ограничений на распространение эротических и даже порнографических игр — и они свободно распространялись даже в журналах (с особо сочными описаниями)!
❯ Как это работало?
Однако пожалуй самое интересно это то, как мобильные игры тех лет работали «под капотом». Ведь в отличии от современных устройств, на кнопочных телефонах нельзя было разгуляться с абстракциями, раскидываться аллокациями на куче, и даже использование floating-point арифметики было нежелательным. Более того, многие разработчики намеренно отказывались не только от любых абстракций, но и просто от концепции классов или стандартных паттернов организации сцены/состояний, предпочитая создавать God-объекты для целых игр. В одном классе мог быть код и обработки состояний (меню, игра), и загрузки уровней, и отрисовки, и обработки логики. Нередко отказывались даже от стандартных коллекций типа Vector и структур данных, предпочитая реализовывать статические пулы-массивы с данными для каждого игрового объекта. Как бы это забавно не звучало в контексте Java, но чаще всего использовали процедурный подход программирования:
На первый взгляд может показаться, что программисты были просто неопытными и писали «как умели». Однако на практике это была одна из фундаментальных оптимизаций: во первых, статические пулы с примитивными типами данных избегали дорогого боксинга. Использование структур было не всегда оправданным из-за относительно высокой цены аллокации (а в J2ME они всегда на «куче», в отличии от .NET. Засовывать мелкие объекты в Eden-space те JVM ещё не умели) и примитивности GC. А во вторых, в некоторых JVM верификация почему-то выполнялась не при установке приложения, а при первой загрузке класса ClassLoader'ом. И процесс верификации мог заметно затормозить приложение, при этом съев ещё немного памяти для данных о загруженном классе.
Ведь когда мы говорим о 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-машины на конкретный телефон.
Второй проблемой была графика и разные разрешения экрана. В качестве основного формата изображений, в J2ME был выбран png из-за простоты реализации загрузчика, высокой lossless-компрессии, а также свободности Zlib. Формат png в своей основе подразумевает 32х-битный формат цвета с 4-мя компонентами: R, G, B и A. A — это альфа-канал или степень прозрачности пикселя, и вот с ней у многих телефонов были проблемы. Дело в том что примерно до 2006 года, многие телефоны не умели альфа-блендинг (т.е полноценную полупрозрачность) вообще, из-за чего представляли прозрачность либо как 0 (пиксель прозрачный), либо как 1. Если в игре предполагались полупрозрачные поверхности (например стекла или параллакс-фоны), то для некоторых телефонов их приходилось заменять дизерингом или вообще делать упрощенную, менее красочную версию:
Вы никогда не задумывались, почему современные 2D-игры не зависят от разрешения экрана и выглядят одинаково сочно как на 4K-дисплее, так и на 720P экране бюджетного смартфона? Секрет прост: современные игры используют в качестве системы координат не пиксели, как это делали многие старые релизы (не только Java, но и консольные/ПК), а метры (сантиметры, что угодно). С развитием мобильных GPU, 2D стало частным случаем 3D и теперь все двухмерные элементы — это просто плоские 3D-треугольники. А поскольку растеризатору совершенно не важно какой треугольник ему «скармливают» и при нанесении текстуры/спрайта он оперирует исключительно алгоритмами фильтрации (которые включают в себя масштабирование) — мы можем видеть идентичную картинку с идентичным уровнем масштабирования на любом устройстве:
На ретро-телефонах всё было по другому. Чаще всего у устройств не было не то что 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:
Второе 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 году платформа начала стремительно сдавать позиции...
И этой причиной был 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, а если вы хотите что-нибудь подарить из железа и увидеть о них статью — пишите мне в Telegram. Интересны разные гаджеты: игровые консоли, смартфоны/телефоны, коммуникатоы/КПК, ретро ПК железо и всякое такое. Если девайс интересный, то я порой могу и недели потратить на восстановление его платы. Всем большое спасибо!
Кстати, если вдруг у вас есть какие-нибудь интересные кнопочные телефоны, которые вы хотели бы задонатить для будущей статьи о разработке игры для ретро-девайсов, я готов их принять :)
Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩
