Everything is a Timeline

[alexanderson1993]

Context

In Thorium Classic, timelines are comprised of:

• A timeline object, which holds a number of
• Timeline steps, which holds a number of
• Timeline actions, which are run when the timeline step is activated, including changing the viewscreen, sending messages or sensor data, and updating other attributes of the controls.

Missions proceed as a flight director advances the timeline and activates the steps.

It is possible to automate the timeline in a few ways

• Auto-advance waits until that step has completed its execution, which might include some delays, and then makes the timeline advance to the next step and execute.
• A "Go to timeline step" action is available to jump around in a timeline
• Triggers are a separate entity, but it's possible for them to observe what is happening in the simulation and then execute the "Go to timeline step" or "Go to next step" actions. This isn't seen in practice since triggers and timelines are so decoupled.

In Thorium Nova, timelines look mostly the same. The biggest difference is that you can now define triggers - conditions that the simulation must be in before advancing - as part of a timeline action, which can be set up to activate the next step in the timeline. This enables a fully integrated automated timeline experience.

That means each timeline step has

• Preconditions that must be met before a step activates
• A template of actions which are performed when the step activates
• Completion criteria, indicating that the conditions for advancing the timeline are complete
• Post-actions, which occur when the timeline step is completed

Hold on to that for just a second...

---

Damage reports in Thorium Classic's predecessors used to be static, hand-written text documents which tell the officer all of the steps needed to fix systems on their ship - send a team, send cargo, remove power, plug in these cables, etc. Every time you repair a specific system, you get the same damage report, unless the flight director has prepared multiple reports for a system.

Thorium Classic introduced Task Reports with the intention of automating the damage report verification process. Each step of the report is given

• Preconditions that must be met for the step to be included in the report
• A template for telling the crew what needs to be done to complete the step
• Completion criteria which the simulation uses to know if the step has been completed and the report can proceed
• Post-actions, which occur when that damage report step is completed

...Wait a second. If you tilt your head and squint your eyes, this looks an awful lot like timelines.

That's because it is. It's totally a timeline. A specialized type of timeline, but a timeline nonetheless.

I propose we embrace this idea and use the same structure of data and UI for constructing damage reports as we do for constructing timelines.

What you should comment on:

• Does this make sense? Does it sound interesting or exciting?
• What pitfalls or problems do you see with this proposal? What's missing?
• Any other thoughts or suggestions.

[hjohnr]

Are there criteria built into timelines that are pass/fail, as in if a ship or crew is unable to fulfill objectives for a given step or action, they can't proceed, and mission failure might result? Do some items have timers, for example if an oxygen leak isn't addressed in x minutes, everyone dies, game over?

I'd suggest farming out the writing as much as possible. It still sounds like you have a lot of manual work to do here, and because you are focused on all aspects of development, and creating plots and timelines are probably not as technical as other tasks, you should get help to write stuff. A guide should be developed suggesting how to organize and proceed based on what exists, but then let others write some 'episodes' so that you can focus on getting other things done.

