Print

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

[Miuramir]

"Bed: Needs Bed" is a great example of where improvement can be made, and a fairly good test case to think about improvement options. 

I am pretty strongly of the opinion that hiding options generates both less learning, and more confused questions.  Graying out is a superior choice in almost all cases. 

Given that, one observation I've noted in a couple of applications in the last year or so is that the added utility of the application having a pop-up or other presentation on long-hover of *why* something is grayed out is a really significant from a end-user standpoint.  (Or, perhaps, "Press F1 to show reason this choice is not available"?)  If the user in the above example was presented with "Cannot designate location to install bed because no unallocated and unforbidden beds are in site inventory", that would provide an immediate and substantial clue toward what to do to fix the problem.  If, when then attempting to craft a bed, they were then presented with "Bed cannot be queued for crafting because no unallocated and unforbidden suitable materials are in site inventory (objects of type "bed" require available material of type "wood")", that would then lead fairly obviously to the next stage of the process, and so on. 

The above level of more specific and resolution-focused error message shouldn't require too much additional program logic (tm), as one would presumably set up a structure such that the code check that sets the option grayed out also sets the "why" string or code to be handled by the interface later in whatever fashion(s). 

A further advancement in user-friendliness would be proactive, resolution-focused warnings, possibly of more than one severity level.  "Warning: You are attempting to designate a tree-chopping area, but no available dwarves have Wood Cutting enabled as a labor.  Continue anyway? Y/N", perhaps.  "Suggestion: You are attempting to designate a tree-chopping area, but while there are X dwarves with Wood Cutting enabled as a labor, none have an axe in their personal inventory, and there are no unallocated and unforbidden axes in site inventory.  Continue anyway? Y/N" would be an even further refinement.  This *would* require extra work at a few levels; while it would probably be worth it in the end, I'm not sure that's a sensible goal for a near-term release. 

The overall intent of resolution-focused messages should be that, when seeing the detailed error, warning, etc. message, there should be an obvious, implied action that the user presented with the message can try to resolve it.  If this is propagated through the whole interface, it will naturally lead users to discover the things they need only slightly after they need them, even on their first playthrough. 

(I am old-school about Roguelikes enough that I am OK with users having to make a few mistakes to learn; but it should be obvious what went wrong and what direction to try something different on the next take.  So, "I need to place beds to keep the dwarves from complaining about not sleeping in a bed; but I didn't bring any beds, or any wood, and I embarked on a barren mountainside with no trees, and I'm screwed." is an acceptable bad end, because you've done something that is not the normal default to start with, and have several immediately obvious options for trying again with better choices.  Some people prefer learn-by-doing, and resolution-focused messages strongly help with that.  Others prefer learn-by-research, and they will presumably encounter some sort of walkthrough or guide suggesting that wood is useful in the course of doing so; in case they've unknowingly failed or forgotten a step, the resolution-focused messages help them get back on track.) 

Edit: To add a light-hearted example, consider the famous Monty Python Cheese Shop Sketch as an example in (bad) user interface design. 

Enter Shop > Talk to Shopkeeper > Buy Items > Buy Cheese
Select type of cheese to buy: [Red Leicester] > Red Leicester is not currently available.
Select type of cheese to buy: [Tilsit] > Tilsit is not currently available.
Select type of cheese to buy: [Caerphilly] > Caerphilly is not currently available.
...
Select type of cheese to buy: [Camembert] > Select type > Firm > Firm Camembert is not available
Select type of cheese to buy: [Camembert] > Select type > Runny > Runny Camembert is not available
...
ESC > Set Options > Shop music loop > Off
...
and so on. 

If the response to "Buy Cheese" had been, say, "Buy Cheese: 0 units in 0 types currently available", the whole frustrating experience would have been short-circuited.  Bad for a comedy sketch based on increasing frustration, perhaps; but far better when considered in light of the new user / "noob" experience.

[Miuramir]

Expanding slightly on my previous post, another related UI / UX / presentation issue is making a clear distinction between what might be called "direct actions" and "speculative actions"; especially as users coming from other games may have differing expectations about which actions are which. 

