Interactive Simulation Newsletter

HAPPY NEW YEAR!

2004 has started off with a bang for us--lots of interesting events and projects are in store. As you'll see in the Events section, Jonathan is teaching the first ever, 10-week class on how to build virtual device simulations, at Drexel University in Philadelphia. By mid-year, we expect to move this class online, thanks to your (well, maybe not 'you' specifically!) feedback through the online survey. You can still take the survey and help us to shape the class.

For those of you who haven't heard, we have collected and revised our component set, in particular, have added full Reference panel help and codehints. No need to dig around the book or inside component code anymore to learn how to manipulate the device interface library of almost 30 components. Check them out over here!

When we last left you, we published alternate state engine implementations (by Miro Samek and Ralf Bokelberg), and this month's thread continues, in some respects. We have received quite a lot of interest in learning more about how to use state machines, but we sometimes get comments that going from statecharts to code can be tricky. Even though the process is completely cookie cutter, even we get tripped up sometimes remembering what goes where.

Enter your email address here to receive the accompanying source code and automatic notification on future newsletter releases.

Therefore, in this month's newsletter on the technical side, we give you access to a tool we made that generates skeleton code (in AS 1.0, AS 2.0, and C++) based on an XML statechart description we created.

In our instructional side of the newsletter, this month we discuss how your designers can communicate simulator requirements to your developers. This follows our philosophy of letting the design dictate interaction requirements, rather than the developers rushing off to build interactivity that may or may not be relevant or necessary to the prescribed tasks.

As always, your comments and feedback are welcome.

We have recently developed a simple tool that allows you to quickly generate infrastructure code once you describe the state hierarchies through an XML description:

http://www.eqsim.com/scxml2code.html

The basic idea is that you paste in your XML code into the top box, choose the target state engine implementation, and then press the Generate button. The code appears in the bottom text box. You will see if the compiler had a problem, it will tell you in the header comments how many errors were encountered. This is a simple program and still leaves a lot to be desired of in terms of error checking in your XML description, but we have found this simple tool to allow us to shorten our production time (from design to code) significantly. It also allows us to more easily test designs at an earlier stage, since we can generate code rapidly.

Currently, this tool generates code into three target implementation:

• Our FStEng v 1.5 (ActionScript 1.0) implementation
• Miro Samek's QHsm (ActionScript 2.0) implementation
• Miro Samek's QHsm (C++) implementation