(I am not volunteering, I could write a couple, but I don't have the bandwidth to produce tons of copy :) ). But, good or bad, get some stuff to edit instead of producing from the whole cloth.

Do you do timelines (and damage reports) formatted in XML or something similar?

[alexanderson1993]

Yes, there would be an action that the timeline could execute that would be "mission failure". So your timer example is correct. In pseudocode it would look something like

await wait(1000 * 10) // wait for 10 minutes
if (hasOxygenLeak()) {
  doAction("missionFailure", {reason: "The oxygen leak was not repaired in time and your crew suffocated."})
}

Naturally, you can have more transitive failures by creating an objective, and then marking that objective as "cancelled".

then let others write some 'episodes' so that you can focus on getting other things done.

That's the plan, though I'll write a few myself to demonstrate how it works and show the flexibility and expressiveness of the system. I don't want mission writers to get stuck in a rut of linear timelines.

Do you do timelines (and damage reports) formatted in XML or something similar?

I haven't written this proposal yet - still doing some experiments and tests - but my plan is to have timelines written in JavaScript. I think I can put together tools, guardrails, and training material to make it easy to pick up, write, and test missions - maybe even without needing to run a full flight. More details forthcoming, but you can get a taste here. https://gist.github.com/alexanderson1993/0d946801668d321e765a3b12ebe3cbef

[hjohnr]

Oh, if you are not entirely AI averse (I'm on the fence mostly hate it, but it is inevitable), you could develop some prompts and ask for (many) variants for text-boxes to populate timelines and damage reports if writers are not handy.

[frank-nielson]

Aye. Very good points. This does simplify things if the timeline cannot be forced to go forward. I guess we will see if the inability to force a timeline step becomes a major problem or not.
If a lot of triggers are not firing when they reasonably should, there may very well be a different solution than forcing a timeline step

[alexanderson1993]

Oh, I want to make sure there's no misunderstanding - Flight Directors will still be able to force-execute timeline steps manually if need be. But we still need to account for flights with no Flight Director.

[frank-nielson]

I see. Hmmm, I'm hazy on how we can force the timeline without a Flight Director, but I suppose we can figure that out later

[alexanderson1993]

That's the thing... I don't think we can.

But that's par for the course - just look at any other open-world narrative game.

[frank-nielson]

lol yep! That's why I brought it up. Soft locks happen in games like Skyrim all the time. I'm definitely not saying we need to do better than a AAA title in regards to soft locks, but it would've been nice :)

[Froginator45]

You might already have considered this but I figure I’ll bring it up anyways. Here’s my brain barf:

Having the ability for various nested conditions and exit statements could open the timeline possibilities drastically. Also allowing some timelines to be set on a conditioned loop and allowing said loop to run a set number of times or a random number of times (within a defined limit) would add some interesting possibilities.

Various timeline step conditions could open the possibility for branching timeline splitting/joining.

Having the ability to enable/disable various concurrent timelines based on a difficulty setting could be a way to add replay-ability to each mission and allow a single mission to work for various age groups.

Having a form of the timeline in some sort of “mission journal” for each player would be a nice way for them to see what’s going on and remember where they were if they need to pause the mission for a later date. This would mean each step would need to be markable as a “recorded” step and whose “journal” it is recorded in. Is it a ship wide event? Or only an event that security gets to see?

[alexanderson1993]

Also allowing some timelines to be set on a conditioned loop and allowing said loop to run a set number of times or a random number of times (within a defined limit) would add some interesting possibilities.

Can you give an example of a narrative that is enabled by this kind of looping action you describe?

Various timeline step conditions could open the possibility for branching timeline splitting/joining.

Yes, branching timelines is pretty easy. There's a timeline action for starting a new timeline, and then the original timeline has a condition which triggers once the completion criteria of the timeline are reached. I'm not sure if is better to encourage implicit ("Trigger when the "Destroy all pirates" timeline is considered 'complete") or explicit ("Trigger when ship X has been destroyed") conditions. I guess I could make it so both are possible...

add replay-ability to each mission

Yes! Imagine a mission where you have to choose to give asylum to an escaped slave, but instead you choose to give the slave back to the slave keeper, who returns to their space through a wormhole. Traditionally when this mission is flown at Utah Space Centers, that's considered a mission failure and the crew has to start over and choose differently. But we could write a timeline that branches at that choice and has the crew follow the keeper through the wormhole, kicking off a totally different mission. That's entirely possible.

[Froginator45]

Here's some examples of a narrative for a looping action:

1. You want enemy ships to continually spawn until the players are able to complete some other task. Making it so how quickly they complete the task being the main thing they should worry about. Not shooting all the bad guys.
2. The players need to collect unstable tech in space that have a random amount of radiation pulses that occur when they are moved. Each radiation pulse causes damage to the ship.
3. There is a pulsar in the area with steady interval radiation spikes that cause damage throughout the duration of the mission if they get too close.

Most of those scenarios depend on being able to run concurrent timelines. But maybe some of those things aren't suited for timelines and would be better served using some other mechanic.

[alexanderson1993]

Okay, I get it. An implicit loop, by jumping back to a specific timeline step to reset the loop. So the logic would be

• Perform the looping action
• Wait for some period of time
• Check to see if the condition to stop the loop has been reached. Otherwise, jump to the same step to repeat the loop

Should be doable.