Patent Description:
Since the early twentieth century, amusement parks (or theme parks) have substantially grown in popularity. With the rise in popularity, amusement parks may constantly undergo construction/maintenance as new attractions are implemented and existing attractions are updated. With the increasing sophistication and complexity of modern attractions, and the corresponding increase in expectations among amusement park patrons, improved systems and methods are needed to accommodate technological refreshes and/or updates, which may cause increased downtime of the attractions.

<CIT> describes a ride system including a first ride vehicle and a second ride vehicle positioned within a course and configured to travel within the course. The ride system also includes a control system having at least one controller and at least one position tracking system, where the at least one controller is configured to control movement of the first and second ride vehicles, and where the at least one position tracking system is configured to facilitate identification of a first location and a second location of the first and second ride vehicles, respectively, within the course. <CIT> describes an amusement park attraction having a dynamic ride vehicle for executing a sequence of distinct motion patterns. The ride vehicle includes a movable chassis and a body having a passenger seating area. A motion apparatus, including computer controlled actuators, imparts motion to the body along a plurality of axes independent of any motion of the chassis as it moves along a path in the amusement park attraction. As the vehicle travels along the path, articulation of the body and appropriate steering of the vehicle enables the vehicle to execute, in cooperation with the motion apparatus, a sequence of distinct motion patterns.

The invention provides a method according to claim <NUM> and an amusement park system according to claim <NUM>.

The present disclosure provides systems and methods to rapidly update (e.g., refresh) attractions and other entertainment features in amusement parks through facilitating modularity and separability of hardware components. Provided herein are system architectures that support such modularity and that facilitate interoperability between hardware components that perform different functions within an attraction, but whose operation may interrelate to one other. In certain embodiments, a system architecture of an amusement park may include a game layer, a software architecture (e.g., 'software') layer, and a hardware architecture (e.g., 'hardware') layer. The game layer may communicate logic of a particular game and/or ride attraction to the software layer, which in turn communicates the game logic to the hardware layer to implement the game logic via one or more hardware devices. That is, the software layer may utilize protocols in the form of application programming interfaces (APIs) and wrappers to effectively communicate the game logic to drivers of the hardware in the hardware layer. Due at least to the separation between the game layer, the software layer, and the hardware layer, the amusement park may update various portions (e.g., hardware and/or software components) of the architecture with minimal impact on the overall system of the amusement park.

To illustrate, a new hardware component may be implemented (e.g., plugged in) within an attraction of the amusement park. The hardware component may be an input device and/or an output peripheral device. When the new hardware component is implemented within the attraction, the hardware component may be automatically registered with the system such that the hardware component may generate and/or receive events (e.g., communicate with other components of the amusement park). Indeed, implementation of a hardware component may occur seamlessly, such as without a substantial overhaul of the existing attraction and/or without additional reconfiguration of the system by a technician. Once implemented and registered, the hardware component may be configured to react to a variety of stimulus messages, which may stem from the game logic of the game layer. Thus, the attraction may also implement new game logic and/or new software components while utilizing existing hardware. For example, a particular attraction may utilize a game surface and a plurality of other hardware devices, such as ride vehicles, virtual reality headsets, and so forth to implement a first game. Upon implementation of the new game logic and/or new software components, the same particular attraction may implement a second game utilizing the existing game surface and plurality of other hardware devices.

In one embodiment, certain hardware components may permit guest input that in turn impacts the operation of another hardware element within an attraction to cause a particular output (e.g., an input from a guest weapon may cause a fixed target to light up or otherwise indicate a successful hit). As technology improves, or as the attraction narrative becomes more complex, the attraction may be updated with new hardware components, such as new weapons hardware, which may entice guests to revisit the attraction. However, replacing the fixed elements, such as fixed targets, may be more costly, particularly if such targets include actuating components. Thus, certain hardware components (e.g., the fixed targets) may remain in place even when other hardware components (e.g., weapons) are replaced. Accordingly, in one embodiment and by way of example, the present techniques provide a system architecture that includes hardware wrappers or other communication protocols that permit new hardware components to communicate with existing hardware components without adjustments to the protocols in place and/or to the existing hardware components. In this manner, hardware components, such as weapons hardware, may be replaced. New weapons may be slotted into the system to communicate with existing fixed targets without updating or changing the existing system architecture and/or communication protocols.