A direct action, here, is an action that is expected to process more-or-less immediately; and therefore cannot be taken if some sort of prerequisite is not met.  For example, in DF, you can't designate a spot for a bed, unless you have a bed to go into it.  This is in contrast with speculative actions; you can designate an area for dumping or wood-cutting, even if there is nothing to dump or no trees to be chopped.

Direct actions, when not possible, should ideally always have a resolution-focused reason presented to the player, as discussed in my previous message. 

At some level, a speculative action is never "wrong" from a strict interface standpoint, because a player may be "working ahead" or simply being proactive should the situation change.  That said, useful feedback and/or suggestions can still help the user experience considerably.  "Designating wood-chopping area: X trees in currently-selected area" would be one example, perhaps with a color or minor message change to distinguish the case in which there are no trees selected; or a "Warning: valid area selected for wood-chopping, but no mature trees are currently in the selected area; Continue? Y/N" warning.  In an idea world, each such warning could be toggled on or off in a config file or menu, to match individual playstyles. 

One reason to be better about identifying this sort of thing is that users coming from other games (or simply with a different personal worldview) may have differing expectations about action types.  To continue the "Bed: Requires Bed" example, the user may have been expecting that one would design and place the locations for the furniture of a room first, and then work on constructing the needed elements based on some sort of needs list.  They were expecting that "place bed" would be a speculative action ("Here is where I would put a bed, if I had one"), in contrasts to DF's direct action approach (you need a bed that is already constructed, in an accessible location, not forbidden, etc. to execute the "place bed" action).  This isn't unreasonable, or wrong in the larger sense, but it's not how DF does things; and they can't be expected to know that as a new user. 

A related improvement, and somewhat more challenging from a coding standpoint, would be to have some sort of "pending job status debug" screen, where you could see a list of jobs, optionally sorted by how long they have been waiting, and the reason they are waiting.  So, to continue our example, the user gets a bed made, gets it designated, and then goes off to do other things.  Several months later, they happen to see the unhappiness message again and ask "why isn't there a bed?".  They could pull up the pending job screen, and see that the "install bed" job is on hold because of "No available furniture haulers", and then go fix that. 

[Orange-of-Cthulhu]

I think we should, at least get the following commands/order/whatever:

- do not leave area (could be a burrow or a new kind of zone)
- do not initiate attack (stay in position until attacked by someone, go back to position until attacked again)
- attack anything on sight (current behaviour)
- move somewhere (as in, stop anything you are doing and go to this place)

That at least would make things a little more noob friendly.

At the very least have specific orders be "followed" as high priority (so, if I want the whole squad to attack a specific enemy or retreat). Currently once a dwarf starts fighting you can forget about it and that's very frustating and not expected.

Definitely yes, you can loose your entire military simply because you are not aware that retreat is not an option.

If you're used to games with control over units (which is nearly all games!) you could easily come up with schemes like "I send in my squad vs 200 goblins, then retreat just when they see me and run away and make them follow me, so I can lead the enemy to some kill zone." And then they barge in unextectedly.

The "setting" the dwarfs are on is like the maximum agressiveness possible in tactical games "suicide attack". They need to have the normal range of settings, such as the stuff you mention. I think the default setting should be they never attacked anybody unless the player told them to, but they'd defend themselves plus by default attack people they see attacking another dwarf. But you should be able to give them a bunch of different orders.

I would say on the other hand - dwarf military is already OP as it is. If we got good tactical possibilities, it will become really a lot OP

I think marksdwarves should be set to "fire at will" by default though, as they already are.

[Orange-of-Cthulhu]

Just had my first go at Adventure Mode.

I think maybe you should have a "grace period" of immunity to Bogeymen when you create a new adventurer.

What happened was: I know the world I am in. Went to a small site, tried controls like wrestiling a cats, learned how to eat etc.

Then I wanted to go visit one of my fortresses. On the way there I got attacked by bogeymen and died. (I thought they only came when they slept or when you were in evil biomes, but they just set on me as I was walking at night.) Was still learning how I wield a weapon and so on, so had no chance

It feels underwhelming to die like with zero chance of making it out, just from walking in a forest. Because it should be relatively safe to walk in a random forest.

So maybe if bogeymen didn't attack you like right off the bat, but the game waited to have them attack you till you had played for a whole? I think it's pronanly fine they show up if you have a chance of dealing with them, but the playthrough felt more like the game was punishing me for playing lol.

