U.S. Pat. No. 9,616,342

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

This application describes example systems and methods that relate to a ghost feature of a video game. The video game may be played using a video game console, a hand-held gaming device, a personal digital assistant, a cellular phone, a pad-type or tablet-type computer, a notebook computer, a personal computer (e.g., a desktop computer) and the like. In one example implementation, each of one or more players controls a player character in response to inputs supplied to a respective input device. The input device may include one or more of buttons, keys, sliders, joysticks, cross-switches, triggers, analog pads, touch pads, touch screens, and the like and may also permit determination of aspects of motion, position and/or orientation through the use of one or more of cameras, accelerometers, gyro sensors, ultrasonic transducers, magnetometers and the like.

FIG. 1shows a non-limiting, example game system10in which the ghost feature described herein may be implemented. As shown inFIG. 1, example game system10includes a game console100, a television102and a controller107. WhileFIG. 1shows a video game console, the ghost feature described herein is in no way limited to this gaming environment and can also be implemented in video games running on hand-held gaming devices, personal digital assistants, cellular telephones, pad-type or tablet-type computers, notebook computers, personal computers and the like.

Game console100executes a game program(s) or other software application(s) stored on optical disc104, which is inserted into slot105formed in housing110thereof. The result of the execution of the game program or other application is displayed on display screen101of television102to which game console100is connected by cable106. Audio associated with the game program or other application is output via speakers109of television102. While an optical disk is shown inFIG. 1, the game program or other application may alternatively or additionally be stored in whole or part on other removable or non-removable, non-transitory storage media such as semiconductor memories, magneto-optical memories, magnetic memories and the like. The game program may also be stored on a server accessible to the game console100via a communication network (e.g., the internet).

Controller107is held in a player's hand and wirelessly transmits data such as game control data to the game console100. The game control data may be generated using an operation section of controller107having, for example, a plurality of operation buttons, a key, a stick and the like. Controller107may also wirelessly receive data transmitted from game console100. Any one of various wireless protocols such as Bluetooth (registered trademark) or WiFi may be used for the wireless transmissions between controller107and game console100.

A “nunchuk” controller125may be selectively connected to controller107. Although a wired connection is shown inFIG. 1between controller107and nunchuk controller125, alternatively, a wireless connection may be used. Nunchuk controller125may be held in the user's “other” hand (i.e., the hand not holding controller107) and provides additional game control data to video game console100.

Controller107also includes a camera (not shown) on a front end thereof for capturing images from light-emitting devices108aand108b. Although markers108aand108bare shown inFIG. 1as being above television102, they may also be positioned below television102. In addition, although the markers are shown as being separate from television102, the markers may also be built-into television102. In one implementation, a center point between light-emitting devices108aand108bis substantially aligned with a vertical center-line of display screen101. The images from light-emitting devices108aand108bcan be used to determine, for example, aspects of a direction in which controller107is pointing. Additional details of the imaging operation may be found in U.S. Patent Publication No. 2007-0066394 A1; U.S. Patent Publication No. 2007-0072674 A1; and U.S. Patent Publication No. 2007-0060228 A1. The entire contents of each of these applications are expressly incorporated by reference herein.

Controller107also preferably includes an accelerometer(s) and/or a gyro sensor(s). For example, controller107may include a three-axis, linear accelerometer that detects linear acceleration in three directions, e.g., the up/down direction, the left/right direction, and the forward/backward direction. Linear accelerometers are only capable of detecting acceleration along a straight line corresponding to each axis thereof. In other words, the direct output of the accelerometer is limited to signals indicative of linear acceleration (static or dynamic) along each of the axes thereof. As a result, the accelerometer cannot directly detect movement along a non-linear (e.g. arcuate) path, rotation, rotational movement, angular displacement, tilt, position, attitude or any other physical characteristic. However, through additional processing of the linear acceleration signals output from the accelerometer, additional information relating to controller107can be inferred or calculated (determined). For example, by detecting static, linear acceleration (i.e., gravity), the linear acceleration output of the accelerometer can be used to determine aspects of tilt of the controller relative to the gravity vector by correlating tilt angles with detected linear acceleration. In this way, the accelerometer can be used in combination with a processor (such as a processor of the video game console100) to determine aspects of, for example, roll, pitch, tilt, attitude or position of controller107. Similarly, aspects of various movements and/or positions of controller107can be calculated through processing of the linear acceleration signals generated by the accelerometer when controller107is subjected to dynamic accelerations by, for example, a user shaking or waving the controller.

