Now that the C++ porting is done and I’m making forwards motion, it’s time for an update!

The first big new features implemented since the port job was done is… the ship’s computer.

There’s quite a few parts to this beast, including a fully functional terminal system – so this will be a fairly detailed post, including some info about the systems which have computer screens.

The top-left of the screen is now the main computer system for the ship.

The bottom-left of the display is a toggle switch to shift between modes (also by default set up with a keyboard shortcut – the tilde key).

Let’s break down the screens you can see here…

Ship Status

The Ship Status screen is the default view – and, in theory, if you never burrowed into the screens beyond this one, you could still play the game. You’d be playing it a bit less well, most likely, and parts of it might be tougher, but in theory for a more casual player, you could have this screen flashing by the current damaged components of your ship and other vital information the entire game and do okay just from that.

But if you do look at the next screen…

Damage Control

The damage control screen is a much faster, quick-access way to view the damage state of your ship. It’s less aesthetically pleasing than the summary display on page 1 of the computer, but it also has another feature: you can alter the damage control team’s priority.

By default, your ship’s XO will focus the damage control parties on repairing whatever system is the most damaged (or the most critical to the continued operation of your ship). The problem is, when you’re in a heated battle, some systems may be more vital than your XO releases for your given battle strategy.

For this reason, you are able to cycle the priority to any of the ship’s systems manually, or set it back to letting your Executive Officer handle the repairs as they see fit.

The Watch

If this concept confuses you, and your brain instantly goes to night watchmen, think of your ship’s current watch as people on shift work.

You have more officers than you can use on on duty at the one time, and the longer they remain on watch, the more tired they become.

By default, if you leave your ship to its own running, the XO will cycle people on and off watch as every 20 turns. The tired crew will return to their cabins to refresh, and the crew who’ve had a few hours to sleep and grab some of Cook’s famous single-origin Tarkalian Espresso in the mess will appear on duty.

Of course, not all crew are equal – they have their own experience levels, ranks, and medical states.

In this case, we can see that all the officers on watch except Takiguchi and Wintringham (whose names are in dark grey) are the most senior officers available for that post. Dr Polsky is, for instance, our chief medical officer aboard ship.

Manual cycling of crew isn’t required, of course, but it can be useful – if you’ve been fighting for a while and your crew are exhausted, you might want to take the tired ones off-duty and bring on a replacement from the benches.

One exception to this, however, is General Quarters.

Calling General Quarters aboard ship brings out the most experienced officers to each station, regardless of how they’re doing – and keeps them there.

Even if they hit end of watch and are exhausted, they will stay at their post unless you rescind the order for General Quarters, or manually replace them.

Manual changing of who is at what station can also be useful if one of your crew members is injured.

If one takes critical (or even fatal) damage, they will of course be replaced on watch by the next available officer for the role. However, it’s possible for crew members to sustain minor injuries and remain at their posts. Maybe you want them there, or maybe you want them to go see grumpy Dr. Cottle and have their cuts and bruises tended to.

The System Terminal

Now we get to the big one – the system terminal.

The final pane on the computer is the terminal.

This feature allows you to manually control almost every part of your ship, sometimes beyond the point where they’ve stopped working using the automated systems.

On a very basic level, this means you can perform actions such as altering the state of crew on watch, issue movement orders, spin up the FTL drive, or whatever else you need to do via text.

When your ship systems become critically damaged, the buttons and displays may stop working on the rest of your bridge – but no matter, you can always, in a pinch return to the terminal and perform manual ship commands from there.

But there’s more it can do…

Short range or long range sensors busted due to damage taken?

Well, your backup computer keeps copies of the scans, and you can access them from your terminal.

Under the Hood

This probably seems like a lot of work to go to for a feature that it’s entirely possible to play the game without. There are two reasons for this:

1. It’s cool
2. I built the back-end to make adding these commands quite trivial

I’m going to briefly explain what the second item there means…

So, all ship commands are defined and handled in a master GameCommand module. When the game starts, I have numerous commands configured – from meta commands such as “quit to menu” to in-game commands such as “move left” or “spin up FTL drive”.

They’re all standardised – each function returns a success or fail, and performs its own checks to ensure that it should be allowed to proceed with its purpose.

These commands are tied to buttons and other UI elements in the game. For instance, the above command (watchUp) is tied to the following “Prev” button.

In this case, the button is greyed out – the button is also tied to a “checkCanMoveWatchCursorUp” function, also handled in a DataInterface module which keeps simple boolean check functions.

So when I want to implement a new feature, I add Game Commands, and Game Checks (and a similar thing for anything that outputs strings).

When I want to tie them to the UI, I tell them the name of the command and the check function that they should react to, such as these:

Of course, the above may seem weird to you. Some are in lower-case, and others aren’t.

This is my simple shortcut to stop me having to add new commands into the terminal.

If I put it with a prefix of “ACTION”, then the terminal will ignore it.

If I put it with anything else in its first and second words, it will consider the first a category, and the second a subcommand.

So if I type “help watch” in the terminal, it will list for you all the sub commands that begin with “watch”, and if I type “watch detail”, it will know to find and execute the function which is tied to watch_detail command.

It also accepts parameters – the integer parameter is not required for all functions – many just pass through a 0 and get ignored.

But if you type a number at the end, you can give a parameter to various commands that require it.

Using this system, when I add new features to the ship, I can very quickly ensure (with minimal effort) that the important ship commands are exposed to the text-mode terminal.

And why even ADD the terminal, beyond “it’s cool”?

Well, I’m not saying I’m GOING to hook up a telnet feature where you can control the ship manually that way, but… I’m not saying I WON’T do it, either…