A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. Copyright 2009, WMS Gaming, Inc.
Embodiments of the inventive subject matter relate generally to wagering game systems, and more particularly to devices and processes that control event-driven behavior of wagering game objects in wagering game systems and networks.
Wagering game machines, such as slot machines, video poker machines and the like, have been a cornerstone of the gaming industry for several years. Generally, the popularity of such machines depends on the likelihood (or perceived likelihood) of winning money at the machine and the intrinsic entertainment value of the machine relative to other available gaming options. Where the available gaming options include a number of competing wagering game machines and the expectation of winning at each machine is roughly the same (or believed to be the same), players are likely to be attracted to the most entertaining and exciting machines. Shrewd operators consequently strive to employ the most entertaining and exciting machines, features, and enhancements available because such machines attract frequent play and hence increase profitability to the operator. Therefore, there is a continuing need for wagering game machine manufacturers to continuously develop new games and gaming enhancements that will attract frequent play.
Embodiments are illustrated in the Figures of the accompanying drawings in which:
This description of the embodiments is divided into six sections. The first section provides an introduction to embodiments. The second section describes example operating environments while the third section describes example operations performed by some embodiments. The fourth section describes additional example operating environments while the fifth section describes additional example embodiments. The sixth section presents some general comments.
This section provides an introduction to some embodiments.
Wagering games are continuously becoming more interesting in their functionality. As a result, they are also becoming more complex. Characters and other displayed objects in wagering games have to interact with a host of other objects within the wagering game environment. This leads to increased challenges in controlling and managing the behaviors of the all the objects' movements and interactions within the wagering game. Some specific challenges include having to deal with more object interaction conflicts, more complex object functionality, more object path congestion, greater problems with object motion fluidity, etc. As a result, programmers are having to write longer and more complex programs and scripts to deal with these challenges, which requires more programming, updating, and maintenance time.
The behavior tree 103 can also include tasks that cause the fish 106 to respond to wagering game goals or objectives. For instance the coin 112 can be associated with a wagering game result. The wagering game server 150 can produce the wagering game result, either for the fish 106 to eat the coin 112 or not eat the coin 112 (e.g., nearly miss the coin 112, delay long enough for another fish to eat the coin 112, run away from the predator fish 108, 110 until the coin 112 disappears, etc.). The wagering game result can be a third event 124, that the system 100 indicates to the behavior tree 103. The behavior tree 103 can have a third task 111 that includes a response to the third event 124. For instance, if the third event 124 indicates a “win”, the third task 111 can include an instruction for the fish 106 to swim toward the coin 112 and eat the coin 112. However, because predator fish 108, 110 are in the path between the fish 106 and the coin 112, the behavior tree 103 also processes the first and second tasks 107, 109 according to the events caused by the predator fish 108, 110 as they pursue the fish 106 and/or as the fish 106 interacts with and evades the predator fish 108, 110. Consequently, the behavior tree 103 acts as a self-managing behavior controller, that moves up and down the tree structure of the behavior tree according to events within the wagering game and responses induced by the tasks (e.g., tasks 107, 109, 111, etc.) within the behavior tree 103. The tasks can move up levels of the tree structure as well as down levels, within the same level, as loops or repeating structures, etc. The behavior tree 103 can also include a starting place, such as a root node 105, for reference, or direction. In some embodiments, the behavior tree 103 can include specialized behavior controllers that that work within the behavior tree 103, such as schedulers, composite tasks, special tasks, conditions and actions, etc. The system 100 can work with other behavior controllers, (e.g., finite state machines, artificial neural networks, path finding layers, agents, etc.) that work external to, but in conjunction with, the behavior tree 103. In some embodiments, the system 100 can utilize a simulation of a Newtonian physics model, or “physics engine”, in conjunction with behavior controllers.
Although
This section describes example operating environments and networks and presents structural aspects of some embodiments. More specifically, this section includes discussion about wagering game system architectures.
The wagering game system architecture 200 can include the account server 270, which can be configured to control user related accounts accessible via wagering game networks and social networks. The account server 270 can store and track player information, such as identifying information (e.g., avatars, screen name, account identification numbers, etc.) or other information like financial account information, social contact information, etc. The account server 270 can contain accounts for social contacts referenced by the player account. The account server 270 can also provide auditing capabilities, according to regulatory rules, and track the performance of players, machines, and servers. The account server 270 can include an account controller 272 configured to control information for a player's account. The account server 270 also can include an account store 274 configured to store information for a player's account, such as player preferences regarding player character behaviors. The account server 270 can connect to the community server 280 via the communication network 222. A user can login to a social-network account on the community server 280 and configure user preferences regarding how a wagering game object can behave during a wagering game. The community server 234 can connect to an account on the account server 270, which can store both social-network account information and wagering game account information.
The wagering game system architecture 200 also can include the wagering game server 250 configured to control wagering game content and communicate wagering game information, account information, and behavior controller information to and from the wagering game machine 260. The wagering game server 250 can include a content controller 251 configured to manage and control content for the presentation of content on the wagering game machine 260. For example, the content controller 251 can generate game results (e.g., win/loss values), including win amounts, for games played on the wagering game machine 260. The content controller 251 can communicate the game results to the wagering game machine 260. The content controller 251 can also generate random numbers and provide them to the wagering game machine 260 so that the wagering game machine 260 can generate game results. The wagering game server 250 also can include a content store 252 configured to contain content to present on the wagering game machine 260. The wagering game server 250 also can include an account manager 253 configured to control information related to player accounts. For example, the account manager 253 can communicate wager amounts, game results amounts (e.g., win amounts), bonus game amounts, etc., to the account server 270. The wagering game server 250 also can include a communication unit 254 configured to communicate information to the wagering game machine 260 and to communicate with other systems, devices and networks. The wagering game server 250 also can include a behavior controller unit 255 configured to control behavior of wagering game objects within a wagering game. The behavior controller unit 255 can determine events from a wagering game and cause the wagering game objects to respond to the events. The behavior controller unit can utilize various behavior controllers assigned to the wagering game object so that the object can self-manage its own actions and responses in response to events within the wagering game, such as by using behavior trees. The wagering game server 250 also can include a simulations manager 256 configured to control simulations of a wagering game, sort, filter, and/or store the simulations into groupings, and use the simulations from the groupings in subsequent wagering games to animate a wagering game result. The simulations manager can work with self-managing, intelligent behavior controllers, such as behavior trees, to control behaviors within the wagering game.
The wagering game system architecture 200 also can include a wagering game machine 260 configured to present wagering games and receive and transmit information to control event-driven behavior of wagering game objects. The wagering game machine 260 can include a content controller 261 configured to manage and control content and presentation of content on the wagering game machine 260. The wagering game machine 260 also can include a content store 262 configured to contain content to present on the wagering game machine 260. The wagering game machine 260 also can include an event detector 263 configured to determine events that occur within a wagering game and report the events to the behavior controller unit 255, in the wagering game server 250. The behavior controller unit 255 can then generate behavior control information for wagering game objects and send the behavior control information to the wagering game machine 260, which the wagering game machine 260 can use to control the wagering game objects' responses to the events.
Each component shown in the wagering game system architecture 200 is shown as a separate and distinct element. However, some functions performed by one component could be performed by other components. For example, the server 250 can detect events that occur within a wagering game. Furthermore, the components shown may all be contained in one device, but some, or all, may be included in, or performed by multiple devices on the systems and networks 222, as in the configurations shown in
This section describes operations associated with some embodiments. In the discussion below, some flow diagrams are described with reference to block diagrams presented herein. However, in some embodiments, the operations can be performed by logic not described in the block diagrams.
In certain embodiments, the operations can be performed by executing instructions residing on machine-readable media (e.g., software), while in other embodiments, the operations can be performed by hardware and/or other logic (e.g., firmware). In some embodiments, the operations can be performed in series, while in other embodiments, one or more of the operations can be performed in parallel. Moreover, some embodiments can perform more or less than all the operations shown in any flow diagram.
The flow 300 continues at processing block 304, where the system determines a task on a behavior tree that has a response to the event. In some embodiments, many events may occur simultaneously. A wagering game object within the wagering game may detect the simultaneous events and need to respond to the simultaneous events. The system, therefore, may determine multiple behavioral tasks to process simultaneously. If the system detects simultaneous events that pertain to the same wagering game object, then the system can determine the priority of the events and process the tasks according to the priority. In determining the priority of the events, the system can consider various factors, such as the timing of the events, the severity of the events' impact on the wagering game object, possible interactions between the wagering game object and other objects, distances away from the wagering game object that the events occurs, the events' frequency of occurrence, a requirement to complete a wagering game outcome or goal within a specific time period, etc. To determine the priority of the events, the system can refer to event priority charts, refer to past scenarios involving the same events, run quick simulations showing possible object interactions, etc. One or more behavior trees may include the ability to determine priority of tasks. The system can then process the tasks according to the determined priority. For example, the system can process high priority tasks before processing low priority tasks. After processing high priority tasks, the system can re-evaluate low priority tasks to see if the lower priority events still need processing (e.g., the behavior tree(s) may process child tasks of the higher priority tasks, where the performance of the child tasks may eliminate the need to process the lower priority tasks). If there are conflicts between tasks, the system can resolve the conflicts by assigning priority scores, ranking the scores, then processing the tasks according to their priority score rankings.
The flow 300 continues at processing block 306, where the system activates (e.g., runs, executes, etc.) the task. The task causes the wagering game object to perform specific actions in response to the event. In some embodiments, the behavior tree includes a root node, which selects the particular task to run. A scheduler can execute the task, which in turn executes one or more child tasks, and so on, until completing the tasks. The behavior tree can then cause the wagering game object to function in an “idle” state in the absence of any events. A priority selector can prioritize and select tasks and sub-tasks.
The flow 300 continues at processing block 308, where the system determines whether a second event occurs during the performance of the first task's behavioral response. If another event does occur, the flow 300 can return to processing block 304 and determine another task that relates to the event. If there is a conflict between the performances of the two tasks, the system can prioritize, as mentioned previously. The same behavior tree can include tasks that cause the wagering game object to respond to the multiple events in the proper order. In some embodiments, the system can also utilize a second behavior tree to cause another object to respond to the subsequent event. For example, if the wagering object is at risk of being intercepted or interfered with, the second object can deter the interference. If, however, there are no additional events within the wagering game, the flow 300 can continue at processing block 310.
The flow 300 continues at processing block 310, where the system determines whether the first task requires one or more additional tasks to activate. For instance, a task can call additional tasks (e.g., sub-tasks, child-tasks, a task in another behavior tree, etc.). If there are any additional tasks, then the system can return to processing block 306 and activate the additional task(s). The system can prioritize and process the one or more additional tasks. If, however, there are no more tasks to execute, the flow 300 can end. The wagering game object can return to an idle state and await any additional events.
The flow 400 continues at processing block 404, where the system classifies the wagering game animation into a wagering game result grouping. For example, in
The flow 400 continues at processing block 406, where the system uses the wagering game animation in a wagering game. For example, in
Returning now to
Returning again to
The flow 600 continues, at processing block 608, where the system awards characteristics as a reward for wagering game play, and updates the behavior tree. For example, the system can award abilities (e.g., super speed), appearances (e.g., clothing, facial expressions), items (e.g., sunglasses, a metal detector, etc.) and so forth. The system can award the characteristics based on various factors, such as how much money a player has spent on a wagering game, what level a player has attained on a wagering game, a specific number of wagering game events, etc. The system can automatically assign the characteristics to the wagering game character by adding new branches to the behavior tree and/or enabling access to parts of the behavior tree that previously weren't available. In some embodiments, the system can instead present the obtained characteristics to the player via the graphical user interface (e.g., GUI 702 in
According to some embodiments, a wagering game system (“system”) can provide various example devices, operations, etc., to control event-driven behavior of wagering game objects. The following non-exhaustive list enumerates some possible embodiments.
This section describes example operating environments, systems and networks, and presents structural aspects of some embodiments.
The CPU 826 is also connected to an input/output (“I/O”) bus 822, which can include any suitable bus technologies, such as an AGTL+ frontside bus and a PCI backside bus. The I/O bus 822 is connected to a payout mechanism 808, primary display 810, secondary display 812, value input device 814, player input device 816, information reader 818, and storage unit 830. The player input device 816 can include the value input device 814 to the extent the player input device 816 is used to place wagers. The I/O bus 822 is also connected to an external system interface 824, which is connected to external systems 804 (e.g., wagering game networks). The external system interface 824 can include logic for exchanging information over wired and wireless networks (e.g., 802.11 g transceiver, Bluetooth transceiver, Ethernet transceiver, etc.)
The I/O bus 822 is also connected to a location unit 838. The location unit 838 can create player information that indicates the wagering game machine's location/movements in a casino. In some embodiments, the location unit 838 includes a global positioning system (GPS) receiver that can determine the wagering game machine's location using GPS satellites. In other embodiments, the location unit 838 can include a radio frequency identification (RFID) tag that can determine the wagering game machine's location using RFID readers positioned throughout a casino. Some embodiments can use GPS receiver and RFID tags in combination, while other embodiments can use other suitable methods for determining the wagering game machine's location. Although not shown in
In some embodiments, the wagering game machine 806 can include additional peripheral devices and/or more than one of each component shown in
In some embodiments, the wagering game machine 806 includes a behavior controller module 837. The behavior controller module 837 can process communications, commands, or other information, where the processing can control event-driven behavior of wagering game objects.
Furthermore, any component of the wagering game machine 806 can include hardware, firmware, and/or machine-readable media including instructions for performing the operations described herein.
The mobile wagering game machine 900 includes several input/output devices. In particular, the mobile wagering game machine 900 includes buttons 920, audio jack 908, speaker 914, display 916, biometric device 906, wireless transmission devices 912 and 924, microphone 918, and card reader 922. Additionally, the mobile wagering game machine can include tilt, orientation, ambient light, or other environmental sensors.
In some embodiments, the mobile wagering game machine 900 uses the biometric device 906 for authenticating players, whereas it uses the display 916 and speakers 914 for presenting wagering game results and other information (e.g., credits, progressive jackpots, etc.) The mobile wagering game machine 900 can also present audio through the audio jack 908 or through a wireless link such as Bluetooth.
In some embodiments, the wireless communication unit 912 can include infrared wireless communications technology for receiving wagering game content while docked in a wager gaming station. The wireless communication unit 924 can include an 802.11G transceiver for connecting to and exchanging information with wireless access points. The wireless communication unit 924 can include a Bluetooth transceiver for exchanging information with other Bluetooth enabled devices.
In some embodiments, the mobile wagering game machine 900 is constructed from damage resistant materials, such as polymer plastics. Portions of the mobile wagering game machine 900 can be constructed from non-porous plastics which exhibit antimicrobial qualities. Also, the mobile wagering game machine 900 can be liquid resistant for easy cleaning and sanitization.
In some embodiments, the mobile wagering game machine 900 can also include an input/output (“I/O”) port 930 for connecting directly to another device, such as to a peripheral device, a secondary mobile machine, etc. Furthermore, any component of the mobile wagering game machine 900 can include hardware, firmware, and/or machine-readable media including instructions for performing the operations described herein.
The described embodiments may be provided as a computer program product, or software, that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer system (or other electronic device(s)) to perform a process according to embodiments(s), whether presently described or not, because every conceivable variation is not enumerated herein. A machine readable medium includes any mechanism for storing or transmitting information in a form (e.g., software, processing application) readable by a machine (e.g., a computer). The machine-readable medium may include, but is not limited to, magnetic storage medium (e.g., floppy diskette); optical storage medium (e.g., CD-ROM); magneto-optical storage medium; read only memory (ROM); random access memory (RAM); erasable programmable memory (e.g., EPROM and EEPROM); flash memory; or other types of medium suitable for storing electronic instructions. In addition, embodiments may be embodied in an electrical, optical, acoustical or other form of propagated signal (e.g., carrier waves, infrared signals, digital signals, etc.), or wireline, wireless, or other communications medium.
This detailed description refers to specific examples in the drawings and illustrations. These examples are described in sufficient detail to enable those skilled in the art to practice the inventive subject matter. These examples also serve to illustrate how the inventive subject matter can be applied to various purposes or embodiments. Other embodiments are included within the inventive subject matter, as logical, mechanical, electrical, and other changes can be made to the example embodiments described herein. Features of various embodiments described herein, however essential to the example embodiments in which they are incorporated, do not limit the inventive subject matter as a whole, and any reference to the invention, its elements, operation, and application are not limiting as a whole, but serve only to define these example embodiments. This detailed description does not, therefore, limit embodiments, which are defined only by the appended claims. Each of the embodiments described herein are contemplated as falling within the inventive subject matter, which is set forth in the following claims.
Number | Name | Date | Kind |
---|---|---|---|
7125333 | Brosnan | Oct 2006 | B2 |
20050049029 | Gazdic et al. | Mar 2005 | A1 |
20090247254 | Schlottmann et al. | Oct 2009 | A1 |
Entry |
---|
Aigamedev.com, “behavior-trees-part2”, http://aigamedev.com/videos/behavior-trees-part22008—03—21 , 1-6 pages. |
Aigamedev.com, “bt-overview”, http://aigamedev.com/hierarchical-logic/bt-overview2008—03—21 , 1-5 pages. |
Aigamedev.com, “hierarchical-logic/decorator”, http://aigamedev.com/hierarchical-logic/decorator2008—03—21 , 1-7 pages. |
Aigamedev.com, “hierarchical-logic/parallel”, http://aigamedev.com/hierarchical-logic/parallel2008—03—21 , 1-7 pages. |
Aigamedev.com, “hierarchical-logic/selector”, http://aigamedev.com/hierarchical-logic/selector2008—03—21 , 1-6 pages. |
Aigamedev.com, “hierarchical-logic/sequence”, http://aigamedev.com/hierarchical-logic/sequence2008—03—21 , 1-6 pages. |
Aigamedev.com, “modular-behaviors/actions-conditions”, http://aigamedev.com/modular-behaviors/actions-conditions2008—03—21 , 1-7 pages. |
Aigamedev.com, “programming-tips/tasks”, http://aigamedev.com/programming-tips/tasks2008—03—21 , 1-5 pages. |
Champandard, Alex J. et al., “Behavior Trees for Next-Gen Game AI (Video, Part 1)”, AiGameDev.com http://aigamedev.com/videos/behavior-trees-part1 (Obtained Mar. 21, 2008). |
Champandard, Alex J. et al., “Behavior Trees for Next-Gen Game AI (Video, Part 3)”, AiGameDev.com http://aigamedev.com/videos/behavior-trees-part-3 (Obtained Mar. 21, 2008). |
Metanet Software, “N Tutorials—Broad-Phase Collision”, http://www.harveycartel.org/metanet/tutorials/tutorialB.html Mar. 21, 2008, 1-10 pages. |
Metanet Software, “N Tutorials—Collision Detection and Response”, http://www.harveycartel.org/metanet/tutorials/tutorialA.html Mar. 21, 2008 , 1-12 pages. |
Number | Date | Country | |
---|---|---|---|
20110021263 A1 | Jan 2011 | US |