Casting UI Concerns (was: No More Haste Spell)


Although the central place for design discussion is ##crawl-dev on freenode, some may find it helpful to discuss requests and suggestions here first.

Slime Squisher

Posts: 368

Joined: Thursday, 11th April 2013, 21:07

Post Thursday, 6th October 2016, 04:34

Casting UI Concerns (was: No More Haste Spell)

tabstorm wrote:Semi-trolling but semi-serious question: How is casting haste before engaging in melee substantially different from casting a bolt spell in induced tedium? There are a few instances where you'll cast haste without enemies in view, but these are mostly fixed vaults where you know what's coming, like going downstairs to Tomb:2 or Tomb:3. Both replicate a consumable (bolt wands vs. haste wands). Both are pretty much no brainers, you're going to cast Haste or Bolt when enemies come into view. All that's left is that bolt spells directly damage the enemy and haste dosen't. Are all spells that aren't direct damage spells tedious? What about bolt spells? Aiming bolt spells can get pretty annoying.

Real Talk: Crawl's spellcasting and ranged attack interfaces are terrible. They are okay by roguelike standards, but genre UI is horrible-bordering-completely-unusable to begin with.

It's my belief that a large part of the reason you see new players recommending and playing pure melee characters is simply that bump attacks (and tab) are much less fiddly than going through the (z)ap, (f)ire, and e(v)oke interfaces for their character's primary offense. Press a button, do a thing. Not press 2 (f,f) to 4 (z,?,b,enter) buttons to do a thing, or worse, *maybe* do a thing that the game will proceed to ask for confirmation about. (spell failure chance, blocked line of fire, improper tile picked for autotargeting, etc.)

Sequell stats:
[23:13] <Implojin> !lg !goodplayers s=class cv>=0.18 !boring
[23:14] <Sequell> 505219 games for goodplayers (cv>=0.18 !boring): 109433x Fighter, 42662x Berserker, 37291x Gladiator, 35697x Monk, 32907x Transmuter, 22576x Abyssal Knight, 22542x Conjurer, 21617x Fire Elementalist, 21060x Enchanter, 18265x Skald, 17770x Wizard, 16162x Hunter, 16054x Assassin, 12162x Necromancer, 11504x Chaos Knight, 10717x Earth Elementalist, 10039x Wanderer, 8823x Ice Elementalist, 8598x Venom
[23:14] <Sequell> Mage, 8059x Summoner, 7310x Air Elementalist, 6202x Warper, 4407x Artificer, 3362x Arcane Marksman, Death Knight

The predominant classes here have one thing in common: You can press tab to fight.
You can't argue in good faith that players are picking these classes because they're mechanically strong: Yes, Berserker fits the bill, but things like Fi and Mo begin the game with some of the fewest survival tools of all the classes.


Sure, the player can setup macros to skip through spell selection and targeting, but why should s/he have to? Why is this functionality hidden behind a command that requires knowing it exists and manually setting it up? One-press autotargeted ranged attacks should be set by default to something like (non-numpad) 1,2,3,4,5, with those binds defaulting to known spells in order of memorization at each new game, and a one-press rebind available from i/I/Z/V/a to set each bind to use/fire the chosen item/spell/evocable/ability. Put a string at the bottom of each of those screens saying something like "Press 1/2/3/4/5, then press an item letter to bind an item for use." Set the autofire targeters to sane defaults: Nearest monster for direct damage spells and hexes, selfcast for buffs, tile-targeted adjacent to the nearest monster on a line between itself and the caster for cloud spells (aborting with a manual targeting message only if it would hit the caster or can't find an empty tile).

We could put the manual targeters for those item/spell/ranged weapon binds on shift+number and move the existing binds for !@#$% elsewhere, or we could put them on alt+number, or we could use F1 through F5 instead.

We could default bind 1 to the starting ranged weapon for backgrounds with no book, or set the binds to the starting wands in order of initial inventory slot for artificer.

We could find some space underneath or beside the existing wielded weapon and quivered item display in the main gameplay viewport to display the currently active slot binds, to the effect of something like:
1) wand of flame 2) wand of random effects
3) summon butterflies 4) 13 steel javelins
5) nothing bound


I'm rambling a bit now so I'll stop typing, but what I'm trying to get at is that there's a lot of room for improvement in Crawl's offensive ability interface.

For this message the author Implojin has received thanks: 7
8bitsdeep, Cimanyd, DracheReborn, duvessa, nago, Rast, Styro

