The third phase of a wargame project is to develop the game and associated components. As indicated in the diagram this consists of three steps.
The development work may be organized within a design-develop cycle. That is: some design work will be carried out, followed by some development work. If we think of counterparts in building a house, the design phase is like developing the blueprint (under the control of the architect) and the develop phase is the actual construction (under control of the contractor). Sometimes during construction an impediment is encountered -- maybe certain materials are not available to the contractor or perhaps the ground is not of the expected consistency. The architect then revises the blueprint passes it back to the contractor for construction to continue.
On a wargame project, the interaction between the Design Phase and Develop Phase may follow a similar cyclic pattern.
Step 7: Develop Scenarios
There is a separate web page on scenarios. It includes various approaches to scenario development as used in both the civilian and military communities.
"Story boarding", a technique from the cinema, can be adapted to this. Essentially a "picture" of critical stages can be developed. This should provide the context for how this "picture" can be presented to the players through the scenario. Of course, as often happens with cinematic "storyboarding", many of the frames of the storyboard are overtaken by events, and are never used in the final film.
The scenario framework (or storyboards) give guidance to further refinement of the scenario, and for other aspects like what data will be required for this (e.g., data on countries, military forces, biographies and positions associated with key leaders).
Step 8: Developing Game Design
The design components of a game may include a composite of some or all of the following elements:Manual Rules: James Dunnigan's Complete Wargames Handbook provides an excellent guide for developing manual rules for a game. Maps and Charts: The geographic context of war games is critical to players awareness of issues. These can either be paper products or computer-based products, e.g., using Google Earth or another geographic information system. Panels of Experts: For particularly complex issues, e.g., the reactions of foreign populations to collateral damage from military operations, experts from a wide variety of disciples may provide illumination. Panels of such experts may be provided directly to players as they tackle problems or they may participate in adjudication to determine how a player interaction will affect subsequent activity in a game. The Canadian Army seminar war games on the "Army of Tomorrow" illustrate the plan to use panels and the results. Adjudication Procedures: Many adjudication procedures can be codified. These codified procedures may take the form of manual rules or of a component within a computer-based simulation. When uncertainly is involved random number draws (likes rolls of dice) may be used to determine the outcome. If the players have visited the consequences of one branh, it may be still necessary to re-visit an adjudication and take a different path, leading to an "alternate future". This approach to investigating a variety of branches and sequels may be needed to insure that all critical aspects of an issue are explored. See US Army doctrine on the need to explore alternate branches and sequels, particularly paragraphs 2-13 and 2-129. Combat Models: Well-crafted combat models can be used to determine outcomes related to detection, to movement, to engagement, and to the consumption of supplies. In cases of well-understood physical aspects, e.g., time and distance, these models are highly effective in determining a plausible outcome.
Step 9: Testing and Rehearsing
Critical thinking should be applied agressively throughout this game development step. When addressing most details of the game design, the study team needs to ask itself: "What can go wrong?"
James Dunnigan, in his Complete Wargames Handbook, comments: "game development... means play testing and changing the game and rewriting the rules and taking a lot of abuse from people who would rather play than design and don't appreciate at all the problems the poor designer has in getting anything done".
He goes on to recommend "blind testing (computer game designers call it beta testing). This is where you take your physical prototype and your written rules and send them out to somebody who can play the game without your presence. This is often very revealing."
Dunnigan later cautions: "You can never test enough -- Testing should use the same procedures applied to software. There are several levels of testing. Unit Testing -- Test individual rule for soundness. Example, test map for completeness and correctness. System Testing -- Test rule along with other rules that it normally operates with. Example, test map with movement and combat rules. Integration Testing -- Test all rules together to see that all parts fit correctly. Validation Testing -- Test entire system to see that all user requirements are met. Acceptance Testing -- User tests to see that all requirements are met."
Dunnigan's recommendations come from an era when game designs, especially those he developed, were still largely based on manual rules (his handbook's first edition dates from 1980). Appropriately adapted, Dunnigan's description of the levels of testing can be applied to seminar war games. However, blind testing of the sort that Dunnigan proposes may not be feasible in seminar war games where the judgement of the facilitator is so crucial in determining how player activity will govern outcomes (i.e., where there are no written rules for adjudication). For such games, completely blind testing may not be appropriate; however, an equivalent level of scrutiny should be applied and the facilitator should work through potential branches that need exploration to ensure they will be handled appropriately during game play.
In addition to components of the game itself, the data collection procedures should also undergo testing.