New Bosses

After all this time, we finally have 2 bosses : The Earth Golem and the Ice Golem.

Earth Golem

Slow but a hard hitter, the Earth Golem excels at throwing rock based projectiles. Once it gets to half health, it’ll attack more frequently with tougher patterns to dodge.

Ice Golem

The golem residing on the icy planet Izit. Bit faster than the Earth Golem, and some of his attacks will slow players down. When at half health, will turn the middle row into ice, making it harder for players to evade attacks.

New backgrounds

As you may have noticed in the previous images, the battle background has changed, with the capability implemented to easily replace this background with several other parallax backgrounds I have available.. Similarly, the main menu background has also changed.

New Enemies

Finally, I’ve started leveraging existing enemies and doing palette swaps with modified behaviors to create new enemies. For the Ice World, we have 2 enemies so far.

Conclusion

That’s it for this month! Short and sweet.

Removal of the overworld sections

I’ve gone back and forth on the idea of including an isometric overworld section in between battles reminiscent of Megaman Battle network, the main inspriation for Calamity Sanctuary. At first there was none out of simplicity, then at one point as an experiment I started tinkering around with implementing isometric sections in the game, for various reasons, mainly because I wanted to see if I was capable of not only implementing everything needed to handle isometric logic, but also create interesting procedural maps. I also thought it would be a great way to differentiate myself from popular card based roguelites such as Slay the Spire and Monster Train, which include node based traversal on a map between battles.

In the end, the isometric sections turned out to be too much of a headache. My collision detection code was always wonky, the procedural generation, while definetly servicable, was difficult to tweak into something interesting, and in the end I couldn’t see what the isometric traversal actually brought to the game. After much debate, I ended up scrapping the idea, and despite my quest to differentiate myself my avoiding a map with nodes, that’s what I ended up implementing.

Adding a Map

To put it simply, this is basically the same as the Slay the Spire map. Create a 5x20 array, iterate over it a bunch of times while linking nodes together, and finally clean up to make things more interesting. Set each node type based on probabilaty and certain rules (e.g. no shops on the first floor, no repeated rooms for certain types, etc.) I still need to make it prettier, especially the background, but I already have a couple of neat things in place, such as animated icons and links.

I’m still debating on keeping the information at the bottom of the screen. One one hand, I think be able to see your deck composition at a glance is great for deck building, but on the other the current implementation is pretty ugly and takes up a good amount of screen real estate.

Added a World Screen

This is something I’ve wanted to add ever since I saw the amazing Pixel Planet Generator. The idea is that after each area boss, players will have a choice between different worlds, each with their own enemies, unique events, etc. This is simply another layer of decision making for players : Do they choose the more difficult planet in hopes of obtaining better cards, or do they visit the ice planet, since they picked up a couple of fire cards in the previous world? (Elemental weakness hasn’t been implemented yet, but it’s something I’ve been thinking about more and more lately)

Right now it’s mostly just for show, as all planets have the same encounter and loot tables, but everything is in place to make them eventually unique. Once I have a bigger enemy pool and when I have a better idea of how difficult each of the enemies are I’ll be better equipped to separate them into different tables based on difficulty.

Removed a lot of copyrighted material

Given that Calamity Sanctuary is inspired by Battle Network and the fact that I have no artistic capabilities, it was only natural for me to borrow copyrighted sprites when this game was barely a project. However, I’m now well past that point, and if I want to be able to show off more of the game, I really couldn’t continue having a lot of the major sprites be copyrighted material. While there are still some copyrighted assets remaining, I feel like I’ve removed a good amount of the most prominent ones, such as the main character, enemies, and a bunch of the card art. For the rest, I try to keep a list updated of assets that need to be replaced, so I can go though it and remove items one by one.

I’ve also given myself as a rule to avoid adding any more copyrighted material. Like tech debt, replacing the assets just ends up costing more time in the end, and I wouldn’t want to include any assets I don’t own inadvertently into the final product.

New Keyword - Combo