The disclosed attraction systems and methods may be implemented with amusement park attractions including shows, rides, promotions, and so forth. By employing a modular architecture within the amusement park attractions, the attractions may easily and constantly be updated and refreshed as new technologies emerge. Accordingly, guests are incentivized to visit the amusement park and are further enabled to enjoy the thematic experience provided by the amusement park as attractions are frequently changed and updated.

With the foregoing in mind, <FIG> illustrates an embodiment of an amusement park <NUM>, which may include one or more attractions <NUM>. Each attraction <NUM> may accommodate a plurality of users <NUM> (e.g., guests, patrons). As discussed herein, the amusement park <NUM> may utilize a multi-layer system infrastructure to accommodate technological refreshes, updates, and so forth while minimizing downtime and impact of overall aesthetics and operations of the amusement park <NUM>. Particularly, modularity of the multi-layer system infrastructure may provide for a change (e.g., an update, a replacement, an addition, and/or a removal) of one or more hardware or software components without substantially affecting other elements (e.g., other hardware or software components) of the system.

To illustrate, in certain embodiments, the amusement park <NUM> may include a first attraction <NUM>, a second attraction <NUM>, and a third attraction <NUM>. However, it should be understood that the amusement park <NUM> may include any suitable number of attractions <NUM>. Each attraction <NUM> may include any suitable number of hardware components <NUM>, such as physical components that may interact (e.g., communicate) with software components <NUM>, which may be stored in a memory device <NUM> of one or more controllers <NUM> to perform tasks associated with a particular attraction <NUM>, as discussed in further detail herein. Indeed, there may be any suitable number of controllers <NUM>. In certain embodiments, each attraction <NUM> may be associated with a respective controller <NUM>. The amusement park <NUM> may further include one or more hardware components <NUM> within an environment <NUM> (e.g., queues) of the amusement park <NUM>, which may also be communicatively coupled to the one or more controllers <NUM>. In certain embodiments, the environment <NUM> may include the attractions <NUM>.

The controller <NUM> may employ a processor <NUM>, which may represent one or more processors, such as an application-specific processor. The controller <NUM> may also include the memory device <NUM> for storing instructions executable by the processor <NUM> to perform the methods and control actions of the amusement park <NUM> as described herein. The processor <NUM> may include one or more processing devices, and the memory <NUM> may include one or more tangible, non-transitory, machine-readable media. By way of example, such machine-readable media can include RAM, ROM, EPROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of machine-executable instructions or data structures and that may be accessed by the processor <NUM> or by any general purpose or special purpose computer or other machine with a processor.

The controller <NUM> may be communicatively coupled to elements of the amusement park <NUM> through a communication system <NUM>. In some embodiments, the communication system <NUM> may communicate through a wireless network, such as wireless local area networks [WLAN], wireless wide area networks [WWAN], near field communication [NFC], or Bluetooth. In some embodiments, the communication system <NUM> may communicate through a wired network such as local area networks [LAN], or wide area networks [WAN]. In some embodiments, the communication system <NUM> may communicate through lights/lasers, sounds, quantum mechanics, or other environmental stimuli.

Each hardware component <NUM> (e.g., peripheral device) may be categorized as an input device and/or an output device peripheral device. That is, each hardware component <NUM> may be an input device, an output device, or an input/output device. An input device may receive an input, such as from one of the plurality of users <NUM>, and send input signals indicative of the received input to the controller <NUM>. The hardware components <NUM> may include interactive components, and the input may be received via one or more user input devices (buttons, knobs, touchscreens, joysticks, actuatable elements, steering controls, triggers, etc.) of the interactive components. Correspondingly, and as a result of the input signals, the output devices may receive the input signals, which may be received from the controller <NUM> and/or directly from the input devices. For example, the controller <NUM> may then, in turn, send one or more signals to one or more locations, such as the output devices, within the amusement park <NUM> to provide an appropriate response according to the received input. The output devices may react accordingly to the signal, such as through actuation of a device or through display of images/information via a display device. For example, with regard to hardware components <NUM> of the first attraction <NUM>, input devices may include VR devices such as VR tools and VR googles, and output devices may include the VR goggles as images are displayed via the VR goggles. With regard to hardware components <NUM> of the second attraction <NUM>, input devices may include ride devices (e.g., tools) that the users <NUM> may interact with during a ride cycle and output devices may include animatronic show pieces and ride vehicles. With regard to the hardware components <NUM> of the third attraction <NUM>, input devices may include steering wheels and output devices may include a scoreboard, and a game floor display. However, it is to be understood that the amusement park <NUM> may include any suitable number of attractions <NUM> with any suitable number and type of hardware components <NUM>. Further, VR devices may serve as input/output devices that facilitate user interaction with the attraction <NUM> to generate the input and cause another hardware element to output a response. In turn, the response may also trigger output changes to the display of the VR devices. As used herein, VR may refer to augmented reality, virtual reality, mixed reality, or a combination thereof.

Each of the hardware components <NUM> and software components <NUM> may be replaced or updated based on various factors. For example, emerging technologies, movies or other media releases, seasonal change, time of day, routine maintenance, or any combination thereof may motivate a change to the hardware components <NUM> and/or software components <NUM> of the amusement park <NUM>. When a component (e.g., a hardware component <NUM> or a software component <NUM>) is introduced, updated, or otherwise changed within the amusement park <NUM>, the component may be registered with the amusement park <NUM> such that the component may interact (e.g., communicate) with other components of the amusement park <NUM>. That is, the one or more controllers <NUM> may include various protocols to send and receive information to and from components of the amusement park <NUM> as discussed in further detail with reference to <FIG>.

<FIG> is a block diagram of a system architecture of an amusement park system <NUM> of the amusement park <NUM>. The amusement park system <NUM> may be separated between a game layer <NUM>, a software layer <NUM> (e.g., a software architecture layer), and a hardware layer <NUM> (e.g., a hardware architecture layer). The game layer <NUM> and the software layer <NUM> may each be stored within the memory <NUM> of the controller <NUM>. The game layer <NUM> and the software layer <NUM> may be communicatively coupled to the hardware layer <NUM> via the communication system <NUM>. The game layer <NUM> may include a game logic <NUM>, which determines logic of when an attraction <NUM> interacts with, changes, and/or manipulates elements (e.g., hardware components <NUM> and/or software components <NUM>) of the attractions <NUM>. That is, the game layer <NUM> may operate and execute game logic <NUM>.

The software layer <NUM> may include one or more game application programming interfaces (APIs) <NUM>, one or more wrapper APIs <NUM>, and multiple wrappers <NUM>. The game API <NUM> may define an interface language set that any game implementation (e.g., game logic <NUM> of a particular attraction <NUM>) can use to communicate with the software layer <NUM> and the hardware layer <NUM>. For example, the game logic <NUM> may communicate with the game API <NUM> to trigger various environmental stimuli (e.g., reactions carried out through the hardware components <NUM>) within the amusement park <NUM>.

The wrapper API <NUM> may route messages from the game API <NUM> to the wrappers <NUM>. The wrappers <NUM> are software elements that conform, extend, and/or implement a standard interface class and are configured to register with the wrapper API <NUM> to receive the messages associated with the environmental stimuli. The wrappers <NUM> may communicate with a driver associated with a particular hardware component <NUM> so that the hardware component <NUM> may receive the messages associated with environmental stimuli. In certain embodiments, each hardware component <NUM> may be associated with one or more respective wrappers <NUM>. The wrappers <NUM> may serve as a buffer between the hardware components <NUM> of the hardware layer <NUM> and the software components <NUM> of the software layer <NUM>. For example, when the hardware components <NUM> are updated or changed, the change or update will not impact operations, logic, and/or builds of the software components <NUM>. Conversely, as software components <NUM> are updated, the wrappers <NUM> may reduce and/or prevent the need to update the hardware components <NUM> to be compatible with the updated software components <NUM>. In certain embodiments, additional hardware components <NUM> or features may be added. In such embodiments, one or more wrappers <NUM> associated with the newly added hardware components may also be added to the software layer <NUM>. The newly added wrappers <NUM> may then be registered with the wrapper API <NUM> to be able to receive stimulus signals (e.g., messages, events).

The hardware layer <NUM> may include the hardware components <NUM> which, as discussed herein, are configured to be easily replaceable and/or updatable. That is, the hardware components <NUM> may utilize a modular design (e.g., composed of standardized units), standard (e.g., universal) mounting points, and dynamic internal configurations to improve implementation of new hardware components <NUM> and updates to existing hardware components <NUM>. For example, the hardware components <NUM> may utilize a general purpose interface bus (GPIB) <NUM> (e.g., general purpose interface (GPI)), which may form part of the communication system <NUM>, to communicate with components within the software layer <NUM> and other hardware components <NUM> within the hardware layer <NUM>. Indeed, in certain embodiments, the hardware components may utilize a wired communications network. In another example, the hardware component <NUM> may utilize a wireless communications network as provided herein. In some embodiments, the hardware components <NUM> may communicate without the use of a network, such as by direct or broadcast communications through wired and/or wireless means. As a further example, the hardware components <NUM> may utilize and/or be a line replaceable unit (LRU) <NUM>, which is a modular component that is easily replaceable. Particularly, the LRU <NUM> may be quickly replaced at the attraction <NUM> (e.g., "on the line") which may provide for decreased downtime of the attraction <NUM>. Indeed, the hardware components <NUM> within the hardware layer <NUM> may utilize, for example, a limited number (e.g., one) of types of power supply, a limited number (e.g., one) of types of input and output modules, and a limited number of other components. In this manner, if a portion (or all) of a hardware component <NUM> should be added or changed, the portion may easily be implemented due at least in part to the standard (e.g., general, universal, modular) components. The modular design of the hardware components <NUM> may be based on standards, guidelines, and best practices to ensure correct implementation. In certain embodiments, the hardware components <NUM> may provide self-testing. That is, the hardware component <NUM> may determine if it is suitable to continue operation. For example, the hardware component <NUM> may include one or more sensors <NUM> configured to monitor inputs and outputs of the hardware component <NUM> to determine the operational status of the hardware component <NUM>, such as whether the hardware component <NUM> is operating as intended and/or if a part within the hardware component <NUM> should be replaced/updated, such as if the hardware component <NUM> is nearing an end of its product lifecycle.

By way of example, the hardware element <NUM> may be a weapon element of an attraction <NUM> within the amusement park <NUM>. One or more of the sensors <NUM> of the hardware element may detect the user input of a trigger actuation to cause the weapon to fire at a target. Based on the firing, other hardware components <NUM>, such as targets, may detect a successful hit or an unsuccessful hit. The input signal caused by the weapon firing and any target hits may be communicated via the software layer <NUM> to the game layer <NUM> to associate the successful hit with a particular user to in turn provide output signals back through the software architecture layer <NUM> to the hardware layer <NUM> to cause the target, for example, to light up or actuate. That is, the input of a user actuation of a weapon may cause an output of a target actuation. Certain attraction runs may include enhanced weapons with new capabilities, and the game logic may receive the actuation signals through the appropriate wrapper <NUM> to cause the target actuation. If an upgraded weapon has a blast or other enhanced capability, the game logic <NUM> may unlock new types of hardware components <NUM> that are typically stationary or may cause new movement scenarios for the targets. However, the absence of such enhanced features during normal game runs does not interfere with the ability to operate the attraction <NUM>. Further, the system <NUM> is capable of rapidly handling the incorporation of new hardware components <NUM> for special attraction runs along with a smooth return to normal operations. The software layer <NUM> facilitates the communication to and from the hardware components <NUM> such that the input signals are received in a plug and play manner by the game logic <NUM>.

<FIG> is a flow chart of a component implementation process <NUM> that may occur within the amusement park <NUM>. In some embodiments, implementation of a new component may be caused at least in part by one or more changing factors. As discussed herein, a new technology release/update, a particular time of year, movie/video game release, maintenance, and so forth may motivate amusement park personnel to change an attraction <NUM>. For example, a seasonal change, such as from fall to winter, may motivate a change from a Halloween-themed attraction <NUM> to a snow-themed attraction <NUM>.

In certain embodiments, the component implementation process <NUM> may start with removal of an existing (e.g., previously installed) component (block <NUM>). For example, if the new component being implemented is an animatronic show piece, an existing (e.g., previously installed) animatronic show piece may first be removed. When the existing component is removed, the amusement park system <NUM> may receive a signal indicative of the removal (or, based on a lack of a signal from the element, may update the system to indicate removal). To illustrate, before the occurrence of block <NUM> (e.g., before the existing animatronic show piece is removed), a show clock of the attraction <NUM> associated with the animatronic show piece may have been configured to schedule a stop of a ride vehicle adjacent to the animatronic show piece to enable viewing and/or interaction of riders with the animatronic show piece. However, upon removal of the animatronic show piece, the system may receive an input indicative of the removal, and the system may update the show clock to remove the scheduled stop of the ride vehicle adjacent to the former location of the animatronic show piece. In this manner, the interoperability of the various hardware components may be dynamically updated based on a change in ride configuration.

At block <NUM>, the new component may be implemented (e.g., installed, plugged in, uploaded). In certain embodiments, the component being implemented and the existing component may each utilize LRUs <NUM>, as discussed herein. Indeed, the new component may be easily implemented using the same connections as the existing component, thereby increasing an efficiency of the component implementation process <NUM>, and decreasing a downtime of the attraction <NUM> in which the component implementation process <NUM> is occurring. Moreover, in certain embodiments, the component implementation process <NUM> may start with the installation of the new component (block <NUM>). That is, it should be understood that it is not necessary for a component to be removed before a new component is installed. Indeed, the new component may simply be an addition to the amusement park <NUM>.

At block <NUM>, the new component may be registered (e.g., auto-configured) with the amusement park system <NUM>. When a new component is implemented (e.g., plugged in), the system may receive an indication that the new component is implemented and may know how to interact with the new component. That is, the new component and its associated functions (e.g., movement functions, display functions, special effect functions, etc.) may be registered with the system such that the new component and its associated functions may be utilized by the amusement park system <NUM>. In certain embodiments, the auto-configuration (e.g., the registration) performed at block <NUM> may be performed without user interaction with the amusement park system <NUM>. Indeed, once the component is implemented (block <NUM>), if the component is a hardware component <NUM>, the wrappers <NUM> may identify the hardware component <NUM> and its associated functions and may notify the amusement park system <NUM> that the hardware component <NUM> is implemented so that the amusement park system <NUM> may now utilize the hardware component <NUM> (block <NUM>). In some embodiments, registration (block <NUM>) of the functions of a hardware component may correspondingly register the component as an input peripheral device and/or as an output peripheral device. Similarly, if the component is a software component <NUM> (e.g., an operating system update), once installed, the amusement park system <NUM> may selectively utilize the software component <NUM> and its associated functions.

Overall, once a new component is registered, the component may generate and receive events (e.g., communicative signals). Particularly, the amusement park system <NUM> may communicate with the component to utilize the registered functions of the new component (block <NUM>). In certain embodiments, the new component may be registered utilizing an event router/manager. The event router/manager may receive events from the new component and deliver the events to other portions of the amusement park system <NUM>. Similarly, the event router/manager may receive events from portions of the amusement park system <NUM> and may communicate the event to the new component. In some embodiments, events may be assigned (e.g., communicated) utilizing a flag, which may be a predefined bit or bit sequence that holds a binary value to indicate the presence of an event. That is, one or more components of the amusement park system <NUM> may utilize a flag to communicate with other components within the amusement park system <NUM>. In one embodiment, a new hardware or software component may be registered as a type of a group of existing components.

In one example, a new hardware component <NUM> may be a holiday present structure that, at certain times of the day, lights up to indicate that prizes are available. The new component may be registered as a present and, when the system communicates via the wrappers <NUM> to all of the registered presents, all of the registered presents may light up. The presents may be distributed throughout the amusement park <NUM>, and the system may, in a modular manner, register a new present, and communicate to all of the components registered as presents to drive a common operation, such as a light up function, regardless of their location within the amusement park <NUM>. Further, the new hardware component may have additional functionality, such as an animatronic opening feature. The system <NUM> may send an activation signal to all of the presents, and, for the presents with enhanced functionality, the activation signal may also drive the operation of the animatronic opening feature as well as the light up feature. For presents without the enhanced functionality, the activation signal triggers the light up feature only.

<FIG> is a schematic view of a group of components <NUM> that may be included in one or more of the attractions <NUM> of <FIG>. The group of components <NUM> in the illustrated embodiment may include a variety of software components <NUM> and hardware components <NUM> that may be organized and communicatively coupled utilizing the hierarchical system architecture of the amusement park system <NUM> described in reference to <FIG>. In the illustrated embodiment, the group of components <NUM> may include a ride vehicle <NUM>, a steering wheel <NUM>, a game floor <NUM>, a special effects system <NUM>, an animatronic show piece <NUM>, a show clock <NUM>, and other components. In certain embodiments, each component of the attraction <NUM> may be associated with one or more software components <NUM> and one or more hardware components <NUM>. As discussed herein, components of the group of components <NUM> may be updated utilizing the methodology described in reference to <FIG>.

