[All] Keyboard interface and keymaps

[Remuz]

Hi everyone,

I am sure this has been beaten to death before, but I was not around at that time, so here it goes. Feel free to point me to an old thread though.

I've been wondering if it's worth creating a new default keymap, together with the current Roguelike and standard ones, but everybody would have different opinions on where the moved keys should go

This was said by Lebannen in another thread, and led me to think about the current keymaps. There is a lot a redundancy, and some commands apply only to a subset of items. Considering that some commands apply to distinct subsets of items, we could fuse them together.

For example :
- 'u'se a staff
- 'a'im a wand
- use 'm'agic to cast a spell from a book
- 'p'ray for priests
- 'A'ctivate an artifact
- 'r'ead a scroll
- 'q'uaff a potion
- 'z'ap a rod
- 'F'uel a lantern/torch

All those commands could be accessed from only one command, say 'u' for 'u'se an item. For people that cannot type like me, this would speed up gameplay, help new players to learn how to play, and overall improve the game. Also, it could ease the introduction of a mouse driven interface (I would love to see my equipment in a term window, and then simply click on an item to use it).

Please note that this kind of reasoning has been applied before, thanks to the existence of the '+' command, that disarms, digs, open and close door, etc.

Optionally, the 'b'rowse command could be discarded, and accessed through the 'u'se book menu, as this command is seldom used after a while.

Other simplifications in the keymap could be as follows. I am not saying all should be done, only that they are technically possible :
- 'w'ear/'t'ake off could be one command (can not be 'u'se, because there is a conflict for activable artifacts).
- '<' and '>' need not to be separate, as one only ever stands on one type of stairs at a time.
- '=', '@', '%' can be a subset of the options menu

That's it, thanks for your comments.

[Lebannen]

ZAngband combined a lot of commands, from what I remember, and also supported easy-open/easy-disarm etc via movement; the net result was that far fewer keys were required, making it much easier to create new keymaps.

The only advantage I see to having all the separate commands is that the combination with inscription support means you can hotkey more easily. But that's much more of an advanced player trait anyway...

[Nick]

For example :
- 'u'se a staff
- 'a'im a wand
- use 'm'agic to cast a spell from a book
- 'p'ray for priests
- 'A'ctivate an artifact
- 'r'ead a scroll
- 'q'uaff a potion
- 'z'ap a rod
- 'F'uel a lantern/torch

All those commands could be accessed from only one command, say 'u' for 'u'se an item.

You are pretty much describing the 'h'andle command, described on this page. I don't know whether there are any plans to put this into Vanilla; I have, by coincidence, included it in the next version of FA.

[takkaria]

You are pretty much describing the 'h'andle command, described on this page. I don't know whether there are any plans to put this into Vanilla; I have, by coincidence, included it in the next version of FA.

There are. Sometime. The work I did in V in cmd-obj.c with separating out the different commands and their UI entry points was to make this kind of thing easier without doing things quite as hackily (sorry!) as in the handle patch.

[takkaria]

This was said by Lebannen in another thread, and led me to think about the current keymaps. There is a lot a redundancy, and some commands apply only to a subset of items. Considering that some commands apply to distinct subsets of items, we could fuse them together.

For example :
- 'u'se a staff
- 'a'im a wand
- use 'm'agic to cast a spell from a book
- 'p'ray for priests
- 'A'ctivate an artifact
- 'r'ead a scroll
- 'q'uaff a potion
- 'z'ap a rod
- 'F'uel a lantern/torch

All those commands could be accessed from only one command, say 'u' for 'u'se an item. For people that cannot type like me, this would speed up gameplay, help new players to learn how to play, and overall improve the game. Also, it could ease the introduction of a mouse driven interface (I would love to see my equipment in a term window, and then simply click on an item to use it).

Many people have argued for and against this kind of reductionism.

Let me present a few arguments against this.

1. Imagine the situation where you're playing, think "ah, time to read that scroll of summon monster", hit 'r', and the small number of scrolls shown, your eyes find it and you hit the appropriate letter almost instantly.

2. Imagine the situation where you have a staff of summon monster in slot 'g' and a rod of acid bolt in 'h'. You want h, your finger slips and you hit g. Ouch.

This all said, I think people should be able to a) spend more time looking at the screen and b) shoot themselves in the foot, so a command like this will turn up at some point. It's not a priority, though.

[quote]

