U.S. Pat. No. 8,678,929

DETAILED DESCRIPTION OF THE INVENTION

A method for client side (local) prediction of one or more local game objects to reduce apparent network lag of multiplayer simulations for interactive games, such as networked video games and other applications, is described herein.

A simulation is a process wherein a game device, server or system determines new states for a game based on a prior state and player inputs. A state of a game might include where various players' characters are in a game space, a score, an inventory of game objects available to those characters, a camera location, positions/stances of characters or other game objects, etc. For example, if the frame is a soccer game, the game state might include positions of a ball and 22 players, a score, time left on the clock, etc. and in one simulation cycle, the game system considers that state and current user inputs for the current cycle to arrive at a new state for the current cycle. A display image can then be generated for the new state. A simulation cycle's period can coincide with an update rate of a display image, but this is not required. Where not all user inputs are available for a current simulation cycle, more than one simulation can be run and suitably blended in order to generate a current display image.

One simulation can be a network simulation that waits until all user inputs (or all necessary user inputs) are available for a given cycle. Of course, this may result (depending on network latency or delays) in the simulation running for a past cycle. In an embodiment of the present invention, one simulation is run for a current cycle with local user inputs (and possibly other user inputs, if available) and the simulation makes a guess, default, estimate and/or approximation of the unavailable user inputs, while another simulation (a network simulation) is run for a prior cycle where at least all simulations can be merged/blended to provide a display image for a current cycle, thereby providing a local player with an apparent reduction in network lag/delay. As network lag/delay goes down, the network simulation gets closer in time to the local simulation, and the merge/blend process should provide a smooth transition.

It should be understood that the invention is not limited to a particular type of game hardware, but might apply to consoles, computers, handheld devices, cell phones capable of playing games, and other hardware. Game consoles are made by several vendors, such as Microsoft's Xbox 360™ console, Sony's PS3™ console, and Nintendo's Wii™ console, the portable DS, Sony's portable PSP™ device, and Apple's portable iPhone™ device.

Typically, the play of a game depends on what input is provided, i.e., the game is interactive. An end user of an interactive or other game is often referred to as a “player”. That player is provided with user input devices to convey the player's inputs to an interactive video game. In one embodiment, a local player has authority over a local game object. The interactive video game also provides for outputs, such as a video display output and/or an audio output. Other outputs might also be present, such as a data transfer output (or input/output) for interacting with other game systems and/or storage and/or remote data systems, etc. It should be understood that the actual display is not required for embodiments of the present invention, but can be added to a game system when the player plays the game. For example, aspects of the invention might be embodied in instructions forming program code stored on computer-readable media programmed such that ordinary and/or readily available computers, computing devices, game consoles or other platforms can be provided with the program code and/or computer-readable media to provide the player with an interactive video game playing experience when coupled to a display or other output device.

In the description that follows, embodiments of systems and methods having aspects of the present invention will be described, in part, with reference to certain illustrated embodiments. These embodiments largely encompass examples of systems and methods suitable for allowing networked interactive applications to operate, such as a networked video game. However, the invention is not limited to any particular architecture, environment, application, or implementation. For example, although embodiments will be described in reference to gaming applications, the invention may encompass other applications and features including other applications where it will be beneficial to reduce the degrading effect of network lag. Moreover, embodiments will be described directed to a peer-to-peer networking topology. However, embodiments may include other network topologies, such as client-server topologies. Therefore, the description of the embodiments that follows should be construed for purposes of illustration and not limitation. Further details are provided in reference to the figures described below.

Two simulations, a local simulation and a network simulation, may run asynchronously for a single frame, each frame corresponding to a single time phase within the game. The local simulation and the network simulation can be run independently, and as such, the local simulation can provide a steady frame rate to the local user. As long as the network delay does not exceed a threshold, the local player should not notice any course-correction performed on game objects as they are rendered and displayed while the network lag varies. In a system with network lag, the local simulation operates in a present time frame, whereas the network simulation operates in a past time phase.

