U.S. Pat. No. 9,707,476

INTRODUCTION

In response to the need for increasing the longevity of legacy games and to play a game with a shorter time frame in which the gamer is familiar, a method to create mini-games has been devised. The method is based on creating a mini-game from a legacy game title using a snapshot technique. The method involves a mini-game generator generating a snapshot of an interesting starting location within the legacy game. There is some defined event that when achieved will cause the mini-game to reach an endpoint or a non-endpoint. These events can include, without limitation, the mini-game timing out, a certain score being achieved, the lead character being neutralized, the adversary being neutralized, or some other objective being reached. One or more triggers that correspond to the events are identified from the legacy game. The triggers are used to define the endpoint of the mini-game. The triggers can also be used to define other corresponding events that occur during mini-game play. The mini-game generator records the snapshot and triggers data. A developer can create a script from the captured data (snapshot and triggers) and bundle the script with the captured data. Within a mini-game, the gamer can be instructed to complete new objectives or challenge their friends for high scores in a format that was not originally designed into the legacy game. Further, since the mini-game is derived from a legacy game, the gamer already knows the characters and basic components of the game, and is therefore more likely to play the mini-game.

DETAILED DESCRIPTION OF THE DRAWINGS

Although the following detailed description contains many specific details for the purposes of illustration, anyone of ordinary skill in the art will appreciate that many variations and alterations to the following details are within the scope of the present disclosure. Accordingly, the aspects of the present disclosure described below are set forth without any loss of generality to, and without imposing limitations upon, the claims that follow this description.

In order to create mini-games without reverse engineering and recoding a legacy game, a game designer may rely on the use of triggers and snapshots to provide information needed for the mini-games without having to dig into the code of the legacy game. The mini-games may be created by providing an emulator with game inputs that bring the emulated game to a certain point where the mini-game will begin. A snapshot may be generated at that point in order to be used as the starting point in the future mini-game. A snapshot can be generated at any location in a legacy game. As used herein, a snapshot may be a recorded description of the state of every device being emulated at a designated time during the emulation according to an aspect of the present disclosure.

A snapshot may be generated by a snapshot generator as follows. First the snapshot generator delivers game inputs to an emulator. The emulator receives the game inputs and proceeds to emulate the game according to the game inputs. At some point during the emulation, the snapshot generator delivers a suspension request to the emulator. Once the suspension request is received, the emulator will suspend the emulated title at the next point in time at which all devices being emulated are in a steady state. Steady state means there are no asynchronous activities occurring in the emulator. At this steady state, the snapshot generator generates a snapshot of the emulated game by recording the current state of all devices being emulated. Snapshots are further described in commonly assigned pending application Ser. No. 61/666,679 filed on Jun. 29, 2012, and entitled “SUSPENDING STATE OF CLOUD-BASED LEGACY APPLICATIONS”, which has been incorporated herein by reference.

Once the snapshot is taken to identify the starting point in the mini-game, triggers may be generated according to aspects of the present disclosure in order to provide new experiences for the game. According to an aspect of the present disclosure, a trigger event that requires an emulator to produce a desired output is identified. A trigger that is associated with the trigger event is then identified and stored in a memory of the emulator. Thereafter, when the emulator runs an emulation routine, it will compare the emulated game data to the trigger stored in its memory, and will therefore know to produce the desired output when the emulated game data matches the trigger. Game designers may then develop a script by using the snapshot and triggers to produce the mini-game. Triggers are further described in commonly assigned pending application Ser. No. 61/666,628 filed on Jun. 29, 2012, and entitled “DETERMINING TRIGGERS FOR CLOUD-BASED EMULATED GAMES”, which has been incorporated herein by reference.

FIG. 1is a schematic diagram illustrating interaction between client device platform103and an emulator107according to aspects of the present disclosure. The emulator107may be accessed by a client device platform103over a network160. Although only a single emulator is shown inFIG. 1, aspects of the present disclosure are not limited to such implementations. The client device platform103may access a plurality of alternative emulators107over the network160. The emulators107may be identical to each other, or they may each be programmed to emulate unique legacy game titles106or unique sets of legacy game titles106.

