Print

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

[Stove]

Fortress mode and adventure mode work on two very different timescales, which as Toady has discussed in the Talks, creates some weird anomalies.

The time scale in adventure mode is pretty normal and not particularly problematic.

In Fortress mode, things happen on two time scales simultaneously, which is why it is problematic.

See this article to understand how time works: http://df.magmawiki.com/index.php/Time

Certain things are sped up:
The passage of time: It's 72 times faster than the timescale of adventure mode. This is so that the calendar doesn't pass at an unreasonably slow pace for the player.
The completion of most jobs: They seem to be completed relative to the passage of time, for the most part.


Other things happen in "realtime", or rather, on the same apparent time-scale as Adventure mode:
Movement of creatures
Physics (falling stuff, the flow of liquids)
Combat
Hauling
Mechanical triggers

This causes Toady One and Threetoe some difficult design decisions, because time is so anomalous and inconsistent in Fortress mode.

So, what if "Fortress Time" is separated into two different speeds?

In addition to pausing and stepwise time progression (with the period key), you'd have a "realtime" mode and a "fast" mode, and the ability to switch easily between them.

In realtime mode, time passes as it does in Adventure mode. The things I listed under "realtime" above would be unchanged in this mode. It would also take a long time for seasons to change, and tasks that realistically would require a lot of time to complete would occupy your dwarves for a longer period of time. (Mining, making things, etc.)

In fast mode, the things listed under "sped up" above would be unchanged. Time passes quickly, seasons change at the speed you're used to.
The difference from current "fortress-time" is that movement and physics must be sped up. Dwarves zip all over the place rapidly. This is the problematic part of this suggestion - it would require a reliable method to simulate something that is already processor-intensive happening much faster. I'm not sure this is even possible for fluid physics.

But I could be wrong, so I'll continue to explore the idea:

Hauling tasks would be less of a drain on the fortress, since they would be completed much faster relative to other jobs. In designing a fortress, you would not have to worry as much about distances.

Eating and drinking would take up less time, and also be less of a drain on the fortress. This means dwarves can eat and drink more frequently, and consume food at a more realistic rate.
As well, characters would be able to have a more realistic sleep pattern.

Something which should be addressed regardless of whether this suggestion is considered is that the relative length of time that certain tasks take to complete should be more carefully considered regardless of skill. For example, carving a large pot out of stone should probably take a lot longer than making one out of clay and firing it in a kiln. Some tasks may even take several days to complete--in which case, it should be possible for it to be completed gradually in multiple sessions. I can already see some of this in jobs such as mining, where a wall can be partly mined, with a faded appearance, and finished later.

In response to certain events, such as ambushes or combat, the game should be forced into realtime mode until combat is resolved, so that hostile encounters won't spiral rapidly out of the player's control.


This also has implications for adventure mode. If the duration of jobs is made more realistic, then it would be rather awkward to make such actions a single-turn event. Perhaps, when performing a long-duration job in adventure mode, it would actually switch to realtime or fast mode until the job is complete.


So basically, using a gameplay mechanic with precedence in many other games, all of the temporal anomalies resulting from the weird timescale of fortress mode can be solved completely, and the only hindrance to this solution (from what I can tell) is coming up with a way to rapidly simulate or generalise creature movement and fluid physics.

[NW_Kohaku]

You're not doing much to sell the idea by putting that it might be unimplementable in the title 

Anyway, I remember being in a few conversations about similar ideas, especially with Silverionmox in this thread about how breaks and sieges are handled.

What you're basically suggesting here, however, is something that probably isn't really possible.  Even if you make less weather or temperature checks to speed up the game, pathfinding and fluids are the things that take up the most time, and are the prime reason why you aren't getting 100 FPS at all times right now.  Simply running the game as fast as possible is the way that the adventurer mode way of handling sleeping works... and it does't work so well.

[Stove]

