Пакетные активы с зависимостью libGDX

Question

Я создаю движок для карточных игр на основе libGDX для многих похожих игр, которые планирую сделать.Вот как я планирую структурировать это: каждая игра - это отдельный проект, а движок - это зависимость, добавленная в модуль core.Сам движок будет иметь много ресурсов, таких как спрайты карт и другие элементы пользовательского интерфейса, и их тоже нужно включать.

Как я могу заставить эту структуру работать?Есть ли способ заставить зависимость включать свои активы?Альтернативой является дублирование всех ресурсов для каждой игры, что я не считаю очень эффективным.Также активы находятся в модуле android по умолчанию, которого нет в зависимости от движка (движок - это один модуль).Куда мне положить активы в модуль двигателя?

Answer 1

У нас есть настройка, которая кажется похожей на ту, которую вы описали выше, с отношением «многие к одному» проектов и активов.Вот потенциальный способ сделать это.

Основная идея такова:

1. Иметь единственную, авторитетную папку активов
2. Иметь индивидуальныйпроекты копируют эту папку в свои выходные данные сборки во время сборки
3. Выполните это с помощью задачи компиляции проекта dependsOn или задайте finalizedBy задачу копирования.
4. Убедитесь, что Android и другие проектысчастливы, копируя ресурсы туда, где внутренние файловые API libgdx ищут этот конкретный тип проекта.(Например, проекты android автоматически получают assets/, предварительно добавленный к URI, предоставленному Gdx.files.internal(). Этот шаг в большей степени зависит от вашей личной файловой структуры, поэтому может потребоваться небольшая настройка, чтобы получить правильный путь для всех проектов, ноне отчаивайтесь!

Примечание: Gradle должен автоматически отслеживать, действительно ли каталог ресурсов был изменен. Если ничего не было обновлено, то задачи копирования фактически станут бездействующими, что значительно ускоряет сборку для не первых запусков. Очевидно, что если вы выполните cleanAssets, как я упоминал ниже, то это не будет применяться.

Преимущество этого подхода (мне в любом случае), это то, что он больше не опирается на межпроектные ссылки или неконтролируемые манипуляции с путями к классам. Это просто реальные файлы в реальных каталогах. Недостатком является то, что он увеличивает используемое дисковое пространство, потому что вразличные проекты.

Следующее не является полным примером, но, мы надеемся, приведемвам достаточно, чтобы пройти.

Пример задачи копирования в действии. Этот конкретный пример берет каталог ресурсов из «основного» проекта и копирует его в проект Android.

android/build.gradle

task copyAssets(type: Copy) {
    from "../core/assets"
    into "./assets"
}

Пример зависимости сборки проекта Android от этой задачи:

android/build.gradle

afterEvaluate { project ->
    project.tasks.preDebugBuild {
        dependsOn copyAssets
    }

    project.tasks.preReleaseBuild {
        dependsOn cleanAssets
        finalizedBy copyAssets
    }
}

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

Пример зависимости задачи копирования для не-Android-проекта:

build {
    finalizedBy copyAssets
}

Если вы все еще застряли, дайте мне знать, где я постараюсь помочь.

Answer 2

Делай, как libgdx делает сам.В classpath включены ресурсы, такие как arial-15.fnt, который находится в основном проекте по адресу gdx / src / com / badlogic / gdx / utils /.Посмотрите на конструктор BitmapFont без параметров, как на него ссылаются.