Print

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

[Andeerz]

So, a major problem in DF is the discrepancy between Adventure Mode and Dwarf Mode time scales.  This discrepancy makes implementation of certain features in the game, both existing and planned, problematic, since they need to accommodate for a 72 fold difference in time speed between modes. 

I will get to my suggestion on how to fix this, but, before I do, there are two threads this suggestion is based off of:

Rectification of timescale across modes

and

Dwarf Mode Real Time Game Speed w/ Skipping Forward in Time

Basically, I want to present a suggestion of how to accomplish essentially what was stated in the first linked thread.  A lot of these ideas were discussed in the second linked thread.

The overall suggestion is to do the following:

1.  Make Dwarf Mode have two speeds it can run at that can be toggled at the players will.  These speeds would be "slow" (same as Adventure Mode speed which is 1 tick = ~1 game second) and "fast" (same as current Dwarf Mode speed which is 1 tick = ~1.2 game minutes). 

2.  Increase movement speeds in Dwarf Mode to those of Adventure Mode.

Spoiler: Details and Problems (click to show/hide)

DETAILS: 
In "fast" speed, movement would require some abstraction, as I think it would not be possible to have movement be calculated the same way as in "slow" speed.  Basically, every once in a while, the game should cache possible paths between areas in the fort using an algorithm as detailed here.  It could be calculated once a game-month or something.  Whenever the game is in "fast" mode and an entity needs to move, it will set up a path to where it needs to go using one of the cached paths.  Every tick, the entity would advance along the path, having moved a distance equal to the speed of the entity times the time of the tick (~1.2 game minutes).  Every tick, the traveling entity could check to see if its path has been interrupted or impeded (perhaps using the same calculations currently used for determining this in the game).  Frizzil should chime in here.  It would be nice to spend a chunk of this thread discussing implementation of this and how this would affect performance. 

PROBLEMS: 
A very big problem I could foresee with this is that it might be impossible to just have the path caching take place only every once in a while.  The map is dynamic with dwarves mining things out and building things all the time.  In order for things to work without exploit, wouldn't the game need to make calculations every time something is built or mined out to see if it interrupts any cached paths?  If so, would this be processor intensive enough that it would break the game? 

Also, another equally big problem: for short distances that would take less than 1.2 game-minutes to travel by an entity, what should the game do in "fast" time?  Like, for example, say a dwarf needs to haul some stuff a few tiles away that would only take 15 ticks in "slow" time.  It would take only .21 ticks to accomplish the same task in "fast" time.  Would the game be able to take this into account and allow the dwarf to be able to do other things during the same tick?

3.  Increase combat speeds in Dwarf Mode to that of Adventure Mode

Spoiler: Details and Problems (click to show/hide)

DETAILS:
Any time combat would take place in Dwarf Mode, the game would automatically slow to "slow" speed if not already at that speed and continue with combat like it happens in Adventure Mode.  As combat is something that shouldn't take that long (only a few game minutes, or maybe an hour or two for a huge skirmish!), this wouldn't be problematic, I don't think.

PROBLEMS:
I don't really see any problems with this.

4.  Have hunger/thirst/sleep requirements the same in Dwarf Mode as they are in Adventure Mode.

Spoiler: Details and Problems (click to show/hide)

DETAILS:
How this would affect gameplay would be contingent on how the pathing stuff in #2 would work.  I do not at all see this impacting things negatively at all.  Time spent eating and sleeping per day would end up taking the same proportion of time as it does now in the game.

PROBLEMS:
The only problem I see is that assuming a dwarf will eat 3 times a day, sleep once a day, and need to walk to and from work at least once a day, that's 10 pathfinding calculations at the very least per game-day per dwarf.  As things are right now, a dwarf maybe only needs to do these same things a fraction of that amount in the same amount of game-time... So this could push FPS to abysmally low levels at a much earlier stage of a fort's maturity.  But that is all contingent on how #2 is handled.

