Print

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

[Neruz]

I'd like to have the option to set a workshop to make automatically requested items, and then assign one of my underused dwarfs to it.  But it's not always what you want.  Still, it would be neat if, say, when you had a workshop set up to generate beds as needed, you could place beds and the workshop would build them and send them to the indicated location.

THIS. It would be so useful if we could tell a workshop to be automated to immediately meet any needs. Combine this with the ability to set orders like "Ensure we have at least 10 cruches in stockpiles at all times" and a massive amount of the baby sitting in DF would be cut.

Micromanagement is good, baby sitting is not.

[Jiri Petru]

Ok, this discussion inspired me to go and sum up my proposals of the Labour Automation System  (TM) (C) (R).  How about we continue the discussion there and leave this thread for other complaints?

Solarn, all your issues can be solved either by a well implemented automation, or by turning off what you don't want to have automated, or by changing the default setup. Automation isn't meant to play the game instead of you. Players like you could even have ini option to have nothing automated! But there's no point speaking against automation when it doesn't make you any harm and others would kill for it.

[Solarn]

(One last post here then I'm migrating to the new thread)

It's just that I've never met a computer smart enough not to screw up automated tasks in even much simpler games than Dwarf Fortress. Whether it's bad prioritizing, using up precious resources or organizational problems, something always goes wrong.

For example, in Dwarf Fortress items that are currently being carried do not show up as available. Depending on how far the stockpile is from the workshops, an automated order could produce two, three or even four times as much items as needed as workshops check for the number of items of that type and find none because the ones they just produced are currently being carried. This would use up both resources and production time.

Or how would you determine which workshops would meet a particular order? Let's say you have six carpenter's workshops. That's not even an unrealistic number. One of them is for producing beds when needed, so it's close to the sleeping quarters. Another one is producing barrels for the farming industry, which constantly needs them. Yet another one is producing, let's say bins. And so on. And suddenly an automated order arrives for twenty crutches (because they're so convenient as an example). How do you control which workshop takes the order and which doesn't? After all, bin production could stop for a while and maybe bed or door production too, but stopping the barrel production would mean rotting plump helmets everywhere because they can't be put into barrels and a stopped brewing industry until the order is met. You could micromanage the workshops to ensure important production does not get stopped, but then the automation loses its point.

[Chronas]

Suddenly needing 20 crutches isn't a common occurrence, goblins aren't that dangerous and orcs aren't canon, remember?
What you are saying is that the automation will be stopped by an emergency -put in the same category as running out of trees or your legendary carpenter tantrums and smashes his workshop because his fisherdwarf wife just got carp'd. it is unreasonable to expect an automated system will run like clockwork when its crafted with dwarvern mechanisms.

[Neruz]

For example, in Dwarf Fortress items that are currently being carried do not show up as available. Depending on how far the stockpile is from the workshops, an automated order could produce two, three or even four times as much items as needed as workshops check for the number of items of that type and find none because the ones they just produced are currently being carried. This would use up both resources and production time.

Ovbiously this is a problem with the way the game checks items, not a conceptual automation system.

Or how would you determine which workshops would meet a particular order? Let's say you have six carpenter's workshops. That's not even an unrealistic number. One of them is for producing beds when needed, so it's close to the sleeping quarters. Another one is producing barrels for the farming industry, which constantly needs them. Yet another one is producing, let's say bins. And so on. And suddenly an automated order arrives for twenty crutches (because they're so convenient as an example). How do you control which workshop takes the order and which doesn't? After all, bin production could stop for a while and maybe bed or door production too, but stopping the barrel production would mean rotting plump helmets everywhere because they can't be put into barrels and a stopped brewing industry until the order is met. You could micromanage the workshops to ensure important production does not get stopped, but then the automation loses its point.

That's why you declare specific workshops as 'automated' workshops, able to accept automated orders. Your important bed, barrel and bin workshops do not accept automated orders, but that one up there that doesn't do anything vital does.

[jamoecw]

why not have a list and have an idle workshop selected for one automation job at a time.  so if you have 6 carpenter workshops, and two are idle, and you have a shortfall of 20 crutches then the two idle workshops produce one crutch each?  that way automation jobs don't clog workshops, and you have a list of what is needed.


