Print

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

[pkrums]

In my opinion, Dwarf Fortress is the greatest game ever made. However, if you want to play with 200 dwarves and all of the features, the speed of the game is almost so slow as to make it not enjoyable. Keep in mind, I would like to play out a fortress for multiple GENERATIONS of dwarves, which wouldn't be too hard with the starting speeds, but as the number of interactions increases exponentially (?), it's simply not possible. Toady's code is not public domain, but perhaps letting users specify memory and CPU restrictions and investigating your data structures could yield improvements. I have a 2.2 GHz Intel core i7 processor (pretty basic), and DF seems to be maxing out the processor instead of the memory. Perhaps some "fuzzy" dwarf interactions could lead to an improvement.

Oh, and if this is already in discussion somewhere, please redirect me...

Specifically, I was thinking of a limit on the depth of calculations. Say, 3 calculations before a decision is made.

Or, here's a thought, maybe a time-step setting, where you can reduce your control over your fortress by less than retiring it while speeding up the game. You could have regular time steps at the beginning, and then lengthen them and perhaps control the kinds of announcements that pause the game.

[Lubricus]

The game is impressive fast I think it should be balanced for smaller fortresses instead. I don't see why it's better with 200 dwarfs than 40. The game should'd come with a flood of immigrants and the crafting should work with fewer dwarfs. I also think there is a little to much depth in the simulation of f.ex. dirt and contamination's that is just to CPU heavy.
Normal games try to fool you and look like more is going on than is true, dwarf fortress is the other way it's way more going on than most of the players have found out.

[pkrums]

Cause with 200 dwarves you can occupy half of them with researching the secrets of life and death..........

[Bradders]

Some of the biggest offenders for FPS-death are:

• non-caged non-restrained pathing pets (particularly large drops using pet-forbidden doors), pathing errors stemming from narrow corridors, and too-wide passages offering too many options for packs of working dorfs
• temperature calculations (as evidenced by the New Magma Pump Stack - adding an extra block of space on both sides of a single stack level's magma reservoir making a 'T', to every level, keeps magma/heat on every level and doesn't force the game to recalculate the temperature for every block adjacent to the stack every tick like non-expanded stacks do)
• owned, scattered, decaying items that have to be 'aged' and register every frame, also contaminants/blood
• moving fluids, or worse, mist, or even worse, a misty waterfall that you can't turn off.

You're definitely correct about DF being proc-locked, though I understand the 64 bit update is supposed to greatly ease things in this regard - I haven't yet updated past 43.03 though.  Some degree of fuzzy interactions would be a godsend for chunking some of these overly-frequently-checked tasks down to a reasonable amount of proc load time, especially on things that are checked constantly but affected infrequently, like clothing decay - clothes only go from normal to xItemx to xXItemXx to XXItemXX, but the integer value for their decay is kept and checked on every tick, for every article of clothing, for every dorf.

[lethosor]

clothes only go from normal to xItemx to xXItemXx to XXItemXX, but the integer value for their decay is kept and checked on every tick, for every article of clothing, for every dorf.

Where'd you hear that? I don't know about this one off the top of my head, but I know that a lot of periodic updates are run at larger intervals (every 20, 100, 500, etc. ticks).

Also, the 64-bit build is a little faster, but at most 10-20%.

[pkrums]

You know, if DF became multi-threaded, programming wouldn't necessarily have to worry about interactions between the threads. Because DF is a game with a steep learning curve that requires users to learn many features, you could have a quick manual about how threads interact, and then do something simple like separate each map into 4 quarters. Users could worry about the interactions as long as they are simple enough.

[Bumber]

You know, if DF became multi-threaded, programming wouldn't necessarily have to worry about interactions between the threads. Because DF is a game with a steep learning curve that requires users to learn many features, you could have a quick manual about how threads interact, and then do something simple like separate each map into 4 quarters. Users could worry about the interactions as long as they are simple enough.

What happens if one unit is chasing another and it crosses the boundary? Not pretty.

[anewaname]

Perhaps some "fuzzy" dwarf interactions could lead to an improvement.

The less-fuzzy dwarf and object interactions are the valuable, beautiful, and rare things, that DF brings to a gaming world that is... limited in those things.

[MrWiggles]

You know, if DF became multi-threaded, programming wouldn't necessarily have to worry about interactions between the threads. Because DF is a game with a steep learning curve that requires users to learn many features, you could have a quick manual about how threads interact, and then do something simple like separate each map into 4 quarters. Users could worry about the interactions as long as they are simple enough.

ToadyOne has said a few times that Multithreading wouldnt really improve the game performance much.

And the learning cliff in DF is a bit overstated. Its fairly easy to learn. The UI fights you a bit, but the basic things to learn arent a lot. The problem is that the game doesnt tell you what the bare minimum of things you need.