U.S. Pat. No. 9,005,033

DETAILED DESCRIPTION

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

In one embodiment, a player's activities as they progress through a level of a game are recorded. If the player successfully negotiates the level, then the recorded game-play data can be saved. The game-play may then be rerendered showing the successful navigational paths by the player and shared with other players. For example, the player may enjoy reviewing their successful negotiation of the game level. Likewise, the player may send the game-play data, such as by emailing, to a friend so that they can recreate the player going through the game level.

In one embodiment, game-play data including, for example, game commands entered by the player during play of the game are saved along with game data that provides control variables of the game, are saved to a file. In other words, game data is data generated during the playing of the game. The game data is stored along with the player commands to make up the game-play data. Using this technique the file will generally be relatively small and is referred to as a “thin” file. The game data includes game parameters and variables, such as game status and random numbers that are generated during the game and that are used to control aspects of the game. For example the game data can control the artificial intelligence (AI) used during the game. Using this technique the files are generally small and easy to transfer. In one embodiment a game console and the game can be used to render the play back or recording of the session. In another embodiment, a computer or server operating game software may render that play back or recording of the game session.

In another embodiment, frames of the game play are recorded. In other words, as the player navigates the game level all of the frames, such as the audio and video of the game are stored. This technique will typically produce a large, or “thick”, file. An advantage of a “thick” file is that it can be rendered without having to have the game that was used by the player when the recording was made. In other words, a “thick” file can be played back on a different viewer or ported to a standard audio visual file format and does not require the game console and game used in creating the recording.

In one embodiment, game-play data is saved only when a player is successful in completing a level or portions of a level of a game. In another embodiment, the player can determine if they want to save the game-play data recording whether they are successful in completing the level or not. After more than one set of game-play data are saved, the sets can be assembled into a larger file. For example, if a game has twenty levels and the player has saved game-play data of the player successfully completing all twenty levels, then the twenty game-play data sets can be combined into a single file of the player completing the entire game. In other embodiments, the player can select desired game-play data sets to be combined into a larger file.

In one embodiment, the game that is being played can be an online game. In this embodiment, the actions of all the players in the game can be recorded as the player navigates the game. For example, using a “thin” file technique, the players commands and actions, as well as the commands and actions of the other players and the game data are saved. Using a “thick” file technique the frames of the game during play can be recorded.

FIG. 1is a block diagram illustrating a system that operates in accordance with an embodiment of the present invention. As illustrated inFIG. 1, a computer, or game console,102may be coupled to a video display104such as a television, monitor, or other type of visual display. A game or other simulations may be stored on a storage media106such as a DVD, a CD, flash memory, USB memory or other type of memory media. The storage media106can be inserted to the console102where it is read. The console can then read program instructions stored on the storage media and present a game interface to the user.

Typically, a user or player manipulates a game controller110to generate commands to control and interact with the video game or other simulation. The game controller110may include conventional controls, for example, control input devices such as joysticks, buttons and the like. Using the controller a user can interact with the game, such as by using buttons, joysticks, and movements of the controller110, and the like. This interaction or command may be detected and captured in the game console102. The user's inputs can be saved, along with the game data to record the game play. In one embodiment, the game data can include states of the game and variables such as random numbers generated during the game and used to control the game. Likewise, game data associated with the audio and video of the game play may be captured to record the user's experience as they navigate different levels of the game.

FIG. 2is a block diagram of an example online environment. As shown inFIG. 2, multiple players or users202,204, and206can interact and enter into online sessions, such as online games, over a network208. The network208can be connected in many different architectures, for example, a Client Server architecture, a Peer-to-Peer network architecture, a mesh network, or other type of architecture. The online environment can also include a server210that coordinates the online session. The network208can be different types of networks. For example, the network208can be the Internet, a Local Area Network or any variations of Local Area Network, a Wide Area Network, a Metropolitan Area Network, an Intranet or Extranet, or a wireless network. Also, the term “online session” can be used to identify any network topology where different users are connected to a network and send and receive information from other users connected to the network. In one example, an online session can be an online game where users connected to the network send and receive information pertaining to a game.

As the players202,204and206play the game, and navigate various levels, game-play data of their playing of the game can be recorded or saved. In one embodiment, the players commands as well as the game kernel are recorded using a “thin” file technique. In another embodiment the game play is recorded as audio and video frames of the game using “thick” file technique.

In one embodiment, the server210can be a game console, such as a PlayStation 3 (PS3) by Sony Corporation. Players202,204, and206can upload game-play files to the PS3. The PS3 can render and play back the game sequences to the players.

The players202,204, and206can use various devices to communicate with the networks208. The players can use wireless or wired devices to communicate with the network208. Players can also use various wired or wireless devices, such as a game console, a computer, an iPod by Apple Inc., a virtual world such as Home by Sony Corporation, a cell phone, or other devices to interface with the network208.