another example with multiple types would be if you had: 4 farms, 2 kitchens, 2 brewerys, 1 millstone; and you had a shortfall of 6 wine, 2 simple meals;  you have in stock 1 flour, 1 plump helmet, 60 wheat seeds, 0 helmet spawn; your kitchen orders are to not cook seeds; 1 farm, 2 kitchens, 1 brewery, 1 millstone are idle; 3 farms are set for weat, 1 brewery is making rum.

Spoiler (click to show/hide)

the plump helmet would get qued for brewing at the idle brewery, leaving 5 wines left on the list, with only 1 unit of flour and no other cooking ingredients the simple meals wouldn't be able to be qued just yet.

having qued the plump helmet you would then have a shortfall of 1 plump helmet, but there are no more spawn yet.

when the wheat rolls off of the farms you sit back and do nothing, and the program is set for only 1 flour so it does nothing.

when the wine gets brewed at the idle brewery (which is now brewing wine) 5 spawn are now available to plant, but the program only plants one because that's all it is set to plant.

when the plump helmet grows it is then picked and you have 1 plump helmet and 1 unit of flour, which then gets used up to que a simple meal at one of the idle kitchens, leaving a shortfall of 1 plump helmet and 1 unit of flour.  since you have wheat it grabs one and ques up a make flour job at the mill, it also uses up another of the remaining four spawn to plant another plump helmet, leaving only 3.  at this point you have a shortfall of 5 wine and 1 simple meal.

