Welcome to another monthly openage update. This month there's been a lot of progress inside the gamestate, so there is much to show and even more to discuss.

Modpack Loading - Part 2

Since our previous update, modpack loading and game data handling inside the engine's gamestate have been greatly extended. The biggest advancement in this regard is that the engine can now create actual units - or game entities as we call them - from the information in the nyan database. Additionally, the available game data from the modpacks can now be used in the game simulation routines. Right now, game entities can do very little and therefore still use a very limited amount of the data, but it's a step forward from having hardcoded test entities.

Here you can see how different entities from the AoE1, AoE2 and SWGB modpacks are created and displayed from modpack data:

Note that this example contains both buildings and units as game entities. Internally, openage doesn't differentiate between different unit types and instead uses composition to define what each game entity can do. This means that when a game entity is spawned, the engine essentially "assembles" its capabilities by assigning properties and abilities (e.g. Move, Turn, Idle, Live, etc.) based on what is defined for the game entity in the modpack.

Rudimentary Game Logic

Now that we can get game entities into the game world, we can start playing around with them. Currently, there are only two things a game entity can do: Idle or Move. This doesn't sound like much, but more stuff will soon be added to the gamestate one by one. Most of this months work went into the architecture to support more complex action states of game entities.

In openage, the action state of a unit is not directly driven by commands from the input system but by a node-based flow graph with task nodes, branching paths, and wait states for events. Commands mainly signal where to go next in the graph. We do things this way because commands in RTS usually do not trigger one specific action but start entire action chains. For example, a Gather command in AoE2 does not just involve the process of slurping up resources; it also requires moving to the resource, automatically finding a dropoff place and actually depositing the resources in the player's storage.

Below you can see an example of what such a flow graph looks like. The example flow graph is currently hardcoded in the engine and assigned to every game entity. In the future, we want these flow graphs to be configurable per game entity (or game entity type), so that every unit could display different behaviour.

Operating on the flow graph in the engine then looks like this:

What's next?

The flow graph logic in the gamestate was the last major component missing in the new engine architecture. Since that is almost done, we will probably prepare a new release soon containing all the changes made over the last months. Before that, we have to clean up all the rough edges in the code and make the features more "presentable" to those who haven't followed the update posts.

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