Print

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

[10ebbor10]

I do like your idea a little bit Andeerz. I think it would be an improvement over the status quo. However, to be honest, the most important part of my idea to me is real time game speed, and time skipping is just the way that it's made to work. It's the place where I'd like the abstraction to be shoved into because I feel that it's a better place for it. I also think slower time scales could be improvements, but I still think real time is the best because it avoids artificial time distortion of the game's balance, especially multiple inconsistent time distortions across different systems.

OH!  I think I'm getting messed up in what you mean by "slower" vs. "faster" and what you mean by "real-time"...  I think you and I might have the exact same goals... and I don't see how my suggestion or yours (given I understand it correctly) would retain any time distortions. 

And do you feel that my suggestion would distort game balance?

Timey wimey wibbly wobbly stuff: It's complicated.

As far as I know, you're only abstracting pathfinding, whitout actually changing anything. So no. I don't know how large the gains would be.

[Andeerz]

- Much more detail(but much is the same)

Would there be more detail necessarily?  As far as I can tell, the same stuff will be happening... timing would just be different.  Though I feel this rectification across time modes might allow for more detail in dwarf mode that might otherwise only be relegated to adventure mode...

-Would require to rework the engine twice. We're talking about a shift as big as 2D to 3D here, maybe bigger.

How so exactly?  I think I am misunderstanding the OP...

I do like the idea of just increasing the amount of thigns that happens per tick. However, there would be a limit on how much performance you can gain with this, and I'm pretty sure it will stay below 2*. (Reason: animals, fluids, doors, multitude and reassinging of jobs. If one thing changes the game has to calculate everything again, weather, temperature and then some more.)

Oh, crud... I keep forgetting about fluids.  Pewp.  This would have to be another thing that would need to be abstracted differently than it is now regardless of the suggestion... 

Also, I think increasing the amount of things that happen per tick would hurt performance before helping it.

You raise a great point though with the recalculating thing... hopefully whatever abstractions would be made would be robust enough to accomodate for (or simply abstract out) such changes that would necessitate recalculations.

[Andeerz]

Timey wimey wibbly wobbly stuff: It's complicated.

Give me a made up example!  I don't care how contrived it is.  This would help a lot in figuring out whatever weaknesses there might be in whatever suggestion.

As far as I know, you're only abstracting pathfinding, whitout actually changing anything. So no. I don't know how large the gains would be.

I am suggesting changing four other things, though:
1. hunger/thirst/sleep requirements
2. Adding a toggle between adventure-more and dwarf-mode time (1 tick = ~1 second and 1 tick = ~1.2 minutes respectively...)
3. Increasing the amount of food/water units harvested when harvesting a tile of plants/butchering an animal/getting water from a well
4. keeping entity movement speed per game-time-unit the same in dwarf mode as it is in adventure mode

Let me know if I need to make anything more clear...

[Rakushun]

I do like your idea a little bit Andeerz. I think it would be an improvement over the status quo. However, to be honest, the most important part of my idea to me is real time game speed, and time skipping is just the way that it's made to work. It's the place where I'd like the abstraction to be shoved into because I feel that it's a better place for it. I also think slower time scales could be improvements, but I still think real time is the best because it avoids artificial time distortion of the game's balance, especially multiple inconsistent time distortions across different systems.

OH!  I think I'm getting messed up in what you mean by "slower" vs. "faster" and what you mean by "real-time"...  I think you and I might have the exact same goals... and I don't see how my suggestion or yours (given I understand it correctly) would retain any time distortions. 

And do you feel that my suggestion would distort game balance?

Actually I don't think I originated the slower and faster talk. My idea is full-on extreme and there have been several compromise ideas posted by others. Mine is "1 real minute = 1 dwarf minute" + "timeskips of any length, interrupted by anything the player desires, customizable so only things the player wants to be skipped are skipped".

I think that anything less introduces a time distortion of game balance because all abstraction is necessarily distortion. Obviously this effect would increase the more time is compressed, so a "slower" mode where we can see day/night cycles and such would be less distorted than the status quo and therefore better in my opinion. The effect gets much worse, in my opinion, when anything in the game is faster or slower, relatively, than anything else. Personally, and obviously not everyone agrees with me on this, I would prefer that distortion be eliminated entirely from the game as we know it (by making the game real time) and packed away in time skips that would ideally be as little immersion-breaking as possible. It would avoid any distortion caused by multiple interoperating time scales, which is the worst offender in my opinion, and place the rest somewhere where it wouldn't interfere with the low-level detail of dwarven life that I would like to see.