The client device platform103may include a central processor unit (CPU)131. By way of example, a CPU131may include one or more processors, which may be configured according to, e.g., dual-core, quad-core, multi-core, or Cell processor architecture. The client device platform103may also include a memory132(e.g., RAM, DRAM, ROM, and the like). The CPU131may execute a process-control program133, portions of which may be stored in the memory132. The client device platform103may also include well-known support circuits140, such as input/output (I/O) circuits141, power supplies (P/S)142, a clock (CLK)143and cache144. The client device platform103may optionally include a mass storage device134such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The client device platform103may also optionally include a display unit137. The display unit137may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. A controller145may be connected to the client device platform103through the I/O circuit141or it may be directly integrated into the client device platform103. The controller145may facilitate interaction between the client device platform103and a user. The controller145may include a keyboard, mouse, joystick, light pen, hand-held controls or other device. The client device platform103may include a network interface139, configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods.

The network interface139may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via an electronic communications network160. The network interface139may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The client device platform103may send and receive data and/or requests for files via one or more data packets over the network160.

The preceding components may exchange signals with each other via an internal system bus150. The client device platform103may be a general purpose computer that becomes a special purpose computer when miming code that implements embodiments of the present invention as described herein.

The emulator107may include a central processor unit (CPU)131′. By way of example, a CPU131′ may include one or more processors, which may be configured according to, e.g., a dual-core, quad-core, multi-core, or Cell processor architecture. The emulator107may also include a memory132′ (e.g., RAM, DRAM, ROM, and the like). The CPU131′ may execute a process-control program133′, portions of which may be stored in the memory132′. The emulator107may also include well-known support circuits140′, such as input/output (I/O) circuits141′, power supplies (P/S)142′, a clock (CLK)143′ and cache144′. The emulator107may optionally include a mass storage device134′ such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The emulator107may also optionally include a display unit137′ and user interface unit138′ to facilitate interaction between the emulator107and a user who requires direct access to the emulator107. By way of example and not by way of limitation a client device platform103or engineer may need direct access to the emulator107in order to program the emulator107to properly emulate a desired legacy game106or to add additional mini-game capabilities to a legacy game106. The display unit137′ may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. The user interface unit138′ may include a keyboard, mouse, joystick, light pen, or other device. The emulator107may include a network interface139′, configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods.

The network interface139′ may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via the electronic communications network160. The network interface139′ may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The emulator107may send and receive data and/or requests for files via one or more data packets over the network160.

The preceding components may exchange signals with each other via an internal system bus150′. The emulator107may be a general purpose computer that becomes a special purpose computer when running code that implements embodiments of the present invention as described herein.

Emulator107may access a legacy game106that has been selected by the client device platform103for emulation through the internal system bus150′. There may be more than one legacy game106stored in the emulator107, e.g., in the memory132′ or in the mass storage device134′. Additionally, one or more legacy games106may be stored at a remote location accessible to the emulator107over the network160. Each legacy game106contains game code108. When the legacy game106is emulated, the game code108produces legacy game data109.

By way of example, a legacy game106may be any game that is not compatible with a target platform. By way of example and not by way of limitation, the legacy game106may have been designed to be played on Sony Computer Entertainment's PlayStation console, but the target platform is a home computer. By way of example, the legacy game106may have been designed to be played on a PlayStation 2 console, but the target platform is a PlayStation 3 console. Further, by way of example and not by way of limitation, a legacy game106may have been designed to be played on a PlayStation console, but the target platform is a hand held console such as the PlayStation Vita from Sony Computer Entertainment.

As shown inFIG. 2, the mini-game is generated from a legacy game. By way of example, and not by way of limitation, the mini-game generator218chooses a mini-game starting location in the legacy game, as indicated at251. The starting location may be any location within the legacy game. After a starting location is chosen, the mini-game generator generates a snapshot of that point in the legacy game, as indicated at252. The next step is to choose one or more events from the legacy game execution state, as indicated at253. In some implementations, the executions state may be modified slightly after it has been loaded. By way of example, and not by way of limitation, the execution state maybe modified by setting the current score, number of lives remaining, or remaining time in the game.