Ziggurat Zagger

Posts: 3037

Joined: Sunday, 2nd January 2011, 02:06

Post Thursday, 6th October 2016, 10:55

Re: DCSS TrunkWatch™: No More Haste Spell

Implojin wrote:The predominant classes here have one thing in common: You can press tab to fight.
You can't argue in good faith that players are picking these classes because they're mechanically strong: Yes, Berserker fits the bill, but things like Fi and Mo begin the game with some of the fewest survival tools of all the classes.


You may already know, but the ` key spams the last spell you've used. It doesn't always make good targeting choices, but neither does tab.

goodcoolguy wrote:This is totally wrong. If you have gotten spellhaste online and the significance of the investment is such that it is "optimal" to use it every time a fight lasts more than 3-4 turns, you have made serious strategic error.


If you have access to spell haste, then it is 'optimal' to use it if you are doing nothing more than walking across an empty room to the stairs. You get back the turn you invested in casting it in just three steps. You may not need it to cross that empty room, but it lets you cross that empty room faster and therefore better. Spell haste is infinite, so you don't need to save it for actual emergencies.

Slime Squisher

Posts: 368

Joined: Thursday, 11th April 2013, 21:07

Post Thursday, 6th October 2016, 13:45

Re: DCSS TrunkWatch™: No More Haste Spell

KoboldLord wrote:You may already know, but the ` key spams the last spell you've used. It doesn't always make good targeting choices, but neither does tab.

` repeats the last input. This is not the same as recasting the most recently cast spell.

As a simple example, think of a player on a new Fire Elementalist rounding a corner and wanting to (re)cast flame tongue. Their most recent keypress was either a movement tap or autoexplore, so they can't simply press ` to use their primary XL1 means of dealing damage. They have to manually cast, most likely with (z,a,enter), and they might end up pressing those keys just to get a warning with no action taken, because the thing that broke their autoexplore happens to be out of range of the spell. Now they might have to move closer and press (z,a,enter) again. Potentially 6+ keypresses to try to initiate an action that they expressed their desire to perform the first time their finger touched z. They can subsequently press ` until the thing dies, sure, but with the gotcha that their recasting might still break if they happen to open their inventory, look at their character window, or perform any other input besides continuing to press `.

More experienced players might have taken the time to manually setup macros to reduce this down to a single keypress of something like F1, but even for those players there's a gotcha: Doing this with the game's builtin macro editor creates dumb chains of command input that don't perform any sanity checks like target validation when the macro runs.

It is of course possible for the (ever so distant from actual) player to "fix" this by instead doing their automation with Lua scripting, but then they've moved even further out of the realm of what should be required to play the game.


Alternately, our plucky new player could simply roll a Fighter and bump attack things or press tab. S/he is now seeing one action happen onscreen with every keypress. Dang, this is a lot nicer!

Trying to pawn good default command inputs off on things like the macro editor and repeat command bind is a false solution. Requiring several keypresses to *maybe* do a thing is a completely needless approach that makes the game harder to play for anyone not already so blinded by previous exposure to genre staples that they have become incapable of seeing how terrible this is. Paucity of complexity in command input is a Good Thing.

autofight_throw is, of course, a thing, although it should be pointed out that it defaults to false and most players will never edit their rc.
The real solution is to change all of the default ranged ability use input binds to require only one keypress for simultaneous targeting and activation, with no confirmation. Press button, do thing.