-Would require to rework the engine twice. We're talking about a shift as big as 2D to 3D here, maybe bigger.

How so exactly?  I think I am misunderstanding the OP...

I don't think I'd call it reworking the engine twice, it would be replacing all current abstraction with real time values, then implementing an (I think simpler) method of more extreme abstraction, strategically placed and internally consistent. I'd say it's reworking the engine about 1.5 times, but what do I know? If anyone does, it's Toady.

[QbertEnhanced]

I think andeerz's suggestion is one of the most thought through. It'd allow you to dealwith what goes on at night, you could have the game automatically cut back to 1 tick = 1 sec. mode if, for example, a host of boogeymen came upon a lone foolhardy dwarf out of bed.
When run in fast mode, the dwarves would be teleporting all about the place, but the same overall amount of work would get done as in current timescale.
This would also avoid the discrepancies in time that are bound to come up in future arcs (as I mentioned earlier with the armies example).

Negatives of this idea, as far as I can see:
1. Could be considered less visually appealing. By taking away the abstracted time (wherein a dwarf takes a week to walk to work) we don't see dwarves move smoothly about the fortress in SPED UP mode. But, one could slow it down and allow things to move slowly to watch everything happen.
2. # of calculations per minute
If the game could store paths, and somehow efficiently check if something has changed the most efficient path, then the pathing issue could be somewhat taken care of.
This would leave (to my knowledge) weather and fluid dynamics as the big killers. In those two respects, we'd be looking at something like 72 times as many calculations per real world minute. This would need a lot of optimization to handle well.

However, I'm not one to shoot down a plan because it has challenges. I really love the idea of bringing the amount of detail present in the game into focus in dwarf mode, and I think proper day cycles, schedules and the like, will really help the game, especially further down the road. There's planned future features like taverns, armies, traders and the economy. To have this all be abstracted out would slowly snowball into something increasingly ridiculous. Dwarves would spend a solid week at the tavern, then go and spend a month picking out some new socks to buy. Making the move to a system where time in game is a constant, but with differing amounts of calculations per tick would make the whole thing stick together a lot more coherently.

[Rakushun]

However, I'm not one to shoot down a plan because it has challenges. I really love the idea of bringing the amount of detail present in the game into focus in dwarf mode, and I think proper day cycles, schedules and the like, will really help the game, especially further down the road. There's planned future features like taverns, armies, traders and the economy. To have this all be abstracted out would slowly snowball into something increasingly ridiculous. Dwarves would spend a solid week at the tavern, then go and spend a month picking out some new socks to buy. Making the move to a system where time in game is a constant, but with differing amounts of calculations per tick would make the whole thing stick together a lot more coherently.

I love this paragraph.

[Andeerz]

I do like your idea a little bit Andeerz. I think it would be an improvement over the status quo. However, to be honest, the most important part of my idea to me is real time game speed, and time skipping is just the way that it's made to work. It's the place where I'd like the abstraction to be shoved into because I feel that it's a better place for it. I also think slower time scales could be improvements, but I still think real time is the best because it avoids artificial time distortion of the game's balance, especially multiple inconsistent time distortions across different systems.

OH!  I think I'm getting messed up in what you mean by "slower" vs. "faster" and what you mean by "real-time"...  I think you and I might have the exact same goals... and I don't see how my suggestion or yours (given I understand it correctly) would retain any time distortions. 

And do you feel that my suggestion would distort game balance?

Actually I don't think I originated the slower and faster talk. My idea is full-on extreme and there have been several compromise ideas posted by others. Mine is "1 real minute = 1 dwarf minute" + "timeskips of any length, interrupted by anything the player desires, customizable so only things the player wants to be skipped are skipped".

I think that anything less introduces a time distortion of game balance because all abstraction is necessarily distortion. Obviously this effect would increase the more time is compressed, so a "slower" mode where we can see day/night cycles and such would be less distorted than the status quo and therefore better in my opinion. The effect gets much worse, in my opinion, when anything in the game is faster or slower, relatively, than anything else. Personally, and obviously not everyone agrees with me on this, I would prefer that distortion be eliminated entirely from the game as we know it (by making the game real time) and packed away in time skips that would ideally be as little immersion-breaking as possible. It would avoid any distortion caused by multiple interoperating time scales, which is the worst offender in my opinion, and place the rest somewhere where it wouldn't interfere with the low-level detail of dwarven life that I would like to see.