Gyro sensors can be used in addition to, or in place of, the acceleration sensor for determining, for example, aspects of movement, tilt, etc. of the controller.

With reference to the block diagram ofFIG. 2, game console100includes a RISC central processing unit (CPU)204for executing various types of software applications including (but not limited to) video game programs. CPU204executes a boot program stored, for example, in a boot ROM to initialize game console100. CPU204can also execute a software application (or applications) stored on optical disc104, which is inserted in optical disk drive208, or stored in some other memory accessible to CPU204. User-accessible eject button210provided on housing110of game console100may be used to eject an optical disk from optical disk drive208.

CPU204is connected to system LSI202that includes graphics processing unit (GPU)216with an associated graphics memory220, audio digital signal processor (DSP)218, internal main memory222and input/output (IO) processor224.

IO processor224of system LSI202is connected to one or more USB ports226, one or more standard memory card slots (connectors)228, WiFi module230, flash memory232and wireless controller module240.

USB ports226are used to connect a wide variety of external devices to game console100. These devices include by way of example without limitation game controllers, keyboards, storage devices such as external hard-disk drives, printers, speakers, microphones, digital cameras, and the like. USB ports226may also be used for wired network (e.g., LAN) connections. In one example implementation, two USB ports226are provided.

Standard memory card slots (connectors)228are adapted to receive industry-standard-type memory cards (e.g., SD memory cards). In one example implementation, one memory card slot228is provided. These memory cards are generally used as data carriers but of course this use is provided by way of illustration, not limitation. For example, a player may store game data (including ghost data as described below) for a particular game on a memory card and bring the memory card to a friend's house to play the game on the friend's game console. The memory cards may also be used to transfer data between the game console and personal computers, digital cameras, and the like. Content such as video, photos and music contained on memory cards inserted into slot228may be accessed via the user interface of the console for output, for example, using the display screen101and speakers109of television102.

WiFi module230enables game console100to be connected to a wireless access point. The access point may provide internet connectivity for on-line gaming with players at other locations (with or without voice chat capabilities), as well as web browsing, e-mail, social networking, software downloads (including downloads of game software and other applications) and many other types of on-line activities. In some implementations, WiFi module230may also be used for communication with other game devices such as suitably-equipped hand-held game devices. Module230is referred to herein as “WiFi”, which is generally a designation used in connection with the family of IEEE 802.11 specifications (e.g., 802.11, 802.11a, 802.11b, 802.11g, 802.11n, etc.). Game console100may of course alternatively or additionally use wireless modules that conform to other wireless standards.

Flash memory232stores, by way of example without limitation, game save data, ghost data, system files, internal applications for the console and downloaded data (such as application programs including game programs).

Wireless controller module240receives signals wirelessly transmitted from one or more controllers107and provides these received signals to IO processor224. The signals transmitted by controller107to wireless controller module240may include signals generated by controller107itself (e.g., button press data, accelerometer data, gyroscope data, etc.) as well as signals generated by other devices such as nunchuk controller125that may be connected to controller107. Of course, in other implementations, nunchuk controller125may directly communicate signals to wireless controller module240of console100. As mentioned above, the communications may use the Bluetooth protocol.

