To provide better insight into how our AI crewbots work we put together this blog to give everyone some clarity on how exactly they work and how the Watson powered voice recognition works with them.

While Bridge Crew was designed as a Social VR game first and foremost, there are times you may be a player or two short or you may just feel like exploring space on your own for a bit. The crewbots were developed to help fill in those blanks. The game is playable and beatable with an AI crew, but they were not intended to replace human players and may not perform as well as your buddies would.

Keep in mind that with VR, performance is at an extreme premium to keep framerates high to avoid player discomfort so highly sophisticated AI that heavily affects that performance was not in the cards. The crewbots are a very effective solution that meets the goals of providing basic crew substitutes without any negative impact on framerates.

To interact with your AI crew members you can either issue commands to them directly using a contextual UI, or you can issue crew wide orders from the Captain’s chair. Most misconceptions are about how crew wide orders work as well as how having humans occupying some of the stations affects these orders.


Crew wide orders were developed to help reduce menu complexity and simplify some complex, common, behaviors. These commands will work with any combination of players and AI manning stations but in the case of humans operating stations the AI assumes that the players will handle their appropriate tasks.

“Analyze Target” for example, will cause tactical to try to scan once in range, engineer to set full power to engines, and helm to fly to the target. You could do this without the crew wide order, however you will have to drill down into each station’s command list in order to do so, and you’ll have to wait for tactical’s scan order to become valid. We execute this sequence of events commonly enough in the game to warrant a nice “macro” for the behavior. “Transport Target” works in a similar fashion. Assuming a target has been scanned, helm will fly to the target, tactical will lower shields if they are up, and engineer will begin the lock on process.

Crew wide orders can be fairly nuanced. For example, the “Cloak Hunt” order (Only available on the 1701-D) will send crew to scanners, adjust power for phasers and shields, arm torpedoes, switch them to proximity and steer the ship toward the radar blip. Once “close” the Tactical crewbot will fire. However, the “Engage Target” order will respect the ship’s current torpedo armed state. So if the captain had previously ordered “arm torpedoes” through tactical’s order panel or via red alert, “Engage Target” will fire torpedoes, if they are not armed, the order will not arm them, and we only shoot phasers.

Think of crew wide orders as a large collection of tiny individual commands whose result is chasing an enemy to fire upon, hunting cloaked ships, etc. There are many things going on in the background during one of these orders.

Now let’s talk about one of the crew orders that needs further clarity, Engineer’s repairs.

When a mission starts, the Engineer Crewbot is initialized with an “auto repair” behavior this is the most basic and default repair mode. This behavior has a few different outcomes depending on if you are on the Aegis/TOS bridge or EnterpriseD. On the Aegis/TOS bridges, if the ship has 100% subsystem health across all subsystems, the Crewbot will unassign the repair crews. If the ship has subsystem damage, auto repair waits until 40% subsystem damage before acting. This means no crews will be assigned to repair until these points are reached.

Auto repair works with a priority list. When it picks what subsystem to fix first, it will choose based on this list. Once a subsystem is repaired, it will reevaluate based on this list and reassign crew to other subsystems that are below the damage threshold.

The Auto Repair behavior can be overridden by either player interaction with the repair panel, or captain’s orders. If the captain orders a “Balanced Repair” the 40% limitation is removed and the crewbot will act based on the priority list if any system has less than 100% health. Otherwise, the behavior is the same as auto repair. Once all subsystems are healthy, we return to the auto repair behavior.

If the captain orders repairs on a specific subsystem, the crewbot will repair this system until 100%. It will then return to the auto repair behavior. The behavior is similar if a player sits at Engineering and sets repair crews. If a player modified any repair crews, the Engineer Crewbot will not run any auto repair logic. Instead, it will leave the crew where they are until those subsystems become 100% healthy. After which, we will return to the Auto Repair default behaviors.

Repair works differently for the Enterprise D. Since leaving crew at a subsystem will give a perk if it is healthy, the Ops Crewbot behavior in this instance is to leave crew at a station if assigned by order or manual player action. Additionally, the “Optimize” orders are essentially presets. This helps ensure if the captain orders a preset, the Crewbot will not reassign crew designated for the preset for repair duty. Typically, our preset orders will have one floating crew to deal with subsystem repairs that are outside the desired optimizations. If a player assigns crew at all, the crewbot will not automatically move crew around on the Enterprise D. Instead, you will have to (as captain) assign a preset to clear any previous player’s settings.


Late in our development cycle, in fact after the crewbots were developed, we got the opportunity to work together with our partners at IBM to utilize Watson to make all of this better. What Watson brings to the table is an easier, more intuitive way to operate the crewbot system. It simply takes the place of the in game UI with voice driven commands.

Here’s how it works in a diagram:
The crewbots in operation under Watson command execute the very same code as when run with the UI. So if for any reason Watson is not available the crewbots are still available with the same functionality. What that also means is that you can see what voice commands are possible by looking at what UI driven commands are available. The big advantage Watson brings to the table is a quicker more intuitive way to issue those commands.

So other than a simpler way to execute these commands, what does Watson’s vaunted cloud functionality give us? Well in addition to a very powerful and effective voice recognition service, Watson is able to interpret what you said and give its confidence level in what you are asking for. Thus, it is able to tell us what command to execute even if you do not say it exactly the “right” way. Thus, we can have “make it so” and “punch it” and “engage” and many other variations result in the same command executed. We then have enhanced this by “training” Watson with Star trek terminology so it has a better idea of what to expect and how to interpret what players say.

The result, more than 80% of the time someone presses the button and says something to Watson we end up executing a command. Now when you factor in how many times people press the button and change their mind, or say nothing or just goof off, this is a very high success rate.

So in summary, the crewbots can be given orders directly for a single station or crew wide orders can be given that affect multiple stations at once. The Watson voice recognition feature is then available to help issue those exact same orders in an easier fashion.