Hello and welcome to the March 2023 update for openage.

As promised last time, this months update is mostly about inputs, managing those inputs and a tiny bit of event handling. It also contains small amounts of Gaben, so wait for the end of this post if you are into that. But first let us tell you something about the challenges of processing inputs.

Inputs in RTS

The problem with RTS is that they can allow a wide range of different mechanics and actions that have to be mapped to inputs. To complicate matters further, you usually don't control just one entity but many, which can also have their own actions available depending on ownership, state and various usage contexts. Furthermore, shortcut keys may be assigned multiple times in different contexts, so a naive mapping of key to action doesn't really work.

For openage, we have to take all this into account and additionally ensure that everything is as configurable as possible. Otherwise, support for multiple games will soon become very tricky.

openage's new input management

The solution implemented this month is to divide input processing into two stages: A low-level input system that handles/preprocesses raw inputs from the Qt window system and several high-level input handlers that translate the results into the actual (gameplay) actions or events.

Here is an overview for how that works internally:

Raw inputs from Qt (keyboard or mouse events) are first forwarded to the low-level input system (InputManager) via the window management. There, we do a little bit of preprocessing like stripping unnecessary information from the raw inputs. Context management, i.e. figuring out the currently active key binding, is also handled at this stage. If the input can be associated with an active key binding, it is sent to a high-level input system that performs an action with the input.

The high-level input systems are basically gateways to other components inside the engine, e.g. the gamestate or the renderer (Controller). Therefore, these are the places where the actual actions that have an effect on the game or visual output are performed. In the case of the engine controller - the gateway to the gamestate - the actions are functions that create an event for the gamestate. Which action is performed is decided by a simple lookup using the input event. The available actions will most likely be hardcoded until we introduce more scripting, but the current system allows them to be mapped to any key combination or mouse button.

With this feature done (or rather awaiting merging in PR #1501), the engine is now able to spawn a game entity with the gaben graphic on mouse click:

What's next?

Focus will now shift to implementing a few more input actions for creating gamestate events and implementing the gamestate internals along the way. The internal gamestate implementation for processing these events still needs a lot of work too, so we will probably try to implement one or two events at a time and see what else needs to be done along the way.

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