When I first sat down to write this, I thought maybe I’d gotten to do it for another fortnight again, like last time. But no, I just got a crapton done because I’m off work fro the year so I’ve been working almost full-time on Deck & Conn for a few days now.

Here’s where we’re at now…

What’s Up?

So, in short here’s what I’ve done since last time:

• Full implementation of the reactor, batteries, auxiliary power units, helm, and sensors as they relate to states and power systems.
• Re-factored the way the panels are drawn, with art now being done in greyscale with colour applied procedurally during rendering. This gives me more options to tweak the whole colour of all our background panel assets.
• Moved around all of how the art pipeline worked.

It’s… been a busy week. So here’s a breakdown of what I did…

The Back-End

From a back-end perspective, the reactor, batteries, APU and such all now work. It generates and draws power from what’s running, and all the UI for those items is now in place.

The start-up process for the ship from cold ‘n dark is now about 70% done. It looks something like this:

Items in brackets are optional.

1. Start the APU
2. (Turn on APU pump if you’re in a hurry)
3. Wait until you have the APU running
4. (Turn on the APU vents if you want)
5. When you have about 4-5kWh of power stored in your batteries, start your reactor
6. Once the reactor is up, or about to be up, turn off the APU to stop burning fuel
7. Switch reactor mods if you want – low / reduced power gives you less power but also emits less radiation to give away your permission
8. Power up the helm, sensors and other systems

The Front-End

As you can see above, I’ve done a LOT of UI work. There’s now many more button types, interfaces and displays.

Atop of that, I’ve also changed the panel graphics so they’re greyscale, with colour applied during rendering. This means a lot of things that need specific colours now have multiple layers – the panels now have a _panel asset and _panel_decals asset, with only the former getting colour applied to it during the rendering stage.

I’ve also spent a bit of time figuring out precise layouts. For a relatively simple game, there’s a lot that needs to be crammed onto the screen. Not all of it can fit at once, so some things will have to be buried under options.

For now at least, I’ve decided to put the non-combat and ship-movement features below the main screen. (Mags is to magnetise the hull – that is, turn on shields.)

This leaves me with two major spaces left on the screen – bottom-left quadrant, and some space below the sensor panel at the top-left.

I think I will, for now, put weapons top-left, and given there’s still TONS of stuff left to add (crew details, damage control, communications) I’m going to put those inside a display, with modes you can toggle between.

That’s not coded yet, but it’s coming soon. What also needs to be done then, is given the switches used elsewhere on the screen are intended to be diegetic buttons and switches, I will need to make a new set of UI that looks like the kind of simple buttons and window icons you’d find in the retro-futuristic look of these terminals. I may end up basing this UI loosely off early graphical OSs and window managers such as Atari TOS or early Macintosh system versions.

I will avoid the “black on white” look though, as it’d be a bit jarring next to the muted greens and browns that make up the rest of the screen.

Utilities and Workflow

Beyond this, I’ve also re-factored how my art is pipelined into my project.

I’ve now got a python script that takes all the .aseprite files from certain “live” folders (“w” for widgets, “r” for room objects, “i” for general images, etc) and spits out the layers with the folder name as a prefix.

So this means that my button.aseprite file in “w” for widgets will be exported as w_button_unpressed, w_button_pressed, etc.

This took quite a few hours all-in but it dramatically reduces the workload and chance of human error when adding new assets for the game.

I’m not quite there yet either, but in theory you can delete the entire gfx/ folder and the script will re-create all the game assets from the working art folder.

What Next?

So, as I mentioned above, I’ve got a lot of time on my hands between now and the 9th.

So my plan for the next week will probably be something like this:

• Implement the ‘shipboard terminal’ on the bottom-left
• Add magnetic shielding
• Add weapons UI
• Implement FTL drive functionality and the ability to move from sector to sector
• Damage and the Damage Control terminal
• Emissions & Scanning

Honestly, that’s easily over a week’s work. But we’ll see how I go…

Long-term? My goal is, if possible Alpha in January, Beta in February, and release some time in March.

In practice I may not hit these, but it’s good to have goals to try and hit, even if you miss them by a bit.

As for what those terms mean in this case…

• Alpha will be the core game mechanics all in place. Ship movement, combat, simple AI
• Beta will be the core game mechanics and the meta-game mechanics too – missions, patrols, crew management, etc
• Release is… well, probably early access to be honest. I will release on Windows and macOS to start with on itch, with Linux (x64 and arm64) at some point later on. If it does okay, I may even look at Steam after Itch is all up and running.

Wish me luck!