Future Angband

**d_m** · December 31, 2011, 07:59

Toward User Friendliness

Definitely agree with the thrust of this thread. I am composing a post that is probably way too long but hopefully is at leas ta bit provocative.

Right now learning Angband (or any *band, or really most traditional roguelikes) is a pretty uphill battle. Some of this is real, inherent complexity but a lot of it isn't. This post is going to focus on one of the more important things I think we need to do to achieve user friendliness: reduce the number of commands new players need to use, while also making them more discoverable.

There's a larger debate about verb/noun versus noun/verb commands. I am going to steer somewhat clear of this by arguing that both forms can be appropriate. Most (modern) games actually mix the two strategies: you'll often choose to cast a spell before deciding who to cast it on, but you'll almost always browse inventory to choose which item to use/wear/whatever.

My belief is that if we can support a (relatively) small number of commands we will have much more flexibility in terms of how to invoke them, whereas right now anyone without a full qwerty keyboard has real difficulty playing Angband (no offense to the heroic attempts to get Angband playable on handhelds).

Here's a current list of commands:

INVENTORY/ITEM MANAGEMENT
(i) list inventory
(e) list equipment
(g) get item (+item?)
(d) drop item (+item)
(k) destroy/squelch item (+item)
(w) wield item (+item)
(t) take off item (+item)
(I) inspect item

MOVEMENT/REST/SEARCH
arrow keys move
(W) force walk (+dir)
(.) run (+dir)
(R) rest
(s) manual search
(S) toggle auto search

INTERACT WITH TERRAIN
(<) go up stairs
(>) go down stairs
(T) tunnel
(o) open door/chest
(c) close door/chest
(j) spike door
(B) bash door
(D) disarm trap/lock door

BOOKS/MAGIC
(b) browse book
(G) gain new spell
(m) (p) cast spell

USING ITEMS
(E) eat food
(F) fuel light
(q) drink potion
(r) read scroll
(A) activate artifact
(a) aim wand
(u) use staff
(z) zap rod
(f) fire bow/xbow/sling
(h) default fire
(v) throw

LOOKING AROUND
(*) targeting mode
(M) full screen map
(L) look around map
(l) look at nearby things

MENUS AND INFO OUTPUT
([) list visible monsters
(]) list visible items
(^F) show level feeling
(^P) view messages
(C) character screen
(~) knowledge menu
(=) options
(?) help

SAVE AND QUIT
(^X) save + quit
(^S) save
(Q) suicide + quit

