Chapter 13: Naval, Air, and Specialized Systems

I have designed nearly thirty wargames, and almost all of them are land games. Hex grids, ground formations, supply lines running back to railheads and depots. That is where my experience lives. I have opinions about CRT design that I can defend with data from dozens of development cycles. I have built supply systems tailored to specific theaters and iterated on them across an entire series. I can talk about morale, command, and movement from the position of someone who has made every mistake available and learned from most of them.

Naval and air warfare are different. I have studied them, played games that simulate them, and attempted to design in those spaces. But I do not have the depth of experience in naval and air game design that I have in land combat. This chapter is honest about that. I am not going to pretend I have the same authority here that I have in the preceding eleven chapters. What I can do is orient you toward the design problems that naval and air systems present, point you at the games and designers who have solved those problems well, and share the lessons I learned from my own limited forays into these domains. If your subject demands a naval or air system, this chapter will help you understand what you are getting into. It will not hand you a finished framework. You will need to do additional research, study the games I reference, and in some cases find collaborators who know more than you do.

That last point is the most important thing in this chapter.

Naval Warfare

Naval wargame design operates under a different set of assumptions than land combat. The fundamental dynamics are not the same. On land, terrain dominates. Rivers, mountains, forests, and cities shape movement, restrict avenues of approach, and provide defensive advantages. At sea, the terrain is featureless. There are no ridges to defend, no chokepoints to block, no forests to hide in. What matters is detection, range, speed, and firepower. Naval combat is more an exercise in modeling technical and physical systems than the more ephemeral concerns that drive land warfare: morale, cohesion, command breakdown, the willingness of troops to hold a position under fire.

Ships do not rout. A warship that comes under fire does not break and flee the way an infantry battalion might. It fights until it cannot fight anymore, or it maneuvers to disengage. This changes the texture of the game. In a land game, you are asking whether a formation will hold or collapse. In a naval game, you are asking about positioning. Maneuver is the critical element. Getting your ships into a favorable firing position while denying that position to your opponent is the core decision loop. The combat itself, once ships are in range and bearing, tends to be more deterministic than land combat. Guns fire, shells land, damage accumulates. The uncertainty comes from whether you can achieve the positional advantage in the first place.

The era you are simulating determines almost everything about your naval design. Ancient naval combat, where triremes rammed each other and marines boarded enemy vessels, shares almost nothing mechanically with a World War II carrier engagement fought at ranges of hundreds of miles. Age of sail combat, with its dependence on wind direction and broadside gunnery, demands a different movement and firing system than a modern submarine game where detection is the primary challenge. Even within the twentieth century, the jump from World War I dreadnought engagements to World War II carrier warfare represents a fundamental shift in what the game needs to model. When you choose a naval subject, the era constrains your design more rigidly than it does in land games. The technology defines the tactics to a degree that has no parallel on land.

Hex grids work for tactical naval games where individual ship positioning matters. Players need to track bearing and range for gunnery, and hexes provide the spatial framework for that. At operational and strategic scales, areas work better than hexes for sea movement. The open ocean is vast and homogeneous. Putting a fine hex grid over the North Atlantic creates an overwhelming number of movement options without adding meaningful decisions. Sea zones or areas reduce the spatial problem to its essentials: where are your forces, where are the enemy’s forces, and where do the shipping lanes run.

Avalanche Press’s Great War at Sea series handles the operational-to-tactical transition in a way worth studying. Players plot orders on a strategic map, move forces simultaneously, and then shift to a tactical battle map when opposing forces intercept each other. The dual-map approach separates the two core problems of naval warfare: the search problem, finding the enemy across a vast ocean, and the engagement problem, fighting effectively once contact is made. That separation is clean and reflects how naval operations work. A fleet commander’s first challenge is always knowing where the enemy is. The battle itself comes second.

Jack Greene used staggered movement phases in several of his naval designs, including Royal Navy. The initiative player moves after the non-initiative player, allowing them to react to the opponent’s positioning. This is an attempt to achieve some of the benefits of simultaneous movement, where both sides are adjusting to each other in real time, without the bookkeeping burden of written orders. It produces a reasonable asymmetry: the player with initiative gets the last word on positioning, which is a significant advantage in a domain where maneuver determines everything.

