Print

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

[Vattic]

Even if he didn't mind working with other programmers I doubt he'd include the custom job management screen you mention.

Generally, we'd prefer to stay away from spreadsheets or a numbers-oriented priotization for specific labors on the labor list. We'd rather see the labor list removed entirely in many circumstances, depending on fortress citizen status, but that'll have to wait until starting scenarios are completed.

Isn't that like saying "I'd prefer to stay away from an Interface that works"?  Because it's not something about presentation, it's about how the game was built in the first place that requires specific types of data to be in the game in the first place. 

Toady built a game where you need to be able to compare dwarves to see which one is best suited for a task, or where, when a job isn't being done, you need to see how many dwarves are assigned to that task, who is available to be shifted over to that task, and what consequences there would be for assigning those labors to them.

He built a spreadsheet-based labor screen by building a game that requires a spreadsheet-based labor screen to actually manage.  And if he doesn't like that, well, HE'S BUILT THE WRONG GAME, THEN.  This is a simple failure to think the consequences of his design through, and it shows through every fracture in this broken and failed interface of his.

While I have no issue with spreadsheets either I have to disagree that it's required as I've heard plenty of people saying they use the DFHack autolabour plugin happily. Once you have a lot of dwarves it would make some sense to have the player define broad strokes/policies and have the game figure out which specific dwarves should be doing what (doesn't Dwarf Therapist suggest jobs based on personality now?).

Similar could work for ranching where you'd define the broad idea of what kind of traits you want selected for and then the dwarves manage it and report back every so often instead of forcing you to micromanage it.

Have to say I'd be disappointed if the only interface available was isometric like Gnomoria; I found having tiles invisible to the player and the underground caverns to be confusing because of Escher like depth illusions (there has been talk of this difficulty in the Stonesense thread too). While the UI is much better designed in general I found some aspects fiddly, especially navigating the nested menus by mouse (why I've argued for keeping keyboard shortcuts even if they need to be more regular and logical).

You can use a button to make walls shorter in Gnomoria, which is a help.  You can also try to set the "slice" of the world down to just 1, which also stops depth illusions.  (I also find need of this with TWBT...)

And yes, you can use keyboard shortcuts in Gnomoria, as well, which I do with a custom key layout so that U is a ramp up, J is a ramp down, I is stairs up, K is stairs down, L is build floor, O is build wall, : is replace floor, P is replace wall, etc. etc.  I don't use the number buttons in Gnomoria at all except to use delete, which is just plain 5.

But yes, that scheme works specifically because I made it, and I made it all at once, so it follows a specific logic pattern, and I know what it does.

Even with all the mitigating features you mention I still find isometric less immediately understandable than a top-down view. If you are having problems with figuring out layers in TWBT I suggest you tweak the transparency of the shadows and similar. Gemset also makes it lighter with depth instead of darker which I find much clearer.

Back when I first played it there were no keyboard shortcuts for building and the like, but I have played since and found them useful. There wasn't even the number thing you mention.

[NW_Kohaku]

There's quite a bit of hyperbole being thrown around, I'd just like to remind you that Dwarf Fortress is currently in development and certain things (like 6 ft eyelashes and suicidal birds) are to be expected. Could you explain to me how the bugs in DF are indicative of outright incompetence? You portray Toady as being unable to "think anything through" and reliant on circular reasoning, despite failing to understand his focus or vision. Getting so very frustrated at things that are bound to change isn't very productive, and I will reiterate that Vanilla DF is playable, and to me it is as playable as I'd expect from a game at it's stage of production.

I'd already said it was an exclamation of frustration, so yes, some hyperbole, but anyway...

As already stated multiple times, saying something is "just an alpha" is no excuse for Dwarf Fortress.  The problem is that these are bugs that are not being found or corrected because the tools to find them are not being built.  That isn't a random, expectable, careless mistake, especially not when it happens consistently for years in spite of people arguing that more care should be taken towards them. 

It's a flawed coding methodology.  It's a persistent bad habit where not only is it not being actively corrected, but any time the habit is mentioned, the ones who mention it are always attacked with the same lines about how it's wrong to even question the habit.

It's a simple train of thought to follow where making nest boxes for chickens required for maintaining a breeding stock will lead.  Nest boxes were literally built for collecting eggs, and there's a flaw in their basic, primary purpose that you don't see?  Not a bug, but a failure of design, as there is no way to designate eggs should not be harvested without unnecessarily elaborate designs of burrows or mechanisms and drawbridges to keep dwarves from harvesting fertile eggs. 

