Print

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

[G-Flex]

Sure it makes DF a bit more realistic.  But does it improve the game in any other way?  Does it make it more fun?

Such a change would touch just about every aspect of the game, potentially causing bugs in every aspect of the game.  It would also take up a huge portion of Toady's time, which could be spent on better things.  Maybe introduce this in v2.0

• I don't think you understand the complexity of the game as stated to be necessary for the game to reach 1.0 status.
• It could certainly improve many aspects of the game. It would finally be possible to have, say, workshop operations that are precise at all. Right now that's all kind of screwy and very very low-precision.

[NW_Kohaku]

It could certainly improve many aspects of the game. It would finally be possible to have, say, workshop operations that are precise at all. Right now that's all kind of screwy and very very low-precision.

To give a better example of this (other than the "it takes a whole cow to make one set of leather gloves" thing), consider that I want to make a pottery mod.  If I want to make ceramic jars in this game, it would run into a problem: people would wonder why they should use ceramics instead of wooden barrels.  A wooden barrel takes one wood.  Meanwhile, a piece of charcoal to fire the ceramics kiln takes one wood.  Then I'd have to get that ceramic glazed, which is actually a process something like glass, which means I'd have to use an entire unit of sand, equivalent to the making of a glass item.

Likewise, a copper earring takes the same amount of material as a pair of copper boots.  A stone earring takes the same amount of material as a stone door and a floor and the entire wall.  In fact, as came up in the thread about building walls over floors, the floor takes up as much stone as building the floor and the wall that stands on top of it, meaning building a wall over a floor would be taking two stone, while just building the wall would take one stone.

[G-Flex]

Currently, it would also be impossible to have furnaces require less than one wall unit of coal per production task, unless you have the coal->coke reaction produce more than one bar of coke... in other words, more than one wall's worth.

[Hammurabi]

• I don't think you understand the complexity of the game as stated to be necessary for the game to reach 1.0 status.
• It could certainly improve many aspects of the game. It would finally be possible to have, say, workshop operations that are precise at all. Right now that's all kind of screwy and very very low-precision.

A.  I fully understand the amount if work needed to get to v1.0.  It's probably somewhere around 20 man-years left.

B.  As soon as workshops are fully in the raws, there are better solutions.  Make a cow produce 20 units of leather, a pig 8 units of leather.  A leather glove might take one unit of leather, while a leather chest armor takes six.  For items that need less than "one unit", make multiples like mugs already do.  One block of stone gets crafted into 12 stone earrings, etc.

Currently, it would also be impossible to have furnaces require less than one wall unit of coal per production task, unless you have the coal->coke reaction produce more than one bar of coke... in other words, more than one wall's worth.

Make a new task in a workshop that turns "one coal" into "20 coal bricks".  Then each forge task can use some number of coal bricks.

[G-Flex]

That doesn't solve the other issues mentioned.


Also, I wasn't talking about the amount of work. I was talking about the complexity of the game.

[NW_Kohaku]

When looking over this idea, though, it starts to really dawn on me just how friggin' huge a 3m cube really is.

Consider a dwarven bedroom.  Again, a 3m cube is roughly 100 sq. feet of floorspace.  100 square feet is enough space for a pretty decent bedroom.  Not luxurious, but enough for a bed, a chest, and a cabinet, at least.  A 5' by 5' area is just barely enough for a full-sized bed.  It occupies just a quarter of the tile, but would preclude the placement of anything else in a tile, while the piece of furniture that contains the dwarf's clothing would likewise probably be closer to occupying about 10 square feet than 100, although it would occupy a full tile, as well.  The modest, 3 tile bedrooms (not even counting the 100 sq ft for the door) would be 300 square foot rooms, which should be quite luxurious.  That's not even touching how palacial a noble's room would become.

Hallways are 10 feet wide, as well.  Dwarves still have to stop, and try to path around anyone who gets in their way, though.  In order to accomodate traffic, you have to make those halls at least 20 feet wide... and 30 feet wide for a wagon.

All walls are 10 feet thick.

All doors occupy 100 square feet of swinging space.

Unfortunately, there is really only one way to counter such a problem, and that is to make the cubes smaller.  It could theoretically be that we simply make cubes 1/8th the size I originally suggested (5' cubes, similar to D&D, or 1.5 meter cubes, for a total of 3.375 cubic meters space), and simply make all floors occupy two z-levels (or make it three times, so that each tile is 3' or 1 meter cube).  Alternately, we could make tiles rectangular prisms, and make them twice (or three times) as tall as they are wide or long.  This could be solved by making z-level pathfinding more expensive than horizontal pathfinding.

