Print

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

[Featheredragon]

This entire idea just makes my brain melt. This is awesome. DO NOT LET THIS IDEA DIE!

[LordBaal]

Well hopefully this would become a thing someday, Toady himself have said that the current of "buildings" is likely a place holder.

When I read the OP I easily think I could have wrote it myself, I agree 100% with this.

As for the economic zones, I have thought of something before, but can't find the post. Basically, what I thought was to designate "civil" areas where your dwarves would do anything they want, mine, stablish shops, markets, farms, build homes and basically do whatever they hell they wanted. You could still control and regulate their activities by delimiting the zones they could use (who wide, deep and long could they dig) and mandates like forbidding to mine X mineral/rock, or all the gold found being dumped onto the royal(player) stockpiles and so.

Things like this would widen the role of you as the player from almighty God to also a living manager (it would also give nobles a more useful role). Of course if you feel particularly dictatorial you could simply play as now not establishing zones of free use for civilians (it would make sense if you are not managing a city but a military fortress in the literal sense of the word for example).

Of course this is if dwarven economy follow the same logic as the humans do.

[Loci]

I think the tool problem is a bit exaggerated. It would only really be a problem if somebody forgot include a container. A dwarf would take whatever tool(s) necessary (e.g. hammer and tongs) to the proper furniture item for the job (e.g. anvil). As long as a dwarf prioritizes items already in the workshop, the tools should generate jobs to be put back where they were found, using the same code already in the hospital.

I think you underestimate the problems with tools. Ten workshops with 10 different types of tools means 100 new types of items to be created, tracked, and assigned. (And 10 tools is certainly far less than the average tradesman would have had.) The amount of micromanagement necessary to create a functional fortress would increase drastically.

While I like the idea of workshop zones, the tool handling really needs to remain simple. I'd suggest a generic "tools" item, made by a metalcrafter, that gets "specialized" into a specific type of "tools" item when taken to a workshop. So a generic "iron tools" becomes an "iron mason's tools" if taken to a mason's shop, an "iron kitchen tools" if taken to a kitchen, etc. That conveniently accomplishes the goal of requiring tools for realism without bogging down the player with micromanaging jigsaws, coping saws, ripsaws, jab saws, etc.

[LordBaal]

I think the tool problem is a bit exaggerated. It would only really be a problem if somebody forgot include a container. A dwarf would take whatever tool(s) necessary (e.g. hammer and tongs) to the proper furniture item for the job (e.g. anvil). As long as a dwarf prioritizes items already in the workshop, the tools should generate jobs to be put back where they were found, using the same code already in the hospital.

I think you underestimate the problems with tools. Ten workshops with 10 different types of tools means 100 new types of items to be created, tracked, and assigned. (And 10 tools is certainly far less than the average tradesman would have had.) The amount of micromanagement necessary to create a functional fortress would increase drastically.

While I like the idea of workshop zones, the tool handling really needs to remain simple. I'd suggest a generic "tools" item, made by a metalcrafter, that gets "specialized" into a specific type of "tools" item when taken to a workshop. So a generic "iron tools" becomes an "iron mason's tools" if taken to a mason's shop, an "iron kitchen tools" if taken to a kitchen, etc. That conveniently accomplishes the goal of requiring tools for realism without bogging down the player with micromanaging jigsaws, coping saws, ripsaws, jab saws, etc.

Not necessarily if the manager gets to a working order where you can have standing orders as "always have at least 100 nails done to be procured by anyone" and the sort. Also much less if civilian activities not controlled by you are ever allowed.

[Loci]

Not necessarily if the manager gets to a working order where you can have standing orders as "always have at least 100 nails done to be procured by anyone" and the sort. Also much less if civilian activities not controlled by you are ever allowed.

So your response to a complexity concern is to add a new manager function, two new variables per item (number stocked and allowed uses), and 100 auto-repeating manager tasks?

While I'm sure that's somebody's idea of a good time, it's not mine. I don't use the manager, don't want to set up 100 tasks just to start a fortress, and don't want to worry about the last of my metal being used to automatically craft kitchen utensils when I really needed a mechanic's shop. 

[LordBaal]

Yes, sort off. I'm sure the manager would also allow for priorities and you could always state to have X ammount of resources on stock for your personal mandates.

[GoblinCookie]

So your response to a complexity concern is to add a new manager function, two new variables per item (number stocked and allowed uses), and 100 auto-repeating manager tasks?

While I'm sure that's somebody's idea of a good time, it's not mine. I don't use the manager, don't want to set up 100 tasks just to start a fortress, and don't want to worry about the last of my metal being used to automatically craft kitchen utensils when I really needed a mechanic's shop.

Yes, the best solution to a complexity problem is to find a simple solution rather than a complex one.  The sheer potential of the manager is very much underutilised and underdeveloped.

The game definately needs tools in order to have an economic order that makes any kind of sense.

[Enchiridion]

a whole lot of thought. just read it.

I would tend to agree with you on most things regarding these tags. I do not use them myself as I do not mod, but I also see that you have almost everything conceivable covered. Nice.

As for the whole tool/macro question, I understand that this adds complexity to the game, but that, in my opinion, is not bad if it is meaningful complexity. In my opinion it would give crafting zones(orkshops) a much MUCH bigger meaning as any basic tool can be produced by smashing two rocks or sticks together most of the time. Like, need a mallet? Well, technically a rock can do. Need a chisel? Well, just let me smash these rocks together until one is sharp enough. Mallet and chisel is really all you need at the very start.

If you are not pleased with this, I could make a big chart explaining the various possibilities of tool hierarchy and so on.