The failure to understand the vision here is the failure to follow the consequence of mechanics to how they force players to react to what interface will be required for them to make that reaction with a proper degree of information. 

What is your defense of that based upon, other than blind, unthinking loyalty and hatred of any form of criticism? 

And no, it's not bound to change.  Maybe the specific pieces of code change, but it's clear the methodology never has, and as long as the loyal dogs chase off any that would criticize their master, it never will.  As long as the flaw in methodology persists, the consequences of that flaw will continue to manifest through every update in this game.  Again, as the people who started this thread stated, every time you build on top of a bug, the harder it becomes to trace that bug and eliminate it.  If the mistakes in methodology that let the bug slip through keeps being repeated, then more and more bugs slip through. 

[NW_Kohaku]

While I have no issue with spreadsheets either I have to disagree that it's required as I've heard plenty of people saying they use the DFHack autolabour plugin happily. Once you have a lot of dwarves it would make some sense to have the player define broad strokes/policies and have the game figure out which specific dwarves should be doing what (doesn't Dwarf Therapist suggest jobs based on personality now?).

Similar could work for ranching where you'd define the broad idea of what kind of traits you want selected for and then the dwarves manage it and report back every so often instead of forcing you to micromanage it.

Well, what you're talking about here is automation. 

That is potentially a much better solution than just handing the player the information they need and telling them to still manually sort things out, themselves, but it may also be problematic.  After all, the player may not always want to rely upon whatever the script automatically gives them for one esoteric reason or another. 

Automation also really requires it be an optimization problem to start with.  That is, there is one unambiguous, mathematically provable BEST way to divide your labor.  There are so many factors whose relative importance are not strictly mathmatically knowable in DF that such a concept would be difficult to determine.  For example, I care what my metalsmith's personality is, because that job's quality results really seriously matter.  I don't give a crap how suited my threshers are to threshing.  However, different players may care more about carpentery quality than masonry quality, and most "craft" jobs use the same attributes and personality traits, so you're basically asking a player to choose between various dwarves with various potentials being assigned to various crafts when everything has an opportunity cost, but that cost is difficult to weigh.  (If a dwarf would make five times better a mason than a metalsmith, but they're still a better metalsmith candidate than any other dwarf you have available, which do you assign that dwarf to? How much is the marginal cost between that dwarf and the next dwarf down the line?)

This gets worse when you talk about mods.  If a mod has different jobs with different values, how do you make the game recognize this in which dwarves are selected for what jobs?

And Dwarf Therapist isn't that helpful in that regard.  It can allow sorting based upon attribute and preferences, but you need to manually set the weights to make it work properly, and it's still difficult to really weigh opportunity cost of putting someone who's a 52% match instead of a 53% match to make that 53% person into a different job they 60% match...

The thing is, again, when you automate this, and make the dwarf with the biggest match percentage just automatically take that job, there may be a whole host of other things you may prefer they do. 

Autolabor works if you play the game the way that autolabor requires you play. 

Would it be possible to create a flag in Autolabor to set a certain type of labor as 'dedicated'? Like say, set "autolabor HAUL_STONE 2 4 d", where D disables all other labors in the dwarves it selects, leaving them as only stone haulers?

A generalized "HAUL" labor would also be useful, and would act as a macro that sets all of the Hauling labors to the set values.

I'd make this but sadly I have zero programming skill.

I don't know why anyone would use autolabor anymore as it does not assign skills optimally and anyone who ever had diplomat responsibility has their labors auto-stripped, including former mayors and expedition leaders. If you have to use autolabor, then your only option there would be to assign them the stone hauling labor only in something like Therapist then put them in a burrow so autolabor will ignore their labor assignments.
But autohauler is designed so you get a lot more control. All you'd have to do then is set the dwarf's stone hauling labor as the only one active then set a labor with the forbid flag so hauling assignments are not changed, by default Alchemist is one. For either program though you'll have a problem with hauling jobs accumulating, so make sure that at least 5% of non-military are idlers.

Autolabor seems to be fairly blind in how it works, and works more by just randomly grabbing dwarves to make them do jobs as you need them, not as you would want them to eventually be worked up into becoming.  That is, it works if you are focused upon the short term, not the long term, and would probably work best if you have a smaller fort, where you don't want dedicated dwarves doing only one task, anyway. 

(But then again, I never really sat down and tried to work it out, and maybe it's been changed since then...)

Likewise, the current method of dealing with vanilla is to just set labors as you need them, and eventually move towards a system of one-labor-per-dwarf that only a larger fortress can really afford.  The lack of efficiency is generally compensated for with raw productivity.  However, it means you have little real capability to retrain dwarves or make up for losses by any means other than taking untrained peasants and assigning them to fill the holes. 

Many manager games just plain don't have traits or potential just to sidestep all these issues to begin with.  As it stands, some form of automation (dwarves pick their own labors) is necessary, but you still need to have some method of control as a player, to stop everyone from being a friggin' fisherdwarf in the desert, and nobody being a mason. 

But basically speaking, yes, you can move away from spreadsheets, and use automation, but the problem is, it needs to both be very sophisticated as a script, (and it WILL be problematic,) and it needs the general mechanics of the game to be custom-fit to the automation that will operate it.  And making the mechanics to fit the interface is the problem I'm flogging well past death.

[bcmpinc]

But no, it's not urgent. DFhack should be sufficient until we're nearer to v1.0. I'd much prefer Toady continue to focus on the major game arcs instead.

I see that argument popping up quite often, however the problem I have with it is masterfully expressed by Toady's quote:

We’ve been working on it for 13 years now, we’re 40% through with the goal list as of this latest release. 20 years still seems like a fair figure for 1.0. But, you’ve got the whole 90/10 rule, right? So maybe we should be saying 200 years instead… that’s probably to get it out of alpha. The last little push there for the 180 years of interface and graphics design for it or whatever. We’ll have some sort of technological singularity to help us out by then I suppose…

If Toady keeps refusing help from other people and postpones the interface rewrite and bug fixing till after ~v0.90, then yes, his 200 year estimate might not be that far off. I do agree that it is not urgent though:

It was urgent when users thought it worth the effort to write dfhack and Dwarf therapist. Now, we're way past urgent.

Another frequently stated argument says that the interface is fine as the game is currently playable. Yes the game is playable, but barely. Despite DF surpassing minecraft a few orders of magnitude in complexity, I can still squeeze more hours of gameplay out of minecraft, than I can with DF. The reason for this is that most of the complexity is invisible to the player (such as animals with commitment issues, growing eyelashes, etc.), barely visible (dwarf preferences, personality and mood), too much micromanagement (jobs and military), too bugged (bins/barrels), etc. And as a bonus, this complexity remains largely untested.

Making it open source does not solve the problem, and telling people to fix it themselves is not a solution because only a small subset of players have the necessary skill to both program and know the game and user interface design well enough to design a good interface.

Indeed, however, that small subset of players will solve the problem. I do understand though that making DF open-source is a giant leap, with risks that Toady is not willing to take. Though, he could take smaller steps instead. He could, for example, start with:

• move the image export functionality into the the graphics library (afaik the only part of DF that still uses the SDL API directly);
• link the graphics library dynamically on windows and mac (now it only does that for linux);
• make the graphics library open source (it isn't as the linux build lacks the build scripts necessary to recreate libgraphics.so);
• attach an open source license to the graphics library (preferably LGPL).

[lethosor]

Lacking build scripts doesn't make something non-open-source. Aside from that, there is a build script, as well as a fork that can be built with CMake.
I do agree that making libgraphics dynamically-linked would be useful, though.

[bcmpinc]

there is a build script, as well as a fork that can be built with CMake.

I did know about the first one, though the build script is rather messy (as is the repository it is in) and I could not get it working. Thanks for the second one. I have not yet been able to compile it (I'm on a 64-bit machine), though I'm hopeful. Maybe if I'm bored I'll try porting it to SDL2.0, add ttf support to the opengl mode, or something.

Edit: I finally managed to build libgraphics.so on my 64-bit machine. Unfortunately I hit two errors: the error_log variables' decorations don't match; the enabler structs differ. This is probably caused by a difference in the used STL implementation.

[quekwoambojish]

It's weird how people don't think changing the UI isn't an urgent matter in my opinion.

1. New players have an unfairly hard time with it, and won't stop bugging me about where this and that is when I try playing with them.

2. It really is slow getting around many of the menus, a good amount of the time you have to do this cumbersome 1 row at a time way of scrolling. When you finally manage to scroll down the page, you can't see the other page you just scrolled down from.

3. EVERYTHING militia oriented is absolutely horrifying to navigate. Uniforms, scheduling, and barracks designations etc are extremely non-intuitive with the current UI.

4. Buildings are a pain in the butt to find, and 1/2 the time new players build the wrong thing thinking it's something else. I have had at least 4 instances where players didn't build anything useful because they don't know that most of the useful things are considered workshops.

5. It would be very nice to have a toggle display of particular resources. I forget to look at that stuff quite frequently.

6. Our community is FANTASTIC, and we should take advantage of that by giving these people something else to improve on. I have a few friends who wouldn't have been able to play DF if something as simple as a tile pack wasn't created by the community, and now they've been playing for 2+ years. It would have really been a shame if that option wasn't there for them.

[shadowclasper]

As already stated multiple times, saying something is "just an alpha" is no excuse for Dwarf Fortress.  The problem is that these are bugs that are not being found or corrected because the tools to find them are not being built.  That isn't a random, expectable, careless mistake, especially not when it happens consistently for years in spite of people arguing that more care should be taken towards them. 

It's a flawed coding methodology.  It's a persistent bad habit where not only is it not being actively corrected, but any time the habit is mentioned, the ones who mention it are always attacked with the same lines about how it's wrong to even question the habit.

I don't know why this is having to be said over and over or why people are persistently ignoring it when it's stated, or even outright dismissing it.

An alpha's purpose is to make the game actually playable. A game that is in alpha needs to have information very publically displayed or at least have some tool for monitoring hidden information at all levels, otherwise you can't correct problems because while things don't act the way you want them too, they might do so in such subtle ways that you never figure out WHY they are going wrong.

And it all plays back into the interface again and again and again. If the game requires a third party utility to be playable, it is not a proper game, any AAA game, hell, any INDIE game that attempted to do so would be laughed out of the marketplace. DF holds a special place through sheer momentum but it is -dieing-. It is no longer the only game on the block. It is only a matter of time that people will create 'close enough' similarities that are better designed and more usable if Toady doesn't get ahead of the game -now-. Then it won't matter if DF is, actually, the best and most complete fantasy world simulator, nobody will care, because they will be getting a 'close enough' experience to that.

edit: Don't believe me? Nobody believed there'd be something like Gnomoria or Towns or the other 'close enough' DF-like games. Anybody want to take bets on how much of the DF-itch clockwork empires is going to scratch for a lot of people?

AND THOSE ARE MADE BY GODDAMN INDEPENDENT COMPANIES. THEY ARE MADE BY INDIES.

Wait for it. Just wait. Eventually, we are going to have sufficient tech and prebuilt and publically available scripts that it won't be unprofitable for a AAA company to make something like this and make it WELL and QUICKLY. This has to be dealt with ASAP or DF will die under it's own weight.

[Dyret]

Towns

lol

[Vattic]

edit: Don't believe me? Nobody believed there'd be something like Gnomoria or Towns or the other 'close enough' DF-like games.

The core mechanics shared between DF, Gnomoria, and Towns were not new when DF first released. It was similarities to old classic settlement management games like Dungeon Keeper and Cultures, rather than roguelikes, which attracted me (autonomous units, base building, production line management). I find it hard to believe anyone would think those mechanics were never going to appear in another game. The other mechanics which DF is noted for are much rarer even in games directly inspired by DF. I know of few other projects with such detailed procedural world building for example (Ultima Ratio Regum being notable).

Still I share your concern, though not as extreme by the sounds of it, and would be sad if DF ended up neglected in favour of similar but more accessible projects (I like Toady and Threetoe's own brand of crazy). Toady has mentioned his own concern over a AAA studio using their deep pockets to out compete him (can't find the quote, but I think it was in a DF Talk episode). Personally I'd be happy with some of the previously suggested simple UI changes and key choice made more unified.

[shadowclasper]

Still I share your concern, though not as extreme by the sounds of it, and would be sad if DF ended up neglected in favour of similar but more accessible projects (I like Toady and Threetoe's own brand of crazy). Toady has mentioned his own concern over a AAA studio using their deep pockets to out compete him (can't find the quote, but I think it was in a DF Talk episode). Personally I'd be happy with some of the previously suggested simple UI changes and key choice made more unified.

I might be using slight hyperbole, and I don't think this is going to happen in the time frame of even 5 years, but that timeframe is miniscule in terms of DF's projected production lifetime. Which is minimum 20 years.

I think in -that- time frame, it IS a serious threat. This isn't going to happen tomorrow, but it will almost certainly happen within the development time frame Toady has given in his most optimistic estimates, never mind the far more likely estimates of 30-50 years at the current rate.

Also I honestly think the only thing necessary to do would be to make the simple UI changes and the key choices made more unified, at least in the short term, but the game really does need to have more accessible means of getting data without memory hacking both for bug fixes and for creating a proper UI.

[BasKing]

This game needs an interface overhaul really bad.
I love the game. But I get angry at the interface all the time.
It is just not consistent. It all looks very 'ad-hoc'.

• One big example is using updown(leftright). It should always be possible to (also) use the cursorkeys for these. But sometimes it is umhk, sometimes it is +-, sometimes 8246.
• Examine the 'give professions to dwarfs' screen while preparing to embark. Why use white and nearlywhite. It is almost impossible to see what dwarf is selected, and no indicator is showing if pressing 'up' will 'up' the list of dwarfs, or the list of professions: you just 'have to try and find out' if you are working on the left or right list? Not user friendly at all.
• Esc is sometimes used as enter. Why. Use enter as enter.
• Sometimes it is use right/left cusor to toggles things, sometimes it is 'press enter to toggle things in a list'. Be consistent.
• Menu options should be clickable. Why not create buttons with the menu texts on them, so users can both use the keyshortcuts, as well as click the buttons. Many people (90+ percent?) prefer the mouse to interface, and hate using keys (as they cant type really well).
• Areas use different ways to select them. Setting areas in Zones has a different workflow compared to setting them for stockpile area. These should be consistent. It is confusing now.
• Most people use the mouse to select areas. Why not let users click the mouse to indicate corners of area's, most will thank you on their knees for it. I will.
• Lists are listed by keyshortcut, but it should be by name. When looking up an item in a list the flow is 'now what key do I use to make xx' not 'now what can I make with key yy'
• when you know the user has to wait several or more seconds: blank the screen and display a 'plz wait' message. Now, when you press e to embark, you dont know what is happening for dozens of seconds: Is it working? Did you press e hard enough? Should you press it again?
• When I press the little X in the upper right hand corner of the screen: the program should stop (almost) instantanously. I have seen a guy get physically angry by DF not closing when he pressed x. Just show a 'plz wait' screen, do all saving and stuff: and kill the program. No more 'lets have the user jump to hoops when he/she tries to stop the program'.
• make the tileset easy to swap. The old school 'all ascii' default tileset is.. well.. very very 'oldschool'. Perhaps it is part of the attraction to this game (as only die-hard lovers of the genre will tolerate it), but I know many, many prospect gamers will just instantly dump the game as soon as they see the ascii-art-interface. I know there are tilesets out there, but they should be integral to the game: 'make new tileset''give name'(change tiles)'upload to website''download from website'(with some quality indicator like number of downloads or some score, and example of the art). Yes, it is a lot of 'extra work', but it will make the game much more approachable for a wider audience (the ones that dont know how to install 7zip, download a file, and guess where and how it should be extracted to make things work). Most users will download the game, start it, see the ascii, and dump it.

Don't get me wrong: the game is great, I play it for hours on a row. Just some feedback on the things that annoy new users like me.

[Salmeuk]

I think a lot of people here would quickly jump ship to a AAA-quality game that emulated some of the complexity of Dwarf Fortress. Some might never look back. Imagine Blizzard, with their magic money-making fingers, sitting down to create a zerg-fortress or some corny thing.

Personally, I don't think the sort of game Toady is trying to make will ever be judged as a sound investment by the sorts of people who run those AAA companies. Independent devs, perhaps, would be willing to try. This sort of game has a heritage, and has always attracted a small crowd of gamers. Comparisons to Gnomoria and Towns (lol) aren't very relevant because those games had none of the charm or depth that makes DF what it is, and while they emulate some of the complexity they miss out on the important bits. That's my opinion but it would be tough to argue otherwise.

My point is that no matter what threat's to DF's future you guys conjure up we can't really guarantee any of them happening anytime soon, so what's another few years of using a (don't skewer me for this opinion) perfectly-manageable interface while the game grows in depth? You underestimate this community, which while it isn't exactly growing in size it has developed an amazing potential for gaining new members. Old ones filter out, become bored with the game and go silent. New faces appear, fresh and overly-enthusiastic and ready to pick up where the others left off.


If you find yourself really hating the interface, take a break! Just put the game down for a few years. You'll find that there isn't anywhere else on the planet to experience a dwarf fortress, and either you will accept this fact and move on with your life or return to find the game as you left it: a beautiful, incoherent and utterly challenging system of childhood fantasy-simulation. If you're playing Dwarf Fortress just to play the game, you're doing it wrong.

[lethosor]

This game needs an interface overhaul really bad.
I love the game. But I get angry at the interface all the time.
It is just not consistent. It all looks very 'ad-hoc'.

• One big example is using updown(leftright). It should always be possible to (also) use the cursorkeys for these. But sometimes it is umhk, sometimes it is +-, sometimes 8246.

8246 should be equivalent to the cursor keys, but DF displays the shortest keys. + and - are used fairly consistently where the arrow keys can be used to move around the map at the same time (the hospital menu is the only exception I know of). umkh are used to resize things where the arrow keys wouldn't make sense (does the "up" arrow increase the size of a building from the top or decrease it from the bottom?), although mouse support there would probably be better.

• Examine the 'give professions to dwarfs' screen while preparing to embark. Why use white and nearlywhite. It is almost impossible to see what dwarf is selected, and no indicator is showing if pressing 'up' will 'up' the list of dwarfs, or the list of professions: you just 'have to try and find out' if you are working on the left or right list? Not user friendly at all.

They're pretty easy to distinguish for me, but you could try modifying your color scheme. I believe that only the selected row in the active column is white, which should tell you which column you're working in.

• Esc is sometimes used as enter. Why. Use enter as enter.

Where?

• Sometimes it is use right/left cusor to toggles things, sometimes it is 'press enter to toggle things in a list'. Be consistent.

I'm not aware of any screens that only support the mouse, and only a few have actual mouse support.

• Menu options should be clickable. Why not create buttons with the menu texts on them, so users can both use the keyshortcuts, as well as click the buttons. Many people (90+ percent?) prefer the mouse to interface, and hate using keys (as they cant type really well).

I'm fine with mouse support, but I'm skeptical of that claim - sure, a lot of new players may not be used to using the keyboard as much, but a lot of experienced players think it's faster.

• Areas use different ways to select them. Setting areas in Zones has a different workflow compared to setting them for stockpile area. These should be consistent. It is confusing now.
• Most people use the mouse to select areas. Why not let users click the mouse to indicate corners of area's, most will thank you on their knees for it. I will.

Agreed

• Lists are listed by keyshortcut, but it should be by name. When looking up an item in a list the flow is 'now what key do I use to make xx' not 'now what can I make with key yy'

Are there specific lists like this? If you're talking about the 'b' menu, I believe those are ordered by internal building type IDs, which happen to be in the same order as the hotkeys for many (but not all) entries.

• when you know the user has to wait several or more seconds: blank the screen and display a 'plz wait' message. Now, when you press e to embark, you dont know what is happening for dozens of seconds: Is it working? Did you press e hard enough? Should you press it again?

Toady has done some work with this (e.g. the saving/loading progress bars), and it's been suggested before, so I wouldn't be surprised if he gets to it in the next release cycle.

• When I press the little X in the upper right hand corner of the screen: the program should stop (almost) instantanously. I have seen a guy get physically angry by DF not closing when he pressed x. Just show a 'plz wait' screen, do all saving and stuff: and kill the program. No more 'lets have the user jump to hoops when he/she tries to stop the program'.

It displays the options menu when you're in a screen where pressing "Esc" displays that menu, but I agree that it could be handled better.

[shadowclasper]

If you find yourself really hating the interface, take a break! Just put the game down for a few years. You'll find that there isn't anywhere else on the planet to experience a dwarf fortress, and either you will accept this fact and move on with your life or return to find the game as you left it: a beautiful, incoherent and utterly challenging system of childhood fantasy-simulation. If you're playing Dwarf Fortress just to play the game, you're doing it wrong.

Stupidest thing I've ever read on these forums.

If you're playing a game to -just play the game- then you're doing it wrong? Please. That's as backwards as the idiots claiming you're not really playing the game if it's not in ASCII.

It's a childhood-fantasy simulation and wonderful, but for god's sake it could be presented better. Would you go to a restaurant with fantastic food if all the orders had to be made in morse code and you had to climb ladders to get to your tables? Maybe a few times, but after that it's too much trouble.