(With all of this said, it is not my intent to diminish the effort of any previous devs who have tried to improve Crawl's interface. Improvements in a game with a volunteer team necessarily happen at their own pace, and that's okay. It is an older game, with design decisions that reflect its history, but as above: There's plenty of room for improvement!)

edit: See ToME4's ability bar for a functional example of how to do single-press keybinds for abilities of varying sources. This exact solution might not work in DCSS due to terminal size limitations, but there is space under the HP/MP bars that could be used!
Last edited by Implojin on Thursday, 6th October 2016, 13:55, edited 1 time in total.

For this message the author Implojin has received thanks: 5
BabyRage, Cimanyd, DracheReborn, Rast, Shard1697

Ziggurat Zagger

Posts: 4432

Joined: Friday, 8th May 2015, 17:51

Post Thursday, 6th October 2016, 13:52

Re: DCSS TrunkWatch™: No More Haste Spell

Implojin wrote:It's my belief that a large part of the reason you see new players recommending and playing pure melee characters is simply that bump attacks (and tab) are much less fiddly than going through the (z)ap, (f)ire, and e(v)oke interfaces for their character's primary offense. Press a button, do a thing. Not press 2 (f,f) to 4 (z,?,b,enter) buttons to do a thing, or worse, *maybe* do a thing that the game will proceed to ask for confirmation about. (spell failure chance, blocked line of fire, improper tile picked for autotargeting, etc.)


I think main reason of playing melee characters is to have easier game. As caster you need to pay attention to :
1) MP. Melee characters can just press tab until it is stopped by autofight_warning.
2) monsters (resistances, position). Melee characters can just press tab after rushing forward or luring around a corner
3) skill training. Melee characters train a single skill on first floors, then they are fine training Fighting, Weapon, Armour and Dodging all the way until Zot 5
4) spells. Which spell should I learn, which spell should I train, which spell should I cast.
5) your own HP. You will have much less AC, HP, EV than melee character. Caster gods don't have good panic buttons (compare Trog to Vehumet or TSO to Sif Muna, for example). Only Kiku is good and even then all panic buttons require MP, sometimes as many as 10 MP (Ru, Chei, Zin, Lugonu).
Interface issue is not as big deal here IMHO, you are going to cast different spells and enjoy targeting them anyway, otherwise you wouldn't play a caster
Underestimated: cleaving, Deep Elf, Formicid, Vehumet, EV
Overestimated: AC, GDS
Twin account of Sandman25

For this message the author VeryAngryFelid has received thanks:
Rast

Tartarus Sorceror

Posts: 1739

Joined: Tuesday, 13th March 2012, 02:48

Post Thursday, 6th October 2016, 14:39

Re: DCSS TrunkWatch™: No More Haste Spell

Implojin wrote:Sequell stats:
[23:13] <Implojin> !lg !goodplayers s=class cv>=0.18 !boring
[23:14] <Sequell> 505219 games for goodplayers (cv>=0.18 !boring): 109433x Fighter, 42662x Berserker, 37291x Gladiator, 35697x Monk, 32907x Transmuter, 22576x Abyssal Knight, 22542x Conjurer, 21617x Fire Elementalist, 21060x Enchanter, 18265x Skald, 17770x Wizard, 16162x Hunter, 16054x Assassin, 12162x Necromancer, 11504x Chaos Knight, 10717x Earth Elementalist, 10039x Wanderer, 8823x Ice Elementalist, 8598x Venom
[23:14] <Sequell> Mage, 8059x Summoner, 7310x Air Elementalist, 6202x Warper, 4407x Artificer, 3362x Arcane Marksman, Death Knight


I agree with your argument, but I don't think the stats do much to support you here. The mechanically strongest races are the ones most suited to a fighter-type background. (Ignoring theoretically optimal crawl where Felid is the strongest race because it can run away from everything etc). So of course new players are going to choose those.

For this message the author Rast has received thanks:
VeryAngryFelid
User avatar

Barkeep

Posts: 1788

Joined: Saturday, 29th June 2013, 16:52

Post Thursday, 6th October 2016, 15:33

Re: Casting UI Concerns (was: No More Haste Spell)

This subject seems like a worthy topic for GDD, and I think implojin has done a great job summarizing the problems with spellcasting's interface.

For this message the author archaeo has received thanks:
VeryAngryFelid

Dungeon Master

Posts: 3618

Joined: Thursday, 23rd December 2010, 12:43

Post Thursday, 6th October 2016, 15:37

Re: DCSS TrunkWatch™: No More Haste Spell

implojin: You raise a lot of good points, but I'm afraid they go to waste because this is the wrong topic.

I am definitely interested in improving the interface. My contributions in the past have been 'ff' (you commented on it negatively, but it used to be even worse :)), the quiver, and commands like % and Ctrl-O. If I remember correctly, nobody has seriously contemplated using the number keys as default spell triggers. That's something which might work out.

Bottom line: This should definitely be discussed in a dedicated thread.

edit: While I was typing this, the interface stuff got moved to a new thread. Thanks!

Tartarus Sorceror

Posts: 1694

Joined: Tuesday, 31st March 2015, 20:34

Post Thursday, 6th October 2016, 15:42

Re: Casting UI Concerns (was: No More Haste Spell)

Damn overmoderation! :P

I like the idea of having some spell hotkeys, and the number keys do seem like a great idea. Would that have any negative interaction with moving via the numpad? I know right now if I press 7 on the number row my character moves northwest, just like the numpad key. But obviously if I press shift+2(@) I don't move south until I hit a wall, I open my character screen. So I guess there's a distinction, but it seems there's a little cross over at the moment.
User avatar

