Document COMAF02 Revision 1.

4
Author Leo Lam Date 09/09/06

Software
Requirements
Specification

PROJECT COMAF

- Combat Manoeuvres Framework -

DETAILS
Project Title Combat Manoeuvres Framework (COMAF)
System/Subsystem Title Phase 1
Document Issue Date 09/09/2006

APPROVAL

Page 1 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

Checked by Name Signature Date

Author Leo Lam
Technical Approval Paul Beckett
Project Manager Paul Beckett

Revision History
REVISIONS
Version Primary Authors Description of Version Date
1.0 Leo Lam First draft 18/02/2005
1.1 Leo Lam Adjustments for Build 1 15/03/2005
1.2 Leo Lam Updated requirements for Build 1 22/05/2005
1.3 Leo Lam Updated requirements for Build 2 18/11/2005
1.4 Leo Lam Updated requirements for Build 3 05/09/2006

Page 2 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

Table of Contents

Revision History........................................................................................................................ 2
Table of Contents...................................................................................................................... 3
1.0 Introduction.................................................................................................................... 4
1.1 Purpose of the document........................................................................................... 4
1.2 Scope......................................................................................................................... 4
1.3 Definitions and Acronyms........................................................................................... 4
1.4 References................................................................................................................. 5
1.5 Document Overview................................................................................................... 5
2.0 Product Overview........................................................................................................... 7
2.1 Product Perspective................................................................................................... 9
2.1.1 System Interfaces................................................................................................ 9
2.1.2 User Interfaces.................................................................................................... 9
2.1.3 Hardware Interfaces............................................................................................ 9
2.1.4 Software Interfaces............................................................................................. 9
2.1.5 Communication Interfaces...................................................................................9
2.1.6 Memory Constraints............................................................................................ 9
2.2 Product Functions..................................................................................................... 10
2.3 User Characteristics................................................................................................. 10
2.4 Constraints................................................................................................................ 11
2.5 Assumptions and Dependencies..............................................................................11
2.6 Apportioning of Requirements..................................................................................11
3.0 Requirements............................................................................................................... 12
3.1 (F) Functional Requirements....................................................................................12
3.2 (I) External Interface Requirements..........................................................................13
3.3 (P) Performance Requirements................................................................................14
3.4 (D) Design Constraints.............................................................................................14
3.5 (Q) Quality Attributes................................................................................................ 14
4.0 Use Cases and Processes........................................................................................... 15
4.1 Functional Requirements..........................................................................................15
Appendix A. Additional Design Considerations.......................................................................17
A1. Combat Function Requirements...............................................................................17
A2. Design Rationale...................................................................................................... 18
A3. Proposed Simulation Components Design...............................................................19
A4. Use Case Scenarios.................................................................................................20
A5. Sample Interfaces..................................................................................................... 22

Page 3 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

1.0 Introduction
1.1 Purpose of the document
This document outlines the software requirements of Project COMAF (Combat Manoeuvres
Framework), intended for the project manager and development personnel to understand the
overall product perspective, and the finer requirements of the product itself.

1.2 Scope
The COMAF project involves the development of a software application framework aimed at
furthering the research on fostering strategy learning through game technologies. COMAF is
based on a previous study by DSTO and RMIT to study commercial off the shelf game
packages in relations to aiding the Army’s manoeuvrist training [1].

The products of this project include:

 COMAF Framework source code

 COMAF Game application

The COMAF framework is responsible for providing a high-level API for developing
applications that can be used in manoeuvrist games. The internals of the framework shall
provide the event handling, object management, scene management, graphical displays and
multi-user controls. The demo application is an extension of the framework by providing a
functional application that uses the framework.

1.3 Definitions and Acronyms

COMAF – Combat Manoeuvres Framework – A software framework that provides the
foundation of building games or training applications for combat manoeuvres and tactical
training.

COMAF Application – A derivative work of COMAF. Refers to a simulation or game that is

written using COMAF as the foundation.

SDD – Software Design Document: Internal designs of the software system – Aimed at
developers.

SDLC – Software Development Lifecycle: A process that describes how software is built.

SDP – Software Development Plan: A general planning document outlining various aspects of
the project.

SRS – Software Requirements Specification: The document that outlines major project
requirements, features to be included in the application.

Page 4 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