Wireless controller module240may also wirelessly transmit signals to controller107. By way of example without limitation, controller107(and/or another game controller such as nunchuk controller125connected thereto) may be provided with vibration circuitry and vibration circuitry control signals may be sent via wireless controller module240to control the vibration circuitry (e.g., by turning the vibration circuitry on and off). By way of further example without limitation, controller107may be provided with (or be connected to) a speaker (not shown) and audio signals for output from this speaker may be wirelessly communicated to controller107via wireless controller module240. By way of still further example without limitation, controller107may be provided with (or be connected to) a display device (not shown) and display signals for output from this display device may be wirelessly communicated to controller107via wireless controller module240. It will be appreciated that wireless controller module240can communicate signals to nunchuk125either directly or via controller107.

Proprietary memory card slots246are adapted to receive proprietary memory cards. In one example implementation, two such slots are provided. These proprietary memory cards have some non-standard feature(s) such as a non-standard connector and/or a non-standard memory architecture. For example, one or more of the memory card slots246may be adapted to receive memory cards used with a different gaming platform. In this case, memory cards inserted in such slots can transfer data from games developed for this other gaming platform.

One or more controller connectors244are adapted for wired connection to respective game controllers. In one example implementation, four such connectors are provided for wired connection to game controllers. Such game controllers may be for another gaming platform. Alternatively, respective wireless receivers may be connected to connectors244to receive signals from wireless game controllers.

A connector248is provided for connecting game console100to DC power derived, for example, from an ordinary wall outlet. Of course, the power may be derived from one or more batteries.

GPU216performs image processing based on instructions from CPU204. GPU216includes, for example, circuitry for performing calculations necessary for displaying three-dimensional (3D) graphics. GPU216performs image processing using graphics memory220dedicated for image processing and a part of internal main memory222. GPU216generates image data for output to television102by audio/video connector214via audio/video IC (interface)212.

Audio DSP218performs audio processing based on instructions from CPU204. The audio generated by audio DSP218is output to television102by audio/video connector214via audio/video IC212.

External main memory206and internal main memory222are storage areas directly accessible by CPU204. For example, these memories can store application programs such as game programs or other software applications, applets, scripts, etc. read from optical disc104by the CPU204, game program or other software applications, applets, scripts, etc. read from flash memory232by CPU204, various types of data and the like.

ROM/RTC238includes a real-time clock and is preferably powered by an internal battery (not shown) so as to be usable even if no external power is supplied. ROM/RTC238also may include a boot ROM and SRAM usable by the console.

Power button242is used to power game console100on and off. In one example implementation, power button242must be depressed for a specified time (e.g., one or two seconds) to turn the console off so as to reduce the possibility of inadvertently turn-off. Reset button244is used to reset (re-boot) game console100.

With reference toFIG. 3, example controller107includes a housing301on which operating controls302a-302hare provided. Housing301has a generally parallelepiped shape and is sized to be conveniently grasped by a player's hand. Cross-switch302ais provided at the center of a forward part of a top surface of the housing301. By actuating cross-switch302a(e.g., up, down, left, right), the player can, for example, move a player character in different directions in a virtual game world.

Buttons (or keys)302bthrough302gare provided rearward of cross-switch302aon the top surface of housing301. Buttons302bthrough302gare operation devices that output respective signals when a player presses them. Generally, buttons302bthrough302gare assigned various functions in accordance with the application being executed by game console100. Button302his a power switch for remote on-off switching of the power to game console100.

A plurality (e.g., four) of LEDs304is provided rearward of button302con the top surface of housing301. Controller107is assigned a controller type (number) so as to be distinguishable from other controllers used with game console100and LEDs304may be used to provide a player a visual indication of this assigned controller number.

Program instructions for the video game may be encoded onto an optical disk104(i.e., a non-transitory computer readable medium), which is inserted in optical disk drive208of game console100. Alternatively, the program instructions may be downloaded to game console100(e.g., via a wired or wireless connection to the internet) and stored in on-board memory, such as flash memory232. In either case, these program instructions are executed by CPU204, and GPU216performs image processing based on instructions from CPU204. Images resulting from the image processing are displayed on television102. Audio DSP218performs audio processing for the game based on instructions from CPU204. Audio resulting from the audio processing is output via speakers109of television102.

