Ah, that's fine then. As long as those two lists contain everything, I can easily make my program without feeling like I'm missing anything.
The way these languages work (one was originally a fork of the other, so they are similar), I think I can make them save to and read from a key config file that will handle remapping similar to Brogue. That is, one key will be interpreted as another when the game window is in focus. For example, if the config file contains a line that says
a=b and the user presses the
a key, the wrapper will interrupt the keycode and send the one for
b instead. I've used these languages before for other games and know they work well (though I've only ever used hard-coded keycodes rather than configurable ones), plus I'd release the source so people could use it without any qualms, but some users may be weary of it anyway: reading and intercepting keycodes sounds an awful lot like what a
keylogger does (and may even trigger a false positive in certain virus/malware scanners)... :/
And yes, an external solution like that would
probably work for non-English keyboards too, but I have no way of testing that since I don't actually
own a non-English keyboard. Plus, the possibility of certain scanners throwing a false-positive about it being a keylogger means it might not be the most
professional solution for your commercial game either... :/
Another limitation that can be kind of annoying for certain games is that AutoIt/AutoHotkey programs
usually can't distinguish between in-game dialog windows, so a "what is your name" screen would have some
very strange behavior, lol. When I made a remapping program for the PC version of
Phantasy Star Online, I got around this limitation by programming a key command (mapped to
Ctrl+Tab IIRC) to
toggle the remapping of the other keys...