What is the Flight Director's role?

[alexanderson1993]

In a game where pretty much everything can be automated, what purpose does the Flight Director, or Game Master, serve?

There are some things only a Flight Director can do, like play the role of aliens and crew members, have conversation, and debate. But does that mean the Flight Director's role is simply "Actor", while the simulation handles the actual storytelling?

The broadest answer is "Enhancement" - perhaps providing a more nuanced musical soundtrack, with carefully curated music cues. Or adjusting the difficulty of the flight based on how the crew is doing.

And, of course, Flight Directors are required for completely unscripted missions, which should be possible with the Flight Directors controls.

How else does the Flight Director change the experience in the simulator?

And should there be a distinction between missions that are intended to be flown by Flight Directors and missions that are solely automated, with no Flight Director? Or should any mission, fully automated or not, be able to be flown by a Flight Director?

[Xansta]

The role of the flight director largely depends on the scenario/mission/timeline design. Your question also puts the flight director's role into two categories in my mind.

Set Them Free
This flight director designs a fully automated mission. This includes planned dialog with NPCs with only limited dynamic content highly dependent on a list of responses at each stage of the conversation. Different ambient music could be selected prior to the start of the game as well as various parameters such as difficulty, size of crew, time limit, etc. The time spent in preparation may go beyond typical authoring parameters to include items that might otherwise be considered part of the universe such as planets, stars, asteroids, black holes, wormholes, nebulae, artifacts, stations, factions, aliens, player ships, NPC ships, etc. These things may or may not have programmed orbits, planned impacts on the players based on proximity or other conditions. Once the work is done, the Flight Director has the option to participate in the mission as a member of the crew. The flight director may prefer to stay in the flight director seat as a backup to any automation written. As a backup to automation, the flight director or mission writer can improve on the automation until the scenario can run without backup, increasing the chances of the flight director being one of the crew.

Guide Them Safely
The scenario/mission/timeline is not required to have automation, but allows for it. The flight director expects to serve an active role as the game master as events unfold. This allows for dynamic interaction with NPCs either via verbal interaction, text message exchanges, live video cameras covering a costumed NPC (adjunct flight director) or even in-person visitation by an adjunct flight director or by the flight director personally. In this scenario, it may be the flight director that writes the scenario/mission/timeline, or it could be something already prepared by someone else to facilitate the entry of a new flight director or a flight director that does not have the time to construct a new adventure. The degree of active intervention required depends on how much automation has been written in preparation. However, the scenario/mission/timeline will be set up intentionally with active flight direction in mind. Places requiring the hand of the flight director should be clearly identified. Places where flight director intervention is optional should also be identified. The more automation present, the less pressure on the flight director. Depending on the scenario writing skills of the author, the flexibility of the story may be limited with excessive automation. Less automation puts more responsibility on the flight director, but likely gives more flexibility in how the story unfolds.

Of course, there are likely to be scenarios/missions/timelines that don't readily fall into either of these categories. Fully automated scenarios can have a number of places where a flight director can provide direction. There should be generic tools available for a flight director to use dynamically to add flavor to the scenario. For example, in Empty Epsilon, the built in controls on the GM screen allow you to spawn ships of any faction. These ships may be friendly, neutral or enemy to the players. These ships can be directed by the GM to do a variety of things: idle, roaming, stand ground, fly to a location (shooting enemies on the way), fly to a location (ignoring enemies on the way), dock with a station, defend a target, defend a location. Stations, asteroids, nebulae, planets and other things can be spawned on the fly during a mission. Short range and long range sensors are shown on the GM screen so you can spawn stuff out of sensor range and have them fly in towards the players. Ships spawned can have their attributes tweaked so that they behave differently from your run of the mill NPC ships. In short, the GM has a great deal of flexibility without there having to be any automation written whatsoever. WIth default controls like that, any fully automated mission can be radically changed by the GM. I think Nova should have something similar as a default set of GM/flight director tools.

[astrolamb-gaming]

I don't think I have much to add to Xansta's answer. I will note that I'd like to see minimal difference in how the Flight Director does things during a mission and while writing a mission. While the capability to make changes on the fly should be available, the Flight Director should also be able to inject timelines, objectives, and events into the mission mid-flight.

[Xansta]

I sort of merged the flight director role in with the mission creator role. They can obviously be two different people, but I expect that there will likely be significant overlap, especially if automated and/or prepackaged missions are de-emphasized.

[astrolamb-gaming]

Been thinking a bit more about this.

I have to keep in mind that my perspective is almost exclusively from Artemis, which is a very different game than what we're trying for with Thorium Nova. The #1 biggest difference between the two is that Thorium is much less limited in terms of its capability to entertain larger groups of people on a single vessel. There are many more small tasks which can be done at a given time, and it would be nigh on impossible for a flight director to manage all of those tasks in real-time and successfully keep the entire crew engaged. This is much easier to do in artemis, with realistically 6 people at most at any time (barring fighters).

This difference implies to me that one (or more) of the following options must be available (in increasing order of personal preference for me):

• The missions are primarily designed prior to a flight, and the flight director makes sure that things run smoothly, troubleshoots if need be, and perhaps makes some changes here and there as things progress

• The game dynamically adds random minor story elements/mini-quests (kinda like stock artemis currently does)

• The game offers suggested pre-designed mini-quest timelines to the flight director whenever there is a lull in activity for one or more of the crew.

• The flight director is able to quickly manually add pre-designed mini-quest timelines into the mission that fit into the story they are trying to tell, along with setting up the main story on the fly.

[astrolamb-gaming]

^ This assumes, of course, that we intend to support the capability of Thorium Classic to have crews upwards of 25-30 people.

