TRACK GENERATION

Abstract

Building a track for a computer game, including: enabling a player of the computer game to generate the track using a controller used to play the computer game, wherein the track is generated from a point of view of the player steering the controller; and laying out the track behind the player steering the controller.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a national phase application under 35 U.S.C. §371 of PCT/US2010/036927, filed on Jun. 1, 2010, entitled “Track Generation,” which claimed priority to U.S. Provisional Patent Application No. 61/182,885, filed Jun. 1, 2009. The disclosures of the above-referenced applications are incorporated herein by reference.

BACKGROUND

Computer entertainment game systems and gaming technology have advanced over the years from simple games such as Pong® and Tetris® to very complex shooter and sport games that have high speed, high resolution graphics and can be played in a multi-player environments. Increased sophistication of features has increased players' interest in the games as well as increasing the difficulty of playing the games. However, for racing games, selecting and driving a track from several pre-made tracks can be frustrating if the player is unable adapt to the “feel” of the terrain of the track.

DETAILED DESCRIPTION

Certain implementations as disclosed herein provide for methods and systems for building and editing a track and/or path (hereinafter referred to as a “track”) of a computer game. In one implementation, a player of the computer game generates the track (e.g., using track splines) by driving or steering a controller normally used to play the computer game. The track is generated from a point of view of the player using the controller. An alternative implementation includes a training simulation in which an expert driver/flyer drives or flies a track and a beginner driver/flyer tries to emulate the performance of the expert on the track laid out by the expert. Another alternative implementation includes a “follow-the-leader” challenge game in which a lead player performs certain maneuvers and dares the following player to repeat the maneuvers.

After reading this description it will become apparent how to implement the invention in various implementations and applications. However, although various implementations of the present invention will be described herein, it is understood that these implementations are presented by way of example only, and not limitation. As such, this detailed description of various implementations should not be construed to limit the scope or breadth of the present invention.

FIG. 1 is a flowchart 100 illustrating a method for building a track for a computer game in accordance with one implementation of the present invention. In this implementation, a player of the computer game is enabled to generate the track, at box 110, using a controller used to play the computer game. In one example shown in FIG. 2, the player is provided with a user interface window which enables the player to view and steer the controller to generate the track by maneuvering a vehicular game item (e.g., a kart).

In the illustrated implementation of FIG. 1, the track is then generated, at box 120, from the point of view of the vehicular game item being controlled by the player. FIG. 3 shows a top view of the track being laid out. Generating the track from the point of view of the vehicular game item results in the track (which includes at least turns, valleys, hills, and bridges) being laid out behind that vehicular game item, at box 130. The steepness of the turns, valleys, hills, and bridges are determined by the directional controls on the controller and the speed at which the player steers the game item around the turns, valleys, hills, and bridges. FIG. 4, FIG. 5, FIG. 6, and FIG. 7 show example shots of the player steering the vehicular game item around the turns, valleys, hills, and bridges. In one implementation, the track splines being laid down by the player is inexact, and thus, the track generation system calculates and completes the track.

In one implementation, the track generation system creates a terrain which conforms to the track being laid out. Thus, in this implementation, the terrain including the turns, valleys, hills, and bridges are generated dynamically in the track generation process. In another implementation, the track generation system creates a track which conforms to a pre-existing terrain. Thus, in this implementation, the track is being laid out on top of a pre-existing or pre-made terrain which may include turns, valleys, hills, and bridges. FIG. 8 shows a top view of a completed track with the terrain including turns, valleys, hills, and covered bridges.