[Shonai_Dweller]

Just had my first go at Adventure Mode.

I think maybe you should have a "grace period" of immunity to Bogeymen when you create a new adventurer.

What happened was: I know the world I am in. Went to a small site, tried controls like wrestiling a cats, learned how to eat etc.

Then I wanted to go visit one of my fortresses. On the way there I got attacked by bogeymen and died. (I thought they only came when they slept or when you were in evil biomes, but they just set on me as I was walking at night.) Was still learning how I wield a weapon and so on, so had no chance

It feels underwhelming to die like with zero chance of making it out, just from walking in a forest. Because it should be relatively safe to walk in a random forest.

So maybe if bogeymen didn't attack you like right off the bat, but the game waited to have them attack you till you had played for a whole? I think it's pronanly fine they show up if you have a chance of dealing with them, but the playthrough felt more like the game was punishing me for playing lol.

You were very unlucky and wandered into an evil biome (one of the very few places bogeymen still exist, and even then many don't have them - they don't come out at night any more). Use one of the many world utils to check out the geography first. If the bogeyman didn't get you, one of the many other beasts in these incredibly dangerous areas would have. Or the evil rain.

Doesn't the name of the region appear in the fast-travel map? You can normally tell by it's name if you should be avoiding the area.

Alternatively you found a bug (or are playing a modded game). Post your save if you still have it and are sure you're in a regular area. What you're complaining about is not something which is supposed to happen.

[Schmaven]

It could be an earlier version too.  I don't recall when bogeymen were changed, but I think it was fairly recently that they were.

[Shonai_Dweller]

It could be an earlier version too.  I don't recall when bogeymen were changed, but I think it was fairly recently that they were.

Then should be deleted from this thread. Meaningless noise to complain about old versions of the game in a thread aimed at improving the current version.

[Orange-of-Cthulhu]

It could be an earlier version too.  I don't recall when bogeymen were changed, but I think it was fairly recently that they were.

Maybe that's it, my version is the one before the villains update.

Anyway, my posts about bogeymen can then be taken as an expression of satisfaction that the issue was resolved

[Rumrusher]

ok so I was wondering how many new players are getting hit with that guildhall adv camp bug that crash to desktop if you ever make a guild hall?

[Shonai_Dweller]

ok so I was wondering how many new players are getting hit with that guildhall adv camp bug that crash to desktop if you ever make a guild hall?

New players not only actually playing Adventurer but trying out the building interface, successfully making some buildings and then trying to make a guildhall? Likely about 3.

[darkhog]

Please integrate Dwarf Therapist functionality. I know that Toady doesn't like spreadsheets and all, but honestly it is the best way to assign labors, check on skills and so on, otherwise DF-likes like Rimworld or Gnomoria wouldn't ape DT.

[Putnam]

Please integrate Dwarf Therapist functionality. I know that Toady doesn't like spreadsheets and all, but honestly it is the best way to assign labors, check on skills and so on, otherwise DF-likes like Rimworld or Gnomoria wouldn't ape DT.

There was already talk about the labor overhaul in August last year.

[Timeless Bob]

Upon unretired embarks, all chests and cabinets become unbuilt.  In a fortress with several hundred bedrooms, a hospital, and several crafting halls, this makes re-designating EVERY SINGLE ONE a serious chore.  I would imagine this would be a game-breaker for noobs who want to come back to visit their old successful fortress after experiencing an upset that ends their most recent one.

[Neckbeard]

I don't know if this thread is still taking suggestions, or if this has been suggested before (but I did search for it).

Basically item stacking issues are a real pain ingame.

In particular, when bolts are fired from a crossbow, the stack of bolts goes from being 1 stack of 25 bolts (or 5 if they are made from bone) to 25 stack of one bolt.  If those bolts are recovered and re-used, the quiver will only hold 3 stacks of bolts, i.e. 3 stacks of one bolt each.  You may as well just make every bolt break after being fired for all the good those singular bolts actually do.  Is it really that hard to stack bolts of the same quality and material back up to a maximum of 25 per stack after they have been used?  It also encourages players to melt down single bolts fired from crossbows, which leads to metal duplication.