Barkeep

Posts: 1788

Joined: Saturday, 29th June 2013, 16:52

Post Thursday, 6th October 2016, 15:48

Re: Casting UI Concerns (was: No More Haste Spell)

Let me know if you prefer to make a new post/delete that old one, dpeg, but I moved the one you made in the old thread here.

dowan: There have been tileschatters who use the number row keys for movement. As you'd expect, they were mostly objects of wonder and derision, and I don't know that Crawl needs to maintain that control scheme.

For this message the author archaeo has received thanks: 2
Arrhythmia, dpeg

Ziggurat Zagger

Posts: 6454

Joined: Tuesday, 30th October 2012, 19:06

Post Thursday, 6th October 2016, 16:13

Re: Casting UI Concerns (was: No More Haste Spell)

Does no one use auto magic?

Maybe we should just turn on the existing feature by default and bind it to some key....
Spoiler: show
This high quality signature has been hidden for your protection. To unlock it's secret, send 3 easy payments of $9.99 to me, by way of your nearest theta band or ley line. Complete your transmission by midnight tonight for a special free gift!

Ziggurat Zagger

Posts: 8786

Joined: Sunday, 5th May 2013, 08:25

Post Thursday, 6th October 2016, 16:32

Re: Casting UI Concerns (was: No More Haste Spell)