ESOTERIC
({) inscribe item
(}) uninscribe item
(

take notes
(/) identify symbol
(V) display version
(ENTER) command list
(^E) toggle choice subwindow
(^R) redraw screen
(() load screen dump
()) save screen dump

Whew! I am sure I forgot a few, but that is ~69 distinct commands (counting each of the 9 movement "directions")! And that is not counting debug commands, borg commands, etc.

As someone who loves unix, terminal emulators, screen, shells, etc, it pains me to say this, but I think we need to move away from commands like (i)nventory (which produces some text output) and towards things like the spell menu and the new store interface. There's no reason we need to have N commands that all interact with inventory when we can have one command that brings up the inventory and N contextual subcommands which do different things to the selected item. There's already some movement toward this in V/V4, but it's kind of half-baked.

So, I will here propose a minimal set of future commands, along with a mapping from the current V4 commands I listed. Obviously variants will have extra commands, but hopefully this will be useful for those authors as well:

Any of these commands except those that are used all the time (e.g. movement) might be accessed via a menu.

INVENTORY
1. One command to bring up inventory, which will include equipment and pack/quiver/whatever. User can select items in this list via mouse, arrow keys, or maybe via letter. Subcommands will include:

a. toggle equip/unequip (only applies to some items)
b. use item (only applies to some items, contextual on item type)
c. drop item
d. get info about item
(e. other action menu, if needed, for esoteric commands, e.g. incriptions)

This command replaces (partially or fully):
(i) (e) (d) (w) (t) (I) (b) (m) (p) (F) (q) (r) ({) (}) (A) (a) (u) (z)

MOVEMENT/SEARCH
1. Arrow keys/numpad to move. Get rid of the toggling pickup command. I would really like to permanently enable "disarm-on-move" and remove "force walk". Maybe outside the scope of our plans.

2. Run/Click-to-run-to-square. These commands are useful to avoid button mashing, and click to run is really important on touch screens.

3. Rest. I would map the "5" numpad command to be this also. I might remove the "bonus recovery" of resting but even so the command is useful due to the handling of disturbance. This command might end up in a submenu somewhere.

(4+5. Search/Toggle auto-search. As per other threads, online discussion, etc. I strongly believe searching should be passive and continuous, so I'd rather not have these commands at all.)

Commands removed: (

, possibly (W) (s) (S)

INTERACT WITH TERRAIN
(1. Interact with current terrain. This would involve things like taking stairs up/down, and in variants might involve e.g. drinking from a fountain. I would prefer to just ask users when they move onto a piece of funky terrain if they want to interact with it, but this might not be appropriate given decisions about e.g. energy.)

(2. Interact with adjacent terrain. This could involve locking/unlocking door, traps, tunneling, etc. I would prefer to just make this implicit in the move command, but again, this would require gameplay changes that are maybe outside the scope.)

The big idea here is that I don't think we gain a lot by having lots of annoying movement/terrain-interaction commands. For things that happen rarely (going up/down stairs) prompting the user is fine (and could prevent a user error). For things you might do a ton, like disarming traps, opening doors, etc. it should probably just be automatic like it is in most other games. For things like tunneling I'd prefer to say that tunneling can *only* happen with a digger, and that it happens on move with diggers. Or you could remove tunneling. But again that's a gameplay change.

Terrain interaction commands are probably the hardest to unify without changing gameplay. They could end up in submenus but that might be super annoying. In that case the best option might be a "select square" command whose submenu could include these commands.

Commands possibly removed: (<) (>) (T) (o) (c) (j) (B) (D)

BOOKS/MAGIC
If you imagine our current magic menu, but with the ability to cast/learn/browse spells all at once, you no longer need these different commands. Imagine this submenu being triggered by "using" a book and you can get rid of all these commands.

Commands removed: (G) (b) (m) (p)

USING ITEMS
1. A single "use" command. Each item type only has one "use" (not including wielding/removing, or shooting/throwing/fighting). This command is activated from the inventory menu (as shown earlier).

(2. There is maybe a case for "use default ranged attack at nearest opponent", a more general version of the (h) command. This isn't necessarily the right section, but I will note it here. That command is useful precisely because it is so easy--putting it behind a menu would kill it.)

Throwing/shooting commands would probably be moved to something like targeting or looking around--generally when in tactical situations you tend to choose who you're fighting before you choose what you shoot/throw. This is a bit inverted from magic, but since magic is much more general than combat (and sometimes doesn't require a target) I think this is OK.

Commands removed: (E) (F) (q) (r) (A) (a) (u) (z) (f) (h) (v) (f), maybe (h)

LOOKING AROUND
Most of these commands pull their own weight, although (L) and (l) are arguably a subset of (*). I think we could reduce ourselves to:

1. View map. Would work basically as it does now. Either via key command or submenu.

2. Select-square. This would work like (*) but with more explicit context menus about what you want to do to the square, or learn about that square, etc. There might be some keyboard shortcuts (like now) but there would also be a friendly menu.

(3. Maybe some other kind of look around command. But ideally I think #2 should be able to take care of this.)

Commands removed: (l) maybe (L)

MENUS AND INFO STUFF
This big change here would just be to put most of this stuff in a menu, so that instead of a different command for each, you could get to all of them via this one menu. For the purposes of this exercise I consider the commands removed, only because they would not require buttons/keys to be allocated or memorized. Save, quit and suicide should go in this menu also.

The exceptions would be list items/monsters, which you might want to do a lot. Honestly, these commands work much better in subwindows, so maybe they should be removed anyway. Also, maybe help could stay as (?) as well. Shrug?

Commands removed: (^F) (^P) (C) (~) (=) (?)

SAVE AND QUIT
As per the previous point, these can be put in the main menu

Commands removed: (^X) (^S) (Q)

ESOTERIC
Almost all of these could be hidden deep in a menu hierarchy. The only one that should be more accessible is (

, assuming you imagine note-taking to be something players will do. I bet that feature could be removed and very few people would actually miss it, especially as we get better adding important events to the player notes automatically.

Anyway this post is waaaay too long and I've run out of steam. I am sure I made a bunch of mistakes and left important things out. But hopefully I've painted a picture where the user would not need to memorize very many keys. This works great for handhelds and consoles also.

The biggest problem is that the UI does have a real effect on gameplay/commands/rules and vice-versa, so it's hard to reimagine this stuff without committing oneself to a lot of other positions as well.

**ghengiz** · December 31, 2011, 11:19

Originally posted by d_m

Definitely agree with the thrust of this thread.

mmm...this kind of UI sounds familiar...
If I'm not mistaken, most of the changes you propose can be found e.g. in another roguelike, powder, which uses a toolbar with the more used commands under the map, and a menu when you decide to interact with an item in the inventory, equipment included.

Do you think of something like that (but the toolbar, maybe) for angband?

**d_m** · December 31, 2011, 17:52

Originally posted by ghengiz

mmm...this kind of UI sounds familiar...
If I'm not mistaken, most of the changes you propose can be found e.g. in another roguelike, powder, which uses a toolbar with the more used commands under the map, and a menu when you decide to interact with an item in the inventory, equipment included.

Do you think of something like that (but the toolbar, maybe) for angband?

So, having looked at Powder again, I will agree that it moves in that direction.

However, Powder still doesn't go far enough. When I click on a book I shouldn't be asked whether I want to eat it (at least, not in the *band I am imagining). Powder gives me 11 actions I can do with a book, where I would prefer ~4 (read, drop, get info, other). Also, I would probably not go with Powder's icon/toolbar approach (at least not for PC versions), but would provide contextual shortcuts.

if you read Powder's keyboard help it still has far too many entries for my liking. Part of this are its Nethack roots, so it has to stuff like the "dip" command. But I think I am hoping to go even farther.

**nppangband** · December 31, 2011, 22:55

Originally posted by d_m

So, having looked at Powder again, I will agree that it moves in that direction.

However, Powder still doesn't go far enough. When I click on a book I shouldn't be asked whether I want to eat it (at least, not in the *band I am imagining). Powder gives me 11 actions I can do with a book, where I would prefer ~4 (read, drop, get info, other). Also, I would probably not go with Powder's icon/toolbar approach (at least not for PC versions), but would provide contextual shortcuts.

I have done this in NPP, with a few bugs to be worked out. But if you choose an object, you will only get commands applicable to that object. Foe example, if you select a spellbook, you will only get browse if you are teh right type spellcaster. You will only get Study if you have spells eligible to study in that book, and you will only get cast as a command if you have already learned the command. You can even learn or cast multiple spells without having to re-select the book. But each object has more possible commands than you would guess. For example, almost every object can be inscribed and/or uninscribed, thrown, destroyed, dropped, examined and used or wielded. So the minimum # of commands for any given object is around 6-7.

I am glad there are other developers who want to make this happen. I hope those of us who are willing to work on this coordinate our efforts, so any UI improvements get implemented consistently across as many variants as possible, so we don't duplicate each others work, and so we don't have people going off and coding something that one of us has already written.

**takkaria** · December 31, 2011, 23:00

I don't suppose anyone has considered having a 'magic' menu that displays spells available rather than accessing them by object? I'm not sure how it would play, but it would allow some better categorisation I think - 'm'agic -> 'e'scape -> 'p'hase door anyone? Just a thought.

**ghengiz** · December 31, 2011, 23:46

Originally posted by takkaria

I don't suppose anyone has considered having a 'magic' menu that displays spells available rather than accessing them by object? I'm not sure how it would play, but it would allow some better categorisation I think - 'm'agic -> 'e'scape -> 'p'hase door anyone? Just a thought.

seems a very neat idea...
the categories could be:
escape (phase door, teleportation, teleport level?, word of recall?)
buffer (bless, berserker,...)
attack (magic missile, ...)
utility (identify, remove curse...)

**Derakon** · January 1, 2012, 00:57

I think it'd be easier to just list all of the spells you have available in your spellbooks than it would be to try to order things by category. You'd also want to leave gaps in the list for spellbooks you aren't currently carrying / spells you haven't learned yet, so that the letter used to access a specific spell doesn't change as you gain access to more spells. Otherwise, sounds like a neat idea to me!

**Nick** · January 1, 2012, 01:51

OK, so here's a refinement and possible implementation of some of what I said first.

Have a big human-readable file which contains all the configuration information (and this can include squelch settings, which style of commands to use, etc etc). Have this set up with sensible defaults for each platform; have other sensible defaults available.

The intent should be that new players can download and start playing in an intuitive way, but the game is configurable for experienced players. There should be basic help which gives the important information, but more detailed information for players who want to go away from the default configuration.

There should probably be a single command which gives access to all the advanced configuration information.

I appreciate takkaria's attempt to minimise options, but Angband players generally tend to be a little, um, particular; I think the config file approach may satisfy both impulses.

**Blue Baron** · January 1, 2012, 02:35

I am curious about this in relation to the expanded mouse support I wrote (esp. with the fixes in the pull request I just made). For instance, cast,study,browse are only in spellbook context menus and only if the same conditions for the keyboard command to succeed are true.

About command simplification, I agree with a simple set of commands for new players and the current complicated set for veterans. for new players we already have 'U' - use inventory, 'm' - cast magic, Alter+direction to interact with adjacent tiles, and enter for full command list. Perhaps we just need a command to interact with the tile the player is standing on? Then only mention those in the front of help files, and the rest later in the help file?

some other things I want to try to do, still all in the text ui for both ascii and tiles:
hotkeys - Alt-F1 - Alt-F10 menu to setup/clear keymaps/inscriptions for F1 - F10 to use an item or cast a spell while keeping any part of the inscription after the first !, like it is currently possible (though complicated) to setup.

keymap more clear - use some character in keymaps to set a new flag to auto clear more prompts, until the keymap ends. (Possibly until just before the last keypress of the keymap.)

add a window layout reset command to set the layout in windows to a hardcoded layout and font based on the screen size. Also run this command when the windows port is started and an ini file is not present.

ignore chests when they are opened, rather than in the squelch_item_okay function. If chests are generated empty, ignore them at generation.

implement a subwindow list of charging items.

change graphics mode list iteration slightly.

set default hp warning level to 30%

try to fix some blank spots in menus that do not get wiped, esp. in wine.

grey out use commands in context menus that won't do anything.

d_m: It sound like you want throw, inscribe, and squelch on a second object context menu page?

about a graphical ui: I like the current multiwindow text ui for windows, so I would want a graphical ui to be an option. (an options->ui submenu on the menu bar.)

a good start for a graphical ui might be to allow optional port term hook functions for ui functions. maybe start with get_item(), get_spell(), get_check(), get_number(), get_direction(), do_cmd_inven(), and do_cmd_equip(). For instance:

Code:

bool get_item(params)
{
    if (term->get_item_hook) {
         term->get_item_hook(params);
    }
    ....

the ui options would setup/clear the term hooks as well as the info/files the port needs. This way there is always some ui, no matter what the port implements. (Graphical ui would always have to be implemented by the port through. The requirements of SDL and windows are fairly different.)

about the core/ui split: the above isn't it

the split would make the above easier. A start on it might be to move the source files into sub directories: base, base_ui, game, game_textui, game_nontextui, platform.

btw, I just added a context menu option to lock closed doors, since I didn't know that was possible until I read d_m's list

**Shockbolt** · January 1, 2012, 09:40

Originally posted by takkaria

I don't suppose anyone has considered having a 'magic' menu that displays spells available rather than accessing them by object? I'm not sure how it would play, but it would allow some better categorisation I think - 'm'agic -> 'e'scape -> 'p'hase door anyone? Just a thought.

what about a combined skill/spells bar where you have icons that represent for example searching and infra vision with cooldown timers once activated, and you are also able to drag and drop spells(from the spellbook) onto the same bar, and those are activated by clicking on them or by a combo of keys such as Alt+1, Alt+2 or Ctrl+1 or Ctrl+2 depending on if it's row 1 or row 2?

I imagine that the spells would need to be accessed in also the same way as they are done currently.

**ghengiz** · January 1, 2012, 09:54

Originally posted by Shockbolt

what about a combined skill/spells bar where you have icons that represent for example searching and infra vision with cooldown timers once activated, and you are also able to drag and drop spells(from the spellbook) onto the same bar, and those are activated by clicking on them or by a combo of keys such as Alt+1, Alt+2 or Ctrl+1 or Ctrl+2 depending on if it's row 1 or row 2?

I imagine that the spells would need to be accessed in also the same way as they are done currently.

why the cooldown timers? AFAIK no spell needs that, unless you mean a global mana pool (represented by a bar, for example) which refill with time: not enough mana, no spell can be cast

**Shockbolt** · January 1, 2012, 10:02

Originally posted by ghengiz

why the cooldown timers? AFAIK no spell needs that, unless you mean a global mana pool (represented by a bar, for example) which refill with time: not enough mana, no spell can be cast

Searching would be a perfect target for a cooldown timer, and I can think of others too. That way, you'd get rid of the "s"-spamming currently needed playing todays Angband version. As for spells, I see no problem suggesting new spells to be added to the current books, or even slightly altering some of the ones already there. "Magelight" could be the equivalent of a torch, you have a magical light that burns for x-rounds, and that is represented by the cooldown timer.

Even an icon for eating, switching a lightsource on/off, refilling or digging could be added to that bar.

**RCIX** · January 1, 2012, 10:20

I think something that would be much desired is a smoother way to remap keys. I have it rigged to single-button press cast a spell, but it's inconsistent (sometimes I have to press enter to get more messages, sometimes not), relies on the appropriate spellbook being bound to slot 1 via {@m1}, and is only to cast at the nearest monster.

I would use "cast at targeted monster" but I think i would need a single button press "rotate through valid targets" key for that. It doesn't help that there are so few unused keys available ATM :P

On the note of messages, there desperately needs to be a better message display, since being in any sort of combat situation with 5+ monsters means I'm usually spam pressing enter through the avalanche of messages =/

Edit: didn't see second page. Still think the above might be useful though.

**AnonymousHero** · January 1, 2012, 11:08

for new players we already have 'U' - use inventory

(I haven't played since 3.1.2v2, so please forgive me if this is already in.)

Personally, I think the "old" commands must also be removed -- it will provide more real estate for placement of the "unified" commands, so you can devise more obvious mnemonics.

Future Angband

Future Angband

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment