что такое портировать игру
Почему так сложно портировать игры на PC — кратко и просто о долгом и трудном
Портирование игр — это действительно нелегкая задача для разработчиков, даже если речь идет о выпуске игры на ПК, где она, собственно, и разрабатывалась. И в этой статье один из основателей студии Disparity Games Джейсон Старк (Jason Stark) расскажет, с какими трудностями сталкиваются его коллеги по цеху.
Вопросы сооснователю Disparity Games задавали журналисты сайта PC Gamer. Материал подготовлен на основе англоязычной статьи.
Как портируют игры на ПК
Геймеры спрашивают, почему разработчики просто не могут выпустить ту версию игры, которую они делали на PC во время тестирования. А когда они делают это и выпускают забагованный билд, те же геймеры сетуют на ошибки и винят девелоперов в лени.
Чтобы понять всю сложность процесса, достаточно просто представить, как много компонентов имеет любой современный компьютер. Различное «железо», тысячи версий драйверов, и иногда очень трудно предугадать, как их связка поведет себя в тех или иных условиях.
Даже хорошо оптимизированные и отлаженные игры часто работают не так, как нужно, если компьютер имеет специфический набор ПО и комплектующих. В этом смысле вопрос «хорошего» или «плохого» порта — это скорее вопрос вложения денег и времени: сколько ресурсов готов потратить разработчик, чтобы обеспечить наибольшую совместимость? Впрочем, абсолютный идеал все равно недостижим.
Перенести игру на консоли тяжело, но в случае возникновения бага на одном Xbox One, ты будешь знать, что то же самое будет на всех остальных Xbox One.
Больше платформ — больше проблем
При портировании игры разработчик фактически создает ее уникальную версию. Это означает, что выбор каждой дополнительной платформы для выпуска игры увеличивает сложность релиза на порядок. Это умножение, а не сложение. В случае нескольких платформ нужно не только выпускать, но еще и быстро реагировать на всевозможные проблемы, оперативно решать их.
Каждый патч или обновление нужно тестировать на каждой платформе отдельно. И только если ни на одной не возникло проблем, выпускать это в «паблик». Ведь безобидный «фикс» на одной платформе может вызывать критический сбой на другой. Нужно учитывать кучу факторов и особенности архитектуры каждой среды.
Создание ПК-порта игры с прошлого поколения консолей тоже довольно проблемное дело. Проект, который ранее запускался в 30 fps, далеко не всегда можно быстро «завести» в 60. А игры из прошлого десятилетия нельзя по мановению руки адаптировать к 4K-разрешению, как бы просто это не казалось.
Когда проще сделать игру заново
Короче говоря, портирование — это довольно непредсказуемый процесс. Но вместе с этим разработчик должен стремиться к тому, чтобы все версии одной и той же игры были похожи по своему функционалу и внешнему виду. При этом зачастую это невозможно на практике из-за кардинальных различий между платформами. А также из-за необходимости соблюдать лицензионные соглашения.
Вы редко слышите негативные рассказы о портировании игр, потому что в интересы разработчика не входит посвящать третьи лица в требования платформодержателей. Им не хочется читать критику в свой адрес.
Особенности продвижения
Если на минутку забыть о технических вопросах, то выпуск игр на разных платформах все равно является очень трудным делом. Ведь если игра выходит на системе, ее нужно продавать тем, кто этой системой пользуется. Нужно искать популярных «ютуберов», налаживать связь с сообществом игроков, делать промо-материалы для каждой платформы в отдельности.
Например, в коллективе из 20 человек вопросами продвижения могут заниматься трое. Они не участвуют в разработке как таковой, только занимаются изданием, маркетингом и продажами. Для маленьких студий вопрос выхода на нескольких платформах — это серьезная головная боль: рук не хватает.
К тому же никто не отменял непреднамеренных вещей вроде выпуска портов разного уровня качества. Это иногда выходит само собой, но игроки почти всегда начинают обвинять разработчиков в том, что они «продались» и перетянуть игроков на другую платформу. Хотя на самом деле большинство разработчиков хотят выпустить хороший порт для любой системы, просто не всегда это получается.
Впрочем, бывает и обратное, когда выходит переиздание какой-то древней игры и она пробивает чарты продаж. В таких случаях игроки готовы платить хорошие деньги, чтобы получить улучшенную версию любимой игры, так как это отличный способ отблагодарить девелопера за хорошую работу.
Операционная система Haiku: портирование приложений и создание пакетов
Осенью этого года, спустя 6 лет разработки, вышла первая бета-версия «R1/beta1» операционной системы Haiku. Я давно слежу за этим интересным проектом, который нацелен на воссоздание и последующее развитие существовавшей в 1994-2000 годах системы BeOS. Поэтому, как только на новостных IT-сайтах я увидел новость о выходе бета-версии Haiku, я незамедлительно решил посмотреть, что же было добавлено в этот долгожданный релиз. После установки системы в виртуальную машину VirtualBox и небольшого ознакомления с её основной функциональностью, я подумал, что было бы неплохо немного помочь OpenSource-сообществу, которое сегодня развивает эту операционную систему. Начать я решил с того, в чём у меня накопился небольшой опыт: с портирования некоторых игровых проектов.
Рабочий стол операционной системы Haiku.
Позже я попытался доработать некоторые уже существующие приложения и библиотеки. Именно этой моей небольшой деятельности в различных репозиториях с открытым исходным кодом и будет посвящена эта статья. В ней я последовательно опишу те проблемы, с которыми столкнулся и расскажу про методы их решения. Большинство патчей, которые были сделаны в процессе этой работы, я попытался отправить в upstream существующих проектов, дабы обеспечить в них поддержку Haiku и заинтересовать их разработчиков существованием альтернативных операционных систем.
Операционная система Haiku использует гибридное ядро, которое представляет собой реализацию микроядерной архитектуры с возможностью динамической подгрузки необходимых модулей. Оно базируется на форке ядра NewOS, которое было разработано бывшим инженером Be Inc., Travis’ом Geiselbrecht’ом. Сегодня этот разработчик работает в Google над ядром, которое называется Zircon, для новой операционной системы Google Fuchsia, но это уже другая история. Итак, поскольку разработчики Haiku декларируют бинарную совместимость с BeOS, то они вынуждены поддерживать не две привычных всем архитектурных ветки, а три: x86_64, x86 и x86_gcc2. Последняя архитектура представляет собой груз совместимости с компилятором старой версии GCC 2.95. Именно благодаря ей имеется возможность запуска приложений, написанных для оригинальной операционной системы BeOS. К сожалению, из-за этого груза совместимости, разработчики Haiku не могут использовать современные возможности языка программирования C++ в системных API. Тем не менее, установочные образы они подготавливают только для двух архитектур: x86_64 и x86. Всё дело в том, что дистрибутив Haiku для x86 является гибридным: несмотря на то, что все системные компоненты собраны под x86_gcc2 для обеспечения бинарной совместимости, пользователю предоставляется возможность установки или сборки любых современных приложений, которые были сделаны с расчётом на современные компиляторы и архитектуру x86. Дистрибутив Haiku для архитектуры x86_64 является полностью 64-битным и не имеет возможности запуска 32-битных приложений BeOS и Haiku. Однако, совместимость на уровне API имеется, поэтому если у вас есть на руках исходный код приложения под BeOS или Haiku x86, вы без проблем сможете скомпилировать его под Haiku x86_64 и всё должно работать. Образ операционной системы под архитектуру x86_64 рекомендуется для установки на реальное железо, если вам не требуется поддержка каких-либо специфичных приложений BeOS или 32-битных приложений Haiku.
Стоит сказать, что в этой операционной системе имеется частичная поддержка стандарта POSIX. Этот фундамент делает её родственной UNIX-like системам и позволяет легко переносить их программное обеспечение. Основным языком программирования является C++, он активно используется, поскольку публичные API у Haiku в основном преследуют объектно-ориентированную парадигму программирования. Тем не менее, никто не запрещает использовать и язык программирования C, только для большинства случаев придётся писать соответствующие прослойки совместимости. Программный интерфейс операционной системы сгруппирован в отдельные системные фреймворки, которые отвечают за ту или иную возможность, например, за интерфейс или поддержку сети. Это немного похоже на то, что имеется в macOS или во фреймворке Qt. Обязательно нужно отметить, что эта операционная система является однопользовательской, хотя некоторые подвижки в сторону обеспечения многопользовательского режима работы у разработчиков Haiku имеются.
Не могу не поделиться с читателями этой статьи положительным опытом использования продвинутой системы управления окнами приложений, которая имеется в Haiku. На мой взгляд она одна из самых удобных и в своём роде является визитной карточкой этой OS.
Продвинутое управление окнами в операционной системе Haiku: поддержка тайлинга и вкладок.
Окошки можно скреплять между собой во вкладки, как это сделано в современных браузерах, прикреплять их друг к другу и удобно изменять их размер. Поддерживается простенький тайлинг, перенос контекстов некоторых приложений из одного окна в другое и репликанты. Более подробно обо всех возможностях местной оконной системы можно прочитать в официальной документации, там же описаны все необходимые сочетания клавиш быстрого доступа.
Я не буду писать в этой статье полный обзор всех особенностей и возможностей Haiku, так как те, кому это интересно, легко смогут самостоятельно найти нужную информацию в интернете.
Содержание:
1. Пакеты и репозитории в Haiku
По сравнению с оригинальной BeOS, в Haiku появилось значимое нововведение: система управления пакетами, которая включает в себя различные инструменты для получения и установки программного обеспечения из различных источников. Такими источниками могут служить официальные репозитории Haiku и HaikuPorts, неофициальные репозитории и просто отдельные и специально подготовленные HPKG-пакеты. Подобные возможности по установке и обновлению ПО давно известны в мире Unix-like операционных систем, теперь же вся их мощь и удобство успешно добрались и до Haiku, что не может не радовать рядовых пользователей этой операционной системы. Благодаря выстроенной вокруг пакетного менеджера инфраструктуры, теперь любой разработчик может легко портировать новое или доработать уже существующее приложение с открытым исходным кодом, затем добавить результаты своего труда в репозиторий портов программного обеспечения HaikuPorts, после чего они станут доступны всем пользователям Haiku. В итоге получившаяся экосистема напоминает таковую у операционных систем macOS с их Homebrew, FreeBSD с их портами, Windows с MSYS2 или Arch Linux c его AUR’ом.
Инструмент для сборки пакетов и портирования программного обеспечения, называемый HaikuPorter, поставляется отдельно от операционной системы и устанавливается по небольшому мануалу, расположенному в репозитории на GitHub. После установки этой утилиты с того же GitHub’а скачивается всё дерево рецептов, над которым и работает разработчик. Рецепт представляет собой обычный Shell-скрипт с инструкциями, по которым HaikuPorter и будет собирать требуемый HPKG-пакет. Примечательно, что сам инструмент написан на языке программирования Python 2, тесно взаимодействует со существующей системой управления пакетами, а для фиксации изменений исходного кода ПО и генерации набора патчей, внутри себя использует стандартный инструмент — Git. Именно благодаря подобному стеку технологий делать рецепты для сборки HPKG-пакетов и наборы патчей к ПО в виде patchset-файлов очень удобно и просто. В большинстве случаев мне пришлось использовать всего три команды при работе с HaikuPorter’ом:
Первая команда просто собирает выбранный пакет, вторая команда очищает директорию сборки, а третья создаёт или обновляет набор патчей в соответствии с вашими изменениями, которые были зафиксированы в Git-репозитории рабочей директории посредством коммитов.
Таким образом, чтобы опубликовать какой-либо пакет в репозиторий HaikuPorts и сделать его доступным для всех пользователей Haiku, разработчик должен установить у себя HaikuPorter, развернуть дерево рецептов, локально собрать HPKG-пакет и протестировать его, затем сделать коммит в свой форк дерева рецептов, после чего оформить Pull request на GitHub’е. Опубликованную работу должны рассмотреть разработчики Haiku, после чего они принимают решение влить ваши изменения в репозиторий или же отправить их на доработку. Если изменения приняты, то такой же HaikuPorter, установленный на сборочном сервере, удалённо соберёт пакет и автоматически опубликует его в репозиторий.
В бета-версию «R1/beta1» операционной системы Haiku была добавлена специальная программа HaikuDepot, которая позволяет работать с пакетами и репозиториями через графический интерфейс пользователя, а не через консольные команды в терминале.
Программа HaikuDepot, запущенная в операционной системе Haiku.
Благодаря этому инструменту неискушённые и начинающие пользователи Haiku могут удобно управлять своей пакетной базой. Стоит отметить, что это приложение не просто является GUI-оболочкой над существующим пакетным менеджером, но и реализует дополнительную функциональность. Например, авторизированные пользователи могут выставлять оценки и писать отзывы к доступным для установки пакетам. Кроме того, у HaikuDepot имеется специальный сайт Haiku Depot Web, позволяющий просматривать изменения пакетной базы в интернете или скачивать отдельные HPKG-пакеты.
Портирование любимой игры под Android
Создание игры процесс захватывающий и познавательный. Особенно это заметно, когда ремейк «классики» делаешь сам, руководствуясь идеями оригинала и десятками часов, потраченных на прохождение кампании. У меня не было сколь-нибудь значимого опыта разработки для Android’a, поэтому создание работающего «как надо» приложения для планшета поначалу выглядело довольно туманно, но от этого не менее притягательно. При наличии времени и возможностей, можно стряхнуть пыль со старых игр, подмазать и подклеить, добавив поддержку «больших» разрешений и окажется, что они выглядят не хуже современных продуктов, выложенных на маркете, даже с палитрой RGB565 без альфа-канала. Я предполагал, что будут подводные камни и заботливо спрятанные грабли, которые лежат тихонько во время разработки, но больно лупят по голове, стоит запустить игру на реальном железе. Чего сильно не хватало, так это отладчика, а возникающие проблемы лишь укрепили желание достичь поставленной цели. Под катом будет рассказ о том, как это все заработало.
Стоит сразу предупредить, что это возможно будет рассказ о велосипедах, я не придумал ничего такого, что не гуглится на просторах «интернетов». Также Читатель вряд ли увидит новые решения или мега технологии, но найдет опробованные инструкции по сборке приложения, использующего SDL1/2, для Android.
Здравствуйте!
Ремейк игры Caesar III© начинался совсем не как отдельный проект, а скорее набор фиксов для количества жителей, поддержки «больших» разрешений и исследования декомпилированного кода оригинальной игры в поисках пасхалок и недокументированных режимов работы. А когда количество восстановленного кода перевалило за половину от общего, стало понятно, что можно попытаться восстановить игру. В качестве библиотеки отрисовки была выбрана SDL1.2, которая хорошо зарекомендовала себя в других проектах, а ещё проста в освоении и использовании. Ремейк поначалу был Linux-only, в начале этого года перебрался на другие платформы (Mac, Windows и Haiku), а потом у меня завелся вот такой планшет, а голове периодически возникали мысли «работает на одном линуксе, должно работать и на другом».
Попытка номер раз, удачная
У SDL версии 1.2 «из коробки» нет возможности работы под андроидом, зато есть замечательный проект libsdl-android, который позволяет, используя свое окружение и скрипты собирать код, использующий эту библиотеку в приложении для андроида. Собранное приложение может загрузить ресурсы как из интернета, так и распаковать из установщика. Сам libsdl-android содержит большое количество библиотек, которые могут вам понадобиться, начиная от bzip2 и разных кодеков, до самой SDL и его окружения SDL_image, SDL_mixer, ttf и другие. Если у игры нет платформозависимого кода, то портирование занимает несколько шагов:
/.bashrc;
echo «export ANDROID_NDK=
/.bashrc;
echo «export NDK_ROOT=\$$ANDROID_NDK» >>
/.bashrc;
echo «export PATH=\$$PATH:\$$ANDROID_NDK:\$$ANDROID_SDK/tools:\$$ANDROID_SDK/platform-tools» >>
Если все удачно скомпилилось, то в папке commandergenius/project/bin появится файла MainActivity-[release|debug]-unsigned.apk, который нужно подписать и установить на устройство.
/projects/commandergenius/project/bin/MainActivity-release-unsigned.apk caesaria
$ mv
/projects/caesaria.apk
$ adb uninstall net.dalerank.caesaria
$ adb install
Подводные камни
0. Определение окружения: для начала надо определиться в каком окружении будет работать Windows, Linux или Linux Android.
Решение: Проверяем наличие дефайнов ANDROID/__ANDROID__.
3. Обработка событий: пропадает событие SDL_MOUSEBUTTONUP при движении пальцем по экрану, это могла быть недоработка в самой библиотеке libsdl-android или я где-то его терял. Проявлялось иногда в отсутствии реакции элементов интерфейса на действия пользоватся, например после движения остановились на кнопкой, которая по идее должна перейти в состояние если над ней находится курсор мыши.
Решение: Специфично для моего приложения — при сборке под андроид было добавлено принудительное обновление состояния элементов под курсором при движении последнего.
4. Мелкий интерфейс: разрешение экрана современных мобильных устройств сопоставимо или превышает разрешение монитора, используемого 10-15 лет назад, но физические размеры заметно меньше, оттого и сам элементы пользовательского интерфейса выглядят мелко и пользоваться ими будет не всегда удобно.
Решение: Переделка интерфейса, что достаточно хлопотное занятие и не всегда удается сохранить первоначальный вид.
Один переезд равен двум пожарам(народная мудрость)
Все началось с того, что один из коммитеров прислал ссылку на ветку разработки, где успешно запустил игру с использованием относительно свежей библиотеки SDL2, а до этого использовалась версия SDL1.2 — 2008 года выпуска. Надо сказать, что я и сам рассматривал возможность перехода на новую версию, особенно после просмотра списка изменений, который сулил нормальную поддержку Mac и Android, что называется «из коробки». А тут еще и миниотпуск на работе получился, взяв кувалду побольше гайд потолще и большую чашку кофе, я начал переводить ремейк на новый «движок».
Не хочу утомлять читателя техническими подбробностями переезда, просто у самой библиотеки с приходом аппаратной поддержки изменилась идеология работы, что поначалу доставляло определенные трудности, пока я к ней не привык. Переезд растянулся на неделю вечеров и под конец представлял собой исправление оставшихся недочетов и графических артефактов. Переделки были закончены и подготовлены сборки для «больших» ОС, и опять появилась необходимость повторного чтения мануалов по сборке приложения под Андроид, потому как libsdl-android нормально адаптирован для работы с SDL1.2, а поддержка SDL2 похоже заброшена (о чем сами авторы и пишут в ридми)
Осознал я правдивость этого текста, когда было потрачено несколько часов в попытке запустить порт в старой конфигурации через libsdl-android. Ну что ж, отрицательный опыт — тоже опыт: буду использовать доступные инструмены.
Попытка номер два, не совсем удачная
SDL2 уже содержит все необходимые конфиги для сборки приложения под андроид, почитав статью, рекомендованную на официальном сайте, можно пробовать собрать чтонибудь. Опять же будут несколько шагов, за исключением установки и настройки adt.
$git clone bitbucket.org/dalerank/caesaria
$hg clone hg.libsdl.org/SDL
$mkdir caesaria/android
$cp SDL/android-project caesaria/android
$mkdir caesaria/android/libs
$mkdir caesaria/android/data
$cp SDL caesaria/android/libs
Для чего все эти копирования сделаны. чтобы проще было считать относительные пути для библиотек. В папке android/libs будет лежать SDL и компания, в папке android/data — будет иконка приложения.
В папке android/android-project/jni создаем символьные ссылки на компоненты приложения
Немного о том, что же я тут написал:
zlib нужен для сборки freetype, который в свою очередь нужен для SDL_ttf и будет отвечать за рендеринг шрифтов.
Библиотека smk нужна для воспроизведения видео в формате smack, в этом формате выполнены ролики оригинальной игры.
Bzip, lzma и aes нужны для работы с zip-архивами.
libpng требуется для загрузки текстур для игры.
SDL, SDL_mixer, SDL_net отвечают соответсвенно за рисования, работы со звуком и сетью.
application содержит исходники самой игры, которые будут собраны в библиотеку libapplication.so
в папке src располагаются исходники библиотеки libmain.so, а вот для неё уже написано кружево java-вызовов над с-кодом, которое позволит нам успешно стартовать и порадовать пользователя яркой картинкой.
Настройки проекта и конфиги для ndk уже любезно предоставлены авторами SDL2
Чтобы система сборки увидела, какие нам необходимы библиотеки для работы и собрала их, нужно написать для них конфиги, наподобие Makеfile. С большой вероятностью Android.mk уже будет присутствовать в репозитории библиотеки, или их можно найти на просторах интернета. Мне пришлось дописать конфиги сборки для для игры и библиотеки libsmk.
Конфиг содержит указание скомпилировать все файлы с расширением .с, найденные в текущей папке (для libsmk это будет jni/smk)
Аналогично пишется и конфиг для сборки библиотеки, которая будет представлять саму игру.
LOCAL_C_INCLUDES := \
$(LOCAL_PATH)/$(SDL_PATH)/include \
$(LOCAL_PATH)/$(SDL_MIXER_PATH) \
$(LOCAL_PATH)/$(SDL_NET_PATH)/include \
$(LOCAL_PATH)/$(FREETYPE_PATH)/include \
$(LOCAL_PATH)/$(GAME_PATH) \
$(LOCAL_PATH)/$(DEP_PATH) \
$(LOCAL_PATH)/$(DEP_PATH)/libpng
Тоже должно быть понятно, в LOCAL_C_INCLUDES добавляет пути где нужно искать заголовочные файлы, в LOCAL_SRC_FILES добавляем файлы с исходным кодом,
в LOCAL_SHARED_LIBRARIES прописываем зависимости приложения.
флаги rtti, exceptions отвечают за использование RTTI и исключений.
Теоретически, после выполнения описанных шагов на подключенном девайсе или эмуляторе вы увидите установленное приложение. 
Грабли
1. Где искать ресурсы.
Место размещения ресурсов зависит от конкретной реализации ОС, но в большинстве случаев приложению будет доступна папка /sdcard/Android/data/имя_пакета/files, при использовании непосредственно пути может быть ошибка доступа или ошибка поиска файла.
Получить полный путь к директории приложения можно через функцию SDL_AndroidGetExternalStoragePath(), определенную в файле SDL_system.h
2. Использование флагов создания окна.
Комбинация SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN | SDL_WINDOW_BORDERLESS работает не на всех девайсах, убираем SDL_WINDOW_OPENGL или SDL_WINDOW_BORDERLESS и смотрим какой из флагов крашит программу. Не могу объяснить с чем связано такое поведение. С флагом SDL_WINDOW_SHOWN запукается по логам один в один, как и со всеми флагами, но при этом вероятность вылета намного меньше.
3. Слишком много звуковых каналов.
Наблюдаются вылеты при вызове функции SDL_mixer::Mix_AllocateChannels(N>16) c ошибкой, что невозможно иниализировать звук. Обходится снижением запрошенного числа каналов, насколько корректно решать эту проблему таким способом я не знаю.
4. stlport vs gnustl
Вылет при использовании stlport, нарвался на этот баг при обходе вектора с использованием итераторов на эмуляторе Nexus 7 (Android 4.0.3). Опять же не могу объяснить факт сей ошибки, решилось использованием gnustl при сборке приложения.
5. Мое кунгфу сильнее твоего.
Использование библиотеки с именем, похожим на имя той, что уже есть в системе приводит к загрузке чужой библиотеки, в которой возможно нет необходимых функций. Ошибка появилась из-за того, что я собираю свою версию libpng.so, решение было найдено на stackoverflow, исправилось заменой имени библиотеки libpng.so на libpnggo.so
В заключении.
Работает! Почти не отличается от ББ! Доволен ли я? Не очень!
Дело в том, что толи я криворукий, толи лыжи не едут, но на планшете приложение получилось крайне медленным (10-12 fps для крайне простой картинки результат унылый), думаю, вина тут в руках и незнании матчасти. SDL — отличная библиотека в обеих реинкарнациях, и много действительно хороших игр использует её, а также портировано на андроид.
Потраченного времени на создание порта не жаль точно, получен определенный опыт и много положительных эмоций, когда игра взлетела. Тем, кто ещё раздумывает пробовать или нет, однозначно пробовать, не откладывайте на потом!
З.Ы. За развитием проекта всегда можно посмотреть тут.