OH!  I get it now.  In that case, hmmmm... the big problem I see is that it MIGHT be impossible to make 1 real-time minute = 1 in-game minute because of physical limitations on how fast computers can go.  My understanding could be fundamentally wrong, but I understand that DF operates in a similar fashion to any RTS, FPS, or whatever game that has things happening in "real time"... 

Basically a game operates by performing a series of calculations in sequence.  If a game is to represent stuff happening through time, there has to be an arbitrarily defined unit of time (a tick).  A tick can represent a fraction of a second of game time (NOT real time...), a year, or whatever depending on the simulation.  For example, for an FPS, a tick could represent a fraction of a second...  In that FPS, the instant you press the fire button, the game calculates the position of the you just fired bullet during the tick you pressed the fire button (or a tick soon after) using simple Newtonian physics equations or some abstraction thereof.  After all other calculations are performed that are time dependent (like positions of other entities, countdown of a game timer or something) during that tick, the game proceeds to the next tick, where the same time-dependent calculations are repeated, and the game advances by one unit of arbitrarily defined game time (not real time).  The length of the tick in REAL time can vary depending on how many calculations need to be completed before proceeding to the next tick and how fast the computer is that is performing them.  In the case of most FPS games, there are only a relative handful of calculations that need to happen during a tick, namely bullet positions (unless they are ray-traced, instantly hitting bullets or something), entity positions, a round timer if applicable, etc. if we are being simplistic here... In the case of DF, you probably have many orders of magnitude more calculations to perform in a given tick, and CERTAINLY much more complex calculations to perform (bullet trajectories are simple and are contingent on only like 3 variables, whereas pathfinding of a dwarf is contingent on so many parameters it's mind boggling...) that are probably not yet fully optimized.  Because of this, unless you are running DF on ridiculously fast processor beyond what is typically available, if you have a large fortress, you can probably never really have things sync up where 1 second real time = 1 second game time... at least not for a while.     

I hope I make sense.

HOWEVER, I agree with the overall premise of everything you are saying pretty much.

[Rakushun]

Basically a game operates by performing a series of calculations in sequence.  If a game is to represent stuff happening through time, there has to be an arbitrarily defined unit of time (a tick).  A tick can represent a fraction of a second of game time (NOT real time...), a year, or whatever depending on the simulation.  For example, for an FPS, a tick could represent a fraction of a second...  In that FPS, the instant you press the fire button, the game calculates the position of the you just fired bullet during the tick you pressed the fire button (or a tick soon after) using simple Newtonian physics equations or some abstraction thereof.  After all other calculations are performed that are time dependent (like positions of other entities, countdown of a game timer or something) during that tick, the game proceeds to the next tick, where the same time-dependent calculations are repeated, and the game advances by one unit of arbitrarily defined game time (not real time).  The length of the tick in REAL time can vary depending on how many calculations need to be completed before proceeding to the next tick and how fast the computer is that is performing them.  In the case of most FPS games, there are only a relative handful of calculations that need to happen during a tick, namely bullet positions (unless they are ray-traced, instantly hitting bullets or something), entity positions, a round timer if applicable, etc. if we are being simplistic here... In the case of DF, you probably have many orders of magnitude more calculations to perform in a given tick, and CERTAINLY much more complex calculations to perform (bullet trajectories are simple and are contingent on only like 3 variables, whereas pathfinding of a dwarf is contingent on so many parameters it's mind boggling...) that are probably not yet fully optimized.  Because of this, unless you are running DF on ridiculously fast processor beyond what is typically available, if you have a large fortress, you can probably never really have things sync up where 1 second real time = 1 second game time... at least not for a while.     

I hope I make sense.

HOWEVER, I agree with the overall premise of everything you are saying pretty much.

Your explanation does make sense. Like I said before, the greater the time compression the greater the distortion, so if literally matched time was impossible or just too problematic, the next best thing would be a rough approximation, as close as possible. I'm trying to stay away from the minutiae of technical difficulties such as this because none of us really has intimate knowledge of how the game is programmed, exactly how skilled Toady is, whatever. I don't want to spend a lot of time speculating on factors that only Toady knows. He's the person with the best knowledge about practicality, and as the originator of the idea I'm basically defining my role as pure theoretician.

[Andeerz]

Cool.  Gotcha!    I mean, I don't think anything that I mentioned really kills your suggestion outright given it's true.

[GreatWyrmGold]

I'm not in favor of full on real time, just that the abstraction be less severe, to allow for sensible levels of micromanagement in dwarf scale time. I think this problem will need addressing sooner or later. For example in the army arc, let's say you sent your army out on 2 month patrol, that 2 months would zip by in fortress time. Good heavens would that be a huge disconnect, Urist McLazypants managed to drag a solitary table across the fort in the time it took 200 dwarves to march 200km.

Edit: spelling on a smart phone...

My goodness, what do you make your tables out of, slade? In two months, my dwarves can haul about a dining room's worth of furniture each. Try to not make up figures.

And GWG needs to calm down.

Probaby, but look at it from my perspective. The way I see it, these people have been more or less leaving their arguments unchanged as I point out the problems with them. At least they stopped accusing me of calling time-skips a bad idea...

I don't wanna be selfish, but I wanna explore a response to one of my posts...

I don't consider that selfish.

The way I see it, perhaps all that needs to be done to get at this pathfinding burden problem without introducing anything all that novel into the game is to (when things are running "fast" as in 1.2 minutes per game-time-tick like dwarf mode does now) have it so that the game would calculate accessibility of tiles the way they are calculated for Trade Depots sort of.  So, there would be multiple sort of "accessibility maps" the game would have to store (I'd imagine it would only need to be a handful and not be that resource intensive).  Then, any time an entity needs to get from point A to point B, all that needs to be calculated is if point A and point B are accessible to each other (fall within the same accessibility map), and if so, how far it is away, and see how many game-time-ticks it should take for the entity to appear from point A to point B (teleport).  That would be the only abstraction that would need to be made between time modes.

Hm, maybe, but what about distance? The way you describe it, it sounds like it would take the same amount of time to go from point A to B if they're adjacent as if one's at the surface and one's at the magma sea.

EDIT:

The dwarves spending so much time hauling is an intentional design choise so that your fort looks bussy.

Oh, I really hope that's not the reason behind that design choice.  Just doing it to make things look busy is LAME in my opinion. 
However, I agree with your emphasis on the importance of hauling in the game.  But, speeding movement up would not at all diminish this importance at all.  It would remain just as important, and hauling-related-technologies would still be huge game changers and time savers.

I think that doing it "to make things look busy" is not nearly as "lame" as you imply. After all, forts are supposed to look busy, no?
Also, I'm a bit fuzzy on what your suggestion is. Is it slowing down the in-game clock in Fortress Mode to more like Adventure Mode, plus time-skips, or is it what we have now plus accelerated mode?

Oh, I'm sorry. I forgot that you don't actually care about watching dwarves' lives, so you don't care that it would be impossible to play an actual fortress-building game while also enjoying the little details in dwarven daily life. Because if the timescale was slowed like you are suggesting, it'll take a lot longer to go through a fortress week and still enjoy the little things. To say nothing of my earlier point that fortress-making is usually done with the steps all mixed together...

You're straying into full-on strawman territory. Nothing has been said or even implies that it would take the player longer to do things. I think it would actually take less time because you could spend the same amount of player time watching stuff going on but less player time sitting around waiting for things to be done. It doesn't matter if you want to mix your steps together, just skip to whenever you feel like beginning the next step and do it. The bulk of your arguments so far are just ranting about nonexistent theoretical limitations on the system that you seem to invent yourself just to denounce. If you don't stop putting words in my mouth and making wild assumptions, I'm not going to respond to your future posts in this thread.

Sounds funny, seeing as you were claiming I thought time-skips were bad for a while. And, anyways, what part of "Hey, let's have more time calculated per in-game day" does NOT imply that it would take longer to get stuff done? I'm not talking about theoretical limitations, I'm talking about the obvious ramifications of having Fortress Mode run 28-72 times faster: It takes more RL time for the same amount of dwarf time. Does that not describe your idea?

More plump helmets would need to be harvested per tile. That also means that fewer seeds would need to be made per plump helmet, or else that more seeds would be needed to plant one tile with plump helmets. And what about animals? Are you going to up butchering returns? But wait, bones are tied to the same system that creates meat! So, either we'd need to accept having a lot more bones and such plus a little tinker, or we need a major tinker with butchering returns. My point is that everything needs to be changed if the timescale is, or else nothing works.

I got your point quite awhile ago, my point that you continue to refuse to address is that the current system requires more tinkering for each new addition, and potentially requires systemic tinkering for re-balancing with some new additions. Talking from a program design perspective, it's like investing in a more versatile program architecture to save effort in the long run. Obviously my idea would require a lot of work on the front end because everything currently having to do with time and related to the current time abstraction would need to be adjusted. I never claimed that it wouldn't. Again, you seem determined to rail against nonexistent issues or things I haven't said. I don't care how much effort this idea would take, and I have no reason to, because Toady is in charge and no one's making him do anything. I will suggest whatever ideas I think would be good, no matter how radical, and he is free to listen or not listen to them. You're wasting everyone's time by presuming to have a claim on Toady's and presuming to dictate what he should or should not do based on how much of his time and effort would be spent.

If I thought that it was a good idea, I would be all for it, no matter what the programming time. But I don't. The point of that was pointing out that it would not be quick and easy to change the fortress mode timescale, like you seemed to be claiming.

Summary of points made against my idea, not by anyone in particular:
-"Ignoring all the stuff the OP has written about how this would work, it wouldn't work!"

Which stuff?
...Also, who was the OP again?

-"I feel that I own Toady's time and labor, and reject this idea on the premise that it would require an expenditure of too much of both resources, which I own."

Where has anyone implied that? No one feels that they own Toady's time or labor, any more than they do the money in the federal treasury. That doesn't mean that we want the government to waste its money on stupid stuff, nor that we want Toady to spend his time on ideas that many of us feel would make the game worse and not ones that would make it better.

-"It's crazy! But I feel no particular desire to raise any actual argument about why that is."

Who has said that? I have done my best to explain my arguments.

-"I can sit here and endlessly bring up seemingly-different but for the purposes of this argument the same issues and declare that these potential problems invalidate this entire idea, and continue the process when each of my specific but suspiciously similar objections is addressed. And I apparently plan to continue to do so."

Um, who has done this? Yeah, I've brought up the same issues a lot, but that's because you haven't really addressed the core issues.

3. Just ignore the time difference. Change moon states and day/ night so that they aid gameplay, not realism. (Strangely, I feel this would bother immersion less than timeskips and long loading screens)

Thanks ebbor, that could be a very valid point. I would NOT like anything that involved much of a loading time. I think that it could be entirely possible for Toady to achieve a negligible loading time with my idea, but Toady is the person best equipped to make that determination.

He's saying to add flavor divorced from the calander (which I think is a good idea), just FYI.

-snip-

I do like your idea a little bit Andeerz. I think it would be an improvement over the status quo. However, to be honest, the most important part of my idea to me is real time game speed, and time skipping is just the way that it's made to work. It's the place where I'd like the abstraction to be shoved into because I feel that it's a better place for it. I also think slower time scales could be improvements, but I still think real time is the best because it avoids artificial time distortion of the game's balance, especially multiple inconsistent time distortions across different systems.

Funny, I feel just the opposite. The time-skip may not be any less demanding of Toady's time and energy, but it isn't hotly debated and it won't require that players wait a lot longer before anything Fun, like migrant or sieges, happens.

Timey wimey wibbly wobbly stuff: It's complicated.

Give me a made up example!  I don't care how contrived it is.  This would help a lot in figuring out whatever weaknesses there might be in whatever suggestion.

I think it's a Doctor Who reference.

As far as I know, you're only abstracting pathfinding, whitout actually changing anything. So no. I don't know how large the gains would be.

I am suggesting changing four other things, though:
1. hunger/thirst/sleep requirements
2. Adding a toggle between adventure-more and dwarf-mode time (1 tick = ~1 second and 1 tick = ~1.2 minutes respectively...)
3. Increasing the amount of food/water units harvested when harvesting a tile of plants/butchering an animal/getting water from a well
4. keeping entity movement speed per game-time-unit the same in dwarf mode as it is in adventure mode

Let me know if I need to make anything more clear...

So...you're tending towards the "Slow down FM to AM speed" side of the argument? Sad, it means I need to argue with you.


-----


For everyone who seems to be confused about why I think that slowing down Fortress Mode to allow for realistic schedules, like three meals a day and day/night cycles, here's the biggest argument I've been repeating over and over yet which has been ignored and/or misinterpreted every time I've repeated it:

It would make everything take longer IRL.

Let's choose a number for the heck of it--the number I came up with,  x28, seems to be the most conservative and fit the dwarven "day" fairly well, as dwarves eat twice a month and I believe sleep half that often.

So, currently it takes about two hours, let's say, to get a fortress from Granite 1, 1051, to Granite 1, 1052. Maybe half (probably less, depending on playstyle) of that is designations and other things the player does that cause the game to autopause; let's assume that this number does not increase much, although if we increase the amount of work dwarves can do in a day from "maybe make a chair" to "make a few pieces of furniture," which is probably more realistic, then obviously you'd spend longer than that one hour. That leaves one hour of waiting and watching while the dwarves follow your orders. If the game was slowed down to 28x speed, that hour would become 28 or so, and that means that you'd make it tothe end of the year at the end of a bit over an RL day, spent playing constantly without any breaks. How does this not affect things? Sure, with time-skips, you can argue that you would be able to have your fort skip past the time you spend waiting for things to get done, but whose fortresses are only doing one thing at a time? This is extra-true at the start, where after digging out the start of your fortress you are planting crops, building workshops, filling bedrooms and dining rooms with beds and tables and stuff, et cetera. In short, playng at the new speed would make things take A LOT more of our time to get done. Who wants that?

[Rakushun]

GWG: Nobody wants that. I think the reason we've been talking past each other is that you seem to be thinking that the player would somehow be limited in time skipping just because they had more than one thing going on in the fort at once.

Sure, with time-skips, you can argue that you would be able to have your fort skip past the time you spend waiting for things to get done, but whose fortresses are only doing one thing at a time?

Perhaps you should explain why you think the system would be limited in this way, because I'm the OP, and I have no idea where you got this idea from.

Here's your example:

after digging out the start of your fortress you are planting crops, building workshops, filling bedrooms and dining rooms with beds and tables and stuff, et cetera.

Designate dig; Skip until done. Set farms, workshops, beds, tables, and chairs to be built; Skip until any one of these things is done. If it's the farm that's done, assign crops. Workshop, assign jobs. Bed, designate dormitory. Table, designate meeting hall. Set whatever else you want to be done as well. Skip again until the next thing is done. See? You can keep skipping even if your fort is working on more than one thing at a time. Please don't take this example to be a set-in-stone procedure that everyone would have to follow like you did with my "check in and see what your dwarves are doing at various times of the day" example.

[GreatWyrmGold]

GWG: Nobody wants that. I think the reason we've been talking past each other is that you seem to be thinking that the player would somehow be limited in time skipping just because they had more than one thing going on in the fort at once.

Sure, with time-skips, you can argue that you would be able to have your fort skip past the time you spend waiting for things to get done, but whose fortresses are only doing one thing at a time?

Perhaps you should explain why you think the system would be limited in this way, because I'm the OP, and I have no idea where you got this idea from.

Simple. It's not needed, but...let me give an example.
You want to build a dining room. You choose an area to dig, so you have stone to make furniture, and you make furniture from the stone. As it is now, it's easy to order the furniture as the stone gets mined, but if you were time-skipping, either you'd do it so much that you'd really not be much better off, or you'd have to wait until the end of the room-mining phase to make the furniture. That's assuming you can even set controls for time-skipping to "When this designation completes."
I could provide a longer and more detailed explanation, comparing a fort being created as it is now to how I imagine it would be if you needed to use time-skips to move in any sort of swift manner, but until then, just imagine doing a dozen tasks of the dining-room level of complexity or greater at once.

Here's your example:

after digging out the start of your fortress you are planting crops, building workshops, filling bedrooms and dining rooms with beds and tables and stuff, et cetera.

Designate dig; Skip until done. Set farms, workshops, beds, tables, and chairs to be built; Skip until any one of these things is done. If it's the farm that's done, assign crops. Workshop, assign jobs. Bed, designate dormitory. Table, designate meeting hall. Set whatever else you want to be done as well. Skip again until the next thing is done. See? You can keep skipping even if your fort is working on more than one thing at a time. Please don't take this example to be a set-in-stone procedure that everyone would have to follow like you did with my "check in and see what your dwarves are doing at various times of the day" example.

Alright, that moves towards the "enough time-skips that it's not really a lot better than doing without" end of the scale. And, of course, you'd miss out on watching your little maniac-depressive alcoholic midgets get over their issues and turn a dangerous landscape into a functioning fortress. And all of that is, again, assuming that you can program the time-skips to both be complete when X jobs are done and when one of a number of tasks is complete. The latter might not be hard, but the former would probably require a level of continued simulation above what's otherwise needed for a simple "Skip ahead X weeks/months/years" system would, making every time-skip take longer.
None of this should be taken as an argument against time-skips, only against a system that required them to get anywhere at a good speed.

Alright? Have I made my point? Do you want an extended example comparing a hypothetical player who is a lot like me making a fortress of some kind in the current system and n the proposed slo-flo time system?

[Andeerz]

Hm, maybe, but what about distance? The way you describe it, it sounds like it would take the same amount of time to go from point A to B if they're adjacent as if one's at the surface and one's at the magma sea.

Distance would make a difference.  I am glad you asked because I didn't feel like I made it clear enough... anyway, the way I suggest it, you have point A and B on the same accessibility map.  Distance would be calculated either by a similar pathfinding algorithm as what is currently in place (which might partially defeat the purpose of my accessibility map idea, though this might cut time down by eliminating many other possibilities) or a simple calculation of linear distance maybe modified by some other parameters... I'd prefer the former.  Anyway, you have that calculated the instant an entity needs to get somewhere, then the distance is divided by the the speed of the entity to get how many game-time-units (ticks) the dwarf would take to appear from point A to point B. 

This would sort of abstract out the possibilities of having travel interrupted if things remain in dwarf mode time (as during the time between initiating travel from point A and arriving at point B, with my suggestion, the dwarf would effectively be incorporeal (teleporting)), but I think that is acceptable if we are talking about short distances encountered when having to navigate through a fort that is not under attack or something.  If time is switched to adventure-mode-time during travel (while the dwarf is effectively incorporeal), what could then happen is the game could just put the dwarf a percentage of the way to the destination proportional to the amount of time that had already passed since entity started travel over the total calculated amount of time to travel from point A to point B calculated beforehand.  That might make a slight lag when changing between time-modes, but it probably would be acceptable since it would pretty much be performing just as many calculations during that time switch as what the game normally does now in a given time tick.  I hope I make sense.  It makes perfect sense in my head, at least.

EDIT:

The dwarves spending so much time hauling is an intentional design choise so that your fort looks bussy.

Oh, I really hope that's not the reason behind that design choice.  Just doing it to make things look busy is LAME in my opinion. 
However, I agree with your emphasis on the importance of hauling in the game.  But, speeding movement up would not at all diminish this importance at all.  It would remain just as important, and hauling-related-technologies would still be huge game changers and time savers.

I think that doing it "to make things look busy" is not nearly as "lame" as you imply. After all, forts are supposed to look busy, no?
Also, I'm a bit fuzzy on what your suggestion is. Is it slowing down the in-game clock in Fortress Mode to more like Adventure Mode, plus time-skips, or is it what we have now plus accelerated mode?

What I am suggesting is keeping dwarf-mode time as it is right now, but with the option of toggling the game to Adventure Mode time at will and perhaps automatically during combat.  No accelerated mode, though I am not against the ability to time skip in addition to this.

To do this would require the following in order to keep things rectified between Adventure and Dwarf modes:
1. Adventure mode hunger/thirst/sleep requirements implemented in Dwarf Mode
2. Increasing the amount of food/water units harvested when harvesting a tile of plants/butchering an animal/getting water from a well to accomodate 1.
3. keeping entity movement speed per game-time-unit the same in dwarf mode as it is in adventure mode (make dwarves move as fast in Dwarf mode as in Adventure mode)

It would also require some sort of abstraction of fluid mechanics... but this could still work with keeping fluid in dwarf mode as is, though it would be ridiculous.

More plump helmets would need to be harvested per tile. That also means that fewer seeds would need to be made per plump helmet, or else that more seeds would be needed to plant one tile with plump helmets. And what about animals? Are you going to up butchering returns? But wait, bones are tied to the same system that creates meat! So, either we'd need to accept having a lot more bones and such plus a little tinker, or we need a major tinker with butchering returns. My point is that everything needs to be changed if the timescale is, or else nothing works.

I am completely ok with this as it would just be a simple change of parameters.  No need to change the number of bones, just change the number of meat units.  And for organs, make them divisible, which wouldn't be implausible.  It could be coded in minutes, though it would probably take a few days or weeks of playtesting and debugging to get stuff realistically balanced.  But that's what we players can help with with our feedback!

I am suggesting changing four other things, though:
1. hunger/thirst/sleep requirements
2. Adding a toggle between adventure-more and dwarf-mode time (1 tick = ~1 second and 1 tick = ~1.2 minutes respectively...)
3. Increasing the amount of food/water units harvested when harvesting a tile of plants/butchering an animal/getting water from a well
4. keeping entity movement speed per game-time-unit the same in dwarf mode as it is in adventure mode

Let me know if I need to make anything more clear...

So...you're tending towards the "Slow down FM to AM speed" side of the argument? Sad, it means I need to argue with you.

Nope.  I am not suggesting that.  I am suggesting keeping FM and AM speed just the same.  Just change the movement speed in dwarf mode to that of adventure mode and do the other things necessary to make it all work which I mentioned above in this post.  The only huge obstacle I have yet to think through well is fluids... though, again, I could be missing something else that makes my suggestion completely not feasible.

Also, both my suggestion and the OP's suggestion, as far as I understand it, would not make the game take any longer (barring any sort of increased computer resource requirements that might kill framerate...).  In fact, my suggestion at least might actually speed up stuff since getting from one place to another would be faster... though this might be offset by increased sleep and eating requirements.  Overall, I think overall time requirements for getting a fort running would end up being the same...

[10ebbor10]

Yes, Doctor Who reference.

Also, this is what the game needs to do just to calculate such a timeskip.

1. It needs to understand the fortress. What goes where, which dwarves do what, how much food will be eaten, how long each dwarf will spent time hauling,...
2. It's need to abstract the fortress
3. It needs to run the abstraction
4. It needs to deabstract the fortress, whitout placing dwarves in silly places and such.

All this would probably take at least 30 seconds, not including the actual calculations, making using them for short term timeskips unwieldy.

[Frizzil]

@Andeerz
Just to give you and anyone else some supah-useful info as a CS major (if you're at all interested), pathfinding literally translates to traversing a graph of nodes, in an attempt to find the path from one node to another.  Given N nodes, the worst case number of operations (of arbitrary size) is N^2, just due to the way the algorithm works out (it's thoroughly studied in computer science, and that's the best anyone on the planet can come up with.)  It's generally much less than this, say if a dwarf is only moving to a nearby cell, but the worst case gives both an idea of how expensive the algorithm is and an accurate approximation for whenever dwarves travel far away (all the time, I think.)   Mainly, polynomial complexity of the algorithm prevents DF from doing it in a very straightforward manner (the straightforward manner being each cell considered a node in the graph... if there are 10,000 cells in an area, you couldn't possibly calculate this every tick and not cause tremendous lag, because it'd be 10,000*10,000 operations worst case.)  So DFs solution to this is to redefine what a "node" is-- suppose DF can break the game world into "zones" (rooms, hallways, etc), then each zone, rather than each cell in it, comprises the graph-- instead of 10,000 nodes, you get maybe 50!  I imagine DF is already doing this or something better, and Toady has likely poured tons of time into optimizing it.  This is an extremely difficult problem, one that he's probably already spent months on, and it's likely the algorithm couldn't be sped up without significantly changing a game mechanic (like allowing dwarves to teleport through walls, thereby eliminating the need for pathfinding altogether.  Instead maybe mark some zones, like unexplored ones, as "unenterable to all dwarves" so dwarves never teleport there-- would be an instant lookup (polynomal time of 1 ))

If by any chance Toady hadn't done something similar yet, I was thinking a great way to speed up the pathfinding would be to have "graphs of graphs of graphs of..." however many levels as determined by the current number of total nodes.  Partitioning the graphs into distinct nodes would be fairly expensive (N^2 * log2(N) I think... check http://en.wikipedia.org/wiki/Graph_partition), but the beauty is that it only has to be calculated infrequently.  You could think of the graphs layers as being "regions->locations->structures->rooms->cells", though the number of layers higher than "cells" would actually be determined dynamically as the fortress took shape.  With a tree like structure, I think traversing the graph would change from N^2 to (N/B)^2 / logB(N), where N is your node count and B is your number of nodes per partition.  With N=10,000 and B=25, you'd go from 100,000,000 operations to about 56,000!  In uh, non-geek terms, it's the difference between searching through neatly organized folders and folders scattered all over the floor   I hope that wasn't too jargony

As far as an "accessibility map" goes, I think what the premise was might translate roughly to "caching" frequently calculated paths (I might have misunderstood).  It'd only work if the number of nodes could be generalized to some degree, like in a hierarchical graph system (caching every possible path would be (cell count)^2 otherwise, so with tens of thousands of cells, you wouldn't have enough RAM).  Basically, caching paths for every room combination is feasible, but paths between every cell combination isn't.  So the aforementioned zone system would work well with it, and that super-meta-graph thing I cludged together would work REALLY well with it!

Hope that wasn't too rambly, just thought it might be good to give an idea of what kinda stuff would have to go into this idea   I really like the idea, I hope I didn't give an impression to the contrary, I just thought it'd be good for people to know what they were asking for

EDIT:  On the offchance Toady reads this, apparently Fibonacci heaps are good with Dijkstra's shortest path algorithm: http://en.wikipedia.org/wiki/Fibonacci_heap.  You should add one if possible: you'll totally feel like a badass if you do.

EDIT again:  Apparently choice of heap also depends on how "dense" the graph is.  You could dynamically check densities and swap between Fib heaps (for dense) and Binary heaps (for sparse) depending on the situation.  http://stackoverflow.com/questions/504823/has-anyone-actually-implemented-a-fibonacci-heap-efficiently  (I happen to be on the subject of heap selection for a research project, haha)