By the way, have you worked out what sort of overhead timelines add to the vanilla way of handling things? And it seems you'll be well over the 500k word mark 'till you're done - great news
That's an interesting question. It's hard to quantify. From a technical perspective, it's nothing especially fancy -- it's just a flavor of reactivity. I think the majority of extra effort is in the area design process, and depending upon how well that's done, there could be more burden on area implementation and also QA. We haven't fully realized those costs yet.
But I think its impact is more in the trade-off against other things -- as I'm sure you realize, we have many reasons to keep the total number of states as low as we can for any given quest. (I don't actually mean "as low as we can" as this would be at odds with goals of high reactivity, immersion, etc. So I mean more that we want to make sure that the quest states we do include are worth the effort they require.)
I'm wording that awkwardly, but basically: if we increase overall complexity because time matters, then we have to simplify in some other way so that everything is manageable. When designing a quest with a time dependence, the designer needs to figure out how to keep the overall complexity (of implementation) reasonable and this takes more thought and/or requires "compromises" in terms of other sorts of potential reactivity.
For example, TTON quests tend to have singular initial states -- they are designed so that you acquire them through one specific event or NPC. Say there's a murder investigation. You might receive it only through talking with someone who wants you to solve the murder. Perhaps the corpse is placed in a room that's initially "blocked" by the quest NPC so that it's not possible to find it first (i.e., until we know you must have received the quest already). (This is assuming the situation were such that it would feel weird if you could find the corpse without that starting the quest. Other design solutions are also possible.) The more starting points a quest has, the more complicated it is to handle all routes well. So limiting the starting states saves implementation/writing complexity that we can then invest in other types of reactivity. (This was a conscious (if not ubiquitous) design decision for TTON because we feel other types of reactivity are more impactful (for this game).)
(Aside: How the timeline events came up was somewhat accidental. In fleshing out the design/implementation of the Bloom, Jesse Farrell came up with a one-off idea for an event and this inspired the larger system, which was very compatible with how we were already planning to approach the passage of time. Though we were concerned about the possible increase the scope, we felt it was manageable and "prototyped" in the Bloom.
(So the feature risks feeling a little "tacked on" there, as it wasn't deeply integrated into the initial design. But I think few would notice this (except that I'm admitting it here =) ) -- we've iterated on the Bloom enough that they fit better, and there'll be more iteration later as well. Meanwhile, the timeline events are quite thoroughly integrated into some of the areas we designed later, such as Sagus Cliffs. We'll see how all unfolds, but so far it looks like it will feel pretty natural in these places.)
Oh, yes, we'll be well over the 500K word mark. (I'm not entirely sure how much this is a good or bad thing.
We have no specific word "target," just projections based upon the completed edited/revised work.)