Perseus Patrol devlog #4: Combat engagements

If you have tried my pre-alpha demo at demo.perseuspatrol.com, you noticed that one major component is missing from the game loop: tactical combat.

This week I want to unpack what I have envisioned to build in 2026 into the above demo, how it plays into the other game mechanics and how the story can utilize greatly these engagements.

First of all, let’s recount the past games I will use as inspiration for this:

• Star Trek Armada I - II: for their controls, fleet a management and crew systems,
• Homeworld: for their scale, mobile manufacturing and large tactical engagements,
• StarCraft I - II: for their action, controllability and easy overview,
• Imperium Galactica II: the battles relating to planets and colonies, however the actual engagements are pretty dated and usually auto-played,
• Supreme Commander: multiple scale at the same time running in parallel,
• Space Rangers I - II: variability of the engaging ships, subsystems and role-playing elements.
• Ground Control series: their focus on greatly progressing the story with each mission.

A twist idea: using the pre-planning of the mission element from The Sting! One of my favourite games of my childhood with its wonky art style, the logical puzzles and still unique fun to this day.

Designing for a website has limitation. Additionally I like to switch up my platforms, sometimes I just want to tap slowly on idle on my iPad, sometimes I want more action and active gaming.

Type of engagements

I started thinking of two major types of engagements I want to be able to play in my game: surface and orbital!

Orbit/space

Initial idea to show scale of capital ships against more moderate sized fregates, small crafts:

Surface

More conventional approach is perfectly working from e.g. the C&C series, twisted with the “The Sting”’s planning style gameplay:

Idea bag for components to be built into the game:

• Ground objects: terrain (sand, soil, rock), water (river, lake), roads (width defines type), walls (brick, stone, concrete), roof (concrete, tiles), foliage, impassable.
• Unit types: infantry, exoskeleton, armored vehicle, tank, helicopter, fighterjet.
• Weapons: railguns (from pistols to artillery), explosives, missiles.
• Technical layers: terrain, routing, visibility, firing range.

Layered combat

If I introduce the concept of multiple parallel layers for the combat field, I get a more streamlined combat engagement concept. I can turn on and off some layers to focus action into smaller space. Additionally, I can introduce very complex strategic thinking into the game as units can have different limitations how they can interact:

• Subsurface: e.g. submarines, underground bases and installations.
• Surface: conventional bases, factories, civilian structures, gun placements, mobile units, etc.
• Aerial: flying units like more conventional airplanes, fighters, helicopters.
• Atmospheric: most crafts Steeldome can deploy operates mostly on this layer for bombing runs and other attack supports, high atmospheric operations that currently stratofortress bombers can achieve.
• Orbit: to simplify user interactions, the vast space of orbit is condensed into one layer with easy automatic non-collision between units, except the massively sized carriers and battleships, like Steeldome itself.
• Deep space: e.g. the carrier Steeldome and its escort fleet, opposing carriers, capital ships and other units in reserve, essentially not in the action yet.

Sectorial combat

The layers by themselves still constitute an absolutely enormous space where action could take space. In order to further confine the player into a tactical situation where unit level actions make sense, I would model the engagement space as a square frustum:

In this case, the layers would follow from the top to bottom, smallest the subsurface and largest is the orbit. Deep space is represented as reserve unit list that can be deployed but takes time for them to arrive to orbit.

Putting together the two:

Phases of combat engagements

Entry points

Two ways to start one:

• game forces the player to deal with it,
• player chooses to escalate by engaging.

Either way, when the combat starts, the game needs to do a few things:

• set up the combat field, based on the location, it generates terrain, places structures on surface or in orbit,
• then collects the sides or groups in the vicinity who can deploy units to the sector,
• and for each group, it collects all units already in location (due to mobilization actions), then all units close enough to act as reserve.

When these are all done, the game sets up the combat engagement and displays it to the player in a dialog window. Starts as paused and the player can plan their immediate actions, including what units to deploy from reserve.

Playing the combat engagement

Here using “The Sting”’s core gameplay loop during the heists, we can imagine some steps:

1. Deploy from reserve
   1. Initiate deploy by drag dropping from reserve line to map location
   2. Emphasize arrival of reserve unit when timer is up
2. For each unit:
   1. Move unit
   2. Task unit
   3. Withdraw unit
3. Move timeline
   1. Forward to see play out
   2. Backward to change decisions

Exiting a combat engagement

Repeat above steps until the player is satisfied with the result or all player units have withdrawn from the sector. If engagement ends by withdrawing or all units destroyed but there is more than one group left in the sector, calculate a probably outcome.

E.g. Civilian settlement, Pirate raiders and Steeldome are all in the sector. If Steeldome loses all crafts, it can not safely bombard or engage pirate raiders directly, hence player withdraws the mothership before all raiders are destroyed. In this case, remaining raiders power is used to sack the civilian settlement, resulting in dissatisfaction toward you and the Federation.

Story during an engagement

In special engagements or when special, named units appear, the story may progress by the in-combat decisions. E.g. destroying a hunted pirate or separatist leader, or losing a named craft yourself, etc.

In these cases, acknowledgement and dialogue pre-scripted will play out on the combat radios. There is no private chatter or dialogue decisions happening during the combat engagements. We deal with the consequences after the combat resolved using the visual novel style storytelling. I will write a bit more about the story presentation in next devlog entry.

Visual design

The Operations Room meets Lines on Maps:

UI/UX crosses Armada, StarCraft and Homeworld:

The major elements above:

• left selector buttons switch between your own units,
• left selected unit actions on the bottom show what can be done with the selected owned unit,
• right selector buttons switch between targeting hostile or friendly units with color coding,
• right selected target unit state and actions show what is the observed hostile or friend is up to,
• bottom timeline shows all major events and planned elements as markers, where you can move the timeline to specific point and control replaying.
• top line used for more complex menus, status messages, goal tracking and resource tracking, as even Steeldome’s manufacturing is not stopping during the engagement!

I need to ideate about how to represent the battle layers for the player and to be able to switch fluently between.

Summary

All this long ideation session and the above points became muddled and diluted. Let’s recap:

• with 6 layers, 5 combat active and 1 reserve layer,
• with a square frustum sector space,
• and plenty of units to command,
• in a real time but plannable strategic view.

I think this will bring some new life to tactical/strategy gaming if I can make this work.

Next task on this front is to create a proof of concept. Not connected to the current demo yet. As I can separate this into a micro-service, having input and output specifications well defined.