Interactive Simulation Newsletter

WELCOME!

In the process of preparing for workshops and talks over the next few months, David and I have had the chance to think a little more about one of the first questions people ask about simulations and e-Learning: "which simulations are good for learning?" We provide some thoughts on this tricky question in this month's feature article.

Our Component Corner article advances the work from the book with respect to making dials behave more realistically. We show how to add a "rate-limiting" parameter to the dial components, to reflect the natural delay that dials possess in arriving at their current values. This solves the problem of a how to make dial movement look more realistic.

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

If you have a story to tell about a simulation project you are developing or have developed, please let us know. By sharing and discussing our experiences, we all become better simulation developers!

While we were preparing for an upcoming talk, one of our colleagues summarized the interest of the audience by telling us to "talk about what types of simulation are good for learning." On the surface, it is an innocent question, and certainly of great interest to many people who are trying to put "simulation" in its place within learning, and particularly within e-learning or technologically-assisted learning.

We understand the intent of the question to mean "what types of learning can best be enhanced/addressed using what types of simulations," but for the sake of argument, we'd like to explore issues related to the exact question, because we believe it reveals an inappropriate shift of attention that we see common in today's marketing of simulation in the e-Learning space.

Aside from some other problems with the question, such as "how do you define simulation?", the original question inadvertently places the emphasis on the means to a solution, namely simulation, without properly qualifying the problem. In other words, while simulations can be used to solve problems, you first need to analyze the problem and generate a plausible hypothesis regarding whichever instructional format(s) you use to solve the problem. Also, while well-designed simulation and interaction afford the opportunity to practice skills, assess proficiency, and possibly enable 'exploratory learning,' they are rarely sufficient alone to solve learning problems, since learning is a collection of skills, knowledge, and the understanding of when and how to apply knowledge.

Not to shy away from answering the question directly, though, we might respond with with an answer that turns out not to be so informative: a simulation is useful to learning when you can show a measurable improvement in performance.

The reason this is not particularly informative is that the response applies to any type of learning, not just simulation. It is a truism that if you can show a measurable performance improvement with whatever instructional format, you can say it is useful to learning. However, the response does shift the focus from the simulation "solution" to a meaningful training problem: targetting and measuring performance improvement.

In our view, a more appropriately-worded question would be

How can you develop learning that shows a measurable performance improvement?

In this context, simulation may only be one piece of the puzzle. We have found when the designer can give specific performance objectives, and learning materials are designed to meet those objectives, it is possible to measure performance differences. Good performance objectives need to be specific, such as "demonstrate that the operator can set up the machine in this mode with these settings," or "under these circumstances," not "the operator should be able to understand a schematic."

Th question reformulation focuses on the typical main training problem, which is to improve performance. While some training succeeds in spite of the trainer and the materials, we have found that consistent, positive results rarely happen without good planning.

Part of good planning is to have a solid idea as to what constitutes success or failure--a project hypothesis. The hypothesis can be in terms of costs, time, performance, or anything else you can measure. You might define a hypothesis that states "by using this approach, the project will reduce training time by 10%." Depending on how much money, time, or other resources that translates to, you can determine how important it is to solve the problem. By putting it in those terms, you can measure how much such a project is worth, and you can more easily determine trade-offs with respect to its development. After the project has been released, or you have delivered and tested prototypes along the way, you can test your hypothesis to see if it succeeds or fails.

The holy grail is, of course, to be able to quantify the improvement required such that it becomes possible to justify the investment and provide quantifiable benefits to fund future efforts, or to recognize that a particular type of format does not work effectively in the given situation. Too often, we as designers are pressured to apply technological "solutions" before we really understand the problem well enough.

In the dial components developed in the book (FISRndDial and FISSectDial), we simplified the task to make the dial instantly reflect the current value, rather than the more realistic behavior of smoothly transitioning the needle to a new value. Real dials do not respond instantly to different values--they move to the new value at a predefined rate.

In the figure below, compare the behavior of the dials on the top row to the dials on the bottom row, once you set a target value (between 0 and 100) and press GO. Use the slider on the top right to adjust the speed at which the dials reach their target values.

This situation is another example in which we can use inheritance to extend the behavior of the basic dial components, rather than having to re-program all dial functionality in new components.