Greene was one of the more experienced naval wargame designers in the hobby, and I learned from him directly when I attempted a standalone World War I naval game early in my design work. I came into the project assuming I knew how to rate warships for a game. My approach was straightforward: multiply a gun’s rate of fire by the shell size to produce a firepower rating. Greene corrected me. The right formula was shell weight multiplied by rate of fire. Shell size, the diameter of the projectile, is not what determines the destructive effect of a hit. Shell weight is. A 12-inch shell and a 14-inch shell may not differ much in diameter, but the heavier shell carries more explosive filler and more kinetic energy at impact. The distinction matters when you are trying to rate the relative firepower of different warships. Greene’s formula became the basis for every ship rating in the game.

I shelved that project. I was fascinated by World War I naval warfare, had read about Jutland and the Dreadnought arms race, and wanted to build a game around those engagements. But as the design progressed, I recognized that my understanding of the subject was not deep enough to produce a compelling standalone game. I could model the gunnery. I could build the ship ratings. But the larger design, the operational framework, the detection mechanics, the way formations maneuvered at fleet scale, required a level of expertise in naval warfare that I did not have. Rather than publish something mediocre, I put it aside. That was the right decision.

Greene passed away recently. His contributions to naval wargaming were substantial and spanned decades of design work. Games like Royal Navy and the naval components he contributed to various projects demonstrate a designer who understood his subject with the kind of depth that produces good simulations. The hobby is poorer for his absence.

Air Warfare

Air power in wargames exists on a spectrum from full abstraction to standalone simulation, and most land wargames stay toward the abstract end for good reason.

The most common approach in land games is to treat air power as a support mechanic. Air units provide column shifts or DRMs during combat, interdict movement in certain hexes, or fly supply missions. The player decides where to allocate a limited air budget each turn, and the effects integrate into the existing ground combat systems. This approach works because it captures the strategic decision, where to commit air assets, without requiring the player to resolve individual air missions through a separate combat system. Most ground commanders did not control the details of how air strikes were executed. They requested support and it either arrived or it did not. A simple allocation mechanic mirrors that experience.

The danger comes when a land game designer tries to model air operations with too much fidelity. I know this from personal experience. The Procedural Combat Series, my operational system, includes an air warfare module that attempts to model a realistic menu of air operations: air commitment to mission boxes, air-to-air combat resolved in two stages, surface-to-air missile fire, on-call recycling, ground support, interdiction, suppression of enemy air defenses, strategic bombing, airmobile operations with their own interception procedures. Each of these individually makes sense. Air-to-air combat happens. SAMs fire at attacking aircraft. Suppression of air defenses is a real mission type. No single rule in the system is unreasonable.

The problem is cumulative. The same air-to-air combat and SAM fire procedures recur inside six or seven different mission contexts. A player resolving a single air strike walks through a procedural chain that touches half a dozen subsystems. A BGG user named rzymek had to create a flowchart to make the air strike resolution sequence comprehensible.

When your players need flowcharts to navigate a support mechanic within a ground game, the system has become too heavy for its role. Air operations in PCS should have been simplified. The procedural weight is excessive for what is, at its core, a modifier on ground combat. I would design it differently today.

The lesson is not that air power should always be simple. The lesson is that the complexity of your air system needs to be proportional to its role in the game. If air power is a support element in a ground war game, it should take minutes to resolve, not tens of minutes. If air power is the central subject of the game, then the complexity is justified because the player is there specifically to engage with those decisions.

Wing Leader by Lee Brimmicombe-Wood, published by GMT, is an example of what happens when a designer builds an air combat game from first principles rather than trying to adapt ground-game conventions to the sky. The most striking design choice is the map orientation. Instead of the traditional top-down hex map, Wing Leader uses a side-view perspective: the X-axis represents the raid path and the Y-axis represents altitude. This is not a gimmick. It reflects a genuine insight about what WWII air combat was about. The tactical problem for fighter controllers and squadron leaders was not navigating a vast horizontal space. It was managing the raid axis and altitude. Where is the bomber stream heading, and can my fighters get above it in time to make an effective pass? The side-view map captures that problem directly.

Wing Leader operates at squadron and flight scale, not individual aircraft. It models formation management and attrition rather than individual dogfights. Units have tally and spotted states that represent situational awareness, whether a formation knows the enemy is there. Cohesion checks model formation breakdown under the stress of combat. Brimmicombe-Wood recognized that WWII air combat, at the scale that mattered operationally, was about whether formations held together and executed their missions, not about individual aces performing aerobatic maneuvers. That insight drove every design decision in the game, and the result is one of the more innovative wargames published in recent years.

DVG has built entire game series around air combat using card-based and tableau systems rather than hex maps, demonstrating that the design space for air warfare is broader than many designers assume. GMT’s catalog includes Downtown, Bloody April, and other titles that find different mechanical solutions to the problem of simulating air operations. If you are designing an air combat game or a game with a significant air component, study these titles. They represent a range of approaches, and understanding what each one chose to model and what it chose to abstract will inform your own design decisions.