5.  Change the amount of food/water units harvested when harvesting a tile of plants/butchering an animal/getting water from a well to accommodate #4.

Spoiler: Details and Problems (click to show/hide)

DETAILS:
I would do this by increasing the yield of food units per animal, increasing yield of water/booze/whatever liquid for the purposes of consumption at least.  I would also either increase the amount of food units yielded per plant, or just keep it as-is.  The latter would require bigger farms (on the order of what is seen in human settlements in the game currently) to support a fort, which I am totally cool with.  Either way, though, there would probably need to be some balancing and tweaking of food yield per plant to get things reasonable, which wouldn't be hard to do.

PROBLEMS:
Increased number of items on the map at a given time might happen, which might hurt FPS depending on how things are handled.  If how items and stuff are handled is kept as they are now in the game, this could be a problem, no?

6.  Change the Dwarf Mode fluid simulation to accommodate #1 and #2

Spoiler: Details and Problems (click to show/hide)

DETAILS:
My suggestion could still work with keeping fluid mechanics the same as they are now in Dwarf Mode... but it would be silly looking. 
I really haven't thought this part of the suggestion out.  I am completely open to suggestions here.

PROBLEMS:
No idea...

Overall, I think my suggestion is plausible and something that should be seriously considered as a solution to a rather annoying thorn in the game's side.

Let's discuss this!!!  Are there any problems I am failing to address?  Anything not clear?  I plan to update this post as more problems/solutions are brought to fore.  Discussion of the problems in #2 would be much appreciated...

EDIT: Ok... after some discussion of the problems in #2, it appears that it is not possible to implement my suggestion without loss of detail in movement during "dwarf-mode" time.  Depending on how much detail is lost, this could make my suggestion something that could make toggling between speeds (adventure-mode time and dwarf-mode time) alter how the game behaves enough to open up exploits and essentially break the game.  :/  I don't feel like there is any way to know other than just trying it out and doing some controlled experiments.

EDIT:  I think my suggestion is impossible to effectively implement.  See here.

[GreatWyrmGold]

I hope you won't mind if I make suggestions of problems for some of the points?
#3, for instance--a good problem is the fact that "combat" is hard to define. After all, a minecart bumping a cat or a dwarf falling a z-level involves combat calculations.
For #4, you left out drinking. Since dwarves currently eat three times in a month and a half, and drink six times during that time, presumably there would need to be three drinks at the three meals, a nightcap, drinking first thing, and probably one other drink, EVERY DAY. That means that (assuming we cut it to five drinks a day) the dwarf is pathing from bed to drink stockpile, from drink stockpile to food, from food to dining room, then work pathfinding, then to the drink stockpile and food stockpile in some order to grab a meal and drink, then to the dining hall, then back to work, then repeat that for dinner, then path for work or relaxation, then to the drink stockpile, then to bed, and don't forget there's usually at least a couple pathfinding routines per job. Assuming one two-path job per work period and just pathing to the meeting hall after dinner, that's around 15 pathfinding calculations per dwarf per day. And that is, I believe, the conservative estimate. In other words, if food's consumed at three a day and drink at a roughly proportionate rate...there's a lot of work to be done.
For #5, I'm not sure if larger stacks affects FPS, but having the stacks splint more (breaking one off a stack per dwarf, more or less, three times a day) would. I guess the distinction is more of a technical difference than one that really matters, but I'm a semantic.
Second #5: I recall reading that, in order to stop the perpetual motion generator issue, either around 100 waterwheels would need to be used per pump, or the water would need to flow so slowly that it would evaporate before the next bit was pumped. In either case, it seems to me that increasing the rate of fluid flow would probably worsen the PMG problem. This is speaking from one art hearsay and two parts wild guess, so you should say that this COULD happen. Also, floods would be harder to survive, but since you're living in a mine that's pretty realistic so that might not count. Except with magma, you should probably be able to outrun that.

[QbertEnhanced]