in this cycle you have 1 plump helmet rolling off the farm, which goes into wine production, which causes a shortfall of 1 plump helmet which is remedied by auto planting 1 spawn leaving 2 left.  flour also rolls out from the mill, which just sits there since the only available cooking materials is flour and wine, which you have a shortfall of (and thus won't use).  you also have 1 simple meal going into your food stocks, leaving a shortfall of 5 wine and 1 simple meal.

in this cycle you have wine coming out of the brewery, along with 5 more spawn.  1 plump helmet from the farm, which goes into simple meal production along with the flour from last cycle.  the new helmet short fall causes the program to plant another spawn, now up to 6 (5+2-1), and the program also makes more wheat. shortfall is now at 4 wine.

in this cycle a plump helmet rolls off of the farm and into the brewery, and a spawn gets planted.  spawn 5, wine 3.

in this cycle the wine rolls out with 5 more spawn, and the farm produces one plump helmet, which goes into wine production and one spawn goes into plump helmet production.  spawn 9, wine 2.

in this cycle the wine rolls out with 5 more spawn, and the farm produces one plump helmet, which goes into wine production and one spawn goes into plump helmet production.  spawn 13, wine 1.

in this cycle the wine rolls out with 5 more spawn, and the farm produces one plump helmet, which goes into wine production and one spawn goes into plump helmet production.  spawn 17.

in this cycle the wine rolls out with 5 more spawn, and the farm produces one plump helmet, which leaves no more shortfalls, and 22 spawn.

very simple, and allows one to do his own micromanaging if one wishes to, operating off of a shortfall list which can be set to auto fulfill similar to workshop jobs being set to repeat.  won't tie up workshops if you are using them and no need to set workshops to accept auto commands.

[nodule]

(long top-level reply ahead)

There are two relevant concerns here: first, what turns off newbie players?  Lots of people have focused on this to good effect.  Second, what prevents someone who has learned the ropes from really getting into this game?  As someone who overcame the first hurdle, played obsessively for a week, then lost interest, I think I can speak to both concerns.

tutorial/tilesets: I started playing dwarf fortress using an excellent tutorial that provided a pre-packaged version with the mayday tileset preinstalled.  I don't think I would have gotten into this fabulous game were it not for that.  Pre-packaging that tileset with an easy way to enable it (first time loading df="would you like to use ascii graphics or a tileset? you can change this later") would be huge.  As for an in-game tutorial, that isn't strictly necessary since there are excellent third-party ones available.  But I strongly encourage linking to one prominently on the download page, and perhaps also in-game.  There's absolutely nothing wrong with the complexity of the game, but it is almost impossible to figure out without a careful tutorial.

game saving: many many people, including myself, loaded the latest season auto-save the second time they started df, which caused them to think that they had lost progress (and once they have done that, they have!).  Perhaps I'm dense, but I did this many times, each time being incredibly frustrated, and my main save game ended up being the one marked year 03 even into year 10.  something as simple as naming these save games "backup-xxxx" would be a huge help (preferably also warning the user before loading one of them!)

UI/framerate: enough has been said about this so far, I think.  After making a fort of 60 dwarves, it is sad to see the framerate drop precipitously and know that it will only get worse.  It is a serious blow to one's creativity to constantly think about the framerate implications of the cool things you want to do.

labour micromanagement: as several other people have said, it is fun to set up new industries, but maintaining them is incredibly frustrating.  Putting a workshop on auto-build works well, until one of the source resources dries up, which causes all the tasks to be cancelled.  It is also too easy to either run out of an item, or over-produce it.  I felt that I was constantly in a seesaw between having no wood and having too much, having no alcohol and having gallons, etc.  In an attempt to clear out stone, I let my mechanics produce thousands of mechanisms which I had to find storage space for.  Having systems like "build 15 beds if there are none" would be so so huge.  Generally, I found it difficult to keep dwarves busy without making them over-produce (thus causing problems with storage and hauling).

game balance: This is what ultimately why I don't play anymore, and has been mentioned by others.  The game as it stands doesn't do a very good job carefully delivering challenges to the player in a way to maximize "fun".

This view has been expressed by others saying "the game is too easy", and by others saying "the game is too simulationist", and by other still in saying "the game is too hard".  People saying these things have generally been attacked in this thread, the usual vein being "if you don't like it, don't play" or, for systems that are too easy "you don't have to play using X".  The problem is that (in my mind) Dwarf Fortress is first and foremost not a simulation, but a game that uses simulation to produce varied and emergent game play.  The reason why people are (somewhat) saddened about the current developmental arc isn't that they wouldn't like some of the new simulation components, but that the existing components haven't had their "fun factor" refined yet. 

One good example is immigrants.  Starting a new fort is incredibly exciting: you have so many new systems to set up and you're constantly balancing the work output of your very limited labour.  You feel attached to each dwarf.  Just as you're making a bit of progress, 12-20 immigrants show up.  It is very easy to be overwhelmed.  Your connection with each dwarf is severed.  You often don't have enough for everyone to do.  It is discouraging.  People have been criticized in this thread for not being able to "handle" the immigrant influx, saying that it is an expected challenge of the game.  Sure, but what happens is that you've replaced the challenge of doing what you can with limited labour with the challenge of having to micromanage three times as many dwarves.  I think that this is objectively bad, and immigration should only be a certain % of your current population (max 50% at the beginning, less as your fort grows).  As for those who complain that you can manage this yourself through init.ini tweaking: this is true.  Tweaking should be for power players who want to go beyond the designers original intent, not be necessary to fix a game design problem that is commonly run into.

Were I in the position of developing df, I would try very hard to make the currently-available game as much of a "game" as possible, to ensure continued interest in its development.  This would mean spending a few months working on balance issues in fortress mode, and consider gameplay balance fixes as important as bug fixes even while developing the next component of nifty simulation.  Not everything can be fixed to satisfaction before developing more architecture (something several people have argued, and it makes sense).  But as some people have pointed out, there are several things that should be able to be fixed by tweaking some constants (range attack, farming, immigration, perhaps trap trigger %, etc.).  It feels like the current approach is to wait until a more robust/realistic simulation engine "fixes" the problem, which is unsatisfying.

Several people have commented that a lot of new features that _are_ being developed will have cool gameplay consequences.  This is true (underground sites, poison, etc. do sound cool).  But, will the necessary (imo) several months of making these things balanced and useful in-game be done next, or will another simulation system be done next?  If the answer is the former, it is tempting to be excited about the future of df.  If the latter, I'll try to forget about df and hope I stumble across it in five years.

I am a software developer and so I realize the tensions and tradeoffs involved.  I hope I don't sound too critical of Toady: I have immense respect for his work and this game in particular. 

It is truly an inspirational concept and game, and I hope it continued to be as it is further developed.

[Earthquake Damage]

Were I in the position of developing df, I would try very hard to make the currently-available game as much of a "game" as possible, to ensure continued interest in its development.  This would mean spending a few months working on balance issues in fortress mode, and consider gameplay balance fixes as important as bug fixes even while developing the next component of nifty simulation.  Not everything can be fixed to satisfaction before developing more architecture (something several people have argued, and it makes sense).  But as some people have pointed out, there are several things that should be able to be fixed by tweaking some constants (range attack, farming, immigration, perhaps trap trigger %, etc.).  It feels like the current approach is to wait until a more robust/realistic simulation engine "fixes" the problem, which is unsatisfying.

Toady has, to my knowledge, deliberately avoided working on many game balance issues.  The game is very much unfinished at the moment.  Some aspects of the game are placeholders, to be more thoroughly developed in the future.  Others simply cannot be (semi-)permanently fixed/improved in the game's current state because a long-term fix will rely on an incomplete or untouched development arc (read the development pages if you want some idea what the final game should look like).  Why should Toady spend several months of development on temporary solutions when he already plans to rewrite the underlying systems later on?

So, yeah.  Fixing existing problems for the benefit of new or current players would be great, but much of that effort would go to waste as the game develops.  On the other hand, leaving the game poorly balanced in the interim has a detrimental effect on the fan base.  For Toady, that means fewer potential donations.  For some of the fans, it keeps the riffraff away from the forums. 

[Aaaamory]

Discarded worn clothing being ignored when marked for dumping.  WTF.  I know nobody touches it because it's still owned by the dwarf and everything, but I think a cleaner dwarf should sweep it up unless it was tossed it on the floor of their sleeping quarters, they can mess up their own private space all they like.

[Neruz]

Yeah, balance is a good example of things that really shouldn't have time wasted on them at the moment. Remember that DF is only ~28% complete, that's whitebox level. Most games don't see public beta until they're more like 90 - 95% complete to give you a comparison.

[darkflagrance]

The greatest problem with turning off the fanbase at such an early stage is that one risks turning away those fans for life. Someone who has tried Dwarf Fortress once, and acquired a strong feeling of frustration before finally giving up, may be deterred by the effort they remember having put in from trying the game even in a greatly improved state.

[Neruz]

Dwarf Fortress only appeals to a small hardcore\elitist demographic, so alienating the fanbase is less of an issue.

Additionally, it's pretty ovbious that Toady is doing this because he wants to, so the fanbase is substantially less important than it is for a major commercial company that would be doing it to make money.


Dwarf Fortress is very much an aberration of game production, i wouldn't try to apply mainstream techniques to it.

[zwei]

Dwarf Fortress only appeals to a small hardcore\elitist demographic, so alienating the fanbase is less of an issue.

Additionally, it's pretty ovbious that Toady is doing this because he wants to, so the fanbase is substantially less important than it is for a major commercial company that would be doing it to make money.


Dwarf Fortress is very much an aberration of game production, i wouldn't try to apply mainstream techniques to it.

I'd call bullshit on this.

First, it hardly caters to "leet hardcores". It has steep learning curve and controls that require dedication to master, but that is not a point of this game. Point is to have fun in sandbox world, which is by design game for casual people with anyone going hardcore being ... weird person.

It has steep learning curve only because there is no way to lean how to play it without reading detailed tutorial and wiki. Its controls are just way too messy. But that is not by design, but rather by accident and result of it being one-man-dev show.

Seccond, Fanbase is actually quite important: Creator is doing this instead of/as full time job, so he does need money to keep on going, and, well, the more fans the merrier.

Last, dwarf fortress is not aberation at all. It is Spore or Sims or GTA type game that happens to have more detail and is harder to play. Give it decent graphics coat and controll, Make good tutorial, Make several fortress mode missions with storyline in premade world and you get game with solid potential.

And, chicken-and-egg, if game gets enough fans/supoport, Creator could actually hire designer to figure out good gui for him, graphics guy to make it 'nice' and put DF:2010 edition on steam.

[Neruz]

I call bullshit on you reading my post. I said that the fanbase for Toady is less important than it is for a major commercial company as Toady is far less interested in the bottom line.

Dwarf Fortress most certainly is an aberration. It's an exceedingly complex one and a half man roguelike game. All the standard game design models say that DF should have died by now, and indeed in 99% of the time it would. The original Armok being a good example, DF has managed to cheat the odds.

And finally, DF is a Roguelike, Roguelikes have small fanbases, compare the DF fanbase (which numbers maybe a thousand at most, and more like a few hundred) to the fanbase of a mainstream game, which will often number in the ten thousands, or, in the case of a certain MMO, over 11 million.


Finally, the fact that it has a steep learning curve for a good reason does not in any way change the fact that it has a steep learning curve.

[Aqizzar]

How is a Real Time Strategy town management sim a "roguelike" in any way except that by default it uses ASCI for graphics?  Adventure Mode yes, but Adventure Mode barely exists yet.  Roguelike is not a synonym for any game that's hard to play and has crappy/no graphics.