Mission Management System

[alexanderson1993]

Missions are objects that have configurations for the simulators which run the mission - not specific simulators, but instances of a simulator which are configured with an actual simulator when the mission is instantiated as a flight. These mission simulator objects would be very sparse - all they have is a timeline of actions which is applied to the simulator when the mission is instantiated. These actions would configure and set the simulator up in nearly every way.

This part is a little bit hazy - how much of a simulator is inherit in the simulator itself and how much is defined by the mission which is being run? On one end of the spectrum, the simulator could be defined entirely by the mission, including the decks, rooms, and personnel on the ship. On the other, the simulator is very static with definite decks, rooms, and personnel, etc which remain the same regardless of which mission is being run.

Missions are created simply by creating a timeline. Timelines are created by manipulating elements on Core (I suppose you could do the same with stations too). All actions performed during a given time are placed into a timeline cue. The flight director then commits that cue. This cue is the initial state of the mission. The process is repeated for every part of the timeline. Note that things which the crew must do should be excluded from this. For example, activating the engines should not be part of the timeline.

If the mission defines the simulator, then part of the initial cue of the timeline could be creating all of the parts of the simulator, such as the systems which it has, etc. This would mean that there would need to be a method for adding and removing systems from the simulator. This could include adding and removing cards from stations. Example: A card for controlling the Phase Cloaking Device during the Parameter mission - the system and card don't exist till the device is on the ship.

[alexanderson1993]

The physical aspects of the simulator will be defined by the simulator itself. Things like the decks, rooms, stations configs, systems, and personnel will be built into the saved simulator. However, these things could be overridden by the timeline events which initialize the flight. Decks and rooms could change, personnel could decrease, systems could be added, etc.

[brentjanderson]

This kind of thing actually fits relatively well with the entity-component system design (referred to in #23 and at https://en.wikipedia.org/wiki/Entity_component_system). Essentially, each entity can be tagged with components. To give the simulator a certain property (e.g. a cloaking device), you attach the component to the simulator. Simulation behaviors would then find all entities that have that behavior attached to them, and respond accordingly.

[alexanderson1993]

Depends on #34

[alexanderson1993]

Missions, Template Simulator (along with all of the necessary assets) should be import/exportable and portable so they can be easily transferred between installations.