The example systems and methods described herein involve so-called “ghost data.” In racing-type video games, it is known to store ghost data indicative of a player character's racing performance in a race. The same or a different player character can then race against a ghost character in a subsequent race, the performance of the ghost character in the subsequent race being based on the ghost data stored in the prior race. For example, in the Mario Kart 64 video game, the game program captures ghost data as a player character's vehicle races around the track, recording vehicle location information at various points during the race. Once the race is complete, the player can choose to race on the track again and compete against a “ghost” car whose position during the race is determined by the ghost data stored during the previous race.

In the example systems and methods involving the ghost feature described herein, CPU204executes a video game program stored, for example, on optical disc104or in flash memory232and loaded into main memory206and/or222. The execution of the video game program generates a three-dimensional (3D) virtual game world within which player characters can move based on, for example, inputs to controller(s)107by respective game players. One or more virtual cameras are positioned in the virtual game world and images virtually “captured” by these cameras are displayed on television102. Sounds in the virtual world are output via speakers109associated with television102.

Generally speaking, each game player is assigned to or chooses a particular player character to control during game play. Thus, game player1controls player character1, game player2controls player character2, etc. The appearance characteristics of player characters during game play are generally determined by the video game program. In some instances, the video game program includes instructions for permitting a player to designate or customize certain aspects of the player character appearance. These aspects may include, but are not limited to, facial characteristics, hair style and color, and the like.

Each game player typically uses his/her own controller107to control a corresponding player character. Such control includes, by way of example and without limitation, movements and actions of a player character within the game world. In the example video game program executed by game system10, a player character moves in a free-roaming manner (e.g., not confined to movement along some predetermined track or path such as a race track) in the 3D virtual game world according to inputs supplied via controller107.

As part of a game set-up process, a game player may choose (e.g., by a menu selection) for game system10to periodically store ghost data for a player character. In other example implementations, ghost data may be stored during game play for multiple player characters. This ghost data may be stored during execution of the video game program in a game session every frame, every x frames, x times per second (e.g., 30 times per second) or at some other periodic interval. The interval may be constant throughout the video game or may vary as the video game is played (e.g., every frame for some parts of the video game and every other frame for other parts of the video game). In alternative implementations, the video game program may automatically store ghost data periodically during game play and generate a display (e.g., on television102) at the end of game play requesting player input as to whether the ghost data should be saved for use in a subsequent game session. The player may also be given an opportunity designate a location for storing the ghost data (e.g., in local on-board memory, on a memory card and/or on a server).

As discussed, the ghost data is used to generate a ghost character which appears during a subsequent game play session. Various types of data may be stored to generate the ghost character and control its behavior (e.g., movement and/or actions) during the subsequent game play session.

By way of example and without limitation, position data indicative of the player character's position in the 3D virtual game world over time may be stored periodically. This position data may include coordinate data (e.g., x, y, z coordinates) with respect to a world system of coordinates.FIG. 4shows an illustrative two-dimensional path404of a player character406that moved from A to B in a portion402of a virtual game world during a particular game play session. Position data is periodically stored as the player character moves along this path in response to game player inputs via controller107. In a non-limiting example implementation, the position data is stored for every frame so that the ghost data for player character406includes position data as follows:

TABLE IFrame NumberPosition1 (at Point A)(x1, y1)2(x2, y2)3(x3, y3). . .. . .N (at Point B)(xn, yn)

It will be appreciated that the position data can be readily extended to three-dimensions by including z-coordinate values. Using this position data, a corresponding ghost character can be controlled to move along the same path404during a subsequent game play session.