Well even if it slowed down based on false alarms, how often does that really actually happen?
I only get those kind of bogus reports every 15 minutes at the most. So I don't really see that being a huge problem.
The issue with drinking and eating, it'd be a pain in terms of path finding. But it could also have some good gameplay effects. Maybe something along the line of allowing civs to carry backpacks to take their lunches and a couple drinks on the go or something. And more spread out eating areas, maybe food stored in rooms (though that might have to wait for the economy update).

[Andeerz]

Good points!  I'm glad you pointed those out.

For #3... I guess those kinds of instances could count as combat.  Basically, anytime an entity needs to make some sort of damage calculation.  But in "fast" time, if it's handled the way I describe, I believe the chances of such accidents would be decreased maybe... which bothers me a little since it could be viewed as an exploit.  But I could imagine that not being an exploit if dwarfs in the future become smarter about avoiding things anyway.  Hmmm...  And with these instances being handled as combat, I wonder how frequently they would occur and if they would happen frequently enough to interrupt gameplay to an annoying extent.

For #4... so, instead of 10 pathfinding calculations, it would be somewhere around 20 per day per dwarf, worst case would be maybe 30.  That's quite a lot.  Hmmm...

For the second #5 thing (which I renamed #6)... you also raise an interesting and ridiculously big problem that might even merit its own thread altogether.  I don't know enough about how the game is programmed and what calculations it makes for physics crap, but I have a feeling that what might lead towards a solution to this issue is a strict definition of tile size, mass, and other physical parameters that right now are rather ambiguous.  Then real physics laws could (hopefully) be effectively applied and things like conservation of energy and mass would arise naturally.  Easier said than done...

As for fluid simulations and game speed... perhaps an abstracted system could be worked out for fortress mode in "fast" time.  I wonder if there are threads dedicated to that that might have some potential solutions?  Would increasing fluid flow alone (ignoring the PMG problem) break the game somehow???  Would it lead to potentially similar problems I mentioned in #2 (the short distance stuff)?  I need to look around more to see if this was discussed before... 

Anyway, I would LOVE for Toady to chime in on this sometime, though I am totally understanding of the fact that he probably has other things to do that are much more pressing.

EDIT:  And, Qbert, yeah.  I have the same thoughts.

[GreatWyrmGold]

Well even if it slowed down based on false alarms, how often does that really actually happen?

A lot, if you're unlucky. As an example, there's a lot of times when some stupid puppy or duck of both get hit by a minecart in my one fortress. And construction accidents, often generating combat reports, are fairly common.

The issue with drinking and eating, it'd be a pain in terms of path finding. But it could also have some good gameplay effects. Maybe something along the line of allowing civs to carry backpacks to take their lunches and a couple drinks on the go or something. And more spread out eating areas, maybe food stored in rooms (though that might have to wait for the economy update).

If dwarves carried food with them, that would invalidate the point of dining rooms. Drink makes sense, though; instead of grabbing a barrel and drinking straight from that, they'd pause as they work or eat to swig some dwarven wine.

[QbertEnhanced]

I don't mean they'd eat EVERY meal on the go, I just mean that it'd be neat if they grabbed breakfast at home before heading to work (or at least some dwarves would do so). Or could eat lunch on the job if they were being sent far from the nearest dining room (miners come to mind). But would almost always have dinner in the dining hall.
It'd make for a bit more autonomy imo.

[GreatWyrmGold]

That's more reasonable, but unless I'm in a big rush I always eat at some kind of dining room, so presumably dwarves would prefer that over eating bites of plump helmet between swings of a pick or what-have-you.

[Silverionmox]

Packing lunch for work makes sense though, in particular for miners, woodcutters, and other professions that operate far from the comforts of the dining room.

[GreatWyrmGold]

Maybe there should be some sort of order for dwarves of a specific profession and/or specific dwarves to take their food with them for lunch?

[QbertEnhanced]

Maybe there should be some sort of order for dwarves of a specific profession and/or specific dwarves to take their food with them for lunch?