The only way I could see this idea working is:
1. If creature movement could be generalised, with movement over many tiles taking place immediately once a path is found. The problem here is accounting for traffic jams in high-traffic areas, which slows down movement in a way that is hard to predict.
2. If the physics of liquid is overhauled. I have actually been considering an idea in my head based on something you posted in another thread which, if it works, might actually solve this problem. It would treat any area of water within a single layer as an object with a total volume of water, instead of fiddling with the volume of each tile individually. The depth of a tile in this system would be displayed as the same number among every tile in the area (which is just total volume of water / total capacity of tiles * 7, rounded) . I haven't yet determined how feasible this model of fluid physics actually is.

[Granite26]

The alternative is to just move everything to realtime, make jobs take a long time to finish, sleep more/longer, and all sorts of other things to bring dwarves out of circulation (I.E. not pathfinding or thinking).  Take out animal loads (I.E. put them in pastures).  Then you've got the spare CPU to run the simulation faster.  Perceived game time might slow down 50%, but them everything gels and makes sense.

[Askot Bokbondeler]

one could abstract the dwarves movement when in fast time, the game would just check if a place was reachable and randomly teleport a dwarf to it every time a job was queued. on one hand the game would be reduced to looking at numbers going up and down between sieges, on the other hand, this could be an effective way to increase fps...

[Granite26]

Fast forward button is a bad, bad idea.  You want your simulation to run at close to the maximum speed whenever possible.  Otherwise, you COULD be spending more CPU cycles to make the game more awesome, but you aren't, because you're running too slow.

Alternately you could simulate with less detail at higher speeds but that's a clear non-starter, you wind up with quantum effects (things work different at different speeds).

See, I think players expect to do a certain amount of managing per minute of gameplay.  If you slow down the timescale too much, dwarves start taking a lot longer to mine out each wall, and that's okay...but it stops being a game.  Let's say an adept miner takes one workday to mine out ten wall sections, or an adept mason takes one workday to build ten wall sections.  Maybe one full day takes one minute.  In the early game, would you be happy seeing your adept miner take a full ten minutes just to dig out your starting bedrooms?  Still, 10 tiles a day would mean he could mine out 3650 tiles a year.  That's more than a third of a 2x2 embark zone!  You could mine out ALL the space under a 2x2 embark range in just under 40 dwarf labor years...Considering we're not even talking legendaries, that's pretty fast.

At the same time, if one full day is one minute...That's 2.5 seconds per game hour.  One second is 24 game-minutes!  Your dwarves will be BOOKING it around the fortress.  NYOW.  Superdwarf!