In either the first pass (i.e., the track generation pass) or subsequent passes, the generated track and/or environment can be edited, at box 140, to change the track shape, the track surface parameters (e.g., texture, type of surface (dirt, concrete, ice, oil, etc.), and other track parameters. In one implementation, the edits can be made while driving the vehicular game item.

In one implementation of the track editing, the player can edit in small sections or modify large sections of the track with a move tool. The player can also scrub the track spline at a high speed to edit any area quickly and easily. Further, the terrain and section geometry dynamically adapts to changes in the track.

In another implementation of the track editing, track props are used to enhance a finished track. In one case, a player places props individually (i.e., one pickup) or in groups (i.e., a row of pickups). In another case, a player places animated props that include a “tweaker” which adjust animation parameters including animation speed, offsets, and trigger volumes. The tweaker can be placed anywhere on the track, with each animated prop having its own trigger volume.

In another implementation of the track editing, track sections (e.g., track runoffs, guard rails, vertical driving surfaces, etc.), which are “morphable” pieces of geometry, are placed alongside the track. Thus, the track sections placed around the track will morph to fit the shape of the track spline so that the sections can seamlessly blend with the terrain. The track sections can include marker points to allow the player to modify individual aspects of the sections. For example, a tree can be modified to a rock in a tropical section.

In one implementation, the game environment may be populated, at box 150, in either the first pass (i.e., the track generation pass) or the subsequent passes. The population of the game environment can be automatic (“auto population”) or manual. In populating the game environment, a theme may be set (e.g., beach, city, jungle, mountain, etc.) so that the game objects associated with the theme can be dropped into place as the player is driving to create the track. In one implementation, each theme features unique track surfaces, buildings, terrain, and skyboxes. Further, each of the themes can include sub-themes. The entire track and environment can be changed and fully re-populated upon switching from one theme to another theme.

Dynamic map calculation of the track generation system allows morphing and manipulation of the drop-in game objects to ensure the integrity of the track. Therefore, the population of the game environment accounts for road intersections and creates a smooth and substantially complete path to the finish. The auto population feature is configured to: (1) build world geometry around the track based on the selected theme; (2) add track sections; (3) add pickup items; (4) add boosts; and (5) enable a player of any skill level to build a fully finished track and environment. In one implementation, the finished track can be saved, shared, and/or sold to other players.

FIG. 9, FIG. 10, FIG. 11, and FIG. 12 show example builds of the world geometry or terrain around the track based on the selected theme. For example, FIG. 9 shows a small hill dropped in near the track. FIG. 10 shows another hill with rough terrain. FIG. 11 shows a flat terrain. FIG. 12 shows a small canyon having rough gorges.

FIG. 13 and FIG. 14 show further examples of drop-in terrain items. For example, FIG. 13 shows items such as trees and buildings placed in accordance with a selected theme. FIG. 14 shows another example of drop-in items such as sheep placed within the grounds of the track. FIG. 15 shows a top view of one example of the fully populated track.

In another implementation, the track generation system provides track templates so that the player can change the overall “feel” of the track without modifying the overall spline shape. Each theme can have several terrain variations with each terrain variation having a selection of track templates. Therefore, the track templates can be configured as saved tracks that the designer has created specifically for that terrain variation.

FIG. 16A and FIG. 16B form a flowchart 1600 illustrating a technique for providing track generation using an existing race track driving game in accordance with one implementation of the present invention. In the illustrated implementation, non-track generation functionalities are disabled from the driving engine, at box 1610. For example, the disabled non-track generation functionalities include jumping, drifting, and reverse functions. At box 1620, a pair of overlapping collision surfaces (i.e., first and second collision surfaces) is placed under a vehicular game item. In one implementation, an invisible first collision surface is placed under the vehicular game item, and a second invisible collision surface is placed just in front of the first collision surface, but overlapping the first collision surface. The physics system of the racing game interacts with these collisions surfaces (i.e., all driving is done on these surfaces).

Once it is determined, at decision box 1622, that the vehicular game item moved off the first collision surface, and is fully on the second collision surface, the first collision surface is moved ahead of the second collision surface, at box 1630, in the travel direction and orientation of the vehicular game item. This technique places the small collision surface to be always under the vehicular game item allowing the game item to drive in any direction. Additional inputs can be added to these collision surfaces to create hills and banks so that the vehicular game item can interact with these hills and banks. In one example, physics engines of the racing game can drive over the created hills by pitching the collision surface ahead of the vehicular game item up or down.

The position and orientation of the vehicular game item is then recorded at equidistance intervals, at box 1640, as trail points. In one implementation, the position and orientation is recorded as the vehicular game item drives around as if on a magic carpet. A smooth curve defining the center of the trail is generated, at box 1650, using the trail points, once a number of data points are collected. Additional splines can be lofted out from the center of the trail, at box 1660, to define the edges of the track. Once the track is completed, further analysis is done on the splines, at box 1670, to determine how to dress the splines with the appropriate art. For example, spline overlaps and tight corners are specially treated with specific care. Bridges are placed on the track where there are overlaps, and rumble strips are added to the inside of the corners. When it is determined, at box 1672, that the art is attached onto the track, the art is warped and wrapped onto the splines created earlier in the process, at box 1680, similar to wrapping a 3-D skin onto a character skeleton in a 3-D sports game.

In an alternative application, a track generation technique is used in a training simulation in which an expert driver/flyer (e.g., professional race car driver or fighter pilot) drives or flies a track/path and a beginner driver/flyer tries to emulate the performance of the expert on the track/path laid out by the expert. In another alternative application, a track generation technique is used in a “follow-the-leader” challenge game in which a lead player performs certain maneuvers and dares the following player to repeat the maneuvers. The difference between this follow-the-leader game and the simulation game is that in the simulation game the expert finishes the drive/fly before the beginner starts the emulated drive/fly. However, in the “follow-the-leader” game, the follower can emulate the leader by following the leader on the track/path generated immediately behind the leader (and in front of the follower). Other alternative applications include using the track generation technique for games such as a roller coaster game, a quest game, an adventure game, or other similar type of games.

There are several advantages to generating a track dynamically while driving a vehicular game item that would be normally used to play the game. One advantage is the realistic feel of the driving condition (e.g., steepness of the road, bank on the road, sharpness of the turn) of the track since it is generated while driving through the track. Another advantage is that the game can be more enjoyable by generating and modifying the track by driving or “feeling the road”. Yet another advantage is that the track can be built relatively fast by driving to generate it.

Various implementations of the invention are realized in electronic hardware, computer software, or combinations of these technologies. Some implementations include one or more computer programs executed by one or more computing devices. In general, the computing device includes one or more processors, one or more data-storage components (e.g., volatile or non-volatile memory modules and persistent optical and magnetic storage devices, such as hard and floppy disk drives, CD-ROM drives, and magnetic tape drives), one or more input devices (e.g., game controllers, mice and keyboards), and one or more output devices (e.g., display devices).

The computer programs include executable code that is usually stored in a persistent storage medium and then copied into memory at run-time. At least one processor executes the code by retrieving program instructions from memory in a prescribed order. When executing the program code, the computer receives data from the input and/or storage devices, performs operations on the data, and then delivers the resulting data to the output and/or storage devices.

Those of skill in the art will appreciate that the various illustrative modules and method steps described herein can be implemented as electronic hardware, software, firmware or combinations of the foregoing. To clearly illustrate this interchangeability of hardware and software, various illustrative modules and method steps have been described herein generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled persons can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the invention. In addition, the grouping of functions within a module or step is for ease of description. Specific functions can be moved from one module or step to another without departing from the invention.

Additionally, the steps of a method or technique described in connection with the implementations disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium including a network storage medium. An example storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can also reside in an ASIC.

Claims

1. A method for building a track for a computer game, the method comprising:

enabling a player of the computer game to generate the track using a controller used to play the computer game,

wherein the track is generated from a point of view of the player steering the controller; and

laying out the track behind the player steering the controller.

2. The method of claim 1, further comprising

selecting a theme of the computer game.

3. The method of claim 2, further comprising

populating an environment around the track based on the selected theme.

4. The method of claim 1, wherein laying out the track includes

forming at least turns, valleys, hills, and bridges on the tracks or path by steering the controller.

5. The method of claim 4, wherein steepness of the at least turns, valleys, hills, and bridges are determined by directional controls on the controller and the speed at which the player steers the controller around the at least turns, valley, hills, and bridges.

6. A game console comprising:

a game controller that inputs commands to the console to play a computer game;

a processor that:

enables a player of the computer game to generate a track for the computer game using the game controller,

wherein the track is generated from a point of view of the player steering the game controller; and

lays out the track behind the player steering the game controller.

7. A computer-readable storage medium storing a computer program for building a track for a computer game, the computer program comprising executable instructions that cause a computer to:

enable a player of the computer game to generate the track using a controller used to play the computer game,

wherein the track is generated from a point of view of the player steering the controller; and

lay out the track behind the player steering the controller.