Or, you know, we could just not care that fortresses are wildly disproportionate.

[Silverionmox]

I think it could be entertaining to define one square as the cube circumscribed around a dwarf. Humans and elves would then require two squares of open space to be able to walk upright, and that would assure that tall and short humanoids feel very different. Not to mention the military implications.

[NW_Kohaku]

Oh, and about density and mass and volume already in the game... I got un-lazified, and did a little research.

Iron is listed in the game raws as having a "SOLID_DENSITY" of 7850.  Wikipedia says pure iron has room temperature density of 7.874 g / cm^3.  My calculator says that's 7874 kg / m^3.  I'll just assume Toady was rounding or assuming some less dense impurities in the iron or something, and that this is the set of units Toady is using for his metals, since gold's SOLID_DENSITY is 19320, while wikipedia says 19.30 g/cm^3, and silver is SOLID_DENSITY 10490 versus wikipedia density of 10.49 g/cm^3.

OK, so we already have the game material density listed in the exact units I wanted to use, anyway, so we can find object volume fairly easily, right?

Since I didn't get THAT un-lazy, I'm just using the wiki page so that I don't have to go cataloguing all sorts of material densities on my own.

Apparently, you find the weight (mass and weight are the same for now, as gravity is always a constant, regardless of world) of a weapon by taking its material density, multiplying by the size of the weapon, and then dividing by 1,000,000.  Since we are dividing that cubic meter we are using as a base unit by a million, and there are a thousand liters in a cubic meter, we can find that the unit for size is still a milliliter, the same as with creature sizes, which I said in a previous post.

Gloves and shields are only the density divided by 100,000, and so take up 10 milliliters of volume... which seems quite tiny to me...  (And in the wiki page, it even links to bug reports listing this as a probable reason why shields are so light and weak.)

Shoes take up 1/6th of a liter times their "layer size", which is essentially their thickness value.

etc. etc.

When we are able to calculate these things, we are able to actually see what volume such objects are actually supposed to occupy (and, incidentally, argue that those volumes are probably wrong.)

Edit: I should also note that the fact that "size" is an integer value that seems to line up perfectly to milliliters, and is consistant across creatures and objects, density lines up as basically kg/m^3, and mass is measured in kg seems to heavily imply that Toady went out of his way to actually accomidate being able to measure objects in DF in exact units, rather than abstract unitless lumps the way that "stones" and "logs" exist now and in earlier versions.

[NW_Kohaku]

Sure it makes DF a bit more realistic.  But does it improve the game in any other way?  Does it make it more fun?

Yes and yes.  I've been trying to explain this with the list of things that such a change makes possible, but I'll explain again in the bit a little down the way.

Such a change would touch just about every aspect of the game, potentially causing bugs in every aspect of the game.  It would also take up a huge portion of Toady's time, which could be spent on better things.  Maybe introduce this in v2.0

First, there is no v2.0.  There probably will not even be a v1.0, as it will just stretch on to infinity with versions 0.282.3582.14e as Toady keeps finding more things to cram into the game. But that's beside the point.

This argument means about the same thing to this particular suggestion as it means to every suggestion.  Any suggestion takes up Toady's time if he impliments it, and any change can cause bugs. 

This is made even more silly by the fact that, as you say, this will impact quite a bit, meaning that the more things that he changes before making this switch, the MORE work it will be to make sure everything is properly aligned.  It is, in fact, the sooner the better, as it took a total reworking of the entire material system (meaning every single type of material and object had to be reworked) just to get eveyrthing on this metric system equivalency I've been talking about.

This change, meanwhile enables quite a bit more to be done by players and modders and by regular players alike, making this obviously "worth it".

On Eternal Suggestion Voting.
Dwarves may make them shorter theoretically, but when we are dealing with stone caves, a little extra ceiling room for buttressing may be a good idea.

Dwarves are not the only ones who matter, anyway. Gotta account for human and other structures.

Well, this is based upon human building standards, not dwarves, anyway...  It's just being made a 10' cube since round numbers are easiest to work with.

...