In order to determine the course-corrected positional values of the shared global objects, a two-way blending process may be performed. As used herein, “blending” may include interpolation, including linear and/or trajectory interpolation, where a weighted average of coordinates or trajectories are used to determine a new position. In a first blending step, the network simulation sends its calculation of a pose for the local player to the local console, which then blends the poses of the local character from the local simulation and the network simulation. A second level of blending may take place for shared global objects. Using the blended pose for the local player, a positional value for the shared global object is determined on the local console. This represents the expected location of the shared global object based on the blended position of the local player. The expected location of the shared global object is then blended with the positional values for the shared global object as determined by the network simulation. This blended position of the shared global object is finally rendered and displayed along with the local and remote players. By rendering and displaying the local game object as described herein, the local game player views the game frame as being responsive to the input commands in real-time, and by rendering the course-corrected shared global objects, the local simulation is blended to reality, i.e., to be more aligned with the network simulation. In another embodiment, the blended local game object may also be rendered and displayed.

FIG. 1is an exemplary process flow diagram100which illustrates one method of client side prediction of a local game object to reduce apparent network lag. The steps are labeled S1, S2, S3, but might be performed in an order other than the order of the labels. In one embodiment, the process flow100is performed on a local node connected to a peer-to-peer network. Flow100shows the process of generating multiple simulations of a frame within an interactive video game. In one embodiment, two distinct simulations are generated. A first simulation (“local simulation”) is generated in real-time, using a predicted state of a local game object for a present frame in the game play. The predicted state of the local game object is determined using a local player's input commands. After the simulation is performed, one or more shared global objects in the game are course-corrected in order to match the state of the shared global objects as determined by a network simulation. The state of the local game object (and possibly non local game objects) may be “predicted” in that some proxy is used for the as-yet unavailable remote user inputs, such as a guess, results of AI, extrapolation, etc. Even where the local game object is an object controlled by local user inputs, it might still depend on remote user inputs. For example, a local user input might direct a football player to run, but remote inputs might be such that a remote player's inputs caused the remote player's character to knock the local player's character down. Since these are two different states resulting in two different displays, the local simulation needs to decide on what the remote player's inputs might have been.

The frame is then rendered and displayed to the local player using the predicted state of the local game object and the one or more course-corrected shared global objects. From the vantage point of the local player, the local player's game object appears to be instantaneously responsive to the input commands, even within the context of networked game play. A second simulation (“network simulation”) is also performed for the same frame using state data, interaction data, and input commands of all the remote players within the game.

Some previous solutions have a simulator generating the network simulation on a local player's game console that waits for input command signals from the remote game consoles within the network before rendering the frame on the players' video displays. In those systems, the wait time causes a noticeable delay between rendering of frames during game play. In one embodiment of the present invention, the local simulation increases the gaming experience by diminishing the effects of network lag. The network simulation for a frame is not rendered or displayed to the game player. Instead, the network simulation for a previous frame (i.e., frame for a previous time phase) is generated and the state information for the local game object and the shared global objects is used to perform course-correction of the shared global objects. Thus, the local simulation enables real-time multiplayer gaming during networked game play and the network simulation enables the local simulation to render course-corrected objects which are corrected so as to be harmonized with the network simulation.

In step S1, a local simulation is run using the local player's input command that is generated for the present frame in the video game. An input command is any command provided by or determined from player input, such as: controller data from a player's interaction with a game controller, a command to spawn a new player, and X, Y, Z coordinates of a game object. The output of one portion of the simulation is a predicted state of the local game object for the present frame at t, where t denotes the present frame to be rendered and displayed at a current time. In another embodiment, the output is a predicted pose for the local game object. Various target poses may be created for a character, such as in keyframe animation, and intervening frames of animation can be generated to transition the character being animated from one pose to the next pose.

Traditional distributed peer-to-peer game play requires that each local node send the input signals of the local player to every other node in the network once those inputs commands are received. In step S2, a network simulation is run for a previous frame using the input commands from each node in the network. In one embodiment, the local player's input commands are supplied from a local pad. Delays in the network may cause the network simulation to run behind in time from the local simulation. Accordingly, the network simulation operates on a previous frame at t-n, where t denotes a current time and n denotes the network delay not including game latency. The output of the network simulation is a state or a pose for the networked game objects and the local game object(s) at t-n. In addition, the network simulation also provides a state or positional information for one or more shared global objects at t-n.