Please note that this kind of reasoning has been applied before, thanks to the existence of the '+' command, that disarms, digs, open and close door, etc.

And what a horrible command it is too. (*coughs*. IMO, obviously)

Optionally, the 'b'rowse command could be discarded, and accessed through the 'u'se book menu, as this command is seldom used after a while.

If you'd played anything past 3.0.6 then you would see that browsing now lets you examine individual spells for more detail on their effects. You couldn't do this if the command was merged.

Other simplifications in the keymap could be as follows. I am not saying all should be done, only that they are technically possible :
- 'w'ear/'t'ake off could be one command (can not be 'u'se, because there is a conflict for activable artifacts).

I think these are far too easily muddled up if they're the same command. ("Oh, I appear to have accidentally taken off my sword, which is why I'm being pwned by the Great Wyrm... wield, oh, dead.")

- '<' and '>' need not to be separate, as one only ever stands on one type of stairs at a time.

I think nothing is gained by merging these.

- '=', '@', '%' can be a subset of the options menu

I take it you've not played anything past 3.0.6 then? They've already been done.

[Remuz]

Nice. This patch seems to address every one of my points, and more. The exception being the '>' and '<', which is very minor. I can't wait to test it in FA.

As for the '=', '@' and '%' grouped together, this is already in vanilla, I just noticed.

[Nick]

The work I did in V in cmd-obj.c with separating out the different commands and their UI entry points was to make this kind of thing easier without doing things quite as hackily (sorry!) as in the handle patch.

That's OK - I'm used to recoding everything I do several times, and it's nice to know that this time the algorithm will terminate.

[Remuz]

I take it you've not played anything past 3.0.6 then? They've already been done.

Yup, sorry about that. Angband development is going so fast these days, that I can hardly keep up. (ok, that's a lame excuse, I should have checked before posting)

[takkaria]

Yup, sorry about that. Angband development is going so fast these days, that I can hardly keep up. (ok, that's a lame excuse, I should have checked before posting)

When you say "so fast", and you mean "a major release two years after the last one", ...

[Big Al]

I'd prefer most of the commands are not merged. I'm hardly have a lack of keyboard space to make macros (I count 16 unused commands on the a-z, A-Z keys, in addition to ^-key combos). I die of typos far too often as it is and it'll only happen so much more if I have the possibility of using a type of object that I wasn't intending. I could see combining 'z', 'a', 'u' and maybe 'A' (since they're all debatably all the same action), and combining 'm' with 'p', but don't merge them all the rest.

[roustk]

I could see combining 'z', 'a', 'u' and maybe 'A'...

I would argue against that, because I'm one of those people who use inscriptions (and I often have more than 10 numbered rod/staff/wand/artifacts). For example, my current warrior has a rod of detection @z0, staff of <magic mapping> @u0, and artifact of identify @A0. I also will inscribe scrolls of magic mapping @r0 and potions of enlightenment @q0, when I have them. (I use codes 1-8 for attacks, but 0 and 9 are for informative things.)

As I reflect on this, I realize that I mis-coded my artifact -- at the start of this game I planned to use 9 for identify and 0 for detection. Maybe I'll change it.

Kevin

[Remuz]

When you say "so fast", and you mean "a major release two years after the last one", ...

Really? Where have I been all that time? I wonder. I honestly had not realized.

The issue with inscriptions can be easily solved by leaving the old commands. That way you can continue using the old 'u'se, 'a'im, etc, if you decide to do so. I am not sure this would be a good thing in the long run, but this would be a way to please everyone.

[Big Al]

Good point, roustk.

Another solution (which a lot of modern games seem to do these days) is in the options screen, have a big list of all the commands in the game, and you can individually set each key to a command. So if you wanted all the use, zap, aim, etc commands all on the same key, simply assign them all to the same key. If not, then assign them to different keys. There'd a couple default keymaps to choose from (like the current normal & roguelike keys), or you could make your own eg. if you're used to the Nethack command keyset. Or (as was discussed in another thread recently) you could remap the 'jkluio' keys to movement keys '123456' if you don't have a numpad and move around the open, use, inspect, etc commands to where you want.

Or you could do the reverse and have a list of all the key combos possible and then you can select what action(s) you want associated with that key. Now that I think about it, this way would work better, I think. With this, you could combine the macro system too: for each key, you can pick the action(s) associated with it, as well as optionally other key presses following the command. Maybe I'll take a look at how hard this would be to implement.