Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[anallyst]

every time i start another try with df, i get soon frustrated by the weird menu design, so i stop playing after a while.

in some menus with 2 columns, you can move left and right with left and right keys.
in others, you have to use two sets of cursor keys for every column. (stock vs trading menu)

make menus use columns, which can be switched via tab and then
navigated via cursor keys, in ALL of them.
there could be a convention that the first column can be directly accessed via F1, the second via F2, etc.
in the embark window, where TAB has another meaning, just select another key for that purpose like "Home"
the embark window consists of 4 tabs, in each one of them cursor keys should work.

whenever an area can be designated, use the same system: select start and end sector.
i'm speaking about the weird ukhm/UKHM style navigation i.e. used for selecting the embark region or building walls.

once that is fixed i'll make a generous donation, because then i can actually enjoy the game.

[Jake]

Okay, a couple of points to consider.

First, this is an alpha, with slightly less than one third of the planned features added. If Toady spends a couple of months reworking the interface now, with a bunch more stuff to shoehorn in, we'll be in the exact same mess all over again by the time v0.6 rolls around.

Second, a conservative estimate based on forum membership numbers puts the DF player community at twenty thousand people, and they all seem to get along just fine. I wholeheartedly agree that it's confusing at first and not especially consistent, but you do get used to it.

[anallyst]

a couple of months ? i bet its at most 2 days of work, and it would save future hardcoding of even more incosistent menus, because i suggest to create one main menu class like this

Code: [Select]

trading_menu = menu.new();
trading_menu.add_column(stock_column);
trading_menu.add_column(trader_column);
trading_menu.set_select_key(VK_ENTER);
trading_menu.add_action("T", "Trade", &do_trade());
trading_menu.show();
an additional benefit would be that more players could eventually get used to the game, which means more donations to save the toad.

[thijser]

The main problem with the argument that we are not done yet is that if we really are at only 1/3 then we still got 18 years to go before we are done. I somehow doubt df will still be very populair in 18 years and I doubt even more then once we approach the end of the 18 years that we will still have the same number of planed features.

[Virex]

Everyone (save for some it seems) know how to operate the "inconsistent" menus almost intuitively. I don't see why toady should take the time to redo the interface and confuse even more people then it does now, since everyone has to relearn how to use the interface. On top of that, he'd be doing the job of the player, since almost all keys can be reconfigured, including those that govern how the menus are operated.

[Jake]

The main problem with the argument that we are not done yet is that if we really are at only 1/3 then we still got 18 years to go before we are done. I somehow doubt df will still be very populair in 18 years and I doubt even more then once we approach the end of the 18 years that we will still have the same number of planed features.

That assumes an equal length of time between major updates. My impression from the speed at which things are progressing now is that a lot of the really fundamental stuff is now squared away, and we'll get to 0.4x a lot sooner than we did 0.3x.

[GTM]

every time i start another try with df, i get soon frustrated by the weird menu design, so i stop playing after a while.

I feel your pain, but the reality is that an interface overhaul is not on the agenda any time soon.  For the time being, you're better off adapting your playstyle to mesh with the way the game's interface works.  I think you'll find that it's not that arcane after you get used to it - that's been the case with many of us, at least.

[jei]

a couple of months ? i bet its at most 2 days of work, and it would save future hardcoding of even more incosistent menus, because i suggest to create one main menu class like this

Code: [Select]

trading_menu = menu.new();
trading_menu.add_column(stock_column);
trading_menu.add_column(trader_column);
trading_menu.set_select_key(VK_ENTER);
trading_menu.add_action("T", "Trade", &do_trade());
trading_menu.show();
an additional benefit would be that more players could eventually get used to the game, which means more donations to save the toad.

I second the above. It's not 2 months of work, it's one decent day + undoubtedly various bugfixes. This current "random interfaces" style is a significant part of what keeps many from even starting to play and learn the game, - They just don't want to bother with learning a weird counterintuitive interface. Cut off a decent part of the learning curve and you multiply the interested players who will get hooked.

[Auto Slaughter]

I can see it being more than a couple of days but a couple of months seems like way too much.  Changing the keys around to be consistent between different screens, or adding a mode where the controls are consistent (this alpha interface looooves modes, which are just about the biggest no-no there is in text-based interface design) is not reworking the entire interface and would not derail the project.

Seriously, Virex - putting "inconsistent" in scare quotes?  What are you smoking?  You don't have to pretend that this is the first time you've ever come across the notion.