In step S3, course correction of one or more of the shared global objects is performed for the local simulation of the frame at t. Course-correction is used to smoothly move, over a series of ticks, an object from where the local simulation predicts it to be to where the network declares it to be. This may be accomplished by blending positional values of a locally simulated prediction of the shared global object at t with that of the network simulation at t-n. The output of course-correction is a blended state or positional information of the one or more shared global objects. As previously mentioned, “blending” may include interpolation, including linear and/or trajectory interpolation, where a weighted average of coordinates or trajectories are used to determine a new position.

For example, in the context of a soccer game, a local player may control a local game object(s) and remote players may control remote game objects. A shared global object, such as a soccer ball, may be controlled by any one of the local players or remote players. During networked game play, the soccer ball is course-corrected, such that the location of the ball that is rendered and displayed on the local player's display is the result of blending between the predicted location of the ball, as determined by the local simulation, and the location that is known to the network simulation. Course-correction is described in further detail inFIG. 2. Of course, these techniques can also apply to other sports games (i.e., American football, tennis, golf, racing, etc.) and non-sport games.

In step S4, the one or more course-corrected objects are rendered on a display of the local player. In addition, the predicted pose of the local object at t (as determined by the local simulation) and the poses for the networked game objects at t-n (as determined by the network simulation) are also rendered on the local display.

FIG. 2is an exemplary process flow diagram200that illustrates one method of course-correction between a network simulation and a local simulation. At step210, a predicted pose for the local game object(s) at t is determined by the local simulation. This predicted pose can be used in a two-step blending (i.e., interpolation) process for course-correction of the one or more shared global objects. At step220, the pose for the local game object(s) at t-n, the pose for the networked game object at t-n, and the state or positional values of the one or more shared global objects at t-n are determined by the network simulation. The pose for the local game object(s) and the state or positional values of the shared global objects can be used in the two-step blending process for course-correction of the shared global objects. Accordingly, at step230, the pose for the local game object(s) and the state or positional values of the shared global objects are sent to the local simulation to be used in course-correction. The pose for the networked game object may be used for rendering and displaying the frame to the local player.

Step240is the first of the two-step blending process for course-correction, in which the blended pose for the local object at t is determined. The blended pose can essentially be a combination or blend of the values of the predicted pose of the local object at t (as determined by the local simulation) and the actual pose of the local object at t-n (as determined by the network simulation). The blended pose can then be used to predict the state or positional values of the shared global object. At step250, a state or positional values of the shared global object is predicted based on the blended pose, which was determined at step240.

Step260is the second of the two-step blending process for course-correction, in which a blended state or positional values of the shared global object is determined. The blended shared global object represents the combination or blend of where the local simulation predicts the shared global object to be with where the network simulation dictates the shared global object to be. In particular, the shared global object at t-n is blended with the predicted state or positional values of the shared global object at t. Accordingly, the blended shared global object can be rendered as a course-corrected object. When blending is accomplished using the two-step process described herein, the local player perceives the local node to be operating in real-time during networked game play.

FIG. 3illustrates a game system300for providing course-correction for shared global objects. Game system300includes network simulator328, local simulator329, course-corrector332, and renderer317. In one embodiment, game system300is a local node connected to a peer-to-peer network. The game command flow might begin when power is first supplied to game system300, when it is reset or similar events. Program data of a game may be loaded. Thereafter, the game advances on the basis of the program data and player/user input provided by the game player via input devices. Input devices may include game controllers to convey the player's inputs to the interactive game for the present frame at time t to be simulated and displayed to the player.

The player input, such as to control movements of the local object of the interactive application, may be received by the local node. As used herein, player input is a broad term encompassing input provided by a player of the game. Local simulator329includes a local pad301, which stores a snapshot of the state of one or more objects that are controlled by the local player. The model described herein may be supported for any number of networked, local, and non-player characters. In the context of a soccer game, twenty-two game players may be present, any subset of which may be networked, local, or non-player characters.