1.4 References
[1] P. Beckett, L. Lam, G. Galanis, Battle Map Scenario Game Project: Literature Survey
Report, Royal Melbourne Institute of Technology & Land Operations Division (DSTO), 2003

[2] ”Fundamentals of Land Warfare", Australian Army publications [Online] Available:

http://www.defence.gov.au/army/LWD1/LWD1sitemap.htm

1.5 Document Overview

The latter sections of the software requirements specification are organised as follow:

Section 2 provides an overview on the product design and its intended purpose, complete
with the essential design principles and product perspectives.

Section 3 contains the actual requirements of COMAF, arranged in the following categories:

Section 3.1 (F) Functional requirements

Section 3.2 (I) External interface
requirements
Section 3.3 (P) Performance requirements
Section 3.4 (D) Design constraints
Section 3.5 (Q) Quality attributes

Requirements blocks in Section 3. should be interpreted as shown in the following Figure.

Identifier Requirement Rationale
Statement

Source Priority Other Attributes Status

Identifier: Each requirement will be labelled with a unique identifier. The requirement may
be referred to in other documents using that identifier. The identifier may not be reused by
other requirements in the event that this requirement becomes obsolete.

Requirements Statement: The text of the requirement.

Source: The source or origin of the requirement. The source may be a person or a
reference to another requirement.

Rationale: The reasoning behind the requirement. This field may sometimes be left empty if
the source of the requirement is another requirement.

Priority: The priority of a requirement may be indicated by the number of stars as follows:

 Suggestion
 Desirable
 Important

Page 5 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

 Very Important

 Essential

Other Attributes: Other attributes may be assigned to requirements to support development

needs.

Status: The status of the requirement shall be indicated by a status bar that highlights the
following levels of progression:

V Passed validation review

C Passed content review
Q Passed quality review
A Approved for implementation
D Requirement accounted for in design
I Implemented
T Tested

Section 4 presents alternative views of requirement attributes.

Page 6 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

2.0 Product Overview

COMAF is a product designed for one purpose: To enable the simulation (and training) of
strategic and tactical manoeuvres from the military and psychological point of views. It is to
provide an environment where tactical simulations can be played out and the decisions to be
reviewed by experts.

COMAF is based upon the “Manoeuvrist Approach” to land combat as specified by the
Australian Army’s Fundamentals of Land Warfare [2]. The key focus of this approach is
outlined in this statement:

“… manoeuvre theory regards war as a competition based in time and space rather than on
spatial position alone in which the ability to maintain a higher tempo of operations relative to
the enemy’s creates opportunities for defeating the enemy’s centre of gravity. Manoeuvre
theory is based on a profound understanding of the enemy, and particularly how the enemy’s
perceived strengths can be undermined. The theory also assumes a detailed knowledge of
friendly forces, and the neutral or non-combatant parties within and outside the battle space.”

– Fundamentals of Land Warfare, Australian Army publication

The essential enabling concepts for the manoeuvrist approach include:

 Joint warfighting – the ability to use the techniques and capabilities of each
service in campaigns such that the effects will be greater than the sum of the
parts.

 Combined arms teams, including combat, combat support and combat service
support elements, employed in a mutually supportive manner that allows the
Army to operate in a broad range of situations.

 Combat function capability, describing the range of actions that land forces must
be able to undertake to apply land power. The Combat Functions will a key
attribute of a trainer targeting train battle tactics, leadership and command skills.

Figure 1. Combat Functions (from [2])

The key combat functions that are required in the battle space training systems are described
below and in Figure 1.. These functions were used as the principles for the development of
COMAF:

 Know: the capacity to predict, detect, recognise and understand the strengths,
vulnerabilities and opportunities available within the battle space.

Page 7 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

 Shape: to engage in actions that enhance the position of the friendly force, delay
the enemy’s response, or lead the enemy into an inadequate or inappropriate
response in order to set the conditions for decisive action.
 Strike: to apply tailored effects in a timely fashion. Striking requires the precise
integration and application of force at selected points in the battle space to
achieve specific outcomes.
 Shield: to protect friendly forces and infrastructure. Shielding is achieved by
measures that include avoiding detection, and protection against physical or
electronic attack.
 Adapt: to respond effectively to a change in situation or task, recognizing the
chaotic nature of war and continuously updating procedures and plans.
 Sustain: to provide appropriate and timely support to all forces including the
