WO1994019784A1

WO1994019784A1 - Scenario development system for vehicle simulators

Info

Publication number: WO1994019784A1
Application number: PCT/US1994/001665
Authority: WO
Inventors: Norman S. Copperman
Original assignee: Atari Games Corporation
Priority date: 1993-02-17
Filing date: 1994-02-17
Publication date: 1994-09-01
Also published as: US5660547A

Abstract

A vehicle simulator including a system for development of vehicle simulation scenarios. The vehicle simulation system includes simulated vehicle controls providing input signals to a computer, and feedback devices, including a video display, providing a user with feedback on the operation and location of the simulated vehicle as it is driven through a simulated universe. One aspect of the invention is a scenario development system which uses the vehicle controls, the computer and the output devices to enable a scenario developer to develop a simulation scenario which includes other programmed vehicles. The scenario developer can determine when and where the other programmed vehicles become active in a simulated universe in which the scenario takes place, as well as determine when and where the programmed vehicles leave the simulated universe. The scenario developer can also program the path of the programmed vehicles through the simulated universe by simply driving the programmed vehicles through the simulated universe using the vehicle controls and the feedback devices to define the path that the scenario developer wishes the programmed vehicle to travel.

Description

SCENARIO DEVELOPMENT SYSTEM FOR VEHICLE SIMULATORS

Microfiche Appendix A microfiche appendix containing computer source code is attached. The microfiche appendix comprises two sheets of microfiche with a total of 65 frames, including one title frame.

The microfiche appendix contains material which is subject to copyright protection. The copyright owner has no objection to the reproduction of such material, as it appears in the files of the Patent and Trademark Office, but otherwise reserves all copyright rights whatsoever.

Background of the Invention Field of the invention The present invention generally relates to vehicle simulators and, more particularly, is concerned with a scenario development system for a vehicle simulator. Background of the Invention

A vehicle simulator can be defined as a system that simulates the operating conditions of a vehicle in an environment. Typically, the simulator will include all of the controls that the vehicle being simulated would have and the simulator will try to simulate the operation of the vehicle as it would operate in the real world. For example, if the vehicle being simulated was an automobile, the simulator would typically include controls such as a steering wheel, a gear shift, brakes, and an accelerator, and the automobile would be simulated in an environment which usually includes a road.

Vehicle simulators provide the means to efficiently train operators of the vehicle without exposing the operator to the dangers associated with operating the vehicle in the real world. The simulator permits the operator to experience how the vehicle will operate in a given situation including those situations where the vehicle would otherwise be damaged like, for example, when the operator makes a mistake in his handling of the vehicle. The experience garnered though making mistakes on a simulator is invaluable when compared to the inherent risks of vehicle damage and operator injury associated with making a driving error in a real-life situation. As an example, in a police training application, a student can learn the limits of a police cruiser or guidelines for pursuing another vehicle, and be tested in these areas without any of the associated risks of real life training. Nowadays, vehicle simulators are often implemented by using computers and computer driven video displays. Typically, these vehicle simulators include the standard vehicle controls and instruments for a specific vehicle, as well as a video display which represents to the user the world outside of the vehicle he is operating. In these types of simulators, the computer generates a scenario which requires the user to maneuver the vehicle within a simulated universe. Within this simulated universe, the computer also generates specific events such as random traffic patterns, oncoming traffic, cars pulling away from curves, etc., to thereby give the user the feeling of operating the vehicle in traffic and also' to^* test the user's ability to respond appropriately to the computer generated events.

A major shortcoming of these simulators is that the number of scenarios and events contained within the simulator is limited. As a consequence, the user of simulator eventually repeatedly experience all of the events programmed in the simulator. Once a student has seen the same scenario or event a repeated number of times, the educational value of continued simulator operation is diminished.

An additional problem with presently known computer based simulators is that generally all of the scenarios and events are developed and incorporated into the simulator in softwar form prior to use of the simulator. Often, the perso developing the scenario is not a person who would be mos knowledgeable about what types of scenarios and events shoul be included in the vehicle simulator to maximize it educational benefit. For example, a computer programmer ma have some idea as to what scenarios and events should b included in an automobile simulator that is intended to trai police officers to pursue other vehicles. However, th programmer is certainly not as knowledgeable about the type of events that are likely to occur during such a pursuit as i an experienced police officer. The educational benefi derived from vehicle simulators will only be completel realized if the scenarios and events are as realistic a possible in that they closely approximate what the drive actually experiences in the real world. Accordingly, scenarios and events developed by individuals with n expertise in instruction of actual vehicle . operation will likely not be as valuable as such scenarios and events developed by experienced instructors.

Generally, the instructor who provides guidance for the student users of vehicle simulators is very knowledgeable about the scenarios and events that the student is likely t encounter in the real world. For example, the operation of simulator designed to train police officers to correctl operate vehicles in a city environment will include instruction by an experienced police officer. While this training officer may be knowledgeable about what occurs in the real world, he is generally unable to reprogram the simulato to be more realistic as the computer programs which drive vehicle simulators are usually extremely complex, hence, changing the programming for the simulation to make it more realistic or even adding additional events or scenarios to the simulator is usually beyond the ability of most trainin officers.

Hence, there is a need for a vehicle simulator in whic the set of scenarios and events can be continuously and easil

SnEEURul.E26) odified. Additionally, there is a need for a simulator tha permits a person, who is not an expert in compute programming, to develop additional scenarios and events t occur during the simulation.

Summary of the Invention To meet the aforementioned needs, the present inventio includes a system and method for creating simulation scenario in a vehicle simulation system that is easily programmed by a instructor or a user who need not be experienced at compute programming. Generally, the system can be implemented in an vehicle simulator requiring a specific simulation scenari involving other vehicles. The developer or programmer of th scenario can use the vehicle controls and the simulato display to define the characteristics and movements of number of programmed vehicles, as well as other fixed objects, in the simulated universe.

Specifically, the system of the present invention permits a scenario developer to sit at the controls of the simulator, select a desired type of vehicle to appear in a simulation scenario, view a simulated universe, and progra characteristic such as the speed and path of the vehicle i the simulated universe by manipulating the controls of the simulator. Thus, the developer "drives" the programme vehicle through the simulated universe in the manner in which the developer wants the vehicle to operate in the scenario he is creating. In this fashion, the developer of the simulation scenario can program a specific event, e.g. a car going through an intersection, by simply driving a car through the intersection in the simulation universe. The developer can program various separate events including different vehicles in this same fashion to thereby develop an entire scenario having multiple traffic events.

Similarly, the system of the present invention permits a scenario developer to position objects, e.g., stop signs and direction signs in the simulated universe for an automobile driving simulation, by selecting the object from a menu and

SUBSTITUTE SHE . using the simulator controls to move through the simulate universe to the position that the developer wishes the object to appear. In this fashion, the developer of a simulation can easily position objects in the simulated universe along the anticipated path of a subsequent user of the simulation system.

In one specific aspect of the present invention, the simulation system for training drivers to operate automobiles in traffic is programmed such that the movements of other vehicles, the positioning of objects, and the status of traffic lights in the simulated universe are defined by a scenario developer using the simulator controls. To program a vehicle to appear in a scenario for a student, the developer selects a type of automobile from a menu of automobile types, uses the simulator controls to drive the automobile to a position in the simulated universe, initiates a recording process, and drives the automobile along a path in the simulated universe in the manner the developer wishes the vehicle to appear when the simulation is running. This recording can be played back during simulation. Similarly, as mentioned above, the developer can also select an object, such as a road sign, from a menu, use the simulator controls to drive to the position in the simulated universe where the developer wants the object to appear, and initiates a process to record the presence of the object at that position for a specified period of time when the simulation is being used by a user or student.

In another aspect of the simulation system of the present invention, vehicles and objects programmed to appear in the simulated universe by the scenario developer are programmed to appear at a specific time on a scenario clock. The time on the scenario clock that the vehicle and objects appear in the simulated universe can be selected by the scenario developer so that the objects or vehicles appear in the simulated universe in close proximity to the vehicle being operated by a user or student when the simulation is being run. For example, in an automobile simulation, automobiles can be programmed to drive through intersections in front of th vehicle being operated by the student or other automobiles ca be programmed to pull out from curbs.

Further, with the simulation system of the presen invention, several different types of simulations can b developed. For example, the developer can develop one type o simulation where the student follows a pursued or rabbi vehicle through the simulated universe. In this type o simulation, the scenario clock can be programmed to incremen in a variable fashion, depending upon the distance between th user's vehicle and the rabbit vehicle. Specifically, as th user's vehicle gets closer to the rabbit vehicle, the scenari clock increments at a faster rate . • This causes the rabbi vehicle and all the other vehicles previously programmed t appear in the simulation to move faster. Conversely, as th user's vehicle falls further behind the rabbit vehicle, th scenario clock increments at a slower rate, causing the rabbi vehicle and all the other preprogrammed vehicles to mov slower. Hence, the scenario clock increments at a tim selected to maintain a pre-selected relative distance betwee the rabbit vehicle and the vehicle driven by the user. Th developer knows that when the scenario is played for student, the student driving an observer vehicle following th rabbit vehicle will always be a pre-selected relative distanc behind the rabbit vehicle. Hence, when the developer i programming vehicles to appear in the simulation, th developer knows the approximate position the student will b in when the scenario is being played. Consequently, th developer can, for example, program a vehicle to driv directly at the position the pre-selected relative distanc behind the rabbit vehicle. When the scenario is replayed fo the student, the vehicle will appear to the student to driv directly towards the student, regardless of how fast th student drove the observer vehicle in the scenario. In another aspect of the simulation system of the presen invention, the developer can develop a simulation where th user or student will drive through the simulated univers following road signs or other directions. The developer, whe developing the simulation can drive a phantom vehicle alo the path which the developer intends the student to follo When the simulation is run and the student maneuvers throu the simulated universe on the intended path, the phanto vehicle driven by the developer during the development of t simulation is not shown. However, the scenario time clock which determines when other programmed vehicles enter an leave the simulated universe, can be programmed to variabl increment depending upon the distance between the vehicl driven by the student and the position of the phantom vehicl as driven by the developer during the development of th scenario. In other words, the .scenario clock can b configured so that no matter how fast the user drives hi vehicle, the scenario clock changes variably so that th user's vehicle is at substantially the same geographica position as the phantom vehicle at any given time shown on th scenario clock. Consequently, the developer can program othe vehicles to appear or events to occur in the simulate universe in places which necessitate action, such as evasiv action, by the user during the simulation and these event will occur at the appropriate time, forcing the user o student to take the necessary evasive action, regardless o how fast the student drives the vehicle during the simulation Furthermore, in another aspect of the present invention the developer can also control the variable incrementing o the scenario clock using the scenario development system o the present invention. Specifically, while developing th scenario using the phantom vehicle, the developer can set radial distance around the phantom vehicle that defines a area in which the scenario clock will increment at a defaul rate if the user is within this radius with his vehicle whil the scenario is running. Using this feature, the developer o a simulation can selectively cause the scenario clock to spee up and slow down depending upon how close the user is to th phantom vehicle.

Additionally, in yet another aspect of the presen invention, the scenario simulation system simulates operatin an automobile through a city or suburban setting. Th developer of the simulation can program traffic lights locate at different intersections in the simulated universe to chang states, e.g., change from red to green and vice-versa, a different times on the scenario clock by manipulating th simulated controls of the simulated vehicle and driving th simulated vehicle through the simulated universe to a positio where the developer wishes to change the state of the lights The developer then depresses an appropriate button to recor the time on the scenario clock that the light state i supposed to change. In this fashion, the developer can easil program a scenario where the traffic lights change a different times on the scenario clock. These and other object and aspects of the presen invention will become more fully apparent from the followin description and appended claims taken in conjunction with th accompanying drawings.

Brief Description of the Drawings

Figure 1 is a block diagram of one presently preferre embodiment of a vehicle simulation system of the presen invention including a scenario development process.

Figure 2A is a user's view of a typical street scen corresponding to a video screen display provided by th vehicle simulation system of Figure 1 when the vehicl simulation system is in the pursuit mode.

Figure 2B is a user's view of a typical street scree corresponding to a video screen display provided by th vehicle simulation system of Figure 1 when the simulatio system is in the driving test mode.

Figure 3 is a front elevation view of one preferre embodiment of a set of input devices and an instrument pane for the simulated vehicle of the vehicle simulation system o Figure 1.

Figure 4 is a flow diagram of one preferred embodiment o a function forming a portion of the control process of Figur

SUBSTITUTE SHEET. RULE 26 1, which performs a previously developed simulation scenario.

Figure 5 is a flow diagram of one preferred embodiment o the "scenario_timer" function of Figure 4.

Figure 6 is a flow diagram of one preferred embodiment o the "update_scenario" function of Figure 4.

Figure 7 is a diagram of a typical developer menu scree provided by the vehicle simulation system of the presen invention.

Figure 8 is a is a diagram of a typical program men screen provided by the vehicle simulation system of th present invention.

Figure 9 is a flow diagram of a preferred embodiment o the "program_vehicle" function called from the add vehicl line of Figure 8 for adding a programmed vehicle to simulation scenario under development, using the vehicl simulation system of the present invention.

Figure 10 is a flow diagram of a preferred embodiment o the "to_program_observe" function of Figure 9.

Figure 11 is a flow diagram of a preferred embodiment th "create_and_program" function of Figure 9.

Figure 12 is a flow diagram of a preferred embodiment o the "do-place-start" function of Figure 8, for setting th user's starting position in a simulation scenario unde development using the vehicle simulation system of the presen invention.

Figure 13 is a flow diagram of a preferred embodiment o the "run_timer" function of. Figure 8.,. for timing the distanc between two locations within the simulated universe using th vehicle simulation system of the present invention. Figure 14 is a diagram of an edit menu screen provided b the vehicle simulation system of the present invention.

Figure 15 is a flow diagram of a function for replayin the path of the rabbit or phantom vehicle called from th Replay Path line of Figure 14, using the vehicle simulatio system of the present invention.

Figure 16 is a diagram of a traffic lights menu scree provided by the vehicle simulation system of the presen invention .

Figure 17 is a flow diagram of a preferred embodiment o a "do_program_lites" function called from the Traffic Light

Menu of Figure 16 which allows the scenario developer t program the traffic lights in the simulated universe to chang states.

Figure 18 is a flow diagram of a preferred embodiment o a function called from the Traffic Lights Menu shown in Figur 16 which replays the scenario and displays the changing state of the traffic lights in the simulated universe.

Figure 19 is a diagram of a replay window menu provide by the vehicle simulation of the present invention whic allows the developer to specify particular windows, or period of time, of the scenario that will be replayed to the studen once the student has completed the scenario.

Figure 20 is a diagram of a traffic control menu provide by the vehicle simulation system of the present inventio which allows the developer to set a traffic control distanc which affects the incrementing of the scenario clock and th relative positions of the programmed vehicles and th student's vehicle in the simulated universe.

Figure 21 is a diagram of a setup menu provided by th vehicle simulation system of the present invention, whic allows the developer to review the scenario under developmen under different programmed parameters.

Figure 22 is an overhead view illustrating a portion o a simulated universe containing vehicles and vehicle path programmed by the developer using the vehicle simulatio system of the present invention. Figure 23 is an organizational chart illustrating on presently preferred embodiment of the data structures employe to develop and use a simulation scenario via the vehicl simulation system of the present invention.

Detailed Description of the Preferred Embodiments

Reference is now made to the drawings wherein lik numerals refer to like parts throughout. This application i a continuation-in-part of application No. 08/018,951 file February 17, 1993, which is hereby incorporated by referenc in its entirety.

It should be understood that a driver training or vehicl simulation system 100 as hereinafter described is applicabl to any type of vehicle that is operated by a human. Th present invention includes simulations which are easil generalized to driver training systems for all kinds o simulated vehicles and all types of vehicle operation.

SYSTEM OVERVIEW

Figure 1 is a block diagram illustrating one presentl preferred embodiment of the driver training or vehicl simulation system 100 of the present invention. The syste 100 is preferably operated by a user 102 (show schematically) , such as a student who desires to improv driving performance or a scenario developer who intends t develop a new scenario for the student. A more specific embodiment of the system 100 as presente in the following figures and description comprises a vehicl simulator for driver training such as training police officer to drive police cars in realistic conditions. Specifically the vehicle simulator is used to train students to eithe drive a pre-selected course and respond to events occurring i the simulated universe or, to pursue vehicles through simulated universe. At times, the user 102 can be a instructor, the developer of the simulation scenario or student. In Figure 1, the user 102 preferably sits in a booth o housing (not shown) such as the one described in th assignee's U.S. patent entitled "Rear Entry Booth an Adjustable Seat Apparatus for a Sit-Down Arcade Video Game" U.S. Patent No. 4,960,117 hereby incorporated herein b reference. In that way, distractions are minimized and th user 102 can concentrate on self-improvement of his drivin technique. In the driver training system 100, the user 102 moves turn signal lever 104, manipulates a plurality of dash an column switches 105, manipulates a key turned ignition switc 107 for stating the simulated automobile, depresses a brake pedal 106 which is part of an ABS brake simulation system 131, manipulates a key ignition 107, and depresses a gas pedal 108 in the customary manner. In addition, an automatic transmission shifter 110 is manipulated by the user 102 to select a reverse gear or one of a plurality of forward gears. A steering wheel 112 is also turned by the user 102 to guide the simulated vehicle in the desired direction of travel through the simulated universe. Further, the user 102 ca manipulate three rocker switches 182, 184 and 186 which are shown and described in greater detail in reference to Figure 3.