The snapshot can be free of context. For example, the snapshot may include information that a left arrow button on the input device was depressed by the local player. In one embodiment, the local player's interaction with the control device is directed to exercise control over a local game object or character. Accordingly, the local pad may include a snapshot of the local game object(s) for the present frame in the game. The snapshot for the local game object(s) may be denoted as Local Pad 0 (t)302, where t indicates the present frame to be rendered and displayed at the current time, and 0 uniquely identifies the game object among a plurality of game objects. In one embodiment, input swapping techniques are employed to relay information and maintain synchrony between the local and remote consoles during networked game play. As such, a copy of the Local Pad302is sent to the Network Simulation328for processing and for swapping with the other nodes in the network.

Additionally, the Local Pad302is provided to a game artificial intelligence engine (game AI)303. The game AI303applies AI analysis on the networked game objects at t, based on the last known states of the networked game objects, to derive a guess about the states of the objects for a current frame. Using the Local Pad302and the states of the networked objects at t, the game AI determines high-level control parameters, such as context-dependent action requests307, for each of the game objects. Action requests may include information such as which joints in a skeletal representation of an object need to be moved and the direction of movement in order to carry out the player's input command Action requests resolve the question of whether a particular action is physically possible and contextually true. As shown, action requests are generated for each of game objects 0-21 at t. For example, suppose the context free pad information (i.e., left button depressed) is processed and transformed to context-dependent action requests (i.e., start running in a northerly direction at speed X). The action requests307are provided to a post update module312and a reaction controller315, which is described in further detail below.

The action requests are also provided to animation/physics engine308. Animation engine308might perform an actual physics simulation of game characters for which states for the present frame are known to the local game console. For example, the local console receives in real-time input commands for the Local object 0 (t), and performs a physical simulation on the Local object 0. Animation/physics engine308may also perform collision detection. The output of animation engine308is a client-side prediction of the local object, denoted Local Pose*0 (t)309, where * indicates a predicted value and “client-side” refers to a same system, software, and/or device that is local to the local player. Various target poses may be created for a character and intervening frames of animation can be generated to transition the character being animated from one pose to the next pose. It should be noted that only the state of the local game object need be predicted. The states of networked game objects need not be predicted, as is typically done in client-side prediction using dead reckoning.

Additionally, the action requests may be provided to animation/physics engine305. Animation engine305is functionally similar to animation engine308, except that animation engine305performs an actual physics simulation of game characters if the states/poses for the networked game objects are unknown or cannot be trusted if received from the network simulation. The output of animation engine305may be a client-side prediction of the remote objects, denoted Pose*1-21 (t)306. Although animation/physics engines305and308are depicted as separate units, the functions of both engines305and308may be performed by a single animation/physics engine.

In order to perform course-correction, network simulator328provides known position, state, or other information about the game objects to the course-corrector332. Using the information garnered from the local and network simulations, one or more shared global objects are course-corrected for the present frame prior to rendering and displaying a display of the present frame to the local player. Network simulator328includes a network interface320for receiving snapshot of state information from remote nodes and for receiving local game object information, such as Local Pad 0 (t)302, from the local simulation as input commands are received. In one embodiment, the network interface320includes a storage for the local and remote snapshot information. When the network delay is greater than zero, n>0, the network simulation operates on a previous frame t-n. Snapshots for the networked game objects, denoted as Local Pad 1-21 (t-n)321, are collected from the storage in the network interface320. A snapshot of the local game object, denoted Local Pad 0 (t-n)322, is also collected from the storage. The Local Pad 1-21 (t-n)321and the Local Pad 0 (t-n)322are provided to the game AI323. Using the Local Pad 1-21 (t-n)321and the Local Pad 0 (t-n)322, the game AI determines high-level control parameters, such as context-dependent action requests324, for each of the game objects.

The action requests are provided to animation/physics engine325. Animation engine325performs an actual physics simulation of all game characters 0-21. Animation/physics engine308may also perform collision detection. The output of engine325is an actual known network position or state of the objects 0-21. For example, the output may be a set of poses for the networked game objects, denoted Pose 1-21 (t-n)326, and a pose for the local object, denoted Local Pose 0 (t-n)327. The Local Pose327is provided to course-corrector332. The set of poses for the networked objects, Pose 1-21 (t-n)326, and the Local Pose327are provided to a post update module330, which performs various functions such as modifying poses for collisions, determining and modifying the state of shared global objects, and analyzing player pose information (i.e., speed, momentum, etc.) in preparation for the next animation update. The output of the post update module330is a state or positional value for one or more shared global objects, which can be fed back to the game AI323. In the context of a soccer game or other ball-oriented game, a shared global object may include a ball. Accordingly, the output provided by the post update module330includes a state of a ball, denoted Ball (t-n)331, which is provided to the course-corrector332.