provision of stocks, replacement of weapon systems and reinforcements.

COMAF is designed to accommodate a simple, gaming environment with the primary

characteristics as listed below. It is expected that an application derived from COMAF will
exhibit these desirable characteristics:

 Game Playing – To allow the mental training of the concepts via abstract game
playing that may detract from common tactical trainers focusing on realism.
 Allow professional mastery of the concepts being trained, through the use of
games.
 Allow commanders to operate against a thinking opponent in two-sided free-play
exercises.
 Support rigorous evaluation and objective feedback.
 Support the close simulation of battle conditions – preparing individuals and
teams for the stress of combat.

The subsequent sections shall provide more information on various aspects of COMAF,
including its interfaces, functions (including design rationales), assumptions and constraints.

Page 8 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

2.1 Product Perspective

COMAF is self-contained; it is not related to any larger systems but rather a framework upon
which other applications will depend.

2.1.1 System Interfaces

COMAF shall interface with at least one of the common operating systems, including
Windows (2000/XP), Linux/Unix and Mac OSX.

2.1.2 User Interfaces

As COMAF is a framework that provides the core functionalities, its interfaces are limited to
those that relate to the application developer. As a rule, COMAF shall provide programming
interfaces for at least one common programming language, including C++ and Java.

2.1.3 Hardware Interfaces

COMAF shall interface with any common PCs with a processing speed of 1GHz and above,
with standard video cards (8Mb video RAM or more), networking hardware (LAN), standard
input devices including mouse and keyboard.

2.1.4 Software Interfaces

There are several required software products that COMAF shall rely upon, including:

 Graphics Library (3D/2D)

 Networking Library
 Discrete Event Simulation Library
 GUI Library

2.1.5 Communication Interfaces

COMAF shall interface with UDP/TCP networking protocols in the aims of providing multi-user
capabilities via LAN.

2.1.6 Memory Constraints

COMAF shall require extensive memory usage and it is therefore required to have at least
512MB RAM available for use.

Page 9 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

2.2 Product Functions

COMAF is expected to facilitate a number of features that assists in manoeuvrist training.
These features are as follows:

1. Manoeuvrist Simulation. The principle function of COMAF is to provide a simulated

environment that exhibits, or allows the user to perform a series of actions that will
lead to behaviours as dictated in the Manoeuvrist Approach. These include:

 The five combat functions – Shape, Shield, Strike, Sustain and Adapt, of
which adapt is one of the more valuable functions that should be a major
focus of design. (Please refer to Appendix A for more information on what
these combat functions imply for the actual operations of applications derived
from COMAF.)
 The “Centre of Gravity” – Behaviours of panic shall be displayed when this is
destroyed.
 The enemy’s “Determination” – Dictated by various circumstances, which
shall be modifiable.

2. Game Playing. By nature, COMAF is designed to facilitate game playing as a form

of training on the tactical and operational (strategic) level. Applications derived from
COMAF shall provide multiplayer capabilities (and single player as an AI component
becomes available) for at least two players over an established networking
environment.

3. Strategic Planning. COMAF Applications shall also allow the “After Action Reviews”
for evaluation and revision of tactics. Accurate data that describes the events and
decisions made in the scenario shall be required for analysis.

4. Behaviour Modelling. As part of depicting as accurate a battlefield model as

possible using abstract concepts, COMAF shall cater for some simple ‘rules’ that will
guide the game entities so that they will exhibit simulated manoeuvrist behaviours in
their responses.

All major requirements shall revolve around these four product functions. As there are
numerous issues related to these, please refer to Appendix A for additional information that
will provide better understanding of these issues.

2.3 User Characteristics

Three types of users have been identified for project COMAF:

1. Army Personnel – These are the trainers/trainees who will be the ‘game players’ of
COMAF applications. They have limited exposure to the finer technical details of the
simulations but may be well versed in computer game playing in one form or another.

2. Psychologists / Human Factor Experts – The human subject experts may benefit from
the use of COMAF applications to model behaviour for simulated objects, and
observe how they may influence decision making and reactions on the field. They
have limited computer experience, and would prefer a Windows-like interface to
conduct their work.

3. Developers – This group of users are theoretically the main users of COMAF, as they
will be utilising COMAF for developing applications. Developers are expected to be
highly experienced in the technical and design aspects of COMAF.