For example, the game floor <NUM> may be an interactive game floor (e.g., a hardware component <NUM>) capable of providing (e.g., displaying) a variety of games in response to one or more signals provided by one or more software components <NUM>. In certain embodiments, one or more software components <NUM> within the game layer <NUM> and/or the software layer <NUM> may be updated such that the game floor <NUM> may provide a new game. When a software component <NUM> associated with the display of the game floor <NUM> is updated, the game floor <NUM> may automatically start communicating (e.g., receiving/sending signal/events) with the new software component <NUM> to display the new game. In certain embodiments, implementation of a change in a software component <NUM> may include registration of new executable code. Similarly, in certain embodiments, the hardware components <NUM> of the game floor <NUM> may be updated. For example, the game floor <NUM> may be updated to include a new animatronic show piece <NUM> on the game floor <NUM>. Due at least in part to the structure and modularity of the amusement park system <NUM>, the animatronic show piece <NUM> may automatically start generating and receiving signals once implemented (e.g., plugged in) within the attraction <NUM>.

As a further example, the steering wheel <NUM> may be an input device which may provide directional control to the ride vehicle <NUM>. In certain embodiments, the steering wheel <NUM> may send one or more signals indicative of the direction that the ride vehicle <NUM> is being steered to the controller <NUM>. Based on the direction of the ride vehicle <NUM>, the controller <NUM> may implement various effects, such as redirecting the ride vehicle <NUM>, increasing or decreasing a score, and so forth. In a certain embodiment, the steering wheel <NUM> may be updated to account for a different type of game. For example, the game type may be updated from a simple driving game to a game with virtual tools, which may be utilized via user <NUM> interaction with input devices (e.g., buttons) located on the steering wheel <NUM>. In such embodiments, the original (e.g., old, existing) steering wheel <NUM> may be removed and replaced with the updated steering wheel <NUM> with the input devices. When the new steering wheel <NUM> is implemented (e.g., plugged in), the new steering wheel <NUM> may be registered with the amusement park system <NUM> and may generate and/or receive events henceforth.

Indeed, the events (e.g., signals) generated and/or received by the original steering wheel <NUM> may be different than the events (e.g., signals) generated and/or received by the new steering wheel <NUM>. For example, the original steering wheel <NUM> may be configured to receive direction signals (e.g., through user input) indicative of a driving direction of the ride vehicle <NUM>. Moreover, the new steering wheel <NUM> may be configured to generate multiple types of signals based on activation of the input devices (e.g., buttons, knobs, touch screens, etc.) included in the new steering wheel <NUM>. For example, beyond direction control, actuation of the input devices of the new steering wheel may generate special effect signals indicative of one or more special effects (e.g., light effects, vibration effects, mist effects, sound effects, etc.) of the special effects system <NUM>. When the new steering wheel <NUM> generates signals to activate the special effects based on user input, the controller <NUM> may receive the signals to actuate the respective special effects of the special effects system <NUM>. Further, as used herein, it should be noted that inputs provided by a user <NUM> to hardware components <NUM> (e.g., input peripheral devices) of the amusement park system <NUM> may include biometric inputs, which may include body/gesture tracking.

Moreover, in certain embodiments, the attraction <NUM> shown in <FIG> may be a path-based ride attraction <NUM> including one or more of the animatronic show pieces <NUM> that are configured to be actuated based on input (e.g., signals) provided by the show clock (e.g., a software component <NUM>) <NUM>. That is, the show clock <NUM> may be configured to provide signals to actuate the animatronic show pieces <NUM> such that the animatronic show pieces <NUM> are actuated, or perform a function, when one or more of the ride vehicles <NUM> are within a particular distance threshold from the animatronic show piece <NUM>. In other words, the show clock <NUM> may keep one or more schedules such that the animatronic show pieces <NUM> are scheduled to actuate when one of the ride vehicles <NUM> is within a particular range of the animatronic show piece <NUM>.

Additionally, the show clock may keep one or more schedules to actuate one or more effects of the ride vehicles <NUM> when the ride vehicles <NUM> are within the particular distance threshold of the animatronic show piece <NUM>. For example, the show clock <NUM> may be configured to cause the ride vehicle <NUM> to vibrate, stop movement, or cause the occurrence of another special effect of the special effect system <NUM> when the ride vehicle <NUM> is within the particular distance threshold. In certain embodiments, the show clock <NUM> may be updated based on one or more new components being implemented and registered with the amusement park system <NUM>. For example, in some embodiments, a particular animatronic show piece <NUM> may be removed from the attraction <NUM>. Upon removal of the particular animatronic show piece <NUM>, the amusement park system <NUM> may determine that the particular animatronic show piece <NUM> has been removed and the controller <NUM> may send a signal to the show clock <NUM> to update the schedule of the show clock <NUM> such that the ride vehicle <NUM> does not stop, vibrate, or incur a special effect when the ride vehicle <NUM> is within the particular distance threshold of the former location of the particular animatronic show piece <NUM>.

Still further, as discussed herein, a component, such as an animatronic show piece <NUM> may be replaced if the attraction <NUM> is to be updated. Particularly, an original animatronic show piece <NUM> (e.g., a hardware component <NUM>) may be replaced with an updated animatronic show piece <NUM>. In such embodiments, the original animatronic show piece <NUM> may be associated with a first set of functions and special effects, and the updated animatronic show piece <NUM> may be associated with a second set of functions and special effects. For example, the original animatronic show piece <NUM> may be capable of actuating one or more of a plurality of limbs and may eject water while the updated animatronic show piece <NUM> may be capable of one or more of a plurality of limbs, may emit certain light effects, may emit certain sound effects, and may eject steam. In certain embodiments, when the updated animatronic show piece <NUM> is implemented, the updated animatronic show piece <NUM> may utilize the same connections as the original animatronic show piece <NUM>. That is, as discussed herein, both the original animatronic show piece <NUM> and the updated animatronic show piece <NUM> may utilize LRUs <NUM>, standard mounting points, a modular design, and other features to increase an efficiency of replacing (e.g., updating) the original animatronic show piece <NUM>. When the updated animatronic show piece <NUM> replaces the original animatronic show piece <NUM>, the new animatronic show piece <NUM> may be registered with the amusement park system <NUM> such that the updated animatronic show piece <NUM> may generate and receive events (e.g., signals) to communicate with the amusement park system <NUM>. Once implemented and registered, the amusement park system <NUM> may receive a notification of the available functions of the updated animatronic show piece <NUM> and may be configured to activate (e.g., send events/signals via one or more of the wrappers <NUM>) the available functions of the updated animatronic show piece <NUM>. Further it should be noted that, in some embodiments, only one or more portions of the original component (e.g., original animatronic show piece <NUM>) may be updated (e.g., replaced) to update the original component.

It should be understood that while certain examples used herein discuss the use of particular hardware components <NUM> and software components <NUM> such as the ride vehicle <NUM>, the steering wheel <NUM>, the game floor <NUM>, the special effects system <NUM>, the animatronic show piece <NUM>, the show clock <NUM>, and so forth, the associated methodology, such as the component implementation process <NUM> (<FIG>) for changing or updating the components, may be applied to any other suitable component within the amusement park <NUM>. Generally, a change of a component (e.g., hardware component <NUM> and/or software component <NUM>) may register functions associated with the change of the component such that the amusement park system <NUM> may selectively drive the functions.

Claim 1:
A method, comprising:
removing a first hardware component (<NUM>) from at least one connection of an amusement park (<NUM>), wherein the first hardware component (<NUM>) is associated with a first set of functions;
providing, to a controller (<NUM>), a first indication of the first hardware component (<NUM>) being removed from the at least one connection;
implementing a second hardware component (<NUM>) of the amusement park (<NUM>) utilizing the at least one connection, wherein the second hardware component (<NUM>) is associated with a second set of functions, and wherein the first set of functions is different than the second set of functions;
providing, to the controller (<NUM>), a second indication of the second hardware component (<NUM>) being implemented utilizing the at least one connection; and
registering the second hardware component (<NUM>) with an amusement park system (<NUM>) of the amusement park (<NUM>) such that the second set of functions of the second hardware component (<NUM>) is configured to be selectively driven according to one or more clock signals from a show clock (<NUM>) of the amusement park (<NUM>).