Course-correction may then be performed, whereby one or more shared global objects are course-corrected for the present frame prior to rendering and displaying to the local player. The course-corrector332performs a two-level blending process. As previously mentioned, “blending” may include interpolation, including linear and/or trajectory interpolation, where a weighted average of coordinates or trajectories are used to determine a new position. In the first blend process311(which might be a software routine executed by a game device), the pose of the local object as determined by network simulator328is blended with the predicted pose as determined by local simulator329. In particular, the local pose 0 (t-n)327is blended with local pose*0 (t)309. The output of blend311is a blended pose of the local object at t, which is provided to a post update module312. Using the action requests 0-21 (t)327, Pose 1-21 (t-n)326, and the output of blend311, post update module312determines a predicted state or positional value for the one or more shared global objects, denoted Ball*(t)313. The output of post update module312is fed back in a loop to game AI303. This feedback loop maintains the synchronization of game states.

A second blend316may then be performed. As shown, the shared global object state for a previous frame, as determined by the network simulation, is blended with the predicted state of the global object, as determined by course-corrector332. In particular, Ball (t-n)331is blended with Ball*(t)313to produce a blended shared global object at t. Accordingly, blend316moves the predicted location of the Ball at t to be closer to the location where network simulator328declares the Ball to be at t-n.

The blend may occur over multiple updates such that the visual effect is that of a consistent convergence and course-correction to match the real (i.e., network) simulation game. Since the local simulation and the network simulation are separate, the local simulation can run as an illusion and provide a steady frame rate to the player. As long as the network simulation only falls behind by a threshold (i.e., a few frames), the blending is virtually unnoticeable by the player and gives the illusion that the local AI is updating instantaneously, for example, at 24 Hz, 30 Hz, 50 Hz or 60 Hz. This provides a lag-free online game experience. Thus, as the network simulation stays in synchronization with the real game, the local simulation runs at a constant frequency based on the local user's inputs.

In one embodiment, the two-step blending process, represented inFIG. 3by blend311and blend316, are controlled by a reaction controller315. The animation of a local game character at the local simulation is blended with the network simulation to create a visual result. The reaction controller315can dynamically change the blend weight, such that the amount by which the final position of the game object is determined by scaling the local simulation values and/or the network simulation values according its corresponding weight. The reaction controller315reads the current state of the local object. When the local object has a ball, or other shared global object, the local player may be controlled by mostly the local simulation. In one embodiment, the influence of the network simulation would cause a poor visual result for handling of the ball. The influence of the network simulation is required, however, to maintain the synchrony between the disparate simulations. For example, a weight of 60% of the local simulation-side can be used when the local player is dribbling a ball. In other words, 40% of the network simulation is used. In another embodiment, the local player does not have control of the shared global object, and another weighting scheme may be used. For example, when the local player loses a ball, the weight of the local simulation is gradually changed to 20%. This scheme observes the actions of the local player and the ball. In one embodiment, the reaction controller calculates the weight given the current states. In another embodiment, the blend weights between the network and the local simulations are determined by the amount of difference between the coordinates or trajectories of the objects. A difference that exceeds a large threshold may correlate with blend weights that move the local simulation more towards that of the network.

The present frame in the game may then be rendered. In one embodiment, the renderer317uses the blended shared global object (t) resulting from the two-step blend process, poses for the networked game objects 1-21 (t-n)326, and the predicted pose for the local object, Local Pose*(t)309, to render the present frame. Accordingly, pre-blend poses for the local and networked objects are rendered in the present frame. In another embodiment, blended poses for the local and/or any networked game objects may be rendered.

FIG. 4Aillustrates a positional error for a shared global object. Two simulations, a local simulation and a network simulation, may run asynchronously for a single frame. The network simulation requires the input commands from each and every remote player before running a simulation on a frame. Where network delay is apparent, the network simulation operates on a previous frame in the game, at t-n, where n is the network delay. An output of the network simulation includes a state of a shared global object. In the context of a soccer game, the shared global object may be a ball, and the output of the network simulation may include BallNetwork Sim(t-n)410.