I've been using AutoHotkey under Windows to remap the cursor controls to a USB gamepad and I have run out of joystick axes because the gamepad I'm using only has eight axes.  I was getting along with settings for 8462 / cursor keys, -+*/, umhk, and UMHK but today I came across another screen that uses wasd.  Or for another example, to back out of a menu or confirm changes (and often it's not clear which one of those you're doing, sometimes backing out is confirming changes and sometimes it's not) can be escape, enter, shift-enter, d, x, or 4 / left-arrow.

It's an alpha and it's such a fabulous game that people will just suffer through the interface - unlike thijser I'm pretty confident that df will be popular 18 years from now, people are still playing Super Mario Bros. and porting / emulating it to Flash and Java HTML5 / Canvas and doing derivative games and riffing on it, aren't they?  Doom came out almost 18 years ago for example (and whoa, in looking for the release date I just came across Doom, the Roguelike, most recently updated in March of this year) - but a really minimal amount of effort could clear away a great deal of the migraine-inducing obstructions to enjoying it.  I have ADD with pretty high distractablility and I would seriously estimate that I spend 60 or 65 percent of my time bogged down in screwing around with the interface, hitting the wrong key on the wrong screen and heading down the wrong branch of the menus (like, I'm in b - Build, C - Walls/Floors/Stairs and I mean to back out so I reflexively hit x, but instead of backing out that takes me down into x - Up/Down Stair, and I realize I'm lost so I hit escape twice but that only takes me up to b - Build, so when I hit b again to try get back into the Build menu and start over it instead takes me to b - Build, b - Bed and I have to stop and figure out what the hell went wrong; note that in many other areas you can head down four or five menu levels and just hitting escape once will take you back to the root - and that's always when I want to be able to back up only one level, of course) and then zoning out and forgetting what the hell I was trying to do in the game because I'm lost in the interface.

It's like a 1980s interface, and not a fairly good 1980s interface like NetHack (there's another oldie for you, released 23 years ago and still going strong, I saw a version completely converted into a web application not too long ago.)  I'm not referring to it being a text-based interface, I have no objection to that, I'm talking about basic usability issues that were overcome in text-based interfaces decades ago.

But with any luck Toady'll get around to it soon, especially if there are more $16k donation months like April!

[Mckee]

Yes the menu's are inconsistent, yes it can be a pain sometimes if you are trying to do everything very quickly, but aside from the fact you can alter the key binds yourself, the game actually tells you what each button does on each menu.

I don't speed game on DF, if it takes me half a second to check whether it is enter or escape, it makes very little difference overall. I think Toady has more important stuff to take care of. The game is still in alpha, much more is going to be added. I reasonably expect many more weirdly assigned menus and thats just life with DF.

[Auto Slaughter]

...the game actually tells you what each button does on each menu.

That's why I said that it's like a 1980s interface instead of saying it's like a 1976 interface.  You're right that it definitely beats out vi, for example, but that's a ridiculously low bar.

I don't speed game on DF, if it takes me half a second to check whether it is enter or escape, it makes very little difference overall. I think Toady has more important stuff to take care of. The game is still in alpha, much more is going to be added. I reasonably expect many more weirdly assigned menus and thats just life with DF.

If you only had to press enter or escape infrequently it would be okay but spending 60 or 65 percent or more of one's play time in UI snafus or fumbles is not insignificant.  It's not a matter of speed playing, it's a matter of spending your time playing at all.  I sure as heck am not a speed player of any game.

I can understand it if you don't have any experience with software development but pretending that usability is inconsequential is almost as ludicrous as pretending that df's UI is not inconsistent.  As people have pointed out above this could be fixed with a fraction of the amount of effort that, say, implementing pathing took, or even just the amount of effort that setting up the Mantis bug tracker took.  It's very important so in combination with it being such a small task it would provide an immense amount of ROI for investment of programming hours.

It really is not very reasonable to leave the UI like this; quite frankly it's the sort of thing a dwarf would do if a dwarf was a software developer, so maybe you're right though that it's to be expected.

[Ethicalfive]

I also agree that an understandable, consistant menu system is a must. I remember first picking up this game, unable to get my mind around the menu system at all, everything seemed to make no sense at all. Fortunately for me, I persisted, read alot of forum posts, wiki articles and binged on captnduck tutorials and now the menu system is *almost* second nature to me.

I can clearly see where new features have come in and each new submenu style seems to reflect that. I don't think it is too much to ask for abit more consistency, with the benifit of less persistant players actually able to pick the game up also.

I also made Dwarfpad(linked in sig) in a bid to try take some of the pain out of the umhkUMHK system. Seems there was little to no interest in it, but seeings as I provide the script along with the executable, should be simple to extend for anyone that wants to do so.

@Auto Slaughter: I also thought about mapping my controlpad for handling dwarf fortress, but I did want to learn about ahk's UI, do you have your ahk scripts up anywhere?

[Auto Slaughter]

@Auto Slaughter: I also thought about mapping my controlpad for handling dwarf fortress, but I did want to learn about ahk's UI, do you have your ahk scripts up anywhere?

I pretty much just copied the AHK examples with a few added variables, but here it is.  You might have to change things if your joystick axes have different names, which their sample script JoystickTest.ahk will tell you.

Code: [Select]

;
; AutoHotkey Version: 1.x
; Language:       English
; Platform:       Win9x/NT
; Author:         Auto Slaughter
;

#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.

#Persistent  ; Keep this script running until the user explicitly exits it.
SetTimer, WatchPOV, 5
SetTimer, WatchAxis, 5
SetTimer, WatchAxis3, 5
return

WatchPOV:
GetKeyState, POV, JoyPOV  ; Get position of the POV control.
KeyToHoldDownPrev = %KeyToHoldDown%  ; Prev now holds the key that was down before (if any).

; Some joysticks might have a smooth/continous POV rather than one in fixed increments.
; To support them all, use a range:
if POV < 0   ; No angle to report
    KeyToHoldDown =
else if POV > 31500                 ; 315 to 360 degrees: Forward
    KeyToHoldDown = -
else if POV between 0 and 4500      ; 0 to 45 degrees: Forward
    KeyToHoldDown = -
else if POV between 4501 and 13500  ; 45 to 135 degrees: Right
    KeyToHoldDown = Enter
else if POV between 13501 and 22500 ; 135 to 225 degrees: Down
    KeyToHoldDown = +
else                                ; 225 to 315 degrees: Left
    KeyToHoldDown = Esc

if KeyToHoldDown = %KeyToHoldDownPrev%  ; The correct key is already down (or no key is needed).
    return  ; Do nothing.

; Otherwise, release the previous key and press down the new key:
SetKeyDelay -1  ; Avoid delays between keystrokes.
if KeyToHoldDownPrev   ; There is a previous key to release.
    Send, {%KeyToHoldDownPrev% up}  ; Release it.
if KeyToHoldDown   ; There is a key to press down.
    Send, {%KeyToHoldDown% down}  ; Press it down.
return


WatchAxis:
GetKeyState, JoyX, JoyX  ; Get position of X axis.
GetKeyState, JoyY, JoyY  ; Get position of Y axis.
KeyToHoldDown2Prev2 = %KeyToHoldDown2%  ; Prev now holds the key that was down before (if any).

if JoyX > 70
    KeyToHoldDown2 = Right
else if JoyX < 30
    KeyToHoldDown2 = Left
else if JoyY > 70
    KeyToHoldDown2 = Down
else if JoyY < 30
    KeyToHoldDown2 = Up
else
    KeyToHoldDown2 =

if KeyToHoldDown2 = %KeyToHoldDown2Prev2%  ; The correct key is already down (or no key is needed).
    return  ; Do nothing.

; Otherwise, release the previous key and press down the new key:
SetKeyDelay -1  ; Avoid delays between keystrokes.
if KeyToHoldDown2Prev2   ; There is a previous key to release.
    Send, {%KeyToHoldDown2Prev2% up}  ; Release it.
if KeyToHoldDown2   ; There is a key to press down.
    Send, {%KeyToHoldDown2% down}  ; Press it down.
return


WatchAxis3:
GetKeyState, JoyZ, JoyZ  ; Get position of Z axis.
GetKeyState, JoyR, JoyR  ; Get position of R axis.
KeyToHoldDown3Prev3 = %KeyToHoldDown3%  ; Prev now holds the key that was down before (if any).

if JoyZ > 70
    KeyToHoldDown3 = k
else if JoyZ < 30
    KeyToHoldDown3 = h
else if JoyR > 70
    KeyToHoldDown3 = m
else if JoyR < 30
    KeyToHoldDown3 = u
else
    KeyToHoldDown3 =

if KeyToHoldDown3 = %KeyToHoldDown3Prev3%  ; The correct key is already down (or no key is needed).
    return  ; Do nothing.

; Otherwise, release the previous key and press down the new key:
SetKeyDelay -1  ; Avoid delays between keystrokes.
if KeyToHoldDown3Prev3   ; There is a previous key to release.
    Send, {%KeyToHoldDown3Prev3% up}  ; Release it.
if KeyToHoldDown3   ; There is a key to press down.
    Send, {%KeyToHoldDown3% down}  ; Press it down.
return

[Auto Slaughter]

Another little note: for anyone trying to do the same thing in Linux with a gamepad the utility qjoypad is the way to go, although it's a GUI rather than a scripting interface.