Print

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

[Neonivek]

Well the squares are more of a vague representation of space based around concept rather then raw physics.

Which means that Dwarf Fortress does use different laws of physics then the real world.

[Duke 2.0]

Humans can drown in five feet of water?

Megabeasts can drown in five feet of water?

Is there a goal of re-working sizes in the Dev Notes?

[Red Jackard]

Prefer mine since the numbers are rounded off.  Besides, it's only for rough comparisons.  

[ June 05, 2008: Message edited by: Red Jackard ]

[Toady One]

Kobolds just dig themselves a medium size cave.  I didn't have them expand it because they get popcapped pretty early on, but I could make them do it dynamically...  okay, there.  They'll expand their cave up to a number depending on their population size, and they'll do it in amounts each year based on the number of miners they have.  The dwarf fortresses, which I haven't fleshed out at all, should be handled in the same way, but I'm not there yet.  Humans and goblins don't use their miners either...  hardly any of the professions are used, because we don't have a caravan arc, again.

It's not really family trees...  it would be great to have a visualization of the trees (Bloat51), but right now it just lists their parents, children, deities, things like that.

Yeah, there are lots of small UI tweaks that would help a bit, but I don't think the ones you mentioned would significantly expand the fanbase when compared with the glaring omissions.  Looking past the graphics and the keyboard input are things that a lot of people aren't going to do.  As for retaining players, yeah, some tweaks would help there, though I don't think it's the only thing that breaks people out of the game.  I need to balance several concerns -- (1) the internals of current screens all being gutted for a new format, (2) handling current small UI requests, and (3) not wanting to do small UI requests because ongoing core changes make many UI choices premature.  The gutting in (1) can help mitigate (3), by making the interface code more resilient, although it cannot alleviate the problem completely.  (1) and (3) both hamper my enthusiasm for (2), so my plan was to just jump in on (1) as soon as I get my army stuff done.  Even that will still feel like I'm doing things in the wrong order, since many interface decisions can't be made properly without a more complete game, and worse, (2) is the only thing that makes people happy in the short term.

Dwarf-made holes don't refill because I don't have a good way of detecting what should fill and what shouldn't.  It's not impossible -- as Zemat said, it would be vaguely like the cave-in-code, or something.  It can't just put water everywhere without causing a CPU crisis -- I tried this, and we're not ready for it yet (it also looks silly without more water soaking into the ground initially, at least in biomes with permeable soil).  Ponds/rivers don't have to have water to refill.  Each raindrop event adds 1 unit of water to any pond or river square that has less than 7 units (and yeah, 0-7 units comes from the 3 bits available, allowing that to be modded might be an optimization issue, at least with my scant programming knowledge, since the flow code would have to respect/access any new init variables).  Outdoor 1-deep water will no longer evaporate if the weather isn't clear, so rainfall should ensure some filling.  It's a little goofy that only the ponds/rivers can refill, but that's how it'll be until something CPU-safe arises, and yeah, you should be able to dig tunnels from the dry ponds and so on to collect water in a underwater pool or however you'd like to handle it.

