Yesterday, we spoke briefly of what’s getting left out of Random Carrier Battles’ first playable prototype. Today, we’ll cover the happier side of that story: what’s in!

UI stuff
I have some informational interface tasks to take care of, to allow players to view task force members and elements of air groups. I figure to stick this on the left side of the main UI.

Some aircraft design improvements
I believe I’ll need to make some tweaks to aircraft and escort design, to specify quality of armament: the early use of the TBF Avenger was hampered by the poor quality of the Mark 13 air-launched torpedo, and I can’t capture that in the system as is. Similarly, British battlecruisers, German pocket battleships, and Yamato aren’t well-captured by the system as is. (Battlecruisers, in this framing, would be heavy cruisers with good guns; Scharnhorst would be battleships with poor guns, and Yamato would be a battleship with good guns.) Although surface combat is out of scope for the initial prototype, I want to have enough data to do a passable job at it when I come to it.

I may also have to make radios a feature of airplane design, so that types with historically good radios can communicate better than types with historically poor radios.

Aircraft handling: repair, fueling, arming, launching, recovery
Aircraft handling is a big focus of Random Carrier Battles: more than previous games in the carriers-at-war genre, I want to get down into the weeds. I want to track aircraft status to a fine-grained level of detail, down to how far along arming and fueling have progressed, or how warmed-up the engine is. On deck, I don’t think I plan to track exactly where planes are spotted, but I may do some tracking of takeoff run available—this would penalize light aircraft carriers with large air wings by preventing them from launching everything in one go, which is, in my view, a feature.

In terms of discrete development tasks, I’ll have to figure out how to turn a designed air group into an air group instance in the game world, build systems to hold air operations status and control transitions between air operations states, and build UI to control it all.

This feature will also lay the groundwork for land-based airfields, as well as seaplane tenders and seaplane-carrying cruisers.

Air combat!
Making this one heading is perhaps a bit ambitious on my part, but there you are. Air combat has a bevy of subordinate features, including representing armaments (to give damage) and ship and aircraft systems (to take damage), a planner for missions, and unit combat behavior AI.

Systems and armaments are the easiest of the bunch; they merely involve defining a set of systems for each class of asset, along with a set of armaments generated from the asset’s statistics and arming status.

The mission planner is a complicated feature, and one which I hope will be industry-leading: a central clearinghouse where admirals can view all missions currently planned or in progress, create new missions, cancel unlaunched missions, and eventually, handle every air operation in the task force. For now, it may fall to players to prepare the aircraft assigned to missions on their own initiative, depending on how the aircraft handling features shake out.

Finally, combat behavior AI: this is by far the biggest feature under this heading, and the hardest to handle. It includes automatic marshaling of air groups (players won’t have direct control over aircraft in flight), CAP behavior, scout plane behavior, strike planes’ flights to their targets, and attack behavior for dive bombers and torpedo bombers. Ships will also have to maneuver under direct attack (that is, to avoid incoming torpedoes, and to throw off dive bombers’ aim).

Initial spotting and scouting
Spotting and scouting in their fullness will require a lot of work, so I’m going to build a simpler system to start with. Simply put, you can see everything on your side, and anything within horizon range of your ships and planes.

Submarines will come later.

That’s that! I hope you find these plans as exciting as I do. I hope to get the demo to a state where I can take some usable screenshots and videos and submit to Steam Greenlight, at which point I’ll be hitting you up for upvotes.

Good afternoon, and happy Thanksgiving! While sitting here watching the turkey and the giblet broth, I had some time to work out a little roadmap for taking Random Carrier Battles from its current state, barely above proof of concept that the Godot engine is suitable for this purpose, to a playable prototype (if one that doesn’t capture my full vision).

So, to get the ugly out of the way first, let’s talk about what I’m leaving (for now) on the cutting room floor.

Wind and weather
Though they are crucial parts of aviation, they’re incredibly complicated, and I want to do them right the first time, rather than hacking something together now. With modern processors and multi-threading, I can push weather simulation into the background and only update every few in-game minutes, which leaves me lots of time to try interesting simulation techniques. ‘Interesting’, as I said, is a synonym for ‘hard’, and so I won’t be exploring these yet.

Land-based air
It may turn out that the mechanics of land-based air—launching and recovery—is a freebie based on doing carrier-based air. If it isn’t, though, I’ll tackle it later, along with design for land-based types like multi-engine bombers and flying boats.

Full visibility and spotting system
My plan for Random Carrier Battles is to attempt to capture just how blind carrier admirals were a lot of the time. Enemy positions will only be known by spotting reports, and allied air positions will only be known with full precision when they can be seen from friendly task forces. All of that will require a detailed system for spotting and visibility, and a system for displaying and archiving spotting reports. It’s less straightforward than it sounds, since the AI (when that arrives) will need access to that information for its fleet. Speaking of…

Artificial intelligence
I may provide some sort of rudimentary AI, but I may also leave it more or less entirely to scripting, or give the computer perfect knowledge. Don’t expect anything amazing, at any rate.

So, what does that leave to do? Nothing less than the core of the game. Come back tomorrow or Saturday for details!

I spent some time the other day playing the old-school DOS version of the current state of the art in carrier air warfare simulations, SSG’s 1992 classic appropriately entitled titled Carriers at War. As far as DOS-era wargames go, it’s pretty good—it doesn’t bother you with too many details, and it (largely) lets you focus on the grander strategy. I really blew the Battle of Midway as the Americans, though.