` objectively does not work properly for recasting spells. It's useful for some things, but using it as "automagic" is borderline suicidal and shouldn't be brought up as a serious option.

Rast wrote:The mechanically strongest races are the ones most suited to a fighter-type background.
Dg, DD, and Sp are most suited to a fighter-type background?

For this message the author duvessa has received thanks:
archaeo
User avatar

Blades Runner

Posts: 546

Joined: Friday, 2nd October 2015, 14:42

Post Thursday, 6th October 2016, 16:35

Re: Casting UI Concerns (was: No More Haste Spell)

I believe you can setup your rc to make tab automatically cast/target the spell assigned to 'a'. This is obviously very clumsy, fiddly, and requires player actions that realistically will never happen (editing rc files). Point is, functionality exists that helps at least a little bit, but the interface for making it work isn't there.

On spellcasting UI, part of the problem is not just UI in my opinion. Having various different things you can use at any given time is good up to a point, but the crawl situation where you have a lot of options that do roughly the same thing, e.g. five kinds of direct damage spells, is problematic.
The Original Discourse Respecter

Ziggurat Zagger

Posts: 6454

Joined: Tuesday, 30th October 2012, 19:06

Post Thursday, 6th October 2016, 16:50

Re: Casting UI Concerns (was: No More Haste Spell)

goodcoolguy wrote:I believe you can setup your rc to make tab automatically cast/target the spell assigned to 'a'. This is obviously very clumsy, fiddly, and requires player actions that realistically will never happen (editing rc files). Point is, functionality exists that helps at least a little bit, but the interface for making it work isn't there.


That is what I was talking about for 'automagic' btw (it doesn't have to be bound to tab) it works ok, you can even have it stop below a certain MP threshold. But as you say, it isn't on by default, so it's unlikely that it will be used widely at all.
Spoiler: show
This high quality signature has been hidden for your protection. To unlock it's secret, send 3 easy payments of $9.99 to me, by way of your nearest theta band or ley line. Complete your transmission by midnight tonight for a special free gift!
User avatar

Barkeep

Posts: 1788

Joined: Saturday, 29th June 2013, 16:52

Post Thursday, 6th October 2016, 16:57

Re: Casting UI Concerns (was: No More Haste Spell)

I'd argue that part of the problem is that Crawl has excellent tools for tailoring the UI system to one's own preferences, but they're hidden in the .rc file system, which isn't exactly user friendly. At some point, creating a better user experience for commonly used options would be awesome.

That said, would a possible UI improvement for this problem look something like putting an option in most of the menus (evocations, abilities, spells in particular) to set a hotkey? Is there someplace in the game we could prompt the player to select what tab does?

For this message the author archaeo has received thanks: 2
Cimanyd, VeryAngryFelid

Swamp Slogger

Posts: 167

Joined: Friday, 23rd October 2015, 03:12

Post Thursday, 6th October 2016, 18:19

Re: Casting UI Concerns (was: No More Haste Spell)

What about:
  • Under your stats is displayed your "Default Attack"
  • When you tab, you use your Default Attack with the auto-targeter or move closer if out of range
  • Default Attack is chosen with the p key, which (as pollen gollem pointed out forever ago) isn't doing much right now
  • The Default Attack selection menu guides you like object creating in wizmode: "do you want to select a [s]pell, [a]bility, e[v]ocable, [f]ire from your quiver, or [m]elee?" The if e.g. the player presses 'a' display "which ability would you like to select? [insert list of abilities]"

The main awkwardness of this is that by displaying your default attack on the main screen, people might think it had an effect on game mechanics. I personally think this would be outweighed by convenience/discoverability.

For this message the author phloomp has received thanks: 3
Cimanyd, dowan, VeryAngryFelid

Slime Squisher

Posts: 368

Joined: Thursday, 11th April 2013, 21:07

Post Tuesday, 15th October 2019, 02:26

Re: Casting UI Concerns (was: No More Haste Spell)

Simple bump at ebering's request.

I still think it would be nice if a one-press keybind UI were written to reduce offensive ranged ability use down to a single tap that combined all of [ability selection + activation + targeting confirmation]. Ideally these binds would be visible from a window in-game and not require player engagement with macros/Lua/rcfile automagic fiddling.

The new positional-magic branch presents an opportunity to remove targeting confirmation from all ranged targeters, at minimum. I think that player UX with heavy spellcasting/ranged damage characters could be vastly improved by polishing the ranged UI + default ranged keybinds, and I think it would be great if changes along these lines were worked into a branch.


Please note that this thread was written as a tangent in another thread, and separated here by archaeo years ago. The ideas expressed above may not be fully supported here, but hopefully it's still reasonably coherent.

Re: Relevance to 2019 Crawl: Just assume that all of the OP still applies, because it probably does.

Dungeon Master

Posts: 250

Joined: Thursday, 27th November 2014, 19:12

Post Tuesday, 15th October 2019, 04:14

Re: Casting UI Concerns (was: No More Haste Spell)

Implojin wrote:I still think it would be nice if a one-press keybind UI were written to reduce offensive ability use down to a single tap that combined all of [ability selection + activation + targeting confirmation]. Ideally these binds would be visible from a window in-game and not require player engagement with macros/Lua/rcfile automagic fiddling.

The new Positional Spellcasting branch presents an opportunity to remove targeting confirmation from all ranged targeters, at minimum. I think that player UX when playing archetypes other than o+tab meleedudes could be vastly improved by polishing the ranged UI + default ranged keybinds, and I think it would be great if someone found the time to develop this.


I try to be conservative in my public commitments to development, to ensure I make them. See the Nemelex overhaul and the absent comprehensive card review. So, I'll say that at present I personally won't be approaching this. Not because it's a bad idea, but because I don't want to build up hopes irresponsibly.

That said, aidanh has been doing lots of good ui work over the past few versions and I will definitely see if I can con talk him into taking a look at something like what's suggested. Perhaps in this thread we can help motivating him by fleshing out the concept near the end of the OP because it is very good. Even if not I think a fairly finished design can be put on the UI Implementables GitHub wiki page, where I steer new contributors technically interested but who are unsure of the codebase or their gameplay ideas. Hopefully the hero we need will appear.

Implojin wrote: One-press autotargeted ranged attacks should be set by default to something like (non-numpad) 1,2,3,4,5, with those binds defaulting to known spells in order of memorization at each new game, and a one-press rebind available from i/I/Z/V/a to set each bind to use/fire the chosen item/spell/evocable/ability. Put a string at the bottom of each of those screens saying something like "Press 1/2/3/4/5, then press an item letter to bind an item for use."


There are technical issues with non-numpad number row and ugh but let's focus on the flow and then cross that bridge. There also isn't really room in 80x24 console hud, but maybe a quiver toggle to switch between "quiver" and "autokey" modes will suffice.

Regarding the auto-targeting, here is the flowchart I'd suggest:

  • Use last target if it's still alive and sensible to target (passes ally and self damage checks)
  • If not, but it's still alive, offer the manual targeter; only prompt once if the non-sensible thing to do is chosen and just re-do it after that
  • If not, because it's dead, select a new target automatically
  • If there are possible targets but none sensible, offer the manual targeter; again remembering the user's preference to just do it
  • If there are no visible targets go directly to manual targeting, don't force the user to go through Z or whatever (since they can bail out by aborting the targeter).

Finally, add a t command to xv to set the target for auto keys, and use ctrl or alt+num to explicitly request target selection (we don't use alt+stuff hardly at all! (there might be a reason for this I'm not good at the user input side of crawl)).

Regarding the binding of the autokeys, here Aidan's ui overhaul makes adding new buttons (and appropriate help) to the i/I/V/a screens easy. In particular, since q and r now go through the same code on the back end as i, this system could easily incorporate "single key item use".

One more neither here nor there idea: add an inscription !t to force a target prompt. I can imagine this taking the place of !f on my throwing nets (to stop me from autofight_throwing them).

Please note that this thread was written as a tangent in another thread, and separated here by archaeo years ago -- The ideas expressed above may not be fully supported here but hopefully it's still coherent.

Re: Relevance to 2019 Crawl: Just assume that all of the OP still applies, because it probably does.


The default targeters have improved some since 2016! But that's only a small step.

Swamp Slogger

Posts: 153

Joined: Wednesday, 4th April 2012, 15:11

Location: Hengelo, Netherlands

Post Tuesday, 15th October 2019, 10:41

Re: Casting UI Concerns (was: No More Haste Spell)

Another idea:
when automagic would cast a spell, show the targeter. That should give players a good indication who they will be casting at (or that they are still out of range)
User avatar

Vaults Vanquisher

Posts: 454

Joined: Thursday, 1st November 2018, 02:33

Post Saturday, 19th October 2019, 12:41

Re: Casting UI Concerns (was: No More Haste Spell)

The best way to deal with casting UI issues is removing targeters entirely, which seems like it's gotten some traction with current devs, but there is already a system that allows the player to select ranged attack types in a way that persists across sessions and whose selection appears in the main HUD -- the quiver command and automatic ranged weapon fire system. Expanding this to work with spells would deal with the ability selection aspect of this. It could also be expanded to have an "alt-fire" functionality, i.e. two quiver slots and a second trigger button. Something like tab and ` would work -- alt-fire, if set, would clobber the repeat command, no major loss imo. Now you can just remove "auto magic." Bonus points for quivering a-menu abilities and wands/evokers as well.