Without waiting for input commands from all of the remote players, the local simulation makes a prediction about the location of the ball at the present frame in the game, i.e., Ball*Local Sim(t)420. The amount of error430between the location of the ball as known by the network simulation and the predicted location of ball is determined. The error430can then be course-corrected.

FIG. 4Billustrates a course-corrected shared global object. In one embodiment, BallNetwork Sim(t-n)460represents an output from a network simulation and Ball*Local Sim(t)470represents an output from a local simulation. The amount of error between the two simulations can be course-corrected, such that the local simulation is rendered with a global shared object that is locationally closer to the network simulation. Course-correction may include blending the ball at the network simulation with the ball at the local simulation, to produce a Blended BallLocal Sim(t)480. The Blended BallLocal Sim(t)480may then be rendered and displayed to the local player. The blending may be virtually unnoticeable by the player and gives the illusion that the local simulation is updating in real-time. This provides a lag-free online game experience.

FIG. 5illustrates a game command flow between components of a network simulator and a local simulator. A local and a network simulation are generated for each frame for game play. The local simulation provides a “real-time” gaming experience for the local game player. The local simulation may be generated for a frame using, for example, input packet 1 (501) for Frame 1506at time phase t1. Likewise, local simulations may be generated using input packet 2 (502) for Frame 2507, input packet 3 (503) for Frame 3508, and input packet 4 (504) for Frame 4509where t2, t3, and t4, respectively, represent increasing time phases. Moreover, the local simulation for a current time phase may also be generated using the outputs of the network simulation for a frame in a previous time. For example, the local simulations for Frame 1 (506), Frame 2 (507), and Frame 3 (508) are based on the input commands from input packet 1 (501), input packet 2 (502), and input packet 3 (503), respectively. The local simulations for the first three frames do not include results from the network simulation since network simulations are non-existent from t1thru t3. In this embodiment, the first network simulation does not appear until t4. Unlike previous Frames 1-3, Frame 4 (509) is generated using the results of the network simulation at Frame 1 (511) and the local player's input command, i.e., input packet 4 (504).

The network simulation in the game play is not rendered but enables course-correction to be performed on shared global objects in the game. The network simulation is generated based on network input, which may include an aggregation of state, interaction data, and input commands for every player within the network of game play for a frame. In one embodiment, network latency between t0and t2has caused a delay such that the network input commands are not received by the local node until t3where aggregate network input for Frame 1 (510) is received. The network simulation for Frame 1 (511) can then be generated at t4using the aggregate network input for Frame 1 (510).

FIG. 6illustrates a game system for providing one or more games for a user. System10is shown including one or more game media12(game A, game B, game C), a game device14, and a display16.

One or more game media12can include any game applications that may be used by game device14to involve a player in a game (and possibly also non-players who are also around). Each game medium12includes logic to provide a game, denoted as game A, game B, and game C. In one embodiment, the game provided by game device14is an electronic video game. Games are each individually stored on media, such as compact disk read-only memories (CDROMs), digital versatile disks (DVDs), game cartridges, or other storage media. A game, such as game A, is inserted in, coupled to, or in communication with game device14so that game device14may read all or part of a game application program code and/or related game data found on game media12.

Game device14is a computing device that includes a processor, such as a CPU, and data storage combined or in separate elements. Game device14may be connected to a network that allows game device14to provide games that are not included on one or more game media12. Thus, game A, game B, and game C may be accessed through the network and not be individually stored on game media12. To allow a user to select from a plurality of available games, a display16might present a list of the games provided by game applications on game media12. A game application may be also referred to as a game code and/or a game program. A game application should be understood to include software code that game device14uses to provide a game for a user to play. A game application might comprise software code that informs game device14of processor instructions to execute, but might also include data used in the playing of the game, such as data relating to constants, images and other data structures created by the game developer. A user interacts with the game application and game device14through user input/output (I/O) devices.

Display16is shown as separate hardware from game device14, but it should be understood that display16could be an integral part of game device14. It should also be understood that game media12could be an integral part of game device14. Game media12might also be remote from game device14, such as where game media is network storage that game device14accesses over a network connection to execute code stored on game media12or to download code from game media12.