What, C++ you say? That is one of the powers of designing your systems with statecharts--the target platform is not intricately embedded in the system design. For example, once you design your charts, you can produce C++ (or Java, C#, or whatever) code, perhaps for embedding into the real device, and also generate ActionScript for your Flash-based presentations (prototypes, training, etc.). We have not yet implemented a code generator to C# or Java, but if people want that, please let us know and we'll put it out. This, of course, is all possible through Miro's state machine implementations (see his web site for information about the code in different target platforms).

Note: Miro has made his ActionScript implementation available for free (in the November 2003 subscriber's edition of our newsletter), but not the other target languages. You must buy his book to unlock the codes for his C++ implementation. We don't see how you are really going to use his code effectively without the book, so it seems pretty reasonable to us. You can get our FStEng v1.5 in the subscriber's edition of the July 2003 Newsletter, or by filling out the simulator class survey.

The Basic XML Description

In the downloaded ZIP file, or on the online tool page, you will find example XML code you can use to explore the XML elements and attributes. As well, we have included an HTML document that sketches the allowable elements and attributes for use as a reference.

We have defined our XML elements to follow the basic conventions described in our book. The XML code has two parts (1) the description of the state machine, and (2) a description of the events. These are coded as follows:

<HSM name="My State Engine">
...
</HSM>

<events>
...
</events>

As you might imagine, within the HSM tag, you place a hierarchical arrangement of state, hState, and hStateC elements.

Note that only our FStEng v1.5 engine supports hierarchical concurrent states. In his book, Miro describes how to implement them using his framework, but it is a manual process. If the code generator runs across an hStateC while producing code for a target platform that does not have this feature, it reports an error and marks the place in comments within the code.

For more information about tags and capabilities, see the HTML file included in this month's download, or ask us a question on our discussion boards!

BACK TO TOP

One of the common problems we hear about in simulation development is the difficulties that project managers, instructional designers, and developers have in communicating the necessary functionality for simulations. Even when the project revolves around a device, which usually should ground the topics more easily than a soft skill situation, there tends to be divergence in what level and type of functionality is necessary.

Perhaps because there is a device involved, it becomes more attractive to let the developers loose on simulating the product before all the instructional elements have been determined. Without proper guidance, developers can easily get carried away with detail that is unimportant instructionally. This inevitably leads to projects and simulations that are unnecessarily complex (even to the point of being worse than a simpler approach), and take longer than necessary to complete (both in terms of time and money).

We'd like to offer our basic approach as the basis for establishing that communication, in particular, for relating what aspects of the simulated device the instructional designer needs for the project. Since we take a instructional-centered approach, we purposely hold off the main tasks in device simulator development until the basic groundwork has been laid.

Our approach focuses essentially on what the simulator needs to look like, and what it needs to do. We don't have the designer try to specify how it works, only what elements are required to fulfill the instructional pieces of the presentation. We have identified five essential areas in the specification of a simulator:

1. Look. What visuals are required for the simulator? The look describes how the simulator visually needs to appear. Is the interface simply an instrument panel, or does it include schematics and/or other mental models? Ideally, we like to provide visuals here so we have a starting point.
   
2. Functionality. What functions does the device have to perform? Since this can turn into quite an open question, we like to break down the different specific functions and computations that are required. Are there any fidelity requirements in terms of behavior that have to be met? For example, does the device have to perform a function with a specific accuracy related to the real device? Often, for instructional purposes, it is fine to develop computational algorithms that approximate, or let's face it, fake, the output. That is not bad, so long as the boundaries of realistic output are not violated. You don't want users drawing conclusions that are incorrect, but often the cost of developing highly-accurate computations is greater than necessary for the tasks you need operators to accomplish. Admittedly, this is an area we have gotten trapped in when we start building the device before the instructional tasks are specified.
   
3. Configuration. How will the presentation need to configure the device, that is, what starting points in terms of device state and context are necessary? Knowing the limit of possible configurations can save a lot of time from the developer standpoint.
   
4. Active Querying. What information about the simulator state or properties are needed (e.g., for evaluation of correct or incorrect results)? This can be determined by reviewing your performance objectives with special attention to what you have defined as accomplishing those objectives (the accomplishment is the element that says when you know the user has met the objective). The prompting and feedback you design will further help you figure out what information you need to know from the simulator to make informed interventions.
   
5. Passive Notification. What critical events do I want the simulator to tell the presentation that have occurred (e.g., to trigger evaluation, prompting, or feedback)? An inefficient way to evaluate user performance is to poll the simulator at some rate to see when the tasks have been accomplished. A better way is to let the simulator tell the presentation when the simulator has changed states, or values have changed. These are what we call "passive notifications." You as the designer should specify at which point the simulator should communicate to the presentation that something meaningful has happened. Note that the simulator may be generating a lot of notifications that are not relevant to one particular task, but you need to specify what may be relevant for different tasks in the presentation.
   
   You can think of the simulator while it's running as announcing its current status with respect to meaningful things it does. Whether or not the presentation wants to use that information is determined by the presentation based on the specific task requirements. For example, suppose you are teaching how to operate an analog/digital watch, and one of the tasks is to set the correct time. Therefore, the task will at least require a passive notification when the watch leave the "time setting" state, and it will require an active querying of the current time.

You will notice that in the process of articulating your performance objectives and their interaction requirements, such as the last part of Passive Notification (5), you will come up with elements both for passive notification and active querying, not to mention the other categories. We have found that an efficient approach to answering these questions involves reviewing each performance objective to determine required information in each category.

In essence, we find that the value of this approach lies in establishing a starting point, namely the answers to these questions, which enable further discussions among team members, but focused on specific answers. We're always eager to hear what you think!

We constantly run into all different people around the country and world who have interesting simulation projects they have in mind or have prepared. We want to encourage you simulator programmers, instructional designers, gamers, managers, and other developers to share your stories and best practices with the rest of us. We invite you to lead or join the discussion on our FlashSim discussion board:

http://FlashSim.infopop.cc/

We also will monitor the discussions for particular topics that might make good newsletter information, so go forth and post!

If you have suggestion for topics you'd like to see in the newsletter, or links to events or interesting Flash pieces you've made, please email us at newsletter@FlashSim.com.

This newsletter (in public form) also is available on FlashSim in the RESOURCES section:
http://www.FlashSim.com/newsletter/v2n1.html

If you are receiving this newsletter from a friend and want to subscribe yourself, please email us a message with the subject "Subscribe" to addListener@FlashSim.com.