As far as targeting goes, one of the problems in my opinion is that the player does not know what will be targeted before opening the targeter because this information is not part of the display. Part of the problem there is that the autotargeter's choice depends on what ability would be used. With the above generalized quivering mechanics, we can take the primary quiver slot ability targeter as the default and highlight the default target or projectile path on the map at all times if applicable. The alt-fire slot target could be available via a hold-toggle button. Could have a toggle for displaying the default target at all if the player finds this intrusive. Overriding the default target could be accomplished by a chord like shift-tab, shift-` or whatever.

Of course there are a lot of details to fill in here. The player may want to have an empty primary quiver slot and only use alt-fire for a ranged attack like a wand or god ability on a melee character, and so on. Many possible use-cases to look at. This general outline will fix 90% of the fiddliness of magic and ability targeting and selection UI in crawl without wildly changing the overall interface.
This is where mechanical excellence and one-thousand four-hundred horsepower pays off.

Slime Squisher

Posts: 368

Joined: Thursday, 11th April 2013, 21:07

Post Saturday, 19th October 2019, 13:28

Re: Casting UI Concerns (was: No More Haste Spell)

I don't think that a two-slot quiver would sufficiently ameliorate the UX problems here. Mainline DCSS has how many* offensive ranged abilities? And you're proposing that an alt-fire quiver would address the UI clusterfuck of players trying to dynamically use any significant portion of them?

*This is less rhetorical and more me being too lazy to go count, but even after ebering's ranged reforms go through I'm assuming the answer will still be "lots". I hold mild hope that it might become "choko".

Think about the workflow here: As soon as players want to use anything beyond quiver-2 with some frequency, they'd have to re-quiver, presumably with something like 'QZa1', because if you're allowing abilities+spells in the quiver you have to add a differentiation key for that. Alternatively, as soon as players want to cast not-quiver-spell-3, they just go through the old-style use interface and gain nothing.

How is an ability bar better? Well, for one thing, you avoid some of the above-mentioned targeter confusion that would occur with a swap-quiver where both are bound to a single key. For another thing, you have more dynamic slots available to cover player spell/item use workflow. How many slots is enough here? I honestly have no idea, you could try to pull some measure of typical ranged ability use from the bots but I think the practical constraint here is going to be that hard 80x24 space limitation in the main viewport. Any hotbar would just translate into a UI screw if players can't see at-a-glance what's bound to each slot. This is fine and dandy in tiles, but, y'know, console.

