Collaborative Authored Simulation-Centered Tutor Components

Allen Munro, David S. Surmon, Quentin A. Pizzini, and Mark C. Johnson

Behavioral Technology LaboratoryUniversity of Southern California250 No. Harbor Drive, Suite 309

Redondo Beach, CA 90277munro @usc.edu

AbstractAs we have developed a number of authoring systems forsimulation-centered tutorial development, each successiveauthoring system has achieved its original goals, and yet hasbeen quickly shown to have limitations that motivated thenext authoring system. The history of these systems revealstwo emerging requirement themes. The first theme is thatthere is a need for more than one level of tutor development.For example, a two-level authoring system might provide aneasy-to-use system tbr novice tutor developers and a deeperlevel of authoring for expert tutor developers. A secondtheme is that the tutor delivery system should becomponential and open so that it can work withcollaborating applications, some of which may not haveeven existed when the authoring system was originallydesigned. The second part of this paper describes oneessential element of a componential approach to simulation-centered tutor development, the specification of simulationservices that may be required by tutors.

I. Authoring Simulation-Centered Tutors:Lessons Learned

We have been involved in the development of a series ofauthoring tools for the development of tutors for manyyears (Towne, Munro, Pizzini, Surmon, Coller & Wogulis,1990; Towne & Munro, 1991, 1992; Munro & Towne,1994; Munro, Johnson, Surmon, & Wogulis, 1993; Munro& Pizzini, 1996; Munro, 1997). A primary motivation forbuilding such authoring systems for developing tutors is toincrease the cost-effectiveness of tutor development. Usinga well-designed authoring system, an author should be ableto much more rapidly develop, test, and modify a tutor thanif a number of lower-level development tools, such asprogramming languages and expert system shells, are used.A cost effective approach will make feasible thedevelopment of a much larger number and wider variety oftutors than would be possible using more expensivetechniques.

IMTS: The Intelligent MaintenanceTraining System (1984-1989)This authoring system, described by Towne & Munro(1988), supported the development of interactive graphical

simulations based on schematics (electrical, hydraulic, ormechanical). Authors could create behaving simulations byconnecting behaving components from a parts library.Additional information about system level symptoms andcauses could be entered in table form. A generictroubleshooting expert could assist a maintenance traineein selecting tests to perform and in evaluating those tests.Figure 1 displays an example of a simple static stateschematic simulation.

va lye

Pump I s--t -~1 /I I ’I I

Pwr ~;upplyAFigure 1. A simple static state simulation

In this figure, there is a switch under the control of thestudent. The student can observe changes in a valve, anactuator, and an output light. These are the indicators in thesimulation. A good deal of usefid instructional interactionwith students can be phrased in terms of the states ofcontrols (such as the switch) and such indicators. Thesimulation authoring system let developers draw objects inall their possible states and enter rules for transitioningamong the states. A separate simulation scene editor wasused to compose these authored objects into connectedsystems.

IMTS included an intelligent monitor of studentperformance called Profile. Profile watched studentsmanipulating controls and noticed changes in indicators. Itwas designed for equipment troubleshooting (faultisolation) training. It made judgments about whatmalfunctions students should suspect, based on theiractions and the indications they had observed. It couldoffer advice on the potential usefulness of tests andobservations being considered by the student, and it could

6O

From: AAAI Technical Report FS-97-01. Compilation copyright © 1997, AAAI (www.aaai.org). All rights reserved.

advise about what should and should not be suspected,based on what had been done in the session.

Lessons Learned from IMTS. IMTS could be used tobuild equipment simulations of a certain class. Withadditional authoring about malfunction effects, it couldalso be used to deliver equipment troubleshootinginstruction. Unfortunately, the naturalness and ease of useof the simulation authoring environment encouraged itsapplication in domains for which it was not designed.¯ Shnulation authoring systems should not be too special-

purpose.The ease of use of the simulation composition systemgenerated demand from a wider authoring communitythan was originally envisioned. The special-purposemaintenance training focus was a negative for this largergroup of authors. The range of systems that could besimulated was also found to be too restrictive.Simulations were based on object states and did notsupport contiimous effects. Some authors needed deepercontrol over simulation objects and simulated systems.One way of describing the simulation authoringlimitations of IMTS would be to say that it tried to betoo intelligent. The authoring system itself had anunderstanding of hydraulic effects, electrical effects, andmechanical effects. As soon as authors tried to apply thesystem to simulating economic systems, chemicalreactions, satellite orbits, or any other domain that didnot fit into the ’equipment’ orientation of IMTS, theauthoring system kept authors from accomplishing whatthey wanted to.

