Categories
Final Report

GSoC Final Report

My project focused on extending ScummVM’s Keymapper system to a larger number of game engines. The Keymapper allows players to remap controls to their liking, but many engines in ScummVM still relied on fixed input handling. By integrating the Keymapper into more engines, the project set out to improve accessibility, provide a consistent user experience, and give players greater flexibility in how they play.


What I did:
I added Keymapper support to 24 engines, fixed a few bugs encountered during the implementations, and helped standardize keymapper action descriptions. This standardization reduces the number of unique strings in the codebase, easing the workload for translators.


The current state:
Keymapper support is now available in 24 additional engines, allowing players to remap controls in a wide range of games that previously relied on fixed input. Several of my pull requests have already been merged into the main ScummVM codebase, and the remaining ones are under review. Overall, the project goals have been successfully achieved, and the improvements are now part of ScummVM’s ongoing development.


What’s left to do:
All goals outlined in my proposal have been completed, I added Keymapper support to the 23(The first one was not part of proposal) engines I had committed to. Beyond the scope of the proposal, there are still around 40 engines in ScummVM without Keymapper support, which could be future work for anyone interested in continuing this effort.


List of PRs:

  1. Toltecs keymapper: Pull Request
  2. Sludge keymapper: Pull Request
  3. Supernova keymapper: Pull Request
  4. Voyeur keymapper: Pull Request
  5. Titanic keymapper: Pull Request
  6. Normalize keymapper action descriptions: Pull Request
  7. Sword25 keymapper: Pull Request
  8. TeenAgent keymapper: Pull Request
  9. NGI keymapper: Pull Request
  10. Buried keymapper: Pull Request
  11. Access keymapper: Pull Request
  12. EFH keymapper: Pull Request
  13. Sherlock keymapper: Pull Request
  14. Neverhood keymapper: Pull Request
  15. Prince keymapper: Pull Request
  16. Lab keymapper: Pull Request
  17. Petka keymapper: Pull Request
  18. Queen keymapper: Pull Request
  19. Fix capitalization in Queen keymapper action descriptions: Pull Request
  20. Pink keymapper: Pull Request
  21. Drascula keymapper: Pull Request
  22. Chamber keymapper: Pull Request
  23. Make EFH keymapper table use POD and avoid global constructors: Pull Request
  24. Hypno keymapper: Pull Request
  25. DM keymapper: Pull Request
  26. Private keymapper: Pull Request

Any challenges or important things you learned during the project:
Each engine in ScummVM handles input differently, so I had to study and adapt to new codebases before adding Keymapper support. In doing so, I often uncovered and fixed unrelated bugs. Working on a new engine every 3–4 days also greatly improved my ability to read, understand, and modify existing code, and gave me confidence in working with large, mature projects.


Conclusion:
This project successfully achieved its goals by bringing Keymapper support to 24 engines in ScummVM, making input more flexible and accessible for players. Along the way, I learned how to work effectively with large codebases and contribute to a mature open-source project. I’d like to thank my mentors and the ScummVM team for their guidance and support, and GSoC for giving me the opportunity to work on a project that will benefit both developers and players.

Categories
week 12

Week 12: Keymapper Support for Hypno and Dungeon Master

This week I worked on the Hypno and Dungeon Master engines. I also got my Chamber keymapper PR merged 🎉.


Hypno Engine

Working on the Hypno engine felt a bit nostalgic—it was actually the first engine I touched in ScummVM when I fixed a small bug as an intake task for GSoC.

The engine supports three different games, each with its own input handling. Because of this, I had to create separate keymaps for each game, rather than a single shared one.

Apart from that, the implementation was fairly straightforward. The main tasks were:

  • Disabling the keymapper in certain sections where the game uses full keyboard input

  • Enabling/disabling keymaps for some of the menus

Nothing particularly tricky, but it was nice to revisit the engine where my GSoC journey began.


Dungeon Master Engine

Dungeon Master was another unannounced engine that I added keymapper support to. Fortunately, it didn’t have any blocking bugs or missing features, so I was able to test it thoroughly without issues.

The engine came with a decent number of keys to map, but overall the process was smooth and didn’t pose any significant difficulties.


Wrap-Up

This week, I:

  • Added keymapper support for Hypno and Dungeon Master

  • Got my Chamber PR merged 🎉