Allowing ctrl/alt meta-binds to be used across the ability bar would be great. [Reflecting upon that old OP, shift+number binds seem obviously too drastic a change for DCSS: Commands like @%^$# are too engrained in the playerbase.]

One idea that I had the other day was to turn either ` or ~ into a generic "hotbar window" keybind. This shouldn't be the primary display of the hotbar binds; you'd want the current binds to be visible in the main viewport, but as a modality-shift window the player could use it to view all of their ctrl/alt/whatever binds if we extend the hotbar to also be capable of binding meta keys. I think the repeat last and macro binds are probably both reasonably expendable: Assuming these hotbar binds are written to fire in a single tap, any/all of the resulting hotkeys will supplant repeat last (with more functional targeting, to boot). The macro bind could be put pretty much anywhere, I think: Players probably aren't rewriting macros frequently.


I agree that removing targeters from the default use-keys is the way to go here, but for the sake of avoiding player frustration (in case of a mismatch of targeting expectations) I also think it's better to keep manual targeters available* and bound to a meta key by default.

*I'm all for the concept of making all targeting fixed-position-based. Until that is actually coded, though, manual targeters need to stick around. No matter how good we make the autotargeter decisions, someone will have a different opinion of where it ought to have targeted.

With all of this said, I do think that it would be nice for the quiver to become ability type agnostic.


Edits: tangents, clarity, more tangents
Last edited by Implojin on Saturday, 19th October 2019, 14:53, edited 4 times in total.

Zot Zealot

Posts: 1004

Joined: Thursday, 16th August 2018, 21:19

Post Saturday, 19th October 2019, 14:31

Re: Casting UI Concerns (was: No More Haste Spell)

tealizard wrote:The best way to deal with casting UI issues is removing targeters entirely, which seems like it's gotten some traction with current devs, but there is already a system that allows the player to select ranged attack types in a way that persists across sessions and whose selection appears in the main HUD -- the quiver command and automatic ranged weapon fire system. Expanding this to work with spells would deal with the ability selection aspect of this. It could also be expanded to have an "alt-fire" functionality, i.e. two quiver slots and a second trigger button. Something like tab and ` would work -- alt-fire, if set, would clobber the repeat command, no major loss imo. Now you can just remove "auto magic." Bonus points for quivering a-menu abilities and wands/evokers as well.

As far as targeting goes, one of the problems in my opinion is that the player does not know what will be targeted before opening the targeter because this information is not part of the display. Part of the problem there is that the autotargeter's choice depends on what ability would be used. With the above generalized quivering mechanics, we can take the primary quiver slot ability targeter as the default and highlight the default target or projectile path on the map at all times if applicable. The alt-fire slot target could be available via a hold-toggle button. Could have a toggle for displaying the default target at all if the player finds this intrusive. Overriding the default target could be accomplished by a chord like shift-tab, shift-` or whatever.

Of course there are a lot of details to fill in here. The player may want to have an empty primary quiver slot and only use alt-fire for a ranged attack like a wand or god ability on a melee character, and so on. Many possible use-cases to look at. This general outline will fix 90% of the fiddliness of magic and ability targeting and selection UI in crawl without wildly changing the overall interface.


This would be nice actually. Most (of my) characters have something which they spam. It would also make throwing and slings (with their stones&bullets) more convenient. I don't mind reverting to the menus for non-spammy stuff.
User avatar

Vaults Vanquisher

Posts: 454

Joined: Thursday, 1st November 2018, 02:33

Post Saturday, 19th October 2019, 14:55

Re: Casting UI Concerns (was: No More Haste Spell)

Indeed, you tend to spam the same spells/abilities over and over again in this game and once you have an interface for spamming two different spells, you've probably got over 80% of casts, then you have z-enter. It is unrealistic to expect to expose all or even a large fraction of possible spell, wand, and ability options in the top level interface without degenerating into fancy macros, which is in fact what implojin is talking about as far as I can tell [edit: did not see implojin edits until later, not sure what his real thoughts are as of this writing].

Now of course, you could talk about additional alt-fire triggers, say on the function keys. You will not be able to cleanly expose their state in the HUD, I think, so you're talking improved macros already. Exposing targeter state also becomes more involved, but maybe reasonable through chording. But fine, you can do this. You are already getting into strongly diminishing returns.

The important point is to think in terms of number of commands affected rather than number of types of commands affected -- obviously there are tight constraints on the number of types of commands you can helpfully address and how helpfully you can address them with these kinds of changes. We need to accept that and concentrate effort where it can have the most impact.

Incidentally, the alt-fire quiver is new, useful functionality for characters that never cast a spell.
This is where mechanical excellence and one-thousand four-hundred horsepower pays off.

Slime Squisher

Posts: 368

Joined: Thursday, 11th April 2013, 21:07

Post Saturday, 19th October 2019, 16:26

Re: Casting UI Concerns (was: No More Haste Spell)

For clarity, my vision of a skill hotbar in Crawl began simply:

10 hotkeys, bound to 1 through 0.

This came from some thoughts about turning the game into a coffebreak roguelike with a drastically reduced usable item inventory.


Developing the concept from there (years ago) into something that might work in Stone Soup brought with it the necessity of (somehow) fitting the skill hotbar display into the available console window space.

At the time, it seemed like there was space for maybe 4 to 6 items to be displayed in the main window, underneath the character stats. I think this was before the noise bar existed; I'd have to take a look at how much space is available in $current_year.

Working within that 4 to 6 slot limitation, and with the understanding that 4 to 6 binds really isn't that much relative to the total amount of usable targeted spells/species abilities/god abilities/evocable items/ranged weapons that exist in DCSS, my interpretation of this discussion then developed into layered keybinds of a simple [1,2,3,4], [Alt+1,2,3,4], [Ctrl+1,2,3,4] kind of thing. I am envisioning here that holding Ctrl or Alt would dynamically change the displayed slots in the main window, to display any abilities bound there.

I don't think that these keybinds need to be able to do fancy macros: That would defeat the purpose. (The purpose being to make ranged combat in Crawl more palatable from a player-ease-of-use perspective.) DCSS already has multiple ways to keybind fancy macros: The in-game macro editor, and the out-of-game ability to write custom Lua functions in your rcfile. We don't need more of that.

My interpretation here has always been that these binds just need to hook a good-enough autotargeter and fire, with the important part being that they do so in one keypress. Rebinding them obviously needs to be fluid from the player's perspective, given that many of the abilities intended to be bound here are charge-limited. Nothing out-of-game, no macro editing text prompts, if a thing runs out of charge it's removed from the bar on the fly. New things should probably be added automagically too.


Honestly, I'm open to the notion that there may be some better way to approach this than what's in my head. I think the last time I started Crawl for purposes other than local branch testing was something like two years ago? The implementation nuance is better left to someone who is more familiar with the current behavior of the targeters and UI backend -- I referenced these concepts in ebering's thread in the hope that something like it could make its way into mainline DCSS alongside the positional spellcasting rework.
User avatar

Vaults Vanquisher

Posts: 454

Joined: Thursday, 1st November 2018, 02:33

Post Saturday, 19th October 2019, 20:38

Re: Casting UI Concerns (was: No More Haste Spell)

What I mean by "fancy macros" is macros made in a more streamlined way than with a literal macro language/in-game editor like what (I presume, I've never used it in any serious way) we already have. That is, a single choice of action (targeting included, but with no visual indication of the target in the interface) bound to a single key. Such a thing would be only a marginal improvement over what's already available through basic rc options and macros of course.

As long as it's possible to manually target some ranged attack, you're going to have manual targeters even if there are fewer of them and any kind of one keystroke attack trigger will therefore have to autotarget some effects. This is where quiver/fire/tab's model looks pretty good. If you need to target manually you can, the only problem is that you may not know when you need to target manually to hit your desired target. I'm not aware that this issue has been raised before, but it seems to me that it's worth considering as part of the story of streamlining things along the lines you consider here. Of course this is relevant to melee target selection by tab as well. This is the value of registering a primary attack as I've described -- the game will know what it can target and can tell you what its default target will be before opening any menus or activating any command.

Given that you will sometimes need to manually target things, it would be good for the same interface to allow autotargeted and manually targeted versions of the same ability, hence the value of associating the key and chorded/modified versions of the key with the same ability with different targeting behavior. If I understand this other approach implojin suggests, then manual targeting would fall back to the usual system. Not so good imo.

Now I admit a generalized quiver menu like I'm talking about would be sort of a combination of the = menu and the existing Q menu, slightly complex. On the other hand, a large number of slots that essentially amount to macros is going to create more management and need to remember and fiddle with subscreens or display modes than what is effectively an extra virtual equipment slot.
This is where mechanical excellence and one-thousand four-hundred horsepower pays off.

Return to Game Design Discussion

Who is online

Users browsing this forum: No registered users and 21 guests

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.