The mini-game generator identifies one or more triggers that correspond to the events, as indicated at254. The events may include, by way of example and without limitation, mini-game-ending triggers such as the mini-game timing out, an adversary being neutralized, a protagonist being neutralized or a certain score being achieved. The events may also include, by way of example and without limitation, non-mini-game-ending triggers such as a certain score being achieved or a game character reaching a certain level within the game. The identified triggers may include changes in the game state or game data that correspond to the events. For example, if the event is a certain score being achieved, the corresponding trigger would occur when the game data indicates that the certain score has been achieved. The mini-game generator combines the snapshot and triggers to generate a script209for a particular mini-game, as indicated at255. The mini-game script209selection may then be loaded on an emulator207. The mini-game script209, a snapshot of the starting location and trigger data may all be stored in a non-transitory computer-readable medium.

In some implementations, game state information may be harvested and utilized within a controlling script to determine subsequent events within the mini-game. By way of example, and not by way of limitation, information regarding virtual items obtained by a player during one the mini-game may be carried over to a subsequent part. Alternatively, the score may determine whether a player advances to another level or determines the level to which the player advances after a section the mini-game has been completed.

FIG. 3schematically illustrates an example of implementing a mini-game. A client device platform303instructs an emulator307to send emulated game data of a legacy game by selecting a mini-game option from a plurality of mini-game choices312as they may appear on the client device platform display311. Based on the mini-game312selected, the mini-game script317provides the emulator307with game inputs that bring the emulated game to the starting location of the mini-game within the legacy game execution state316. The starting location data314of the emulated game are then sent to the client device platform303and are shown on the client device platform display311.

FIG. 4schematically illustrates another example of implementing a mini-game. In this example, as game play begins, a client device platform403receives emulated game data414of a legacy game from an emulator407. As the game is played on the client device (e.g., using a game interface411, which may be implemented in hardware or software or some combination thereof), emulated game data414is continually sent to the client device platform403from the emulator407. Simultaneously, mini-game input data420is sent from the client device platform403to the emulator407. The mini-game script417monitors game play that results from the emulated game data414and input data420to determine if any triggers occur. The mini-game script417provides the emulator407with game inputs that bring the emulated game to an end when a game-ending trigger occurs. The mini-game script417may also provide the emulator407with non-game-ending inputs when a non-game-ending trigger occurs.

FIG. 5is a flow diagram illustrating the interaction between the client device platform103the mini-game script109and the emulation process570. In one embodiment, the mini-game is selected from the client device platform103, as indicated at591. The mini-game selection data is sent to the emulator107which loads the game instructions and the mini-game script109, as indicated at571. The mini-game script109loads the snapshot581onto the emulator107and mini-game play begins, as indicated at576. The emulator107generates emulated game data as indicated at577. The emulated game data is sent to the client device platform103. The client device platform103receives emulated game data from the emulator107, as indicated at592. The client device platform103sends game inputs as also indicated at592which are received by the emulator107, as also indicated at577. The mini-game script109monitors data from the emulated game identifying triggers that correspond to events within the game, as indicated at582.

FIG. 6is a decision tree illustrating how the mini-game script209monitors data from the emulated game at582. If the mini-game script detects a mini-game-ending trigger, e.g., by comparing the emulated game data to the trigger data, the script sends mini-game-ending instructions to the emulator. If the mini-game script does not detect a mini-game-ending trigger it continues monitoring the game data. If the mini-game script detects a non-mini-game-ending trigger, the script sends non-game-ending instructions to the emulator and continues monitoring the game data.

As may be seen from the foregoing, embodiments of the present invention allow for the increased utility of legacy games through the use of snapshots and triggers without having to expend the resources required for creating an entirely new game. This provides game players with the benefit of shorter gaming experiences for games in which they are already familiar.

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. In the claims that follow, the indefinite article “A”, or “An” refers to a quantity of one or more of the item following the article, except where expressly stated otherwise. The appended claims are not to be interpreted as including means-plus-function limitations, unless such a limitation is explicitly recited in a given claim using the phrase “means for.”