¯ It should be possible to author instruction, as well as togenerate it at run-time.IMTS also offered too little authoring control overinstructional intelligence. Tutor development was fastand effective only if a particular type of maintenancetutor was wanted; no other type of tutor could bedeveloped using the system.

RAPIDS: A Rapid Prototyping ITS DevelopmentSystem (1988-1990)

The lessons learned from IMTS were first applied to ourRAPIDS project (Towne & Munro, 1991). The RAPIDSauthoring system increased the openness and power of thesimulation authoring system by letting authors buildsimulations with continuous value changes, as well as withstate-oriented objects. It required authors to more fullyspecify how values were propagated in a system ofconnected objects, instead of trying to automatically applyphysical laws to every object connection. This made itpossible for authors to build systems that were outside thenarrower domain of equipment simulations permitted byIMTS. Figure 2 below displays a simulation scene for aRAPIDS tutor about a helicopter blade-folding system.

RAPIDS also provided a more open instructionalsystem. It supported a variety of simple instructiontemplates that authors could use to create simulation-

centered tutorials. Authors would build complete graphicalsimulations using one set of authoring tools. Then, using adifferent set of instruction authoring editors, they wouldbuild lessons for delivery in the context of thosesimulations.

Figure 2. A schematic simulation with continuous effects

Lessons Learnedfrom RAPIDS. A lesson of the RAPIDSproject was that still more control needed to be provided toauthors. There was also demand for an easy-to-usesimulation-centered authoring system that could be used onwidely available workstations, rather than only onspecialized Lisp workstations.¯ Simulation authors sometimes require very detailed

control over object behavior.Although the simulation approach was much moregeneral-purpose in RAPIDS than in IMTS, some authorsneeded finer control over graphical features than itprovided. Authors could control universal characteristicsof objects like location, rotation, scale, and visibility, butthey could not control the detailed, unique characteristicsof most graphic primitives, such as fill pattern or color.RAPIDS still encouraged a state-oriented ’bitmap-style’representation of objects.

¯ Ease of instruction authoring is good, but detailedcontrol is necessary.The instructional authoring system was easy to use, butit provided only a few types of structured lessons.Nonetheless, there was considerable interest in usingRAPIDS. Authors were sometimes frustrated by theirinability to make simple changes in the wording orstructure of generated lessons.

¯ Multiple development and delivery platfotTns shouM besupported.Potential users were put off by the fact the RAPIDS, likeIMTS, was available only on specialized Lisp machines.

61

RIDES: A Rapid ITS Development Environment(1990-1996)The RIDES authoring system provides a much richersimulation authoring environment, one that encourages thedevelopment of continuous behaviors and that offered veryfine control over the behavior of graphical objects.Simulations can control the specialized attributes of certaintypes of graphic primitives, including the colors andpatterns of objects, the text of text primitives, and so on.

RIDES offers two levels of authoring for creatingbehaving objects in a simulation. The ’libraries’ authoringlevel lets inexperienced authors select behaving objects (orgroups of related objects) from libraries. See Figure 3,below. These objects can then he pasted into simulationscenes.

Figure 3. Selecting simulation objects fi’om a library.New library objects can be created simply by selecting

authored objects on a simulation scene and saving them ina library.

More expert simulation authors can develop novel newobjects by drawing them (or by importing their graphics)and then writing rules, using the RIDES event andconstraint editors, that control the behavior of those objectsin RIDES simulations. See Figure 4.

RIDES also provides two levels of instruction authoring.A high-level authoring system permits subject matterexperts who are not experienced instructional developers toquickly and interactively produce several different kinds ofsimulation-centered lessons. This approach to authoring iscalled patterned exercise authoring and is shown in Figure5. A lower-level system lets authors who are more expertdevelop lessons with varied internal structures and withfine control over what is said to the students. Thisapproach, called custom instruction authoring, is shown inFigure 6. In this figure, a lesson that was generated using apatterned exercise editor is being modified.

