The present invention relates to racing games, and more particularly, to a racing game system and method in which a player or players can experience animated video race simulations at different locations and wherein no two races are ever alike.
Video games provide social entertainment in arcades, restaurants and bars, for example. Casino-type games, such as video poker and draw-type video games, where there is a finishing order or draw, are types of video games that have become increasingly popular. Through improvements in animation, game processing and networking, it is now possible to watch animated races such as auto races, horse races, and dog races, for example, at several locations while optionally placing wagers on the animated event.
Prior and current systems offering such races typically create a series of animated races with a variety of outcomes, wherein the series is stored in a pool of animated races for random selection. When a particular race is randomly selected, the known race for each racing entity (e.g., car) and the known finishing order or draw is played out. As a result, such systems only offer a finite number of “canned” races, and the attentive patron can detect a “re-run” of such races by identifying the starting order or what happens in the early stages, for example. For many patrons, this can become boring. Further, to the extent wagering may be placed after the start of such a race, the alert patron may obtain an unfair advantage over other patrons seeing the race for the first time.
The present invention provides a new system and method for offering draw-type racing animation games. The present invention can use a randomly selected outcome and work backwards to the starting point of a race, while randomly selecting events for each racing entity at each backwards step, as well as randomly selecting camera views of the race. Each random event and camera view is stored so that, when the race has been completely run in reverse, the system of the present invention can then render and display the race in forward direction so as to display a unique race every time. In one embodiment, the present invention can provide such games over a network for simultaneous viewing in different locations. In another embodiment, the present invention can accept wagers from viewers for the animated events. In another embodiment, the present invention displays the race in real-time, and does not use streaming video.
It will thus be seen that the present invention provides a racing game and method which can provide a unique race every time.
It will further be seen that the present invention provides a racing game and method that avoids predictability.
It will also be seen that the present invention provides a gaming engine for configuring a race in reverse for forward display.
It will further be seen that the present invention provides an event and camera angle randomizer for contributing variety to a race having a predetermined outcome.
It will further be seen that the present invention provides a method wherein the selection of random events is repeatable.
It will also be seen that the present invention provides a method for running a race in reverse from a predetermined outcome.
Other features and advantages of the invention will become apparent from the following detailed description, and from the claims.
As shown in
It will be appreciated that system 10 can comprise the elements within host component 11 alone, or in combination with the networked terminals 22A and/or 22B and their associated displays. In one embodiment, host component 11 is maintained locally on site of an enterprise offering the racing game of the present invention, and can thereby allow for faster, real-time display of the produced video animation as described in more detail hereafter. One or more elements of host component 11 can be responsible for establishing a prize structure for races, which can establish and associate odds, expected number of winners and prize per winner with the number of successful matches for a given race. For example, if there are ten racing entities (e.g., cars) in a given race, the odds of successfully matching the order of the first three entities will be higher than the odds of successfully matching all ten racing entities. Accordingly, there will be fewer expected winners and a larger prize for matching all ten racing entities. A prize per winner, expected prize pool and expected prize payout can also be established and associated with a number of successful matches in connection with establishing a prize structure. Host component 11 can further be responsible for establishing any wager amounts, the time between draws, and the selection of variables which are configurable for each game.
As shown in
As shown in
As shown in
Sound manager component 32 controls the sound for each race rendered according to the present invention. Racer mesh manager component 33 manages racing entity mesh objects for each racing entity, and can accommodate any form of racer oriented game. In one embodiment of the invention, this component 33 creates a racer mesh object for each racing entity, and can add or remove racer mesh as the race proceeds. For example, if a fatal event occurs for a given car during a given race, all of the objects associated with the “crashed” car will be removed by the racer mesh manager component 33 so that they no longer appear in the scene displayed.
Path manager component 34 manages the creation and maintenance of pointers to each of the racer mesh object's spline path data. Each racer mesh object can be provided with an individual path and can be constructed using vertex data located in the track scene graph, for example. Path manager component 34 can generate a path for each racer mesh object from this vertex data and is also responsible for updating the state of each racer mesh object. In one embodiment of the invention, a spline object is responsible for the actual movement of the racing entities around the track as well as the collision detection with the track.
In one embodiment of the invention, path manager component functions to retrieve, for each racing entity, the current segment object and event object for a given race segment. Based on what event is to happen, the path manager component performs the necessary tasks to make that event occur, whether it is a “passing” event, a “falling back” event, or visual events, for example. If there is no event, or when the event has been completed, a default behavior can be implemented for each racing entity, whereby the racing entity follows the track by an in and out fashion for the turns and straight-aways. Once all of the racing entities have been processed as such, the path manager component can repeat the function for the next segment.
Camera manager component 35 creates and maintains a list of cameras for the scene graph. Each time the present invention requires a camera to render the scene, it will be requested of and presented by the camera manager component 35. Event manager component 36 manages the events and event data for each race in accordance with the present invention. At startup, the event manager component can load a list of base events from an “.xml” data file, for example. Then, event manager component maintains a list of event objects and creates the sequence of race events for each of the car objects by randomly selecting events for each segment of the race track.
In one embodiment, the event manager component 36 creates all of the segment objects for each racing entity. Then, considering the number of race segments for the race, random events for each racing entity are selected based on which events are appropriate for the given segment of the race for each racing entity. After each event has been selected, the order of the racing entities can be displayed on a leader board, and is adjusted to reflect any events affecting the positions of the racing entities as determined by the event manager component 36. In one embodiment of the invention, event information can be established and stored as event types (e.g., pass, fall back, clip, failed pass, spin, move inside, move outside, crash, backfire, spark, blowout, etc.), event categories (e.g., a position event, a fatal event, a visual event, etc.), event dependencies (e.g., event can only occur if an inside/outside move has occurred, etc.) and visual event types. Events can also be created such that they occur only on given track segments (e.g., turn, straight-away, introduction, final segment) or on any segment. Events can also be created such that they can occur multiple times for a given racing entity (e.g., passing or falling back) or only a single time (e.g., tire blowout).
Collision manager component 37 manages all of the collision detection in each race. This component 37 can add objects for collision detection, and responds to collision detections. In one embodiment of the present invention, collision manager component 37 can operate in connection with each frame of a given race. Animation manager component 38 manages the animation. It loads the animation files and is responsible for starting and stopping animations for each car or racing entity. In one embodiment, each animation for each car or racing entity is held in a “.kf” file.
The race manager component 31 can use known randomizer methods for determining a draw or finishing order from among any number of racing entities (e.g., cars, horses, dogs, etc.). For example, if there will be ten cars participating in a given race which is to extend for three laps around a track such as track 75 shown in
Once the draw is determined and stored, the gaming engine then begins to associate events, views, sounds and other features with the given race finish so that the finish image or video can be appropriately animated. For example, if the racing game of the present invention is provided with five separate camera views, the camera manager component 35 will use the initial data object as provided by the race manager component 31 to determine which of the five camera views will be provided for the race finish segment (i.e., video frames) of the given race. In an illustrative embodiment of the invention, the selection of the camera view is random and is determined by the initial data object. Similarly, the sound manager component 32 determines by random selection which of the available sounds for a given finish will be transmitted in association with the race finish segment. In one embodiment, the sound manager component 32 is influenced by the event manager component 36; thus, for example, if the event manager component determines that the race finish segment will include bumping of cars, the sound manager component 32 may be limited to a random selection of sounds associated with cars bumping. In another embodiment, as shown in
The event manager component 36 uses the initial data object 50 to determine events associated with given sections of the race. As shown in
The event manager component can provide as many or as few different events for each different racing entity as desired. In one embodiment, the present invention employs the event manager component to generate at least one event for each racing entity per track segment, for each lap associated with a given race. Thus, in a three-lap race over a track having eight sections, each racing entity will have twenty-four events randomly selected and associated with it. The event manager component 36 can build an event object 53 through available xml event data 54, and can also build a random number generator object 55 for use by the downstream components as shown in
As further shown in
As further shown in
The path manager component 34 then communicates with the collision manager component 37 and animation manager component 38 to build appropriate features which are consistent with the previously determined objects. Thus, after an event, camera view, ancillary event and/or appearance is determined for all racing entities for each segment, the animation manager can help build the animation for that segment involving all racing entities. The path manager component 34 can also build a leader board object, which allows viewers and/or participants to visually follow which racing entity is leading as well as the order of racing entities at each stage of the given race. The path manager component considers the events associated with each racing entity and the previous starting condition of each racing entity for the next segment. Because the race is initially constructed in reverse, the present invention considers future segment starting positions when determining positioning and event for previous segments, so that the race is fluid when eventually run in forward motion. Thus, the path manager component ensures that at the end of a given segment, a racing entity's path will match up with and/or align with the start of the path in the subsequent segment.
In one embodiment, the track path itself can comprise two spline curves, an inner curve, and an outer curve, wherein two adjacent points along a curve define a segment. The spline curves themselves can be interpolated such that the curve looks smooth everywhere and forms a circular pattern that passes through all points used. In one embodiment of the invention, the points chosen can come directly from the three-dimensional model of the track for both the inner and outer curves. The difference in height from a point on the inner curve to a point on the outer curve defines the roll for a car so that, on a banked corner, the racing entities (e.g., cars) will roll and follow the bank of the three-dimensional model. In an illustrative embodiment, in order to position a car along a point inside the two curves, three variables are determined—time, lateral offset and time offset. The time variable can be used as an input into the current event functions for each car to derive lateral offset and time offset. The time variable can also be used to position a reference point along the spline curve pair.
Using the reference point, the lateral offset can be used to move to the inside or the outside of the curve. The time offset can be used to move the point forward along the curve. The result can be a point somewhere in front of the reference point somewhere between the inside and outside of the curve. This is the current point used to compute the XYZ coordinates and HPR (heading, pitch, and roll) of the racing entity for the given time. In a preferred embodiment, the reference point always completes the race in a fixed amount of time, and all racing entities finish some amount of time before or equal to this point, thus guaranteeing race results in a fixed time.
It will be appreciated that all information relevant to the produced outcome is stored in database 18 for validation and authentication purposes of any wagering activity that may be accepted. Further, all of the sensory elements built in accordance with each stage or frame of the race are stored in database 18 as shown in
Once the race finish segment and associated elements have been entirely determined and stored, the present invention proceeds, via the race manager component, to determine elements for the next preceding segment from the finish segment, and these elements are also stored. This reverse processing continues until the given race is drawn back to the starting line.
Referring back to
Wagering engine 16 can also be provided as shown in
In one embodiment, terminals 24 can conduct cash or credit transactions in exchange for gaming tickets or printouts of a user's wager, and can redeem and validate issued and authenticated tickets. Wagers can be consistent with the real-life wagering associated with the given race (e.g., “win”, “place”, “show” bets, as well as quiniella, trifecta, exacta, and “box” bets). In one embodiment of the invention, the terminal can be programmed to establish, deduct from and add to one or more wagering accounts maintained with the retail establishment or gaming provider. The terminal can be manned by human personnel or can be a stand-alone, self-service kiosk.
In one embodiment, the present invention can employ industry gaming technology as is known in the art for the development and display of the game.
In this example, the present invention is generating a race involving four cars, with five appearance types, five event types and five camera angle types. The race is to proceed around a track three times, with the track divided into eight segments as shown, for example, in
From the point of the race finish, the present invention next considers how the segment just before the finish will appear. For instance, if Car 1 has been determined as the winner, and the finishing order of the four cars is Car 1, Car 3, Car 2, Car 4, then the segment before the finish can be randomized such that Car 2 was ahead of Car 3 for second place in the segment before the finish, and Car 4 bumps another car at the segment before the finish. For each car or racing entity, this method is applied for each segment beginning with the final segment and ending all the way back at the starting gate or starting line. In the process, each segment is adjusted as necessary for each car or racing entity such that the car or racing entity's position relative to the field is determined, as well as a randomly selected camera angle and randomly selected events or appearances affecting the car or racing entity.
Table 1 shows an example of the ordering of determination for various factors to be viewed in the playback. For example, in the “final segment” column, the present invention has determined the final ordering for four cars in the race, with each car having a randomly determined “appearance” as well as a randomly determined “event”.
Table 2 shows an example table of car “appearances”.
Table 3 shows an example table of car “events”.
In one embodiment of the invention, the random selection of the appearance and/or event factors is influenced by the desire to playback a realistic simulation; thus, the appearance or event factor may be restricted such that from any given frame to the frame previously before it, certain options are eliminated. For example, a car shown passing the remaining cars in segment N is not likely to have experienced a crash into the wall in segment N-1. Thus, the system of the present invention can adapt to remove certain options based on earlier determined events and/or appearances.
Table 4 shows an example listing of possible camera angles to be employed in connection with developing and rendering a given race in accordance with the present invention.
In one embodiment, the present invention does not provide different racing entity appearances, but rather provides randomly selected camera angles for each frame or racing segment. In a particular embodiment of the invention, camera angles stay on the screen for 5 second periods. It will be appreciated that many other appearance types, event type and camera angles can be applied beyond what is shown in the illustrative tables above. Such types and descriptions can be affected by the type of racing entity (e.g., horses, stock cars, Formula 1 racing cars, dragsters, dogs, etc.), as well as the length and complexity of the given race. Camera angles can be balanced throughout a given race, such that close-up action views and distant “field” views are properly balanced and patrons remain interested throughout the duration of the race.
When the present invention proceeds with playing the outcome, the full motion simulation appears as a forward running video as is known in the art. However, the camera views have been randomized, the car positioning has been randomized, the car “events” have been randomized, the car appearance has been randomized and the final ordering has been randomized, all in reverse. The playback can appear on multiple screens or displays at multiple locations at the same time; thus, the present invention can provide a simulcast of the race and thereby allow more wagering on each play.
An example playback in connection with a car race can occur as follows:
The game opens up displaying a green flag background with the race number and three-second countdown to the start. A flag wipes across the screen for two seconds to reveal start of the race. As the flag crosses the screen, the cars are revealed side by side (two per row) coming out of turn four approaching the start/finish line. At the same moment the green flag clears the screen, the engines power up and reach maximum volume, synchronizing with the first two cars crossing the start line. As the cars enter turn one, the car on the inside of the front row pulls ahead while the car on the outside of the front row moves in behind him.
Cars in the next row do a similar thing, while cars further back in the field stay basically side by side. As the cars exit turn two onto the backstretch, one or more cars begin passing further back in the pack. Entering turn three, a car goes high and gets passed, ending up at the back of the pack. Coming off turn four, the car in second place gets a good bite off the corner and pulls into the lead. Another pass or two occurs on the front stretch. Entering turn one, two cars in the middle of the pack bang into each other, bouncing off each other but maintaining position. Leaving turn two, one car gets loose and fishtails a little, causing him to lose a couple of positions. Again more passing occurs on the back stretch throughout the field. Cars run through turns three and four fairly cleanly, mostly single file with some cars staggered. Exiting turn four, a car near the front goes too wide and scrapes the wall, causing him to slow and lose several positions.
As the cars cross the start/finish line, the white flag is waved indicating the last lap. Approaching turn one, the second place car passes the first place car on the outside and reaches the corner first. In the middle of the field, an inside car clips the back end of a car on its outside and sends him high in the corner, causing him to lose several spots. Leaving turn two, a car near the front of the field begins smoking and falls all the way to the last place; the car continues to circle the track but at a reduced speed, clearly finishing in last place. Several passes take place on the back stretch with some cars passing each other only to be re-passed before turn three. Multiple cars bump and bang through turns three and four as the field tightens up for the last sprint to the finish. Exiting turn four, the three lead cars come off almost head to head, each edging forward on the last stretch before the finish. Just before the cars cross the finish line, the winner pulls ahead for the last time. As the winner crosses the finish line, a checkered flag appears from the area of the screen that the green flag disappeared into and sweeps across the screen (e.g., two seconds). As the checkered flag fills the screen, the scoring pole appears showing the final positions of all cars for, e.g., five seconds.
In such a race, the total time can be, for example, 45 seconds, with five seconds for start activities, seven seconds for finish activities, and three laps at eleven seconds each. Average time can also be approximately 2.5 seconds on each straightaway and approximately three seconds in each pair of turns.
It will thus be seen that the present invention can achieve purely random “uncanned” playback with no two races alike. Literally millions of outcomes and event combinations are available for rendering by the present invention. Accordingly, the present invention adds to the entertainment value, and removes any predictability of the outcome of the race based on early sensory impressions of the race. Further, the risk of associated wagering being tainted by users who have been exposed to the “canned” races of other systems is eliminated.
In one embodiment, the present invention can be incorporated as part of a display or wagering machine having other games or races thereon. In this way, the footprint of the physical embodiment of the device can be limited so that retailers can save space.
A method of rendering the racing game in accordance with one embodiment of the present invention is shown in
It will be apparent to one skilled in the art that any computer system that includes suitable programming means for operating in accordance with the disclosed methods also falls well within the scope of the present invention. Suitable programming means include any means for directing a computer system to execute the steps of the system and method of the invention, including for example, systems comprised of processing units and arithmetic-logic circuits coupled to computer memory, which systems have the capability of storing in computer memory, which computer memory includes electronic circuits configured to store data and program instructions, programmed steps of the method of the invention for execution by a processing unit. The invention also may be embodied in a computer program product, such as a diskette or other recording medium, for use with any suitable data processing system. The present invention can further run on a variety of platforms, including Microsoft Windows™, Linux™, or other platforms, for example.
The invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the claims of the application rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.