FIG. 3is a flow diagram of an embodiment of recording a player's action as they navigate levels of a game. Flow begins in block302where the player begins to play the game at the current level. For example, a player may be playing the game for the first time and so the current level would be the first level. If the player has previously played the game then the current level may be the last level of the game the play was not successful in navigating or at a point within a level.

Flow continues to block304where the commands input by the player as well as the game data are stored. The game data can include, for example, states of game as well as random game parameters that are generated during the playing of the game. Flow continues to block306. In block306, it is determined if the level was successfully completed. If a level was not successfully completed, flow continues to block308. In block308, the stored commands and game data are erased. Flow then continues to block302and the player begins to play the game at the current level. In another embodiment, in block308the stored commands and game data are not erased but can be saved to a file for later replay.

Returning to block306, if the level was successfully completed, flow continues to block310. In block310, the player's commands and the game data are saved to a file. Flow then continues to block312. In block312, it is determined if there are more game levels for the player in the game. If there are more game levels, flow continues to block314and the current level is incremented to the next game level. Flow then continues to block302and the player begins playing the game at the new current level. Returning to block312, if there are no more levels for the player to complete, flow continues to block316and flow stops. In one embodiment, the example inFIG. 3is referred to as a thin file technique.

FIG. 4is a flowchart illustrating another embodiment of recording a player's action as they navigate levels of a game. Flow begins in block402where the player begins game play at the current level of the game. For example, a player may be playing the game for the first time and so the current level would be the first level. If the player has previously played the game then the current level may be the last level of the game the play was not successful in navigating.

Flow continues to block404. In block404frames of the game that is being played are stored at a desired resolution. For example, a frame can be stored once every 60 seconds, or every 30 seconds, or at any desired resolution. The desired resolution can be based on an amount of memory available. Flow then continues to block406. In block406, it is determined if the level was successfully completed. If the level was not successfully completed, flow continues to block408and the stored frames are erased. Flow then continues back to block402and the player begins playing the game at the current level. In another embodiment, the stored frames are not erased but can be saved to a file for later replay.

Returning to block406, if the game level was successfully completed by the player, flow continues to block410. In block410, the stored frames are saved to a file. Flow then continues to block412. Where it is determined if there are more levels of the game for the player to complete. If there are more levels to complete, flow continues to block414. In block414, the current level is incremented to the next game level and flow continues to block402where the player begins to play the game at the new current level. Returning to block412, if there are no more levels to play, flow continues to block416where flow stops. The example illustrated inFIG. 4is one embodiment of the technique described as a thick file.

FIG. 5is a flow diagram illustrating an embodiment of rendering game-play data, referred to as a thin file, such as a file saved using techniques described inFIG. 3. In the embodiment illustrated inFIG. 5, a thin file can be rendered on a game console. Flow begins in block502where starting and ending game levels are selected. Flow then continues to block504and a current level value is set to the starting level that was selected. Flow continues to block506where stored game-play data for the current level are retrieved. Flow continues to block508.

In block508, it is determined if the current level is the ending level. If it is determined that the current level is not the ending level, flow continues to block510and the current level is incremented to the next selected level which is set to the new current level. Flow then continues to block506and the game-play data for the new current level are retrieved. Returning to block508, if the current level is the ending level, flow continues to block512. In block512, the game-play data are assembled into a file to render the game session that was recorded. Flow then continues to block514. In block514, the game console or a game viewer console renders or replays the game session using the game-play data in the file. In another embodiment, the retrieved game-play data can be rendered for one level as the commands and parameters for the next level are being retrieved. In this way, one level can be rendered while the next level is being retrieved instead of retrieving all of the levels and then assembling the entire commands and parameters of the game before rendering.

FIG. 6is a flow diagram illustrating an embodiment of assembling a media file that includes the stored game frames such as the frames saved using techniques such as described inFIG. 4. Flow begins in block602where a starting and ending level of a game are selected. For example, a player can select the first and last game level (i.e., all the game levels), or a user can select desired game levels. For example, the first and second level, the first and last level, the second and last level, or any other desired combination of levels for the game play. Flow then continues to block604. In block604, the starting level selected in block602is set to the current level. Flow then continues to block606.

In block606, the stored frames for the current level are retrieved. Flow continues to block608. In block608, it is determined if the current level is the ending level. If the current level is not the ending level, flow continues to block610. In block610, the current level is incremented to the next level that was selected which is set as the new current level. Flow then continues to block606where the new current level stored frames are retrieved. Returning to block608, if the current level is the ending level, flow continues to block612. In block612, the retrieved frames are assembled into a media file. For example, the retrieved frames can be assembled into an audio-video file, or multi-media file, that a player can share with other players or review themselves.