i{

i--~:-~+ i~.-- I 7 i7}i-,i~, ;,.u i {7 :ii

Figure 4. Custom simulation object authoring

Image 6tou,~ e d Object~i~

Figure 5. Authoring a patterned exercise

¯ we.-~ii i: 7 i iii iiiii iiiiiiiiiii ::;~i !,~

+ n ll~ e.,,erc+~e, we’ll 6emen~liale stand~_.d ogera:ion-d s~tup, ~ich iry~ ii

.~-~ N~-~ i iiiii 7;~: i i iiiiiii

Figure 6. Modifying insttTwtion in the custom lesson editorAs a result of applications of the lessons learned during

the development of IMTS and of RAPIDS, RIDES hasbeen widely experimented with in technical trainingapplications. Its acceptance has undoubtedly beenenhanced by the fact that it is an efficiently implementedapplication that runs on a variety of Unix workstations,including PCs running Linux.Lessons Learned from RIDES. RIDES offers a muchbetter range of development approaches that call fordiffering levels of expertise and offer different levels of

62

control than did our earlier authoring and delivery systems.In fact, the range of options for controlling simulationsseems to be about right. However, still more instructionalcontrol is required by some authors. Furthermore, RIDESisn’t multi-platform enough! Developers want to be able todeliver on Windows 95 and, as new platforms emerge,authors will want to deliver tutors on those platforms aswell. Finally, RIDES could be more open and morecomponential, so that it could be more widely used by ourresearch colleagues.¯ Instruction authors need as much power andflexibility

as do simulation attthors.Even the ¢ustonl instruction authoring in RIDES is stillsomewhat too constrained. It needs to be more flexible,in order to give advanced developers more control overthe structure and flow of tutorials. There should be adeep level of representation of instruction that providesthe power and flexibility of a programming language.Many casual authors would never use this deep level ofinstruction, but it should be available for those who needit.

¯ More platforms shouM be supported.In addition to Unix workstations, many developers haverequested support tbr Windows NT and Windows 95--and, ideally, future platforms as well. At least it shouldbe possible to deliver simulations and simulation-centered tutoring on virtually any platform, even if theauthoring system is not universally available.

¯ An open architecture of collaborative components.Not every feature of the RIDES simulation-centeredtutorial development and delivery system is required forevery project to which it has been applied. In particular,some of our research colleagues at other institutionshave wanted to use portions of the RIDES system, suchas its simulation engine or its course administrationsystem, while substituting for other portions of thesystem their own applications. An architecture ofcollaborative components--some providing simulation,others instructional or course management~efinedwith open communication standards, would facilitate theintegration of our work with that of our colleagues.

Summary of Lessons Learned

Support two or more levels of authoring. We havelearned that widespread acceptance of an authoring systemrequires that each of the major aspects of the system shouldsupport at least two levels of authoring: a very easy-to-useinterface that can be employed with little training toproductively generate useful tutorials, and a very flexibleand powerful system for tutorial elaboration and editing bywell-motivated expert developers. Our latest authoringenvironment for simulation-centered tutor development,VIVIDS, will support two levels of simulation authoring,

similar to those of RIDES. Similarly, VIVIDS will supporttwo levels of tutorial authoring: a high level specificationthat is very easy to generate for certain classes ofpredefined tutorial structures, and a detailed tutorialscripting level, which will be more powerful than thatprovided in RIDES.

Make the authoring system extensible. In VIVIDS,authors can add newly defined behaving simulation objectsto the libraries, where they can be utilized by others. Weplan to provide a mechanism for allowing advanced tutordevelopers to create their own templates for rapidinstruction authoring using high-level specifications.

Make the delivery system open and componential. Manycolleagues have expressed an interest in using only aportion of our tutor delivery system, e.g., only oursimulations, in conjunction with their own tutorialcomponents. Our current VIVIDS delivery system is amonolithic application, but we are architecting a newversion that will support much greater openness. Our nextgeneration VIVIDS delivery system, which we callJavaVivids, will consist of a confederation of collaboratingapplications, including a simulation engine, tutorialmodules, a course control system, and a student modelingsystem. Our research partners and other advanceddevelopers will be able to replace one or more of thesecomponents with their own collaboration-compliantapplications.

Support platform independent delivery of tutors.JavaVivids will be implemented in Java (a high-speedoptimized simulation engine component may be availablefor certain platforms), so that the same tutor deliverysystem can be used on any platform that supports Java.

II. Collaborating Components

The most complete and capable of the authoring systemsdeveloped at our laboratory are RIDES (the Rapid ITSDevelopment System) and its immediate descendent,VIVIDS. The key concepts in these systems are¯ Instruction in an interactive graphical simulation

environment¯ Direct manipulation authoring of simulations¯ Facilities for authoring content-based help¯ A highly productive approach to authoring structured

lessons in the context of interactive simulations

¯ Courses organized around learning objectives

Many interactive graphical simulation-centered tutorshave been built using R/DES and VIVIDS, both in ourlaboratory and at other sites. Most of these are centeredaround 2D simulations, such as those shown in Figure 7,below.

63

i i! i

Figure 7. Two 2D simulations built in RIDESSeveral substantial 3D simulations have been built using Links to content based help, hypertext-like browsing

VIVIDS, includin the one shown in Fi Feedback about reference in behavior authoring editors

Figure 8. A 3D simulation Built with VIVIDSRIDES and VIVIDS 1 are monolithic development-and-

delivery environments_that provide a wide range of userinterface features in support of simulation development,tutorial development, and course development. Thesefeatures include the following:Simulation Authoring Features

Behavior specified by ConstraintsAdvantages: Modularity, locality of effect,, cause

tracing, un-authored flow of controlBehavior specified by EventsLibrary Objects

Both graphics and behavior

Special reference typography, error highlighting,pasting objects as references where appropriate, namechanges automatically update in referenced contexts

Multiple levels of Undo and RedoTransparency of Effects

Appearance changes can be accomplished by editingobject data in interactive editors, or by usinggraphical tools. The effects of the graphical toolsare reflected in the object data editors.

Smart Copy and PasteParallel behaviors are maintained when a multiple

selection set is copied and pasted.Find tool

Supports searching for named objects and attributes,searching in constraints or events, searchingamong attribute values.

Simulation debuggerSupports step-by-step execution, tracing, breaks

Instruction Authoring FeaturesBuild certain types of tutorials by demonstrating

procedures in the simulationModify and customize such generated tutorials in an

interactive lesson editorRobust linkage between simulation and instructionSimulation name changes automatically reflected in

instruction, etc.Objectives-based course designTrace lesson executionLog student actionsStudent performance reporting over network

64

VIVIDS-1 Collaboration in the VET Project

We have been conducting a project in collaborationwith the Lockheed Artificial Intelligence Center andInformatiol~ Sciences Institute to explore the potential ofvirtual environments for technical training--VET (Stiles,McCarthy, Munro, Pizzini, Johnson, & Rickel, 1996;Johnson, Rickel, Stiles & Munro, in

Figure 9. Virtual environment with VIVIDS instructionalintelface

The VET proiect m~es use of three major collaboratingsoftware applications: VIVIDS--from our lab, Vista--a3D interactive environment from Lockheed Martinresearch group headed by Randy Stiles, and Steve--anautonomous agent developed by Lewis Johnson and JeffRickel at Information Sciences Institute.

The success of this project has increased our interest indeveloping a more open approach to tutor components. Inthis brief paper, we focus on a single question: What arethe core low-level services that an instruction moduleshould be able to request of a simulation module?

Open Architecture TutorsA successful architecture for simulation-centered

learning environments must be extremely robust and veryopen. It is very important that the architecture itself not beclosely wedded to one particular theory or approach totutoring in the context of simulations, because we mustexpect that our theories will evolve and improve as weconduct research and as we observe the tools that wedevelop in use. In fact, and ideal architecture willencourage the development of a variety of differentinstructional approaches in the context of interactivesimulations.

?

InstructionModule

Student ModelModule

SimulationModule

Figure 10. Oversimplified approach to tutor modulesFigure 10 presents a conventional simple high-levelarchitecture for a tutoring system. In this much-oversimplified figure, we assume that pedagogicallyrelevant domain knowledge can be found in the componentlabeled ’Instruction’.

As we have wrestled with the design and implementationof a real-world approach to these modules, we have foundit useflal to focus on widely required primitive instructionalservices for simulation-based tutors.

To make the instructional services problem tractable, weenvision an instruction system in which there are low-levelinstructional services (such as presenting a piece of text toa student or requiring that a student touch or click on asimulation object), and higher level instructional modules,such as one that presents previously scripted lessons or onethat monitors complex student problem-solving activitiesand offers advice and correction. The high-levelinstructional modules express themselves by calling onlow-level instructional services. Some of these low-levelinstructional services may have nothing to do with thesimulation module. For example, instructional text may bepresented in a window that is not under the control of thesimulation module, or such text may be presented using atext-to-speech or pre-recorded voice system. Figure 11sketches a portion of this type of system.

IxL-~Imefion Simulation Module

,=~ ~°~t~I~l / R~B"-~ I |°~I~al I I

IAutl:°redI-e~"°n| ~-xPea’tTut°rial°t I ~-:m~on~l I II

++,.+ ..... ......... ........ ’ I ILow-le~+l Ia_.~.ax~n Modules .....

+II++’+-°+’++++’+°"¯ -i+++++-i+ I ,l+:--Figure 11. More detailed approach to tutor modules

Below we lay out preliminary lists of

65

¯ Simulation-based presentation services to be providedby a low-level instruction module, and

¯ Evaluative simulation-based student interaction servicesthat are to be provided by low-level instruction incollaboration with the simulation.

We are attempting to identify the primitive vocabularyof simulation-centered tutorial events. We ask for feedbackfrom our colleagues in the simulation-centered tutoringcommunity. Are the proposed sets of low-level servicesadequate for the requirements of the high-level tutorialmodules that they plan to develop in the future?

In what follows, we have organized a list of proposedlow-level student interaction services for tutors into fourgroups.

1 Non-simulation presentation services

2 Non-simulation student judging services

3 Simulation presentation and monitoring services

4 Simulation judging servicesThe first two groups are not of special concern for this

paper, and are not meant as an exhaustive list. Our focus ison the third and fourth sets of services, which relate toauthored simulations.

1 Presentation services (not simulator-based)These services are non-evaluative. The instructionalcomponent may provide these services directly, or mayrequest them from one or more presentation or mediaservice providers. These components are designed tocollaborate in a complete tutor delivery system.

¯ openTextPresenter

¯ closeTextPresenter

¯ repositionTextPresenter

¯ clearTextPresenter

¯ presentText

¯ presentURL

¯ presentMPEG

¯ presentAVI

2 Student judging services (not simulator-based)These services require an action of the student, and must

evaluate the quality of the student’s response, but they arenot dependent on the presence of a simulation.

¯ Get menu answer

¯ Get keypad answer

¯ Get typed answer

¯ Get spoken answer

Of special interest to us, given our focus on simulation-centered tutorials, are the low-level services that a tutormay reasonably expect a collaborating simulation toprovide.

3 Simulation-based presentation and monitoringservices

These services are non-evaluative. The instructional

component can simply request the service and expect aconfirmation that the simulation has carried it out.¯ openSimulation--A simulation produced by an

authoring system will typically be saved as data in a filethat can be opened by a collaborating simulation player.Hard-coded executable simulations would lack theability to open different simulations.

¯ closeSimulation--When a simulation is closed, anyvisible characteristics of the simulation (e.g., openwindows) should disappear.

¯ openScene---Not all simulations will support thedelivery of multiple views (in, for example, differentwindows). Those that do, however, should offer theinstruction module the service of opening a requestedscene.closeScene--If a simulation can open scenes, it shouldalso be able to close them at the request of the tutor.

saveConfigurationISome simulations, such as those wehave developed, have a mechanism for capturing thecomplete state of the simulation and restoring that stateupon request. This is important for many complexsimulations, because the tutor wants the system to be ina particular state before it begins to discuss features ofthe simulated world that may depend upon the state.Some tutors need to capture a state of the simulationbefore letting the student work with the simulation. Thatway, if the student fails to carry out an assigned task, thetutor can restore the state of the simulation beforeremediating the student.

instalIConfiguration--Restore a previously saved stateof the simulation.startSimuiator--lt can be very usefftl to freeze andunfreeze a simulation during the course of a tutorial.

stopSimulator

lockOutStudent--Sometimes a tutor wants simulationeffects to continue (time to pass, animated effects to takeplace, etc.) while denying the student the ability to carryout any manipulations in the student environment.setSimulationClock--Some simulations may exhibitbehaviors that are dependent on the simulated time.

setClockMultiplier--It is often useful to be able tocompress or expand the time scale, so that students canbe shown processes that are too fast (or too slow) to observed ordinarily.

executeEvent--Some simulations have defined events(such as the appearance of an enemy on a radar screen orthe start of a coolant leak in a nuclear power plant) thatthe tutor may want to invoke under conditions of its ownchoosing.setAttribute--The concept of setting a simulationattribute to a particular value is similar to that ofinvoking an event, but it gives a tutor more intimatecontrol over the characteristics of a simulation, becauseevents must be pre-authored to be available in thesimulation.

66

¯ getAttributeVah~eIA tutor can ask the simulation for anattribute value so that it can accurately refer to or discussthat value in the current simulation state. It can alsomake teaching decisions based on features of thesimulation state that arises as a result of studentmanipulations.

¯ getEapressionValue--This service allows a tutor to sendthe simulation any arbitrary expression in the formatsupported by the simulation and to receive back thecurrent value of the expression. This allows the tutor torefer to values that may not be explicitly computed in thesimulation (e.g., "The current output of the fivegenerating units is 1.21 gigawatts.").

¯ addExpressionListener--This service allows a tutor toannounce to a simulation that it would like to beinformed whenever the value of a particular expressionchanges. A common use of this service is to monitorsome aspects of the state of a simulation after directingthe student to achieve a particular goal in the simulatedworld. When the expression of interest becomes true, thestudent has succeeded.

¯ removeEXpressionListener--Lets the tutor unregister apreviously expressed interest that is no longer needed inthe tutorial.

¯ highlightObjectIA simulation should offer the tutorsome mechanism for making graphical components of asimulation visually salient. In RIDES and VIVIDS,highlighting is accomplished by rapidly alternating thecolors of the object or objects that are to be highlighted.

¯ unhighlightObjectIThe tutor also needs some way tomake objects stop being so visually salient. A usefulvariant form of this service is to unhighlightObject All,which restores all the graphics that are currently beinghighlighted to their normal visual appearance, asprescribed by the current state of the simulation.

¯ addObjectListenerIA tutor can ask a simulation to tellit whenever a student touches a simulated object. Thisservice can be used in combination with thelockOutStudent service to let the student point outobjects without manipulating them. It can also be used tomonitor object manipulations.

¯ removeObjectListener--Lets the tutor unregister apreviously expressed interest in the student’s objecttouches.

¯ carryOutUserActionIThis option lets the tutor "reachover the student’s shoulder" to carry out a manipulationin the simulated environment. This service is very usefulfor demonstrating to students how to carry outprocedures. It is also necessary for remediatingerroneous actions in some simulation-centered tutors.

4 Simulation-based student judging servicesThese services may not actually be services of the

simulation itself, because they can be composed from thelow-level services described under 3, above. However, theyare very commonly utilized in tutorials developed using theRIDES and VIVIDS authoring systems, and are likely to

often prove very useful as low-level simulation-centeredinstruction sen, ices. Here are examples of these services inaction.

¯ requireSetControlThis low-level instruction service employs a nmnber of

the low-level simulation services described above torequire that a student carry out a step in a procedure in thesimulation environment. It judges each studentmanipulation, and resets the simulation to its prior statewhen incorrect manipulations are carried out. After anauthor-specified number of unsuccessful attempts, thecorrect object to manipulate is visually highlighted, and theaction is carried out for the student..

¯ requireReadlndicatorStudents are required to touch the named indicator and

then to tell what value is displayed by the indicator. (InRIDES and VIVIDS simulations, numeric values areentered using a graphical keypad, while other values areentered using a popup menu.) If the student fails, automaticremediation points out the indicator and says what value itdisplays.

¯ requireFindObjectThe FindObject instructional service only requires that a

student touch a named object. It offers remediation throughhighlighting automatically after an author-determinednumber of attempts..

¯ requireStateAttainmentIn R/DES and VIVIDS, students can be required to

achieve a particular state of the simulation. For example,the tutor can specify that the student must ensure thatcertain operational indicators are displaying their normalvalues. At the author’s discretion, the tutorial can notice assoon as the student succeeds and continue with the lesson,or the tutorial can require that the student notify that thestate has been achieved (by clicking the Continue button).The tutorial can point out to the student what aspects of therequired goal have not been achieved. If the student fails tosucceed in achieving the designated state, a previouslyrecorded procedure for doing so can be demonstrated.

A Call for Comments

The list of simulation services in 3 above is a candidatelist of universal low-level services that tutors might expectsimulations to provide. What is missing? What additionalsimulation services do your tutors require? What additionallow-level services do your simulations provide for tutors?Please address comments and suggestions for service listmodifications to munro@rcf, use. edu

67

Acknowledgments

The RIDES and VIVIDS projects are sponsored by theUnited States Air Force under Contract F33615-90-C-0001. Jim Fleming of Armstrong Laboratory serves astectmical program manager. The developers of RIDES andVIVIDS include Mark Johnson, Allen Munro, QuentinPizzini, David Surmon, Douglas Towne, James Wogulis,and Lee Coller. Design suggestions, exhaustive testing,encouragement, and support were provided by MichaelCrumm, Donna Darling, Zuzanna Dobes, David Feldon,Randall Hill, Carol Horwitz, Len Mackie, Wes Regian,Trish Santos, Chuck Swanberg, Rusty Trainor, JoshWalker, and others.

The VET project is sponsored by the Office of NavalResearch under Contract No. N00014-95-C-0179 awardedto Lockheed Martin Co. This work is being performed incollaboration with colleagues at the Lockheed Martin AICenter--Randy Stiles, Laura McCarthy, and SandeepTewari--and with colleagues at USC Information SciencesInstitute--including Lewis Johnson, Jeff Rickel, and RichAngros.

References

Horwitz, C., Fleming, J.L., and Munro, A, Demonstrationof RIDES: An Authoring Shell for Simulation-BasedInstruction in the Systems DemonstrationsHandbook, ITS’96, Montreal, Qu6bec, Canada, June1996.

Johnson, W. L., Rickle, J., Stiles, R. and Munro, A.Instructional agents in virtual environments. Toappear in Presence, in press.

Munro, A. Authoring interactive graphical models. In T.de Jong, D. M. Towne, and H. Spada (Eds.), TheUse of Computer Models for Eaplication, Analysisand Experiential Learning. Springer Verlag, 1994.

Munro, A. RIDES QuickStart, Los Angeles: BehavioralTechnology Laboratories, University of SouthernCalifornia, 1997.

Munro, A., Johnson, M.C., Pizzini, Q.A., Surmon, D.S.,and Wogulis, J.L, A Tool for Building Simulation-Based Learning Environments, in Simulation-BasedLearning Technology Workshop Proceedings,HS’96, Montreal, Qu6bec, Canada, June 1996.

Munro, A. Johnson, M.C., Surmon, D. S., and Wogulis, J.L. Attribute-centered simulation authoring forinstruction. In the Proceedings of AI-ED "93--WorldConference on Artificial Intelligence in Education,1993.

Munro, A. and Pizzini, Q. A. RIDES Reference Manual,Los Angeles: Behavioral Technology Laboratories,University of Southern California, 1996.

Mmtro, A. & Towne, D. M. Productivity tools forsimulation centered training development,Educational Technology Research andDevelopment, 1994.

Pizzini, Q.A., Mtmro, A., Wogulis, J.L., and Towne,D.M., The Cost-Effective Authoring of ProceduralTraining, in Architectures and Methods forDesigning Cost-Effective and Reusable ITSsWorkshop Proceedings, ITS’96, Montreal, Qu6bec,Canada,, June 1996.

Stiles, R., McCarthy, L., Munro, A., Pizzini, Q., Johnson,L., Rickel, J., Virtual Environnwnts for ShipboardTraining, Intelligent Ship Symposium, AmericanSociety of Naval Engineers, Pittsburgh PA Nov1996.

Towne, D. M. & Munro, A. The intelligent maintenancetraining system. In J. Psotka, L. D. Massey & S. A.Mutter (Eds.) Intelligent tutoring systems: Lessonslearned. I-Iillsdale, NJ: Lawrence ErlbaumAssociates, Inc., 1988.

Towne, D. M. & Munro, A. Simulation-based instructionof technical skills. Human Factors, 1991, 33, 325-341.

Towne, D. M. & Munro, A. Supporting diverseinstructional strategies in a simulation-orientedtraining environment. In J. W. Regian and V. J.Shute (F_As.), Cognitive approaches to automatedinstnwtion. Hillsdale, NJ: Lawrence ErlbaumAssociates, Inc., 1992.

Towne, D. M., Munro, A., Pizzini, Q. A., Surmon, D. S.,Coller, L. D., & Wogulis, J. L. Model-building toolsfor simulation-based training. Interactive LearningEnvironments, 1990, 1, 33-50.

68