Dynamically Constructed Timelines

[alexanderson1993]

Be sure to read this discussion first for more context: #691

It should be possible to dynamically construct timelines of all kinds. Let's start by looking at a damage report.

There are a few kinds of tasks which might be included as steps in a damage report:

• Transfer cargo (this cargo to this room)
• Send a team (with these types of officers to this room)
• Send an exocomp (with these parts to this room)
• Compose a long range message (to this destination, that says this)
• Launch a probe (this type of probe with this equipment)

In Thorium Classic, these task templates are all defined ahead of time. Damage reports are then generated automatically based on the length the Flight Director specifies - short, medium, long. This provides a lot of flexibility (time and difficulty management) and variability (every report is a little different). Reports are generated based on

• What templates are defined
• What system the report is generated for
• What other systems/capabilities the ship has (can't send a team if there are no engineering team members)

If the step doesn't meet the criteria, then it can't be included in the report.

As mentioned in a previous discussion this also qualifies as a timeline. The steps are just dynamically generated, but it's still a timeline.

This system opens the opportunity for reports to automatically be generated without the crew or Flight Director asking for it. The simulation can observe how active a crew member is, what reports are currently active, and the state of the ship (what systems have lower efficiency, for example) and generate a report that involves that inactive crew member.

Another benefit for damage reports is that literally any crew action that can activate a trigger can be used in a damage report step. Thorium Classic has tightly constrained Task Templates that can automatically advance damage reports (there is a generic task template that must be manually verified). Thorium Nova removes that limitation.

And it extends beyond damage reports. Second story lines could automatically generate based on what is going on in the ship.

• Intruders being on the ship could be a condition for a report about items stolen from the cargo hold.
• NPC crew members could become disgruntled. If two disgruntled crew meet in the hallways, it could generate and trigger a timeline for resolving a fight between the crew.
• A system with low efficiency could cause a radiation hazard (see this discussion: Internal Hazards #693). A crew member walking through that radiation hazard might generate a timeline for medical to address the harm to that crew member, security to secure the area with the radiation, and a damage team to address the hazard itself.

And the templates for these timelines could provide boosts and bonuses based on how well the crew addresses the situation in the timeline.

This can also extend to the mission timeline. One feature that will be integrated into timelines is the ability to set variables on any entity, including the timeline itself, the ship, or the entire flight. This means that missions could be a bit more open-ended, with more than one option for solving it.

Suppose crews needed to find out where some pirates have taken stolen weapons. If the crew scans for an ion trail as the pirates are leaving, the timeline can notice that and add a variable ionTrailScanned to the ship's variables. Alternatively, they could have decoded a message that indicates where the pirates went and add a variable secretMessageDecoded to the ship. Then, when talking to their mission commander, the dialogue for the commander can be generated based on the state of either of those variables, directly tying the crews actions to the progress of the simulation.

Naturally, if the crew did neither of those things, then the timeline should account for that by either sending them back to the scene of the crime to gather evidence, or outright telling them where to go.

Also, if a Flight Director is playing the role the mission commander, instead of providing dialogue directly, the timeline can highlight the things the crew has and hasn't done so the Flight Director can guide the conversation appropriately.

This feels like a solid improvement - it's still possible to tell the same linear stories as Thorium Classic, but it's also far easier to tell stories with branching storylines, where the actions of the crew actually make a difference in what story is told, while a Flight Director, if present, still retains the tools and power to push the story along if necessary.

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?
• Any other thoughts or suggestions.

[brentjanderson]

This may be what you have in mind, but it's not clear how tightly coupled some of these things are. Narrative-wise, it may not matter if the two NPCs physically interacted in terms of simulation mechanics. What matters is that the players have the idea planted earlier that these two are on a track towards conflict, and then that conflict can erupt later (or not, although if it doesn't then Chekov's gun didn't fire).

Establishing that narratively could happen through a Marauder's map, but you still need a way to escalate this to crew awareness: they can't miss the set up just because they weren't looking at the map. A security message from another deck could mention this in a status report, for example. That message has zero tight coupling to an actual hallway encounter, yet it's just as real to the players.

Mechanics are good for things like "this fire will damage this system's efficiency by X rate until extinguished". But the fire doesn't have to arise for mechanical reasons, it should arise because a narrative step commanded it to happen.