A new card keyword, “Combo” was added. When a card with Combo is played, it will add a new card to your hand. For example, the dagger card, when played, will not only swipe at the square in front of you, but will also add a “Throwing Dagger” card to your hand, which can deal damage across the screen. Combo cards incentivise build which want to play a lot of cards. There are also Combo specific cards and daemons, like the Specialist card, which increases the damage of cards created via Combo, and Resourceful, which will let you draw a card when you play a combo card.

The Combo keyword went through a couple of iterations before landing on it’s current implementation. The initial idea was that playing a Combo card would transform other identical cards in your hand into more powerful versions. There were however 2 major issues with this version :

• There were a bunch of technical and gameplay side effects to consider and I didn’t have a good answer for any of them. Would transformed cards revert to their original form when discarded? Do transformed versions of cards also transform “original” versions of cards when played? Was transforming a card considered discarding a drawing a card?
• I felt that this version incentivised too much just trying to obtain copies of the same card. Since Combo cards wouldn’t be very useful without at least one or two other copies in your hand, it was in player’s best interest to simply avoid picking other cards and going “all in” on one card in particular. I don’t think these would lead to very interesting situations, which is why I abandoned the idea.

New Enemies, Cards, and more

A lot more content was added in these past months. Here are a couple new enemy sprites and animations

Conclusion

A lot has been done since the beginning of the year, but like always, I feel like I very far from an actual finished product. Hell, I’m probably still pretty far from an acceptable Alpha build of the game. However, for those of you who are curious, you can always find the latest build on my Itch.io page. Thanks for reading.

val texture = Texture("player/overworld/player.png")

There are many problems with this approach, notably :

• It’s easy to introduce a typo, which will probably crash at runtime when trying to fetch the asset.

• It’s hard to know if the asset is already being used somewhere else. Sure, you can ctrl+f “player/overworld/player.png” but if you did something like this you won’t find your asset :

  const val PLAYER_FOLDER = "player/"
  val texture = Texture("$PLAYER_FOLDER/overworld/player.png")
  

Since we know all of our assets at compile time, what if we could generate symbols to represent our asset paths? We could even keep the same hierarchy as our file system. Then, instead pf providing a hardcoded string, we could do something like this:

object Player {
    object Overworld {
        const val player = "player/overworld/player.png"
    }
}
// [...]
val texture = Texture(Player.Overworld.player)

Let’s use Gradle to create a task that we can run whenever we add new assets to our project that will let us generate this file.

Creating a Gradle Task

Creating a Gradle Task is as easy as writing task yourTaskName() {} in your build.gradle file. Gradle tasks let you do many powerful things, like generate code at compile time, publish your project to a service like Itch.io, and more. Leveraging Gradle can make routine tasks completely automated.

Lets create a dummy task to make sure everything is working correctly. Navigate to your top level build.gradle file, and inside the project(":core") section, write the following task

task generateAssets() {
    println("Hello world!")
}

You should see the ‘Load Gradle Changes’ button appear in the top right corner (it looks something like this ) Hit that button to let Gradle know you’ve made some changes. If everything goes well, you should be able to see your new task by navigating in the Gradle tab in the top right corner, and searching for your new task (regenerateImages in the pic below). Double click that and you should see “Hello world” print in the console below.

Generating Some Code

Code generation can seem like a daunting task, but in reality it’s just writing text to a file. Lets begin by declaring a couple of constants

task generateAssets() {
    def project = '../core' // Core project folder, should probably be kept as-is
    def assetsFolder = '../core/assets' // Assets folder, should probably be kept as-is
    def source = 'src' // Source folder, should probably be kept as-is
    def pack = 'com.mypack.assets' // package name of the file to be generate. Replace with your top level package name
    def fileName = 'Assets.kt' // File name, feel free to rename as needed.
    
    def newLine = System.getProperty("line.separator") // OS-agnostic new line, will be used in code generation
    def builder = new StringBuilder() // This will be responsible for building up the 'Assets.kt' file
}

So far we’ve just defined a couple of things related to our project. Even if we end up only using these once, I like to declare them all at the beginning, so it’s easier if I end up wanting to move things around, or if I want to copy this for another similar task, just with different parameters.

Lets start generating out Kotlin code. We want to end up with something like this:

package com.mypack.assets

// Generated file, do not modify

object Assets {
    
}

We could use a specialized library for code generation such as Kotlin Poet but for a simple case like this one, it’s a good idea to just write it out ourselves.

task generateAssets() {
    def project = '../core' // Core project folder, should probably be kept as-is
    def assetsFolder = '../core/assets' // Assets folder, should probably be kept as-is
    def source = 'src' // Source folder, should probably be kept as-is
    def pack = 'com.mypack.assets' // package name of the file to be generate. Replace with your top level package name
    def fileName = 'Assets.kt' // File name, feel free to rename as needed.
    def soundExtensions = ['.mp3', '.wav'] // Accepted sound types, feel free to modify
    def imageExtensions = ['.png', '.jpg', '.jpeg']  // Accepted image types, feel free to modify.
    def invalidChars = ['-', '.', ' ', ',']    
    def newLine = System.getProperty("line.separator") // OS-agnostic new line, will be used in code generation
    def builder = new StringBuilder() // This will be responsible for building up the 'Assets.kt' file
    
    builder.append("""package ${pack}

/** Generated from the assets folder. */
object Assets { 

""")
    // TODO asset generation
    builder.append(newLine).append("}")
}

All there’s left to do to actually see this file is writing the contents of builder to an actual file.

task generateAssets() {
    def project = '../core' // Core project folder, should probably be kept as-is
    def assetsFolder = '../core/assets' // Assets folder, should probably be kept as-is
    def source = 'src' // Source folder, should probably be kept as-is
    def pack = 'com.mypack.assets' // package name of the file to be generate. Replace with your top level package name
    def fileName = 'Assets.kt' // File name, feel free to rename as needed.
    def soundExtensions = ['.mp3', '.wav'] // Accepted sound types, feel free to modify
    def imageExtensions = ['.png', '.jpg', '.jpeg']  // Accepted image types, feel free to modify.
    def invalidChars = ['-', '.', ' ', ',']
    def newLine = System.getProperty("line.separator") // OS-agnostic new line, will be used in code generation
    def builder = new StringBuilder() // This will be responsible for building up the 'Assets.kt' file
    
    builder.append("""package ${pack}

/** Generated from the assets folder. */
object Assets { 

""")
    // TODO asset generation
    builder.append(newLine).append("}")
    // Write to file
    def path = project + File.separator + source + File.separator + pack.replace(".", File.separator) +
        File.separator + fileName // ../code/src/com/mypack/assets/Assets.kt
    println("Saving Assets at ${path}...")
    def assetsFile = file(path) // Point to the file
    delete assetsFile // delete the existing file if there is one.
    assetsFile.getParentFile().mkdirs() // Make the necessary directories if they haven't been created yet.
    assetsFile.createNewFile() // Create a new file
    assetsFile << builder << newLine // write the contents of 'builder' to the new file, ending with a newLine character.
}

Hit the ‘Load Gradle Changes’ button, and rerun your task. If everything is correct, you should see your new Assets.kt generated file.

Walking Down the File Structure

We’re able to generate a Kotlin source file with an empty Assets object, now we need to add our asset paths to it. Before doing that, lets write a couple of useful local functions to make things clearer.

// previous lines ommited for clarity
ext.capitalize = { String s ->
    return s.substring(0, 1).toUpperCase() + s.substring(1)
}
ext.isImage = { String name ->
    imageExtensions.any { name.contains(it) }
}
ext.isSound = { String name ->
    return soundExtensions.any { name.contains(it) }
}
ext.isValidAsset = { String name ->
    return isImage(name) || isSound(name)
}
ext.cleanImage = { String name ->
    def newName = name
    (imageExtensions + soundExtensions).forEach {
        newName = newName.replace(it, "")
    }
    invalidChars.forEach {
        newName = newName.replace(it, "_")
    }
    // We cannot start a symbol with a number, so we add 'n' to the begining.
    if (Character.isDigit(newName.charAt(0))) {
        newName = "n$newName"
    }
    // We append _sound to a sound, otherwise we would generate duplicate symbols if an image and sound shared the same filename
    if (isSound(name)) {
        newName = newName + "_sound"
    }
    return newName
}

