*Creating Effective Management Simulations: Rapidly, Responsibly, Relevantly DOI: http://dx.doi.org/10.5772/intechopen.106430*

story is the starting point for constructing a game world reality rather than becoming enmeshed in a cycle of algorithm modeling and testing.

Stories can also be generated through other techniques too. In the classroom, a story can take shape through techniques, such as science fiction prototyping [20] or the Lego Serious Play methodology.

Simulations can find inspiration from within any story and become the narrative basis for the subsequent actions. Having a human frame of understanding and incorporating the flourishes of individuality helps to flesh out a game world and make it more real to those who will participate inside it. Being able to introduce local landmarks, local personalities, or names into the story can help to contextualize the learning and make the impact of their own decision-making within the game world seem more real and significant.

### **4.2 The simulation description layer**

The description layer of existing simulations is locked away within proprietary software. This is the primary layer of existing simulations as it shaped the way that decisions made by students will be transformed through algorithmic manipulation based on a specific formula.

The proposed open-source description layer utilizes the advantages of creating an XML document that could be verified against a consistent XML Schema (XSD). The initial structure for an appropriate XSD has been shared on GitHub [21] by the author as a starting point for further development and discussion. The principle in play is one of simplicity, transparency, and a gradual handoff to the more technical elements of a more sophisticated management simulation engine. An XML document describing the simulation is a text-based document and can be edited by any text editor by multiple authors. The XML contain tags, similar to the way that HTML can be read by a browser to render web pages. In this case, the tags are specifically relevant to defining management simulations. A "storyteller" could easily recognize many of the elements of the XML document and assist to document their simulation in more structured way.

The core set of three tags <steps>, <variables>, and < formulas> are the key building blocks for the simulation. These tags contain further tags. Inside <steps> are <step> tags. Each <step> or turn of the game is defined in this way. Within each step, there is a < narrative> tag that explains the story so far and provides students with a contextualized understanding of what is happening within the game. Each <step> can contain multiple < decision /> tags. Each <decision/> is based on some student input, some static values stored by the simulation, some calculated outputs from previous decisions made by the student or other students, and/or some generated value that has been generated by the progress of the game including values taken from one of the simulation's defined <influence /> variables. For the student, they would see the <narrative> tag's contents at the start of their turn, and based on the decisions being made in the round the interface would also display the user inputs needed to get the expected student decisions for this turn. The inputs being asked from the student would relate to the variables that the game could not itself complete or calculate. The most likely reason would be the need for an input value required from the student based on the formula being used in each decision and what values were already available. Once the suitable inputs were received the simulation could progress to the next <step> depending on the conditions set by the <dimensions> tag and specifically whether this game was being run in "interactive" mode or not.

The <variables> and < formulas> tags are important to move some of the complexity away from the <step> tag itself. <formulas> contain many <formula> tags and < variables> contain many <variable> tags. Any <formula> will be composed of a combination of <variable>s being brought together to represent specific formulaic transitions that occur at <decision/> within each <step>. The XML Schema does not define where the values are stored or how they might be stored but the implication is that this would be done with some form of persistent storage such as an SQL database available locally or through a cloud-based service. This service would also maintain the logged-in state of the participants (against some form of institutional authentication) and their progress within the simulation itself.

The simulation description layer does exactly what it saysit describes the simulation completely in a single text document. For a simple simulation that runs for a small number of turns, this may be a relatively small document but the structure is flexible and a complex simulation running over many turns may require thousands of lines of description (and represent substantial academic output in its own right).

The description of the simulation sets out the individual steps of the simulation in a structured and consistent manner and in a format that remains largely readable by anyone involved in the design of the simulation. By separating out the <variable>s and < formula>s from each of the potentially many <step>s there is an opportunity to consistently reuse these components throughout the simulation without having to continuously redefine and repeat the same statements many times over.

#### **4.3 The decision-making layer**

In combination with variants of the description layer, this layer is found in all existing management simulations. The simulation takes in the decisions from participants through various types of form-like inputs, such as checkboxes and text boxes. The input is then applied to the internal algorithmic model and a response is prepared for displaying before the next round of decision-making. In effect, existing management simulations are this layer alone. In the proposed ecosystem, the decision-making layer does not change in purpose or in the way that it responds. The difference is found in the transparency between the <step>s of the description layer and the actions that are conducted at the decision-making layer. By using a consistent and structured description layer it becomes possible to create a decision-making simulation engine that can read in any similarly consistently formed XML document and then enable the simulation to be played through by an individual, a single group, or as part of global competition.

Decoupling the description of simulation from the engine that can deliver the interaction with a simulation enables a greater level of experimentation, customization, and the refinement of existing simulations (or formula) to reflect changing conditions or to update new academic knowledge in the area.

Using the description layer means that a small "tweak" can be tested in a simulation at steps nine and ten and then the <step>s can be returned to a simple repetition of the original definition used for the first eight <step>s. Defining simulations step by step also consciously encourages creativity by suggesting that influences change and shift over time and do not simply remain static for the convenience of a simulation developer.

Being able to separate the description of the simulation from the decision-making playing of the simulation also creates the prospect that more than one decision-making system might become available, and would be licensed by different institutions
