Print

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

[PatrikLundell]

You mix up mods and utilities. These are two very different things. And, regardless, there not time to implement even half of what ought to be implemented of the basic functionality, so any utility functionality that makes it in would have to be very low hanging fruit (a sand indicator might be such a thing, but don't count on it, especially given the bugs associated with that area of the code: touching the code means having to decide on implementing something that's known to be buggy, or address the bugs, which takes time that's not abundant).

There are a number of utilities that a lot of people use, and a fair bit of that can be considered cheating by at least some players, and there's a significant number of players that don't use any utilities at all. An example that's been discussed is management of labor, where Toady as an aversion to spreadsheet type functionality (e.g. Dwarf Therapist), instead leaning towards internal logic (there are a couple of DFHack plugins for automatic reassignment of labor based on what jobs the logic think needs doing). If one of those approaches is taken while blocking the other, a significant portion of the existing players will be unhappy with the decision (I would be if the one that's wrong for me is chosen).

There are no mods that "everyone" use. There are popular mods that quite a few people use, but, just as with tile sets, there are wildly different preferences. I'd be rather surprised if even half of the players are using any one mod (and suspect not even half of the players use any proper mod at all).

The plan includes mod support, i.e. support to add/remove mods in some easier fashion than the current one, which is the normal way to deal with mods. The game strives to make as much of it as possible moddable, to gradually make more and more of the definitions available as RAW files.

[VABritto]

I think the only thing I could say is my main issue is FPS. Everything else (except tantrum spirals due to corpse seeing) is actually even fun to try fo figure out how to solve. But FPS death is the ultimate downer. Followed relatively close by corpse hauler's insanity.

[Dr. Hieronymous Alloy]

You mix up mods and utilities. These are two very different things. And, regardless, there not time to implement even half of what ought to be implemented of the basic functionality, so any utility functionality that makes it in would have to be very low hanging fruit (a sand indicator might be such a thing, but don't count on it, especially given the bugs associated with that area of the code: touching the code means having to decide on implementing something that's known to be buggy, or address the bugs, which takes time that's not abundant).

There are a number of utilities that a lot of people use, and a fair bit of that can be considered cheating by at least some players, and there's a significant number of players that don't use any utilities at all. An example that's been discussed is management of labor, where Toady as an aversion to spreadsheet type functionality (e.g. Dwarf Therapist), instead leaning towards internal logic (there are a couple of DFHack plugins for automatic reassignment of labor based on what jobs the logic think needs doing). If one of those approaches is taken while blocking the other, a significant portion of the existing players will be unhappy with the decision (I would be if the one that's wrong for me is chosen).

There are no mods that "everyone" use. There are popular mods that quite a few people use, but, just as with tile sets, there are wildly different preferences. I'd be rather surprised if even half of the players are using any one mod (and suspect not even half of the players use any proper mod at all).

The plan includes mod support, i.e. support to add/remove mods in some easier fashion than the current one, which is the normal way to deal with mods. The game strives to make as much of it as possible moddable, to gradually make more and more of the definitions available as RAW files.

That's not really an objection, that's just "implement a toggle option." (And time is, after all, relative).

Mod support is great but if you want the game to be accessible to new players -- specifically popular Steam audience players -- you need to make things like Dwarf Therapist the default option when a new player boots up the game for the first time.  Said another way, if the Steam version is adding an additional design goal -- "accessibility" -- then that design goal needs to be implemented by default. That doesn't mean you can't include the less-accessible modes as a toggle option, but it does mean that (for example) the default mode should be graphics, not ASCII.

The reason focusing on mods (and, yes, utilities) as an idea source is simple -- if someone has written a utility or mod to fix a perceived issue, that indicates they saw it as a problem that needed fixing. If the utility is popular, that means a lot of people agreed with them. All those third-party man-hours invested into improving the game are a resource. Use that resource.

[Shonai_Dweller]