Finally, we’re going to need to write the function that actually generates the strings that will contain the paths to our assets. We’re going to write a function called printFiles(files: File[]) whose goal is to take a list of files (Note: A file can mean an actual file or a directory) and generate the corresponding code. Here’s the gist of it : The function iterates on each file:

• If it’s an actual file, and it’s a valid asset, add a new string to the string builder.
• If it’s a directory, append the beginning of a new object to the string builder, call printFiles recursively with the files in this directory, and finally append a } to the string builder to complete the object definition.

Here’s what that looks like :

// previous lines ommited for clarity
ext.printFile = { File[] files ->
    files.each {
        if (it.file && isValidAsset(it.name)) {
            // This is an asset, create a new string constant
            def varName = cleanImage(it.name)
            def varPath = it.canonicalPath.split("assets")[1].replace('\\', '/').substring(1)
            builder.append(newLine).append("const val $varName = \"").append(varPath).append('"')
        } else if (it.isDirectory()) {
            // Create a new object, and call this function recursively
            builder.append("""
    object ${cleanImage(capitalize(it.name))} {""")
            printFile(it.listFiles())
            builder.append("}")
        }
    }
}

All that’s left now is to call this new function where we previously wrote // TODO asset generation 2 code blocks ago, and voilà, we’re done writing our Gradle task! Here’s what it looks like put all together :

task generateAssets() {
    def project = '../core' // Core project folder, should probably be kept as-is
    def assetsFolder = '../core/assets' // Assets folder, should probably be kept as-is
    def source = 'src' // Source folder, should probably be kept as-is
    def pack = 'com.mypack.assets' // package name of the file to be generate. Replace with your top level package name
    def fileName = 'Assets.kt' // File name, feel free to rename as needed.
    def soundExtensions = ['.mp3', '.wav'] // Accepted sound types, feel free to modify
    def imageExtensions = ['.png', '.jpg', '.jpeg']  // Accepted image types, feel free to modify.
    def invalidChars = ['-', '.', ' ', ',']
    def newLine = System.getProperty("line.separator") // OS-agnostic new line, will be used in code generation
    def builder = new StringBuilder() // This will be responsible for building up the 'Assets.kt' file
    
    builder.append("""package ${pack}

    /** Generated from the assets folder. */
    object Assets { 

    """)
    ext.capitalize = { String s ->
        return s.substring(0, 1).toUpperCase() + s.substring(1)
    }
    ext.isImage = { String name ->
        imageExtensions.any { name.contains(it) }
    }
    ext.isSound = { String name ->
        return soundExtensions.any { name.contains(it) }
    }
    ext.isValidAsset = { String name ->
        return isImage(name) || isSound(name)
    }
    ext.cleanImage = { String name ->
        def newName = name
        (imageExtensions + soundExtensions).forEach {
            newName = newName.replace(it, "")
        }
        invalidChars.forEach {
            newName = newName.replace(it, "_")
        }
        if (Character.isDigit(newName.charAt(0))) {
            newName = "n$newName"
        }
        if (isSound(name)) {
            newName = newName + "_sound"
        }
        return newName
    }
    ext.printFile = { File[] files ->
        files.each {
            if (it.file && isValidAsset(it.name)) {
                // This is an asset, create a new string constant
                def varName = cleanImage(it.name)
                def varPath = it.canonicalPath.split("assets")[1].replace('\\', '/').substring(1)
                builder.append(newLine).append("const val $varName = \"").append(varPath).append('"')
            } else if (it.isDirectory()) {
                // Create a new object, and call this function recursively
                builder.append("""
        object ${cleanImage(capitalize(it.name))} {""")
                printFile(it.listFiles())
                builder.append("}")
            }
        }
    }
    printFile(file(assetsFolder).listFiles())
    builder.append(newLine).append("}")
    // Write to file
    def path = project + File.separator + source + File.separator + pack.replace(".", File.separator) +
        File.separator + fileName // ../code/src/com/mypack/assets/Assets.kt
    println("Saving Assets at ${path}...")
    def assetsFile = file(path) // Point to the file
    delete assetsFile // delete the existing file if there is one.
    assetsFile.getParentFile().mkdirs() // Make the necessary directories if they haven't been created yet.
    assetsFile.createNewFile() // Create a new file
    assetsFile << builder << newLine // write the contents of 'builder' to the new file, ending with a newLine character.
}

