This paper presents the novel use of storyboards for composing, organizing and visualizing tactical agents designed to serve as computer generated forces. These tactical agents represent enemy forces that act and react to trainee actions and are specifically used here to populate military training scenarios. The tactical agents are based on the Context-based Reasoning human behavior representation paradigm. This application of storyboards facilitates the use and visualization of the contextual elements that make up the composed agents. The use of the approach is described and an informal qualitative evaluation is conducted.
Preparing a simulation for a military training session can be a time-consuming process. First of all, training objectives must be expressed by the instructor. Secondly, a mission or task to be executed by the trainee(s) must be specified, and the accompanying environmental conditions must be defined and subsequently reflected in the simulation environment. Thirdly, if the training objectives call for the trainee(s) to be faced with a specific situation, the external entities with which the trainees interact must be designed such that they present that situation to the trainee correctly and at the appropriate time. When this requires the involvement of intelligent software agents, these must be integrated into the simulation in just the right manner to accomplish the desired objective. Planning and organizing the simulationbased training exercise to systematically include these three steps presents a significant problem for simulation-based training.
In recent times, the widespread reuse of standard, reusable scenarios has led to exercises becoming known in advance by the trainees, thereby negating the effect of built-in surprises and diminishing the effectiveness of the training session. This ultimately prematurely requires that new and expensive exercises be created. It would be ideal, therefore, if new training exercises could be easily custom-made for each group of trainees, but that they nevertheless would guarantee an equivalent learning experience for all trainees.
This leads us to the concept of assisted scenario generation for training simulations. While the selection and implementation of certain environmental effects such as weather, time and other such issues is relatively easy, depending on the facilities provided by the simulation infrastructure, others such as the behavior and plans of the external entities typically require much greater care. This is because these intelligent tactical agents could exhibit the wide range of behaviors typically used in these scenarios, thereby resulting in large and complex models. Their large size and high complexity make these agents difficult to build and possibly computationally expensive to run.
However, this is not the entire problem. The external entities are the primary means through which the scenario designer causes the desired situations to be presented to trainees at the right moment. These agents have to be able to react to the trainee actions and still be able to present the desired educational situation. In situations where the roles of the external entity are quick and of a short duration, it may not need to be artificially intelligent. An example of this could be a distracted pedestrian crossing the street in front of the car. In such cases, the model of the pedestrian is simple, as it needs no reaction. Selection and placement of such an external entity would be rather simple. However, for other roles that require extended contact with the trainee such simplicity may not suffice. Examples of this include a driver with road rage, a persistent enemy combatant, or a police officer pursuing a fleeing driver. A more complex process must be developed to assist the training session author in building the appropriate external entities and place them correctly within the simulation.
A tool that helps the session author design the training session -specially the agents used in the training session would be immeasurably helpful. Description of such a tool is our objective here.
Planning has been a core part of AI research since the beginning. Planning is something that humans do naturally and for the most part, effectively. Many tools have been built to assist planners. We investigated the feasibility of using storyboards, as defined by Jantke and Knauf [3], to serve as the infrastructure upon which the agent models could be planned and stored.
The concept of storyboards has been used successfully for many years in many applications such as cinematography, theater, musicals and such time-based works. Storyboarding is a modern approach to planning that actually goes beyond conventional planning. It can be said to be the "… organization of experience" [3]. Jantke [4] asserts that when human activity comes into play (e.g., games, war) predicting the future situations becomes difficult because it is unknown what situation will be faced by the human in a conflict-based context. He maintains that storyboards provide room for such human activity by furnishing means to represent alternative worlds.
Knauf [6] and Knauf et al [7] more recently applied the storyboard concept to course design. They are specifically used to guide the didactic process in traditional learning environments and in e-learning.
The storyboard approach devised by Jantke & Knauf is built upon standard concepts which enjoy (1) clarity by providing a high-level modeling approach, (2) simplicity, which enables everybody to easily become a storyboard author, and (3) visual appearance as graphs.
While other means of structuring the contents of the agents exist, such as state diagrams, Petri nets, etc., none meet the above three requirements as easily as does the storyboard tool described here.
Jantke and Knauf define their storyboard as a nested hierarchy of directed graphs with annotated nodes and annotated edges. Nodes can be either scenes or episodes where scenes denote leaves of the nesting hierarchy and represent a non-decomposable learning activity. A scene can be (1) the presentation of a (media) document, (2) the opening of any other software tool that supports learning (e.g., an URL and/or an e-learning system) or (3) an informal description of the activity. Episodes, on the other hand, denote a sub-graph. Graphs are interpreted by the paths through which they can be traversed. Edges denote transitions between nodes. Figure 1 shows a top-level storyboard that reflects an organization for teaching a college-level course in Artificial Intelligence.
The processes that are commonly represented through storyboarding are characterized by nondeterminism, involvement of human players and the attempt to anticipate the behavior of these human players. These characteristics also apply to simulation-based training sessions. Therefore, we propose here to use this storyboard approach to represent the agent being composed for a session in a training simulation.
The agents themselves are defined in the Contextbased Reasoning (CxBR) modeling paradigm. CxBR specifies that agents built through CxBR be composed of several major contexts, some accompanying minor contexts and definition of transition criteria between the major contexts. While it is active, a major context, together with possibly several minor contexts, controls the actions of the agent. When the situation changes so that the context has changed, a transition to a new active context is effected, with its attendant functions and knowledge taking over the control of the agent. Transition criteria determine when the situation calls for a new major context to be made active and the currently active major context to be deactivated. Only one major context can be active at any one time. We expect here that the major contexts will be defined and created a-priori and be available in some repository, providing a baseline behavior for the agent when it finds itself in the correct context. However, the transition criteria are very applicationdependent, and must thus be specified carefully for each application. See Gonzalez et al [1] for details about CxBR.
We should note that the storyboard is not the agent. It merely helps a human to compose the agents for a specific scenario in a way that is clear, simple and easily visualized. The CxBR-based agents contain the intelligence and the ability to react to events in the simulation exercise.
The objective of the research was not to develop a working model of the tactical agents themselves, but rather to organize their definition in an easilyvisualized and manoeuvrable tool. This is what we describe as composing agents from existing components, in our case, major and minor contexts. Our software tool provides a medium for the scenario storyboard to be reflected, provides an infrastructure to store the agent models for all situations, and can assist the session author with customizing the transition criteria for the major contexts vis-à-vis the training session. The storyboard, however, is not an agent representation paradigm. CxBR is the agent representation paradigm used. The storyboard merely helps in composing the agents from previously defined major contexts and easily visualizing the resulting agent. To better describe the concept, we introduce an example military scenario.
The training scenario used for this experiment involves a fictional maritime country (Blue state) with a lightly defended base in an island far off its mainland coast. This island is the subject of a territorial dispute between the Blue state and a neighbouring and also fictitious Red state. In light of current situations that may lead to potential hostilities with the Red state, the Blue state seeks to reinforce the defences on the island by sending a cargo vessel with supplies and armaments needed to enhance the defences of its island base.
This cargo vessel (M1) is escorted by a small task force composed of one anti-aircraft destroyer and flagship of the task force. This vessel is armed with SAM launchers, one torpedo tube and assorted guns. This is the vessel to be directly controlled by the trainees in this training exercise and it is labelled TF1. Three other warships make up this task force. Two anti-submarine frigates respectively labelled BF1 and BF2 come armed with anti-submarine rockets and assorted guns. The fourth warship is a mine layer, armed with mines and a 12.7 mm machine gun. It is labelled BF3. Their mission is to escort and protect the unarmed cargo vessel (M1) containing critical supplies and weapons from the mainland port to the naval base in the island in question. Their orders are to protect the cargo vessel and to confront any force threatening it, whether air, surface or subsurface. The Blue state ships are at the command of the TF1 commander, who can order them to take any action in accordance with the imposed rules of engagement.
Unbeknown to the trainee Blue force, a Red state force intends to land a heavily armed contingent in the island and capture it without a fight, given the light defences of the island base, and its long distance to the mainland. The invading Red force consists of three vessels, and they are labelled RF1, RF2 and RF3. RF2 and RF3 two are AEGIS-type anti-aircraft destroyers. Besides anti-aircraft missiles, they are armed with an assortment of guns. RF1 is a mother ship carrying three landing crafts that can be deployed from her hull. Each landing craft can carry a platoonsize unit with a light armoured vehicle or jeep with machine guns mounted on them. These landing craft are also armed each with one 12mm machine gun.
RF1 will seek to get close enough to the island on its north side so that it can launch the landing craft and land their forces. They are not aware of the Blue state convoy task force, the cargo vessel or its contents. The initial conditions of the developing situation are described in Figure 2 below. Each task force is not initially aware of the other. When the Red task force enters the Blue state's territorial waters, it is detected by an unarmed aerial surveillance aircraft (not shown), that monitors the waters surrounding the island, and continues to monitor the movements of the Red force. Without air or satellite assets, the Red force later discovers the presence of the Blue task force only when the latter gets within range of their ship-based radar. No other aircraft are relevant in this scenario.
In the initial scenario, the Blue force is in a major context that calls for it to escort the cargo vessel. This means that the Blue task force is to sail at full speed toward its destination, maintaining close scrutiny of their sensors for the presence of threats, as the possibility of a Red force attack on the island has been considered a distinct possibility in the recent past. This major context in control is labelled Escort and it enforces a diamond shaped formation designed to protect the cargo ship from all directions. This major context looks for the possibility of transitioning to several other contexts, such as Confront, Engage, Attack, Retreat and Dock, among others.
The Red force, on the other hand, has as its objective to land undetected on the island's north shore which has good beaches for that purpose, deploy its forces and march overland to the base in the south end of the island and take it through sheer intimidation, preferably without firing any shots. Its initial major context, while in international waters, is simply to navigate to certain coordinates. This major context is called Transit, and involves no special care other than to maintain navigational awareness and avoid collision with other objects as well as each other. Upon reaching the target coordinates, it is to transition to a more guarded form of navigation, where they get into a formation that is protective of the mother ship, and proceed in total radio silence, while at the same time in general quarters. This is the StealthTransit major context.
Planning in CxBR is carried out rather informally. Unlike other AI planning languages and systems, such planning is reflected merely by a sequence of major contexts with defined transition criteria. These plans are easily visualized via the storyboarding tool described here. The major contexts that compose the agent being built can also be easily described likewise, as can the minor contexts. For example, the plan to be initially followed by the Red force agents as a unit, in terms of a sequence of major contexts is shown below and pictorially in Figure 3.
It is somewhat more complicated for the Blue force. Upon detecting the Red force, the task force splits up and different tasks are assigned by the trainee force flagship (TF1). Thus, the ships do not behave uniformly as a unit as do the Red force ships. In other words, each member of the task force has different tasks to execute. So, we describe each ship individually below: A full description of the scenario and the composition of the agents involved therein would exceed the page limits of this paper. The reader is referred to [2] for the full details of the scenario and its implementation.
The storyboard tool presents the availability to create sheets, where each of these sheets contains some logic related to the progression of the story. The sheets can contain episodes, scenes or to-do boxes. An episode contains a longer lasting series of actions or subactions. It can be composed of other episodes or of scenes. Episodes are depicted by rectangles with small notches at the left and right sides. As the name suggests, scenes contain more temporally short actions. Scenes are depicted by simple rectangles. They intuitively equate to major contexts and minor contexts respectively.
The storyboard tool is based on Microsoft Visio, with some custom-made functions and shapes to allow the free and easy movement among sheets. The main progression of the storyboard is reflected in the Mission sheet. This sheet is the plan for the agents that will participate in the scenario. In terms of CxBR, these represent the progression of major contexts to be executed by the agent being composed. These major contexts are represented as episodes in the mission sheet. The all-important transition criteria that triggers transitions between major contexts is found on the mission sheet, placed between the major context episodes. Figure 3 depicts the Mission sheet for the Red Force in this scenario. The comments shown between each major context represents a textual description of the transition criteria. In the case where the rule language syntax for the system being used is known, this comment could include the actual code for the transition rule.
Episodes and scenes have the ability to switch to other sheets that may contain an expansion of the elements found in the episode or scene. This provides the ability to quickly inspect a sub-context and its contents.
The storyboard begins with an initial condition and ends with a final condition shape. These shapes are scenes. Clicking twice on the initial conditions scene will take one to the initial condition sheet, which contains the same graph shown above as Figure 2. This is shown in Figure 4 below. The Initial Condition Sheet also refers to a document which describes the initial conditions in a narrative text. This document gives the scenario developer background information on the scenario to be created. Note in Figure 3 the text between the Initial Conditions Scene and the Transit major context episode in the mission sheet. This represents the transition to the major context. In this case, the transition is a simple one -commencement of the simulation, at t = 0.0. The funnel-looking pentagon shapes are return "worm holes", so to speak. They represent a way to quickly return the user to the page from which the sub-sheet was called. For example, when double-clicking on the Transit MC episode on the mission page, this takes one to the page where the details of the Transit major context are described. To return from there back to the mission page, the funnel shape is clicked and the return is executed. Figure 5 shows the Transit major context details. The two worm holes below the sub-contexts depict the return pipe from the respective sub-contexts Navigate and AvoidCollision. The worm hole below the entire graph is the return pipe to the Mission sheet.
A sub-context sheet is shown in Figure 6. This one in particular is that Navigate sub-context. This one is shown for a particular reason. One of the advantages of CxBR is the potential for reusability of lower-level contexts by several major contexts. One of those predictably re-used is the Navigate sub-context. It is called by the Transit MC and the Retreat MC. Conceivably, it is such an important function that it should be called by all major contexts. Once the control passes to the Navigate sub-context, a return should be executed to the major context that called it. The ability to remember which major context called it is not intrinsic in Visio, so several return worm holes must be created, one for returning to each of the various major contexts that may call it. While this puts the burden of remembering on the user, it nevertheless works well.
Lastly, an important part of a CxBR is the reactive context set. These major contexts are not included in the mission plan because their use is not expected in the plan. However, the behaviors represented within these reactive contexts could be useful if the mission does not go strictly according to plan (as they rarely ever do). Note that reactive major contexts are structurally similarly to those in the mission plan. It could be that a major context could be reactive in one mission but part of the plan in another. It just depends on the needs of the mission.
The reactive major contexts are contained in a separate sheet called, appropriately enough, "Reactive Major Contexts". This sheet includes an episode for each major context whose activation could be possible in the course of this mission but not explicitly planned. These episodes have a link to its respective major context description page. These include links to the sub-contexts they call, just as was done for those major contexts included in the mission plan.
The tool was used to build the scenario for the intruder interception mission described above. No quantitative evaluation was done, as it is not a performance-oriented tool. Rather, a qualitative and rather informal evaluation was deemed to be the sensible alternative. This was judged by how long it took to learn to use the tool. As part of this research, the first author used the tool for the first time after only having attended a few paper presentations by the second author, totalling approximately two hours of lecture. These presentations were in the context of the latter's research in didactic design, and not in building tactical agents for a simulation. Learning the use of the tool took approximately another two hours of working with it. This was done without documentation of the tool, other than reading the afore-mentioned papers. [3, 4, 5, 6, 7 and 8] However, it only took the first author a total of approximately 12 working hours to develop and organize the storyboard once he learned how to use the tool. This informal and qualitative evaluation shows that it is indeed an extraordinarily intuitive tool to learn to use, even without formal documentation.
The advantages of this tool go beyond the organization of the agent components. It is quite feasible to have the sheets included in the tool contain the actual source code for each component, such as the major contexts, the minor contexts and all functions that are to be included with the CGF model for the mission in question. The ability to attach files, although not extensively used in this particular work, can serve to attach source code files to each major context and sub-context.
The research preformed here hypothesized that an existing storyboard tool, used previously for academic coursework organization and development, could be used to also define, organize and visualize military missions for the purposes of preparing training scenarios. The research consisted of defining a training scenario that would be typical of a military mission to teach trainees about tactics and doctrinal courses of action. Then, that scenario would be implemented in to the storyboard tool. The objective of the implementation was to gauge its applicability to simulation-based training. The results indicate that, after an informal evaluation, it does indeed satisfy the hypothesis that it would be a highly useful tool for this type of applications. While some improvements can be made to the tool vis-à-vis this type of application, it is useful as is, with only minor modifications made as part of this research.