Page 10 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

2.4 Constraints
Constraints that might affect the COMAF requirements are listed below.

 Copyright Licensing. COMAF’s licensing model has yet to be determined, although the
general direction is towards open source. The licensing model employed (LGPL, GPL,
MPL/BSD, Proprietary) will influence the selection of software packages as they carry
various licenses that may be unsuitable for COMAF development. Some libraries that
have been investigated to date are open source, but attract a fee for commercial use.

 Hardware Limitations. While it is the aim of COMAF’s authors to minimize the hardware
requirements, resource limits may affect the feasibility of implement some of COMAF’s
functionalities, including the choice of computer language and runtime environment.

 Validation Methods. A proper evaluation model has yet to be developed to provide the
necessary guidelines to validate COMAF’s simulation output.

 External Interfaces. As COMAF is dependent on external package(s) to provide specific

functionalities such as graphics display and simulation modelling, the performance and
adaptability of the chosen packages may have an impact on achieving the requirements.

 Human Interfaces. COMAF is developed jointly by DSTO and RMIT, comprising of

stakeholders (and users) from many areas of expertise. The functionality of COMAF
applications, especially in the human interfaces part, will largely depend on feedback from
these users. It is possible that interface-related requirements are affected as a result.

2.5 Assumptions and Dependencies

The following assumptions are depended upon for the established requirements:

 The Manoeuvrist Approach is the only doctrine to be referred to in regards to the military
aspects of COMAF.

 COMAF will run within a client/server environment.

2.6 Apportioning of Requirements

Requirements that may be delayed fall into two categories:

1. Simulation-related: These include some of the finer requirements that may depend
on the choice of simulation model(s) to be used.

2. Interface related: The design of the interface will be affected by feedback from the
stakeholders in regards to the actual operations and functionality of the software.

Page 11 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

3.0 Requirements
This section provides a comprehensive description of the organisation of the project, including
the organisational structure, individual responsibilities, and the life-cycle model to be used in
the project. Only general requirements are listed here – Specific details such as game rules
and game features would be defined more clearly in the Software Design Document.

Please note that “COMAF” signifies the underlying API framework, and “COMAF Application”
refers to a simulation or game that is written using COMAF as the foundation (See Section
1.3. Definitions).

3.1 (F) Functional Requirements

F1 COMAF shall be able to operate with the simulation environment through the processing of game
entities.
L. Lam Controlling the operations of game entities is the key function of the framework.
 Build 1 VCQ A DIT

F2 COMAF shall be able to operate on a common terrain format.

L. Lam Based on the assumption that the game shall operate on an open terrain.
 Build 1 VCQ A DIT

F3 COMAF shall maintain a list of internal orders for the simulation environment in order to make
changes to the terrain and game entities during the game.
L. Lam In order to keep coherence to a maximum, COMAF should delegate as much of the maintenance
functions to the application as possible.
 Build 1 VCQ A DIT

F4 COMAF shall be able to guide game entities in performing simple, automated tasks, including
navigation and communicating with the player.
L. Lam The internal operations of game entities will be handled by COMAF. Most of these functions are
‘common sense’ tasks or reactions to the surrounding environment.
 Build 1 VCQ A DIT

F5 COMAF shall be able to operate independently regardless of the choice of GUI or graphical
interface.
L. Lam It is a desirable goal to make COMAF portable to other applications that may have different rules
or styles of play.
 Build 1 VCQ A DIT

F6 The COMAF application shall support multiplayer games of two players.

L. Lam
 Build 2 VCQ A DIT

F7 The COMAF application shall allow the game to operate in real-time (i.e. not turn-based).
L. Lam
 Build 1 VCQ A DIT

F8 The COMAF application shall allow the player to manipulate game entities on the map to perform
tasks such as movement and combat.
L. Lam

Page 12 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

 Build 1 VCQ A DIT

F9 The COMAF application must comply with the game rules as depicted in the Game Rules
Document.
L. Lam This refers to the finer details of the game – All COMAF applications should be modelled after the
“Game Rules”.
 Build 1 VCQ A DIT

F10 The COMAF application shall allow adjustments to properties be made for each entity.
L. Lam Referring to the changing of entity properties in the middle of the game
 Build 3 VCQ A DIT

