3 questions:
1.What are you going to do about the fact that multiplying the amount of food items will be a major drain on CPU resources. (Especially when things like rotting and such are going to be considered, and food stockpiles aren't failproof anymore. I'd rather have food rotting and such than realistic time, for a variety of reasons)
I cannot give any concrete solution. I do not have enough knowledge about how the game stores the data to offer any suggestion on improvements. However, like GWG said, I think that having an increase in number within stacks is not going to harm performance much. There would be more stuff lying around, but it's hard to say how much this will impact performance without actually trying it. If eating and drinking frequencies increase and there are more food units per harvest, then I'd imagine the increase in consumption of these items could partially counteract increased production of these items... but I could also see situations where that might not be the case.
2. How are you going to handle fast mode? You can't just tell the game to go faster.
Read the OP. I am not telling the game to go faster. I'm telling the game to go the same speed (in fast mode) as it does now in dwarf mode, but have movement speeds changed along with some other things. I try to address the issues with this in the OP.
3. Why? Are these assumptions correct;
Pro's
-Realistic
- allows for sensible shedules
Contra
-Lot's and lots of work
-Seperates the background (lives of dwarves) from the foreground (live of the fort)
-Ie, more like seeing highly detailed pictures of dwarven lives, rather than a single, if somewhat blurry video of a dwarven life.
I think GWG highlighted a huge problem right here:
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.
These kinds of discrepancies open the game up for huge exploits and holes in the game mechanics when things involving interacting with stuff outside of your fort come along (which are indeed planned!). My suggestion might be a good way to solve this problem. Additionally, my suggestion would potentially allow for a concrete distinction between day and night; night raids could happen, forts would be less active at night when most people are asleep, there would be non-trivial reasons for having artificial lighting (like torches and stuff), all of which could allow for some very interesting strategies to be employed and !!FUN!! situations to happen to say the least (i.e. realistic strategic problems that people IRL had to make solutions and accommodate fort designs for... and that would be fun challenges for players). I could give quite a few examples of what this alone could open up. I can also give reasons why other suggestions of night time simulation in dwarf mode would not really work in the long run (like having a handful of chunks of time a year being designated as "night").
With regard to the separating background from foreground, with my suggestion, the only thing that would really change in this regard is that the player will see moving entities appear to "teleport" about at normal (fast) game speed instead of seeing them move one tile at a time. Anything involving moving around would look different but ultimately would behave similarly. I wouldn't miss being able to see tile-by-tile movement for most of the game. In slow game speed, one would be able to see the kind of movement one currently sees in dwarf mode. Sleeping and eating would happen more frequently, along with corresponding pathing. Hauling would happen faster. However, crafting, mining, and other jobs wouldn't necessarily change at all in their time and resource requirements (other than time taken to move raw goods from a stockpile to the workshop). I don't see any loss in detail here. In fact, I'd see an increase in detail as stuff like day and night could happen believably. The only conceivable loss of detail would be during how I propose to change movement during fast game speed, which might change (decrease) the chances of moving entities colliding with things that cross their path.
The lots and lots of work argument is not one I consider valid. The time discrepancy issue is something that Toady will eventually have to deal with one way or another, and any solution is going to involve a lot of work.