[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]

Originally Posted by Remuz

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]

Originally Posted by Nick

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]

Originally Posted by Remuz

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]

Originally Posted by takkaria

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]

Originally Posted by Remuz

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.