FIG. 7is a flow diagram of rendering a recorded game session file on a server. Flow begins in block702where a player sends recorded session files to the server. Flow continues to block704where a starting and ending level are selected. For example, the player that sent the files to the server can select the starting and ending levels, or another player or user that wants to view the session can select the starting and ending files or all the levels sent can be automatically selected. Flow continues to block706. In block706, the current level is set to the selected starting level. Flow then continues to block708.

In block708, the game-play data including a player commands and game data that have been stored for the current level are retrieved. Flow continues to block710. In block710, it is determined if the current level is the ending level. If in block710it is determined that the current level is not the ending level, flow continues to block712where the current level value is incremented to the next selected level that is set to the new current level. Flow then continues to block708and the game-play data for the new current level are retrieved. Returning to block710, if it is determined that the current level is the ending level, flow continues to block714. In block714, the game-play data are assembled into a game session replay file. Flow then continues to block716. In block716, the game session replay file is rendered. Flow continues to block718. In block718, the rendered game session can be streamed or otherwise transmitted to the user desiring to observe the replay. In another embodiment, the game session is rendered real-time as game-play data of a level are retrieved. In this way, the rendering can occur real time as it is being streamed to a user.

FIG. 8is a block diagram of a gaming system800that may be used to implement various embodiments described herein. As shown inFIG. 8, the gaming system800may include a processor module801and a memory module802. In one embodiment, memory module802may be RAM, DRAM, ROM and the like. In addition, the gaming system800may have multiple processor modules801if parallel processing is to be implemented. The processor module801can include a central processing unit803. In addition, the processor module801can include local storage or a cache to store executable programs. The local storage can also store player commands and game kernel during the play of a game. The memory module802can include game program storage805. In addition, the memory module802can include signal data storage806, for example, signal data acquired from game controller operated by a user. The memory module802may also store player commands and game kernel during play of a game. The memory module802can also include player data808such as player profile data as well as game statistics that may be provided.

The system800may also include well-known support function module810such as input/output module811, power supplies812, a clock813, in cache memory814. There can also be a controller830that interfaces to the input/output module811. The system800may also optionally include mass storage module815such as a disc drive, CD ROM drive, DVD drive, tape drive or the like to store programs and/or data. The mass storage module815may also store player commands and game kernel files recorded during play of a game. The system800may also optionally include a display module816as well as a user interface module818to facilitate interaction between the system800and the user. Display module816may be in the form of a cathode ray tube, a flat panel screen or any other display module. The audio and video of the game play can be saved to the memory module802or mass storage815.

The user interface module818may include a keyboard, mouse, joystick, write pen or other device such as a microphone, video camera or other user input device. The processor, memory, and other components within the system800may exchange signals such as code instructions and data with each other via a system bus820.

The system800may also include a data input/output module840. The data input/output module can be a network interface module. For example, the data input/output module840can interface to a local area network, a wide area network such as the Internet, or other network. In addition, the interface to the network can be wired or wireless.

Various embodiments may also be implemented primarily in hardware using, for example, components such as application specific integrated circuits (“ASICs”), or field programmable gate arrays (“FPGAs”). Implementation of a hardware state machine capable of performing the functions described herein will also be apparent to those skilled in the relevant art. Various embodiments may also be implemented using a combination of both hardware and software.

The term “module” as used herein means, but is not limited to a software or hardware component, such as an FPGA or an ASIC, which performs certain tasks. A module may advantageously be configured to reside on an addressable storage medium and configured to execute on one or more network enabled devices, processors or gaming systems. Thus, a module may include, by way of example, components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, variables, and the like. The functionality provided for in the components and modules may be combined into fewer components and modules or further separated into additional components and modules. Additionally, the components and modules may advantageously be implemented to execute on one or more network enabled devices or computers.

Furthermore, those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and method steps described in connection with the above described figures and the embodiments disclosed herein can often be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above 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, block, circuit or step is for ease of description. Specific functions or steps can be moved from one module, block or circuit to another without departing from the invention.

Moreover, the various illustrative logical blocks, modules, and methods described in connection with the embodiments disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (“DSP”), an ASIC, FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be any processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

Additionally, the steps of a method or process described in connection with the embodiments 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 exemplary storage medium can be coupled to the processor such 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.

While the above is a complete description of the preferred embodiment of the present invention, it is possible to use various alternatives, modifications and equivalents. Therefore, the scope of the present invention should be determined not with reference to the above description but should, instead, be determined with reference to the appended claims, along with their full scope of equivalents. Any feature described herein, whether preferred or not, may be combined with any other feature described herein, whether preferred or not. Thus, the invention is not intended to be limited to the embodiment shown herein but is to be accorded the widest scope consistent with the principal and novel features disclosed herein.