B.  As soon as workshops are fully in the raws, there are better solutions.  Make a cow produce 20 units of leather, a pig 8 units of leather.  A leather glove might take one unit of leather, while a leather chest armor takes six.  For items that need less than "one unit", make multiples like mugs already do.  One block of stone gets crafted into 12 stone earrings, etc.

...

Make a new task in a workshop that turns "one coal" into "20 coal bricks".  Then each forge task can use some number of coal bricks.

OK, so then, if we want to make items out of units less than one log, we then have to make an entirely seperate kind of wood material, so that when a dwarf chops down a tree, it makes one log, but we can then split it into the 20 different wood items we need to have a little bit more leeway in how much material is used in a single given reaction, like making a barrel or other furniture, wheras I'd need some entirely seperate system for reducing wood to coal based on mass instead of volume, since woods have different densities.  That's not even counting stone, where it probably won't be raw-moddable how uncut stone will be used in constructions, anyway.

Again, the game is already made out to be able to measure objects in the units I am describing.  It just has to switch the way it presents the game to allow you to use items by the pound, as it were, and to be able to stack objects properly, which is something Toady has listed as something he will work on, anyway.

This doesn't even go into the potential applications of this change, which I tried to describe earlier.  Take, for example, the matter of tree sizes.  The trees that only take up one tile (not counting a psuedo-root structure in the tile below) have been a known problem in this game for a while.  It's quite hard for Toady's elven tree cities to take place when your city would be built upon trees the size of shrubs, after all.  This gives the chance to have a real mechanic whereby you can measure tree mass and size as it grows per annum, AND have it matter if/when your dwarves chop them down - especially useful when we are talking about dwarven tree farming when THAT gets up and running.

It gives us a chance to deal in more precise ways with metal wastage, or even how much ore can be extracted from a vein - currently, you either generate an ore stone, or vaporize a rock.  Now, you can have percentile success rates, generating varying degrees of smeltable ore or waste.  Likewise, the lumber cutting process can make higher-skilled woodcutters preserve more of the wood from the tree they have felled, making higher skill rankings in such skills actually matter.  Likewise, the mullock can be semi-faithfully tracked instead of simply vaporizing all cleared stone that isn't made into a "stone" object.

It gives us a chance to deal more realistically with food consumption rates based on creature size.

It lets us be able to user-define the actual size of most of our new products.

It can let us rework the fluid system to be both more accurate and take up less of our precious FPS.

Most importantly, it helps remedy a major hole in a game that otherwise respects notions of verisimilitude without really upsetting anything major.  I don't see how you can see only negatives in this, as I see only positives in exchange for something that Toady is probably going to have to give up and do eventually, so he might as well start thinking about doing it now.  After all, if he waits until "v2.0", there are more interlocking pieces that can break.  It's better to do it now, when so many things have yet to be implimented, and when those things, thanks to an internally consistant means of measurement, can probably be implimented with more ease than they otherwise would be.

[G-Flex]

First, there is no v2.0.  There probably will not even be a v1.0, as it will just stretch on to infinity with versions 0.282.3582.14e as Toady keeps finding more things to cram into the game. But that's beside the point.

As an aside, I'm not sure if you know this, but Toady doesn't consider "1.0" to be when the game is complete. Magic in general is even post-1.0 material. Of course, this is going by the old dev pages, so I'm not sure how true this still is.


I agree with what you say and don't have much to say (for once). There's just not much downside to this at all if things are presented reasonably to the user.

[Hammurabi]

I don't see how you can see only negatives in this, as I see only positives in exchange for something that Toady is probably going to have to give up and do eventually, so he might as well start thinking about doing it now.

FWIW, I agree with many of the positives that you mentioned.  For example, I think it is ridiculous that a square can only hold one gemstone (or only 10 gemstones in a bin).  I like your idea.  I just think there are many more important things for Today to work on that have a bigger effect on gameplay. 

[NW_Kohaku]

Something in the farming thread got me thinking, though, when it comes to liquids.

Correct.  I don't know how DF tracks the map data, I just know that it's pretty crammed; every bit assigned to something.  And water is actually 4 bits:

abcd

a = water/magma

bcd = 0-7 level.

If we are reworking how fluids would be tracked by making fluids be tracked in terms of volume, then we will break how fluids are currently tracked.  This may not necessarily be a bad thing as current fluid mechanics are not terribly efficient, and can only handle the fluids of water and magma currently.