You’ll notice that the indentation and general formatting in the generated code is a bit off. Personally I don’t think it matters since you’ll never really be looking directly at the code, but you could easily modify the previous code block to take indentation into account. Nonetheless, here’s what your generated code should look like (after applying auto formatting in IntelliJ) :

object Assets {
    object Battle {
        const val background = "battle/background.png"
        const val blue_bottom = "battle/blue_bottom.png"
        const val red_bottom = "battle/red_bottom.png"
        const val red_cracked_tile = "battle/red_cracked_tile.png"
        const val red_empty_tile = "battle/red_empty_tile.png"
        const val red_tile = "battle/red_tile.png"

        object Results {
            const val background = "battle/results/background.png"
            const val background_big = "battle/results/background_big.png"
            const val failure = "battle/results/failure.png"
            const val success = "battle/results/success.png"
        }
}

You should now be able to use these paths anywhere in your project that uses assets.

class MenuScreen: KtxScreen, KtxInputAdapter {
  override fun show() {
      super.show()
      val inputProcessor = Gdx.input.inputProcessor
      val multiplexer = InputMultiplexer(this, inputProcessor)
      Gdx.input.inputProcessor = multiplexer
  }
  
  override fun keyDown(keycode: Int): Boolean {
      when(keycode) {
        Input.Keys.E -> {
          // Do Something when 'e' key is pressed
        }
        else -> return false
      }
    return true
  }
  
  override fun hide() {
      super.hide()
      (Gdx.input.inputProcessor as? InputMultiplexer)?.removeProcessor(this)
  }
}

While this might be sufficient for a simple game, hardcoded key inputs into a screen gives us hardly any flexibility. If for example we wanted to replace all actions currently handled with the ‘e’ key by the ‘q’ key, we’d have to go over all of our screens and replace it. Even worse, this doesn’t allow users to remap keys themselves, since we’ve tightly coupled our desired action to the ‘se key.

How about if instead of listening to keys, we listened to actions instead? Let’s replace keyDown with onAction and turn it into something like this :

override fun onAction(action: Action): Boolean {
      when(action) {
        INTERACT -> {
          // handle interact action
        }
        else -> return false
      }
  return true
  }

Let’s see how to get something like this up and running.

Creating our own InputProcessor

We’re going to need to place something between LibGDX’s input processor and our screens to intercept user input and replace it with our actions. We’ll call this InputActionManager.

class InputActionManager : KtxInputAdapter {

    fun init() {
        Gdx.input.inputProcessor = this
    }
  
  enum class InputAction {
        UP,
        DOWN,
        LEFT,
        RIGHT,
        INTERACT,
    }
}

Screens won’t bind to the Gdx.input.inputProcessor anymore. Instead, the sole InputAdapter will be this class. Later on, we’ll add the screens as listeners of this class to be able to receive events.

We’ve also added an InputAction enum, which represent the different actions we want to handle.

Mapping Inputs to our Actions

Let’s add a hash map to map Input to Actions :

private val keyboardMappings = HashMap<Int, InputAction>().apply {
        put(Input.Keys.UP, InputAction.UP)
        put(Input.Keys.DOWN, InputAction.DOWN)
        put(Input.Keys.LEFT, InputAction.LEFT)
        put(Input.Keys.RIGHT, InputAction.RIGHT)
        put(Input.Keys.E, InputAction.INTERACT)
    }

Now we can map our input to our actions whenever the user presses an input.

override fun keyDown(keycode: Int): Boolean {
    val action = keyboardMappings[keycode]
    // Notify listeners of action
}

Introducing the Action Listener

We need a way to notify screens of actions. We’ll create an interface called ActionListener which screens will be able to implement if they want to handle input.

interface ActionListener {
    fun onAction(action: InputAction): Boolean
}

The InputActionManager will keep a reference to all ActionListeners who have subscribed, and propagate the Action until an ActionListener handles the action.

class InputActionManager : KtxInputAdapter {
  private val actionListeners = ArrayList<ActionListener>()
  