Same issue crops up with processing item stacks into other useful items.  Like brewing pig tails into dwarven ale.  I can't get stacks of 9 items to brew into 45 units of alcohol anymore, as the cap is for booze stored in a barrel or pot is now 25.  Meaning, at most, only 5 brewables should be used to brew booze.  If we know that, is it that hard to get dwarfs to gather 5 of something, possibly from different stacks before doing the actual brewing operation?  As it stands now, if you want efficient booze storage and usage, you have to constantly micromanage item stacks by forbidding and un-forbidding item groups to get the brewer to do their job efficiently and correctly.  Same goes for the miller, milling dimple dye, and probably a few others.

Update: Actually it turns out that I can get stacks of booze bigger than 25.  At least for some above ground based crops.

As a side note to the above, embarking with something like grapes to make booze with is doable, but tedious and un-intuitive.  Because the grapes are stored in a bag, and the still wont recognize above ground fruit in a bag as usable, I have to dump the grapes out of the bag into a dumping zone that is situated over a food stockpile, and then reclaim them in order to use them for brewing.  The stockpile isn't enough because the dwarves will just put the bag with the grapes still inside into the stockpile, but not empty the bag.  I think this has something to do with above ground fruits being labeled as "leaves", which itself is bad, because it makes you think you are brewing with the leaves of the grapes, instead of actual grapes.  If you farm them, you get both a grape plant, and also the grapes themselves.  The grape plant seems to be useless junk itself, but it can be stored in the food stockpile, while it's the "leaves" that you want.  I know this is nitpicky, but it really needs fixing.

The stacking issue is also prevalent when working with ash, lye, and potash.  You can embark with lye stacked up to units of 5, but you can't make it stacked up that way.  Every unit of lye that you create is always a stack of one.  Meaning, every time you use lye to make potash or soap, you have to gather it one at a time.  But the lye you embark with is properly stacked.

It's also an issue with tallow made at the kitchen.  Every glob of fat is turned into an equivalent glob of tallow.  But then the single stack of tallow takes up a whole barrel or pot when stored in a stockpile, which then takes up a whole space in the food stockpile.  Not game breaking, but kind of annoying if you are low on food storage, or space.

It's not like the game can't handle stack management either.  I've seen the dwarves do it correctly when working with milk to make cheese.  You can tell the dwarves to milk creatures over and over again, to get a barrel full of milk, and then tell them to turn it into cheese, and you'll get a big stack of cheese when they do.

It might seem like a small thing, but improper stack management leads to all sorts of stupid, preventable issues, like overproducing items that lead to FPS death, marksdwarves not stocking up on ammo properly and running out if they need to be deployed in the field (and they *can* be deployed in the field, is managed properly.  I don't see why they should be restricted to just being defensive units all the time.), having it take forever to haul items that are actually light and small because they are being hauled one at a time (except for seeds, thankfully.), not being able to see how many of a specific item is actually in a container or on a tile because you are scrolling through endless entries of items that should be stackable, having to maintain 100's of pot and barrels of booze (and other items created as stacks like prepared meals) because the dwarves like to take from bigger stacks instead of finishing off little stacks of items (leaving tons of barrels of booze that have like 1 unit of beer or rum in them instead of finishing it to free up the container for re-use), tons of pathing that has to be done over and over that comes from all of these operations, and the like.

I know I can fix most of these problems by manually dumping items into a one time zone that set up for manually moving items into a space, but it's tedious to oversee this process constantly and really takes away from the rest of the game.



While I'm at it, single tile booze stockpiles are aggravating in a different manner in that the first tile always has an empty reserved barrel on it, and never gets booze brought to it.  This is an issue for jail cells as what should be a simple exercise in turns into a weird complicated thing where you need to spread a booze stockpile over multiple jail cells, chop it down to size (starting over if you mess it up), and then make sure you have a tile that is walk-able, outside of the cells, to the top left, that an empty barrel can be placed, just so that you can lock the room that tile is in once it has it's reserve barrel, so that every other tiles will actually have a barrel of booze placed upon it.  Other items that don't require a container can be put into a mini stockpile, but not ones with containers.  This is really important for the justice system to work smoothly, as having dwarves die of thirst in jail over a random trade restriction announced after the fact is just aggravating.