Vebber started with a general information on gaming and game design he uses for audiences that are less familiar with gaming. While not the focus of the talk, I wanted to highlight two of his graphics, both of which provide some useful synthesis of recent debates on the nature of gaming. The first integrates the “cycle of research” with some of our recent discussion about what type of logic is used in games to generate new knowledge.
The second discusses the relationship between OR analysis, gaming, and the level of problem, which is a common concern in my work and the broader field.
My interest in broad methods issues aside, Vebber’s presentation was focused on a overview of the current state of the Fleet Battle School game sandbox.
The core goal of the project was to design a capability game to determine what point does the change in capability cause changes in player decision making. As a result, the platform should have the ability to support very interesting sensitivity analysis about the intersection of combat effectiveness and decision making that is often elided or ignored in current gaming.
Right now the focus of the Fleet Battle School game is weapons and sensor capabilities of different platforms (though features like speed and fuel use are also built into the current rules). The game instantiates relative differences in capability rather than trying to mimic specific current capabilities. While you can input values that mimic specific real world platforms, that isn’t really the focus of the project. Again the focus here is how the ratio between different platforms’ capabilities impacts player decision making. As a result, the adjudication model was built to focus on plausible results, rather than claiming any type of predictive power.
Fleet Battle School is a digital platform for naval operations planning game built on krigspiel principles (that is rigid rules for physical movement and combat, in contrast to a seminar table top game that would use looser rules focused on organization and political decision making). The system allows the game designer to edit the map terrain, platform capabilities, order of battle, and rules (though some programming skills are needed for really deep changes here) within the game platform.
The game also allows for multiple “levels” of players on both the blue and red team, so that the gap between commanders and line officers can be included in the game. The commander can set a daily intent, individual “officers” can then set more specific orders which the commander then approves and submits. C2 is largely handled outside of the game platform in order to accommodate different networks, but it will require that C2 be documented outside of the platform.
The system can then either auto-adjudicate or allow an umpire to override outcomes either in all cases or only in less probable die rolls. There are also some nuanced setting to represent friction that can also allow penalization of bad leadership and declining capabilities over long deployments.
That’s all is a pretty superficial description of the platform and its capabilities, but if all this sounds interesting, I would urge folks to check out the Wargaming Connections blog where Paul has posted more materials in association with the launch of the beta.
One point that I think is critical to highlight is the way Vebber’s development experience also allowed the project to avoid many common pitfalls with computer game development in the government. This has been a long development process with lots of paper playtesting, use of off the shelf products for some game functions where appropriate, and “good enough” graphics until end-users articular clear priorities. Having been involved in computer game development from within the government, I’ve seen how a lot of these can go wrong, so in many ways I think Fleet Battle School is a great case study about how to do this kind of development. Vebber’s regular and detailed updated on the development process should be a reference to anyone attempting this kind of project in the future.