God I hope Dwarf Therapist never becomes the default interface for the game. I completely agree with Toady on his dislike for a game about micromanaging every single dwarf in a spreadsheet.

I mean, yeah, it's popular enough to include as an option deeply buried in an advanced tools window somewhere, but as default, you've just killed the game.

Therapist as an alternative to the current system seems nice, because the current system is so poor, but it's really not the only option. And, "fans like it, therefore Toady must make the game according to their whims" has never been the way Dwarf Fortress had been developed. We celebrate it because it's an independent project, not because it's yet another game-by-committee developed by some massive studio.

[muldrake]

Mod support is great but if you want the game to be accessible to new players -- specifically popular Steam audience players -- you need to make things like Dwarf Therapist the default option when a new player boots up the game for the first time.  Said another way, if the Steam version is adding an additional design goal -- "accessibility" -- then that design goal needs to be implemented by default. That doesn't mean you can't include the less-accessible modes as a toggle option, but it does mean that (for example) the default mode should be graphics, not ASCII.

The thing about DT specifically is I see noobs being immediately intimidated instead of assisted by being faced with a complicated spreadsheet-like app when starting the game.  And the in-game version is even more intimidating.  I think things like the dfhack plugins autolabor and labormanager, by handling some of these tasks automagically rather than requiring something that looks like office work, would probably be more helpful.

Even these aren't perfect, because while autolabor/labormanager both do some things well, they do other things poorly, and if you don't already have experience with something like DT you don't know how to go into micromanaging it.

