Aerial Combat is kind of specialized and has different needs than some other TTRPGs like fantasy games many of which use an I go you go turn system and a random initiative.

As I was reading Speed of Heat a supplement that relies on Air Power I see that it uses a long 12 second turn with a number of phases and the loser of initiative goes first to give the winner the advantage of seeing the opponents moves before acting. Starfinder‘s starship combat uses this method as does Battletech.

What I’m worried about are recreating certain aerial maneuvers like loops. In an I go you go system the opponent who won initiative goes first, moved and fires on their turn which means if the winner was in the lead position they do some fantastic maneuver get into position behind their opponent and fire.

If the winner was in the chase position they just fire and take a victory lap.

In typical I go you go systems like Pathfinder and Dungeons and Dragons the player being fired upon has a static defense as well as some reactions they can use at anytime to protect them.

I am thinking that a system called punctuated real time would help here. Let’s say for example both jet fighters are the same with equally skilled pilots.

The chase fighter during its turn gets behind the lead fighter and targets them with a missile or guns. If the lead pilot becomes aware of the attack they could break left or right, launch flares or chaff to avoid the incoming attack. The pilot could also pull into a loop trying to break the opponent’s target lock.

Any of these moves would take some time to resolve. Players would move their initiative token down the tracker by an amount of time equal to the action they are taking. Equally matched fighters and pilots might go back and forth without scoring a kill.

In practice the differences between aircraft capabilities and pilot skill as well as variables like starting speed and altitude will change that dynamic.

In the Korean war US pilots were told not to get into turning fights with MiG fighters which could turn tighter than the Saber jets. This would make for a faster turn for the MiG and a shorter time on the initiative tracker.

What they found out in practice was the MiGs had manual controls the pilot would force the joystick in the direction of the turn pulling on cables and moving flaps to execute the turn.

The Saber jet pilot would see the MiGs turn and move to follow the MiG, pushing the Saber’s stick over which activated hydraulic systems that operate the flaps and the Saber enters the turn. The hydraulic system was faster to activate than the manual controls.

Airplanes operate differently at different speeds and altitudes which affects how wide a turn is, how many Gs push on the pilot and how long an action takes. Pilots of faster climbing aircraft will climb out of problems, for example as they seek to exploit the differences in capabilities to their advantage.

As we explore these differences a static turn system where the opponent is paused during the other player’s turn won’t serve us well. A full real time system might not do well either, we may not care about managing every degree of a turn or loop until the maneuver is complete, waiting instead until the opponent does something you need to react to.

If a ground based opponent detects enemy aircraft and launches a surface to air missile the missile will take time to reach its target and the pilot will have the opportunity to deploy countermeasures and attempt maneuvers which will all go into the initiative tracker.

If a fighter picks up an enemy aircraft on radar, but has rules of engagement that require visual confirmation then the time it takes to get into visual range goes into the initiative tracker. If an early Soviet fighter is directed by ground control radar operators they can’t engage until they get into visual range and that travel time goes into the initiative tracker.

At least in theory.

I’d like to break all these things up into their smallest component parts and then see if lumping them into abstract actions and reactions loses too much depth in favor of fast gameplay.

Manual controls are slower to initiate than other methods. Imagine a car without power steering and power brakes.

Hydraulic controls are faster than manual controls, but slower than fly by wire, imagine a car with power steering and power brakes.

Electro-mechanical controls are faster than manual or hydraulic controls, smaller and lighter.

All of the above controls are used to maneuver an aircraft where its natural state is straight and level flight.

Fly by wire systems can use computers to stabilize unstable aircraft designs. The car analogies are traction control, stability control, and anti-lock brakes all of those do things the driver is physically incapable of by using computers, sensors and timing doing things faster than the driver could. The unstable aircraft designs do not naturally assume a position of straight and level flight, this  instability makes them more maneuverable. An example would be a very shallow boat hull, it is not deep therefore not stable, but it is also not constantly fighting friction of water against the hull just to maneuver. Aircraft like this have multiple computer systems to prevent a total systems failure.

So I would make a chart for these different systems and make either a time to effect for real time or an initiative penalty for abstracted RPGs. Some systems with more dynamic initiatives could have two different planes start on the same count and the one with the slower control systems would change it’s initiative to one worse. Over time the two fighters make the same maneuvers, but without some drastic change the lead of the faster fighter would become insurmountable. The slower fighter might attempt tighter turns, paying for their turning deficit with their body and their airframe, I read somewhere a pilot calls this using G for brains. Pulling Gs to get you out of trouble will deplete your aircraft’s energy and probably lose you the fight.

If you have any feedback about this post or our books please feel free to contact us.

Paul

Evilrobotgames at Gmail.com