A big part of my absence – for WAAAY longer than I intended – has been work on an operational maritime wargame system. OK, AND I’ve played way to much Civ V and Legendary Heroes…
I’ve dabbled with an operational level maritime game since my increasing dissatisfaction with the Victory Games Fleet Series as it developed. Area movement systems, horribly complex and unworkable “tacti-perational” systems with more subphases than Ptolemy had epi-cycles and wrestling with the twin demons of command and control that was representative of the real world, but did not make the game a bore; and representing the difficulties of ISR over wide areas with the wide variety of assets available.
I’ve had several opportunities to refine the system, one a few years ago that I showed at Connections (still at the Ptolemaic Epicycle stage). I promised a “developer blog” long ago…but real life kept getting in the way. Nearly a year ago I received an opportunity to assault the breech once more, this time for a CNO Rapid Innovation Cell project to create a “sandbox” abstract game amenable to concept exploration and educational purposes.
I happened to have a LOT of my own work lying around, and while this was different sort of animal than what I envisioned originally, much of that work could be adapted for this purpose. Plus the head start my work provided, gave a decent chance of completing a manual game system in the timeframe of a typical CRIC project. And so the Fleet Power Project took a very abstract detour, adapting to become what is now “Fleet Battle School” (FBS).
OK, get the groans out of the way at the Ender’s Game reference, I liked “Fleet Power”, but the customer is always right!
For the game system to be releasable to the public, it had to be rather highly abstract, representing capabilities of ships, submarines, aircraft, and related maritime assets in a way that was representative and internally consistent, but had a “rheostat” that could be adjusted allowing general classes of ships, with varying capabilities, but not intendd to represent actual platforms. This also allowed it be used like the old Traveller Sci-Fi RPG’s “Trillion Credit Squadron” to design your own task force and fight it out with someone else’s. A single supercarrier with 6th fighters and UCAV’s, protected by Super Cruisers? or a half dozen “jeep carriers” with a couple dozen frigates and a motley assortment of “fleet support ships (AKA “steel chaff”).
I have to give kudos’ to Chris Carlson who has been very generous sharing his ideas on the subject of representing capabilities of things in “generational” terms, something I apply much more broadly than he in the Fleet Power Project and refined for this application. The resultant implementation of “capability levels” (CL’s) for nearly every aspect of defining the game units has allowed for representation of relationships in a way that has a grounding in basic physics, with “hooks” to dive deeper if desired for a specific application, but stays abstract enough to be easily understood by non-gamer professionals.
Over the next few weeks, I will discuss the development of FBS as we move from the Beta phase to a final product. That product is not a “game” in the shrink wrap sense, but a “toolbox” of related game systems that can be used at various scales (e.g. 24nm, 32nm or 48nm per hex and “Game Days” divided into 8, 6, or 4 operations phases.)
There are provisions for “open” face-to-face play or “closed” umpired play, and 2 main levels of complexity: a “basic” level for scenarios 3-4 days in length, that leaves out many of the complications of logistics and “friction”, and keeps the “chrome” of column shifts and player decisions to a minimum; and an “advanced” level that can theoretical be used for games of a month or more, but is best for about 2 weeks (where higher operational-strategic decision-making issues become significant).
This adaptability is meant to demonstrate the advantages of a manual game over “black box” computer simulations and allow an analyst or educator to tailor the “playability vs detail” to best achieve the objectives desired. The underlying tables for generating “situational awareness” in an area of interest (a radius around an “OpArea” marker), determining if an encounter occurs when units are in proximity to each other, and then resolving engagements that result are set up as a set of linked excel spreadsheets. The hex scale, certain assumptions about how effective units are at the subtasks underlying the “SA, Encounter, Engagement” model, and what the “steps” are between the various “CL’s” are can be entered as inputs, and the various tables will update themselves.
I’m currently working on the “Design Guide” meant to various ways the game can be played, and the details of what’s “under the hood”. I look forward to comments from the community as I draft that document over the next several weeks. I plan to bring an example game to Connections for Demo night.
Providing a venue to share experiences like this is one of the reasons I started the blog. Hopefully others will get the opportunity to take advantage of it as well.
Paul, will you be bringing FBS to Connections for us to play with?
Very INteresting Paul – I am not a naval gamer usually but the concepts you discuss sound as if they could be adapted to other venues. Will this be strictly a manual game, or does it need to be supported by Excel spreadsheets or other additions?
In the Demo’s we have done, we start with purely manual adjudication to show the details and “roll real dice”. Once you configure the spreadsheet for a given scenario, you can print out the tables and use them manually without further need of a computer. Its fairly time consuming however, as there can be a lot of dice rolling – particularly in air battles.
If you use all the “drill down” sub-phases (BVR, Transition and WVR) and “chrome” table shifts (who gets “advantage” that combat round, morale checks for losses, special capabilities of “high CL” ECM and defensive countermeasures, etc.) a single big air battle could take over an hour. For a lot of applications, you can just total up the missile shots each round, roll on the “M-hits out of N shots” distribution table and allocate the hits. The added resolution of “playing it all through” not adding enough given the time involved. It can be done, however, if the objective is to look at variations in discrete capability differences between aircraft types.
At a “medium” level of detail (resolving each combat round using “advantage” and some chrome shifts) in a basic game scenario, it took a bit over 45 minutes to resolve a multi-axis attack by a 3 Bomber Regiment strike escorted by a Fighter regiment and ECM birds against a Carrier Strike Group. However, given the sporadic nature of the action we got through about one and a half game days in a 4 hour playsession.
Player planning and decision time is the long pole in the tent. Since you plot your “Daily Intentions” (mission, movement and ‘guidence’) for each unit (a group of ships like a Carrier Strike Group, or an Air Wing, with submarines handled indiidually – usually 8-12 units per side) for an entire game day “up front” at the start of the day, thinking through the “major muscle movements” takes a while. You can change the plan as it unfolds, but it generates some adverse column shifts in the basic game, and accruing ‘friction points’ in the advanced game (representing confusion, and mistakes under time pressure without proper briefing etc.).
The big use of the “computer adjudication” as it stands now is to roll lots of dice with a single “F9” press. That cuts the combat adjudicaiton time by a factor of 3 or so. Automating some of the “chrome” with check boxes and “look-up” functions to automactically apply the table shifts could be done, but I haven’t had time…