Categories
Week 11

Week 11: Keymapper Support for Drascula and Chamber

This week I worked on two more engines: Drascula and Chamber. I also got my PRs for the Pink, EFH, Drascula, and Lab engines merged 🎉.


Drascula Engine

The Drascula engine wasn’t particularly difficult, but it came with a decent number of keys and keymaps. The process was straightforward overall, though it was somewhat time-consuming due to the sheer amount of keys that needed replacing.

One interesting aspect of this engine was that I came across my first in-game easter egg while testing the key actions—definitely a fun surprise during the work.

I also had to handle enabling and disabling keymaps in a few spots. Nothing too complicated, but still took time.


Chamber Engine

Chamber became my second unannounced engine (after Sludge engine) where I added keymapper support. Normally, I’ve been focusing only on announced and tested engines, to avoid running into unrelated bugs that might interfere with the keymapper work.

In this case, I only realized the engine was unannounced after I had already started working on it. Since I didn’t encounter any gameplay-breaking issues, I decided to go ahead and finish the keymapper implementation.

The work itself was on the simpler side. Chamber only had a handful of keys, and just a single keymap that needed to be toggled on and off. Figuring this out was quick and straightforward.


Wrap-Up

This week, I:

  • Added keymapper support for Drascula and Chamber

  • Got my Pink, EFH, Drascula, and Lab PRs merged 🎉

Categories
Week 10

Week 10: Queen and Pink Engines

This week I worked on adding keymapper support to the Queen and Pink engines. On top of that, I also got my Neverhood, Prince, and Queen keymapper PRs merged.


Queen Engine

The Queen engine was moderately challenging. It came with a good number of keys, but the real twist was the variable keybinds for some actions. these depended on the language of the player’s copy of the game. This was somewhat similar to what I encountered earlier in the Sherlock engine.

Another tricky part was that the keybind selection logic was embedded deep in the engine code. To make it compatible with the keymapper, I had to refactor the code so that the language-based key selection happened in the keymapper section instead. This made it accessible for usage in the keymapper initialization.

Some sections of the game also needed keymapper toggling. those were relatively straightforward to set up.


Pink Engine

Pink, at first glance, seemed simpler—fewer than 10 keys in total. But as always, appearances can be deceiving.

In the game, you can’t move your character freely. Movement only happens when you click an interactable object or character, at which point the character walks to the target and interacts with it automatically.

The key actions didn’t just trigger standard gameplay—they altered this entire interaction sequence. For example:

  • One action skips the walking animation entirely.

  • Another lets you walk to the target but cancels the interaction.

  • Yet another skips both walking and interaction, simply teleporting you there.

There were also keys that modified or skipped the sequence that plays when you interact with a target—like skipping a conversation, skipping part of it, or even restarting a dialog from the beginning if you missed something.

Identifying exactly what each key did was the hardest part here, but once that was figured out, mapping them to the keymapper went smoothly.


Wrap-Up

This week, I:

  • Added keymapper support for the Queen and Pink engines

  • Got my Neverhood, Prince, and Queen PRs merged 🎉

Categories
Week 9

Week 9: Lab and Petka

This week, I focused on adding keymapper support to two engines: Lab (used by The Labyrinth of Time) and Petka (used by Red Comrades 1 and 2)


Lab Engine

The Lab engine was moderately complex due to the game’s dual-interface design. The Labyrinth of Time features two main interaction modes: a point-and-click exploration interface and an inventory screen. This meant I had to track which interface the player was currently in and enable or disable the appropriate keymappers accordingly.

There are multiple ways to switch between these modes—such as right-clicking or clicking the inventory button—so I had to carefully identify and hook into all the transitions to ensure the keymappers toggled appropriately.

I also encountered, for the first time, a case where the game interface slightly varied depending on the version of the game. It was a simple adjustment but interesting to note.


Petka Engine

In contrast, Petka was simple and quick to implement. The game uses only a few keys and has a single interface, so a single keymapper was sufficient.

The only minor complication was the language barrier—the game is entirely in Russian, which made understanding certain actions and UI flows a bit more difficult. However, with some investigation and context clues, I was able to complete the mapping without major issues.


Wrap-Up

This week, I:

  • Implemented keymapper support for the Lab engine

  • Implemented keymapper support for the Petka engine