So, let’s talk about a way in which I hope to improve on the old classic: movement. Carriers at War plays out on a 20-mile hex grid; Random Carrier Battles currently tracks positions down to 10 meters; rather than a five-minute time step, I use a six-second timestep (organized into ten steps per one-minute turn) for movement and combat. This lets me do all sorts of fun things which 1992’s processing power did not allow, which I’ll get to shortly. It also causes me a great deal of trouble, which I’ll gripe about first.

The short version is, the kinematics are hard.

The slightly longer version is, there’s a lot of math involved in working out just how game entities ought to move. Warships aren’t much of a problem, because it turns out that warship maneuvering is pretty straightforward¹. Aircraft, however, get a little tough. Not only do I have to consider everything I do with warships, I have to account for performance differences at altitude, as well as rates of climb and descent beyond which aircraft must either decelerate or accelerate. I don’t have the design fully worked out for that yet, I’m afraid, so I can’t say much more yet. Rest assured it’s complicated.

So, what does that enhanced positional and temporal resolution buy me above Carriers at War?

Better simulation of strike range
This is the biggest win, in my opinion. With such a high temporal and positional resolution, I can simulate fuel consumption to a much greater level of accuracy. As such, I don’t need to limit myself to Carriers at War’s fixed strike ranges². The TBD, for instance, gets a with-torpedo range of 90 miles. I’ve seen other figures give a combat radius of 150 miles, and still others give a range (not radius) of 435 miles with a torpedo. By tracking fuel, I can, to some degree, ignore the trickier combat radius figures², and simply grab a plausible cruise range figure. If I mix in some reasonable modifiers for speed, altitude, weight, climbing and descending, and maneuvering, suddenly I have a system which doesn’t need to work with combat radius at all. Players can launch strikes well beyond range if they want to; they just need to know that they’ll have to either deal with losing planes to fuel exhaustion, or follow the strike with their carriers.

Realistic combat behavior
The level of detail in kinematics, and the short time step, lets me make emergent some behaviors which might otherwise be the result of dice rolls. For instance, are Devastators running in on your carriers? Turn away from them, and the slothful American torpedo bombers will have to chase you, running their fuel down and exposing them to the depredations of your CAP and your escorts’ AA. Dive bombers rolling in on you? Throw the helm hard over to throw off their aim.

Many of these behaviors can be made to happen automatically: ships under dive bomb attack will make evasive turns on their own, for one. I haven’t yet decided which behaviors will end up being automatic, and which will be tactics set up by the player, but my aim is to do the low-hanging fruit for the player.

A notable exception to the above model is air combat: my current expectation is that the six-second combat step will prove too large for air combat (and relatedly, that emergent air combat behaviors will prove very complicated to code), and that the best way to handle it will be to put planes into a furball object inside which combat is handled in an abstract manner.

Exploration of unexplored formation options
Allowing the player relatively detailed control over formations, and keeping track of positions in similar detail, allows players to try some unusual tactical ideas. For example, the Japanese were not in possession of shipboard radars until fairly late in the game. What if, in some hypothetical battle, they detached some escorts from the main task force to make a search line a few miles toward the threat? Perhaps they could better direct their CAP to meet incoming threats.

That’s only one example. Undoubtedly there are others which haven’t occurred to me yet.

Those are at least a selection of the benefits of an approach with a greater focus on direct simulation, as opposed to a more traditional hex and counter approach. We’ll see how they turn out.

1. At least to the fidelity I plan to simulate. There are lots of fascinating behaviors when you introduce multiple screws into the mix, but given that Random Carrier Battles is still, at its essence, a game of task forces, I don’t intend to allow players to give orders that detailed.
2. The reason they’re so fiddly is that nobody ever talks about their assumptions: what load, exactly, constitutes a combat load? Is range deducted for reserve fuel and the time spent forming up? Are allowances made for maneuvering over the target? These are three of many questions left unacknowledged by most authors of military references.

Coming soon, or at least at some point down the line, from the Softworks division of Many Words Press, Random Carrier Battles:

Random Carrier Battles is a computer wargame simulating aircraft carrier warfare at the operational level between the mid-1930s and the end of the Second World War. It features a user-friendly design system for carriers, escorts, and aircraft, along with a large library of predefined types for your convenience. Planned features include a scenario editor and a random scenario generator, along with some premade scenarios covering major battles in the Second World War.

If you listened to Episode 12 of The Crossbox Podcast, you’ll remember my goal for the design system: create something just complex enough to adequately capture the different schools of carrier design in the era in question.

In scenarios, the player fills the role of the admiral in command, controlling the composition and disposition of the task force or task forces under his control, as well as the tempo and target of air operations. Hands-on admirals will be able to control aircraft handling down to the individual plane aboard their carriers; big-picture admirals will be able to delegate those to the computer.

Both kinds of admiral will have plenty to sink their teeth into strategically: Random Carrier Battles will accurately model the uncertainties inherent in carrier warfare, including incorrect spotting reports and communications failures, incomplete information about enemies, and lack of direct control over aircraft.

Obviously, this project is still in its infancy. I’ll be blogging about the development process here (at least until it’s far enough along for its own website), and sharing more screenshots and videos as things progress. Stay tuned for more information in the months to come!