Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old December 31, 2011, 05:16   #1
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 54
Posts: 7,702
Donated: $60
Nick is on a distinguished road
Future Angband

Following ideas in this thread and this thread, and also buzzkill's universal tileset, I have been doing some thinking about a way forward for Angband.

Basically, I think we should rethink a whole bunch of stuff, and do it all at once so as to minimise the duration of the pain.

Here are the things off the top of my head that have been being simultaneously kept compatible with tradition, and modernised:
  • Commands
  • Squelch
  • Tile handling
  • ASCII/UTF-8 handling
  • Help
  • Subwindows
  • Macros/keymaps
  • Mouse/touch controls
  • Zoom
  • Savefiles
  • Preferences

I'm sure there are others. I propose that Angband 3.x should keep these things as they are, with no further development (at least for the medium term). v4, on the other hand, should rewrite them completely with regard to functionality and not tradition.

Moreover, I think there should be a core configuration (with things like simplified commands, and minimal options) for new players to start on (and probably for smaller devices), and an expanded version which is essentially the same game but with greater facility for customisation.

I should emphasise that many people have done a great deal of good work on these things. This can be the basis for, or at least inform, the future model.

The essence of Angband is contained in the gameplay, objects, monsters, messages, etc - so none of the things I listed above. We can plan these to be compatible with the way gaming devices are now without affecting the fundamental game.

Thoughts?
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old December 31, 2011, 06:59   #2
d_m
Angband Devteam member
 
d_m's Avatar
 
Join Date: Aug 2008
Location: Philadelphia, PA, USA
Age: 38
Posts: 1,516
d_m is on a distinguished road
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.
__________________
linux->xterm->screen->pmacs
d_m is offline   Reply With Quote
Old December 31, 2011, 10:19   #3
ghengiz
Adept
 
ghengiz's Avatar
 
Join Date: Nov 2011
Location: Roaming in Terry Pratchett's Discworld
Posts: 178
ghengiz is on a distinguished road
Quote:
Originally Posted by d_m View Post
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?
ghengiz is offline   Reply With Quote
Old December 31, 2011, 16:52   #4
d_m
Angband Devteam member
 
d_m's Avatar
 
Join Date: Aug 2008
Location: Philadelphia, PA, USA
Age: 38
Posts: 1,516
d_m is on a distinguished road
Quote:
Originally Posted by ghengiz View Post
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.
__________________
linux->xterm->screen->pmacs
d_m is offline   Reply With Quote
Old December 31, 2011, 21:55   #5
nppangband
NPPAngband Maintainer
 
Join Date: Dec 2008
Location: Stat Gain, Angband
Posts: 926
nppangband is on a distinguished road
Quote:
Originally Posted by d_m View Post
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.
__________________
NPPAngband current home page: http://nppangband.bitshepherd.net/
Source code repository:
https://github.com/nppangband/NPPAngband_QT
Downloads:
https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57
nppangband is offline   Reply With Quote
Old December 31, 2011, 22:00   #6
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,928
Donated: $40
takkaria is on a distinguished road
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.
__________________
takkaria whispers something about options. -more-
takkaria is offline   Reply With Quote
Old December 31, 2011, 22:46   #7
ghengiz
Adept
 
ghengiz's Avatar
 
Join Date: Nov 2011
Location: Roaming in Terry Pratchett's Discworld
Posts: 178
ghengiz is on a distinguished road
Quote:
Originally Posted by takkaria View Post
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...)
ghengiz is offline   Reply With Quote
Old December 31, 2011, 23:57   #8
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,805
Derakon is on a distinguished road
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!
Derakon is offline   Reply With Quote
Old January 1, 2012, 00:51   #9
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 54
Posts: 7,702
Donated: $60
Nick is on a distinguished road
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.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old January 1, 2012, 01:35   #10
Blue Baron
Adept
 
Join Date: Apr 2011
Posts: 103
Blue Baron is on a distinguished road
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
Blue Baron is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Future of Angband development Timo Pietilš Development 95 December 28, 2011 17:07
The future of Oangband? CJNyfalt Variants 64 August 1, 2011 19:42
Include xchar or utf-8 in future? hernaldo ToME 1 July 31, 2010 21:20
Future of Vanilla? dhegler Vanilla 31 January 28, 2010 13:36


All times are GMT +1. The time now is 22:15.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.