In 1994, Jeff Freeman posted to V-Net a set of rules for resolving starship combat. They were simple, elegant, and had an excellent ratio of realism to complexity. Inspired by them, I made an adapted set of rules for smaller fighter craft, which largely mirrored his rules. What's presented here is mostly the same document as I wrote in 1994, though I've done some editing to correct the more egregious examples of bad writing and unclarity. Eventually this will be retooled and made a part of Prism but for now they're here as written all those years ago.
The following rules are a modification to Jeff Freeman's starship design rules, intended for creation of smaller fighter craft, typically with a crew of less than five. These rules work, in most ways, identically to Jeff's starship combat rules. The differences fall in to two categories. First there are different emphases that small craft combat require: emphases on the skills and attributes of individual pilots, on movement and facing, and on maneuverability; and less emphasis on overall ship capabilities, on the use of sensors, and on crew. These changes permeate these rules.
The other class of changes are scale changes: places where the starship rules work the same, but the units are changed. I've made new units via the metric system. Where starships use blocs, fighter craft use cblocs, that is, 1/100th of a bloc. In general you can all but ignore what the unit is; the effect is the same. The reason for the different unit names is twofold: clarity when comparing to starship rules, and the possibility of using both in one battle. (That is not going to be easy, and it will require you to be comfortable with the scaling process. Fortunately, even in mixed battles, the starships focus on one another, and the fighter craft on one another.)
Size units (blocs) are scaled by 100; that is, a cbloc approximately 1/100th the size, in tons or any other equivalent unit, of the size of a starship bloc. Similarly, energy, measured in units in starships, is measured in cunits here.
Distances, however, are scaled by a factor of 10. This means it takes a fighter craft 10 movements of 1 dhex to cover the same distance as 1 hex of a starship. This can become essential in maintaining one map. Time is also on a scale of ten; there are ten dturns (in which a fighter craft may act) in every turn (in which a starship acts). In practice, you will have to count time in dturns, placing the starship's actions between dturns 5 and 6, 15 and 16, etc.
Finally, damage is scaled by a factor of 10. That is, the amount of firepower necessary to take out one bloc is ten times greater than that needed to take out one cbloc. When applying fighter craft dhits to starships, divide by ten and round down; thus, at least 10 dhits are required for the starship to even notice, and many more are likely to be required to get past screens. Only the most superpowered fighter craft can even get the attention of a starship. Going the other way, a starship weapon pointed at a fighter craft does 10 dhits for every hit it would have done against another starship; which is likely to obliterate any fighter craft on a single shot, much like picking off missiles. For this reason, even in mixed battle, craft will "pick on somebody their own size" if they want to stay alive and accomplish something. Note: some scenarios might include a starship with a specific vulnerability making it possible for a fighter craft to do some serious damage to it in some specific way. We all remember a few times that the Rebel Alliance did this to certain moon-sized starships owned by the Empire, for example. This is not covered by the rules; it's a part of a scenario.
Select a craft size, in cblocs. A cbloc is a generic unit of measure which combines mass, volume, and surface area into a single unit. There is 1 cbloc per 0.05 tons displacement (more or less), so a 1-ton craft is a 20-cbloc craft. Some typical sizes: one-man scout: 20 cblocs; one-man fighter: 35 cblocs; heavy one-man fighter: 50 cblocs; two-man fighter: 75 cblocs; small shuttle: 100 cblocs; normal shuttle: 150 cblocs. The Galileo (shuttle of the original Enterprise) would be 125 cbloc; a Babylon 5 Starfury, 60 cblocs.
Most fighter craft are short-range, capable of travel only within a solar system, if even that far, and do not have jump or hyperspace travel; they rely on a mother ship. Some small craft, such as courier craft, are equipped with a jump drive, but this usually precludes almost anything else. A jump drive takes up 20 cblocs and carries enough fuel for two one-parsec jumps.
The sublight drive is the craft's normal method of moving from point A to point B. Hull size (in cblocs) divided by 20 gives the number of cblocs required to achieve movement of one G in one direction.
It is common for a fighter craft to be able to do such accelerations in more than one direction. The Starfury is the perfect example: it can thrust just as hard out the "forward" direction as the backward, and pretty darned hard out the top, bottom, and both sides. In game terms, it would have six drives: a forward and a backward drive, each capable of 3Gs, and top, bottom, left, and right drives, each 1G. Since a Starfury is a 60 cbloc craft, this uses up 3 per G per drive, or 9 + 9 + 3 + 3 + 3 + 3, or 30 cblocs, fully half the craft's hull.
Also note that the "drive" (in game terms) may well consist of several actual drive units, as on a Starfury, where each of the above drives consists of four engines. In fact, virtually any fighter craft drive will consist of two or more engines, so that speed between them can be varied in order to "steer".
Sublight drives require 1 cunits of power per cbloc to operate.
A minimum of 1 cbloc per 10 cblocs of hull must be allocated to armor. That is, a 60-cbloc craft would require 60 / 10 =6 cblocs allocated to armor, at a minimum.
In fighter craft combat, sensors are much less significant and are even optional, since the ranges are close enough that pilots can generally see their opponents. (All spacegoing craft are equipped with basic sensor and communicator technologies, of course; in this, we refer only to stealth sensors.) A sensor takes up 1 cbloc and 1 cunit of power per dhex of range desired, and allows a pilot to scan an opponent's craft and estimate the opponent's strength, power capabilities, etc. (Information available varies with skill of the operator and the technology available in the campaign.) They can also be used to find opponents who are trying to hide behind other crafts or obstacles, or in a craft's "blind spot" (the area or areas where a craft's engine exhausts prevent normal scanning).
Screens absorb 1 dhit per cbloc allocated to screens. Screens require one cunit of power per cbloc to activate. In many cases, screens are not really force shields; instead, they are magnetic fields tuned to the particles beams, seeking to magnetically direct the beam away in part or full.
Beam weapons come in two varieties: fixed and turreted. Fixed beam weapons inflict one dhit per cbloc allocated, but only face in a given direction, and can only be aimed by turning the entire craft's facing. Turreted beams can face at any direction up to 30 degrees from their central aim; they take up as much space as an equivalent fixed beam weapon, plus one cbloc. All beam weapons require one cunit per cbloc. Note that turreted weapons are generally automatically aimed by computer, but if the craft has a gunner to operate the weapon, the gunner's skill at operating such weaponry counts as the skill level rather than that of the computer, the targeting systems adding their bonus to the gunner's skill.
Note that beams can be pulsed bursts of energy, coherent laser beams, particle beams, or anything else of the like; that's just special effects. They all work the same.
Each cbloc allocated to launch tubes allows the craft to fire one missile. Missiles can be instructed before launch to home on a given aspect of a target, such as heat signature, identification signaling, or even color; but they cannot be remotely controlled. However, missiles are able to attack in any direction. One cunit of power is required to fire a missile, but no expenditure is required thereafter.
Each cbloc allocated to missiles provides 5 missiles in storage, instantly available to any tube on the craft. Missiless stored in cargo can be transferred to an empty tube on some turn preceding their launch. However, most craft are too small to have cargo space large enough to store missiles, much less the room for a person to maneuver internally to move the missiles. On many craft, missiles are only loaded from the outside.
Missiles have a rate of movement and a damage value, the sum of which cannot exceed the tech level of the missile. For example, a tech 10 missile could have a move rate of 5 and a damage value of 5, or a 3 move and 7 damage, etc. The move and damage values of the missiles must be determined when the missiles are purchased, either with the craft or when resupplying expended missiles (at the mother ship, starport, or base). Note: these are not anywhere near the same missiles as used on starships; they are much, much smaller.
Each cbloc allocated to power produces 6 cunits of power. Several of the above components require power in order to activate. For example, a 6-cbloc sensor requires 6 cunits of power. If only 5 cunits are available to the sensor, then it acts as a 5-cbloc sensor even though there are still 6 cblocs allocated to it.
Each person that the craft can support will take up 3 cblocs for themselves and the life support systems and other necessities for them. Room for them to move about takes another cbloc; without that, they are strapped in, or in an enclosed area, or otherwise unable to move.
Cargo (holds) require 1 cbloc per 0.05 tons capacity.
Fighter craft may be equipped, to varying degrees, to enter atmospheres, land, take off, or even travel in water or thick gases (as in gas giants). There are four options to purchase:
Land Only: the craft can land on a planet. Cost is 1 cbloc per 50 cblocs of hull size. The craft must be lifted back into space by booster rockets or some other means.
Land And Lift: the craft can land on a planet and also lift back off and leave the planet's gravity well. The craft must have at least one drive capable of more Gs of acceleration than the planet's gravity. Cost is 1 cbloc per 25 cblocs of hull size.
Fly: the craft can act like an airplane in atmosphere, including the ability to land and take off. Leaving the atmosphere requires a drive with at least half as many Gs as the planet's gravity. Cost is 1 cbloc per 10 cblocs of hull size. Since this upgrade won't help if a planet has no atmosphere, a craft might also have Land Only or Land And Lift for use on planets without atmospheres.
Thick-Fluid Flight: as Fly, but also enables flight in fluids much thicker than air, such as water or extremely dense gases. Only available to crafts that have the Fly capability already; cost is an additional 1 cbloc per 30 cblocs of hull size.
None of these require any power beyond that of their drives. The space allocation is used up in aerodynamic shaping, aerofoils, landing gear, more versatile atmospheric seals capable of withstanding atmospheres, shielding of delicate parts, etc.
The Damage Allocation Sheet is used to apply hits to the craft. Each box () on the damage allocation sheet corresponds with one cbloc. When a component takes a hit, one box corresponding to that component is filled in (or X'ed out or whatever) to indicate that the component has been damaged. A six-cbloc sensor is reduced to a 5-cbloc sensor with one hit, 4-cblocs with another, etc.
Here is a sample Damage Allocation Sheet for a 60-cbloc Starfury:
Back drive (3G)
Front drive (3G)
Left drive (1G)
Right drive (1G)
Top drive (1G)
Bottom drive (1G)
Fixed beam weapon, facing forward
Crew: one pilot, fixed in position
Here's the Babylon 5 raider delta-wing, a 40-cbloc craft:
Back drive (2G)
Sensors, range 3 dhexes
Fixed beam weapon, facing forward
Crew: one pilot, fixed in position
Cargo: 0.25 tons
Fly in standard atmosphere
Here's the Galileo (from ST:TOS, I don't know what if anything they did with it in TNG et. al.), with 125 cblocs:
Back Drive (2G)
Sensors, range 10 dhexes
Fixed beam weapon, facing forward *
Crew: 2 people
Crew: 2 people
Crew: 2 people
Crew: 2 people
Cargo: 0.6 tons
Cargo: 0.6 tons
Land and Lift in standard atmospheres
* Did the Galileo have any weaponry? I couldn't remember so I gave it a tiny one. If it should have more, take it from cargo; if less, put those 2 back into cargo.
Each craft needs a damage chart, so that when a hit is applied the GM (or player) can roll to see which component is effected. With the 60-cbloc Starfury chart above, the easiest method is to either roll d% and reroll rolls over 60, or to just get a computer to roll a d60 directly. A single cbloc can only be destroyed once; if it is hit again, reroll. Note: skilled gunners might target and destroy a specific system with a "called shot" (GM's discretion).
Craft are assumed to have navigational computers (which are used to control and coordinate guns, multiple engines, etc.), basic sensors, communications systems, docking capabilities, etc. These are assumed to be duplicated or protected well enough that the only damage to them which needs to be reflected is already represented in damage to the other components. GM's discretion for damage to communications systems.
Before beginning combat, the GM needs to think about handling of movement and make a few decisions.
With small fighter craft, the intricacies of maneuverability, position, speed, and facing, in a 3D space, become infinitely important than they are in the much simpler situation of large starships at great distances without much by way of facing. It is tempting for a GM to simplify starship combat, by making movement be in any direction, with no regards to facing, in two dimensions, and without acceleration concerns. This takes away considerably from the flavor of small craft combat. On the other hand, a full implementation of 3D combat with craft position, facing, and velocity in three directions, can be dizzying, not to mention tedious. The following system is the best compromise I could come up with.
The GM should choose, in advance, if combat will be 2D or 3D. In 2D combat, all facings, directions, and positions shall remain on one plane; there is no use for top or bottom mounted drives or weapons. Most of the time you'll use this mode, as 3D requires some dizzying thinking and is tricky to keep track of on a map. Ship designers should be warned and not spend any cblocs on top or bottom mounted drives and weapons if this is your plan.
The remainder of this document assumes 2D combat. 3D combat works the same except instead of a hex map, you need to track actual vectors in 3D space for both location and speed. Since 3D maps are largely impossible, I'd only consider this if it could be computerized. I'd like to develop this alternative but it doesn't exist for now.
Ship location, speed, and course can be randomly determined or based on the courses of crafts, or their deployment from other ships. A craft can detect other crafts at a range of 20 dhexes; a craft with sensors can add twice the sensor's range to this maximum detection range. If a larger ship is nearby, it can relay telemetry readings from its much-longer-range sensors if it wishes. However, the effective range of craft-based weaponry is only 15 dhexes.
Each combat dturn is divided into the following dphases. Actions within each dphase are executed in order by the reaction speed (Quickness, Dexterity, or equivalent) of each pilot.
Optional Rule 1: add a random factor by rolling a die and adding to each Quickness stat; the size of the die depends upon the type of stats used in your system, but should be about one-third the effective stat range. For instance, on 3-18 stats, use a d6; on 1-100 stats, use a d20; on stats running from -25 to +25, use a d10 or d12. It doesn't really matter what, so long as you're consistent.
Optional Rule 2: on weaponry dphases use the Quickness of the gunner in those crafts with a separate gunner; crafts without will use the pilot's Quickness with a small penalty (again, size depends on the stats used in your system).
Remember, these are dturns and dphases, one-tenth the size of starship turns and phases. Starships act after the 5th, 15th, 25th, etc. dturn.
If you have sensors, you can get the results of any scans they do, at the beginning of this dphase.
Each cbloc you allocated during design to power production gives you 5 cunits of power. Sublight drives, screens, beams, and tubes require power to operate. You may purposely underpower any of these. Since most crafts are designed with sufficient power to operate every component at max, this step can actually be skipped until the power supply suffers damage. Allocation might take some foresight because you have to allocate power to components you won't be using for several dphases.
If you fire no drives, your movement is identical to your movement the previous round. Otherwise, add movement to your previous movement equal tot he number of G's you apply. Craft with multiple drives can fire more than one (if sufficient power is available).
Remember that movements are vectors, that is, they have both magnitude and direction. A craft not moving, facing to the top of the map, which fires its rear thrusters at 3G, is now moving 3 dhexes per dturn topwards. If on the next dturn the pilot fires hir front thrusters at 2G, sie is now moving 1dhex per dturn topwards. Yes, this is a lot more complex than starship movement. There's really no way to make it any simpler than this without making fighter craft combat nothing more than "HO-scale starship combat".
This can get tricky is someone thrusts at a different direction than they are currently moving. For example, someone going 3 dhexes/dturn topwards has rotated left one hex-side; they then thrust at 3G. Rather than trying to add these together, the GM should track it as 3 topwards, 3 top-left-wards. When he moves, just do one move, then the other, like moving a chess knight.
When the moves get too complex, the GM can "normalize" the movement. The easiest way to do this is to do the move, then figure out a simpler way of accomplishing the same thing. For example, consider a ship moving 3 topwards and facing bottom-left-wards, which fires thrusters at 3G. It is now moving 3 top, 3 bottom-left.
Starting from A, they move 3 topwards to B, then three bottomleftwards to C. The GM can simplify this by changing the velocity to 3 topleftwards.
Note that when doing these multiple-step moves, the ship doesn't really do it in these steps, it takes the most direct route from start to finish; so the question of whether it collides with anything depends only on that path.
This may seem tricky, but it's not. The only way it can get tricky is if someone wants to cancel all movement and is moving in several directions at differing speeds; but even then, it's no big deal, since you don't have to figure out exactly how many Gs they need to fire at, only if it's less than what they can fire at.
Most players, used to thinking of cars that turn their velocity and facing together, or planes which turn by banking, will need to have the point made to them that facing and velocity are totally independent. It may also help to make very clear to them that a velocity that the GM is keeping track of as several different-direction velocities, is really one velocity. Unless all involved craft have engines in many directions, better have a big sheet of hex paper for your first few battles.
During this dphase you can change the facing of your craft by up to 60 degrees around one axis. In 2D space, you can rotate one hex-side of facing. Facing will affect what weapons you can bring to bear and also which of your drives are usable.
Generally, the GM will only allow rotations in full or half hex-sides (that is, in multiples of 30 degrees) just to keep things sane. Sometimes you will need a smaller rotation to bring a weapon to bear on an opponent. In this case, the GM will allow you to fire partway through the rotation, or actually, to "have fired" partway through the rotation, since by the time dphase 4 comes up and you can fire, the rotation will have finished.
Beams may be fired at any target which is within range (15 dhexes) and within the area a beam weapon can fire. The gunner must make a skill roll based on a Gunnery skill (or equivalent) to try to hit. Craft without gunners can rely on the pilot's skill (with a penalty for being so busy flying the craft) or a computer's skill at the same. Note: this roll only takes into account aim issues; it does not account for defenses. This roll should be modified by a -5% (scale according to the dice you use) for every dhex/dturn of movements of the target.
Optional Rule 1: movement towards or away from the gunner does not count; only use the "transverse" movement.
Optional Rule 2: give a penalty of -5% for every dhex more than five of distance between the craft.
If the beam hits, see Inflicting Damage below.
Any missiles launched during preceding dturns proceed at their rate of speed (in dhexes/dturn) according to their programming. If a missile reaches a target, it will inflict damage on the target; see Inflicting Damage below. Note: the missile's programming can be misinterpreted by the simplistic computer on the missile. Generally, missiles follow sensors in front of them; if two equally likely targets are in front, it is equally likely that they will follow either one. Those who can't shoot down a missile can, if they fly well enough, confuse the missile into following someone else, possibly even the one who fired it.
Missiles may be launched with any programming desired. Note: programming more complex than a single condition will take several rounds, require a skill roll, and may even be impossible, depending upon the missiles. Missiles appear one dhex away from the firing craft, in a direction chosen by the person firing them.
Calculate damage for each beam or missile separately. Beams inflict one dhit (one tenth of a starship "hit") per cbloc allocated to the weapon. Missiles inflict one dhit per damage value of the missile.
Screens: screens absorb one dhit in 6. For beams, take the number of dhits, divide by six and round down. If you roll below the remainder on a d6, add one. This is the number of dhits absorbed by screens. The maximum number of dhits absorbed by screens is equal to the screen power level.
For missiles, screens repel whole missiles, not individual dhits. One missile in six will penetrate, up to a maximum missile count equal to the screen power level. Add up the dhits of all missiles which got through.
Apply one dhit to armor, if any remains.
Randomly choose a cbloc to be hit. This destroys that cbloc and uses one dhit.
If any dhits remain, go to step 2.
Most components have their effective cbloc rating reduced when they are hit. For instance, a 3-dhex sensor system (3 cblocs) hit once now works like a 2-dhex (2 cbloc) sensor system. For sublight drives, a certain number of cblocs is required for each G of acceleration; if cblocs are lost, so are the corresponding Gs. For example, the Starfury has 9 cblocs to produce 3G in its rear engines. If a Starfury take a single dhit to one of those cblocs, the drive has only 8 cblocs and is thus only capable of 2G. Jump drives do not work at all if any of their cblocs are destroyed. Atmosphere capabilities will be seriously hampered if up to 1/10th of their cblocs are destroyed, and useless at more than 1/10th.