In thinking about it, the best way to handle such a thing is with tracking fluids as, essentially, an object like a stone or a barrel (although I am not particularly sure how those are handled exactly, I would assume that, rather than as a set of bits in every single tile, would instead be a set of references), but with a special location, so that it could be checked without being terribly difficult to search for it amidst the giant list of objects in the game. 

A set of flag bits could be set up, essentially "HERE_THERE_BE_MAGMA" as one bit to let pathfinding and game mechanics know that magma-related fun is occuring in that tile, and another for "DANGEROUS_WATER_LEVELS", which would be based on having enough water to block pathing for non-amphibious creatures.

It would actually be somewhat more ideal if fluid was tracked as a large, multi-tile entity than as a property of every individual tile, as that would allow the fluid mechanics to operate on a large, continuous body of fluid, rather than upon potentially thousands of individually randomly moving clumps of fluid, which consumes CPU power voraciously.  Fluid could then theoretically just be tracked in a single large chunk of memory, with references to the tiles it occupies.  (Of course, this is speaking from a position of being blind as to the full way in which this is being implimented, which is a major handicap, as I have to talk in far more abstract terms than I really wish.) 

If we are making entire bodies of fluid (and their surrounding containers) into large entities, then for the calculations, we would be able to do a little calculus-style calculation of fluid flow, which would be more complex, but, considering the fact that it would save on potentially hundreds or thousands of smaller calls to the rand() function and checks against what is sitting in the tiles next door, it should have a significant net savings.

(Oh, and if anyone has links to more concrete examples of how fluid mechanics actually works, especially if it refers to how it is checked, please post it. I'd like to have both eyes open when I'm trying to figure these things out.)

[NW_Kohaku]

Actually, while trying to find out what the volume of a crossbow bolt should be, I was reminded of another reason to include more easily divisible units of materials: why are crossbow bolts with metal tips made entirely of metal?  Should it not be possible to make wood bolts with metal tips?  Similarly, metal picks should probably not have metal handles, when wooden ones are likely as good.

[CapnMikey]

Hey NW_Kohaku, I like your suggestions (this thread and others).  I think you and I have similar ideas of fun. 

I have thought about this before, and my biggest sticking point was that realistic distance makes the unrealistic time much more apparent.  We could actually say, okay, a dwarf walks 200m in one season - what?  I would lean towards revamping time, so it passes at a realistic speed, but that leads to a whole host of other problems, as I'm sure you can imagine.  Do you think it would be okay to have realistic mass/volume/distance, but highly gamey time?

Also, how much of the change is just semantics?  I became happier when I started thinking of "1 granite earring" as "1 (freaking huge pile of) granite earring(s)", and "1 seed" as "1 (big ole sack of) seeds".  Like, if a block made 100 earrings, their value would have to scaled down, or else they become a super-tradegood.  Scaled down by, say 100 - then what exactly does the change achieve?

I like your ideas for more realistic engineering/collapse.  I think a good way to alert the player would be a combination of flavour messages, and visual feedback.  Say you're building a bridge of unsupported floors, you might get a message "The floor creaks ominously", and the floor tiles where the bridge would snap off might start flashing.  If you built some support pillars, the flashing would stop.

I would also like to see tall structures topple sideways, rather than collapsing straight down like a perfectly controlled demolition.  Since you can't really have pillars or whatever leaning in gridworld, it's probably only doable if the structure breaks up into smaller pieces, depending on impact speed, but they could rotate.  So if your tower had its left supports taken out, it would fall to the left.  The rooms near the bottom would be intact (but sideways!), with breaks where the terrain contours required, but everything near the top would be smashed into individual stones.

[G-Flex]

Also, how much of the change is just semantics?  I became happier when I started thinking of "1 granite earring" as "1 (freaking huge pile of) granite earring(s)", and "1 seed" as "1 (big ole sack of) seeds".  Like, if a block made 100 earrings, their value would have to scaled down, or else they become a super-tradegood.  Scaled down by, say 100 - then what exactly does the change achieve?

The problem is that sometimes you want to keep track of multiple objects. For instance, you can't really interpret an "earring" as a "pile of earrings" when only one dwarf can wear it on only one ear, and this will become more and more true as unique identities for items become more important (ownership, unique properties of items, magical items, people becoming attached to and recognizing them, etc.). For something like seeds, it can matter a bit less, but still might matter (what if you want to leave a trail of seeds behind you in the wilderness to mark your path?).