So while I think most players who stick with it ultimately will, at least at times, want something like Dwarf Therapist, just seeing it at the outset is scary.  (From what I've seen on the Steam announcements the UI is definitely increasing in clarity though which might seriously reduce some of these problems.)

[George_Chickens]

God I hope Dwarf Therapist never becomes the default interface for the game. I completely agree with Toady on his dislike for a game about micromanaging every single dwarf in a spreadsheet.

I mean, yeah, it's popular enough to include as an option deeply buried in an advanced tools window somewhere, but as default, you've just killed the game.

Therapist as an alternative to the current system seems nice, because the current system is so poor, but it's really not the only option. And, "fans like it, therefore Toady must make the game according to their whims" has never been the way Dwarf Fortress had been developed. We celebrate it because it's an independent project, not because it's yet another game-by-committee developed by some massive studio.

For the most part, I find DT to actually add to the time it takes to complete tasks. I prefer just to burrow all migrants and manually check their skills. If Dwarf Fortress, by default, allowed you to bring up a list of most suitable dorfs for a task, like a list of mechanics for when you want to make mechanisms or a list of axe wielders when you have an open position in the militia, I don't think I'd use it at all.

[Starver]

I imagine that with (certain) materials lists having "sort by distance/sort by value" option, and rolling that philosophy out across practically every list you can think of with an intelligent (not ridiculously exhaustive) set of sorting options, that would get around the need for inbuilt-DT.

So for workshop-assignment you could have (as well as default migration-order dwarf ordering/alphabetical-for-easier-finding[1]) current skill level[2], job burden[3], age/strength/some-other-analogue-of-general-fitness[4].

Plus togglable-tickbox column as to whether this dwarf has this job in her list of jobtypes, to be used both as an indicator and as a setter. Access to this in "by jobtype per each possible dwarf" as well as "by dwarf per each possible jobtype" is probably the most immediately useful DT/etc feature missing from Vanilla. At the very least it shows you that you're reserving this workshop for use by someone who isn't currently inclined to use it. The ability to change this fact, in either direction, in situ is an optional bonus that you may not even want to take advantage of at this time. (So don't force it, just make it obvious when it mismatches.)

So, don't go overboard (happiness/consoler-skill/number-of-pets), but be intelligent about it. Room-assignment currently highlights "already has a room of this type" (could be extended to "has <n> rooms of this type", perhaps most useful for those with transient noble-assignations alongside 'original' ones, if only to see where you can free up the civvie quarters for their term in office) and an indicator/sorter of being in a marriage partnership might be useful (assigning one partner 'solves' the needs of both - dependent children are another linked case) amongst other things.

Well, just a thought (or two).


I am a great fan of DT (beforehand using actual spreadsheets to do what DT does, but less efficiently) and use DFHack-based stuff so rarely that I'm not really knowledgable about that class of helpers. But I wouldn't think importing DT directly into Steam-era-Vanilla is the solution. I could work with it (if Clément could), but it isn't the "make everything instantly obvious" utility for everyone. Maybe the alternate brands of workflow tool are, and I've been missing out myself by not trying them, but I'll guess equally (for different reasons) that they are not.



[1] Urist 'nickname' McThingy vs. Odol 'namenick' McWotsit would be decided on U<=>O? McT<=>McW? Even ni<=>na? There'd be good reasons for two of them (pick whether first or last names, both being random anyway, are the best 'inbuilt' alpabetical key.... I'd lean to the first, as you almost might as well choose the second 'surname' dictionary component as much as the first.

[2] Might go too far to have 'aptitude', something that Clément-and-co has worked out emperically/etc. Leave that to an advanced 'helper' plugin like now.

[3] Could be 'tracked recent rate of idleness' or 'number of other current potential work-locations(/work-location-types) already available for'. Again, needs thought as to what sorting value should be enumerated, and providing every permutation isn't going to unconfuse everybody. And don't forget about skill-range-permissiveness being an important 'why aren't they doing a job I told them they can do?' answer that can be dynamically conveyed in/alongside this area of informatics.

[4] And not just for picking the most suitable for this job, but maybe for picking at the opposite end from those most suitable for a different job - i.e. leave the strongest to be your haulers and/or military, so choose your crafter from the weaker end of the scale (arranging his hauling-to-workshop to be minimal) to avoid shuffling later.

[Urist McBlind]

Work assignment is probably the most important thing to fix for new players. It's a core mechanic but convoluted, time consuming, and tedious, and a beginner will be lucky to find where to do it at all without a wiki. You check what a dwarf is capable of in a different submenu than where you select the work, personality facets you might want to consider are somewhere else entirely, andthe work assignment menu itself is unwieldy and poorly subdivided.

For the most part, I find DT to actually add to the time it takes to complete tasks.

I literally cannot imagine how this could be true, compared to your method, but kudos for doing it anyway; I think the most important flaw DT has is removing you from that personal connection with the dwarves you really need for the stories the game generates to hit home. Even as a fan of its functionality I would agree there are almost certainly solutions which stay more true to the game's core while being less intimidating and decently efficient.

Perhaps something closer to the adventurer creation screen, with the dwarf's (sortable) skills/characteristics to the left, his assigned skills next to that and some fortress metrics like number of eg smiths etc. to inform the decisions.

[muldrake]

Work assignment is probably the most important thing to fix for new players. It's a core mechanic but convoluted, time consuming, and tedious, and a beginner will be lucky to find where to do it at all without a wiki. You check what a dwarf is capable of in a different submenu than where you select the work, personality facets you might want to consider are somewhere else entirely, andthe work assignment menu itself is unwieldy and poorly subdivided.

Tooltips that pop up (in some kind of tutorial mode you can disable) when you assign a task and no dwarves have that task enabled might be nice.  Something like Clippy.  "You just tried to build a workshop but no dwarves have X enabled.  Do you want to turn that on now?"  And then take the player to the menu where you do that.

Combining this with some kind of labormanager-like default mode that has some baseline sanity settings that should be good for a starter fort would also be good.  Some changes in the defaults might be nice too.  I think I could really live without that "automatically have dwarves go into the caverns the instant they're open and start messing around with giant cave spider webs" thing.

[Putnam]

Work assignment is probably the most important thing to fix for new players. It's a core mechanic but convoluted, time consuming, and tedious, and a beginner will be lucky to find where to do it at all without a wiki. You check what a dwarf is capable of in a different submenu than where you select the work, personality facets you might want to consider are somewhere else entirely, andthe work assignment menu itself is unwieldy and poorly subdivided.

To be frank, I think the most important thing to aid in accessibility is to tell new players that you don't have to care and that most veteran players are just super wrong about how optimal you need to be.

If you're checking personality traits for labor assignment, then you're microoptimizing way too hard. It's not going to improve any facet of your fortress in any respect, excepting the obvious, like making easily-stressed and violent-averse dwarves not haul corpses.

[Urist McBlind]

Yes, checking personality traits and stuff is overoptimizing, so that could probably be left out, my point was more that its super annoying to use regardless of what you want to do. And telling people not to care is pretty pointless, since a noob isn't actually going to know about it. If you meant not care about labour management in general, I can't agree with that, since DF is a management game at its core, even if it allows you to focus on other stuff, and new players in particular need to be able to effectively manage assigned labours so they can get in the groove of actually playing instead of getting frustrated nothing is getting done.

I argue for stuff like the inclusion of a personality/physical ability summary on the labour screen because that sort of thing helps you remember particular dwarves better, which I think is important to help new players get into the right mindset for enjoying the microstories the game generates. In my experience people get interested in DF because they read about some amazing thing that happens in the game, but get frustrated when they can't see anything like that happen in their own play; it takes some experience to actually be able to follow them and investment in individual dwarves helps.

[NEANDERTHAL]

There should definitely be a more centralized way to view the very complicated details of each dwarf. I imagine putting everything currently on the v(?)-screen(pets, labor, health, inventory), ownership/details screen, relationships screen, and personality screen on one screen all at once, or in the interests of screen real estate putting passages to all these screens on the personality screen (and having passages back!)
The more keypresses and screens the player has to go thru, the harder it is to remember all the relevant info about a dwarf when taking the long trip between info screens.

[Thorfinn]

1. Complex is not the same as complicated. The puzzle should be figuring out what is wrong, not how to get the information about what's wrong, nor how to tell the game what you want to try to resolve it.

2. Something like Clippy is a great suggestion. A newb I helped on my LAN went home, downloaded the game, and got the exact same alligator combat someone talked about earlier. Completely ruined it for him when he couldn't get them to disengage. He complained that so far as he could tell, they'd keep pummeling the alligator until they all starved to death, and rage-quit. At least give some way to walk a complete newb through the menus to allow him to pick up a pointed stick, and when he's ready for it, how to replace that with a real weapon, and how to add armor. 'Course, that wouldn't have helped in this case. I've tried it, and I couldn't figure out how to get them to disengage if I hadn't established at least one person with a weapon ahead of time.

3. Unify zones, for pete's sake. No it's not game breaking, but you need to know that if you want to pasture animals, you use"i", to establish safe areas, you use "w", if you want to store things, you need "p". These are all just regions. Just adding "st(o)ckpile" or "st(o)rage" or something similar to the options on the zone, that enables "O" (capital ''o") to jump to the stockpile settings, exactly like designating it a (p)asture enables "P" and lets you specify which things to pasture, and Bob's your uncle. I'd think even things like fa(r)m plots should be done with whatever you are using for establishing zones. Warrens might have to be something different, since you can specify them across multiple zs, and before excavation. I do understand, however, that those of us who have played for a while are pretty set in our ways, and could never accept the newfangled way of making a food stockpile, now similar to every other zone you would make, "i-enter-arrow-arrow-enter-o-O-f", so you couldn't actually get rid of "p-f-enter-arrow-arrow-enter-ESC-q", but there's no reason newbs should be required to remember three different ways of doing pretty much the exact same operation, and when you use each.

4. More of a suggestion, but among people I've introduced to the game, pretty much everyone is puzzled by the fact that you need a pick to dig through sand. Maybe if those top few dirt layers were diggable without a tool?

5. Context-sensitive loo(k). And merged with whatever(t)is and (q)uery as much as feasible, as suggested earlier. If you are loo(k)ing at a tile, and currently highlighting larch trunk, it would be nice and newb friendly to be able to hit "t" right there to designate it for chopping. If a fisherberry, you can gather (p)lant it. If you are on grass or pebbles or whatever, you can c(h)annel, d(j)ownstair, bCw, bwc, whatever, right there. Maybe only the really common stuff. Ideally, one should want to learn how to do it with keyboard commands because it's heaps faster, so if you were highlighting said fisherberry, it would display something like "gather plant (dp)" so you see the key command every time you use (k).

[EDIT]
Oh, I forgot.

I don't think the problem with weres is that they are necessarily too early, but rather that there are lots of embarks where there's been nothing else to fight, so not only are you thrust into trying to figure out the (IMO) overly complicated military menus, the penalty for getting it wrong is quite severe. And your next embark, your next chance to see what the orders do, it's also going to be against a were.

Like @Shonai_Dweller and others have said, people expect the game to have at least a little combat. Otherwise, why bother with so much detail in the squads, armor and weaponry? It's just pointless complication. There needs to be some early game battles of some sort so the first exposure to it isn't complete and total annhilation.

And personally, I don't think one should expect Wiki or the forums to do the heavy lifting. Most of my play isn't even connected to the internet, so it's not an option anyway. But even if it were, Alt-Tab all the time is hugely distracting from playing the game. Getting through heavy aquifers and moving magma about, sure. Getting through a battle or figuring out how to dig a hole or chop a tree or not cook all your seeds, not so much.

[EDIT2]
Oh, and riffing off something @PatrickLundell said, dump IS too useful to waste on garbage. How about adding different types of dump zones? Heck, even d1, d2, etc. would be awesome, even if there were only a few possible options. Never mind. That's more of a wish than something to make life easier for newbs.

[Starver]

On the unification of zones, I don't think it's fair to mash everything into a single replacement.

Given that pastures are already grouped with water-sources, etc (not mutually exclusive) you'd have to consider a simple area originally designed as a wide-ranging burrow being (all too easily) reconfigured into a refuse zone and/or truly weird megastockpile. And when rooms become "areas defined by their furniture", as long promised, that'd be anothe confusion.

Yes, it would be player-error (and I can think of edge-cases where it might be useful), but I think that a combination of splitting 'Zones' and cross-merging some of the other things (perhaps also traffic priority painting?) into the more properly thought-out separate sets would be the way to go. With more thought applied to this than I can currently muster (beyond knowing what feels wrong).

[Thorfinn]

Fair enough. Burrows are sufficiently different, and you frequently WANT them to be odd-shaped to skip caverns and magma and whatnot. And if the hypotheses about how stockpiles work internally is correct, large stockpiles may turn into a major source of FPS death, depending. If correct, a single max sized pile would be nearly 1000 individual job spawners. One would definitely not want to have a fort-wide mega-stockpile with potentially millions of job spawners.

There may be a good reason why farm plots (for example) could not be created in the same way you create a fishing zone. It may not be coded in such a way that it lends itself to zones. Rather than growth being tied to each individual tile, like it presumably is for plants, and to a multi-z structure tied to one trunk of however many tiles, like it presumably is for trees, maybe it's tied to each cell in a variable-sized building, or simply to the building itself. That might entail a lot of code change, which would be a bad thing, particularly if the farming is all going to be redone in the future anyway. My sneaking suspicion is it's coded the same way, or there would be extra coding to deal with the odd shapes you get when there are non-farmable tiles in the plot.

I'm not saying its one way or another. Just that to a newb, it would be easier to have a single method that defines regions, rather than  bp[umkh], i[select corners], p[select corners], b-b-enter-q-r-[+/-]-d, etc., and remembering when to use which. Defining regions is not complex, it's just complicated.

On the other hand, the clock is running. Whether or not it would make things easier on newbs, what exists has scads of hours of playtest and bugfinding.