Print

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

[greenskye]

NW_Kohaku has a thread concerning volume and mass and while I think that would in general be a better solution, I also feel that it would be a pretty major overhaul of the game. This is an attempt to offer a simpler alternative.


This idea came from the addition of rubble to mining thread. That thread describes a system where you get 7/7 materials from mining a square, some of which are rubble. You then must move the rubble out of the way before you can continue mining. I don't want to argue for or against rubble blocking mining here. That can be handled in the other thread.



The Suggestion

Basically the game would use abstracted units of stone, wood, ore, etc. This is actually what the game does now, but it does so inconsistently. By breaking the units down into smaller pieces, we can more easily balance how resources are obtained and used.


Obtaining resources:

Mining: Instead of dropping a single stone as it does now, it would instead drop 7 items. To line up with recent drop rate changes in mining, fewer than 7 stones might drop. It might be 4 or 2 or 0. If rubble is implemented, the remainder of a tile would be rubble. So you might have 3 stone and 4 rubble. Toady has moved away from skill based drops, so I won't tie miner skill into drop rates now.

Ore/Gems: Ore and gems would also drop as a number of items from a tile. You might get 3 ore and 4 stone. Or 3 ore, 2 stone, and 2 rubble. RNG values affect how many you obtain from a given tile.

Sand: Sand is expressed as a 7/7 value and can be depleted, unlike how it works now. I'm not sure how it should be collected... Perhaps mining just leaves behind a bunch of sand? Or should it function more like water? However it is collected, each tile of sand should contain only 7 units.

Wood: Each tree drops 7 units of wood. Perhaps some units are lost to represent unusable branches or twigs. If multi-tile trees are implemented, each tile would represent a standard 7 units.

Cloth: This already uses units to a degree. I'm not too familiar with exactly how this works, but I would tweak it so it fell in line with  the other industries.

And so on for the other types of resources...

For each of these, they could contain more or less than 7 units. I just used 7 because that's what water and magma used. As I understand 7 was used to save on memory space. It might be better to move to 10 for easier math if the FPS could handle it.

Using resources:

Each industry now has a much more reasonable method of balances resource costs. Each item to be made would cost a variable amount of resources. This would even allow for items that utilize more than one resource (such as wood and metal).

Some examples:

