The CNO’s Rapid Innovation Cell (CRIC) was interested in creating a wargame which would be accessible to a wide audience and allow for experimentation with new approaches and technologies (and how those affected decisions in the operational naval war). The goal was a game in which the effects which occurred in the game were in line with those which would be observed in a much more detailed game. However, we wanted to keep it both more streamlined (to allow it to be played more quickly than a professional wargame) and less specific (so we could eventually share it with a wider crowd of naval game players over the internet). I discuss the game objectives in more detail on the CRIC podcast with Jeff Anderson and Matt Hipple, and a blog post coming soon on CIMSEC.
Paul Vebber’s Fleet Power system provided an excellent place from which to start, since its abstract approach made it much easier to play than a wargame with more complicated set of rules. The idea was that we could create a game where you could replay a scenario over again, to try different decisions and see how it changed the game. We also envisioned eventually being able to design your own fleets (or at least create your own order of battle), and potentially introduce new technologies to see how it would change the game. Does a laser really herald a new era of naval warfare? Or is it “too little, too late?” How many third-generation aircraft does it take to bring down a flight of fifth-generation aircraft?
As we got further into play-testing, we started to find more and more places where we wanted to deviate from the Fleet Power system to try to make a game that was more “playable.” At the end of the day, Fleet Battle School is supposed to be a game that’s relatively easy to sit down and play. We felt it was better to have a game that you could play through again and again rather than trying to model every possible engagement precisely.
So as we’ve started to look forward for how to put together a beta version of the game that we can release onto the world, I would be very interested in figuring out how we can make the Fleet Battle School variant of Fleet Power a better (and frankly, more fun) game. Paul provides an overview of the Fleet Power system here, and I wanted to discuss some of the ways which we leverage the system to create a game that is enjoyable enough that you can sit down with a beer and play through a game, but with enough realism that you’ll buy a helicopter pilot a drink out of appreciation for a task that you might not have understood before.
- We really wanted to focus on the non-umpired version of the game. There’s certainly a lot to be said for a closed game, especially when you are trying to play a cat-and-mouse game. We considered including rules for dummy units to try to offer some opportunity for concealment. Frankly, though, we found that we learned a lot more about naval warfare and the effects of our decisions in playing an open game. In playtesting, we had some phenomenal arguments discussions on how well different sensors performed, and in trying to understand what effect sensing had on the game, this was much more valuable than driving around in the dark. However, this does makes decoy and deception very hard. (We also found that submarines had to be tracked on a separate piece of paper which each player hid from the other.)
- The game is still played with 3-hour turns, but we didn’t divide them up into impulses – all movement was resolved at the same time. We found at 24-mile hexes and 150-mile megahexes, it tended not to matter too much when each side moved. If we wanted to have all the impulses for the few instances where it did matter, it would add hours to the play time. To compensate, during the air phase, we created a priority in air missions so airborne early warning and defensive counter-air missions would be in the air the whole turn, and offensive counter-air and strike missions would move in sequence to allow the fighters to clear the airspace for the bombers.
- We also scrapped the advanced game ATO, but I’m not sure that’s the right answer. The system we used assumed a constant sortie generation rate throughout the day, but it doesn’t allow you to scramble all of your aircraft into a single strike, which is really needed if you’re playing at an air disadvantage and need to get in a lucky strike against a very capable air force. I’m looking for feedback on better ways to manage aircraft.
- Paul’s system has a well-researched model for damage control, which we had debates about throughout the entire project. He had a very complex system for managing different size warheads that I personally found totally cumbersome (and that, frankly, we never used during gameplay). I’ve tried an alternative method that we used in early play-testing where the damage roll is resolved down to a single die-roll to see if the ship is mission-killed, which accounts for the cumulative probability that total number of incoming warheads would have hit something critical. However, I’m still struggling with a good way to model damage to carriers and airfields – the size of both means that a single missile hit isn’t going to take out a critical system, and you’re almost more interested in destroying aircraft on deck than sinking the carrier. I would welcome people’s thoughts on how to model carrier damage.
- We kept the basic command and control system of Fleet Power; it was the big appeal of using that system. It is incredibly concise and streamlines a lot of the complication associated with planning in a wargame. However, rather than track friction points, we simplified it so each orders change entails a 1R shift to all rolls. (That means, on the engagement table, you roll one column to the right, which is bad.) Though, while Fleet Power provides a great menu of order options, planning out your first day’s move tends to still be the most time-consuming part of playtests.
Right now, there’s a very rough alpha test version of the game. It’s principally designed to be playing with a voiceover to help talk through the game, but I’m willing to share (@Chris_Kona) if you are particularly interested in seeing and testing our approach (milSuite link coming soon). We’re certainly interested in hearing your thoughts. As Paul Vebber has mentioned before, this is all leading up to a demo at Connections in August, so hopefully we can share a full beta version after that.