All you need is a teleprompter

Flight directors (analagous to a “game master” for TTRPGs) are at the heart of every Space Center flight. They ensure the simulator is clean and prepared to fly, greet the crew, provide the mission briefing, training, and then actually perform the story. Larger ships may rely on additional staff, but everyone is there in service of a story being told by the flight director.

Bridge simulators have been automatically computing a lot of the simulation for a while. The position of sensor contacts, heating and cooling dynamics in the reactor, and more do not require the flight director’s attention. They are mechanical enough for a computer to handle without human oversight.

The rest of the storytelling and narration basically lives in the flight director’s head. They know what’s coming next, what’s already happened, and how they would react to the crew as different characters. Mission binders and story materials prepared in advance may be used as part of a flight, but eventually the whole thing becomes “muscle memory”. The story is ingrained in the flight director, and they embody the wisdom from every flight they’ve ever flown. This is not unlike someone learning a musical instrument or how to drive: so much becomes second nature that you don’t even think about it.

The problem here is that building up that intuition takes a lot of time, effort, and deliberate practice. It truly is a practice, in the same way that learning how to perform Shakespeare, live music, or dance requires substantial dedication to the craft.

This esssay aims to explore how we might lower the energy required to help someone become a competent flight director. The subversive goal of this effort is that, if we can lower the bar far enough, we might be able to teach a computer how to fly a flight on its own. On our way, we may learn a few things about what flight directing is, and how to make it more scalable.

Prompting in the Theater

Imagine you’re standing on a stage, about to deliver a speech. Or, perhaps you’re a rock star in front of a crowded arena, ready to put on a show. In any entertainment venue, performers live and breathe by their cues. You know where to stand, what to say, when and how to say it.1 Musicians often wear earpieces to listen to a click track and to hear hints from a conductor or stage manager.

For a flight director, what better way to deliver such cues than a teleprompter? Although I don’t think that putting a full-size prompter in a control room is required, what if there was a context-aware box on the screen that fed each cue to a training flight director?

Imagine a box on the core computer, where the next line of dialog, the next sound to play, any action that needs to be taken, any notes to add along the way, are presented one after another as the story goes on. Branches in the story would present as buttons that the flight director could click on to advance to the next set of cues.

Using such prompts would not only ease the transition to being a flight director, but the mission scripts to power such a teleprompter could be crafted in a way that is machine readable. This means that as we present cues to the flight director, we can potentially automate some or all of the actions being taken as the story progresses.

For example, if we have a cue to open a short range communications hail, we could present that to the flight director who would then start the hail. If we automate this a little, the computer could start the hail automatically once we hit that step. That’s not particularly hard to automate, and it would be fully scriptable. This spectrum of automation - from entirely manual with cues, to fully automated - makes it possible to increase automation to the level that is both possible and desirable by the storyteller. Some may want classic, manual flights with zero cues (just don’t put the teleprompter on the screen). Trainees may benefit from some automation, watching cues as they come and go. It may be possible to fully automate a flight using the same primitives, if story authors are willing to put the effort into adding enough content to cover every path through the story.

Tight feedback, great stories

Authoring tools with tight feedback are critical to any automated storytelling.

Naturally, the more you automate, the more content you need describing what and how to automate. Making every possible branch of story part of a complete mission script means you need to construct every bit of content, for every situation. Although that is daunting, it is possible with enough will and effort.

Along the way, flight directors would be able to benefit from whatever content already exists and, as crews and staff come up with novel story flows, writers would be able to craft the next bits of story flow that cover those new cases. Eventually, it is possible that flight directors would be able to hit “play” and let the machine do the rest, supervising in the same way that a human driver supervises a self-driving car. If a flight turns down a story branch that is underdeveloped, human operators could take over to keep the story going and perhaps steer it back into more known territory. Conversely, a flight may twist and turn down otherwise well-worn paths, with impeccable timing and dialog. If this happens on the regular, then the story may be automatable. Adding more content should make either well-worn narratives or new story flows even better.

Thus, one of the design goals of this approach is that a new unit of content should yield more than one unit of storytelling value: story content should compound, and it should be robust to adding extra content any time we like. As an example, let’s suppose that we come up with some clever banter for the chief engineer to say during slower parts of a mission. The banter only makes sense under certain conditions that may not even be possible in every flight, but that might come up sometimes. We ought to be able to add this bit of banter, and the system ought to be able to incorporate it under those unique conditions. Whether it shows up or not is irrelevant, so long as we’ve done our job in coming up with something clever that will only show up when appropriate.

In order to produce all this content, the authoring tools need to be world-class for developing each piece of story, and seamlessly combining them together into a finished script. I’d imagine a few things would need to exist:

1. Editing a story script like this ought to use the same tools people use to write scripts: raw text. The raw text should be easy to read for humans and machines, and not require a degree in computer science in order to use or understand. A great example for this is the Ink scripting language, which is award-winning and designed for basically this very purpose.
   • By itself, Ink does not support some of the tasks we need to perform, so we would need to extend it. More details on how that could work in the post “Ink for show control”.
2. You need an editor that understands Ink and custom extensions to Ink’s script, that can highlight warnings and errors
3. When playing a script, if the computer doesn’t know what to do, we just write it in the Teleprompter box on the flight director’s computer and let a human handle it. If we get completely stuck, the story controls should still let you play things out 100% manually.
4. While editing a piece of content, it should be possible to “play” that content without respect for everything else that may have been written before or after it. Not unlike rehearsing a scene in a play, we don’t need to start from Act 1 in order to work on an interaction slated for the climax.
   • Playing back content should be really fun when done inside a simulator, or with the right editor software. It should feel a lot like sitting down at GarageBand with a connected keyboard, letting you riff on ideas and, when you hit “Play”, what you’ve composed is played back.
   • Imagine sitting down on a bridge simulator set, laptop in hand, iterating on your script. Each time you hit “play” it may actually change the scene your working on. Assistants sitting at the controls should be able to provide feedback on each cue being performed, making story writing a collaborative experience that produces a draft script, readable by humans and executable by computers.
   • This also means that cues may be handled differently depending on the “mode” you’re in. If you have a line of dialog from an NPC, you might hear that dialog spoken back to you by the computer during rehearsal, whereas during a flight it might be performed by a human actor or perhaps come from an MP3 file with subtitles scrolling across the main viewer. When simulating an impact with sound and lighting effects, during a flight this might actually play sounds and instruct a DMX controller, while during rehearsal the sound may play but the lighting effects may be simulated on-screen.
5. Once you’ve played back a scene, you should be able to integrate it across a whole story by starting playback from a certain point in the script. You would initialize things to the way you want them to be, and start playback from that point, playing as far as you like to verify that the scene works. Integrating a story front-to-back in a “speedrunning” mode should be possible, too. Such “speed running” cues could just be that: cues in the script that force the game into a certain state instantly, e.g. allowing you to move the ship instantly to the next location without travel. These cues could be configured to do nothing during a flight, even though they’re still in the script.

Doing these sorts of live edit & rehearse sequences with other actors could prove very helpful for collaborating on a script, incorporating feedback, and rehearsing the whole thing as a group.

Don’t fear the prompter

Having a teleprompter in any scenario would be optional. Experienced, veteran flight directors may not want or even need such tools. As stories grow progressively complex, however, they become useful tools for navigating where you may be at in the middle of a complex flight. Novice flight directors could still benefit from such a prompter, getting cues for each step in the story until they are confident in their own ability to tell the story. Flights with little to no human support become possible if the cues are comprehensive enough and follow machine-readable syntax.