• Crafts and other low end items cost only one unit.
• A door might take 3 stone
• A statue would take 6 stone (it wouldn't quite need all 7)
• Depending on balance 1 ore = 1 bar. This could be tweaked to provide 2 bars, if more variation is needed for metal items.

There will still be a level of abstraction. Some crafts might still give multiples (3 rock mugs, etc). But I don't feel the need to go to smaller units just for realism's sake. For all I care 1 rock craft represents 1 box of rock junk. From a gameplay perspective, it is not necessary to go to such a small scale when you will be dealing with perhaps hundreds of them.
For items that require multiple units, they will have to all be of the same type. I have not created a new fort, but I believe this is currently how metal breastplates work. To reduce coding time, that's how I'd suggest this be implemented. At least until we allow for multiple-material creations.

I'm not against using multiple types of stone or wood, but then we get into the question of what that items properties are. If I use two different stones to make a door, what color is it? Perhaps it could just use the color of the first item. If anyone has suggestions on how to make this work, I'm open to hearing them.


Storage:

Depending on how stacking is implemented, this could change. Right now what I'd suggest is to just replace where one stone/wood/ore could be stored with 7 that could be stacked. This is just a straight 1:1 conversion so it shouldn't mess anyone up very much. If any of the other ideas about items slowing or blocking dwarves are implemented, this could change to incorporate those.

Problems

• Stacking has to be handled first. This system doesn't work if dwarves can't stack and unstack items efficiently. A stack should also be combined in memory to reduce the number of items that are needed to be tracked. I don't want to reduce FPS unnecessarily.
• Hauling needs to work. The recent changes indicate that this has been mostly solved, but as I have not used it, I cannot say that it will meet the requirements. Dwarves should be able to bring all of the required items for a door or other construction in one trip. If this system increases hauling significantly at all, it will not work.
• Proper interface support. The player should be able to tell (via the stocks screen?) how many of each item they have in an easy to understand manner. Also creating a multi-unit item should auto-select the required number of that resource. It should require any more button presses than we have right now.

I believe that these are all issues that can be solved if handled ahead of time. Let me know if you think I missed something.

Why not just go all the way and do true Volume/Mass?

Toady typically does choose to go all the way. However, he has not revealed his plans just yet, so I do not feel it is a waste of time to discuss simpler alternatives. Some of these suggestion also work as a method of abstracting the true volume/mass values. I doubt very many people will want to start ordering things in cubic meters. Overall though I tend to support more complete changes than placeholders, so if Toady has the interest I rather him just go whole hog and do true volume and mass.

That being said, there are some benefits towards a simpler solution.

• FPS. The current temperature/weather system is very complex and also very costly. I truthfully do not know how many more hyper-realistic systems we can put into DF before it becomes unplayable. There are limits to the amount we can simulate in real-time. It may not be possible to track that much information without tanking FPS.
• Value. Yes, tracking volume and mass allows for all sorts of cool things, but if the majority of those things can be achieved via a simpler solution, it might not be worth it. I admit that this argument has typically held very little weight with Toady, so it may be a moot point.

Note that I am not trying to steal discussion away from the Volume and Mass thread. If you would like to argue for or against volume and mass, please do so in the original thread. I'm going to assume for the purposes of this thread that Toady has decided NOT to implement Kohaku's suggestion.



Conclusion

The actual numbers are pretty meaningless at this point in time. The point is that by working with units, Toady has a much finer control over how resources are gained and spent. This allows for much of the benefits described in Kohaku's Volume and Mass thread, without having to actually track volume and mass. Even if volume and mass were implemented, I would suggest some more abstract method of representing quantities of resources.

Under this system, Toady (and potentially modders), have multiple points in the chain to tweak drop rates, costs, and output to provide balance to DF's wide ranging industries. Rather than the various workarounds that we have today, smaller units provide a consistent and easy to understand mechanic for players.

Links

I am 100% positive that this idea has been suggested before. I know that it was brought up in the Volume and Mass thread and many people discussed the concept of multiple sized blocks in the rubble thread, but my other searches have come up empty. If you have found a link to another thread that discusses this idea, let me know and I'll link it.

Volume and Mass (Full disclosure: I have not read this entire thread)
Rubble

[NW_Kohaku]

Ideas like this actually came up frequently as common alternatives to the Volume and Mass suggestion I was pushing for earlier. 

What it comes down to, however, is that for either this or Volume and Mass's idea of precise units but fungible sizes of specific pieces of material, you need stacking first.

The reason we only get one log or one boulder now is that large item lists bloat the current item vector (although I do wish DF would move off of a vector and onto a container type that is more functional with large numbers of contained pointers) is that we simply cannot stack 10 wood planks as a single item times ten, we have to store them as ten individual items.

It's less a problem now that dwarves can collect from multiple piles, but the primary reason that this sort of suggestion wasn't acted upon before was that dwarves needed to collect items from multiple piles if they needed 5 units of wood planks or something.  Without stacking, this is still a problem. 


Mining: for mining, I think that a stone taking up 1/3rd of a tile might actually be easier (so 3 rubble or 2 rubble and one boulder with a possible giant boulder taking up 2 regular boulder's worth) than 7, and 7 is just the number we are most familiar with. 

For these, rubble (or gravel or whatever you want to call it) would best be handled with a generic non-ore rubble type and be capable of stacking with the rubble.

People have pointed out that ores should often be a type of gravel or rubble rather than a boulder, as well, which would be a typed distinctly (hematite rubble/gravel) before being worked. 

Sand is something we may want to consider more carefully.  While I'm all for having a fixed definition of how much sand is allowed in a tile, and making pickaxe mining a Non-Newtonian Fluid impossible, a blunt 7 units of sand per tile is exactly the sort of problem with item sizes that we're supposed to be moving away from, here.

The same goes for wood - part of the objective is to make trees of different sizes, which means more or less wood per tree, rather than a one-size-fits-all 7 wood.  This is especially important if we have tree farming later on with improved farming, and we have different "crop yields" in the tree farming.


Anyway, this whole thing came up pretty often in some flavor or another in the actual Volume and Mass thread, and I'll say here what I said there:

So long as there is stacking, there is NO FPS difference between having the game track "10 liters" or "7 kilograms" of wood and the game tracking "wood [5]".  Literally the only difference between a stack of one and a stack of the other is that in Volume and Mass, the units have a distinct name. 

For example, currently, metal ingots take up 2 liters.  So, a stack of "Iron bars [4]" is exactly the same thing as "Iron bars: 8 liters".  (Excepting, of course, that in this case, the unit of measure is half that of the other, but as long as stacks are nothing more than integers of a given unit size, that's largely irrelevant.)

So, basically, your "simpler" solution is actually no simpler at all.  The Volume and Mass idea is essentially the same thing, but with a name for the units that makes comparisons between different stacks easier. 


EDIT:

In fact, the common unit of measurement in the game (at least, the raws) is the cubic centimeter.  That is the unit used in [SIZE:whatever] in the creature raws.  It is probably also what is used in the hard-coded raws.  SIZE, which everything has defined, is just a cubic centimeter.

If we go by my calculations of a tile, we have [SIZE:27000000] in a tile.  Toady recently talked about a 2m*2m*3m tile for minecart physics, so that would translate into [SIZE:12000000] tiles.  If you just declare that a tile full of sand has 12000000 cubic centimeters of sand in it, you're pretty much done.  Again, this is the unit of measure the game already uses for everything, anyway, it just doesn't tell you outright yet. 

You just need to use a unit to display that volume, and liters (SIZE:1000, or 12000 liters per tile) would be an easier way of doing so.  Then, you can compare a liter of meat to a liter of wood to a liter of metal.

[greenskye]

Good points. I guess my fear in the mass and volume thread is the interface. I'll move my discussion there.