A lot got done in the last little while. In short:

• Selectors and movement code on the sector map
• Scanning UI
• Map Rendering moved into a generic function
• Animated ships
• Action Queues
• New Turn Logic & Interface
• Quadrant View!
• Tons ‘o refactoring

So let’s get into what I did and why…

Let’s kick off with the refactoring to get that out of the way…

Refactoring

Most of this was just taking temp code and moving it into the engine code – making it re-usable and configurable. Notably, this included the ‘Terminal’ objects. They’re widgets now, like everything, handled by the UIManager. Thing is, in practice these are… no longer ‘terminals’. Rather than keep the vestigial name I’m kinda thinking in future I’ll change them to a ‘textfield’ with an in-built terminal mode. (Terminal mode being, in this case, the ability to handle text entry into the field.)

But that’s a future-Elissa problem.

With that out of the way, let’s have a little look at where we are now…

Scanning, Movement and Selector UI

You can now select a direction to move in – for now just using the WASD keys, but buttons on-screen are coming soon too.

There’s also a ‘selector’ – the square, dashed, white object. It can be moved with the arrow keys, and is used to target weapons at things – or scan them. When scanning, a white circle that animates is drawn on the map, to indicate that your scanners will be trained on that tile next turn.

Map Rendering as a Generic Function – and ship animations

My old map rendering code was… well, clumsy. It iterated just fine over the sector, but it also directly used the Love2d draw functions, so had to be run each frame. This isn’t what I want from the game engine, so instead I moved it to a generic ‘run once and forget’ bit of code that creates a lot of Image objects, allowing for animated ones.

Ships are now rendered (and stored) in a better way. Before, while just hacking the look together, it rendered your ship… and your ship only.

I now track ships as a list within each sector, so iterate over them and use their own custom looks.

The up-shot is that (as you can see in the top-most image) there’s now an enemy class of gunship that I’ll be using to code and test the combat and basic AI systems soon.

It also, in theory, means I can create multiple maps if I want. Not sure just why yet, but if I wanted a ship with separate quadrant & sector displays, that’d be quite doable now without re-writing any code.

The ship rendering is still my least-favourite bit of temp art, but the pieces are in place.

Ships now have multiple layers – the base layer, the ‘damage’ layer (applied over the top to show hull damage), the ‘engines’ layer (a flickering engine animation which is visible when the ship has its engines powered up), and finally the ‘active’ layer – lights that turn on when the ship’s main reactor is up and running.

Sensors!

Whatever your selector is over, the top-left data display now shows what you know about the object. This includes, for planets such as this, basic information – if it’s colonised, the class, the population, etc.

In future it will also contain information about what minerals are on the planet once you scan it.

If you select any object in the sector, it’ll show similar contextually relevant information – even on blank space. For instance, if an enemy ship is hiding and the sector display shows some hazy distortion over certain parts of the map indicating there’s a chance an enemy ship is there, moving the cursor over it will show you a rough % chance that a ship is there. Based off this information, the player can select which tile to hit ‘scan’ on.

Aaaand… Action!

Movement works now, but in order to do that… end-turn logic needed to be built.

Enter does the trick, as does the ‘Done’ button (which I will probably change to something less silly-sounding later).

You can queue up multiple actions – the player can perform a movement, a scanning action, and fire any number of weapons they have ready to fire. Just which actions are queued up are now listed on the bottom-right display, above the ‘done’ / next turn button.

This seems minimalist now, but with spinning up / powering up weapon systems, targeting ships, opening torpedo bays and firing all as separate actions, in a fight this screen could easily have up to 8-9 actions on it.

At some point I’ll likely need to add in scrolling functionality for these displays, for this reason.

QUADRANT VIEW – Finally!

When you click the (visually bespoke) button on the bottom-right of the main view screen now (or hit the tab button) it toggles between SEC view and QDT view.

The “Quadrant” view in the original Star Trek game, as expected for a game designed to play on a line printer attached to a minicomputer, displayed each sector as numbers. Number of stars, space stations, and klingon ships.

While numbers alone would fit with a kind of “ultra-retro” aesthetic for this game, it’s just not very fun. So I decided on something else – the screen is designed to have the room to show 12×12 location tiles, with 16px by 16px sprites. This also means, given quadrants are also 12×12 sectors, that I could render a high level view of them – with room the spare.

So, the middle 12 pixels of each tile now contains coloured pixels for the static objects that your computer knows about – stars, planets, space stations. I’m conscious of colour-blindness being an issue, so I’m going to make sure that despite the colours of those tiny pixels MEANING something for experienced players – no information is given that can’t be gotten in other ways. There will be a ‘sector selector’ icon too, like in sector mode, which lets you look at a tile and get details on the top-left display.

Aaand that’s about it for this past fortnight.

Next is… more ship logic, and combat, I think.

Exciting!