When Your Subject Demands Something Different

This chapter is not about ships and aircraft. It is about recognizing when your subject requires mechanics that fall outside the standard hex-and-counter land combat model, and having the honesty to respond to that.

Some conflicts do not fit the conventional wargame framework. A game about submarine warfare in the Battle of the Atlantic is about detection, convoy routing, and attrition over time. Trying to force that into a traditional CRT-driven hex game will produce something that misses what made the campaign unique. A game about the strategic bombing campaign over Germany needs to model industrial targeting, fighter defense allocation, weather over target areas, and the cumulative degradation of infrastructure. These are not problems that standard ground combat mechanics were built to solve.

When you encounter a subject that demands specialized mechanics, you have three options. First, you can do the research and develop the expertise to build those mechanics yourself. This takes time, and it requires genuine humility about what you do not know. Reading one book about carrier warfare does not qualify you to design a carrier combat system. You need to study the existing games in that space, understand why designers made the choices they did, and build your own understanding of the tactical and operational realities before you start writing rules.

Second, you can collaborate with someone who has the expertise you lack. This is what I did with Jack Greene on the naval project. I brought the game design experience. He brought the naval warfare knowledge. The combination produced better ship ratings than either of us would have generated alone. Collaboration is underused in wargame design. Designers tend to work alone, treating the entire project as a solo endeavor. But if your subject spans domains, and many interesting subjects do, finding a collaborator with complementary expertise is not a weakness. It is good design practice.

Third, you can recognize that the subject is not the right fit for you and set it aside. I did this with the World War I naval game. I was interested in the subject, I had done real work on it, and I walked away because I knew the result would not meet my own standards. That is not failure. It is judgment. A designer who publishes a mediocre game about a subject they do not understand well enough has done more damage to their reputation than a designer who never published it at all.

Hybrid Systems and Integrated Designs

Many wargames need to model more than one domain without being a full simulation of each. A game about the Pacific War needs naval, air, and ground components. A game about the Normandy invasion needs amphibious operations, naval gunfire support, airborne drops, and air interdiction alongside the ground campaign. These are integration problems, and they are among the hardest challenges in wargame design.

The temptation is to build a complete subsystem for each domain. Full naval rules, full air rules, full ground rules, all bolted together. The result is usually a monster. The player spends more time switching between subsystems than making strategic decisions. The rules expand to cover the interactions between domains, which multiply faster than designers expect. What happens when an air unit attacks a naval unit? What happens when naval gunfire supports a ground assault against a coastal defense? Each interaction requires its own resolution procedure, and the administrative weight piles up.

The better approach, for most designs, is to identify which domain is the primary focus of your game and build that system at full resolution, then abstract the other domains into support mechanics that feed into the primary system. A game about the ground campaign in Normandy can abstract naval support into a bombardment table and air power into interdiction zones without losing what makes the game interesting. The player’s decisions are about ground maneuver. The naval and air elements create constraints and opportunities within that primary framework.

Games that try to give equal weight to all domains, the true multi-domain simulations, can work, but they require careful integration and a willingness to simplify each individual domain more than a standalone treatment would. The Pacific War games that succeed do so by finding an abstraction level where naval, air, and ground operations can all be resolved with roughly the same mechanical complexity. If your naval system takes thirty minutes to resolve a battle and your ground system takes five, the game is unbalanced regardless of how accurate each system is individually.

Studying Outside Your Comfort Zone

I have spent this entire book telling you to study existing games as part of your design process. That advice applies with even more force when you are working outside your area of expertise. If you are a land game designer attempting a naval game, do not start by designing. Start by playing. Play Great War at Sea. Play Royal Navy. Play War at Sea, the old Avalon Hill classic, and then play a modern treatment of the same subject. Understand what changed between those designs and why. Read the designer notes. Study the ship ratings and figure out how they were derived. Then start designing.

The same applies to air games. Play Wing Leader. Play one of the DVG air combat games. Look at how Downtown handles the integration of air defense networks and strike packages. Understand the design space before you try to occupy it.

And be honest with yourself about whether you understand the subject well enough to design a good game about it. There is no shame in recognizing the limits of your expertise. The shame is in ignoring those limits and publishing something that demonstrates your ignorance to everyone who plays it. Ask for help. Find collaborators. Study the work of designers who know more than you do. That is not a concession. That is how good design works, in this domain and in every other.