Welcome to another monthly update to the openage development. This month's progress consisted of a lot of cleanup and bug fixing tasks but there were also a variety of small features added to the engine. So without further ado, let's jump right in.

Modpack Loading

While the openage converter could already generate modpacks from the original game assets for a long time, the engine couldn't really understand them yet (except for loading/showing single animations for testing). This has been changed now with the addition of a simple internal mod manager as well as loaders for getting game data into the gamestate's nyan database. At this point, the gamestate still doesn't have any logic that can do something meaningful with the data. However, it gets us one step closer to testing features with "real" data instead of the more generic tests and demos that we've shown before. This also means that you might see more AoE2 or SWGB visuals in future news posts!

The engine's configuration is now also loaded as a modpack which is simply called engine. Currently, it contains the bindings for the openage data/modding API referenced by other modpacks. Later, it will probably include other bindings for scripting and GUI. engine is always implicitely available to other modpacks and can be used to interface with the engine API. Storing the engine confguration as a modpack could also allow basic modding of the low-level engine internals, although we'll have to see how well that works in the future.

Renderer Features

Our renderer can now properly handle drawing directions (or angles, respectively) of unit sprites. Depending on the direction a unit is facing in the scene, the renderer will now select the correct subtexture coordinates from the animation's sprite sheet and pass it the the shaders. You can see here how the result looks for one of our test assets (taken from here under CC-BY 4.0):

Of course, it also works for animations from AoE2:

What's probably less noticeable in the videos is that the renderer is additionally able to handled mirroring of sprites, i.e. flipping sprites alongside their X or Y axis. The feature is implemented directly in the display shader and using it should therefore produce very little overhead.

Mirroring is commonly used to save space since the sprite sheet only has to contain sprites for half the available directions. The sprites for the remaining directions can then be inferred from the vertically opposite direction. For example, assets in the original AoE2 release only contained sprites for 5 out of 8 directions. and mirrored the remaining 3.

What's next?

Since the engine now supports modpack loading, we can start working on the gamestate internals using actual game data from the converted assets. The first step will be to initialize the various abilities of a game entity in the engine with information from the nyan database. We will probably start with very simple abilities like Idle, Position, Live, and maybe Move and work our way to the more complex abilities later.

Questions?

Any more questions? Let us know and discuss those ideas by visiting our subreddit /r/openage!

As always, if you want to reach us directly in the dev chatroom:

• Matrix: #sfttech:matrix.org