In addition to or as an alternative to storing position data, inputs to the controller107can be stored. With reference toFIG. 3, inputs (e.g., up, down, left, right) to cross-switch302afor moving a player character in the 3D virtual game world (e.g., along path404) can be stored periodically. In a non-limiting example implementation, the inputs are stored for every frame so that the ghost data for player character406includes example input data as follows:

TABLE IIFrame NumberInput1 (at Point A)Cross-switch RIGHT2Cross-switch RIGHT3Cross-switch UP. . .. . .N (at Point B)Cross-Switch RIGHT
Using these stored cross-switch inputs, a corresponding ghost character can be controlled to move along the same path (e.g., path404) during a subsequent game play session. Inputs to other buttons, keys, triggers, etc. as game play proceeds can also be stored.

If controller107is provided with inertial sensors (e.g., accelerometers, gyroscopes and the like), information corresponding to outputs from these sensors may also be stored.

The ghost data can also record information about events or sights the player character encounters along path404. For example, the ghost data could record that the player character fought an evil enemy at position (xi, yi). When the corresponding ghost character reaches that same position, a message associated with the ghost character, such as “Here is where I fought the evil enemy!”, may be displayed on television102if the player character and ghost character are captured by the same virtual camera. The ghost data could also record an outcome associated with such events and the message could reflect this outcome (e.g., “Here is where I defeated the evil enemy!”).

Other attributes associated with the player character (e.g., weapon choice, weapon use, strength, vitality, game level, and the like) during a game play session may also be stored as part of the ghost data and used to control the appearance and/or behavior of ghost character(s) during a subsequent game play session. In particular, the ghost data for a particular player character may include an avatar of the game player controlling that player character.

During a game play session, the above-described ghost data for the one or more player characters may be stored in main memory206and/or222. At the end of the game play session, this ghost data may be written to flash memory232so that it can be non-volatilely stored and easily accessed for use during a subsequent game play session. In other implementations, ghost data in main memory206and/or222may be periodically written to flash memory232or may be directly stored in flash memory232. Of course, the ghost data may be stored in any convenient local and/or remote memory. Thus, for example, the ghost data may be stored locally in flash memory232and/or a portable memory medium (e.g., an SD card received in standard memory card slot228) and a copy of the ghost data may be stored remotely in a server accessible to game system10. The ghost data may be stored as part of a file which also stores other information such as, but not limited to, player information for identifying the game player associated with the player character whose attribute information is stored; avatar information for the game player; time and/or date of game play session(s); game level; identification information identifying game system10; and the like. The ghost data may be compressed and/or encrypted for storage and/or transmission if necessary or desired.

Thus, in accordance with the systems and methods described herein, a game player (or players) plays a video game and ghost data for the player character(s) controlled by the game player (or players) is stored. This ghost data is usable to provide ghost character(s) that appear during a subsequent game play session. For example, the ghost data controls the appearance and/or behavior (e.g., movement and/or actions) of ghost character(s) that appear during subsequent game play.

FIG. 5is a flow chart setting forth certain aspects of a non-limiting, example game play process. In this example, theFIG. 5processes are variously controlled by CPU204, along with GPU216and audio DSP218as appropriate. It will be readily apparent that the game play process may include other steps (e.g., powering off) that are not shown in the flow chart ofFIG. 5.

At step S1, game system10boots up in response to being powered on (e.g., by pressing power button242). At step S2, game system10displays a menu on television102. The menu provides various selectable options for a player including one or more options for launching an application program such as a video game. If the player makes a menu selection at S3, the selected option (e.g., application program) is executed by CPU204at S4. The execution of the selected option continues until a stop execution input is received as determined at S5. When the stop input is received, game system10returns to S2and displays the menu.

FIG. 6is a flow chart showing certain aspects of the application program execution step S4when the application program is a video game program including the example ghost feature described herein.

At S10, game system10executing the video game program determines whether the ghost feature is active for the video game program. In some instances, the video game program includes instructions for automatically activating the ghost feature and in other instances the ghost feature is activated/deactivated in response to user inputs provided, for example, using controller107. If the ghost feature is not active, game play proceeds with no ghost characters.

