This week, I focused on bringing keymapper support to three engines: Sword25, Teenagent, and NGI. Each had its own quirks, but none were too complex—so I was able to make steady progress across the board.
Sword25
The Sword25 engine uses script-driven input handling. That made things straightforward—no refactoring needed.
My job here was mostly investigative: figure out what each key does and document it for the keymapper. Since input behavior was defined in scripts, I didn’t need to touch much engine-level code. The entire process was smooth and quick.
Teenagent
Teenagent was also fairly simple. It involved defining a few custom actions for specific keys and setting up mouse input. The engine doesn’t have complex input modes or conditionally processed input, so once I identified the key behaviors, wiring up the keymapper didn’t take long.
NGI
The NGI engine was the most challenging of the three this week. While it didn’t introduce any new types of problems, it did have more keys and more complexity around where input is processed.
One big issue: keys pressed during menus, modals, or intros weren’t processed through the same input flow as in-game actions. That meant keymapper actions would either:
-
Be ignored in certain contexts, or worse…
-
Be interpreted in places they shouldn’t be
To fix this, I had to carefully trace the engine’s input handling paths and add logic to enable or disable the keymapper at the right times. Most of my time on NGI was spent understanding those flows and placing the toggles precisely.
Once that was in place, implementing custom actions and mapping key behaviors was straightforward.
Wrap-Up
This week, I:
- Implemented keymapper support for Sword25, Teenagent, and NGI
- Got the NGI keymapper PR merged
- Got the keymapper action label normalization PR merged
Next week, I’ll continue this momentum and explore new engines.