FIG. 7illustrates a game device that might be used to implement a game system. It should be understood that other variations of game device14may be substituted for the examples explicitly presented herein and while the hardware might be essential to allow particular player interactivity, it is not essential to an implementation of the invention even if it is essential to the operation of it.

As shown, game device14includes a processing unit20that interacts with other components of game device14and also interacts with external components to game device14. A game media reader22is included that communicates with game media12. Game media reader22may be a CDROM or DVD unit that reads a CDROM, DVD, or any other reader that can receive and read data from game media12.

Game device14also includes various components for enabling input/output, such as an I/O32, a user I/O36, a display I/O38, and a network I/O40. I/O32interacts with a storage24and, through an interface device28, removable storage media26in order to provide storage for game device14. Processing unit20communicates through I/O32to store data, such as game state data and any data files. In addition to storage24and removable storage media26, game device14includes random access memory (RAM)34. RAM34may be used for data that is accessed frequently, such as game code when a game is being played. In one embodiment, the aggregate network input received by the local game system from the network may be persisted in any one or more of storage components, including memory or mass storage components.

User I/O36is used to send and receive commands between processing unit20and user devices, such as game controllers. Display I/O38provides input/output functions that are used to display images from the game being played. Network I/O40is used for input/output functions for a network. Network I/O40may be used if a game is being played on-line or being accessed on-line. Audio output41comprises software and/or hardware to interface to speakers (such as desktop speakers, speakers integrated in game device14, earphones, etc.). A game device might also have audio inputs (not shown).

Game device14also includes other features that may be used with a game, such as a clock42, flash memory44, read-only memory (ROM)46, and other components. An audio/video player48might be present to play a video sequence such as a movie. It should be understood that other components may be provided in game device14and that a person skilled in the art will appreciate other variations of game device14.

FIG. 8illustrates an example of game variable memory as might be used in the game device shown inFIG. 7. For example, a game code60, game variables62, game device data64, and other data66may be downloaded from game media12and stored in RAM34. It will be understood that a person of skill in the art will appreciate other data that may be stored in RAM34that will enable game device14to provide the game.

Game code60may be any logic that is found on game media12that is used to provide a game, such as program code comprising a plurality of computer instructions. As shown, game code60includes game logic70, library functions72, and file I/O functions74. Game logic70is used to provide any functions of the game. Library functions72include any functions that are used to support the game. File I/O functions74are used by processing unit20to perform input/output functions.

Game variables62are variables that are specific to a game and are used by processing unit20to provide variations of games for different users. The variables allow game device14to provide variations to the game based on actions by a user playing the game.

Game device data64is data specific to a game hardware that game code60is designed for. For example, different versions of game code60may be designed for different platforms supported by different game devices14. Data specifically needed to operate game code60on a specific platform for a specific game device14may be included in game device data64. Other data66may be any other data that is used with the game.

As a game found on game media12is played on game device14, data regarding the state of the game and any other related aspect of the game may be generated. The game state data is then stored in storage, such as storage24, removable storage media26, RAM34, or any other storage media accessible to game device14. The game state data may then be used at another time by game device14to provide a game that is in the same state as when a user last played the game and saved its state. For example, the game state data may include data that allows a user to continue at a same level that the user has completed, data related to certain achievements that the user has accomplished, etc. It should be noted that the game state data does not necessarily start the game at the same exact place as the place when the game was last stopped but rather may start the game at a certain level or time related to when the game was last stopped or its state was saved.

Game variables might include, for example, view variables, character variables, selection variables, etc. View variables might include, for example, a view point, a view direction (or angle), a view rotation (or orientation), a view extent, cursor location(s), etc. Character variables might include, for example, an array of values for each character active in the game, state data on each character (e.g., name, health level, strength, possessions, alliances, type of character, etc.). Selection variables might include, for example, an array of selected objects.

As used herein, “object” is used to generally refer to logical units of a virtual game space. Examples of objects are trees, characters, clouds, buildings, backgrounds, buttons, tables, lights, etc. Each of these objects might be positioned in a virtual game space, typically a three-dimensional (“3D”) space to emulate actual experience. Some objects are player-manipulable characters.