Right now it prefers to pull the starting 7 dwarves from a living civilization.  If they are all dead, I think it picks one of the dead ones at random (or the first one, I don't remember).  It doesn't do anything special, like generate a new civ for the player or anything like that.

I'm not really keen on defining tile sizes.  It opens cans of worms throughout the code, all over the place, and I think the gain is slight in comparison.

[Aqizzar]

Space is most definately abstract if an elephant, a colossus, a table, a floodgate, and an infinite supply of boulders can all exist in one space simultaniously.  Water levels are just abstract denotations of given heights (ankle deep, waist deep, chest deep, more than head high, and so forth if I remember).

Though I do love the idea that when my primative dwarves go to the river they're gulping down 40 gallons of water in one go.

[EDIT]Didn't mean to post that as Toady was weighing in on sizes.

[ June 05, 2008: Message edited by: Aqizzar ]

[Techhead]

Tiles are simple 1 dwameter (short for dwarf-meter) cubed.
Each tile holds 7 dwaliters. One dwaliter can be subdivided into 10 aleliter, because dwarves love comparing things to alcohol. You are already familiar with dwagram and dwabucks, the base units of dwarven weight and currency.
All the units have silly sounding names because the original dwarven names do not translate well.

Viola, can of worms is now fixed.

[Frobozz]

quote:Originally posted by Toady One:
<STRONG>(and yeah, 0-7 units comes from the 3 bits available, allowing that to be modded might be an optimization issue, at least with my scant programming knowledge, since the flow code would have to respect/access any new init variables)</STRONG>

For a minute there I was under the impression you were using a bitfield/storing multiple chunks of data in one variable. But I figure you aren't crazy enough to use something that (1) is probably slower than just using an individual variable for each chunk of data and (2) tends to make porting code to an opposite endian device a pain (not like this really applies anymore).   :p

[ June 05, 2008: Message edited by: Frobozz ]

[Toady One]

No, fluids levels are indeed 3 bits in a 4 byte variable that holds various tile flags.  (1) is certainly true though (2) wasn't an issue with the PPC port and if it were a problem all of the bit-flags everywhere wouldn't have worked to begin with.  However, I currently think (1) is outweighed by the memory cost of assigning extra unneeded bits to a very large play area.  I'm only going to be adding more map variables, so I tend to conserve space when working with the tiles.  If I spend 8+ bits for fluid levels, that'll probably be 5+ bits I really end up wanting later.  Each tile already eats up 29 bytes (not counting block information which pushes that count up a bit).  It's not like 5 extra bits would be a disaster, but it all adds up.  If I end up wanting more resolution for the fluids later (such as 0-255 levels, or whatever, though that has its own problems), then fluid levels would get to live on their own.

I don't know very much about programming or the options that are available for these sorts of issues though, so if there's an alternative and you'd prefer to call me ignorant rather than crazy, that's fine.

[Frobozz]

quote:I currently think (1) is outweighed by the memory cost of assigning extra unneeded bits to a very large play area. I'm only going to be adding more map variables, so I tend to conserve space when working with the tiles.

I disagree with worrying about memory usage. Granted its always nice to keep memory usage low, but lets face it, any system fast enough to get a playable speed for Dwarf Fortress is bound to have a decent amount of memory. I have a habit of glancing briefly at the specs of cheap OEM PCs I run across in Walmart to memorize the average PC capabilities in use and for the most part I haven't seen a system with less than 512MB in a couple of years. The bottom-range on Dell's website is now 1GB!

Given that people tend to wear systems out pretty quickly, I'm assuming that the average barely-functioning OEM PC when DF hits 1.0 will probably have at least 1GB of memory.

 

quote:I don't know very much about programming or the options that are available for these sorts of issues though, so if there's an alternative and you'd prefer to call me ignorant rather than crazy, that's fine.

I hate calling someone ignorant. Especially someone who is self-taught and has managed to create a program of this size. I know I wouldn't want someone to call me ignorant concerning my programming because I'm mostly self-taught as well, having only taken a couple of program design courses to learn stuff I feel would have taken me a long time on my own.

[ June 06, 2008: Message edited by: Frobozz ]

[Neonivek]

On the bright side... perhaps Toady will never need to optimise Dwarf Fortress... due to how fast computer technology is advancing, 2 years from now when the game is finally finished... our computers may be able to run it easily.

[Capntastic]

I think DF will take a lot longer than two years to finish.   If it ever does get 'finished'.

[Neonivek]

Well I am refering to V1 finishing

[Toady One]

I dunno.  When I take the map dims and multiply them by 29, it always seems sort of scary, especially in a canyon that somebody criss-crosses with tunnels so that the dynamic allocation is out of the picture.  480x480x20x29 doesn't seem far-fetched....  130MB, just for the map, and if you go out of your way it can be much worse (768x768x90x29 or so?  Some people find these terrible cliffs...)  Certainly for basic play, the extra bits aren't a problem.  There's probably some nice way to switch over to the compressed method depending on the map size without making too much of a mess, but my own attempt would be tragic.

I should probably change that "the next year or two" part of dev.html.  Even this rudimentary portion of world gen/army arc has taken months and months.

[Neonivek]

quote: I should probably change that "the next year or two" part of dev.html. Even this rudimentary portion of world gen/army arc has taken months and months

Bad Joke Alert

So maybe you should change it to: "In the next indeterminable unit of time measurement or two"

[SmileyMan]

Assuming that DF is written in C/C++ then using a bitfield is going to be no slower or faster than using an element of a struct/class.  Although the latter would obviously make expansion easier.

Aside from total memory size, there are also problems of getting large chunks of memory in a contiguous block, especially on 32-bit systems.  Once we get DF64   it'll all be fine.

Talking of modern hardware, a modern CPU with multiple pre-execution branches will make most programming decisions moot anyway.  Nowadays, it's considered better form to write readable/maintainable code than trying any fancy optimisation technique, because your compiler/CPU should be able to do it for you.

That's my sensible bit for the day.  Now, where's that wine barrel.