F11 The COMAF application shall allow a ‘Training mode’ feature that provides a quick introduction to
the game.
L. Lam
 Build 3 VCQ A DIT

3.2 (I) External Interface Requirements

I1 The COMAF Application shall provide a simple menu-based interface for two players to setup a
new game.
L. Lam This includes setting up a scenario, networking settings etc.
 Build 1 VCQ A DIT

I2 The COMAF Application shall provide the game interface so that the players can place modifiers
(game entities, obstacles) on the game playing field.
L. Lam
 Build 1 VCQ A DIT

I3 The COMAF Application shall allow the player to issue orders to the game entities. Orders shall
include movement and combat functions.
L. Lam
 Build 1 VCQ A DIT

I4 The COMAF Application shall allow the player to see the status of each game entity.
L. Lam
 Build 1 VCQ A DIT

I5 The COMAF Application shall provide an interface that displays the statistical data of the battle,
including casualties and resources availability.
L. Lam
 Build 1 VCQ A DIT

I6 COMAF shall offer a simple programming interface for applications to pass on data regarding the
environment, and receive feedback (list of orders and adjustments) in return.
L. Lam In the working scenario, COMAF is responsible for accepting data input and produce a list of
tasks for the application to perform.
 Build 1 VCQ A DIT

I7 The COMAF Application shall provide the interface in a 2D environment, under a selected
operation system / platform.
L. Lam

Page 13 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

 Build 1 VCQ A DIT

3.3 (P) Performance Requirements

P1 The COMAF Application shall be able to run at an acceptable frame rate (20fps or more) for both
players.
L. Lam
 Build 1 VCQ A DIT

P2 The COMAF Application shall run with a ping time of no less than 1500ms under a LAN
client/server environment.
L. Lam
 Build 1 VCQ A DIT

3.4 (D) Design Constraints

No Requirements.

3.5 (Q) Quality Attributes

No Requirements.

Page 14 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

4.0 Use Cases and Processes

This section provides a proposed view of major processes involved in COMAF Application’s
operations, presented in the form of UML use cases as well as data flow diagrams (DFDs).
The aim of these diagrams is to explain as concisely as possible the detail workings of a
COMAF application and what interactions it will have to handle.

4.1 Use Cases

The use case diagram describes major ‘scenarios’ that occur throughout the running of the
application. Each of the bubbles represents a ‘use case’ or scenario, which may also include
other extension scenarios. Extensions are marked with an arrow labelled with either “extend”
or “include” markings. The “include” label indicates the sub-scenario will definitely occur
within its parent scenario, while the “extend” label indicates an optional extension.

Access Main Menu Host Game

«extend» Adjust Properties

Player

«extend»
«extend»

Display Game Place Entities

Join Game Field and Panels
«extend» «include»

«include»
Split Entities
«extend»
«extend»

Manage Gameplay
Select Entity «extend» Select Entity Action
«extend» Change Entity
Properties
«include»

«extend» «extend»

«extend» «include» Record Actions

«include» Move Entity Join Entities

«include»

Maintain Network Perform Display

Communication Update

Process User Input

Perform
«include» Simulation Update
«include»

Send Simulation
Receive Input
Updates
Signals

Page 15 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

4.2 Data Flow Diagrams (DFD)

Data flow diagrams present views of processes with the additional details on data
interactions. Each major process is presented by a bubble, while boxes without side borders
represent data storage. Note that some processes may interact with an external entity (e.g. a
user).

LEVEL 1 DFD:

1. Begin Main Game

Interface Game Resources

Game Data (e.g. Images)

4. Setup Game
2. Game Setup Scenario

Game and Networking

Setup Information Game Setup Data Setup, Scenario Data

Setup
Information
Game Obj ect
5. Run Game User Input
Network
Communications
Game Visuals
Game Updates Player(s)
Game Setup Details
Game Progress
and Inputs
Updated Data
Netw ork Connection
3. Setup Netw orking (Betw een Players)
Network Settings Simulation Data
Entities
Game Obj ect
(Data)

Simulation Log Perform Simulation Updates Game Data

Processing

Game Progress 6. Process Core

Game Progress Log 7. After Action Ev ents
Data
and Replay Data Rev iew

Game Event Log

As shown in the above diagram, a game generally progresses through several stages:

1. Main Interface – Here the user may choose to start a new game, or other features such as
game replays.
2. Game Setup – The user selects an appropriate game mode (e.g. Multiplayer).
3. Network Setup – The user configures the network for the game (Hosting a game or joining a
hosted game).
4. Setup Game Scenario – Before each game starts, the game field must be set up first. Here the
user begins the placement of entities, shaping the environment. The game will not proceed
until this is done for all players.
5. Run Game – This stage represents the physical updating of the game environment, including
displays.
6. Process Core Events – This stage represents the simulation updates that are performed
behind the scenes.
7. After Action Review – As the game is being recorded, the user may opt for replaying the game
in a review session.

Page 16 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

Appendix A. Additional Design Considerations

This section provides additional information on the design considerations that influence
COMAF’s requirements. Please note that these artefacts were provided only as
reference and may not be used at all in the design of COMAF and related applications.

A1. Combat Function Requirements

In terms of ‘gameplay’ functionality, the following criteria shall be met to reflect proper
manoeuvrist behaviour. This behaviour may be simplified in the final design.

“Shape” Combat Function:

 The ability to define formations for units or teams, which is an important aspect of
enhancing the friendly force’s position.
 Be able to gather around key locations, usually specified by waypoints.
 Ability to alter/destroy the terrain to change the battle space.
 Ability to disrupt/deter the enemy’s operations or luring the enemy to an ambush.

“Strike” Combat Function:

 To apply military forces in surgical strikes, hit and runs, or general assaults at
specified locations.
 Strike teams should be configurable and be comprised of any number of units.

“Shield” Combat Function:

 Provide direct (reinforce) or indirect (artillery/air) cover for allies.
 Provide stealth movement or reconnaissance features.
 Be able to gather around key locations.

“Sustain” Combat Function:

The ‘Sustain’ combat function involves appropriate and timely support to friendly forces via
the provision of stocks, replacement of weapon systems and reinforcements. There are
several questions which need to be explored in this category:

 Replenishing resources for supporting/building new units: How should resources be

obtained/distributed?
 Reinforcing friendly forces: How are allies supported in the game?
 Supply and maintenance model: How does the player resupply or repair its forces?

“Adapt” Combat Function:

According to the Fundamentals of Land Warfare, to adapt is to respond effectively to a
change in situation or task, which requires the rapid and continual adaptation of procedures
and plans to be successful. In the context of games, to provide adaptability requires the
players to change their plans dynamically or to re-evaluate the goals at a certain time interval.
This is easily achieved in multi-user mode; in single player mode (if available), if the same
scenario is played more than once and the player is attempting different strategies, the
computer opponent should react differently.

Page 17 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

A2. Design Rationale

Other concepts from which the requirements are drawn include:

 COMAF will focus on modelling behaviour and psychological/physical energies in

combat as opposed to modelling realism.

 Presentation of entities should be as abstract as possible. For instance, the

simulation environment shall comprise of ‘entities’ that carry amounts of ‘energies’,
with a number of functions that require these energies.

 The rules of the game should be abstract as well, but to a level where the essential
objectives are not lost. A basic game should include simple objectives that range
from “Capturing territories” to “Conserve energies of allies”. According to the
Manoeuvrist Approach, in the actual battlefield environment elimination of the enemy
is second to the main objective – To defeat the enemy’s plans by eliminating their will
to fight, and by destroying the enemy’s centre of gravity (the one manoeuvre that will
throw the enemy units into utter confusion and chaos). The game rules should reflect
these properties and avoid resembling the common game rules in modern strategy
games (e.g. total annihilation of the opponent).

 Destroying the enemy’s determination may be achieved by “sapping their intellectual,

moral and physical energies”. The game rules should also take these into account.

 Design should incorporate the management of perceptions (of the enemy’s and our
own units) as it is the key to defeating the will to fight. Perceptions may be presented
as intelligence gathered by entities – A cost may be incurred in acquiring the intel,
and the user may be given the choice of a balance between energy consumption and
reliability of intelligence.

 It is important to be able to analyse the enemy’s centre of gravity and critical

vulnerabilities. In the ideal situation, the application should make these identifiable to
assist in after action reviews.

 The simulation may be conducted on four levels (also drawn from manoeuvrist
concepts):
o Physical – Simulation of energy usage, combat and movement costs
o Functional – Movements, terrain utilisation (clearing obstacles)
o Temporal – Timing of events, speed of movement
o Moral and Psychological – Bonding between entities, confidence, emotions

