So here’s the big idea with this thing. It’s a custom-built (probably wood) control panel that uses arcade buttons, RGB LED lights other electronics geegaws to connect to the computer running the game, and thanks to a programmable controller -either an Arduino Leonardo or Teensy 3.1- will appear to be just another keyboard to the system. The controller will contain the code that translates a given button press to a keyboard character (or combination of keys) that the game expects to see for its command inputs.
With me so far? Good.
So here are the controls as I’ve laid them out in Sketchup. I’ll only discuss the special features of certain buttons or controls, because if you play the game, you can probably already tell by the button legends. If you don’t play the game, you won’t really care what they do in the game anyway, now will you? 🙂
Why does that matter? Because I’m going to have the CommandStation offer realtime feedback based on what’s going on in the game. For example:\
That “GEAR” button will control the landing gear of the ship. It’s a toggle control, and in the game, the only indicator anything is happening is a relatively quiet sound effect, followed by a little blue indicator in the corner of the game dashboard coming on (or winking out, if the gear is being retracted).
I can make that simple and otherwise boring little thing more interactive. Imagine this: you’re piloting your ship in to a station to land. As you approach your landing pad, you tap the GEAR button, which immediately turns yellow and flashes. Meanwhile, the game recognized the command, so you hear the ship’s landing gear dropping, and after a few seconds, the GEAR button turns solid red, just as the in-game gear indicator comes on.
That was an overly-long description of a very simple process, but you should get the idea about what I’m going for now. I want this panel to change button colors based on the state of their controlled game element. The TGT SUB (target subsystems) buttons, for example, won’t be lit at all unless another ship has actually been targeted. Most of the controls will actually go dark while performing a hyperspace jump, because those components are intentionally functionless in the game in that mode anyway.
The red/yellow/green progress bar is an idea I had to mimic the progress bars of multiple functions of the game. For example, triggering a discovery scan will cause that bar to light up and fill as the scan gets closer to completion. As a small aside, the panel will allow the player to just hit the SCAN DSC button once, and it will hold the command down in the game for the amount of time it takes a scan to complete. Without this, players have to hold down the assigned button or trigger until the scan is done.
These buttons are not used for the game, but are reserved for the panel itself. PWR is of course the power switch for the whole device, which is driven by a re-purposed PC power supply. BTN MODE is a kind of pause button, which temporarily suspends the panel’s communication with the game, and allows the user to change a button’s mode that has fallen out of sync with the game somehow. For example, the game crashes as the ship is in flight, but when it’s re-loaded, the player is back in the station they launched from. Now the panel shows the gear is up, but naturally that’s not possible if the ship is now once again landed. Pressing BTN MODE will allow the player to update the CommandStation to match the game’s actual state of a given control, without sending that control’s command to the game in the process. After changing any necessary controls, the player hits BTN MODE again to restore normal functionality. [UPDATE: this example is no longer relevant, because respawn events are reported in the player journal, and the watchdog app on the PC could detect this and tell the CommandrStation controller to set the button lights to reflect the “docked” or “landed” state automatically.]
Again, keeping the concepts of interactive feedback in mind, this button will change color to red and blink to indicate the panel is not sending signals to the computer.
These are a concept I’m really wanting to include, especially now that the game provides a realtime local journal which we can read, and use code to determine different values of the game state, such as current amount of cash in the player’s account. The top display shows just that, denoted by the ($:) symbol.
The line underneath (F:) shows total fines/bounties levied against the player.
On the second display, the (B:) line shows how much the player has accrued in bounties that are waiting to be cashed-in.
The (C:) line shows how many cargo slots are still open on the ship.
On the right side of the cabinet, you can see the external side of the PC power supply, which brings me to the internals:
This is a very rough idea of what it will look like under the front panel. The part the player sees will be made of semi-opaque white plexiglass that has a printed clear vinyl label applied. The label will be mostly black, but where the gaps in the print are, the backlighting will show through. The backlights are composed of strips of LEDs (yet more WS2812 units, for fine control of colors and levels). Since there will be so many of the darned things, the PC power supply there will be providing the juice for them. The programmable controller is also powered from this supply. Normally, those controllers could just power themselves off the USB connection to the computer, but in this case, I want to avoid the situation where the controller is powered, but none of the lights are. This could cause some problems in the code when it comes time to start changing the lights around.