If the ghost feature is active, at S11, game system10executing the video game program determines whether any stored ghost data generated during a prior game play session is accessible for the video game being executed. In video games with multiple levels, the game system may determine whether ghost data is available for the particular game level being played. As noted above, the ghost data may be stored locally and/or remotely and thus game system10may check local memories (e.g., flash memory232) and/or remote memory(ies) for the ghost data. Regarding remote memory, a game player may have associated remote storage on a particular server or the game system itself may have associated remote storage. For example, a game player may use game system10to set up a storage location on a remote server to which various data (including ghost data for player characters associated with the game player) may be written. Alternatively or in addition, as part of the set-up process for game system10or for a particular video game played using game system10, storage on a remote server may be automatically (or manually in response to player inputs) set up for the game system.

If ghost data is available locally and/or remotely, game system10executing the video game program reads the ghost data and loads the ghost data into main memory206and/or222for use during the current game play session at S12. If multiple ghost data are available (e.g., ghost data in local memory and ghost data in remote memory), the game system may select the most recent ghost data or a selection may be made in accordance with user input.

At S13, game system10executing the video game program determines the number of players playing the video game. This determination may be made, for example, during the game set-up process. For example, the game set-up process may include a screen displayed on television102requesting input of the number of game players. Of course, for some games (e.g., first person games), the number of players is determined by the game program itself.

At S14, the number of ghost characters is determined based on the number of game players determined at S13. In the present example, the number of the ghost characters appearing in the 3D virtual game world is based on the number of game players. By way of example and without limitation, Table III below sets forth an illustrative relationship between the number of game players and the number of ghost characters:

TABLE IIInumber of game playersnumber of ghosts13223140

Thus, in this non-limiting example, the number of ghost characters is determined so that the sum total of the number of ghost characters and the number of game players is equal to four.

Depending on prior game play, it is possible that there may be ghost data for fewer ghost characters than the number of ghost characters determined at S14. Consequently, in order to implement the ghost feature described in this example, the video game program may include predetermined “dummy” ghost data that may be used to generate ghost characters in the event there is insufficient ghost data from prior game play sessions. For example, the video game program may include sufficient dummy ghost data for generating up to three ghost characters (the maximum number of ghost characters in Table III) for a situation in which the video game is being played for the first time. In another implementation, the video game program may include instructions for generating the ghost character(s) during game play without using predetermined dummy ghost data. In still another implementation, game system10may access remote storage storing dummy ghost data or ghost data generated by game play sessions on other game systems. In still other implementations, game system10may simply use the ghost data that is available.

At S15, the appearance of the ghost character is determined. Generally speaking, in prior art implementations, the appearance of the ghost character corresponds to that of the player character whose ghost data is used to generate the ghost character. Moreover, in many prior art implementations, the ghost character is translucent in order, for example, to be distinguished from player characters. In the example ghost feature described herein, the appearance of a ghost character corresponds to an avatar of the game player who controlled the player character when the ghost data was generated. Moreover, in the ghost feature described herein, the ghost character is not translucent. It is displayed using data of the avatar included in the ghost data. Of course, the appearance is not limited to an avatar of the game player. Appearance data may be stored as part of the ghost data or, for example, game system10may access appearance data stored elsewhere for use in the example ghost feature.

At S16, game play begins. The game play includes storing ghost data for one player character or for more than one player character. In particular, in some non-limiting example embodiments, the game play stores ghost data for only one player character. The one player may be determined in accordance with the game program or in accordance with user selection. In some other non-limiting example embodiments, the game play stores ghost data for multiple player characters. Here again, these multiple players may be determined in accordance with the game program or in accordance with user selection. At S17, a determination is made as to whether any remaining ghost characters should appear in the 3D virtual game world. If so, a ghost character becomes present at S18.

