Qplaze-2005: Какие тогда были технологии

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

Java рассчитана на «написано раз, работает везде». Может, в прикладном ПО, если его нормально написать, такой принцип и будет как-то (!) работать, но в играх — нет. Под каждую серию мобильников игра программировалась отдельно. Звук вообще был никак не стандартизирован: у кого-то собственные звуковые классы, у кого-то плохой MMAPI, у кого-то — хороший MMAPI. Кто-то проигрывает AMR (наиболее качественный из GSM-кодеков, дававший 8…15 кбит/с), кто-то MIDI, MMF, тоновые звуки или ещё что-нибудь. Тем не менее, хороший программист делал так, чтобы портация была крайне безболезненной. Мы тянулись к «один день — один порт», но реалистичная цифра — порт в два дня. Что приходилось менять?

Во-первых, менялись так называемые «девайс-классы», отвечающие за экран, клавиатуру, игровой цикл и звук. Эти классы максимально скрывали особенности мобильников: например, Motorola, если поставить пустой прямоугольник отсечки, вообще переставала отсекать (правильно — ничего не рисовать).

Во-вторых, константы и алгоритмы, подобранные методом тыка либо снятые с нарисованной художником графики: если на мобильнике 128×128 отступ 3 пикселя, то на мобильнике 176×208 он будет 4 или 5.

В-третьих, на богатых мобильниках мы обогащали как игру, так и меню.

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

В общем, были у нас поползновения сделать единый исходник для всех портов, но оказалось, это невозможно. Какая-то унификация была, и исправления в одном порте можно было скопировать через Ctrl+C/Ctrl+V в остальные — но не больше.

Часто ограничивался размер архива (JAR), подчас до 64 килобайт. Для экономии архива у нас было много интересных решений.

• Обфускация — автоматическая замена на уровне class-файлов идентификаторов на a, b, …, z, aa, ab… Использовали бесплатную программу ProGuard.
• Архивировали своими силами, программой 7-zip или kzip. У первой лучше совместимость, вторая сильнее жмёт.
• Программы были совершенно не объектные, сильно полагались на массивы и static — подчас были всего два class-файла, midlet и canvas (или M и C, как мы их называли). Чтобы такое как-то можно было программировать, написали препроцессор, который несколько java-файлов (Data, Game, Skin, Menu и прочие) собирал в один.
• Ресурсы собирались в большие файлы — например, в файле может идти сначала тригонометрическая таблица, потом таблицы спрайтов, потом какие-нибудь картинки… Вообще все большие таблицы хранили только в файлах, так экономнее.
• Спрайты мы собирали из кусочков, специальной программой собственного производства. Написана на Delphi 7. (Скажу сразу, спрайты порезаны шакально, но что есть, то есть.)

А вот наш универсальный редактор уровней. Почему «ObjectPlacer»: сначала он только расставлял объекты, а плиточный фон редактировался другой программой. Потом приписали и свои плиточные инструменты, и даже (неполный) Ctrl+Z. Undo-redo действовал по 5 плиток за нажатие: если ведёшь большой штрих и вдруг ошибся, будет отменять по частям.

Разумеется, для сборки всего этого мы использовали собственную систему компиляции. В неё были прописаны все классы от всех мобильников, какие только существовали: и Nokia, Siemens, и Vodafone…

До 2006 года была одна версия Windows — «хрюня», неплохо совместимая по драйверам с 2000. Так что проблем с драйверами дата-кабелей не было.

Выяснилось, что штатные шрифты мобильников лучше не использовать: бывают великоваты, бывают без русских букв. Так что шрифты тоже паковали в текстуры.

Были два подхода к ошибкам движка: допустим, дорога идёт примерно так…

Наш Штирлиц идёт-идёт по склону, и вдруг начинает входить головой в потолок — что делать? Один геймдизайнер говорит: исправляй быстрее! Второй старается не делать таких «глючных» мест. Чаще всё же использовался второй подход.

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

Если экран прокрутился дальше вправо — отпечатываем шестой столбец на месте первого…

…и за две прорисовки выводим фон. Дальше вместо второго столбца рисуем седьмой, вместо третьего восьмой… Если прокрутка ещё и по вертикали — то вместо двух прорисовок четыре. Существовали также структуры данных, экономившие на прорисовке спрайтов; самая простая — отсортировать все спрайты по X-координате.

Большая часть меню также для скорости отпечатывалась на таких внеэкранных буферах. Не все программисты это практиковали, но я — точно.