The mechanical inputs provided by the user 102 to the input devices 104 through 112 and the switches 182, 184 and 186 are translated by transducers into electrical signals which are fed into a computer 114. The mechanical inputs on the brake pedal 106 are translated into electrical signals by the ABS brake system 131 and the signals are fed to a bridge interface circuit 132 connected to the computer 114. The computer 114 further receives both inputs and downloaded programs from a personal computer (PC) 103 which is preferably an IBM compatible computer having a 100 megabyte hard drive and a 4 megabyte RAM. The personal computer 103 and the computer 114, are interactively connected, via a communication link 140. The link 140 should be capable of handling high speed digital data transmissions, on the order of 10 megabits per second, and it preferably uses a communications circuit such as an ADSP 2105 or 2101 manufactured by Analog Devices to ensure sufficiently rapid communication between the computer 114 and the personal computer 103. As can be appreciated by a person skilled in the art, the personal computer 103 can be connected to a network of simulation systems 100 and can provide information and download programs in any number of well known manners. In the presently preferred embodiment, the computer 11 includes a general purpose microprocessor such as a Motorol 68000 (not shown) or another member of the Motorola 680x microprocessor family. One function of the 6800 microprocessor is palette manipulation for video displa purposes. In addition to the 68000 microprocessor, th computer 114 preferably includes a model processor (DSP) , suc as an AT&T DSP32C, a digital signal processor (ADSP) , such a an Analog Devices ADSP-2101, and a graphics processor (GSP such as a Texas Instruments 34010 Graphic System Processor none of which are shown. The DSP performs velocity acceleration, and position calculations. The ADSP provide the "higher-level" functions of video display such a translation, rotation, scaling, and shading while the GS efficiently performs dither patterning, rendering, and th low-level graphics work of writing polygons (so-called polygo graphics) to the video display 122.

The presently preferred computer 114 also includes a rea only memory (ROM) comprising 256 kilobytes of storage for sel test; as well as a random access memory (RAM) comprising: 1.7 megabytes for downloaded programs, object definition data, an graphics universe data; an additional 0.5 megabytes of share memory for additional downloaded graphics object data, share with the ADSP processor. The center monitor in the vide display 122 (Figure 1) also includes an additional 1 megabyt of RAM for downloaded scenario traffic data. Furthermore, th presently preferred computer 114 also incorporates additiona random access memories for each processor as follows: DSP - 6 kilobytes; ADSP - 16 kilobytes of program memory (for th programs downloaded from the programs downloaded from th computer RAM or the stand alone personal computer 103) , 1 kilobytes of data memory; and GSP - 384 kilobytes of progra memory and 640 kilobytes of memory used for image storage an program memory (for the programs downloaded from the compute $AM or the stand along personal computer 103) . The GS employs video random access memory (VRAM) for improved vide display rates. The computer 114 executes scenario software which i stored in a memory (not shown) such as a 128 X 8k, 70-100nse Random Access Memory (RAM) . The scenario software can be on of a number of software scenarios, such as a pursui simulation, stored within the PC 103 which can be downloade into the computer 114 in response to commands executed at th PC 103. The computer software executed by the computer 114 i logically organized to include a control process 120. The control process is further preferably organized into scenario play process 119 and a scenario development process 121.

The control process 120 receives digitized signals fro the input devices 104-112 as well as other digitized input signals from the personal computer 103 via the communications link 140. The control process 120 then passes data from these digitized signals, across a data path 118, to a model process 116 that models the velocity and acceleration vectors of the simulated vehicle. Thus, at a time T, position data, i.e., the Cartesian coordinates of the car, are determined by the model process 116. The position data is made available, across the data path 118, back to the control process 120. Accordingly, the control process 120 applies the "rules of the road" to the new position of the car, and initiates signals t drive a video display 122, a pair of speakers 123 and 124, a low pass filter 133 and an instrument panel 130. The filter 133 provides a low pass filtered signal to an amplifier 134 which is connected to a relay 135, which in turn is connected to a speaker 136 positioned adjacent to a user's seat (not shown) . The relay 135 is preferably a low voltage relay manufactured by Potter & Brumfield, model No. T70L5D, and is further coupled to a relay control circuit 137 which disconnects the speaker 136 when the system 100 is either powering up or down. The system comprising the components 133 through 137 provides the user 102 with road feel cues, such as the feeling of hitting a curb, and is described in the assignee's co-pending U.S. patent application entitled "Vehicle Simulator with Realistic Operating Feedback", Serial No. 08/018,950, filed February 17, 1993.

The play process 119 of the control process 120 provide these output signals to the user 102 when the user 102 i engaged in the scenario. The development process 121 provide these output signals to the developer when the developer i programming a vehicle to appear in the scenario by driving th programmed vehicle through the scenario. The developmen process 121 further utilizes the location information provide by the model process 116 to record the paths of the programme vehicles that the developer has driven through the scenario Hence, the developer of a scenario can develop a particula scenario by simply using the simulated vehicle controls an the video display 122 to program vehicles to appear in th simulated universe, as will be described in greater detail i reference to Figures 7-23 below.

The control process 120 further provides a user viewpoin into a graphical representation of the vehicle universe. I the preferred vehicle simulation embodiment, the computer 11 generates polygon graphics to the video display 122. On preferred video display device, such as model no. 25K719 available from Wells-Gardner of Chicago, Illinois, is a multi synchronous display that can be configured to display 512 384 pixels. The video display 122 may include a plurality o video devices arranged in a semi-circle to give the user 10 a simulated view similar to that of a real vehicle such as car. This arrangement is described in the assignee's co pending U.S. patent application entitled "Modular Displa Simulator", Serial No. 07/704,373.

The video display 122 preferably generates a color, three-dimensional graphical representation of the environment, i.e., the user's perspective of a graphical universe includin items such as a roadway. The speakers 123 and 124 produc sounds such as gear changes, engine revving, skidding, and s on. The instrument panel 130 includes a speedometer 17 (Figure 3) to indicate the speed of the simulated vehicle, a indicator 176 (Figure 3) for the gear selected by using th shifter 110, left and right arrow lights to indicate direction selected by using the turn signal lever 104, a various other indicator lights. Thus, the user 102 presented with real-time feedback from the output devices 12 123, 124, 130 and 136 that is personalized according to h own individual performance and what he encounters in t simulated universe.

The control process 120 further provides feedback simulate the feeling of a steering wheel in a real automobi while being driven. This is preferably accomplished in t same manner as described in assignee's patent entitl "Control Device such as a Steering Wheel for Video Vehic Simulator With Realistic Feedback Forces", U.S. Patent N 5,044,956. In response to inputs from the ABS brake syst 131 via a bridge interface circuit 132, the control proce 120 also provides feedback to the brake pedal 106 via the A brake system 131. The system 131 simulates the brakes on automobile equipped with an ABS braking system on the bra pedal 106 as described in the co-pending U.S. pate application entitled "Vehicle Simulator With Realisti Operating Feedback" Serial No. 08/018,950, filed February 17 1993.

The basic operation of the simulator system 100 will n be described. A program containing a driving simulati scenario is downloaded from the personal computer 103 to t computer 114 which executes the program. Pursuant to t programmed scenario, the computer 114 provides a graphic universe to. be displayed to the- user 102 via the video- displa 122 along with associated sounds via the speakers 123, 124 The user 102, in response to what he sees in the video displa 122 and what he hears from the speakers 123, 124 manipulate the driving controls to thereby drive the simulated vehicle Basically, the user 102 starts the automobile via the ignitio switch 107, puts the automobile in gear via the automati transmission sifter 110, depresses the gas pedal 108 to mak the automobile move, depresses the brake pedal 106 to make t automobile stop and steers the automobile with the steerin wheel 112. In response to the user inputs provided via the inpu devices 104 - 112, the control process 120 of the computer 11 passes data to the model process 116 via the data path 11 which enable the model process 116 to model the velocity an acceleration vectors of the simulated vehicle thereb determining the Cartesian coordinates of the vehicle. Thi data is then passed back to the control process 120 via th data path 118 and is then used by the control process 120 t provide additional inputs to the user 102. For example, th Cartesian coordinates as determined by the model process 11 may determine that the user 102 has driven the simulate vehicle over a curb in the simulated universe. This cause the control process 120 to send an appropriate signal to th speakers 123 and 124 to model the sound of hitting the curb, send an appropriate signal to the low frequency speaker 136, via the low pass filter 133, the amp 134 and the relay 135, t model the physical sensation of hitting the curb, and to sen an appropriate signal to the steering wheel 112 to model th feeling on the steering wheel which results when an automobil hits a curb. Further, the control process 120 also provide feedback to the user 102 through the ABS brake system 131 whe the user 102 applies the brakes sufficiently hard to enabl the system.

In the particular embodiment of a pursuit trainin simulator, the user 102 is generally prompted by the compute 114 to follow a pursued or rabbit vehicle 150 (Figure 2) through, the simulated universe.-. Throughout this. ,detaile description of the preferred embodiments section, the ter pursued vehicle shall be used interchangeably with the ter rabbit vehicle. Similarly, in the particular embodiment of driver trainer, the user 102 is generally prompted by th computer 114 to follow road signs 151 (Figure 2A) through th simulated universe. During the course of either the pursui training simulation or the driver training simulation, th user 102 will have to respond to events generated by th program, such as oncoming traffic and the like. These event are programmable by a scenario developer in the manne described hereinbelow.

Figure 2A is a diagram of a video screen display showin a typical pursuit scenario scene. From the first perso viewpoint of Figure 2A, it is seen that the student is "place inside" of the vehicle being simulated, i.e., an "observer vehicle and looks out at a simulated universe 146 in a fashion analogous to a driver looking through a windshield The developer of the scenarios, which uses the system 100 i the manner described more fully below, is similarly oriente when driving a vehicle in the simulated universe 146 durin the development of a scenario. The user 102 views a thre dimensional simulated graphical universe 146 as projected ont the two dimensional screen of the video display screen 122 The scene represented in Figure 2A is one wherein the user 10 is looking forward through a windshield while driving th simulated vehicle and proceeding on a road 148 in th simulated universe 146 in pursuit of a pursued (or rabbit) vehicle 150. A sidewalk 152, a number of houses 154 as wel other typical scenery seen in a suburban setting are locate on either side of the road 148. As is shown in Figure 2A, th simulated universe 146 also includes one or more intersection 156 which may contain one or more vehicles 158 as cros traffic and a traffic signal 153.

Figure 2B illustrate a display of a typical drivin training scenario scene as seen by the user 102 on the vide display 122. The typical driving training scenario scene i similar to the pursuit simulation scene shown in Figure 2 except that it lacks the rabbit vehicle 150. Further, th typical driving training scenario scene preferably includes plurality of indicator signs 151 which indicate to the use 102 which direction they should turn at intersections and th like to remain on the programmed path of the drivin simulation. As is further explained below, in one preferre embodiment, the vehicles 158 shown in Figures 2A and 2B, th stoplight 153 and the signs 151 can be programmed by scenario developer using the simulation system controls an the video display 122 of the simulation system 100 shown i

SHEET RULE.26 Figure 1 .

The instrument panel 130 of the system 100, as ^' shown i Figure 3, includes a speedometer 172, a transmission gea indicator display area 176, a transmission gear indicator 174 and an indicator and warning light area 178. Several inpu devices of the system 100, including the turn signal leve 104, the automatic transmission or shift lever 110, and th steering wheel 112, are also shown. The speedometer 172 an indicators become active when the user 102 (Figure 1) "starts the simulated vehicle. The speedometer 172 provides measurement of velocity. The gear indicator 174 visuall displays the position of the shift lever 110 upon the gea indicator display area 170. The indicator and warning ligh area 178 includes the following designators (left to right) left turn signal 178a, temperature, battery, seat belt, brake oil pressure, high beam (headlights) , emergency flasher, an right turn signal 178b. The turn signal lever 104 is mounte on a steering column housing 180. Figure 3 also shows th enter rocker switch 182 which is movable between an enter an a set position 183, the select rocker switch 184 and the abor rocker switch 186 mounted adjacent to the dashboard of th simulated vehicle. The switches 182, 184 permit the user 10 to select between various menu choices and the abort rocke switch 186 enables the user 102 (Figure 1) to end a simulatio or development sequence while the simulation or developmen sequence is running.

II. SIMULATOR OPERATION WHILE PLAYING A SCENARIO

To more fully explain the present invention, th operation of the simulation system 100 by a user in previously developed simulation scenario is now described.

Figure 4 is a flow diagram showing the top level functio of the control process 120 (Figure 1) while a student i driving in a typical scenario. In one presently preferre embodiment, the control process 120 is written in the "C language and cross-compiled using a Green Hills Software Inc. "C" compiler available from Oasys, a division of Xel, Inc. of Waltham, Massachusetts. The control process 120 i then executed on a Motorola 68000 microprocessor located i the computer 114. However, one skilled in the art o computers will recognize that many other computer language and computers, may be used to achieve the same result. Computer source code including relevant portions of th control process 120, of which the top level function shown i Figure 4 is illustrative, is attached herewith in th accompanying Microfiche Appendix and is entitled "pursuit.c." One skilled in the technology will recognize that the steps i the flow chart shown in Figure 4, as well as other flow charts included herein, are only means - for representing the functional equivalents of their source code counterparts, an so the diagrams may include material that does not completel parallel the named location or operation of the function i the source code included in the Microfiche Appendix.

Referring now to Figure 4, prior to a start state 220, scenario program is downloaded from the personal computer 103 to the computer 114. For example, the scenario program may be a scenario designed to train student police officers to pursue vehicles through a simulated universe consisting of a suburba town or it may be a scenario designed to train student drivers to deal with different traffic conditions. From the start state 220 the computer 114 (Figure 1) directs the vide display 122 to display, in state 222, a series of menus fro which-the student may, depending on the scenario that is bein run by the computer 114, select the type of vehicle he will drive, or the type of weather. The selection is accomplishe by the student manipulating the switches 182, 184 and 186

(Figure 3) . Preferably, in some of the scenarios that are available to be downloaded from the computer 103, a series of default choices will be made for the type of vehicle an weather. After selections are made for vehicle and weather, if desired, or the default choices are accepted, the student selects the "start scenario" option and then depresses one of the rocker switches 182, 184 or 186 to signal the computer 114 to proceed to the next state.

The computer 114 then initiates a process in state 224 b which the path driven by the student in the observer vehicl can be recorded. This recording preferably reflects how th student driver responded to various events, e.g. vehicl running a stop light, and it can be played back at a late time to permit analysis and critique of the student' performance. Preferably, the recording can be played from th point of view of the student driving the vehicle. Further, a will be described later in conjunction with Figure 19, in thi preferred embodiment, the developer of a scenario can selec only portions of the scenario, such as those portions havin traffic events, like vehicle running stop lights, to be playe back to the student. The computer 114 then initiates a scenario play loop i state 226 by reading the input signals provided by the studen via the user input devices 104 - 112 (Figure 1), i.e., th steering wheel, accelerator etc. The computer 114 uses thes inputs in state 230 to determine the position of the observe vehicle driven by the student in the simulated universe b sending signals on the data path 118 to the model process 116

(Figure 1) representative of the student's input signals. The model process 116 processes the input signals and determine the Cartesian coordinates of the vehicle relative to a pre- defined starting position within the simulated universe 146

(Figure 2) . As will be described in greater detail i reference to Figures 8 and 12 below, the starting points of a scenario in the simulated universe 146 can be determined b the developer of the scenario. Typical starting point of a scenario in the simulated universe 146 include being parked o the side of a road as traffic is driving past, or in a parkin lot that requires the student to drive the simulated vehicle onto a busy street.

Once the computer 114 has determined the position of the observer vehicle containing the student in state 230, it the enters a function 236 entitled "display_world. " In the function 236, the computer 114 uses the positional informatio determined in state 230 to update the display of the background features in the simulated universe 146, e.g. the houses 154, roads 148, etc., on the video display 122.

The display of the background scenario, as well as the display of the other objects to be discussed below, is performed by a digital signal processor (not shown) within the computer 114 (Figure 1) such as an ADSP 2101 chip available from Analog Devices of Norwood Massachusetts. The background scenario can include the houses 154, sidewalks 152, stoplights 153 and signs 151 and streets 148 as shown, for example, in Figures 2A and 2B.

The computer 114 then proceeds to a function 242 entitled "scenario_timer" where the computer -114 updates a scenario clock. The scenario clock is preferably a clock internal to the computer 114 which can be incremented in a variable fashion as will be described in reference to Figure 5 below. In this preferred embodiment, the time on the scenario clock determines when other vehicles are scheduled to appear and disappear in the simulated universe 146 and it also determines the positions on the paths of these vehicles, including the rabbit vehicle 150 in a pursuit type scenario, through the simulated universe 146. Additionally, as will be described in greater detail in reference to Figures 16 and 17 below, the stop lights 153 can be programmed to also change states at selected times according to the scenario clock.

From the scenario_timer function 242, the computer 114 proceeds to a function 244 entitled- "update_scenario" where programmed vehicles, including the rabbit vehicle 150 and the other programmed vehicles 158, are introduced, updated and removed from the simulated universe 146. In the preferred embodiment, the scenarios are developed so that other vehicles, including the rabbit vehicle 150 (Figure 2) in a pursuit-type scenario, are programmed to appear and disappear in the simulated universe 146 at specific times of the scenario clock. Further, the paths of these vehicles through the simulated universe 146 is recorded and stored in the memory of the computer 114 as a continuous series of locations where the vehicle is to be in the simulated universe 146 at particular times on the scenario clock. Hence, once the scenario clock has been updated by the computer 114 in the scenario_timer function 242, the computer 114 then retrieves the stored cartesian coordinates indicative of the programmed location of the vehicle for that particular time on the scenario clock and subsequently updates the video display 122 to display the vehicle at this location. The update_scenario function 244 is described in greater detail in reference to Figure 6 below.

The computer 114 then generates output signals to the user 102 in state 246. These output signals consists of sounds, e.g. the sounds of a collision,- tires screeching etc., via the speakers 123 and 124 (Figure 1) , appropriate road feel cues via the low frequency speaker 136, feedback on the brake pedal 106 via the ABS brake system 131, and feedback on the steering wheel 112. Preferably, the computer 114 determines which output signals to provide to the student based upon the location of the observer vehicle driven by the student in the simulated universe 146 as determined in the update_scenario function 244. Further, the simulator in this preferred embodiment incorporates the feedback systems disclosed in the assignee co-pending application entitled "Vehicle Simulator with Realistic Feedback", Serial No. 08/018,950, filed February 17, 1993.

The computer 114 then moves to state 248 and determines whether the scenario has ended. In this preferred embodiment of the present invention, the simulation ends when either the student has crashed his vehicle, the student has manipulated the abort switch 186 (Figure 3) or the student has driven the observer vehicle to the programmed end of the simulation. If any of these conditions have occurred, the computer 114 moves to an end state 250 where the student is informed that the scenario is over and the vehicle simulator 100 awaits further instructions from either the student or an instructor via the personal computer 103 (Figure 1) . If, in decision state 248, the computer 114 determines that the simulation scenario has not ended, the computer returns to state 226 where it again reads the user inputs from the user input devices 104 - 112 (Figure 1) . Preferably, the computer 114 completes the loop comprising the states 226 through 248 sufficiently quickly so that the scenario clock, simulated background and other vehicles are shown and updated on the video display 122 as they would be if the student were driving a vehicle in the real world.

In^'this fashion, the simulation system 100 of the present invention allows the student to drive the observer vehicle through the simulated universe 146 which contains traffic lights and other vehicles which can be programmed to create traffic situations in the universe 146 to which the student must respond. Hence, the simulation system 100 of the present invention provides a realistic simulation of driving a vehicle in the real world and thereby enhances the educational experience of using a vehicle simulator.

Figure 5 illustrates a flow diagram for the "scenario_timer" function 242 of Figure 4. The scenario clock is a clock which is tied to an internal clock (not shown) which preferably four millisecond clock that is part of the simulation system 100 and is preferably contained within the computer 114. As will be described in greater detail below in reference to Figure 6, in this preferred embodiment of the invention, the position of the programmed vehicles, comprising all of the vehicles within the simulated universe 146.,. other than, the observer, vehicle.,, and. the. state of the stoplights 153 is defined as a function of the time according to the scenario clock. Specifically, the programmed vehicles are programmed to appear in the simulated universe 146 at a set time on the scenario clock, travel along a path where their location is updated at set intervals of the scenario clock, and then leave the simulated universe 146 at the programmed scenario clock time. Further, these programmed vehicles are stored within the memory of the computer 114, when the simulation scenario is running, and sorted in terms of when they are to appear in the simulated universe as is more fully described in reference to Figure 23 below.

Referring now to Figure 5, the "scenario_timer" function 242 operates as follows. Beginning at a start state 290, the computer 114 initially determines, in decision state 292, the adjusting mode that has been programmed for the scenario clock in this particular scenario. In each scenario developed using the scenario development system of the present invention, the developer of the scenario can select one of three different formats for incrementing the scenario clock. One format, entitled RABBIT ADJUST, is specifically configured to be used in pursuit-type simulations where the student in the observer vehicle will be chasing the rabbit vehicle 150. In the RABBIT ADJUST format, the scenario clock is variably incremented depending upon how close the observer vehicle is to the rabbit vehicle. In another format, entitled PHANTOM ADJUST, the scenario clock is variably incremented depending upon how close the observer vehicle driven by the student is to a phantom vehicle. The phantom vehicle is not visible when the student is engaged in the simulation. This is the vehicle that was driven by the developer when the simulation scenario was developed. Finally, the third format for incrementing the scenario clock comprises incrementing the clock in fixed intervals, which, in the preferred embodiment, are preferably 4 millisecond intervals. When the computer 114 determines that the format for incrementing the scenario clock is the RABBIT ADJUST format, the computer 114 moves to state 294. and initially -ascertains the distance between the observer vehicle and the rabbit vehicle 150. This is done by comparing the current location of the observer vehicle, as given by the model process 176 (Figure 1) in state 230 (Figure 4) to the current location of the rabbit vehicle determined in the update_scenario function 244. The computer 114 then moves to a state 296 and determines whether the observer vehicle is within a pre- selected minimum distance of the pursued vehicle 150. If the observer vehicle is not within the preselected distance, the computer 114 returns from the decision state 296 to state 294 to re-ascertain the distance between the observer vehicle and the rabbit vehicle 150 (Figure 2) without incrementing the scenario clock. As can be appreciated, if the student in the observer vehicle falls to far behind the rabbit vehicle 150, or takes a wrong turn, the scenario clock is not incremented and, consequently, neither the position of the rabbit vehicle 150, nor the position of any of the other programmed vehicles in the simulation are updated. This essentially halts the programmed simulation. Hence, from the point of view of the student driving the observer vehicle, the rabbit vehicle 150 and the other programmed vehicles appear to be stationary in the simulated universe 146 until the student drives the observer vehicle within^' the pre-selected minimum distance of the rabbit vehicle 150. If the observer vehicle is within the preselected distance, the computer 114 then adjustably increments the scenario clock in state 300. In the presently preferred embodiment, the amount by which the scenario clock is incremented is dependant upon the distance between the observer vehicle and the rabbit vehicle 150. Preferably, the scenario clock is incremented by a time sufficient to maintain a mean distance of between the student driven observer vehicle and the rabbit vehicle 150 regardless of how fast the student drives the observer vehicle. Specifically, the scenario clock is incremented by a smaller amount when the observer vehicle begins to fall behind the rabbit vehicle 150. This results, in the rabbit vehicle 150 travelling along its preprogrammed path in the simulated universe 146 at a slower pace and thereby allows the student in the observer vehicle to catch up. Conversely, if the student increases the speed of the observer vehicle so that it gets closer than the mean distance to the rabbit vehicle 150, the computer 114 increments the scenario clock by a larger amount. This results in the rabbit vehicle 150 travelling along its preprogrammed path in the simulated universe 146 at a faster pace in order to maintain the mean distance between the observer vehicle and the rabbit vehicle 150. Further, since the positions of all other vehicles in the simulated universe 146 are also updated in the update_scenario function 244 based on the scenario clock, these vehicles will also travel slower in the simulated universe 146 when the observer vehicle falls behind the rabbit vehicle 150 and faster when the observer vehicle comes closer to the rabbit vehicle 150. Consequently, when the developer is developing the scenario, the developer can program certain events to occur with the programmed vehicles, which necessitate the student driving the observer vehicle to take evasive action. Because of the variable scenario clock feature, the events will occur at the appropriate time to require the evasive action regardless of the speed that the student is driving the observer vehicle. As an example, if the developer programs a scenario to have a programmed vehicle driving through an intersection just in front of the observer vehicle, requiring the student to steer around the programmed vehicle, the programmed vehicle will appear in the intersection at the appropriate time no matter how fast the student is driving the observer vehicle. Once the scenario clock has been incremented in the state 300, the computer 114 proceeds to a return state 302 from which it proceeds to the update_scenario function 244 (Figures 4 and 6) .

If the computer 114 determines in decision state 292 that the scenario increments the scenario clock in a fixed fashion, the computer then proceeds to state 304 and increments the scenario clock by a fixed amount. The developer of this type of scenario has less control in scheduling events such as programmed vehicles driving through intersections, running lights and the like, in order to require the student driving the observer vehicle to respond. This is true since the student in the observer vehicle may drive slower or faster than the developer had anticipated. However, developing a scenario which increments the scenario clock in this fashion can provide a scenario which is very realistic^*of driving a vehicle in a normal setting. Once the scenario clock has been incremented by the pre-fixed amount in state 304, the computer 114 then proceeds to the return state 302 from which it proceeds to the update_scenario function 244 (Figures 4 and 6) .

Finally, if the computer 114 determines in decision state 292 that the scenario is programmed to increment the scenario clock according to the PHANTOM ADJUST MODE, the computer 114 moves to a state 306 and ascertains the distance between the observer vehicle, driven by the student and a phantom vehicle. The phantom vehicle is a vehicle which is programmed to drive through the simulated universe on the intended path of the student by the developer when the developer is developing the scenario. The path of the phantom vehicle is then recorded by the computer 114, as will be described below in conjunction with Figure 8, and, once the scenario is being played for a student, the phantom vehicle is used as a bench mark for determining how much to increment the scenario clock. When the simulation is being played for the student, the phantom vehicle is not visible. However, in state 306, the computer 114 ascertains the distance between the phantom vehicle and observer vehicle from the position of the observer vehicle given in state 230 (Figure 4) and the pre-recorded position of the phantom vehicle at the current time on the scenario clock.

Once the computer 114 determines the distance between the observer vehicle and the phantom vehicle, the computer 114 then determines whether the observer vehicle is within a pre¬ defined radius of the phantom vehicle. The pre-defined radius can be defined by the developer as is more fully discussed in reference to Figure 20 below. If the observer vehicle is within the pre-defined radius, the computer 114 then moves to state 310 and increments the scenario clock by the normal pre¬ set fixed increment. Subsequently, the computer 114 proceeds to the return state 302 from which it proceeds to the update_scenario function 244 (Figures 4 and 6) .

If, however, the computer 114 determines in decision state 308 that the observer vehicle driven by the student is not within the set radius of the phantom vehicle as programmed by the developer, the computer then moves to state 312 and adjustably increments the scenario clock. Specifically, i the observer vehicle is not within the pre-defined radius, th computer 114 causes the scenario clock to be incremented s that the position of the phantom vehicle at the incremente time is substantially within the pre-selected radius of th observer vehicle driven by the student in the simulation. Consequently, when the position of the other programme vehicles in the simulated universe 146 are updated in th update_scenario function 244, they are updated to th positions they are programmed to be at the new time on th scenario clock. Note, that, if the observer vehicle i stopped in the simulated universe 146 outside of the pre selected radius, the computer 114 does not increment th scenario clock and effectively freezes the scenario. Hence, the positions of these vehicles, relative to the observe vehicle driven by the student, will be substantially the sam as the position of these vehicles relative to the phanto vehicle. Once the scenario clock as been either fixedly o adjustably incremented in states 310 or 312, the computer the proceeds to the return state 302 from which it proceeds to th update_scenario function 244 (Figure 4 and 6) .

Hence, the simulation system 100 of the present inventio can be programmed by the developer so that the scenario cloc controlling the positions of the programmed vehicles and th stop lights can be either fixedly incremented, or adjustabl incremented based upon the relative positions between th student driven observer vehicle, and. a reference vehicl provided by either the rabbit vehicle 150 or the phanto vehicle. Adjustably incrementing the scenario clock accordin to the RABBIT ADJUST or PHANTOM ADJUST mode permits th developer to develop a scenario in which programmed vehicle are programmed to appear at certain locations at certain time on the scenario clock to thereby force the driver of th simulated vehicle to take evasive action. Consequently, whe the simulation is being run for a student, the programme vehicles will appear in the correct location at the correc time to force the evasive action, as the scenario clock ha been adjustably incremented so that the student is substantially in the anticipated location at substantially the anticipated time on the scenario clock for the pre-programmed event to occur. Figure 6 illustrates an exemplary flow diagram illustrating the operation of the computer 114 as it performs the "update_scenario" function 244 shown in Figure 4. From a start state 262 the computer 114 (Figure 1) determines in decision state 264 whether any programmed vehicles are scheduled to be created in the simulated universe 146 at the current time on the scenario clock as determined in the scenario_timer function 242 (Figures 4 and 5) . The programmed vehicles are stored within the memory of the computer 114 preferably sorted in terms of when, on the scenario clock, they are to be created in the simulated universe 146. If the computer 114 determines in decision state 264 that a vehicle is scheduled to be created, the computer 114 initiates the display of the programmed vehicle in the simulated universe 146 in state 266 on the video display 122 (Figure 1) , provided the observer vehicle driven by the student is in a position to see the programmed vehicle.

If the computer 114 determines in decision state 264 that no programmed vehicle is scheduled to be created in the simulated universe 146 at the current time on the scenario clock, the computer 114 then determines in decision state 268 whether any of the programmed vehicles are currently active, i.e.,. in existence, in the simulated universe 146. If the computer 114 determines that one or more programmed vehicles are currently active, the computer 114 moves to state 270 and retrieves from memory the current time path data and attributes of a first programmed vehicle active in the simulated universe 146 at the current time.

The computer 114 then determines, in decision state 272, whether this programmed vehicle is scheduled to be removed from the simulated universe 146 at the current time on the scenario clock, i.e., the current time on the scenario clock is this programming vehicle's programmed end time. If the programmed vehicle is scheduled to be removed from the simulated universe 146 the computer 114 removes the programmed vehicle and it is no longer displayed in the simulated universe 146 on the video display 122. If the computer 114 determines that the programmed vehicle is not scheduled to be removed from the simulated universe 146, the computer 114 then moves to state 276 and updates the programmed vehicle to its programmed position in the simulated universe 146 at the current scenario time as given by the path data for this programmed vehicle.

The computer 114 then proceeds to determine in decision state 278 whether this is the last programmed vehicle active in the simulated universe 146 that must be updated. If this is not the last vehicle active in the simulated universe 146, at the present time on the scenario clock, the computer returns to state 270 where it recalls the data about the next active programmed vehicle in the simulated universe 146 at the present time on the scenario clock. The computer 114 then loops through states 270 - 278 for each of the vehicles active in the simulated universe 146. In this fashion, the position of each of the programmed vehicles active in the simulated universe 146 is updated.

Once the positions of each of the active programmed vehicles are updated to their programmed positions at the current time on the scenario clock, or if the computer determines there are no active vehicles in decision state 268, the computer 114 then determines- in decision state 282 whether the stop lights 153 (Figure 2B) are scheduled to change at the current time on the scenario clock. As will be described in greater detail below in reference to Figures 16 and 17, the developer can schedule the stop lights 153 in the simulated universe 146 to change from green to yellow and then to red, and from red to green at different times on the scenario clock. If the current time on the scenario clock is a time at which the stoplights are scheduled to be changed, the computer 114 then appropriately changes the stop lights in state 284. Hence, the student driving the observer vehicle in the simulated universe 146 sees each of the stop lights 153 visible in the video display 122 (Figure 1) change from red to green, green to yellow, or yellow to red depending upon the programmed change at this particular time on the scenario clock. The computer 114 then proceeds to the return state 280. From the return state 280 the computer 114 generates output signals to the user in state 246 as described above in reference to Figure 4. The foregoing describes operation of a typical simulation developed using the simulation development system of the present invention. As can be seen by this description, one particular advantage of the present . invention is that the developer of the simulation can program vehicles to drive a path in the simulated universe 146 which necessitates the student in driving the observer vehicle to take evasive action. Further, the simulation system includes a scenario clock which can be programmed to adjustably increment so that the programmed vehicles will be in the correct place to necessitate evasive action on the part of the student, regardless of how fast or slow the student is driving the observer vehicle. The same is true for schedule changes in the stop lights 153. A more detailed description of how the developer develops such a scenario is described below.

III. PROGRAMMING A SCENARIO

The process for developing a simulation scenario, i.e., the developer process 121 (Figure 1) , including either a pursuit simulation scenario or a driving test simulation like those discussed above, will now be described. In the presently preferred embodiment, the developer of the scenario sits at the controls of the simulation system 100 in the same manner as the student or any other user 102 (Figure 1) . Further, the development of the simulation scenario by the scenario developer is accomplished using the vehicle input devices 104 - 112 (Figure 1) , a display of the simulated universe 146 in the video display 122 (Figure 1) as well as the rocker switches 182, 184, and 186 (Figure 3)^'. The developer process 121 of the computer 114 (Figure 1) is preferably activated in response to commands given at the keyboard of the personal computer 103.

Basically, scenarios are developed using the simulation system 100 by the developer sitting at the controls of the simulated vehicle, entering the simulated universe 146, and selecting a vehicle that the developer wishes to appear in the universe 146. The developer then drives the vehicle being programmed along a path in the simulated universe 146 in the manner that the developer wishes the programmed vehicle to perform. The computer 114 records the path and the manner that the developer drove the programmed vehicle for later replay during operation by a user. Hence, all the developer has to do to develop a complex scenario in the simulation system 100 is to simply drive the vehicles in the universe as he wishes the vehicles to perform in the simulation.

Included in the attached Microfiche Appendix is the source code entitled "pursuit.c" and "trflite.c" used to implement the scenario development process 121 of the present invention. This source code also includes routines and functions analogous to the previously described routines and functions implemented by the computer 114 when a scenario is being played. Functions described herein which appear in quotation marks, e.g., "to_program_observe", are the names of some of the functions within the source code which perform the described operations.

Figure 7 illustrates a Developer Menu 320 which is the first menu that is displayed to the developer of the simulation scenario on the display screen 122 (Figure 1) after the development process 121 of the simulation system 100 has been initiated. Figure 7 illustrates that the Developer Menu 320 has an identifying header portion 322 and a box portion 334 which has a Setup Menu line 334a, a Program Traffic line 334b, an Edit Traffic line 334c, a Traffic Lights line 334d, a Replay Windows line 334e a Traffic Control line 334f. The developer uses the Developer Menu 320 to select the next menu containing options necessary to develop the scenario. The scenario developer selects between the lines 334a-334f by moving a shaded line or cursor to the desired Menu line in the box 334. The developer moves between the lines 334a-334f by pressing up or down on the select rocker switch 184 (Figure 3) . When the developer is on the desired menu line 334a-334e, he then presses the enter rocker arm switch 182 to initiate the menu or function contained on that line. Preferably, this method of selecting between menu lines is the same method used for selecting between menu lines of all the menus herein described relating to this preferred embodiment. If the developer manipulates the abort rocker switch 186 (Figure 3) at any time during the development of a simulation scenario, the computer 114 returns the developer to the Developer Menu 320 by replacing the then existing display on the display screen 122, with a display of the Developer Menu 320 as seen in Figure 7.

Figure 8 illustrates a Program Traffic Menu 329 that is displayed to the developer on the display screen 122 when the Program Traffic line 334b of the Developer Menu 320 (Figure 7) is selected. From this menu, the developer is able to program vehicles to appear in the scenario under development, and program the path these vehicles drive in the simulated universe 146 as well as set the starting position for the student driving the observer vehicle in the simulated universe 146 when the scenario is played. The Program Menu 329 contains an identifying header 330, a Scenario Path Time Used header 324, which indicates how much time on the scenario clock has been programmed on the current scenario under development, a Scenario Path Time Available header 326, indicating how much time on the scenario clock is available for the current scenario under development, and a Number of Paths Header 330, which indicates the total number of paths programmed for vehicles in the current scenario under development. In the presently preferred embodiment, there is a limit of 256 vehicles that can be programmed into any one simulation scenario. However, if additional memory space is provided in the computer 114, additional vehicle paths can be programmed into a specific simulation scenario.

Figure 8 also includes a programming box 340 containing a Next Path ID# line 340a, an Add Vehicle line 340b, a Set Startup Position line 340c, a Set Primary Linked Station line 340d, a Scenario Start Time line 340e, a Time Path line 340f, a Traffic Lights line 340g and a Delete All Paths line 340h. The developer selects between the lines 340a-340g using the select and enter rocker switches 182 and 184 (Figure 3) in the manner described above. The functions performed by the computer 114 when each of these lines 342a through 342f are selected will now be described.

The Next Path Id # line 340a provides an indication of the next available ID number for a particular vehicle. In this preferred embodiment, a three digit ID number, e.g. 002, 015 etc. is assigned to each programmed vehicle which is programmed to appear in the scenario. The developer can either select a particular ID number to be assigned to a programmed vehicle using the select and enter rocker switches 182 and 184 or the computer 114 will automatically assign the next available number to the programmed vehicle.

The Add Vehicles line 340b allows the developer to add a programmed vehicle to the scenario under development. Specifically, using the Add Vehicles line 340b, the developer can command the computer 114 to perform a series of functions whereby the developer can drive a programmed vehicle through the simulated universe 146, using the input controls 104 - 112 and receiving output signals from the output devices 122 - 136, in the manner that the developer wishes the programmed vehicle to perform when the scenario is running. The Set Startup Position line 340c allows the developer to set the starting position for the student driving the observer vehicle in the simulated universe 146 when the simulation is played. Selecting the line in 340e initiates a series of functions which place the developer in the simulated universe 146 where the developer drives to the desired starting position in the same fashion as the student drives the observer vehicle.

The Set Primary Linked Station line 34Od is used when there is more than one simulation system 100 linked together in a network. In the preferred embodiment of the present invention, more than one simulation system 100 can be linked together so that more than one student can simultaneously drive in a simulation scenario at any one time. Further, the simulation system 100 of the present invention is configured so that when more than one simulation system 100 is linked together, each of the vehicles driven by the students appears in the video display 122 of the other students when the students are within view of each other in the simulated universe 146. Hence, the students driving in the simulation scenario not only have to respond to the traffic conditions created by the vehicles programmed by the developer to appear in the simulated universe 146, but also to the traffic conditions created by the other students driving in the simulation scenario.

The Set Primary Linked Station line 340c is used by the developer to set one of the simulation systems 100 as the primary station that provides a signal to all of the other simulation systems 100 in the network to thereby synchronize the updating of the position of the programmed vehicles and any change of the stop light 153 in the simulated universe 146. One method of synchronizing the video displays 122 is to have the primary station send a scenario clock signal to each of the other simulations systems 100, which then use this signal as the scenario clock for updating the position of the programmed vehicles. If the scenario clock is programmed to adjustably increment in either the phantom or rabbit adjust modes, then the position of the observer vehicle driven by the student in the primary station simulation system 100 is used as the basis for incrementing the scenario clock. Another method of synchronizing the video displays 122 is to have the primary station simply provide the positions and video displays of each programmed vehicle on the network interconnecting the different simulation systems 100. The Scenario Start time line 34Oe permits the develope to set a time on the scenario clock from which the compute 114 will begin replaying the scenario when the developer i adding a programmed vehicle using the Add Vehicle line 340a as will be described in greater detail in reference to Figure 9 and 10. This allows the developer to add a programme vehicle at a certain time during the scenario without havin to replay the entire scenario from the beginning.

The Time Path line 34Of, allows the scenario developer t enter the simulated universe 146 and use a stop watch to tim how long it takes to drive between two locations in th simulated universe 146. The developer can then use thi information to aid in scheduling programmed vehicles to appea in the simulated universe 146 to thereby create a traffi situation requiring action by the student, e.g., a programme vehicle driving through an intersection as the student in th observer vehicle enters the intersection. The function calle by the Time Path line 342f is discussed in greater detail i reference to Figure 13 below. The Traffic Lights line 34Og allows the developer t select whether the traffic lights 151 (Figure 2) in th simulated universe 146 will change according to a progra selected by the developer, as will be described in greate detail below in reference to Figure 16, or whether the traffi lights 151 will change at pre-selected default times on th scenario clock.

The Delete All Paths line 34Oh allows the developer t instruct the computer 114 to erase each of the programme vehicle attributes and vehicle paths from its memory. Th operation of the computer 114 as it performs the function indicated by the lines 340a - 340h will now be described i reference to Figures 9 - 13.

Figure 9 illustrates the flow diagram followed by th computer 114 in one preferred embodiment of the presen invention for implementing a function 400 entitle "program_vehicle" called when the developer selects the Ad Vehicle line 340b of the Program Menu 329 (Figure 8) . Th program_vehicle function 400 is the function performed by the computer 114 when the developer wishes to add a programmed vehicle into the scenario. With this function, the developer can select the position in the simulated universe 146 that the programmed vehicle appears, the time on the scenario clock that it appears and the path that it drives through the simulated universe 146.

Initially, the computer 114, moves from a start state 400 to state 402 where it assigns the new programmed vehicle to be added, and its path through the simulated universe 146, as well as an identification number 000 to 255. This number is preferably the next highest available or unassigned number within the range 000 to 255 or the number specified by the developer on the line 340a (Figure 9) . After assigning the programmed vehicle an identification number, the computer 114 implements a function 404 entitled "show_vehicle" . In the function 404, the computer 114 causes a series of vehicle types to be displayed to the developer on the video screen 122 (Figure 1) , allowing the developer to select the vehicle type for this programmed vehicle. The computer 114 then determines, in state 406, whether the developer has selected a vehicle type for the new programmed vehicle. If the developer has not selected one of the available vehicle types, the computer 114 returns to the "show_vehicle" function 404. Selection of vehicle types is preferably accomplished by using the select rocker switch 184 to move between displayed vehicles and the- enter rocker switch to select the desired vehicle. In the preferred embodiment, the developer can select the programmed vehicle to be one of a police cruiser, a van, a truck, a compact, a sedan, a Jaguar, a Corvette and a Ferrari. Of course, the type of vehicle can be changed by programming, and could include any type of vehicle, including, for example, aircraft, boats, animals, etc. depending on the universe to be displayed. Graphical references of each of the vehicles are then stored in the memory of the computer 114 for subsequent replay.

If the developer has selected a vehicle type, the computer 114 then moves to state 408 and records in memory th vehicle type selected for this programmed vehicle. Th computer 114 then performs a function 410 entitle "to_mark_observe" where the computer 114 generates on th video display 122 (Figure 1) the simulated universe 146 an instructs the developer to drive to the position within th simulated universe 146 where he can observe the previousl programmed vehicles within the scenario when the scenario i replayed. Once the developer has driven to this position an has appropriately signalled the computer 114, the compute then performs a function 412 entitled "replay_to_mark" . I the "replay_to_mark" function 412, the computer 114 replay the previously programmed scenario from the Scenario Star Time as designated by the developer on the Scenario Start Tim line 340e of the Program Menu 329 (Figure 8) . The compute 114 replays the scenario in the same manner it plays th scenario to a student 102 as previously described in referenc to Figure 4. Specifically, the computer 114 generates th previously programmed vehicles within the simulated universe 146 in substantially the same manner as described in relation in the "update_scenario" function 244 (Figures 4 and 6) .

From the "replay_to_mark" function 412, the computer 114 moves to state 414 and determines whether the developer has pressed the select rocker switch 184 (Figure 3) . If the developer has not pressed the select rocker switch 184, the computer 114 returns to the "replay_to_mark" function 412 where it continues to replay the scenario as it was previousl recorded.

If the developer has pressed the select rocker switc 184, the computer 114 proceeds to a function 416 entitle "to_program_observe" . In the function 416, the computer 114 freezes the replay of the scenario by stopping the scenari clock, and instructs the developer to drive to the positio within the simulated universe 146 that he desires th programmed vehicle being added to appear in the simulate universe 146 during this scenario. Hence, the computer 114 allows the developer to drive to a position in the simulate universe 146 where he can observe the previously programme scenario as it unfolds, freeze the display and the scenari clock at a particular point in the previously programme scenario and then drive to the position where he wishes th new programmed vehicle to appear.

After the developer has driven to this position, th developer presses the enter rocker switch 182 (Figure 3) thereby signalling the computer 114 to perform a function 41 entitled "create_and_program. " In the create_and_progra function 417, the computer 114 instructs the developer t drive the simulator in the simulated universe 146 in th manner that he wishes the new programmed vehicle to appear i the simulated universe 146. When the developer drives a instructed, the computer 114 starts the scenario clock thereby restarting the scenario and initially records th start time and the start location for this vehicle, and the records the subsequent locations in the simulated universe 14 of the programmed vehicle until the developer signals to th computer 114 that he is finished programming the path of th programmed vehicle. From the "create_and_program" functio 417, the computer 114 proceeds to a return state 418 where i returns the developer to the program menu 329.

Figure 10 is a flow diagram illustrating the operation o the computer 114 when it is performing th "to_program_observe" function 416. From a start state 420, where the computer 114 is replaying the previously programme scenario on the video 122 as seen from the position th developer drove to in the "to_mark_observe" function 410, th computer 114 moves to state 421 and freezes the video displa 122 by stopping the scenario clock. The computer 114 moves t state 422 and instructs the developer to drive to the positio in the simulated universe 146 where he wants the ne programmed vehicle to appear and then reads the input provided by the developer via the input devices 104 - 11 (Figure 1) while the developer drives to the desired position

The computer 114 then moves to state 424 and determine the position of the vehicle in the simulated universe 146 b sending signals on the data path 118 to the model process 11 representative of the developer inputs on the input device 104 - 112 (Figure 1) . The model process 116 then processe the input signals and determines the Cartesian coordinates o the developer in the simulated universe 146 relative to th starting position based on these inputs. The computer 11 then generates output signals to the developer in state 426 These output signals include sounds representative of drivin transmitted via the speakers 123 and 124, as well as road fee cues transmitted via the speaker 136, and vehicle contro feedback feelings transmitted via the steering wheel 112 an the brake pedal 106 (Figure 1) . The computer 114 then move to state 430 and updates the image on.the video display 122 t display the background, e.g., the streets 148, the sidewalk 152, the houses etc., of the simulated universe 146 based o the most recent determined position of the vehicle driven b the developer, as given by the model process 116 in state 424

The computer 114 then checks, in decision state 432, t see if the developer has manipulated the enter rocker switc 182 (Figure 3) indicating that he wants the computer 114 t begin recording the path of the programmed vehicle to b added. If the developer has not manipulated the enter switc 182 in decision state 432, the computer 114 returns to stat 422 where it again reads the inputs provided by the developer The computer 114 continues the loop comprising states 42 through 432 until the developer manipulates the enter rocke switch 182 once he has arrived at the desired startin position for the new programmed vehicle. Once the develope manipulates the enter rocker switch 182, the computer 11 moves to a return state 434 from which it initiates th "create_and_program" function 417. Hence, th to_program_observe function 416 allows the developer to driv in the simulated universe 146 to the desired starting positio while the scenario clock is stopped and the other programme vehicles are frozen in place in the simulated universe 146 This permits the developer to view the relative positions o each of the programmed vehicles in determining when a ne

SUBSTITUTE S programmed vehicle is going to enter into the simulate universe 146.

Figure 11 is a flow diagram illustrating the operation o the computer 114 as it executes the "create_and_program" function 417. In the function 417 the computer 114 allows th developer to program the path of a new programmed vehicle i the simulated universe 146 by simply driving the vehicl through the simulated universe 146 in the manner the develope wants the vehicle to perform. In a start state 440, th computer 114 displays the simulated universe 146 on the vide display 122 (Figure 1) from the position the developer drov the vehicle to in the "to_program_observe" function 410. Th computer 114 then moves to state 442 and un-freezes th display by restarting the scenario clock, thereby permittin the positions of the already existing programmed vehicles t be updated along with the traffic lights 153. From the perspective of the developer, this results in the programme vehicles beginning to move along their programmed paths through the simulated universe 146. The computer 114 then moves to state 444 and reads the inputs provided by the developer via the input devices 104 - 112 (Figure 1) as the developer drives the programmed vehicle on the desired path and in the desired manner through the simulated universe 146. The computer 114 then moves to state 446 and determines the position of the programmed vehicle while it is being driven by the developer in the simulated universe 146 via the model process 116 in the previously described manner. After this position is determined, the computer 114 moves to state 450 and records in memory the position of the programmed vehicle, as given by the model process 116 in state 446 and the time on the scenario clock at which the vehicle is at this position. The manner in which this data is recorded and stored in the memory of the computer 114 is described in greater detail below with reference to Figure 23.

The computer 114 then generates output signals to the developer in state 454. These output signals include sounds representative of driving communicated via the speakers 12 and 124 as well as road feel cues transmitted via the speake 136 and vehicle control feedback feelings sent via th steering wheel 112 and the brake pedal 106 (Figure 1) . Th computer 114 also updates the video display 122 to display th background of the simulated universe 146 based on the lates position of the programmed vehicle, as given by the mode process 116 in state 446.

The computer 114 then moves to state 458 and updates th position of the other programmed vehicles in the scenario t their positions and the state stop lights 15 at the curren time on the scenario clock. Subsequently, the computer 11 determines, in decision state 460, whether the developer ha manipulated the enter rocker switch 182 (Figure 3) to thereb instruct the computer 114 to stop recording the path of th programmed vehicle.

If the computer 114 detects that the developer has no manipulated the enter rocker switch 182, the computer 11 returns to state 444 where it again reads the inputs provide by the developer. As can be appreciated, the computer 11 continues to loop through states 444-460 until the develope manipulates the enter rocker switch 182. Hence, the develope can program the programmed vehicle to appear in the simulate universe 146 and drive in a particular manner by simpl driving the vehicle through the simulated universe 146 in th same manner as a student drives the observer vehicle when th scenario is being run.

If the computer 114 detects that the developer ha manipulated the enter rocker switch 182, it then moves to return state 462 where it generates the program menu 42

(Figure 8) on the video display screen 122 and awaits th developer's next input. Hence, the developer, using th simulation system 100 of the present invention, can progra vehicles to appear by simply driving the vehicle through th simulated universe 146 in the manner the developer wishes th vehicles to perform. In this preferred embodiment of th present invention, the other programmed vehicles are als active and moving in the simulated universe 146 while t developer is driving the new vehicle being programme Consequently, the developer can drive the new programm vehicle in conjunction with the previously programmed vehicl to generate traffic conditions and events that the stude will have to deal with when the simulation is run.

Figure 12 is a flow diagram illustrating the operation the computer 114 as it performs the "do_place_start" functi 369 called by the scenario developer from the Set Start Position line 340c of the Program Menu 329 (Figure 8) . In start state 370, where the computer 114 displays the simulat universe 146 on the video display 122 as seen from a defau start position. The computer 114 then causes, in state 37 the video display 122 to display instructions to the scenar developer to drive, using the input devices 104-112, to t position in the simulated universe 146 that the develop wants the observer vehicle containing the student to be at t start of the simulation scenario.

The computer 114 then reads the inputs provided by t developer via the input devices 104 - 112 (Figure 1) in sta 372. The computer 114 then determines, in state 373, t position in the simulated universe 146 of the vehic currently being driven by the developer by sending signa indicative of the developer's inputs on the input devices 10 112 to the model process 116. The computer 114 then generat output signals to the developer in state 374 which inclu sounds representative of driving communicated via the speake 123 and 124 as well as road feel cues transmitted via t speaker 136 and vehicle control feedback feelings sent via t steering wheel 112 and the brake pedal 106. The computer 1 then moves to state 376 and causes the video display 122 update the display of the background in the simulated univer 146, based on the position of the vehicle being driven by t developer, as given by the model process 116 in state 373. After updating the background display of the simulat universe 146, the computer 114 checks, in decision state 38 to see if the scenario developer has manipulated the ent rocker switch 182 thereby indicating that he had selected t new starting position of the observer vehicle. If t computer 114 detects that the developer has not manipulat the enter rocker switch 182, then the computer 114 returns the state 372 where it reads the input signals from the inp devices again. The computer 114 continues the loop comprisi states 372 through 380 until the developer manipulates t enter rocker switch 182. The loop comprising the states 3 through 380 enables the scenario developer to drive t vehicle through the simulated universe 146 to the desir starting position in the same fashion that the student driv the observer vehicle.

Once the computer 114 detects- that the developer h manipulated the enter rocker switch 182 in decision state 3 indicating that the scenario developer has driven to t desired starting position in the simulated universe 146, t computer 114 then moves to state 302 and records in memory t new starting position for the observer vehicle for th particular scenario. After recording the new starti position, the computer 114 moves to a return state 384 fr which the computer 114 returns the developer to the progr menu 329 (Figure 8) . If the developer does not desire create a new starting position for the observer vehicle f this scenario, the computer 114 then starts the observ vehicle at a pre-selected default position in the simulat universe 146. In this fashion, the developer of the scenar can program the starting position for the student in" t observer vehicle when the scenario is running by simp selecting the Set Start Up Position line 340b on the Progr Menu 330 and then driving to the desired location in t simulated universe 146.

Figure 13 is a flow diagram illustrating the operation the computer 114 implementing the "run_timer" function 4 called by the developer selecting the Time Path line 34Oe the Program Menu 320 (Figure 8) . The "run_timer" function 4 permits the developer to time how long it takes to dri between locations within the simulated universe 146. Once t developer knows how long it takes to drive between tw specific locations, he can use this information in schedulin when additional programmed vehicles appear in the simulate universe 146 so as to produce traffic conditions and event which may necessitate action by the student.

Referring now to Figure 13, from a start state 470, th computer 114, in state 471, displays the simulated univers 146 to the developer via the video display 122 (Figure 1) an permits the developer to drive in the simulated universe 146 to the position where the developer wishes to begin timing.

The computer 114 then determines in decision state 472, whether the developer has pressed the select rocker switch 184

(Figure 3) indicating that he wishes .to begin timing. If the computer 114 determines that the developer has not pressed the select rocker switch 184 in decision state 472, the computer 114 returns to the state 471 where the developer continues to drive around the simulated universe 146. if the developer has pressed the select rocker switch 184 the computer 114 then initiates an internal stop watch timer in state 474. The internal stop watch timer records the amount of time, according to the scenario timer, between when the select switch 184 is pressed in the state 474 and when it is pressed again in state 478. After initiating the internal stop watch timer, the computer 114 proceeds to a driving sequence 476 where the computer 114 enables the developer to drive from one location to second location within the simulated universe 146 while incrementing and displaying, the. stop watch on the video display 122. The driving sequence 476 includes states similar to the states 371 to 376 in "do_place_start" function 369 shown in Figure 12. The computer 114 then determines in decision state 478 whether the developer has pressed the select rocker switch 184 indicating that he wishes to stop the stopwatch. If the developer has not pressed the select rocker switch 184, then the computer 114 returns to the driving sequence state 476. If the developer has pressed the select rocker switch 184, then the computer 114 stops the stop watch and the resulting time is then displayed to the developer on the video display 122. From state 480, the computer 1 enters a return state 482 which returns the developer to t Program Menu 329 (Figure 8) .

In this fashion, the developer can use the stop watch determine how long it will take to drive from one location another within the simulated universe 146. This informati can then be used by the developer to time programmed vehicl to appear at specific locations at specific times on t scenario clock. For example, if the developer wants to ha a second programmed vehicle collide with a first programm vehicle at an intersection, by knowing the time on t scenario clock when the first programmed vehicle will be the intersection, the developer can use the stop watch to ti how long it will take to reach the intersection driving 't second programmed vehicle from its starting position with the simulated universe 146. Then, when the second programm vehicle is added to the scenario, the developer can use th information to determine when, on the scenario clock, he mu start driving the second programmed vehicle towards t intersection to collide with the first programmed vehicle.

Note, the foregoing description has described how t developer can develop a scenario where different programm vehicles are programmed to drive along paths in the simulat universe 146. In this preferred embodiment, the developer c also place items, e.g., direction signs etc. in a simil fashion. Specifically, the developer, using the Add Vehicl line 340b, can also select the direction signs 151 (Figu 2B) , then enter a series of functions, similar to the abo described functions, whereby the developer drives to t location in the simulated universe 146 where he wishes t traffic sign 151 to appear and then manipulates the ent rocker switch 182 into the set position to signal to t computer 114 to record the present location as the locati for the direction signs. Hence, the developer can al develop a scenario where direction signs and other stationa objects can be located in the simulated universe 146 by simp driving through the simulated universe 146 to the desir

S

UBSTITUTE SHEET U location .

Figure 14 illustrates an exemplary Edit Menu 51 displayed by the computer 114 to the scenario developer on th video display 122 (Figure 1) when the developer has selecte the Edit Menu line 334c on the Developer Menu 320 (Figure 7) From this menu the developer can further develop th simulation scenario by adjusting various features of th programmed vehicles and then replaying segments of th recorded scenario. The Edit Menu 510 includes an identifyin header 512 and a Suspect/Phantom Path ID header 514 whic identifies which vehicle path has been designated the path o either the phantom vehicle or the rabbit vehicle 150.

The Edit Menu also includes a box 520 which has a Defin Suspect/Phantom Path line 520a, a Replay View line 520b, Reference Path ID line 520c, a Replay Path line 520d, a Pat Time line 520e, a Replay Start Time line 520f, a Vehicle Typ line 52Og and a Remove Path Data line 52Oh. The develope selects between these lines using the select and enter rocke switches 182 and 184 (Figure 3) in the previously describe manner. Note, in some preferred embodiments of the presen invention the Suspect/Phantom Path ID header 514 is a line i the Menu Box 520 and it is used to define which of th programmed vehicles is to be the suspect or phantom vehicle A person skilled in the art can appreciate that these menu can be modified in any of a number of different manners t facilitate use of the simulation system 100 of the presen invention..

The Define Suspect/Phantom Path line 520a allows th developer to designate which of the previously programme vehicles are to be designated either the rabbit vehicle 150 i.e., the suspect vehicle, or the phantom vehicle. A described previously, in a pursuit-type simulation, th developer can select one programmed vehicle to be the rabbi vehicle 150 that the student will pursue through the simulate universe 146. Consequently, the developer can drive programmed vehicle through the simulated universe 146 in th fashion that he wishes the rabbit vehicle 150 to perform whe the simulation is run for a student using the Add Vehicle li 340b of the Program Menu 329 (Figure 1) and then ^'designa this vehicle to be the rabbit vehicle using the Defi Suspect/Phantom path line 520a. In this preferred embodiment of the present inventio defining one vehicle to be the rabbit vehicle 150 causes t scenario clock to enter the rabbit adjust mode. In this mo the scenario clock adjustably increments depending upon h far the student driven observer vehicle is from the rabb vehicle 150. Preferably, the scenario clock is incremented that the rabbit vehicle 150 remains substantially a pr selected distance from the student driven observer vehicl If the student drives too far away from the rabbit vehicle 1 at which time the scenario clock stops incrementing and ea of the programmed vehicles including the rabbit vehicle free in the simulated universe 146.

Since the scenario clock is incremented in the rabb adjust mode so that a nearly constant distance is maintain between the student driven observer vehicle and the rabb vehicle 150, the developer knows the approximate position t student driven observer vehicle will be in at any time on t scenario clock when the scenario is run. Consequently, t developer can program other vehicles to drive in proximity the student driven observer vehicle in such a fashion that t student will be forced to respond accordingly.

Alternatively, the developer can also use the Defi Suspect/Phantom path line 520a to designate one of t previously programmed vehicles to be the phantom vehicle. T developer can drive a programmed vehicle through the simulat universe 146 along an optimum path for the student and th designate this vehicle to be the phantom vehicle using t Define Suspect/Phantom path line 520a. In this preferr embodiment of the present invention, once the develop designates one of the programmed vehicles to be the phant vehicle, the scenario clock is then programmed to increme according to the Phantom Adjust mode described previously reference to Figure 5. In this mode the scenario clock incremented so that, when the scenario is running for student, the relative distance between the programmed vehicl and the observer vehicle driven by the student substantially the same as the relative distance between t programmed vehicles and the phantom vehicle.

Hence, the developer can develop a scenario by initial driving a first programmed vehicle through the simulat universe 146 along the path that the developer wishes t student to take when the simulation is run. The develop then drives additional programmed vehicles in the simulat universe 146 on the basis that the first programmed vehic represents the path of the student driving the observ vehicle. The developer can easily develop traffic situatio which require appropriate responses by the student since t first programmed vehicle is in substantially the same positi the student will be in when he is driving through t scenario. For example, if the developer desires to force t student to avoid a vehicle swerving directly at the observ vehicle, the developer simply has to use the Add Vehicle li 340b of the Program Menu 329 and drive a programmed vehicl directly at the first programmed vehicle. The developer th has to designate the first programmed vehicle the phant vehicle using the Define Phantom/Suspect Path line 520a on t Edit Menu 512. Once the developer has selected the Defi

Suspect/Phantom Path line 520a, the computer 114 preferabl enters a routine whereby the developer can initially selec between defining a rabbit vehicle 150 or a phantom vehicl using the enter and select rocker switches 182 and 184 (Figu 3) . Subsequently, the computer 114 permits the developer t define the path by entering the three digit Path ID numbe assigned to the desired programmed vehicle using the selec and enter rocker switches 182 and 184 in the previousl described manner. Subsequently, the computer 114 records i memory the vehicle attributes for the programmed vehicl corresponding to the designated Path ID number that it i either the rabbit or phantom vehicle.

SUBSTIT - The Replay View line 520b allows the developer to sele the view that he will have when replaying the previous programmed scenario. In this preferred embodiment, t developer can either select an overhead view, where t previously programmed scenario is replayed on the vid display 122 from an overhead point of view or a driver's e view where the scenario is replayed from the point of view student driving in the simulated universe 146.

The Reference Path ID line 520c enables the developer select which of the programmed vehicles is to be edited usi the features of the Edit Menu 512. The developer selects t particular programmed vehicle by simply entering the thr digit Path ID number corresponding -to the selected vehicl using the select and enter rocker switches 182 and 184 in t previously described manner.

The developer can replay the previously programme scenario by selecting the Replay Path line 520d. The compute 114 then replays the previously programmed scenario on t video display from either the overhead or the student's ey point of view. The replay begins at the start time designate by the developer via the Replay Start Time line 520f. Thi process is described in greater detail in reference to Figur 15 below.

The Path Time line 52Oe allows the developer to chang the time that the programmed vehicle identified by th Reference Path ID line 520e is active in the simulate universe 146. As described previously, each programme vehicle is programmed by the developer to appear in th simulated universe 146 at a specific time, drive a particula path and then be removed at a specific time on the scenari clock. The developer, using the Path Time line 52Oe, ca adjust when the referenced programmed vehicle appears in th simulated universe 146. In the preferred embodiment, th developer determines the new time on the scenario clock tha he wishes the referenced programmed vehicle to appear in th simulated universe 146 and the computer 114 then adjust th path data for the referenced programmed vehicle so that i appears in the simulated universe 146 at the new time and i programmed to be positioned along its path and removed fro the simulated universe 146 at a correspondingly different tim on the scenario clock. Hence, if the developer determine that the programmed vehicle is appearing at an intersectio too early, he can use the Path Time line 520e to make th referenced programmed vehicle appear in the simulated univers 146 and perform its operation at a later time.

As described above, the Replay Start Time line 52O allows the developer to select the time on the scenario cloc that he wishes to begin replaying the path of the referenc vehicle via the Replay Path line 520a. Further, the Vehicl Type line 520d allows the developer to change the type o vehicle selected for the reference programmed vehicle. A described above in reference to Figure 8, the programme vehicle can be defined, in this preferred embodiment, to b one of several different types of vehicles including a sedan one of several types of sports cars and one of several type of trucks. Once the developer has changed the vehicle type the computer 114 then changes the vehicle attributes for th referenced programmed vehicle that are stored in the memor

(See, Figure 23) . After viewing a previously programme scenario, the developer may wish to change the previousl programmed vehicle type for a particular programmed vehicle t create a different visual image for the scenario. The Vehicl Type line 52Og allows the developer to change the vehicle typ and the developer can subsequently replay the -scenario wit the new vehicle type using the Replay Path line 52Od.

Finally, the Remove Path Data line 520e allows th developer to remove the path data of the reference programme vehicle identified in the header 519 if the developer decide to remove the referenced programmed vehicle. Subsequently the developer can then replace the referenced programme vehicle by returning to the Add Vehicle line 340b on th Program Menu 329 (Figure 8) .

Figure 15 is a flow diagram illustrating the operation o the computer 114 as it implements a Replay Path function 52 called by the developer selecting Replay Path line 520e of t Edit Menu 510 (Figure 14). From a start state 530, t computer 114 initially determines in decision state 5 whether the developer has selected to replay the scenario fr the overhead point of view. If the developer has selected overhead view via Replay View line 520b of the Edit Menu 51 the computer 114 initializes a camera angle variab (editview) in state 536 so that the computer 114 replays t scenario from an overhead point of view. The computer 1 then performs a "replay_segment" function 540 where t computer 114 recalls the paths of the programmed vehicles the scenario from memory and replays the scenario on the vid display 122 from the overhead point of view. This scenario replayed from the start time designated by the developer v the Replay Start Time line 520f of the Edit Menu 510. As c be appreciated, the computer 114 can also be programmed afford the developer different options for the overhead vi so that the developer can view the scenario from differi heights above the ground. In this preferred embodiment, t computer 114 replays the scenario from the overhead point view on the display screen in the replay_segment function 54 such that the display is centered on either the designat rabbit vehicle 150, the designated phantom vehicle or, if rabbit vehicle or phantom vehicle has been designated, t referenced programmed vehicle identified on the Reference Pa ID line 520c of the Edit Menu 510. The computer 114 procee from the "replay_segment" function 540 to a return state 5 where it returns the developer to the Edit Menu 510.

If, however, the computer 114 determines in decisi state 534 that the developer has selected the driver's e point of view on the Replay View line 520b on the Edit Me

510, the computer 114 then initializes the camera variab

(editview) indicating that a student's eye view has be selected in state 546. The computer 114 then performs function 550 entitled "to_replay_observe" . T "to_replay_observe" function 550 is substantially the same the "to_program_observe" function 410 (Figure 10 and Figu 11) in that it instructs and permits the developer to drive t a position in the simulated universe 146 where he wants t observe the scenario as it unfolds.

The computer 114 performs the "replay_segment" functio 540. Here, the computer 114 displays on the video screen 12 the programmed vehicles visible to the developer from hi position in the simulated universe 146, and from the driver' point of view as the vehicle travels in the simulated univers 146 (Figure 2) along the programmed path. The computer 11 also preferably permits the developer to follow the scenari through the simulated universe 146 by driving in the simulate universe 146 while the scenario is being replayed. At the en of the scenario the computer 114 moves to a return state 55 where it returns the developer to the Edit Menu 510. Hence the developer can replay the previously programmed scenari and then use the features of the Edit Menu 510 to mak alterations to the scenario which are then stored by th computer 114 in memory.

Figure 16 illustrates an exemplary Traffic Lights Men 570 displayed to the scenario developer when the scenari developer selects the Traffic Lights line 334d on th Developer Menu 320 (Figure 7) . The Traffic Lights Menu 57 enables the developer to program when, with reference to th scenario clock, the traffic lights 151 in the simulate universe 146 change. As previously discussed, in thi preferred embodiment, a plurality of stop lights 151 (Figur 2B) are positioned in the simulated universe 146. and. each o these stoplights change states simultaneously, i.e., ever light in the simulated universe 146 changes states at the sam time on the scenario clock.

Referring now specifically to Figure 16, the Traffi Light Menu 570 includes an identifying header 5726 and selection box 582 which includes Replay/Program Traffic Light line 582a, a Light State line 582b, a Traffic Light State line 582c, a Light Change Time line 582d, a Scenario Star Time line 582e, a Replay View line 582f, a Delete Traffi Lights line 582g, a Green Light Default Time 582h and a Yello Light Default Time 582i. The developer moves and selec between the lines 582a - 582i using the enter and sele rocker switches 182 and 184 (Figure 3) in the mann previously described. In this embodiment, the developer can program each of t lights to change states at specific times on the scenar clock via the Replay/Program Traffic Lights line 582a on t Traffic Light Menu 570. For example, the developer c program the lights so that at a specific time on the scenar clock, the lights facing east-west change from green to yell to red and the lights facing north-south change from red green. Further, the developer can also use the Traffic Ligh Menu 570 to review previously programmed traffic ligh schedules. Preferably, the computer 114 is programmed to display t words REPLAY TRAFFIC LIGHTS on the Replay/Program Traff Lights line 582a when the traffic lights 151 have be previously programmed by the developer for this scenari Consequently, if the developer wishes to review the previous programmed traffic lights 153, he can simply select this li and the computer 114 then generates the replay on the vid display 122. The developer can also select the time on t scenario clock that he wishes the replay to begin using t Scenario Start Time line 582e. This option also allows him select the view that he has of the lights when the scenario replayed using the Replay View line 582f. Specifically, t developer can either, see the lights from the point of view the student or a driver driving through the simulated univer 146, or from the overhead point of view looking down on eith the rabbit or phantom vehicle as they travel through t simulated universe 146 along their pre-programmed paths. Replay Lights function 630 performed by the computer 114 wh the Replay/Program Traffic Lights line 582a is selected, a the traffic lights 153 have been previously programmed change states at selected times on the scenario clock, described in greater detail in reference to Figure 18 belo

Preferably, when the developer is adding programm vehicles via the Add Vehicle line 340a of the Program Menu 32 (Figure 8) , the computer 114 displays each of the visibl stoplights 153 to the developer on the video display 122 whil the developer is driving in the simulated universe 146. Th computer 114 also simultaneously implements any programme traffic light change schedule or the default traffic ligh change schedule. The developer can, however, change th default times for the lights by selecting the Green Ligh Default Time line 582h or the Yellow Light Default Time lin 582i. Specifically, the Green Light Default Time is the tim on the scenario clock that one set of opposite faces, e.g. the east-west faces, on each of the stop lights 153 in th simulated universe 146 displays a green light. Similarly, Th Yellow Light Default Time is the time on the scenario cloc that one set of opposite faces on each of the stop lights 15 displays a yellow light. The length that one set of faces e.g., the north-south face, displays a^x red light is, o course, the sum of the Green Light Default time and the Yello Light Default time. Hence, the developer, by changing th Green Light Default Time and the Yellow Light Default time ca also change the Red Light Default time. Preferably, when th developer is adding programmed vehicles via the Add Vehicl line 340a of the Program Menu 329 (Figure 8) , the computer 11 displays each of the visible stoplights 153 to the develope on the video display 122 while the developer is driving in th simulated universe 146. The computer 114 then also implement any programmed traffic lights schedule or the default traffi lights schedule.

As previously discussed, the computer 114 is preferabl programmed to display the words REPLAY TRAFFIC LIGHTS on th Replay/Program Traffic Lights line 582a when the developer ha previously programmed a schedule for the traffic lights 153 Similarly, the computer 114 is also programmed to display th words PROGRAM TRAFFIC LIGHTS on the line 582a when th developer has not previously programmed a schedule for th traffic lights 153. If there is no previously programme traffic light schedule for the scenario under development, th developer can program a schedule by selecting t Replay/Program Traffic Lights line 582a. Once this line selected, the computer 114 performs a function whereby t developer can develop a schedule for changing the traff lights 153 at different times by either driving through t scenario or by looking down from an overhead view at t simulated universe 146 and the programmed vehicles contain therein. The computer 114 performs a "Do_Program_Lite function 590, which allows the developer to develop t traffic lights change schedule for a scenario is more ful described in reference to Figure 17 below.

If, however, the developer has already programmed t traffic lights to change according to. a specific schedule, a the developer wishes to change this schedule, the develop can delete the existing schedule using the Delete Traff Lights line 582g and thereby cause the computer 114 to era the previously programmed schedule. Subsequently, t developer can then select the Replay/Traffic Light line 582 which then displays the prompt PROGRAM TRAFFIC LIGHTS, causi the computer 114 to enter the Program Traffic Lights functi 590 (Figure 17) and the developer can then program a n schedule.

Finally, the developer can also review the traffic ligh change schedule by selecting the Traffic Light State # li 532c. Specifically, each time the developer changes the stat of the traffic lights 153 when programming the traffic light using the "Do_Program_Lites" function.590, the state of t traffic lights is sequentially assigned a three digi identification number. The developer can then recall thi number on the Traffic Light State # line 532c, and t computer 114 displays the programmed state of the traffi lights on the Light State line 582b and the time at which t traffic lights entered this state on the Light Change Ti line 582d. Hence, the developer can program, replay and ed schedule for changing the traffic lights using the Traff Light Menu 570. The programming of a new traffic ligh change schedule and replaying of a previously programm traffic lights change schedule will now be described reference to Figures 17 and 18.

Figure 17 is a flow chart illustrating the operation the computer 114 as it performs the "Do_Program_Lite function 590 called by the developer selecting the line 58 of the Traffic Lights Menu 570. From a start state 592, t computer 114, in state 594, retrieves all of path da describing the paths of the programmed vehicles through t simulated universe 146 beginning from the start time on t scenario clock which the developer specified via the Scenar Start Time line 582e of the Traffic Light Menu 570.

The computer 114 then determines in decision state 5 whether the developer'has selected to program the new traff lights, schedule from the viewpoint of a driver driving throu the simulated universe 146 or from an overhead viewpoi looking down on the simulated universe 146. The develop selects the desired viewpoint using the Replay View line 58 of the Traffic Lights Menu 570. If the developer has select the driver's eye view option on the Replay View line 582f, t computer 114 enters a loop whereby the developer programs t traffic lights 153 by driving through the simulated univer 146 as the scenario is running. Figures 2 and 2A show exemplary view of a portion of a programmed scenario underw in the simulated universe 146 as seen from the driver's e viewpoint.

However, if the developer has selected the overhead vi option, the developer programs the traffic lights, 153 looking down at either the rabbit vehicle 150 or the phant vehicle as either of these vehicles travel through t simulated universe 146. The developer selects between t overhead view and the driver's eye view via the Replay Vi line 582f of the Traffic Light Menu 570 (Figure 16) . T overhead view option essentially uses the rabbit or phant vehicle as a reference vehicle and it also displays all of t other programmed vehicles scheduled to appear in the simulat universe 146. Figure 22 shows an exemplary view of a porti of a programmed scenario underway in the simulated univer 146 as seen from the overhead viewpoint.

Assuming that in state 596 the computer 114 determine that the developer selected to program the traffic lights 15 from the driver's eye viewpoint, the computer 114 moves t state 598 and initiates the programmed scenario from the poin of time on the scenario clock specified by the developer vi the Scenario Start Time line 582e (Figure 16) . The compute 114 then initiates a driving loop in state 600 which i similar to the loop comprised of states 226 - 248 shown i Figure 4 whereby the developer can drive a vehicle using th player input controls 104 - 112 (Figures 1 and 3) in th simulated universe 146. In this situation, the computer 11 continuously provides feedback to the developer via the vide display 122 i.e., updating the background display and th position of the active programmed vehicles, the speakers 12 and 124 and the low frequency speaker 136.

After each performance of the driving loop 600, th computer 114 moves to state 604 and determines whether th developer has manipulated the enter rocker switch 182 (Figur 3) . The developer manipulates the enter rocker switch 182 t stop the scenario clock and thereby freeze the scenario. I the computer 114 determines that the developer has no manipulated the enter rocker switch 182, the computer 11 continues to perform the driving loop 600 where the scenari is updated based on the recalled programmed data. Th position of the developer driven observer vehicle in th simulated universe 146 is also updated based input signal provided by the developer from the input devices 104 - 112 Once the computer 114 determines that the developer ha manipulates the enter rocker switch 182, the computer 11 moves to state 606 and freezes the scenario by stopping th scenario clock.

The computer 114 then initiates a frozen driving functio 608 similar to the "to_program_observe" function 416 (Figure 9 and 10) whereby the developer can drive through th simulated universe 146 while the stoplights 153 and th programmed vehicles remain in their frozen state. This allow the developer to drive to a particular stoplight 153 an observe the positions of the currently active programme vehicles with respect to this particular stoplight 153 at o about the time the developer wants the light to change state. The computer 114 then determines in decision state 61 whether the developer has manipulated the enter rocker switc 182 into the set position 183 (Figure 3) . Once the develope manipulates the enter rocker switch 184 into the set positio 183, the computer 114 changes the state of the stoplights 15 in state 611. As described above, the stoplights 153 displa either red, yellow or green lights on either the east-west o the north-south faces. The computer 114 can be programmed t sequentially change the state of the stoplights 153 from stat to state in response to the developer manipulating the ente rocker switch 184. Once the stoplights 153 are in the desire state, the developer manipulates the enter rocker switch 184 tor ecord the new light state and the current time on th scenario clock in memory and to restart the scenario in state 613 and 620 respectively. In one implementation of th present invention, the computer 114 records the new traffi light state in memory each time the developer manipulates th enter rocker switch 182 into the set position 183 and the awaits the developer manipulating the enter rocker switch 18 again before starting the scenario clock. A person skilled i the art however can appreciate that these implementations ar essentially equivalent.

Upon determining that the developer has manipulated the enter rocker switch 182 into the set position in decisio state 612, the computer 114 proceeds to state 613 where it records in memory the state of the stoplights 153 and th current time on the frozen scenario clock as the next scheduled change for the stoplights 153. Thus, the develope can program the stoplights 153 to change by driving throug the simulated universe 146 while the scenario is being run, manipulate the enter rocker switch 182 to freeze the scenario, change the state of the traffic lights 153 by manipulating th enter rocker switch 182 into the set position 183 and recor the desired state of the traffic light 153 by aga manipulating the enter rocker switch 182. Alternatively, t simulation system 100 of the present invention also permi the developer to change the light states without freezing t display by simply replaying the scenario, driving through and manipulaing the enter rocker switch 182 into the s position 183 each time the developer desires to change t traffic light states.

Similarly, if the computer 114 determines in decisi state 596 that the developer has selected the overhead vi via the Replay View Line 582f on the Traffic Light Menu 5

(Figure 16) , the computer 114 begins to replay the scenario state 614 beginning at the time .on the scenario clo specified by the developer via the Scenario Start Time li 582e. Preferably, if the developer has designated one of t programmed vehicles to be a rabbit vehicle 150 in a pursu simulation scenario, the computer 114 ^{^}centers the rabb vehicle 150 in the center of the video display 122 and th displays this rabbit vehicle 150 travelling through t simulated universe 146 along its preprogrammed path. Furthe as other programmed vehicles travelling on their respecti preprogrammed paths come within the area of the simulat universe 146 shown on the video display 122, the computer 1 also displays these vehicles travelling on their respecti preprogrammed paths through this portion of the simulat universe 146. Similarly, if the simulation is a driver's te scenario, and the developer has designated a phantom vehicl the computer 114 displays on the video display 122 t simulated universe 146 from the overhead view, in the sa fashion as described above, with the display centered on t phantom vehicle.

The computer 114 continues to replay the scenario in th fashion until the computer 114 detects that the developer h manipulated the enter rocker switch 182 in decision state 61 The developer manipulates the enter rocker switch 182 when t developer wishes to change the current state of the traff lights 153, to thereby cause the computer 114 in state 616 stop incrementing the scenario clock and freeze the motion o the programmed vehicles, including the phantom vehicle. Th traffic lights 153 are also frozen in their current states Preferably, the computer 114 is programmed to display th traffic lights 153 from the overhead view in a fashion suc that the developer can determine the state of the traffi lights 153, i.e., whether green, red or yellow lights ar showing on the east-west and north-south faces of the lights In this preferred embodiment, the traffic lights 153 in th overhead view are represented by squares positioned i intersections having four colored panels 155 which indicat the color of the corresponding face of the traffic light as i more clearly shown in Figure 22.

The developer can then change the current state of th traffic lights 153 by manipulating the enter rocker switch 18 into the set position 183 (Figure 3) which results in th state of the traffic lights 153 changing between red, gree and yellow of the east-west and north-south faces of th traffic lights 153 in the previously described fashion Specifically, the computer 114 determines in decision stat

617 whether the developer has manipulated the enter rocke switch 182 into the set position 183 and, once the develope has manipulated this switch, the computer 114 moves to stat

618 and changes the state of the traffic light 153 presentl displayed to the developer.

The computer 114 then determines in decision state 61 whether the developer has manipulated the enter rocker switc 182 to thereby indicate that he has selected the new state o the traffic lights 153. The computer 114 preferably continue to loop through states 614 to 619 until the developer ha manipulated the enter rocker switch 182 Once the computer 11 determines that the developer has selected the new state o the traffic light 153 in decision state 619, the computer 11 then moves to state 613 and records the new light state an the time, according to the scenario clock, that the traffi lights 153 are to scheduled to enter the new light state. Th time on the scenario clock that is recorded in state 613 i the current time on the scenario clock that was stopped i state 616.

Once the computer 114 has recorded the new traffic lig state and the time on the scenario clock that it is schedule to occur, the computer 114 then proceeds to state 620 where i restarts the scenario clock and the movement of the programme vehicles through the simulated universe 146 in state 620. previously described in another preferred implementation o the present invention, the computer 114 records the ne traffic light state in memory each time the develope manipulates the enter rocker siwtch 182 into the set psoitio 183 and then awaits the developer manipulating the ente rocker siwtch 182 again before starting the scenario clock Alternatively, the simulation system 100 also permits th developer to program traffic lights from the overhead point o view without freezing the display by simply replaying th scenario and manipulating the enter rocker siwtch 182 into th set position 183 each time the developer wishes the traffi lights to change states. After restarting the scenario clock in state 620 th computer 114 then determines in decision state 622 whether th end of the scenario being replayed has occurred. If th computer 114 is not at the end of the scenario, the compute 114 proceeds to determine whether the developer had selecte the overhead view or the driver's eye view to program the ne traffic lights schedule which the computer 114 previousl determined in decision state 596.

If the developer had selected the overhead view, th computer 114 returns to state 614 where the programme scenario is updated. Similarly, if the developer had selecte the driver's eye view, the computer 114 returns to state 60 where the computer 114 continues the driving loop permittin the developer to drive to the next desired stop light 153 i the simulated universe 146. Hence, the computer 114 permits the developer to progra a new schedule for the traffic lights by either allowing th developer to drive through the simulated universe 146 as th programmed scenario is running, or by allowing the develop to see an overhead view of the scenario as it is running. T developer can then schedule the traffic lights 153 to chan states at times on the scenario clock when a student drivi an observer vehicle in the simulated universe 146 duri operation of the scenario will be at or approaching intersection. Further, since the developer programs the n traffic lights schedule while the programmed scenario is bei displayed, the developer can also program the lights such th the previously programmed vehicles run red stop lights and t like. For example, the developer can schedule the traff lights so that they are green for the student driving observer vehicle and the developer can also program programmed vehicle to drive through the intersection, runni a red light, at the same time as the student either approach or is in the same intersection with the right of way.

Figure 18 is a flow chart illustrating the operation the computer 114 as it performs the Replay Traffic Ligh function 630 called by the developer selecting the line 58 of the Traffic Lights Menu 570 when a traffic lights chan schedule has been previously programmed by the scenar developer. From a start state 632, the computer 114 procee to retrieve from memory the previously programmed scenari including the programmed vehicle path data, the traffic ligh schedule, and the physical features of the simulated univer 146 in state 634 from the start time designated by t developer on the Scenario Start Time line 582e of the Traff Light Menu 570.

The computer 114 then enters state 636 and determin whether the developer has selected to view the replay of t previously traffic lights change schedule from either t overhead viewpoint or the driver's eye viewpoint, as select by the developer on the Replay View line 582f of the Traffi Light Menu 572. If the developer has selected to replay t traffic lights change schedule from the driver's e viewpoint, the computer 114 moves to state 630 and initiat the replaying of the scenario from the start time given by t developer on the line 582e of the Traffic Lights Menu 570 Subsequently, the computer 114 enters a driving loop in stat 640, substantially similar to the loop comprised of states 22 - 248 shown in Figure 4, wherein the developer can drive, i the simulated universe 146 with the computer 114 replaying th previously developed portion of the scenario in the sam fashion it replays the scenario for a student.

While in the driving loop 640, the developer ca manipulate the enter rocker switch 182 (Figure 3) to freez the scenario being displayed. Specifically, once the compute 114 determines that the developer has manipulated the ente rocker switch 182 in decision state 642, the computer 11 proceeds to state 644 and stops the.scenario clock, thereb freezing the display, such that the programmed vehicles ar not moving and the stop lights 153 do not change Subsequently, the computer 114 enters a function 645 simila to the "to_jprogram_observe" function 416 (Figures 9 and 10 whereby the developer can drive through the simulated univers 146 even while the programmed vehicles and stop lights 153 ar frozen. The developer can stop the scenario and drive to different vantage point to view the programmed scenario and once the developer is at this vantage point, the developer ca manipulate the enter rocker switch 182 to restart th scenario. Hence, the computer 114 determines if the develope has restarted the scenario in decision state 646. If th developer hasn't restarted the scenario, the computer 11 returns to the function 645 permitting the developer t continue to drive through the simulated universe 146 with th programmed vehicles and the stop lights 153 frozen. If the developer has manipulated the enter rocker switc

182 in state 646, the computer 114 then restarts the scenari clock in state 648 and continues with the scenario. Th computer 114 then determines whether it has replayed th entire programmed scenario in decision state 650. If th entire scenario has been replayed, the computer^*114 then move to a return state 652 in which the computer 114 returns th developer to the Traffic Lights Menu 570 (Figure 16) . If th entire scenario has not been replayed, the computer 11 returns to the driving loop 640. In this fashion, th computer 114 loops through the states 640 - 652 until th scenario has been completely replayed, while allowing th developer to selectively stop the replay and drive t particular vantage points in the simulated universe 146.

If the computer 114 determines in decision state 636 tha the developer has selected to replay the scenario from th overhead viewpoint by selecting the overhead option on th Replay View line 582f of the Traffic Lights Menu 570 (Figur 16) , the computer 114 then moves to state 852 and initiate replaying the preprogrammed scenario from the start tim indicated by the developer on the Scenario Start Time lin 582e of the Traffic Lights menu 570. As described previously the overhead option preferably displays the simulated univers 146 from an overhead perspective (see Figure 22) , with th display centered about either the rabbit vehicle 150 or th phantom vehicle.

While the scenario is replaying, the computer 11 periodically determines whether the developer has manipulate the enter rocker switch 182 to freeze the replay. If th computer 114 determines in decision state 654 that th developer has manipulated the enter rocker switch 182, th computer 114 then stops incrementing the scenario clock. Thi results in the programmed vehicles and the stoplights 15 being displayed on the video display 122 (Figure 1) freezin into their respective positions and states at the tim indicated by the scenario clock when it was stopped. Th scenario remains frozen until the computer 114 determines tha the developer has manipulated the enter rocker switch 182 i decision state 658, at which time the computer 114 resume incrementing the scenario clock and thereby updates th positions of the programmed vehicles and the state of the sto lights 153. The computer 114 continues to replay the 'scenario unti it determines in decision state 662 that it has reached th programmed end of the scenario. The computer 114 the proceeds to the return state 652 which returns the develope to the Traffic Lights Menu 570.

Note, in this preferred embodiment when the developer ha selected the driver's eye view and is developing a traffi light schedule by driving the observer vehicle through th simulated universe 146, and also when the developer ha selected the overhead view and is developing a traffic ligh schedule in that fashion, the traffic lights 153 are changin states according to the default times selected by th developer on the Green Light Default Time line 582h and th Yellow Light Default Time line 582i of the Traffic Light Men 570 (Figure 16) . From the driver's eye view, the traffi lights 153 appear as they do in Figure 2B with the light whe they are shown the student driving the simulation scenario In this preferred embodiment, the computer 114 displays th traffic lights with colors on each of the set of opposit faces i.e., the east-west face and the north-south face indicating the current state of the traffic light 153, as i more clearly shown in Figure 22. Hence, using the simulation system 100 of the presen invention, the developer can develop scenarios for students i a simulated universe containing traffic lights. Further, th developer can also easily schedule the traffic lights t change at times when the student driving an observer vehicl in the scenario will be approaching a traffic light. Thi allows the developer to develop scenarios where, for example the student will have to suddenly brake for a traffic ligh and the like.

Figure 19 illustrates an exemplary Replay Window Menu 67 that the developer sees on the video display 122 upo selecting the Replay Windows line 334e on the Developer Men 320. The Replay Window Menu 670 includes a Replay Window Men header 672 identifying the menu and a selection box 67 containing a Window # line 674a, a Start Time line 674b, a End Time line 674c, a Replay Selected Window line 674d, Replay All Windows line 674e, a Delete All Windows line 674 and a Training View line 674g. The developer selects betwee these lines using the enter rocker switch 182 and the selec rocker switch 184 in the previously described manner.

By selecting the Replay Window Menu 670, the develope can pre-program the driving simulation system 100 to record selected portion of the student's path through the simulate universe 146. Specifically, the developer can select portion of time on the scenario clock, i.e., windows of time, whereb the computer 114 records the path of the student driving th observer vehicle while the developed scenario is being run fo a student, along with the path of the programmed vehicles i the simulated universe 146 for that period of time on th scenario clock. Subsequently, after the student finishes th scenario, the computer 114 then preferably replays the window to the student on the video display 122 to permit the studen to see how he performed in the driving simulation Consequently, the developer can, for example, develop scenario and create a traffic condition that requires specific response by the student, and then program th computer 114 to replay the portion of the scenario, as it wa driven by the student, wherein the traffic condition occurre once the student has completed the entire simulation. Hence, the student can be given feedback on his driving performanc during specific times when particular events occurred withou having to see the entire scenario. Referring specifically to Figure 19, the Start Time Lin

674b and the End Time line 674c indicate the time on th scenario clock that the window, identified by the Window line 674a, begins and ends. The developer programs a windo by simply assigning the window an identification number o line 674a and then programming the start time and the end tim on the scenario clock for the window using the lines 674b an 674c respectively. In this preferred embodiment, th developer assigns a window an identification number by simpl entering the start and end times for the window via the line 674b and 674c. The computer 114 then automatically assign the window the next available identification number which i shown on the line 674a. The developer enters the start an end times using the select and enter rocker switches 182 a 184 (Figure 3) in the manner previously described in referen to Figure 7.

The developer can also replay a selected window identifying the window on the line 674a using the rock switches 182 and 184 and then selecting the Replay Select Window line 674d. Further, the developer can replay all the windows using the Replay All Windows line 674e. When t developer is replaying either a selected window or all of t windows, the computer 114 preferably displays on the vide screen 122 (Figure 1) the paths of the programmed vehicl through simulated universe 146 during the time period on t scenario clock specified for this window from an overhe point of view. This allows the developer to determine whethe the replay window will replay the student's path during specific programmed traffic event.

The developer can also delete each of the previousl programmed windows using the Delete All Windows line 674f After deleting all of the existing windows, the developer ca then program a new set of windows if he so desires. Further the developer can also select between Driver's Eye view an Driver's Overhead view for the view that the student will ha for each window is replayed via the Training View line 674g When the developer has selected the overhead view, t computer 114 replays the recorded window of the scenario as i was driven by the student, showing the positions of th vehicles as seen from an overhead position where the positio of the vehicle driven by the student is centered in the vide display 122. Similarly, when the developer has selected th Student's Eye view for a particular window, the computer 114 when it replays the recorded window, replays it on the vide display 122 from the point of view of the student driving th vehicle. As can be appreciated, replaying the scenario fro this point of view allows the student to review exactly how responded to certain driving conditions as he actuall perceived them when driving in the scenario.

Figure 20 illustrates an exemplary Traffic Control men 700 that appears on the video display 122 when the develope selects the Traffic Control line 334f on the Developer Men 320 (Figure 7) . The Traffic Control menu 700 allows th developer to change the parameters governing the incrementin of the scenario clock and the consequent updating of th positions of the programmed vehicles in the simulated univers 146 when the scenario is being run for a student. The Traffi Control Menu 700 includes an identifying header 702 and a bo 704 containing a Replay Traffic Control line 704a, a Traffi Control Entry # line 704b, a Traffic Control Time line 704c, a Traffic Control Distance line 704d, a Scenario Start Tim line 704e, a Replay View line 704f and a Delete Contro Entries line 704g. The developer selects between the line 704a - 704g using the select and enter rocker switches 182, 184.

As discussed above, in this preferred embodiment, th programmed vehicles are programmed to be a specific positio along a path in the simulated universe 146 at specific time on the scenario clock. Further, when the scenario is running, the scenario clock can be either fixedly updated or variabl updated. The scenario clock can be set to variably incremen depending upon the distance between the student driving th observer vehicle and a rabbit vehicle 150, or set to variabl increment depending upon the distance between the studen driving the observer vehicle and a pre-programmed phanto vehicle as described previously in reference to Figures 5 an 6.

For example, when the computer 114 is programmed to ru a scenario with the scenario clock in the phantom adjustin mode, the computer 114 increments the scenario clock so that, when the positions of the programmed vehicles are updated, th positions of programmed vehicles relative the student drive observer vehicle is substantially the same as the positions o the programmed vehicles relative to the phantom vehicle whe the phantom vehicle was driven by the developer whe developing the scenario. This allows the developer to develo a scenario which requires the driver to take evasive action t avoid collisions with the programmed vehicles by driving th phantom vehicle such that the phantom vehicle is in a positio where it would be necessary to take evasive action to avoi colliding with the programmed vehicles. Hence, no matter ho fast or slow the student drives the observer vehicle, th computer 114 in the phantom adjust mode updates the scenari clock so that the programmed vehicles are in the same relativ position to the observer vehicle as they were relative th phantom vehicle when the simulation was programmed. The functions called by the developer using the Traffi

Control Menu 700 enable the developer to modify the phanto adjusting of the scenario clock so that, at particula intervals during the scenario, the computer 114 updates th scenario clock at the fixed default rate when the studen driven observer vehicle is within a fixed radius of th position of the phantom vehicle. Without this function, th computer 114 only updates the scenario clock at the fixe default rate when the student is in substantially the exac same position in the simulated universe 146 as the phanto vehicle.

This permits the developer to develop a scenario wher the student will be placed in situations where some type o traffic maneuver is required to avoid colliding with th programmed vehicles, however, the student will not be require to make the same traffic maneuver as the developer did in th phantom vehicle when developing the scenario. For example the developer can develop a scenario wherein the student wil have to merge into a stream of traffic while avoidin collisions with the programmed vehicles comprising the strin of traffic. By increasing the radius or traffic contro distance, the developer can program the computer 114 t continue to increment the scenario clock at the default fixe rate, and update the positions of the programmed vehicle comprising the string of traffic accordingly, when the studen has not merged into traffic at the same position as th developer driving the phantom vehicle. This allows th student to merge into the string of traffic at a positio different than the developer driving the phantom vehicle.

Referring now specifically to Figure 20, the develop can replay the scenario under development by selecting t Replay Traffic Control line 704a. This also allows t developer to replay the scenario under development and, this preferred embodiment, the computer 114 causes the vid display 122 to also display the radius, i.e., the traff control distance, that has been set for this particul interval. The developer can also replay the scenario from time on the scenario clock other than the actual beginning the scenario by entering the desired start time on t Scenario Start Time line 704e using the enter and sele rocker switches 182 and 184 in the previously describe manner. Further, the developer can also select between a overhead replay view and a driver's eye replay view when t scenario is being replayed by selecting the Replay View li 704f and selecting between the Driver's eye view or t Overhead view. If the developer selects the Driver's e view, then, when the scenario is replayed, the computer 11 performs a loop substantially the same as the loop comprisin states 226 through 248 described in reference to Figure above, thereby permitting the developer to drive through t simulated universe 146 in substantially the same fashion as student would when the scenario was being run for trainin purposes.

The developer selects the traffic control distance fo a.particular time interval by first- inputting the time on th scenario clock that the new traffic control distance is t take place via the Traffic Control Time line 704c an manipulating the select and enter rocker switches 182 and 18 in the previously described manner. The developer the selects the Traffic Control Distance line 704d and enters radius value using the enter and select rocker switches 18 and 184 which, in this preferred embodiment, represents th maximum distance measured in feet between the phantom vehicl and the student-driven observer vehicle that the computer 11 will still increment the scenario clock at its default fixe rate .

Each time the developer enters a new traffic contro distance and time on the scenario clock that it is to occu the new traffic control distance is assigned an identifyi number which is displayed on the Traffic Control Entry Numbe line 704b. The computer 114 preferably sequentially store the traffic control information according to the time on th scenario clock they are programmed to occur. Hence, th developer can edit either the time or the traffic contro distance for any of the traffic control entries by selectin the Traffic Control Entry Number line 704b, then inputting th

- desired traffic control entry number using the enter an select rocker switches 182 and 184 in.the previously describe manner. Once the desired traffic control entry number i entered on line 704b, the traffic control time and the traffi control distance for this entry is then displayed on line 704c and 704d respectively. The developer can then chang either or both of these entries, using the enter and selec rocker switches 182 and 184, to the desired entries. Finally, the developer can also delete all of th previously programmed traffic control distances and interval by selecting the Delete Control Entries line 704g. If ther are no programmed traffic control distances, the computer 11 assumes that the default traffic control distance is zero an adjustably updates the scenario clock accordingly. Hence, b using the Traffic Control Menu 700, the developer can develo a scenario wherein the student can deal with a given traffi condition in a manner different than the manner selected b the developer driving the phantom vehicle. While the Traffic Control Menu 700 and the functio available therefrom have been described in reference to scenario with a phantom vehicle, whereby the scenario cloc increments in the phantom adjusting mode, the traffic contro functions can also be readily adaptable to a scenario wherei the scenario clock increments in the rabbit adjusting mode Specifically, for a pursuit scenario where the scenario cloc increments in the rabbit adjusting mode, the scenario cloc increments at the fixed default rate when the student is at default distance of the rabbit vehicle 150. Hencej by usi the traffic control functions described above, the develop can also program the scenario clock to increment at the fix default rate when the student is within a given radius of t default distance from the rabbit vehicle 150. A pers skilled in the at can readily appreciate that the traff control function of the present invention is readily adaptab to both the pursuit type scenario where the scenario clock in the rabbit adjusting mode and scenarios where the scenar clock is in the phantom adjusting mode.

Figure 21 illustrates a Setup menu 730 that appears the video display 122 when the developer selects the Set line 334a on the Developer Menu 320 (Figure 7) . The Set menu 730 allows the developer to change various paramete about the scenario under development. The Setup Menu 7 includes an identifying header 732 and a box 734 containing Start Scenario line 734a, a View line 734b, a Scenario Sta Time line 734c, a Traffic Speed line 734d, a Driver Vehic Model line 734e, a Weather line 734f, and ABS line 734g, Display Scenario Clock line 734h, a Display Light Change li 734i and a Display Car Interior line 734j .

Using the Setup Menu 730, the developer can replay t developed scenario by selecting the Start Scenario line 734 The developer can either view the scenario from t perspective of the student driving the observer vehicle in t simulated universe 146 or from an overhead point of vi depending upon what the developer has selected on the Vi line 734b. If the developer has selected the Driver's e view on the View line 734b, the computer 114 then proceeds play the scenario from the start time specified by t developer on the Scenario Start Time line 734c and perform loop similar to the loop comprising the states 226 through 2

(Figure 4) thereby allowing the developer to drive through t simulated universe 146 in substantially the same fashion the student. If the developer has selected the overhead vi option, the computer 114 then proceeds to replay the scenar from the start time specified by the developer on the Scenari Start Time line 734c. Hence, the Start Scenario line 734 enables the developer to replay the entire scenario or an segment thereof, to determine if any editing or modification are necessary.

The Traffic Speed line 734d enables the developer t select the mode of operation for the scenario clock. On th line 734d, the developer can select between Fixed incrementin of the scenario clock, Suspect Adjust i.e. Rabbit Adjust, incrementing of the scenario clock or Phantom Adjus incrementing of the scenario clock. As previously describe in reference to Figure 5, the positions of the programme vehicles, including the rabbit or suspect vehicle 150, in th simulated universe 146, at any given instant is dependent upo the time according to the scenario clock. Hence, if th scenario clock is adjustably incrementing at a rate faste than its fixed default rate, the programmed vehicles appear t be moving faster, and if the scenario clock is adjustabl incrementing at a rate slower than its fixed default rate, th programmed vehicles appear to be moving slower.

The developer can also select the type of vehicle tha the student will drive as the observer vehicle by selectin the Driver Vehicle Model line 734e. In one preferre embodiment of the present invention, once the develope selects the Driver Vehicle Model line 734e, the computer 11 performs a function entitled "show_vehicles" whereby a pictur of each of the possible vehicle choices are shown on the vide display 122. In this preferred embodiment of the presen invention, the possible vehicles include a police cruiser, truck, a van, a compact, a sedan, a jaguar, a corvette, and ferrari. Preferably, the computer 114 is programmed so tha the performance of the selected observer vehicle in th simulated universe 146 when the scenario is runnin approximates the performance of the corresponding vehicle i the real world.

The developer can also control the weather conditions i the simulated universe 146 by selecting the Weather line 734f The possible weather conditions include clear skies, snow, fog, dusk, dawn and night. The default weather condition i clear skies. When one of the other weather conditions i selected, the computer 114 enables a function which adjust the display on the video display 122 so that it corresponds t the selected weather condition. This function is described i greater detail in assignee's co-pending patent applicatio entitled "Driver Training System with Performance Dat Feedback", Serial No. 07/898,375, filed May 22, 1992 an hereby incorporated by reference. When the scenario is ru for a student, the computer 114 implements the function an causes the video display 122 to display the simulated univers 146 as it would be seen in the selected conditions. Fo example, if the conditions was selected by the developer -o line 734f to be night, then the sky would appear dark and onl the portions of the simulated universe 146 immediatel adjacent a lamp post or within the beams of the observe vehicle's headlights would be illuminated.

The developer can also enable the ABS braking system 131 (Figure 1) by selecting the ABS line 734g and enabling the system. The ABS brake system simulates the feel of a brake pedal of a automobile equipped with an anti-lock brakin system. The operation of the ABS system 131 was described i greater detail in assignee's co-pending patent applicatio entitled "Driving Simulator With Realistic Operatin Feedback", Serial No. 08/018,950 filed February 17, 1993 whic is hereby incorporated by reference. Finally, using the Setup Menu 730, the developer can also instruct the compute to either display the scenario clock on the video screen 122 when the scenario is being played for a student or not displa the scenario clock by selecting the Display Scenario Cloc line 734h. Further, the developer can also instruct the computer 114 to display changes in the stop lights 153 (Figure 2) according to the developed stop light program, or th developer can disable the stop lights 153 so that they do not appear to change states by selecting the Display Light Chang line 734i. Finally, the developer can also cause the vide display 122 to display the interior view of the simulate vehicle, similar to the view seen by the student by selectin the Display Car Interior line 734j .

Hence, the Set Up Menu 730 allows the developer to fin tune the developed simulation by selecting various operatin parameters for the simulation including the scenario cloc adjust mode, the student's vehicle, the weather etc. Further the developer can also replay the developed scenario via th Start Scenario line 734a to ascertain how the scenario o particular portions of the scenario appear with certai selected parameters.

IV. EXAMPLE SCENARIO DEVELOPMENT

Figure 22 illustrates a portion of the simulated univers 146 as it would appear when viewed from overhead. As can b seen, this portion of the simulated universe 146 includes network of roads 148, several houses 154, one out-buildin 156, a first programmed vehicle 150, and two additiona programmed vehicles 850 and 860. A developer would develop this particular scenario, whic is one of many different possible scenarios that the develope can develop, in the following manner. The developer starts a the Developer Menu 320 (Figure 7) and goes to the Program Men 329 by selecting line 334b. Once in the Program Menu 32 (Figure 8) , the developer selects the location within th simulated universe 146 where the student driven observe vehicle will begin the scenario when it is played. Th developer accomplishes this by selecting the Set Start U Position line 340c of the Program Menu 329 causing th computer 114 to execute the "do_place_start" function 36

(Figure 12) which places the developer at a selected poin within the simulated universe 146. The developer then drive to a point 842 within the simulated universe 146 where wants the observer vehicle to be when the simulation begins Once the developer has driven to this position, the develope presses the enter rocker switch 182 (Figure 3) , thereb storing this location in memory. The computer 114 the returns the developer back to the Program Menu 329.

The developer may then add programmed vehicles to appea within the scenario he is developing. To add a firs programmed vehicle which can be designated the rabbit vehicl 150 in Figure 22, the developer selects the Add Vehicle lin 340b of the Program Menu 329 (Figure 8) . Selecting this lin causes the computer 114 to perform the "show_vehicle" functio 404 (Figure 9) where it generates on the video display 12 (Figure 1) pictures of various types of vehicles from whic the developer selects a vehicle type for the first programme vehicle 150. The computer 114 then assigns the firs programmed vehicle 150 an identification number 000-255. I the scenario shown in Figure 22, the identification numbe assigned to the first programmed vehicle 150 is 001. Th computer 114 then places the developer inside the simulate universe 146 and directs him to drive to a position 844 wher he wishes the first programmed vehicle 150 to appear. When a the position 844, the developer presses the enter rocke switch 182 (Figure 3) , whereupon the computer 114 executes th "create_and_program" function 417 (Figure 11) where it begin recording the path of the first programmed vehicle 150.

As shown in Figure 22, in this scenario, the develope drives the first programmed vehicle 150 in the direction o the arrow 846. After the developer has finished driving th path of the vehicle 150 in the simulated universe 146, th developer again presses the enter rocker switch 182 to signa to the computer 114 to stop recording the path of the vehicl 150. The developer can then go to the Edit Menu 510 (Figur 14) where the developer designates the programmed vehicle wit the identification number of 001 to be the rabbit or pursue vehicle 150. Alternatively, the developer could choose t designate the first programmed vehicle 150 as a phanto vehicle, in which case, when the scenario was run for student, the first programmed vehicle 150 would not be visibl for the student and the scenario clock would increment in t phantom adjusting mode. The developer may then wish to program a secon programmed vehicle 850 to appear in the scenario shown i Figure 22. To accomplish this, the developer returns to th Program Menu 329 (Figure 8) and begins programming the secon programmed vehicle 850 by again selecting the Add Vehicle lin 340b of the Program Menu 329 (Figure 8) . The developer i again asked to select a vehicle type for this vehicle, and th computer 114 assigns the second programmed vehicle 850 a identification number, which, in this case, is 002. Th computer 114 then performs the "to_mark_observe" function 41 (Figure 9) where it displays the simulated universe 146 to th developer via the video display 122 (Figure 1) and instruct and permits the developer to drive to a location where he ca observe the scenario unfold. After the developer has drive the second programmed vehicle 850 to this location, he the presses the select rocker switch 184 (Figure 3) whereupon th computer 114 executes the "replay_to_mark" function 41 (Figure 9) where it replays the portion of the scenario fro either the beginning of the scenario or the time selected b the developer via the Scenario Start Time line 340a of th Program Menu 329 (Figure 8) . In this case, the computer 11 replays the first programmed vehicle, designated to be th rabbit vehicle 150, driving in the direction of the arrow 84 down the street 148. The developer then presses the selec rocker switch 184 to stop the scenario clock and thereb freeze the replay of the scenario, so that the firs programmed vehicle 150 appears to the developer to b stationary in the simulated universe 146. The computer 11 then executes the "to_program_observe" function 416 (Figure 1 and 11) where the developer is instructed to drive to position 852 where the second programmed vehicle 850 will b introduced into the simulated universe 146.

After the developer has driven the second programme vehicle 850 to the location 852, he presses the enter rocker switch 182 (Figure 3) to initiate the recording of the path of the second programmed vehicle 850 in the memory of the computer 114 via the "create_and_program" function 417 (Figure 9 and Figure 11) . In the function 417, the computer 114 restarts the frozen scenario and records the path of the second programmed vehicle 850 as it is driven by the developer in the direction of an arrow 854 to a location 856.

Since the developer can see when the first programmed vehicle 150 will pass on the street 148 in front of the location 852, the developer can initiate the recording of the path of the second vehicle 850 at the point where the first programmed or rabbit vehicle 150, drives in front of the location 852 on the street 148. Hence, the developer can time the second programmed vehicle 85.0 to drive out from behind the out-building 156 just after the first programmed vehicle 150 has passed. From the standpoint of a ^''user 102 when the scenario is played, the user 102 in the observer vehicle is pursuing the rabbit vehicle 150 down the street 148 when the second programmed vehicle 850 appears out from behind the out¬ building 156, thereby requiring the user 102 to take evasive action to avoid colliding with the second programmed vehicle 850. Similarly, if the first programmed vehicle 150 is to be a phantom vehicle, the developer can pull out into the street 148 in front of the first programmed vehicle 150 and this will result in a scenario where the student driving the observer vehicle will have to take evasive- action to avoid th second programmed vehicle 850 when the scenario is run. The developer can further refine the time at which the second programmed vehicle 850 appears by changing the start and end time on the scenario clock via the Path Time line 52Oe of the Edit menu 510 (Figure 14) .

The developer may wish to add additional programmed vehicles to the scenario via the Add Vehicle Line 342d of the Program Menu 329. In the scenario shown in Figure 22, the developer has added a third programmed vehicle 860, which has been assigned the Path ID number of 003 by the computer 114, which appears in the simulated universe 146 at location 86 and drives in the direction of an arrow 864 to a location 866. Again, the developer drives the third programmed vehicle 86 in the manner he wishes it to appear in the simulated univers 146. Hence, the developer can program the third programme vehicle 860 to appear in the simulation universe 146 at th appropriate time on the scenario clock to drive across th intersection 868 after the first programmed vehicle 150 an the second programmed vehicle 850 have driven through th intersection, but prior to when the user 102 (Figure 1) in th observer vehicle drives through the intersection. Th developer can also drive the third programmed vehicle 86 through this intersection at an extremely high rate of spee to thereby create an event where the user 102 will have t take evasive action to avoid being hit by the third programme vehicle 860. The developer can also use the stopwatch of th Time Path line 342e of the Program Menu 329^s (Figure 8) to tim how long it will take to drive the third programmed vehicl 860 from its initial location 862 to the intersection 868. This permits the developer to determine how long it takes t drive the third programmed vehicle 860 to the intersection 86 and to use this information to ensure that the thir programmed vehicle 860 is timed to arrive in the intersectio 868 at about the same time on the scenario clock as th observer vehicle.

In this fashion, the developer can continue to ad vehicles to the simulated universe 146 and time them to appea to create additional traffic events and hazards for the use 102 (Figure 1) in the observer vehicle. Further, th developer can use the Replay Path feature of the Replay Pat line 520d of the Edit Menu 510 (Figure 14) to replay th paths, or selected portions thereof, of the programme vehicles. The developer can also use the features of th Setup Menu 700 (Figure 21) to view how the scenario will loo in various weather conditions via the Weather line 734f, o with the scenario clock incrementing in different modes vi the Traffic Speed line 734d. Additionally, the developer can set the stop light 15 positioned in the intersection 886 to change state^'s as th student driven observer vehicle approaches the intersectio using the Traffic Lights Menu 570 (Figure 16) . Specifically the developer selects the Program Traffic Lights line 582a an the computer 114 begins replaying the scenario from th scenario start time specified by the developer on the Scenari Start Time line 582e. The computer 114 either replays th scenario from the point of view of the driver driving throug the simulated universe 146 or from an overhead point of view depending upon what the developer has selected on the Repla View line 582f (Figure 16) .

If the developer has selected the driver's eye view, th computer 114 then replays the developed scenario from th scenario start time on the video display 122 (Figure 1) as i would be seen by a student. The developer then drives throug the simulated universe 146 in the same fashion that a studen would. As the developer approaches the intersection 868, h manipulates the enter rocker switch 182 (Figure 3) to stop th scenario clock and thereby freeze the programmed vehicles 86 and 850. The developer can then drive in the simulate universe 146 up to the intersection 868 to ascertain th relative positions of the programmed vehicles 850 and 860 t the intersection. The developer can then change the ligh state by manipulating the select switch 184 until the traffi light 153 is displaying the desired state.

For example, the developer may wish., to. program, th traffic light 153 so that the light 153 appears green on it north-south face and red on its east-west face. The develope then manipulates the enter rocker switch 182 into the se position (Figure 3) and the computer 114 records the state o the traffic light at this time on the scenario clock as bein green on the north-south faces and red on the east-west faces Hence, in this example, the traffic light 153 in th intersection 868 is red in the east-west direction when th programmed vehicle 860 goes through the intersection goin from west to east. In this fashion, the developer can creat a traffic situation where the student has to avoid being h by the programmed vehicle 868 as it unexpectedly runs the st light 153.

The developer can also program the traffic lights 1 when viewing the replay of the scenario from an overhe perspective as is shown in Figure 22. The method scheduling the light changes from this perspective substantially the same as the method just described exce that the developer does not have to drive through t simulated universe 146. The computer 114 generates overhead display that is centered on either the rabbit vehic 150 or a pre-programmed phantom vehicle.

The developer may also wish to record the student' driving performance as he maneuvers through the intersecti 868 where the programmed vehicle 860 runs the stop light 153 In that case, the developer selects the Replay Window Menu 6 (Figure 19) , and creates a replay window to cover the time the scenario clock when the student and the programmed vehicl 860 traverses the intersection. Subsequently, after t student has finished driving the scenario, the simulator 10 replays this portion of the scenario illustrating how t student drove through the intersection and dealt with t programmed vehicle 860 running the intersection.

If the developer has designated the first programm vehicle 150 to be a phantom vehicle and has thereby set t scenario clock to increment in the phantom adjust mode, t developer may then wish to set a traffic control distance f the interval of time when the student will be driving throu the intersection 868. The developer uses the Traffic Contr Menu 700 (Figure 20) to select the distance via the line 704

If the developer has programmed the third programm vehicle 860 to enter the intersection 868 at the same time the phantom vehicle 150, when the simulation is run, the thi programmed vehicle 850 enters the intersection at the sa time as the student-driven observer vehicle regardless of h fast or slow the student drove the vehicle due to the phant adjusting of the scenario clock. However, if the develop set a traffic control distance sufficiently large to permi the phantom vehicle to proceed through the intersection ahea of the student driven observer vehicle as the stude approaches the intersection so that the scenario clock stil fixedly adjusts at the default rate, the student then has choice as to how to proceed through the intersection.

Specifically, the student can either proceed into th intersection and attempt to avoid the third programmed vehicl 860 by swerving around it, or the student can stop and wai for the third programmed vehicle 860 to clear the intersectio 868. If the traffic control distance was set to zero, onc the student stopped, the third programmed vehicle 860 woul slow down or stop so that once the student entered th intersection, the third programmed vehicle 860 would als enter the intersection. Hence, the Traffic Control Menu 70 allows the developer to program certain intervals of time o the scenario clock where the scenario ^xclock will fixedl increment provided the student-driven observer vehicle i within a given radius of the phantom vehicle which thereby ca provide greater flexibility for the student in driving th scenario.

V. SIMULATION SCENARIO DATA STRUCTURE

Figure 23 is an organizational chart of one preferre embodiment of the scenario data relating to a simulatio scenario.developed in the above-described manner illustratin one possible manner of storing the data in the memory of th computer 114. A data structure 900 stores data about a singl scenario. This data is initially programmed by the develope using the simulator input controls 104-112 and the compute 114 (Figure 1) . Preferably, this information is subsequentl uploaded into the memory of the personal computer 103 where i is stored until the scenario is required by a user. Data about the number of programmed vehicles in th scenario is stored in an area 900a. The number of programme vehicles stored within the memory is determined by a counte keeping count of the number of vehicles added by the develope via the Add Vehicle line 340b of the Program menu 329 (Figur 8) . In the presently preferred embodiment, there is a limi of 256 vehicles that can be programmed into any one scenario The area 900a also preferably contains an indicator as to th location of a series of Programmed Vehicle data structures 92 which contain information about each of the programme vehicles in the memory.

Also stored within the data structure 900, in an are 900b, is an indicator of where the free path data exists. Al the paths of the programmed vehicles through the simulate universe 146 (Figure 19) are stored in the memory of th computer 114 in terms of a location in the simulated univers 146 at a^' given time on the scenario clock. In this preferre embodiment, at any one time on the scenario clock there ca only be twenty programmed vehicles active in the simulate universe 146 at any one time. The information contained i area 900b provides information about the next scenario tim which is available to have an additional programmed vehicl made active within the simulated universe 146.

An area 900c within the data structure 700 contains th programmed vehicle path identification number (000 to 255) o the programmed vehicle for a pursuit simulation which has bee designated as either the pursued (or rabbit) vehicle 15 (Figure 19) or the phantom vehicle by the developer. Th developer designates one of the programmed vehicles as th rabbit vehicle 150 or the phantom vehicle.

An area 900d contains information about when, accordin to the scenario clock, the scenario is scheduled to end. pursuit-type scenario is scheduled to end when the rabbi vehicle 150 is removed from the scenario. A driver trainin scenario is scheduled to end either when the phantom vehicl is removed from the scenario, or the last programmed vehicl is removed from the scenario. Preferably, once the scenari has ended, the computer 114 displays an appropriate message o the video display 122 indicating that the scenario i completed. Subsequently, any replay windows of the complete scenario are shown to the student on the video display 122.

An area 900e contains information about the traffic light default times. The traffic lights default times are the times listed on the Green Light Default Time line 582h and the Yellow Light Default Time Line 582i in Traffic Lights Menu 570 (Figure 16) . The computer 114 retrieves this information when the scenario is being played and changes the state of the traffic lights 153 based on these default light times unless the developer has programmed a new schedule for light changes using the do_program_lites function described previously in reference to Figure 17 and 17a. The area 900e also contains an indicator indicating the position of a data-structure 940 which contains the time and state - of each light change programmed by the developer using the "do__program_lites" function 590 (Figure 17) . As the scenario clock 934 increments, the computer 114 changes the state of the traffic lights 153 to their new states at each of time periods specified by the developer.

An area 900f in the scenario data structure 900 contains information about the start and end times for any replay windows specified by the developer using the Replay Window function described in reference to the Replay Window Menu 670 (Figure 19) . The area 900f also preferably contains an indicator as to the location of a Replay Windows Data Structure 936 in the memory of the computer 114. The Replay Windows Data Structure 936 contains the time period, according to the- scenario clock, that the computer 114 records the scenario and the path of the observer vehicle driven by the student for each of the replay windows specified by the developer.

An area 900f in the scenario data structure 900 contains the Cartesian coordinates of the initial position of the student driven observer vehicle and also the initial unit vectors, i.e., the direction it is initially facing. The initial position and the initial unit vectors are programmed by the developer via the Set Start Up Position line 340b of the Program Menu 329 (Figure 8) . The information stored in area 900f is used by the computer 114 to correctly place an orient the observer vehicle containing the student in th simulated universe 146 at the start of play of the scenario The computer 114 stores the information about th programmed vehicles in a series of similar data structure 920, 924, 928. These data structures are preferably furthe stored in the memory of the computer 114 in terms of when th programmed vehicle is programmed to appear on the scenario i the simulated universe 146 according to the scenario clock. The data structure 920 contains all the definin attributes of the first programmed vehicle, as well as pointer to the location of the path data for this particula vehicle within the memory of the computer 114. Th identification or Path ID number assigned to the firs programmed vehicle is stored in area 920a of the dat structure 920. This number is used by the computer 114 t

\ retrieve information relating to the first programmed vehicl when the computer 114 is displaying this vehicle on the vide display 122 (Figure 1) . A rabbit/phantom vehicle flag, o indicator, is stored in area 720b of the data structure 720. This indicator specifies whether the first programmed vehicl is either the rabbit vehicle 150 (Figure 19) or the phanto vehicle if the developer has so defined the first programme vehicle. An area 920c indicates when, on the scenario clock, the first programmed vehicle is scheduled to be introduce into the simulated universe 146. An area 920d indicates when, on the scenario clock, the first programmed vehicle i scheduled to be taken out of the simulated universe 146. Th data contained on the lines 920c and 92Od is used by th computer 114 to determine when to display and remove the firs programmed vehicle from the simulated universe 146 (see Figur 4) . The data structure 920 also contains data in a locatio 920e which indicates the initial position of the firs programmed vehicle in the simulated universe 146. The dat structure 920 further contains an area 920f which contain data which defines the type of vehicle the first programme vehicle has been selected to be by the developer. This dat is used by the computer 114 to generate a display of the firs programmed vehicle within the simulated universe 146 via th video display 122 (Figure 1) . The data structure 920 furthe contains an area 920g which is a pointer to the locatio within the memory of the computer 114 of a data structure 92 containing the path data for the first programmed vehicle.

The path data for the first programmed vehicle containe in data structure 922 is arranged so that the data structur 922 contains the location of the first programmed vehicl within the simulated universe 146 (Figure 19) at sequentia intervals of time on the scenario clock. When the firs programmed vehicle is recorded by the computer 114 via the Ad Vehicle line 640a of the Program Menu.329 (Figure 8), the dat structure 922 simultaneously receives the Cartesia coordinates of the first programmed vehicle from the mode process 118 (Figure 1) , as well as the time according to th scenario clock 934. When the first programmed vehicle i displayed by the computer 114 via the video display 12 (Figure 1) , the time on the scenario clock 934 tells th computer 114 the location where the first programmed vehicl should be displayed.

Figure 23 further illustrates that there are similar dat structures for each of the programmed vehicles and their path through the simulated universe 146 in the memory of th computer 114 for this scenario. A data structure 924 contain the attributes of the second programmed vehicle scheduled t appear in the simulated universe 146, according to th scenario timer, with a pointer to a data structure 926 withi the memory of the computer 114 which contains the path dat for the second programmed vehicle. Additionally, a dat structure 928 contains the attributes of the last programme vehicle scheduled to appear in the simulated universe 146 according to the scenario clock 934, with a pointer to a dat structure 930 in the memory of the computer 114 containing th path data for the last programmed vehicle.

Further, Figure 23 also illustrates that the Repla Windows data structure 936 contains information about each o the replay windows 001 - 00N, as programmed by the developer sequentially stored in terms of when, on the scenario clock, the computer 114 is to record the path taken by the student. When the scenario is running, the computer 114 sequentially records each window of time on the scenario clock as specified by the data structure 936. Similarly, the memory of the computer 114 is also logically organized to include a Traffic Control data structure 938 which also contains each of the traffic control distances specified by the developer along with the time on the scenario clock that the traffic control distance is in effect. When the scenario is being run for a student, the computer 114 sequentially recalls each of the traffic control distances as their activation time occurs on the scenario clock and then uses this information to control the incrementing of the scenario clock 934.

While the foregoing discussion has described one possible manner of organizing the data for ready access by the computer 114 when the scenario is being replayed, a person skilled in the art can appreciate that any of a number of well known manners of organizing data can be used to implement the simulation system 100, including both the play and development processes 119, 121, of the present invention. Further, the foregoing description is simply an exemplary representation of the manner of organizing the data for this particular simulation system 100. Included in the Microfiche Appendix is source code entitled "svars.h" which more specifically defines the above described data structures for this preferred embodiment of the present invention.

VI. SUMMARY

The present invention includes a simulation system which includes a simplified process for developing scenarios for vehicle simulators. Specifically, this invention permits a developer to develop a simulation by sitting at the vehicle simulator controls and driving vehicles in the simulated universe according to user selectable parameters. This invention includes a adjustable scenario clock controlling the scheduling of occurances in the simulation. The clock is configured so that the developer can program an event to occur in the scenario designed to require the student user to respond, e.g., take evasive action, that will occur in the scenario^'when the scenario is replayed for the student at the appropriate time to force the student to respond, regardless of how fast the student proceeds through the simulation.

Although the above detailed description has shown, described and pointed out fundamental novel features of the invention as applied to the various embodiments discussed above, it will be understood that various omissions and substitutions and changes in the form and details of the device illustrated may be made by those skilled in the art, without departing form the spirit of the invention. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

WHAT IS CLAIMED IS:

1. A driver training system for a user of a simulated vehicle comprising: at least one plurality of user operated input devices for controlling the operation of the simulated vehicle in a simulated universe; a central controller; a storage medium connected to the controller containing information defining the simulated universe and a scenario; a model process associated with the controller and responsive to signals indicative of user manipulation of the plurality of input devices, for determining position of the simulated vehicle in the simulated universe; a video display, responsive to signals from the controller, for displaying a view of the simulated universe based in part on the position of the simulated vehicle as determined by the model process; and a scenario development process, associated with the controller and responsive to signals from the model process, for developing and storing information in the storage medium defining a path of a programmed vehicle through a portion of the simulated universe as part of the scenario in response to user operation of the at least one of the input devices while controlling operation of a simulated vehicle in the simulated universe.