[alexanderson1993]

Based on the conclusion of #28 that I summarized in this blog post, I think we'll cap Thorium Nova at 12 crew members. That gives a good balance of things to do for everyone without underwhelming the crew or overwhelming the Flight Director.

(Fun fact: Space Centers that use Thorium Classic typically have two flight directors for ships with multiple decks and NPC crews. We'll try to avoid that with automation in Thorium Nova.)

At the Utah Space centers, we refer to those "mini-quests" as "second storylines". Here's a few examples off the top of my head:

• Security has to deal with a fight in the mess hall. Also affects Medical
• There's a hacker among the crew causing havoc in the computer core
• A scientist from a nearby starbase wants the Sensors officer to perform some scans of a nebula the crew is passing
• Ancillary systems, not required for the flight, are broken requiring the Damage Control and Quartermaster to work to repair them

There's a lot of opportunity for creating these, and teaching Thorium Nova when to activate one of these mini-quests. Plus, I imagine there will be lots for everyone to do in the regular comings and goings of the main mission itself. Just flying the ship is a lot of work!

[BrackenFunk]

I'm not sure if this fits this discussion exactly, but I would like to point out that a lot of this work has been done for the Voyager (and presumably other locations have as well) already in Thorium classic. Task flows and the like can help with these automations being discussed. One big thing for me would be the ability to bring these things over to Thorium Nova so that I don't have to rework all of these things we've already built for our simulations.

In fact, lots of work that has been accomplished by Classic's Triggers, Macros, Tasks, and the like should be directly importable to Thorium Nova, and I feel like this is an important idea that I am unsure where to place. Is this something that's already been discussed? Or is this something I can push (and if not here, where?)

[alexanderson1993]

First off, welcome to the discussion, Bracken! I'm glad to have your voice in the mix.

One big thing for me would be the ability to bring these things over to Thorium Nova so that I don't have to rework all of these things we've already built for our simulations.

Part of the reason why I started Thorium Nova instead of just making changes to Thorium Classic was so I could create an entirely new, improved framework. As such, the assumption should be that nothing from Thorium Classic can be ported over to Thorium Nova.

For example, missions in Thorium Classic typically involve a lot of changing the viewscreen to show different videos or viewscreen cards. In Thorium Nova, the viewscreen will be more or less automated, showing a view of the outside of the ship and displaying alerts as HUD items along the sides.

Concepts, like Task Lists, certainly could be implemented in Thorium Nova, but since the framework is totally different, transferring stuff from Thorium Classic is not a feature I intend to pursue. In fact, I think it should be actively avoided, so as to spark new ideas and better ways to build spaceship simulators.

The good news is that since automation is such a tentpole feature of Thorium Nova, you probably won't even have to transfer them over - Thorium Nova will have those automations built in. I think what would be most helpful would be for you to give a list of all of the automation you've built into Thorium Classic using triggers, macros, and such that might be useful in Thorium Nova.

[BrackenFunk]

Understood.

[BrackenFunk]

As far as the role of the FD, whether that's a preset FD (totally automated) or a live person is to be reactionary to the decisions of the crew. Information is then used to make decisions.

As long as all information is usable by the FD, then most of the work should be automated.

An example: For a given simulator, whomever is in charge should be able to basically say, for anything in the simulator, if x happens, then y occurs. The example I'm thinking of here is I should be able to preset the "Engine Heat" problems at intervals of warning. If the heat reaches 70%, then I want to send a notification to the helm, I want the simulator to go to yellow alert, and I want an automated message to go out (pre-recorded or something) to say something. I can do that for any reactionary thing.

I feel that this is the thing that makes flight directing super complicated, and can be eliminated entirely by allowing automations to be crafted by the individual to disallow overwhelming amounts of manual input required from the person flying. That sounds like what the plan is, and so that's good! But a FD may want different things to be automated than another, and so all of that should be up to the person flying. That way the FD has a grasp on what they want to control. That's my two cents on the role of the FD and the relationship with Thorium Nova.

[alexanderson1993]

But a FD may want different things to be automated than another

The hope here is to standardize around sensible automations and have every flight director use those automations. The same thing happened with Thorium Classic - every ship is suddenly using the same cards for weapons targeting, activating engines, setting course, etc. instead of having slightly different cards for each simulator. Flight Directors got used to it.

This is definitely a more drastic change, since it directly affects how the Flight Director tells stories. As I mentioned a Discord, Thorium Classic relies on the Flight Director to build the universe around the crew. Without the hand inside the puppet, or the string on the kite, the whole thing just falls limp. Thorium Nova puts a frickin' engine inside the kite allowing it to fly without a Flight Director.

That does limit the things you are able to do, but the hope is that it make it easier for new Flight Directors to jump in and start telling stories of their own.

That said, as we get closer to actually building these automations, it might be possible that we make them configurable. The level and detail of configuration need to be figured out, but there will most definitely be defaults so not everyone has to configure it from scratch.

[BrackenFunk]

Absolutely. General automations are great and fine. I'm talking about being able to say "engine temp at 80% capacity - go red alert, automated message sent to helm" would be a neat feature to have so that you can customize the way you want YOUR simulator to run. Does that make sense? Is that too much?

[alexanderson1993]

It makes perfect sense, and I don't see why that wouldn't be valuable for every ship to have.

Here's how I see it. Once the engine temperature hits 60%, a little notice appears on the viewscreen showing the current heat level. At 70%, the viewscreen notice gets a little bigger and a little redder. And then at 80%, it triggers alarms to play with a much larger alert superimposed on the viewscreen.

At some point we'll need to have a discussion about the alert condition, and whether that's something that's only changed by the crew, or if the simulation can change the alert condition automatically.