In the prior art, the presence of a ghost character is generally synchronized with the start of a game. For example, in a racing game, a ghost character is present at the start of the racing so that a game player can compete (race) against the ghost character. However, the presence of ghost characters in the present example need not be synchronized with the start of the game. Moreover, in the case of multiple ghost characters, the ghost characters can become present in the virtual game world at different times, thereby causing the number of ghost characters to increase gradually as the game proceeds.

For example, ghost characters may become present in the game world in accordance with the following timing offsets from the start of the game session:

TABLE IVGhost CharacterTiming of display1st ghost character90 frames after a game session start2nd ghost character135 frames after a game session start3rd ghost character180 frames after a game session start

Thus, after a player character is displayed at the beginning of the game play session, the number of ghost characters increases gradually. Of course, the timings shown in Table IV are merely examples and other timings may be used. Moreover, the interval between each ghost character becoming present need not be the same.

Ghost characters will be displayed on television102when the ghost character is present in the field of view of a virtual camera. Because the movement of the ghost character(s) in accordance the ghost data and the movement of the player character(s) are independent of one another, the presence of ghost characters in the virtual world does not necessarily mean that a player character will encounter any of them during game play.

In some implementations, the ghost character's position when it becomes present in the game world is determined by reference to the ghost character's position in the ghost data at the frame (or time) at which it becomes present. Thus, with reference to the 1st ghost in Table IV above, the ghost character would become present in the virtual game world at its position at the 90th frame (e.g., at (x90, y90) using the convention of Table I). Thereafter, the ghost character proceeds to move in the 3D virtual game world (i.e., to (x91, y91), then to (x92, y92), etc.) in accordance with the ghost data. In another implementation, when the ghost character becomes present in the game world at the 90th frame of the game play session, its position corresponds to the initial position in the ghost data (e.g., at (x1, y1) using the convention of Table I). Again, thereafter, the ghost character proceeds to move in the 3D virtual game world (i.e., to (x2, y2), then to (x3, y3), etc.) in accordance with the ghost data.

As the player characters move in the game world, one or more ghost characters may be visible. In particular, as a player character moves in the virtual world, it may encounter a ghost character whose position causes it to be in the same virtual camera image as the player character. Because the ghost characters appear as an avatar corresponding to a game player, a game player playing the current game play session may be able to identify the game player whose avatar appears. A game player in the current game play session may, for example, choose to follow a particular ghost character as the ghost character moves in the 3D virtual game world.

Game play continues until a game stop input is received (S19). At this time, game play stops.

The ghost feature described herein may be used in games of the type in which game characters can move freely within a virtual space. In other words, the ghost feature described herein in not limited to games in which player characters proceed along predetermined routes such as a race track.

If a ghost character reaches the end of its path before the end of a game play session, the video game program may control the ghost character to start again at (x1, y1). Alternatively, the presence of the ghost character in the virtual game world can end.

It will be appreciated that video games often have different game levels and that ghost data may be stored for each different level. A determination of game level may be made at the beginning of a game play session so that ghost data for the appropriate game level may be accessed and used.

The described systems, methods, and techniques may be implemented in digital electronic circuitry, computer hardware, firmware, software, or in combinations of these elements. Apparatus embodying these techniques may include appropriate input and output devices, a computer processor, and a computer program product tangibly embodied in a non-transitory machine-readable storage device for execution by a programmable processor. A process embodying these techniques may be performed by a programmable hardware processor executing a suitable program of instructions to perform desired functions by operating on input data and generating appropriate output. The techniques may be implemented in one or more computer programs that are executable on a programmable processing system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program may be implemented in a high-level procedural or object-oriented programming language or in assembly or machine language, if desired; and in any case, the language may be a compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Non-transitory storage devices suitable for tangibly embodying computer program instructions and data include all forms of computer memory including, but not limited to, non-volatile memory, including by way of example semiconductor memory devices, such as Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and Compact Disc Read-Only Memory (CD-ROM). Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits).

While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.