So for this hypothetical time scale of '1 minute = 1 game day' and '10 mined tiles = 1 game day', I think I just established that dwarves will run too fast (for the user), that gameplay will proceed too slow (for the user), and that the dwarves might actually be working too fast (for logic's sake).  If you tweak the numbers in ANY direction, it gets even worse.

[NW_Kohaku]

Fast mode would have to be very fast to make up for a timescale factor of 72... 

Even with 72 times normal speed, some paths take 200 tiles to cross from one end of the fortress to another, and that means it should take at least three normal dwarf turns, which are 11 frames apiece, so you're talking about 30 or so frames for a dwarf to move, not an instant teleport.

I somehow doubt that Toady is very interested in so heavily abstracting his heavily detailed system that we just have dwarves teleport to save on pathfinding time, and I'm not sure I'd like it, either.

[NW_Kohaku]

Well, I would have to argue with this one point:

If you tweak the numbers in ANY direction, it gets even worse.

I think an absolute statement that says "this scale is completely perfect, and you can't alter it at all" is going too far, but it is worth realizing that the current timescale was put in to achieve multiple goals at once, and that we can't forget that we need to satisfy all those goals at the same time.

[Stove]

Alternately you could simulate with less detail at higher speeds but that's a clear non-starter, you wind up with quantum effects (things work different at different speeds).

The important question to ask here is: Are these quantum effects more undesirable than the temporal hodge-podge we currently have? We already have things working differently at the world-generation timescale than adventure mode and fortress mode timescales.

Fast mode would have to be very fast to make up for a timescale factor of 72... 

Even with 72 times normal speed, some paths take 200 tiles to cross from one end of the fortress to another, and that means it should take at least three normal dwarf turns, which are 11 frames apiece, so you're talking about 30 or so frames for a dwarf to move, not an instant teleport.

This is what I was thinking, and what I meant by dwarves zipping all over the place rapidly.  Problems still arise here: How do you adjust for the movement delays of a narrow, congested hallway? What if a dwarf should be able to travel back and forth between point A and B repeatedly within one frame of fast mode? (For example, hauling a bunch of items to a stockpile only 4 tiles away.)

I somehow doubt that Toady is very interested in so heavily abstracting his heavily detailed system that we just have dwarves teleport to save on pathfinding time, and I'm not sure I'd like it, either.

It's only the processor-intensive aspects that would need to be abstracted, really. What aspect of it would you not like?

[NW_Kohaku]

The important question to ask here is: Are these quantum effects more undesirable than the temporal hodge-podge we currently have? We already have things working differently at the world-generation timescale than adventure mode and fortress mode timescales.

...

It's only the processor-intensive aspects that would need to be abstracted, really. What aspect of it would you not like?

Actually, I have to ask if the "temporal-hodge-podge" is actually undesirable at all? 

I certainly desire a "bullet time button" a lot less than a necessarily unrealistic timescale.

[Stove]

Actually, I have to ask if the "temporal-hodge-podge" is actually undesirable at all? 

I certainly desire a "bullet time button" a lot less than a necessarily unrealistic timescale.

Of course it is. It puts the fortress into a bizarre timescale that's completely inconsistent with everything happening outside the fortress. As Toady said in the talk, it can take several days just for a caravan to reach the trade depot once it has entered the embark region. Maintaining a balance between fortress mode timescale and everything else is very problematic, and the more the fortress actually interacts with the outside world, the more problematic it becomes.

You already have a bullet time button, of course. It's the period key.

As I said earlier, there is precedent for fast mode in many other games. It's an intuitive gameplay device that works quite well in those games I've encountered it in. Just to name a few: Total War (I think all the games have this in battle mode), X-Com, Uplink

[Granite26]

click that comment by Sowelu and read the discussion.

[NW_Kohaku]

You already have a bullet time button, of course. It's the period key.

As I said earlier, there is precedent for fast mode in many other games. It's an intuitive gameplay device that works quite well in those games I've encountered it in. Just to name a few: Total War (I think all the games have this in battle mode), X-Com, Uplink

This is different, Total War just speeds everything in the game up because the game normally does not run at the maximum possible speed that the CPU is capable of handling.  Speeding up the game in that case simply means making everything run in the exact same way that it would run otherwise, but with a lesser delay to give the player chances to react.  Total War does everything that it would do in regular speed when it runs at triple speed.

What you are talking about is radically altering the timescale of everything DF runs upon, and in order to do so, breaking and abstracting multiple key features of the game. 

Of course it is. It puts the fortress into a bizarre timescale that's completely inconsistent with everything happening outside the fortress. As Toady said in the talk, it can take several days just for a caravan to reach the trade depot once it has entered the embark region. Maintaining a balance between fortress mode timescale and everything else is very problematic, and the more the fortress actually interacts with the outside world, the more problematic it becomes.

I still don't see this as being worth such a radical change in the game that would require abstracting out a huge number of game functions. 

The game simply needs to be unrealistic in some ways simply to function as a game.  It's unrealistic for us, as the supposed combined fortress beurocracy, to immediately know the location of every single creature and item in the entire fort, or for dwarves to always know exactly where they are going, or what jobs are necessary, but it's just plain necessary for these things to happen in order for the game to even work as a game at all.

So again, what are we really gaining for all this trouble that makes it worth even attempting?


Semi-edit: Sorry, Granite, I'll do so, now.

[NW_Kohaku]

Oh, and as a minor side-note, the period button thing we have now... I don't know about you, but I don't ever really use it.  I think I only really use it when dealing with trying to see experiments with how long it takes water to flood certain passages or the like.

If one game speed worked at 72 times the speed of another gamespeed, and was the only way to actually get the game moving at a rate that was even playable, then why would you ever want to play anything at the so-called "normal" speed at all?

[Askot Bokbondeler]

when being besieged by goblins and managing your defences