That would probably be best. And would make for a good suggestion in another thread even I think.
But as to the timescale and fluids, I wonder how it would affect it. Maybe if you calculated fluid transfer in terms of room size in fast mode?
As in, 5 tiles of fluid will fill up to 1/5 full in a 25 tile room. Something along those lines might expedite some calculations.
Still I think this timescale suggestion is probably the most workable, and would help bring together the various timescales.

[knutor]

Implement autoexplore, keybind z, in adventure mode, like Tome4 has.  Crank it to max, autopausing for dialog and combat.  Too much time is lost in adventure mode, just getting around.  If they are not meant to be played at the same time, I cannot see the purpose of a time synchronization. 

Please explain, the reason for time synchronization?  Knutor

[QbertEnhanced]

Well for one, time synchronization would help get rid of strange anomalies in the current implementation. For example it can take a good month for your militia to get armed and move where they need to be. Or a week to walk across the fortress. It also currently can take days for water to flow and fill a small area, and combat can also take a week or more to resolve, particularly between skilled combatants.
Going forward, there would also be a host of issues with the x72 time we have in Dwarf mode. For example, if you sent an army out to travel the world map, they'd take a month to get to the edge of YOUR map, but then the rest of their (say 4 month journey) would go buy in a flash in fortress time.
Some benefits of the getting the timescales together would be things like proper dwarven schedules (ie breakfast, lunch, dinner, free time) every day, day/night cycles, more realistic crafting times (proportionate to travel times at least) and basically all the other things that would come from having in-game representation closer match adventurer mode.

[knutor]

Well for one, time synchronization would help get rid of strange anomalies in the current implementation. For example it can take a good month for your militia to get armed and move where they need to be. Or a week to walk across the fortress. It also currently can take days for water to flow and fill a small area, and combat can also take a week or more to resolve, particularly between skilled combatants.
Going forward, there would also be a host of issues with the x72 time we have in Dwarf mode. For example, if you sent an army out to travel the world map, they'd take a month to get to the edge of YOUR map, but then the rest of their (say 4 month journey) would go buy by in a flash in fortress time.
Some benefits of the getting the timescales together would be things like proper dwarven schedules (ie breakfast, lunch, dinner, free time) every day, day/night cycles, more realistic crafting times (proportionate to travel times at least) and basically all the other things that would come from having in-game representation closer match adventurer mode.

Buy should be by.  Fixed it for ya, Q. 

The scale of time in rogue mode serves as a motivating purpose to the player to perform necessary rogue play actions.  There is no player necessities to facilitate in fortress play, so a precise scale of time is an unnecessary application.  The AI runs the show in fortress play. 

Water filling a basin is not dependent upon time, alone.  Condensation.  Isn't it?  A point can be argued against weather.  And weather that lasts months and months is indeed destructive.  So much so, it leaves the game world lacking in vividly modifiable scope. 

I certainly would not want fortress mode dorf AI requiring that many meals in a day, they'd eat through the stockpile, and the vermin population in no time at all. 

Parsing a night cycle, not sure how rogue play does it, but if it hampers my birds eye view, I'd just disable it or find a way around it, or skip playing the game.  I can barely see through the miasma of evil regions, as it stands.  As for how night cycles might relate to CSI:Armok, doesn't affect me, worlds I make have Vampire curses set to 0.  I'm just not that good at DF, to play with them.

I'd like to see a little belt tightening with time frames too, just like you Q, but at a justifiable cost to playability.  Not changes for the shear sake of changes.  Reality at the cost of playability, doesn't have a good exchange rate.  Sincerely, Knutor

[Rakushun]

I wouldn't waste my time arguing with knutor, he doesn't even like Toady's ideas for the game.

[QbertEnhanced]

In regards to your bit about meals, he current abstraction is that each meal actually represents several. So yields would have to be balanced to meet the new timescale. If you butcher an animal, and get 1 month of meat currently, then in the new timescale you'd get the same month's worth of meat, just split into many more meals. It'd allow for more detailed amounts.