Discrete events and cellular automata simulations are some of the recommended
models for this purpose, where the entities are the main focus.

Page 18 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

A3. Proposed Simulation Components Design

The following is a proposed design of the simulation components, and how they may work
with each other.

Simulation
Actions
Environment
Perceptions

Senses

Communications / Orders
Entities

Player

Global directives Processing

Discrete Event Behaviours

Simulation Model

Properties / conditions
affecting events

Experimenter
Simulation Properties:
Properties
adjustments
Physical (Energies)
Functional (Movement, combat, intelligence
Behaviour gathering etc)
Rulesets Processing Temporal (Timed events, reactions)
Moral/Psychological (Perceptions, emotions,
common sense?)

In this particular design, the major components within COMAF consist of:

 A Discrete Event Simulation Model, which is responsible for triggering events in the
simulation of the environment and the entities.

 A Simulation Environment Module, which provides information on what is to be shown

to the player, and what data will the entities receive.

 A set of Simulation Properties within each entity that dictates its actions.

Page 19 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

 A Behaviour Ruleset (list of rules devised by the Experimenter) that affects common
behaviour among entities.

A4. Use Case Scenarios

This section presents a list of possible uses for COMAF applications, a summarized
sequence of actions that would be performed by the users of the framework.

The types of COMAF users shall be identified as follow:

 Game players (Army personnel)

 Trainers (Army personnel)
 Experimenters (Psychologists, human factor experts)

1. Session Preparation

This scenario refers to the initial setup required to prepare for a

new gaming session. The editor interface should allow the
trainer to devise a scenario with adjustable elements such as:

 Scenario objectives / conditions

 Terrain, constructions, hazard areas
 Beginning resources
 Common behaviour rules (outlined in 4. Adjustments)

A set of tools shall be provided to allow the building of terrains, placing objects and units on
the map, as well as specifying a list of available resources for both sides. A common rules
base may also be employed (which would require a separate interface with the functionalities
as described in 4. Adjustments). The user shall be able to select an object and adjust its
properties directly. General objectives may also be edited from a separate interface, in which
the user can add various goals that can be ranked in importance. New events may be
allowed to occur based on the accomplishment of specific goals.

2. Game Playing

The general gameplay is conducted in this sequence:

 The participants select a pre-built scenario for the session

and decide on the team assignments.

 Each player is briefed on the general objectives, and is

given time to study the layout of resources and terrain.

 Once the game has begun, all the actions will be

conducted in real-time, on a grid-based two-dimensional
interface. Information about selected units and scenario
progress is displayed on screen.

 The participant is presented with a range of command

options to manipulate the resources at hand. Such actions
may include movement and engagement orders, as well
as long-term strategies for groups of units.

 Other manipulations may be available by right-clicking on

the objects presented on the main map.

Page 20 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

 At some point in time, the player may be presented with communications from the units,
and may need to respond with a tactical decision.

3. After Action Review

The actions that had taken place throughout the course of the game will be recorded and may
be played back in the “After Action Review”. The users will be able to playback the actions
taken in increments (steps of a timeframe) or real-time (with a pause option), with the
opportunity to review the decision-making process and the internal conditions of the units
involved.

4. Adjustments

COMAF applications shall allow the trainers or experimenters to adjust various properties that
have a more profound influence on the field. Such properties may involve “common rules”
that govern the behaviour of any given unit on the map. Such rules shall be as abstract as
possible (close to English language) in which case the user editing these rules is required
only to have minimal computer knowledge. Rules can be constructed in parts, for example:

1. For all units in Charlie Squad, consider (gradual) retreat if energy level is moderately low

2. For unit with highest energy in 52nd Platoon, assume leadership and retreat if commander is
KIA

3. For all units in Baker Squad, mass panic if unit(convoy) is destroyed

The editor interface shall provide a few windowing features (also referred to as widgets) for
constructing the rules, for example a dialog box with selections of constructs, together with
dropdown boxes for selections.

Page 21 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

A5. Sample Interfaces

Fig.1 General Interface for Main Screen

Fig.2 Main Game Interface (Option 1)

Page 22 of 23
Document COMAF02 Revision 1.4
Author Leo Lam Date 09/09/06

Fig.3 Main Game Interface (Option 2)

Page 23 of 23