Patent Publication Number: US-10322353-B1

Title: Systems and methods for dynamic ride profiles

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims priority from and the benefit of U.S. Provisional Application No. 62/671,940, entitled “SYSTEMS AND METHODS FOR DYNAMIC RIDE PROFILES,” filed May 15, 2018, which is hereby incorporated by reference in its entirety for all purposes. 
    
    
     BACKGROUND 
     This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present techniques, which are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art. 
     Various amusement rides have been created to provide passengers with unique motion and visual experiences. For example, theme rides can be implemented with single-passenger or multi-passenger ride vehicles that travel along a fixed or variable path. Ride vehicles themselves may include features providing passengers with varying levels of control (e.g., various buttons and knobs) over the ride vehicle and/or surrounding environment. However, traditional controls given to passengers of a ride vehicle are generally limited when the ride vehicle follows a pre-determined, fixed path. Accordingly, it is now recognized that there is a need for an improved amusement ride that provides enhanced passenger control over the ride vehicle to create a more adventurous ride experience. 
     For certain amusement park rides, vehicle movements are constrained to programmed profiles (e.g., animations) that are embedded in a programmable logic controller (PLC) of the vehicle. However, it is presently recognized that these programmed profiles are substantially static and, as such, are not updated or modified based on passenger interactions with the vehicle and/or based on realistic physics models. As a result, a passenger of the ride may feel like the ride is staged or unrealistic, which may limit passenger engagement and amusement. Additionally, it is also recognized that PLCs are not capable of performing extensive calculations, such as those used in complex physics models. That is, while PLCs are adept at quickly responding to a parameter change to a value that is beyond a predetermined threshold, PLC processors typically have a lower clock speed (e.g., 200 Hz) compared to other types of processors, such as central processing units (CPUs) and graphical processing units (GPUs) of modern computers. Furthermore, PLC programming and debugging can be difficult, tedious, and expensive. Accordingly, it is now recognized that, when a ride is designed using PLCs alone to determine and generate a passenger&#39;s experience, this can severely limit the ride&#39;s ability to immerse a passenger in an experience that feels true to a realistic physics model. 
     SUMMARY 
     Certain embodiments commensurate in scope with the originally claimed subject matter are summarized below. These embodiments are not intended to limit the scope of the disclosure, but rather these embodiments are intended only to provide a brief summary of certain disclosed embodiments. Indeed, the present disclosure may encompass a variety of forms that may be similar to or different from the embodiments set forth below. 
     Present embodiments are directed toward a dynamic control system for an amusement park ride. The system includes a game server configured to generate game data that describes movement of a virtual vehicle through a virtual environment; a programmable logic controller (PLC) configured to conditionally execute instructions of a dynamic ride profile relative to one or more stored limits to operate physical actions of the ride vehicle; and a dynamic ride profile server communicatively coupled to the game server and the PLC. The dynamic ride profile server is configured to: receive input data, sensor data, and the game data; provide the input data, the sensor data, and the game data as inputs to one or more physical models to generate a portion of a dynamic ride profile based on the movement of the virtual vehicle through the virtual environment; and provide the portion of the dynamic ride profile to the PLC for conditional execution. 
     Present embodiments are also directed toward an amusement park ride having a game server configured to generate game data that includes a virtual environment. The ride has a ride vehicle communicatively coupled to the game server and configured to move passengers along a ride path, wherein the ride vehicle includes: one or more output devices configured to present the virtual environment to the passengers of the ride vehicle based on the game data generated by the game server; one or more input devices configured to collect input data from the passengers of the ride vehicle; one or more sensors configured to collect sensor data during operation of the ride vehicle; and a programmable logic controller (PLC) communicatively coupled to the one or more input devices and the one or more sensors, wherein the PLC is configured to receive and conditionally execute instructions of a dynamic ride profile relative to one or more stored limits to operate physical actions of the ride vehicle. The ride includes a dynamic ride profile server communicatively coupled to the game server and the PLC, wherein the dynamic ride profile server is configured to: receive the input data and the sensor data via the PLC and receive the game data from the game server; provide the input data, the sensor data, and the game data as inputs to one or more physical models to generate a portion of the dynamic ride profile; and provide the portion of the dynamic ride profile to the PLC for conditional execution. 
     Present embodiments are also directed toward a method of controlling an amusement park ride. The method includes: receiving input data from one or more input devices of a ride vehicle of the amusement park ride; receiving sensor data from one or more sensors of the amusement park ride; and receiving game data from a game server of the amusement park ride, wherein the game data describes movement of a virtual vehicle through a virtual environment. The method also includes providing the input data, the sensor data, and the game data as inputs to one or more physical models to generate a portion of a dynamic ride profile based on the movement of the virtual vehicle through the virtual environment. The method further includes providing the portion of the dynamic ride profile to a communicatively coupled PLC of the ride vehicle, wherein the PLC of the ride vehicle is configured to conditionally execute the portion of the dynamic ride profile during operation of the ride to physically move the ride vehicle based on one or more stored limits of the PLC. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       These and other features, aspects, and advantages of the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein: 
         FIG. 1  is a schematic diagram illustrating an amusement park ride having a dynamic control system, in accordance with embodiments of the present approach; 
         FIG. 2  is a schematic diagram illustrating the flow of information within the embodiment of the dynamic control system illustrated in  FIG. 1 , in accordance with embodiments of the present approach; and 
         FIG. 3  is a flow diagram illustrating an embodiment of a process whereby the PLC of a ride vehicle receives and conditionally executes instructions of a dynamic ride profile, in accordance with embodiments of the present approach. 
     
    
    
     DETAILED DESCRIPTION 
     One or more specific embodiments of the present disclosure will be described below. In an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers&#39; specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure. 
     Present embodiments are directed to a dynamic control system that is designed to control vehicle movements of an amusement park ride. The dynamic control system includes a dynamic ride profile server that is communicatively coupled to a PLC of the ride vehicle and that provides instructions to the PLC to adjust the movement of the ride vehicle based on a combination of sensed parameters, physics models, game feedback, and passenger interactions. As such, the dynamic control system enables the ride to provide realistic simulation movements that improve passenger engagement and amusement. Additionally, to ensure proper operation of the ride vehicles, the PLC maintains a set of limits and does not allow the vehicle to perform movements that go beyond these limits, regardless of the instructions received from the dynamic ride profile server. Furthermore, the disclosed dynamic control system enables rides that include enhanced interaction with the simulated environment (e.g., drag, wind gusts, precipitation), as well as enhanced simulated interaction between multiple vehicles (e.g., drafting, collisions), in accordance with physics models of the dynamic ride profile server. 
     The disclosed dynamic control system is discussed below in the context of an example amusement park ride  10 , namely a dark ride that includes two ride vehicles  12 , as illustrated in  FIG. 1 . It should be appreciated that the disclosed dynamic control system may be used in combination with other types of rides and ride vehicles, or using any suitable number of vehicles (e.g., 3, 4, 5, 6, or more). For the illustrated embodiment, the ride vehicles  12  are substantially the same; however, the ride vehicles  12  are differently illustrated in  FIG. 1  to more clearly illustrate different aspects (e.g., components and motion) of the ride vehicles  12 . 
     For the embodiment illustrated in  FIG. 1 , passengers  14  are presented with an augmented or completely virtual environment  15  from within the ride vehicle. More specifically, in the illustrated embodiment, each ride vehicle  12  includes a number of output devices  16 . For example, the output devices  16  may include any suitable number of displays (e.g., mounted to the interior of the vehicles, head-mounted displays), speakers, haptic feedback devices (e.g., rumble/vibration feedback devices, acoustic or ultrasonic haptic devices), physical effects devices (e.g., devices that generate hot or cold bursts of air, devices that generate bursts of mist). In other embodiments, each of the ride vehicles  12  may include other suitable output devices  16 , or other combinations of output devices  16 , in accordance with the present disclosure. 
     Additionally, for the embodiment illustrated in  FIG. 1 , each of the ride vehicles  12  includes a number of input devices  18 . For example, these input devices  18  may include buttons (e.g., ignition buttons), steering devices (e.g., steering wheels, joysticks), control pedals (e.g., brake pedals, accelerator pedals, clutch pedals), gear shifts, and/or brake levers. These input devices  18  may additionally or alternatively include a head and/or eye tracking system that monitors passenger head/eye position to collect steering input from the passengers  14 . In other embodiments, each of the ride vehicles  12  may include other input devices  18 , or other combinations of input devices  18 , in accordance with the present disclosure. In certain embodiments, each of the passengers  14  may have a respective set of input devices  18 , while in other embodiments, each of the passengers  14  may have a complementary portion of input devices  18  that are used in a cooperative manner. 
     Additionally, the ride  10  illustrated in  FIG. 1  includes the dynamic control system  20 , which is designed to control movements of the ride vehicles  12  in accordance with a dynamic ride profile, as discussed in greater detail below. More specifically, the illustrated dynamic control system  20  includes a number of components, such as a dynamic ride profile server  22 , a game server  24 , and a respective PLC  26  of each of the ride vehicles  12 , communicatively coupled together via a network  28 . While the network  28  may be wireless in certain embodiments, it is noted that a wired network generally enables lower latency communication, which can improve performance of the ride  10 . 
     A “game server,” as used herein, and as discussed in greater detail below, refers to a computing device or a collection of computing devices (e.g., physical computing devices or virtual computing nodes) generally responsible for managing a video game aspect of the ride  10 . As such, the game server  24  is programmed to generate a virtual environment (e.g., a virtual 3D space) in which virtual vehicles are designed to move. A “virtual vehicle,” as used herein, refers to a video game entity or element of the virtual environment that has particular attributes (e.g., speed, position, health/damage, fuel, appearance) that are maintained by the game server  24 . For example, a virtual vehicle is associated with each of the physical ride vehicles  12 . In certain embodiments, additional virtual vehicles (e.g., non-playable characters/vehicles) may be present within the virtual environment as well. 
     For example, in an embodiment, the ride  10  may be a racing simulator, and as such, the game server  24  generates and maintains a virtual environment that describes the nature of the race track that virtual vehicles are traversing, the relative speed and position of the virtual vehicles, interactions between the virtual vehicles, attributes (e.g., performance upgrades, health, bonuses, score) associated with the virtual vehicles, and so forth. Furthermore, the game server  24  generates content (e.g., video content, audio content) delivered to the ride vehicles  12  and output by the output devices  16  to yield the virtual environment  15  that is presented to the passengers  14 . For example, in an embodiment, video content presented by display devices of the ride vehicles  12  is content that corresponds to different perspective views generated within the virtual environment hosted by the game server  24 . 
     A “dynamic ride profile server,” as used herein, and as discussed in greater detail below, refers to a computing device or a collection of computing devices (e.g., physical computing devices or virtual computing nodes) generally responsible for determining how the physical ride vehicles  12  should move based on a number of different input data and one or more physics models. As discussed, these inputs include information received from the game server  24  that indicates or describes what is happening to each corresponding virtual vehicle in the virtual environment, such as how the virtual vehicles move in response to a texture or incline of the race track, how the virtual vehicles respond to environmental hazards (e.g., rain, standing water, ice), how the virtual vehicle interact one another, and so forth. Additionally, in certain embodiments, the dynamic ride profile server  22  additionally receives input data from the input devices  18  and/or various sensors of the ride  10 . As discussed below, the dynamic ride profile server  22  provides the received data as inputs to one or more physical models that describe how the physical ride vehicles  12  should move to correspond with what is happening in the virtual environment  15  that is presented to the passengers  14 . In this manner, the dynamic ride profile server  22  generates a dynamic ride profile that instructs each of the ride vehicles  12  how to move to match what is being presented to the passengers  14  by the game server  24 , as well as the inputs received from the input devices  18 . 
     For the illustrated embodiment, the dynamic ride profile server  22  and the game server  24  generally reside in a control area  30  of the ride, while the PLCs  26  are disposed within the ride vehicles  12 . In other embodiments, it is envisioned that the dynamic control system  20  may be disposed substantially or entirely within one or more ride vehicles  12 . In certain embodiments, the dynamic ride profile server  22  and the game server  24  may be hosted by distinct physical computing devices, or may exist as virtual server instances hosted by a common physical computing device. The one or more computing devices that host these servers generally include suitable memory  32  capable of storing instructions and data, as well as suitable processing circuitry  34  capable of executing these stored instructions to provide the functionality set forth herein. 
     For the embodiment of the ride  10  illustrated in  FIG. 1 , each of the ride vehicles  12  is designed to travel along a relatively restricted track or ride path  36  during operation. It may be appreciated that, in certain embodiments, a ride path  30  may only be loosely defined by a set of physical or virtual boundaries, enabling greater freedom of movement for the ride vehicles  12  than a traditional track. However, the ride  10  is designed to modify operation (e.g., position or motion) of the ride vehicles  12  based on control signals from the dynamic control system  20 . Accordingly, in addition to producing effects in the virtual environment  15  that is presented to the passengers  14 , the input devices  18  also provide inputs that can trigger real-world effects, including changing the operation of the vehicles  12  within a predefined set of limits. As discussed in greater detail below, the disclosed dynamic ride profile server  20  can provide control signals to modify vehicle yaw (as represented by arrows  38 ), tilt angle (as represented by arrow  40 ), ride path location (e.g., displacement  42  along the ride path  36 , displacement  44  with respect to boundaries of the ride path  36 ), speed (e.g., rate of displacement  42  along the ride path  36 , rotational rate), or any other suitable parameter of the vehicles  12 , in accordance with a physics-based dynamic ride profile that takes passenger inputs into account. That is, embodiments of the dynamic ride profile server  20  can provide control signals to modify one or more of a position of the ride vehicles  12  along the ride path  36 , a rotational position of the vehicles  12 , and/or provoke any other suitable free form movement along one or more axes (e.g., along six degrees of freedom). This generally enables the ride vehicles  12  to move in a manner that is consistent with what is being presented in the virtual environment  15 , producing an immersive experience for the passengers  14 , as discussed in greater detail below. Additionally, as discussed below, to ensure proper operation of the vehicles  12  and the ride  10 , the PLCs  26  of the vehicles  12  are designed to receive the control signals from the dynamic ride profile server  22  and only implement the control signals when they fall within limits predefined within the PLCs  26 . These limits may include special scenarios outside of normal operating parameters (e.g., maintenance or alarm conditions) 
     For the embodiment illustrated in  FIG. 1 , the dynamic control system  20  includes a number of vehicle controllers that are communicatively coupled to the PLCs  26  of the vehicles  12 , including a ride vehicle speed controller  46  and a ride vehicle rotation controller  48 . The illustrated dynamic control system  20  also has a number of sensors  50 , including sensors  50 A that are communicatively coupled to the dynamic ride profile server  22  and the game server  24  via the PLCs  26 , as well as sensors  50 B that are communicatively coupled to the dynamic ride profile server  22  and the game server  24  via the network  28 . These sensors  50  may include positional sensors (e.g., proximity detectors, radio-frequency identification (RFID) sensors, cameras, light detection and ranging (LIDAR) sensors), velocimeters, accelerometers, gyroscopes, revolutions per minute (RPM) sensors, voltage/current sensors, or other suitable sensors capable of measuring a parameter of the vehicles  12 , the passengers  14 , and/or the ride  10 . For the illustrated embodiment, the PLCs  26  are communicatively coupled to the input devices  18  to receive input from the passengers  14  and to provide this input to the dynamic ride profile server  22  and the game server  24 . Similarly, the PLCs  26  are communicatively coupled to the output devices  16  to present the virtual environment  15  to the passengers  14  based on control signals from the dynamic ride profile server  22  and the game server  24 . 
     For the illustrated embodiment, the dark ride  10  includes a video game aspect. That is, the ride  10  presents information to passengers  14  depicting the virtual environment  15 , and receives input from the passengers  14  that determines the performance (e.g., vehicular movement, score) of the passengers  14  in the virtual environment. For example, the game server  24  may provide, to the output devices  16  of the ride vehicles  12 , audio/visual information (e.g., video content, sound effects, music, virtual reality (VR) content, augmented reality (AR) content) pertaining to the video game aspect of the ride  10 . Additionally, the game server  24  is designed to receive input from sensors  50  of the dynamic control system  20  and/or from input devices  18  associated with the ride vehicles  12 , and, in response, update the audio/visual information presented to the passengers  14 . 
     As discussed, the dynamic ride profile server  22  is designed to determine suitable movements for the ride vehicles  12  that make the ride experience feel like the vehicles are actually moving through the virtual environment  15  being presented to the passengers  14  of the vehicle by the game server  24 . Accordingly, the dynamic ride profile server  22  is designed to receive and process information from other components of the system (e.g., game server  24 , input devices  18 , sensors  50 ) and apply suitable physics models to determine dynamic ride profiles, which include instructions regarding how the vehicles  12  should be manipulated to provide a realistic physical experience that corresponds to the virtual environment  15 , and is responsive with respect to inputs provided by the passengers  14  via the input devices  18 . For example, in certain embodiments, the dynamic ride profile server  22  is configured to adjust dynamic ride profiles, and thereby, the movement of the ride vehicles  12 , to account for changes in physical models (e.g., corresponding to movement through different media), differences in weight among passengers  14 , physical limitations of passengers  14 , and interactions between two or more passengers  14  in the same or different ride vehicles  12 . 
       FIG. 2  is a schematic illustrating the flow of information within the embodiment of the dynamic control system  20  illustrated in  FIG. 1 , as is discussed with reference to elements illustrated in  FIGS. 1 and 2 . As illustrated in  FIG. 2 , the dynamic ride profile server  20  includes (e.g., stores in memory  32 ) a number of physics models  60 . For example, these physics models  60  may include models that define how virtual vehicles (which correspond to the ride vehicles  12 ) move through the virtual environment  15 , such as along a smooth or laminar path, moving along a bumpy or turbulent path, sliding or drifting, or transitioning between different media (e.g., moving between air and water). The physics models  60  may also include models that describe how two or more virtual vehicles interact with and affect one another (e.g., via drafting, collisions, missile attacks) within the virtual environment  15  that is presented to the passengers  14 . Additionally, the dynamic ride profile server  22  is capable of combining multiple models together when processing the received data to generate dynamic ride profiles  62 A and  62 B, which are respectively provided to the ride vehicles  12 A and  12 B as a series of instructions or control signals that define the ride experiences for the passengers  14  of both vehicles. 
     As illustrated in  FIG. 2 , the dynamic ride profile server  22  receives and consumes a variety of data to generate dynamic ride profiles  62 A and  62 B, which are then provided to the PLCs  26 A and  26 B of the first and second ride vehicles  12 A and  12 B, respectively, for conditional execution. For the illustrated embodiment, the consumed data includes passenger input data  64  received via the input devices  18 , as well as sensor data  66  received from sensors  50  directly or indirectly communicatively coupled to the dynamic ride profile server  22  via the network  28 , as discussed above. Additionally, for the illustrated embodiment, the consumed data also includes game data  68  received from the game server  24  that describes what is happening in the virtual environment to the virtual vehicles associated with each of the ride vehicles  12 A and  12 B. The dynamic ride profile server  22  receives and processes this data together, feeding this data as inputs to the one or more physics models  60 , to generate the instructions of the dynamic ride profiles  62 A and  62 B, which are delivered to the PLCs  26 A and  26 B of the ride vehicles  12 A and  12 B. It may be appreciated that since these dynamic ride profiles are based, at least in part, on the input data  64  received from passengers  14  during operation of the ride  10 , the dynamic ride profiles are generated and delivered to the ride vehicles  12  in a serialized or piecewise manner throughout the operation of the ride  10 . 
     However, it may be appreciated that the PLCs  26 A and  26 B of the first and second vehicles  12 A and  12 B do not unconditionally execute the instructions of the dynamic ride profiles  62  received from the dynamic ride profile server  22 . That is, as illustrated, each of the PLCs  26  stores a number of limits  70  that define thresholds for normal or acceptable operation of the ride vehicles  12 . For example, these limits  70  may include a maximum/minimum speed limit, an acceleration limit, a yaw limit, a tilt limit, a current/voltage limit, a torque limit, a minimum intravehicular distance, or any other limit that defines the normal and desired operation of the vehicles  12  and the ride  10 . Additionally, as illustrated, each of the PLCs  26  also receives and processes a portion of the sensor data  66  (e.g., collected by sensors  50 A illustrated in  FIG. 1 ), which is used by the PLCs to enforce the limits  70 , as discussed below. 
     As such, “conditional execution,” as used herein, refers to PLCs  26  receiving dynamic ride profiles  62  from the dynamic ride profile server  22 , wherein, before executing instructions of the profiles, each of the PLCs  26  ensures that executing the instructions in these profiles would not put the ride vehicles  12  or the ride  10  into a state that is beyond the limits  70  stored by the PLCs  26 . For example, the PLCs  26 A and  26 B do not provide or are prevented from providing control signals to the ride vehicle speed controllers  46 A and  46 B or the ride vehicle rotational controllers  48 A and  48 B that are beyond the predefined limits  70  (e.g., beyond the bounds of an envelope defined by the limits  70  in combination). Similarly, the PLCs  26 A and  26 B do not provide or are prevented from providing respective control signals to directly coupled drives  72 A or  72 B that are beyond these predefined limits  70 . Accordingly, it may be appreciated that the experience of the ride is largely dominated by the dynamic ride profile server  22  (which has substantially greater processing power to generate a physically realistic experience), while the PLCs  26  (which have substantially less processing power, but are designed to ensure real-time parameter compliance) enforces the limits  70  to ensure proper operation of the ride  10 . 
       FIG. 3  is a flow diagram illustrating an embodiment of a process  80  whereby a PLC (e.g., PLC  26 A of ride vehicle  12 A of  FIG. 2 ) receives and conditionally executes instructions of the dynamic ride profiles  62 A. The illustrated process  80  begins with the PLCs  26 A receiving (block  82 ) a portion of the dynamic ride profile  62 A from the dynamic ride profile server  22  via the network  28 , wherein the received portion of the profile includes one or more instructions or control signals to perform particular vehicular movements. For example, the instructions of the dynamic ride profile  62 A may include instructions to modify operation of the ride vehicle speed controller  46 A and/or the ride vehicle rotational controller  48 A, as illustrated in  FIG. 2 , to change a speed or rotational position of the vehicle  12 A. 
     In response, as illustrated in  FIG. 3 , the PLC  26 A determines (block  84 ) a current state of the vehicle  12 A based on received sensor data. For example, as mentioned, the PLC  26 A receives sensor data  66  from the communicatively coupled sensors  50 A, and the PLC  26 A utilizes this data to determine a current state (e.g., location, position, speed, acceleration) of the ride vehicle  12 A. The PLC  26 A also estimates (block  86 ) a future state of the vehicle  12 A based on the current state of the vehicle  12 A and the instructions received as part of the dynamic ride profile  62 A from the dynamic ride profile server  22 . The PLC  26 A then determines (block  88 ) whether the estimated future state is beyond one or more of the limits  70  stored by the PLC  26 A. When the PLC  26 A determines in block  88  that the future state is not beyond one or more of the limits  70 , the PLC  26 A executes (block  90 ) the instructions of the portion of the dynamic ride profile  62 A. However, when the PLC  26 A determines in block  88  that the estimated future state is beyond at least one of the stored limits  70 , the PLC  26 A disregards (block  92 ) the instructions and, in certain embodiments, additionally provides negative feedback to the dynamic ride profile server  22  that the instructions of the dynamic ride profile  62 A could not be executed. In response to received negative feedback, the dynamic ride profile server  22  may adjust future instructions in a subsequent dynamic ride profile  62 A generated for the ride vehicle  12 A to try to avoid reaching the limits  70 . 
     In an example, the disclosed dynamic control system  20  controls the driving/racing simulator amusement park ride  10 . During operation of the ride  10 , a virtual vehicle, corresponding to the ride vehicle  12 A, transitions from moving though lower viscosity or lower density medium (e.g., air) to moving through higher viscosity or higher density medium (e.g., water). In advance of the transition, the dynamic ride profile server  22  receives information about the upcoming transition as part of the game data  68  received from the game server  24 , and determines instructions for the dynamic ride profile  68 A at the transition by implementing a change in physics models  60  as the virtual vehicle switches virtual media. As a result of simulated enhanced drag after the transition, the ride vehicle  12 A may experience a sudden deceleration followed by drifting movements, buoyant/floating movements, and so forth, that are indicative of movement of the virtual vehicle through water in the virtual environment  15 , all within the bounds of the predefined limits  70 . 
     In another example, the disclosed dynamic control system  20  controls at least two ride vehicles (e.g., ride vehicle  12 A and  12 B) and the virtual vehicles that correspond to the ride vehicles can interact with one another in the driving/racing simulator amusement park ride  10 . For example, while the two physical vehicles are substantially prevented (e.g., based on the limits  70  stored by the PLCs  26 , based on physical barriers) from physically interacting with one another, the disclosed dynamic control system  20  can enable the corresponding virtual vehicles to interact with one another in the shared virtual environment  15 . For example, when one vehicle is positioned in front of another vehicle in the virtual environment  15 , the dynamic ride profile server  22  utilizes one of the stored physics models  60  to enable the generated dynamic ride profiles  62  to account for drafting effects induced on the trailing virtual vehicle by the lead virtual vehicle. In certain embodiments, one virtual vehicle can virtually collide with a second vehicle in the virtual environment, and the dynamic ride profile server  22  may utilize one of the stored physics models  60  that enables the generated dynamic ride profiles  62  to provide appropriate movement of the vehicles to correspond with this collision, while actual physical contact between the vehicles is prevented. Additionally, in certain embodiments, one virtual vehicle can virtually attack a second vehicle in the virtual environment (e.g., by launching a projectile attack/weapon), and the dynamic ride profile server  22  may utilize one of the stored physics models  60  that enables the generated dynamic ride profile to provide appropriate movement of the vehicles to correspond with the launch and/or contact of the projectile. Again, all of these generated dynamic ride profiles would be conditionally executed by the PLCs  26  of the ride vehicles  12  in accordance with the predefined limits  70  to ensure proper operation of the ride  10 . 
     While only certain features of the disclosure have been illustrated and described herein, many modifications and changes will occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the disclosure. It should be appreciated that any of the features illustrated or described with respect to the figures discussed above may be combined in any suitable manner. 
     The techniques presented and claimed herein are referenced and applied to material objects and concrete examples of a practical nature that demonstrably improve the present technical field and, as such, are not abstract, intangible or purely theoretical. Further, if any claims appended to the end of this specification contain one or more elements designated as “means for [perform]ing [a function] . . .” or “step for [perform]ing [a function] . . .”, it is intended that such elements are to be interpreted under 35 U.S.C. 112(f). However, for any claims containing elements designated in any other manner, it is intended that such elements are not to be interpreted under 35 U.S.C. 112(f).