While at first it may seem natural simply to override the setNeedle method of the dial components to make it flow smoothly to the target value (setNeedle points the needle immediately to the given value), we have to remember that a user may want to initialize the dial at a certain value, or jump immediately to a specific value for a given configuration. Therefore, we will add a new method, xNeedle (for "transition needle").

To achieve the new functionality, we need to add a new property to represent the speed of the needle. We call this property nSpeed ("needle Speed"). The speed is expressed in units/second (units-per-second). The way in which we move the needle at the given speed needs to be independent of frame rate, since our speed is given in units/second and we don't want to be reliant on specific frame rate.

The basic idea is to distinguish two "states" for the dial behavior. The first state is when the dial is set a particular value and the value is equal to the target value. The second state is when the value does not equal the target value, in which case we need to ensure that the component is moving the needle toward the target value at the specified rate. We start the dial in the non-moving state, and the method xNeedle essentially sets a target value and determines if the needle should move, i.e., the target value is different from the current value. If the needle should move, the routine transitions to the moving state, unless it is already there.

The eager ones among our readers may be saying "hey, why not use the state engine to manage the states?" To that we would answer that this situation is so basic that it would be way overkill to employ the state engine mechanisms to this problem. Rather, we can keep the "state" as a property, we call inX, meaning "in transition" (true or false). It does illustrate, however, how one can use the concept of states to think about and solve problems.

To summarize, beyond the basic dial functionality, we need the following methods:

• xNeedle: Set the target value to a given value, and begin transitioning (if not moving already)
• setXSpeed: Set the rate of the dial (in units/second).

We do have to modify the original behavior of getNeedle, which returns the needle position value, to account for the possibility that the needle is not at the target value yet. Therefore, we override getNeedle to determine if the dial is currently transitioning, and, if so, return the current position. If the dial has settled on a value, return that value.

FISRndDialSmoothClass.prototype.getNeedle = function () {
   if (this.inX)
      return this.xVal;
   else
      return this.val;
}

The only trickiness in the code is in how we update the value when the needle is in transition. Since we can't rely on the frame rate, the only recourse is to use setInterval. If a user sets the speed at 10 units per second, we need to ensure that the needle moves 10 units each second. If we schedule the interrupt at 100 milliseconds, that would give us (in theory) ten times per second to update the drawing.

When you wake up from your setInterval dream and come back to reality, you'll realize this won't work because of the "intracacy" of the setInterval implementation (translation: deficiency, with respect to how you would think it should work). The problem is that as the interval gets close to or below the frame rate, setInterval may generate interrupts at half the expected interrupt rate.

The workaround we have chosen is to arbitrarily set the interrupt at 50 milliseconds, or so. This gives adequate performance and a reasonably natural smooth look. When the needle is about to start transitioning (someone has set a target value), we compute the needle's update value per interrupt:

this.unitsPupd = this.nSpeed / 20;

The unitsPupd, or "units per update", is calculated based on the needle's rate. Every 50 milliseconds (20 times per second), we increase or decrease the current value by the update increment. When the current value gets to within one update increment of the target value, we stop the updating and set the current value to the target.

As an extra ornament, we define a dial event that fires when the dial reaches its target value. Since dials are output elements, they typically do not have events, but we felt that this added bonus could help a developer who wants to trigger a response when the dial reaches its target value.

Is the Performance Hit Worth It?

Adding a level of realism to dial movements can be important to the overall look of your simulation or instrumentation. However, there is a price: you will notice performance issues if you have many of the dials active at once. If you end up in this situation, you can optimize the behavior by using instant value dials coordinated with an external setInterval routine that keeps track of intermediate values and sets all the appropriate dials during transitions.

As another alternative, you might find that you are updating your dial values frequently enough that the instant value dials will appear to transition smoothly, if their value is sampled frequently enough so as to never jump large distances abruptly. Therefore, using instant value dials can look perfectly acceptable and you won't suffer the performance hit of the transitioning needle.

What are Your Thoughts on this?

As always, please direct questions or comments to our discussion board!

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 also is available on FlashSim in the RESOURCES section:
http://www.FlashSim.com/newsletter/v1n4.html