  private val keyboardMappings = HashMap<Int, InputAction>().apply {
        put(Input.Keys.UP, InputAction.UP)
        put(Input.Keys.DOWN, InputAction.DOWN)
        put(Input.Keys.LEFT, InputAction.LEFT)
        put(Input.Keys.RIGHT, InputAction.RIGHT)
        put(Input.Keys.E, InputAction.INTERACT)
  }
  
  fun subscribe(listener: ActionListener) {
      actionListeners.add(0, listener) // Latest subscribers get priority
  }
  
  fun unsubscribe(listener: ActionListener) {
      actionListeners.remove(listener)
  }
  
  override fun keyDown(keycode: Int): Boolean {
      val action = keyboardMappings[keycode]
      // Notify listeners of action
      action?.let {
          if (listener.onAction(action)) return true
      } ?: debug { "No Action mapped to $keycode" }
      return false
  }
}

We’ve added methods for adding and removing subscribers, and we’ve created the missing link for notifying subscribers of user actions. We iterate over all subscribers, until we find one which handles the corresponding action. This lets us have multiple classes handling different inputs without the need for a multiplexer. I also added a debug message to notify the dev if they press a key that has no mapped Action.

Implementing an Action Listener

The final piece of the puzzle : implementing an ActionListener and having it subscribe to our new InputActionManager. You’re going to need a way for your objects to access your InputActionManager. Here I’m using KTX-Inject to inject it via dependancy injection, but you could also have it as a static object if you prefer.

class MenuScreen: KtxScreen, ActionListener {
  private val inputActionManager: InputActionManager = MainContext.inject()
  override fun show() {
      super.show()
      inputActionManager.subscribe(this)
  }
  
  override fun onAction(action: InputAction): Boolean {
      when(action) {
        INTERACT -> {
          // Handle interact action
        }
        else -> return false
      }
    return true
  }
  
