LINUX.ORG.RU

Процесс портирования инди-игры на Android OS

 , , , ,


3

2

В далёком 2011 году был такой малоизвестный конкурс для гиков, который назывался RIOT Tag-Team Coding Competition. Целью мероприятия было увеличение количества Homebrew-игр на различных карманных игровых устройствах на базе ядра Linux: Caanoo, GP2X Wiz, Pandora и Dingoo A320. Отличительной особенностью этого конкурса являлось то, что игру необходимо было разрабатывать командой, а игры от «одиночек» не принимались. Именно поэтому двое российских программистов «старой школы»: Don Miguel и Quasist решили объединить свои усилия и начали работать над эксклюзивным игровым проектом для актуальных на тот момент времени консолей от фирмы GPH: GP2X Wiz и Caanoo.

На мероприятии авторы представили 3D-игру под названием Adamant Armor Affection Adventure, которая была выполнена в популярной тогда стилистике Minecraft'а, но имела кучу отличий от него. Всего за три месяца (sic!) ребятам удалось сделать очень многое: разработать достаточно производительный и отлаженный 3D-движок для embedded-устройств, создать десяток разнообразных карт и монстров, записать звуки и музыку, сделать несколько режимов игры, собрать всё это воедино и достойно выступить на упомянутом выше конкурсе, заняв почётное и призовое второе место.

Вдохновившись как самой игрой, так и успехом и самоотверженным трудом её авторов, я решил «воздать славу» нашей отечественной Linux-тусовке и, в свободное от работы время, попивая чаёк, начал портировать её на Android OS.

На скриншоте я представил окружение, в котором выполнил эту работу. На старом ноутбуке, который удобно везде с собой таскать и не страшно потерять, стоит Arch Linux c KDE Plasma 5. Я люблю дефолт, поэтому ничего особо не кастомизировал. Разве что в KWin добавил сокрытие декораций у максимизированного окна. На втором скриншоте Eclipse IDE и портируемая игрушка, которая запущена в эмуляторе устройства. Основная работа проводилась именно в Eclipse. К сожалению, в Android Studio поддержка NDK-проектов до сих пор оставляет желать лучшего. Кроме того, для внесения правок в код движка я использовал Qt Creator IDE: [Скриншот]. На переднем плане окно игры, которая собрана нативно под GNU/Linux. Если кому интересно, то в комментариях к этому посту я выложу все свои наработки.

>>> Просмотр (1366x1536, 1835 Kb)

★★★★★

Проверено: JB ()
Последнее исправление: EXL (всего исправлений: 1)

Ответ на: комментарий от EXL

Вот, что меня напрягает в sdkmanager, так это его выхлоп --list: extras;m2reposi...er;1.0.0-alpha2. И хер поймешь, как выяснить полное имя пакета, что бы его установить.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Кстати, мне понравилось, что в Gradle можно автоматизировать подпись релизных APK-пакетов.

Можно добавить в build.gradle и gradle.properies нужные строки для доступа к ключу, по типу такого, но я нашёл для себя способ удобнее:

$ ./gradlew assembleRelease -Pandroid.injected.signing.store.file=$KEY_FILE \
                                           -Pandroid.injected.signing.store.password=$STORE_PWD \
                                           -Pandroid.injected.signing.key.alias=$KEY_ALIAS \
                                           -Pandroid.injected.signing.key.password=$KEY_PWD
EXL ★★★★★
() автор топика
Ответ на: комментарий от EXL

У меня так:

    signingConfigs {
        release {
            storeFile file("path_to.keystore")
            keyAlias "someAlias"
            storePassword System.getenv("key_store_password")
            keyPassword System.getenv("key_alias_password")
        }
    }


А переменные key_alias_password и key_store_password выставляются или на локальной машине разработчика, или на билд машине.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Да, у меня раньше было так же. Но я отказался от этого блока, потому что некоторые проекты кидаю на GitHub, а там не все клонирующие репозиторий будут разбираться с установкой этих переменных на своей машине. Оооочень странно, что Gradle даже при выполнении команды ./gradlew assembleDebug, почему-то всё равно ругается, что эти переменные, нужные только для релизной сборки, не определены.

EXL ★★★★★
() автор топика
Ответ на: комментарий от EXL

Оооочень странно, что Gradle даже при выполнении команды ./gradlew assembleDebug, почему-то всё равно ругается, что эти переменные, нужные только для релизной сборки, не определены.

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

andreyu ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.