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.