  override fun hide() {
      super.hide()
      inputActionManager.unsubscribe(this)
  }
}

Like with the input processor, we must subscribe when we want to receive actions, and unsubscribe when we’re done handling actions. in the onAction method, we can handle the actions we want, being sure to return true when we want to consume an action and false when we want to keep propagating the action to let others potentially handle it.

So What was the Point of it all?

By decoupling our input we’ve done many things. We now have one central point for input, instead of it being distributed everywhere. That lets us do neat things like disabling all or certain actions if need be, by adding logic in our InputActionManager to keep a list of disabled actions and avoid propagating them. We’ve also made it much easier to implement control remapping. Instead of hardcoding our keyboardMappings hash map, we could save that information to a local file, and add an option screen which lets us modify it.

Adding controller support will be much easier, since listeners don’t need to listen to both keyboard events and controller events. Just have your inputActionManager listen to controller input events and map those to the same Actions as before, that way your listeners don’t need to be made aware of the actual input device, just the desired action.

Do you want to show a demo screen where the player is automatically controlled? While out of scope for this article, here’s the general idea :

• Hide the inputActionManager implementation behind an interface.
• Create a new implementation of this interface
  • This implementation will propage actions in a certain order, instead of mapping inputs to actions
• Inject this new implementation in your “Demo Screen” instead of the default implementation

You could even replace the demo InputActionManager by the real one when the player presses an input, letting them take control at any moment during the demo!

Things to Improve

Here are a couple of things you could add to make the InputActionManager more feature complete :

• Add the possibility to disable certain or all inputs
• Let listeners listen to both onKeyDown and onKeyUp
• Add controller support

val manager = AssetManager()
manager.load("data/mytexture.png", Texture::class.java)
/*
 * Load all assets that we called 'load' on.
 * As long as update returns false, we havn't finished loading
 */
while (!manager.update()) {
  // do nothing
}
// Use the asset
val texture: Texture = manager.get("data/mytexture.png", Texture::class.java);

While using the Asset Manager is much better than loading them on the fly, managing the load and get calls can very quickly start to get messy, not to mention all of the redundant code. Ideally, we would like to declare an asset once, and have the engine handle the loading and whatnot for us.

Proposed solution

@Asset
val textureAsset = AssetDescriptor("data/myTexture.png", Texture::class.java)

val texture: Texture = texture.get()

We’ve introduced the @Asset annotation, which will let us tell our engine that the following field is an asset to be loaded by our asset manager. Here is what the annotation declaration looks like.

@Target(AnnotationTarget.FIELD)
annotation class Asset()

By using this simple annotation we’ve done two things. We avoid having to drag along our asset manager wherever we want to declare assets, and we’ve created one single reference to handle both telling our asset manager to load the object and also serving as a reference point to obtain the actual asset.

However, simply adding the annotation won’t put everything into motion. Let’s see how we actually load the assets at startup.

Loading the Assets

Now that we’ve annotated our fields, we need to fetch this information and queue up the loading. Let’s take a look.

private fun loadAllAssets() {
  val reflection = MainContext.inject<Reflections>()
  val assets = reflection
  .getFieldsAnnotatedWith(Asset::class.java)
  .mapNotNull {
    it.isAccessible = true // Workaround for having this work despite wanting to limit scope of certain assets
    it.get(null) as? AssetDescriptor<*>
  }
  
  assets.forEach {
    assetManager.load(it)
  }
}

This basically replaces all of our load calls from the initial method. We’re using the org.reflections:reflections library to fetch all fields with the @Asset annotation as AssetDescriptors and loading them all. Although I haven’t talked about it so far, AssetDescription is an existing LibGDX class which basically holds the path and filetype information of an asset.

Once we’ve queued up the assets, we need to start loading them all. This hasn’t changed from before so we simply call assetManager.update() each frame, which returns true if we’re finished loading everything.

Obtaining the Assets

The final piece of the puzzle is the get extension function, which lets us obtain the actual asset via the same reference with annotated earlier.

fun <T> AssetDescriptor<T>.get(): T {
    return assetManager.get(this)
}

Using generics lets us omit the actual class name when permitted, which is useful in keeping things short and concise.

Putting it all together

Let’s look at how it all comes together. For reuse in all my projects, I’ve wrapped everything found here in my own AssetManager class. Here is what it looks like (certain lines omited or changed for brevity and completeness).

// package ...
import com.badlogic.gdx.assets.AssetDescriptor
import ktx.freetype.registerFreeTypeFontLoaders
import org.reflections.Reflections
import com.badlogic.gdx.assets.AssetManager as GdxAssetManager

class AssetManager {

    init {
        assetManager.registerFreeTypeFontLoaders()
        loadAllAssets()
    }

    fun install() {
        assetManager.registerFreeTypeFontLoaders()
        loadAllAssets()
    }

    fun update(): Boolean {
        return assetManager.update()
    }

    fun progress(): Float {
        return assetManager.progress
    }

    private fun loadAllAssets() {
        val reflection = Reflections("com.xanadu.section", FieldAnnotationsScanner(), TypeAnnotationsScanner(), SubTypesScanner())
        val assets = reflection
                .getFieldsAnnotatedWith(Asset::class.java)
                .mapNotNull {
                    it.isAccessible = true
                    it.get(null) as? AssetDescriptor<*>
                }
        assets.forEach {
            assetManager.load(it)
        }
    }

    companion object {
        private val assetManager: GdxAssetManager = GdxAssetManager()
        
        fun <T> AssetDescriptor<T>.get(): T {
            return assetManager.get(this)
        }
    }
}

@Target(AnnotationTarget.FIELD)
annotation class Asset()

Improvements for the Future

• Right now we’re using reflection at runtime to obtain all the assets. Ideally we should be generating this code with something like Kotlin Poet at compile time, as bigger projects will take some time finding all of our annotated fields.
• Our @Asset annotation is very simple, we could enrich it with some helpful functionalities. For example, we could add a Level enum to denote which levels of our game uses this asset, so instead of loading all assets at the beginning, we could load necessary assets at the beginning of each level, to avoid a large load time at startup.