Also, technically the only "buildings" left after this would be 1x1 structures that act like tables or chairs or querns etc.

Also, thank you guys for the positive feedback. You have no idea how proud I am that this thing is still here after such a long time and running.

[Tristan Alkai]

As for the whole tool/macro question, I understand that this adds complexity to the game, but that, in my opinion, is not bad if it is meaningful complexity. In my opinion it would give crafting zones(workshops) a much MUCH bigger meaning as any basic tool can be produced by smashing two rocks or sticks together most of the time. Like, need a mallet? Well, technically a rock can do. Need a chisel? Well, just let me smash these rocks together until one is sharp enough. Mallet and chisel is really all you need at the very start.

Maybe my "Construction Substitute" set of tokens might make sense for TOOLs as well?  The tags I already wrote over there should be able to cover situations like this. 

Construction Template:
(snip)
[SUBSTITUTE:?] Reactions that call for the current construction can use this other construction instead.  Can be specified multiple times.  Also accepts NONE and NOTHING, both of which indicate that reactions which benefit from this piece of infrastructure can be performed without it (such as a potter's wheel).
    [PENALTY_SPEED:<number>] Reactions using the substitute will take longer than normal, to a degree specified by the number (I don't know enough about the current math to say exactly how).  For example, the wiki specifies that "millstones process plants much faster than querns."  Milling reactions would call for a millstone, and the millstone would have SUBSTITUTE:QUERN and a PENALTY_SPEED tag. 
    [PENALTY_QUALITY:<number>] Reactions using this substitute produce goods of lower quality than normal.  How much lower is specified by the number (again, I don't know enough about the current math to say exactly how it should work).  I remember reading somewhere on the forum about stone blocks being a potential substitute for a proper anvil, which might involve this tag.
    [CAP_QUALITY:<number>] Reactions using this substitute cannot produce products above the specified quality level. 
[PREFERRED:?] Alias for SUBSTITUTE, with the distinction that workers will seek out this construction in preference to the original one.  Used for magma versions of furnaces.

[crazyabe]

Wow, i would like to see this in game,   but it would require recodeing & current worlds would have to be deleted, for being incompatible with this.

[Heretic]

Great idea, love to see this replace the current system.

+1

[Enchiridion]

As for the whole tool/macro question, I understand that this adds complexity to the game, but that, in my opinion, is not bad if it is meaningful complexity. In my opinion it would give crafting zones(workshops) a much MUCH bigger meaning as any basic tool can be produced by smashing two rocks or sticks together most of the time. Like, need a mallet? Well, technically a rock can do. Need a chisel? Well, just let me smash these rocks together until one is sharp enough. Mallet and chisel is really all you need at the very start.

Maybe my "Construction Substitute" set of tokens might make sense for TOOLs as well?  The tags I already wrote over there should be able to cover situations like this. 

Construction Template:
(snip)
[SUBSTITUTE:?] Reactions that call for the current construction can use this other construction instead.  Can be specified multiple times.  Also accepts NONE and NOTHING, both of which indicate that reactions which benefit from this piece of infrastructure can be performed without it (such as a potter's wheel).
    [PENALTY_SPEED:<number>] Reactions using the substitute will take longer than normal, to a degree specified by the number (I don't know enough about the current math to say exactly how).  For example, the wiki specifies that "millstones process plants much faster than querns."  Milling reactions would call for a millstone, and the millstone would have SUBSTITUTE:QUERN and a PENALTY_SPEED tag. 
    [PENALTY_QUALITY:<number>] Reactions using this substitute produce goods of lower quality than normal.  How much lower is specified by the number (again, I don't know enough about the current math to say exactly how it should work).  I remember reading somewhere on the forum about stone blocks being a potential substitute for a proper anvil, which might involve this tag.
    [CAP_QUALITY:<number>] Reactions using this substitute cannot produce products above the specified quality level. 
[PREFERRED:?] Alias for SUBSTITUTE, with the distinction that workers will seek out this construction in preference to the original one.  Used for magma versions of furnaces.

Sory for the long response time. Yeah it certainly could work that way. In fact, the token system itself wouldnt actually NEED a rework, just maybe a few new tags like the ones you suggested. As is, the workshop tags are still applicable for the areas as they can be counted as the same thing. The only problem thus far that I see is that maybe there would be TOO many tags since there might be some overlap. Perhaps tag macros might be a thing to help simplify, but then it would also bog down the readability for other people who are new to them... hmm...

[Graknorke]

ptw, pretty neat idea.
In my opinion a lot of DF's mechanics need unifying, including workshops, zones, rooms etc. At the moment (as you'd expect for something of DF's size) it's a lot of systems stuck on top of each other as exceptions to the rule, that then become the new rules that need to be added on to later.

[Enchiridion]

ptw, pretty neat idea.
In my opinion a lot of DF's mechanics need unifying, including workshops, zones, rooms etc. At the moment (as you'd expect for something of DF's size) it's a lot of systems stuck on top of each other as exceptions to the rule, that then become the new rules that need to be added on to later.

Such is the sad yet interesting nature of emergent systems.

[vomov]

This might be a stupid question, but: how difficult is it to implement a basic starting version of this?
I've been following Stonehearth, which is a somewhat similar game, but based on odd-looking voxel critters instead of ascii. That game has implemented a type of workshop made out of separate parts in a very short time, leading to (what I think) a potentially very complicated situation. However; they have implemented this in a period of months, while this suggestion has been out there since 2007, in some form, at least.

I'm wondering if Toady actually has this on his list, and how high this is. While DF is hugely more complicated than any other game, including Stonehearth, I don't see this taking more than a couple of weeks to implement, while the benefits (for both gameplay and future coding) are huge.