Game system, game program, game processing method, and game device

Abstract

To provide a game system suitable for a game which makes users to compete on a period required for a game play.SOLUTION: The game system comprises a processor, which starts a first game, processes the first game based on an operation input by a user, generates a game image including a first image based on the first game, transits a game state into a state preceding satisfaction of a first condition when the game state satisfies the first condition in the first game, and suspends or finishes the processing of the first game when the game state satisfies a second condition in the first game.SELECTED DRAWING: Figure 27

Description

[Technical Field]

[0001] The present disclosure relates to a game process for measuring and competing for the time required to play a game. [Background technology]

[0002] Conventionally, a game system has been known in which, after the progress of a game has stopped due to a game over or the like, the game screen is reproduced as it was before the game was stopped, and the game resumes from the point where the screen reached the game stop state (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2001-38049 Summary of the Invention [Problem to be solved by the invention]

[0004] The above-mentioned system allows players to redo their play if they make a mistake, but it cannot be used in games such as time attack games, where players compete to achieve the clearing conditions. For example, in conventional time attack games, it is common for the time attack to end immediately if a mistake is made. [Means for solving the problem]

[0005] In view of the above, the following configuration example is disclosed.

[0006] (Configuration 1) Configuration 1 is a game system including a processor, in which the processor starts a first game, processes the first game based on a user's operation input, generates a game image including a first image based on the first game, and when the game state in the first game satisfies a first condition, transitions the game state to a state before the first condition was satisfied, and when the game state in the first game satisfies a second condition, stops or terminates processing of the first game.

[0007] According to the above configuration, if the first condition is satisfied during the first game, the state before the first condition was satisfied can be restored and play of the first game can be continued. As a result, even if a situation arises in which play cannot be continued because the first condition is satisfied, the user is immediately given an opportunity to start over and proceed with the game so that the first condition is not satisfied, and the user can continue playing the first game until the second condition is satisfied.

[0008] (Configuration 2) In a second configuration based on the first configuration, the processor may measure the time that has elapsed since the start of the first game until the second condition is satisfied, including the time required for the transition of the game state.

[0009] With the above configuration, the total elapsed time can be measured, including the time required for transitions in the game state, thereby providing a game system in which players can compete over the time it takes to complete a series of game plays, including redoes.

[0010] (Configuration 3) In configuration 3, in the above configuration 1, the first condition may be a condition that is satisfied when at least one of the following occurs: a playable character that moves based on an operation input falls, receives damage, or enters a location other than a pre-designated location.

[0011] According to the above configuration, it is possible to encourage smooth completion of the first game within a predetermined range.

[0012] (Configuration 4) In configuration 4, in configuration 1, the processor may store the game state for each frame from the current frame in the first game up to a predetermined period before, and when a first condition is satisfied, transition to the game state for a predetermined frame before the first condition is satisfied.

[0013] According to the above configuration, when the first condition is satisfied, the game state can be returned to a state in which the condition is not satisfied, and then game play can be resumed.

[0014] (Configuration 5) In configuration 5, in the above configuration 1, when the game state satisfies a first condition, the processor may transition to the game state before the first condition was satisfied by sequentially transitioning to the game state of each frame up to a predetermined period ago.

[0015] According to the above configuration, it is possible to present the game state as if it is being played in reverse, and it is possible to present to the user in an easy-to-understand manner how the game state is returning to the previous state, thereby enabling the user to more reliably recognize that the game state has returned.

[0016] (Configuration 6) In a sixth configuration based on the first configuration, when the game state satisfies a first condition, the processor may transition the game state to a state before the first condition was satisfied after a predetermined waiting period has elapsed.

[0017] According to the above configuration, it is possible to make the user more reliably understand that the first condition has been met.

[0018] (Configuration 7) In a seventh aspect of the present invention, in the first aspect, the processor may transition the game state to a game state at the start of the first game when the game state satisfies a first condition.

[0019] (Configuration 8) In an eighth aspect of the present invention, in the first aspect, the processor may run the first game using an emulator. (Configuration 9) Configuration 9 may be such that in the above configuration 1, the processor simultaneously starts a first game and at least one second game that is the same as the first game and operates based on operation history information that is a history of operation inputs, processes the at least one second game based on at least one piece of operation history information, generates a game image including at least one second game image based on the second game, and when a first condition is satisfied in the second game, transitions to a game state before the first condition was satisfied, and when a second condition is satisfied in the second game, stops or terminates processing of the second game.

[0020] According to the above configuration, it is possible to provide a playing experience that is similar to competing with the play of the second game that operates based on the operation history information.

[0021] (Configuration 10) In configuration 10, in the above configuration 1, the processor may store a history of operation inputs in the first game as operation history information.

[0022] According to the above configuration, recording can be performed automatically while the user is playing the game.

[0023] (Configuration 11) In configuration 11, in configuration 1, the processor may process the second game based on operation history information stored by another game system. You may do so.

[0024] According to the above configuration, the second game is executed using the operation history of the other user, so that a playing experience similar to playing against other users in real time can be provided.

[0025] (Configuration 12) In configuration 12, in the above configuration 10, the processor may process the second game based on the operation history information in the case where the time that has elapsed from the start of the first game until the first condition is satisfied is shortest.

[0026] According to the above configuration, it is possible to provide a time attack type game in which players compete to see who can meet the second condition the fastest.

[0027] (Configuration 13) In configuration 13, in the above configuration 11, the processor may start the next first game and second game in a series of games in which multiple types of first game and second game are played consecutively in a predetermined order only when a third condition is satisfied.

[0028] (Configuration 14) In configuration 14, in the above configuration 13, the third condition may be that, in a ranking based on the results of a predetermined first game and a predetermined second game in a series of games, the ranking based on the result of the first game is within a predetermined ranking.

[0029] According to the above configuration, a knockout type game can be provided.

[0030] (Configuration 15) In configuration 15, in configuration 13, the processor may process each of multiple types of second games executed in a predetermined order in the series of games based on operation history information of the multiple types of second games stored in another single game system.

[0031] According to the above configuration, in a knockout type game, if a player advances, the opponent can be the same opponent, providing a playing experience similar to playing a knockout match against the same opponent.

[0032] (Configuration 16) In a sixth aspect of the present invention, the game system of the first aspect may include a plurality of game devices each having a processor, and a server. The processor may upload play record data to the server, the play record data including information on the elapsed time from the start of the first game until a second condition is satisfied in the first game. The server may determine a ranking based on the uploaded play record data.

[0033] According to the above configuration, it is possible to provide an online game in which a player competes with other users to see who can meet the second condition in the first game the fastest.

[0034] Another example of a configuration is a game system having a processor, in which the processor processes based on a user's operational input, starts a first game that ends when a first condition is met, starts measuring the elapsed time from the start of the first game until the first condition is met at the same time as the start of the first game, generates a game image including a first image based on the first game, when the game state in the first game satisfies a second condition, automatically transitions the game state to a state before the second condition was met, and performs an evaluation process in the first game to evaluate the measured elapsed time including the time taken to transition the game state when the first condition is met. [Effects of the Invention]

[0035] According to the present disclosure, it is possible to accurately measure the elapsed time until the second condition is satisfied while having the user play the first game until the second condition is satisfied. [Brief explanation of the drawings]

[0036] [Figure 1] FIG. 1 is a schematic diagram showing an overall view of a game system according to the present embodiment. [Figure 2] Block diagram showing the hardware configuration of the server 1000 [Figure 3] FIG. 1 shows an example of a state in which the left controller 3 and the right controller 4 are attached to the main unit 2. [Figure 4] FIG. 10 shows an example of a state in which the left controller 3 and the right controller 4 are detached from the main unit 2. [Figure 5] Six-sided views showing an example of the main unit 2 [Figure 6] Six-sided diagram showing an example of the left controller 3 [Figure 7] Six-sided diagram showing an example of the right controller 4 [Figure 8]A block diagram showing an example of the internal configuration of the main unit 2. [Figure 9] A block diagram showing an example of the internal configuration of the main unit 2, the left controller 3, and the right controller 4. [Figure 10] FIG. 1 is a diagram for explaining a competition in this embodiment. [Figure 11] FIG. 1 is a diagram for explaining a competition in this embodiment. [Figure 12] FIG. 1 is a diagram for explaining a competition in this embodiment. [Figure 13] FIG. 1 is a diagram for explaining a competition in this embodiment. [Figure 14] Competition screen example [Figure 15] An example of an operation information image [Figure 16] FIG. 10 is a diagram for explaining a state restoration process; [Figure 17] FIG. 10 is a diagram for explaining a state restoration process; [Figure 18] FIG. 10 is a diagram for explaining a state restoration process; [Figure 19] FIG. 10 is a diagram for explaining a state restoration process; [Figure 20] FIG. 10 is a diagram for explaining a state restoration process; [Figure 21] FIG. 10 is a diagram for explaining a state restoration process; [Figure 22] FIG. 10 is a diagram for explaining a state restoration process; [Figure 23] FIG. 10 is a diagram for explaining a state restoration process; [Figure 24] FIG. 10 is a diagram for explaining a state restoration process; [Figure 25] An example of the time attack mode screen [Figure 26] An example of the survival mode screen [Figure 27] An example of the survival mode screen [Figure 28] An example of the survival mode screen [Figure 29] An example of the survival mode screen [Figure 30] An example of the survival mode screen [Figure 31] An example of the survival mode screen [Figure 32] An example of the tournament mode screen [Figure 33] A memory map showing an example of various data stored in the storage unit 1002 of the server 1000. [Figure 34] An example of the data structure of the entry data 302 [Figure 35] A memory map showing an example of various data stored in the DRAM 85 of the game device 1. [Figure 36] Flowchart showing details of time attack mode processing [Figure 37] Flowchart showing details of time attack mode processing [Figure 38] Flowchart showing details of state restoration processing [Figure 39] Flowchart showing details of survival mode processing [Figure 40] Flowchart showing details of survival mode processing [Figure 41] Flowchart showing details of survival mode processing [Figure 42] Flowchart showing details of tournament mode processing [Figure 43] Flowchart showing details of tournament mode processing [Figure 44] A flowchart showing details of the server process executed by the server 1000. DETAILED DESCRIPTION OF THE INVENTION

[0037] An embodiment will be described below. Fig. 1 is a schematic diagram showing an overall image of an information processing system according to this embodiment. The information processing system of this embodiment includes a plurality of game devices 1 and a server 1000. The server 1000 and the game devices 1 are configured to be able to communicate with each other via a network such as the Internet. This embodiment illustrates game processing that is executed in such a configuration, with each game device 1 communicating with the server 1000 as necessary.

[0038] [Server hardware configuration] Next, the hardware configuration of the server 1000 will be described. FIG. 2 is a block diagram showing the hardware configuration of the server 1000. The server 1000 includes at least a processor 1001, a storage unit 1002, and a communication unit 1003. The processor 1001 executes various programs for controlling each server. The storage unit 1002 stores various programs executed by the processor 1001 and various data used by the processor 1001. The communication unit 1003 is connected to a network via wired or wireless communication, and transmits and receives predetermined data to and from the game device 1. Note that while the present embodiment illustrates an example in which there is one server 1000, the server 1000 may be a single server or may be configured as a group of servers performing distributed processing.

[0039] Next, the game device 1 will be described. An example of the game device 1 in this embodiment is a game device including a main unit 2, a left controller 3, and a right controller 4. The left controller 3 and the right controller 4 are each detachable from the main unit 2. In other words, the game device 1 can be used as an integrated device by attaching the left controller 3 and the right controller 4 to the main unit 2. The game device 1 can also be used with the main unit 2, the left controller 3, and the right controller 4 separate from each other (see FIG. 4).

[0040] FIG. 3 is a diagram showing an example of a state in which the left controller 3 and the right controller 4 are attached to the main unit 2. As shown in FIG. 3, the left controller 3 and the right controller 4 are each attached to the main unit 2 and integrated together. The main unit 2 is a device that executes game processing. The main unit 2 includes a display 12. The left controller 3 and the right controller 4 are devices that include operation units that allow the player to perform inputs.

[0041] Figure 4 is a diagram showing an example of the state in which the left controller 3 and the right controller 4 are detached from the main unit 2. As shown in Figures 3 and 4, the left controller 3 and the right controller 4 are detachable from the main unit 2. Note that, below, the left controller 3 and the right controller 4 may be collectively referred to as "controllers."

[0042] Fig. 5 is a six-sided view showing an example of the main unit 2. As shown in Fig. 5, the main unit 2 includes a substantially plate-shaped housing 11. In this embodiment, the main surface of the housing 11 (in other words, the front surface, i.e., the surface on which the display 12 is provided) is generally rectangular.

[0043] The shape and size of the housing 11 are arbitrary. As an example, the housing 11 may be of a portable size. Furthermore, the main unit 2 alone or an integrated device in which the left controller 3 and right controller 4 are attached to the main unit 2 may be a portable device. Furthermore, the main unit 2 or the integrated device may be a handheld device. Furthermore, the main unit 2 or the integrated device may be a portable device.

[0044] As shown in Fig. 6, the main unit 2 includes a display 12 provided on the main surface of the housing 11. The display 12 displays images generated by the main unit 2. In this embodiment, the display 12 is a liquid crystal display (LCD). However, the display 12 may be any type of display device.

[0045] The main device 2 also includes a touch panel 13 on the screen of the display 12. In this embodiment, the touch panel 13 is of a type that allows multi-touch input (for example, a capacitance type). However, the touch panel 13 may be of any type, and may be of a type that allows single-touch input (for example, a resistive type).

[0046] The main unit 2 is provided with a speaker (i.e., speaker 88 shown in FIG. 7) inside the housing 11. As shown in FIG. 5, speaker holes 11a and 11b are formed in the main surface of the housing 11. The output sound of the speaker 88 is output from these speaker holes 11a and 11b, respectively.

[0047] The main unit 2 also has a left terminal 17, which is a terminal for the main unit 2 to communicate with the left controller 3 via a wired connection, and a right terminal 21, which is a terminal for the main unit 2 to communicate with the right controller 4 via a wired connection.

[0048] As shown in FIG. 5, the main unit 2 includes a slot 23. The slot 23 is provided on the upper side of the housing 11. The slot 23 has a shape that allows a predetermined type of storage medium to be inserted therein. The predetermined type of storage medium is, for example, a storage medium (e.g., a dedicated memory card) dedicated to the game device 1 and the same type of information processing device. The predetermined type of storage medium is used, for example, to store data used by the main unit 2 (e.g., application save data, etc.) and / or programs executed by the main unit 2 (e.g., application programs, etc.). The main unit 2 also includes a power button 28.

[0049] The main unit 2 has a lower terminal 27. The lower terminal 27 is a terminal through which the main unit 2 communicates with the cradle. In this embodiment, the lower terminal 27 is a USB connector (more specifically, a female connector). When the all-in-one device or the main unit 2 alone is placed on the cradle, the game apparatus 1 can display images generated and output by the main unit 2 on a stationary monitor. In this embodiment, the cradle also has the function of charging the all-in-one device or the main unit 2 alone that is placed on it. The cradle also has the function of a hub device (specifically, a USB hub).

[0050] FIG. 6 is a six-sided view showing an example of the left controller 3. As shown in FIG. 6, the left controller 3 includes a housing 31. In this embodiment, the housing 31 has a vertically long shape, that is, a shape that is long in the up-down direction in FIG. 6 (the z-axis direction shown in FIG. 6). The left controller 3 can also be held in a vertically long orientation when detached from the main unit 2. The housing 31 has a shape and size that allows it to be held in one hand, particularly the left hand, when held in a vertically long orientation. The left controller 3 can also be held in a horizontally long orientation. When the left controller 3 is held in a horizontally long orientation, it may be held with both hands.

[0051] The left controller 3 is equipped with a left analog stick (hereinafter referred to as the left stick) 32, which is an example of a directional input device. As shown in FIG. 6, the left stick 32 is provided on the main surface of the housing 31. The left stick 32 can be used as a directional input unit that can input directions. By tilting the left stick 32, the player can input a direction corresponding to the tilt direction (and input a magnitude corresponding to the tilt angle). Note that the left controller 3 may be equipped with a cross key or a slide stick that can perform slide inputs, instead of an analog stick, as a directional input unit. In this embodiment, input can be made by pressing down the left stick 32.

[0052] The left controller 3 is equipped with various operation buttons. The left controller 3 is equipped with four operation buttons 33 to 36 (specifically, a right button 33, a down button 34, an up button 35, and a left button 36) on the main surface of the housing 31. The left controller 3 is also equipped with a record button 37 and a - (minus) button 47. The left controller 3 is equipped with a first L button 38 and a ZL button 39 on the upper left of the side of the housing 31. The left controller 3 is also equipped with a second L button 43 and a second R button 44 on the side of the housing 31 that is attached to the main unit 2. These operation buttons are used to issue instructions according to various programs (for example, OS programs and application programs) executed on the main unit 2.

[0053] The left controller 3 also includes a terminal 42 for wired communication between the left controller 3 and the main unit 2.

[0054] FIG. 7 is a six-sided view showing an example of the right controller 4. As shown in FIG. 7, the right controller 4 includes a housing 51. In this embodiment, the housing 51 has a vertically long shape, that is, a shape that is long in the up-down direction in FIG. 7 (the z-axis direction shown in FIG. 6). The right controller 4 can also be held in a vertically long orientation when detached from the main unit 2. The housing 51 has a shape and size that allows it to be held in one hand, particularly the right hand, when held in a vertically long orientation. The right controller 4 can also be held in a horizontally long orientation. When the right controller 4 is held in a horizontally long orientation, it may be held with both hands.

[0055] Like the left controller 3, the right controller 4 is equipped with a right analog stick (hereinafter referred to as the right stick) 52 as a directional input unit. In this embodiment, the right stick 52 has the same configuration as the left stick 32 of the left controller 3. The right controller 4 may also be equipped with a cross key or a slide stick capable of slide input, instead of an analog stick. Like the left controller 3, the right controller 4 is equipped with four operation buttons 53 to 56 (specifically, an A button 53, a B button 54, an X button 55, and a Y button 56) on the main surface of the housing 51. The right controller 4 is further equipped with a + (plus) button 57 and a home button 58. The right controller 4 is also equipped with a first R button 60 and a ZR button 61 on the upper right side of the housing 51. Like the left controller 3, the right controller 4 is also equipped with a second L button 65 and a second R button 66.

[0056] The right controller 4 also includes a terminal 64 for wired communication between the right controller 4 and the main unit 2.

[0057] Fig. 8 is a block diagram showing an example of the internal configuration of main unit 2. In addition to the configuration shown in Fig. 5, main unit 2 includes components 81-91, 97, and 98 shown in Fig. 8. Some of these components 81-91, 97, and 98 may be mounted on an electronic circuit board as electronic components and housed in housing 11.

[0058] The main unit 2 includes a processor 81. The processor 81 is an information processing unit that executes various types of information processing executed in the main unit 2, and may be composed of, for example, only a CPU (Central Processing Unit), or may be composed of an SoC (System-on-a-chip) that includes multiple functions such as a CPU function and a GPU (Graphics Processing Unit) function. The processor 81 executes various types of information processing by executing an information processing program (for example, a game program) stored in a storage unit (specifically, an internal storage medium such as flash memory 84, or an external storage medium inserted into slot 23, etc.).

[0059] The main device 2 includes a flash memory 84 and a DRAM (Dynamic Random Access Memory) 85 as examples of internal storage media built into the main device 2. The flash memory 84 and the DRAM 85 are connected to the processor 81. The flash memory 84 is a memory used primarily to store various types of data (which may be programs) saved in the main device 2. The DRAM 85 is a memory used to temporarily store various types of data used in information processing.

[0060] The main device 2 includes a slot interface (hereinafter abbreviated as "I / F") 91. The slot I / F 91 is connected to the processor 81. The slot I / F 91 is connected to the slot 23, and reads and writes data from and to a predetermined type of storage medium (e.g., a dedicated memory card) inserted into the slot 23 in accordance with instructions from the processor 81.

[0061] The processor 81 reads and writes data from and to the flash memory 84, DRAM 85, and the above-mentioned storage media as appropriate, to execute the above-mentioned information processing.

[0062] The main unit 2 includes a network communication unit 82. The network communication unit 82 is connected to the processor 81. The network communication unit 82 communicates with external devices via a network (specifically, wireless communication). In this embodiment, the network communication unit 82 connects to a wireless LAN and communicates with external devices using a method conforming to the Wi-Fi standard as a first communication mode. The network communication unit 82 also performs wireless communication with other main units 2 of the same type using a predetermined communication method (e.g., communication using a proprietary protocol or infrared communication) as a second communication mode. Note that wireless communication using the second communication mode enables wireless communication with other main units 2 located within a closed local network area, and realizes a function that enables so-called "local communication," in which data is transmitted and received by direct communication between multiple main units 2.

[0063] The main unit 2 is equipped with a controller communication unit 83. The controller communication unit 83 is connected to the processor 81. The controller communication unit 83 performs wireless communication with the left controller 3 and / or right controller 4. Any communication method may be used between the main unit 2 and the left controller 3 and right controller 4, but in this embodiment, the controller communication unit 83 performs communication with the left controller 3 and right controller 4 in accordance with the Bluetooth (registered trademark) standard.

[0064] The processor 81 is connected to the left terminal 17, right terminal 21, and lower terminal 27. When performing wired communication with the left controller 3, the processor 81 transmits data to the left controller 3 via the left terminal 17 and receives operation data from the left controller 3 via the left terminal 17. When performing wired communication with the right controller 4, the processor 81 transmits data to the right controller 4 via the right terminal 21 and receives operation data from the right controller 4 via the right terminal 21. When performing wired communication with the right controller 4, the processor 81 transmits data to the cradle via the lower terminal 27. As described above, in this embodiment, the main unit 2 can perform both wired and wireless communication with the left controller 3 and the right controller 4. When an integrated device in which the left controller 3 and the right controller 4 are attached to the main unit 2 or the main unit 2 alone is attached to the cradle, the main unit 2 can output data (e.g., image data and audio data) to a stationary monitor or the like via the cradle.

[0065] Here, the main unit 2 can communicate simultaneously (in other words, in parallel) with multiple left controllers 3. The main unit 2 can also communicate simultaneously (in other words, in parallel) with multiple right controllers 4. Therefore, multiple players can simultaneously input to the main unit 2 using their own sets of left controllers 3 and right controllers 4. For example, a first player can input to the main unit 2 using a first set of left controllers 3 and right controllers 4, while a second player can simultaneously input to the main unit 2 using a second set of left controllers 3 and right controllers 4.

[0066] The main device 2 includes a touch panel controller 86, which is a circuit that controls the touch panel 13. The touch panel controller 86 is connected between the touch panel 13 and the processor 81. Based on a signal from the touch panel 13, the touch panel controller 86 generates data indicating, for example, the position where a touch input was made, and outputs the data to the processor 81.

[0067] The display 12 is also connected to the processor 81. The processor 81 displays on the display 12 an image generated (for example, by executing the above-described information processing) and / or an image acquired from the outside.

[0068] The main unit 2 includes a codec circuit 87 and speakers (specifically, a left speaker and a right speaker) 88. The codec circuit 87 is connected to the speakers 88 and the audio input / output terminal 25, and is also connected to the processor 81. The codec circuit 87 is a circuit that controls the input and output of audio data to and from the speakers 88 and the audio input / output terminal 25.

[0069] The main device 2 includes a power control unit 97 and a battery 98. The power control unit 97 is connected to the battery 98 and the processor 81. Although not shown, the power control unit 97 is also connected to each part of the main device 2 (specifically, each part that receives power from the battery 98, the left terminal 17, and the right terminal 21). The power control unit 97 controls the power supply from the battery 98 to each of the above parts based on instructions from the processor 81.

[0070] Furthermore, battery 98 is connected to lower terminal 27. When an external charging device (e.g., a cradle) is connected to lower terminal 27 and power is supplied to main device 2 via lower terminal 27, battery 98 is charged with the supplied power.

[0071] Figure 9 is a block diagram showing an example of the internal configuration of the main unit 2, left controller 3, and right controller 4. Note that details of the internal configuration of the main unit 2 are omitted in Figure 9 because they are shown in Figure 8.

[0072] The left controller 3 is equipped with a communication control unit 101 that communicates with the main unit 2. As shown in FIG. 9 , the communication control unit 101 is connected to each component, including the terminal 42. In this embodiment, the communication control unit 101 can communicate with the main unit 2 both via wired communication via the terminal 42 and via wireless communication without using the terminal 42. The communication control unit 101 controls the communication method used by the left controller 3 with the main unit 2. That is, when the left controller 3 is attached to the main unit 2, the communication control unit 101 communicates with the main unit 2 via the terminal 42. When the left controller 3 is detached from the main unit 2, the communication control unit 101 performs wireless communication with the main unit 2 (specifically, the controller communication unit 83). Wireless communication between the controller communication unit 83 and the communication control unit 101 is performed in accordance with, for example, the Bluetooth (registered trademark) standard.

[0073] The left controller 3 also includes a memory 102, such as a flash memory. The communication control unit 101 is configured, for example, by a microcomputer (also called a microprocessor), and executes firmware stored in the memory 102 to perform various processes.

[0074] The left controller 3 includes buttons 103 (specifically, buttons 33 to 39, 43, 44, and 47). The left controller 3 also includes a left stick 32. Each button 103 and left stick 32 repeatedly outputs information relating to an operation performed on that button 103 and left stick 32 to the communication control unit 101 at an appropriate timing.

[0075] The left controller 3 is equipped with an inertial sensor. Specifically, the left controller 3 is equipped with an acceleration sensor 104. The left controller 3 is also equipped with an angular velocity sensor 105. In this embodiment, the acceleration sensor 104 detects the magnitude of acceleration along three predetermined axes (for example, the x, y, and z axes shown in FIG. 6). The acceleration sensor 104 may detect acceleration along one or two axes. In this embodiment, the angular velocity sensor 105 detects angular velocity around three predetermined axes (for example, the x, y, and z axes shown in FIG. 6). The angular velocity sensor 105 may detect angular velocity around one or two axes. The acceleration sensor 104 and the angular velocity sensor 105 are each connected to the communication control unit 101. The detection results of the acceleration sensor 104 and the angular velocity sensor 105 are repeatedly output to the communication control unit 101 at appropriate timing.

[0076] The communication control unit 101 acquires information about the input (specifically, information about the operation or the detection results by the sensors) from each input unit (specifically, each button 103, left stick 32, and each sensor 104 and 105). The communication control unit 101 transmits operation data including the acquired information (or information obtained by performing a predetermined process on the acquired information) to the main unit 2. The operation data is repeatedly transmitted once every predetermined time. The interval at which the information about the input is transmitted to the main unit 2 may or may not be the same for each input unit.

[0077] By transmitting the above operation data to the main unit 2, the main unit 2 can obtain the input made to the left controller 3. That is, the main unit 2 can determine the operation of each button 103 and left stick 32 based on the operation data. Furthermore, the main unit 2 can calculate information regarding the movement and / or posture of the left controller 3 based on the operation data (specifically, the detection results of the acceleration sensor 104 and the angular velocity sensor 105).

[0078] The left controller 3 is equipped with a power supply unit 108. In this embodiment, the power supply unit 108 has a battery and a power control circuit. Although not shown, the power control circuit is connected to the battery and to each part of the left controller 3 (specifically, each part that receives power from the battery).

[0079] As shown in FIG. 9, the right controller 4 is equipped with a communication control unit 111 that communicates with the main unit 2. The right controller 4 also has a memory 112 that is connected to the communication control unit 111. The communication control unit 111 is connected to each component, including the terminal 64. The communication control unit 111 and memory 112 have the same functions as the communication control unit 101 and memory 102 of the left controller 3. Therefore, the communication control unit 111 can communicate with the main unit 2 both via wired communication via the terminal 64 and via wireless communication that does not use the terminal 64 (specifically, communication in accordance with the Bluetooth (registered trademark) standard), and controls the method of communication that the right controller 4 uses with the main unit 2.

[0080] The right controller 4 has input units similar to those of the left controller 3. Specifically, it has buttons 113, a right stick 52, and inertial sensors (an acceleration sensor 114 and an angular velocity sensor 115). These input units have the same functions as those of the left controller 3, and operate in the same manner.

[0081] The right controller 4 is equipped with a power supply unit 118. The power supply unit 118 has the same functions as the power supply unit 108 of the left controller 3 and operates in the same manner.

[0082] [Outline of information processing in this embodiment] Next, an overview of the operation of information processing according to this embodiment will be described. In this embodiment, the following game processing will be assumed as an example of information processing. The game assumed in this embodiment is a time attack game. In this game, a plurality of different games called "races" are prepared. Each race has a clearing condition set, and users compete to see who can achieve the clearing condition of each race (hereinafter referred to as the clear time) from the start of the race. In other words, this game is a game in which clear times are evaluated. The evaluation may involve, for example, presenting the clear time by comparing it with past records, or, if there is an opponent, determining the ranking based on the clear time.

[0083] The "competition" will now be described in more detail. First, in this embodiment, various games realized as competitions are executed using an emulator program. That is, in this embodiment, the emulator program is executed to emulate a predetermined game process executed on a predetermined game device. The predetermined game device is an existing game device separate from the game device 1. In this embodiment, an 8-bit CPU game device is assumed as an example of this predetermined game device. Hereinafter, this game device will be referred to as the "target game machine to be emulated." Herein, the game device 1 assumed in this embodiment has higher processor performance and image processing performance than the target game machine to be emulated. Herein, the game to be emulated (hereinafter, the "target game to be emulated") was originally an existing game for the target game machine to be emulated. The game software medium is, for example, provided as a cartridge or disc. In this embodiment, multiple target games to be emulated are used. In this embodiment, data for each target game to be emulated is stored in the DRAM 35 as a game ROM 324, which will be described later. The game ROM 324 is then loaded into the emulator program, and the game program contained in the game ROM 324 is executed to execute each emulation target game. In this embodiment, when each emulation target game is executed, correspondences between predetermined buttons on the controller and various buttons on the controller of the emulation target game machine are predefined. For example, input of the A button 53 on the right controller is treated as input of the A button on the controller of the emulation target game machine.

[0084] Next, a game executed as a competition utilizes a portion of the emulation target game. For example, suppose that a certain emulation target game is a side-scrolling action game. Suppose one of the multiple stages included in the game has a stage configuration as shown in FIG. 10. In this embodiment, the competition may utilize only a portion of the stage, for example, a portion approximately near the center of the stage in FIG. 10. FIG. 11 shows an example screen related to the competition. FIG. 11 is a game image related to a portion of the stage, displaying a player character (hereinafter abbreviated as PC) 201 and multiple items 202. A competition utilizing this scene may be provided in which participants compete to acquire all of the multiple items 202 in the shortest time. Therefore, the processing related to the competition involves loading a game state corresponding to the scene shown in FIG. 11 into an emulator and starting emulation from this point. In other words, the competition does not start from the beginning of the stage, but from a scene midway through the stage, as shown in FIG. 11. In this example, the game state is the state of the memory of the emulation target game machine at a predetermined timing, saved as data (hereinafter referred to as competition start data). In the following explanation, the memory of the emulation target game machine reproduced on the DRAM 85 of the game device 1 is referred to as the emulator memory. The scene at which the competition starts based on the competition start data is referred to as the "competition start scene."

[0085] As another example of using the stages in a competition, one of the multiple stages may be used in its entirety. Also, for example, a competition may be held that spans multiple stages. For example, if the game to be emulated contains a total of eight stages, a competition may be held that uses only the second and third stages.

[0086] Various conditions can be set for determining whether the clear condition has been met, depending on the competition. In the example of FIG. 11, whether all of the multiple items 202 have been acquired is determined, for example, by monitoring a specific address in the emulator memory. This specific address is, for example, an address that stores a value that can change depending on whether all of the multiple items 202 have been acquired. When the value of this specific address becomes a value indicating that all of the multiple items 202 have been acquired, it is determined that the clear condition has been met. Hereinafter, this specific address will be referred to as a "clear determination address." The clear determination address may be multiple addresses or a combination thereof. In this way, in this embodiment, a competition is performed using a portion or scene of the emulated game. A game is provided in which players compete to see who can achieve the clear condition set for each competition in the shortest time.

[0087] Here, we will provide some specific examples of competitions other than those described above. First, there is a competition in which the clearing condition is defeating a specific enemy character. The enemy character is, for example, a boss character. To give a specific example, assume that the emulation target game is an action RPG with a bird's-eye view. The game includes a stage composed of multiple areas, as shown in FIG. 12 . Game play in the stage begins in the first area, and the stage is cleared by moving the PC 201 to the boss area and defeating the boss character. In the game, each area is displayed as a single game screen, and as the player moves through the areas, the screen scrolls area by area. For example, when the PC 201 reaches the right edge of the first area, the screen scrolls to the left edge of the second area. One competition using an emulation target game that includes such a stage is a competition in which the competition begins when the PC 201 enters the boss area, as shown in FIG. 13 , and participants compete to see who can defeat the boss character the fastest. In other words, the competition uses only the boss area portion of the stage. In this case, the scene immediately after entering the boss area will be the start of the competition.

[0088] Another example of a competition is a competition in which players compete to see who can reach a predetermined point in the game stage in the shortest time. In such a competition, the competition starts when the player character is at a predetermined position in the stage. The competition starts from that point, and the clearing condition is when the PC 201 reaches the predetermined point. For example, in the example of a stage configured as shown in FIG. 12, the competition starts when the PC 201 is in the second area, and players compete to see who can reach the fourth area in the shortest time.

[0089] Another example of a competition is one in which participants compete to see who can transform PC 201 in the shortest time possible. For example, consider a game to be emulated in which PC 201 transforms by acquiring a specific item. In such a game, the competition begins from a start scene in which PC 201 is in a state before transformation, and participants compete to see who can complete the transformation in the shortest time possible after acquiring the specific item.

[0090] Here, a supplementary note will be provided regarding operation inputs to the emulator processing in this embodiment. In this embodiment, in addition to operation data output from the controller, "operation history information" can also be used as input to the emulator processing. This operation history information is data in which the user's operation details are recorded as key log data. As will be described in detail later, in this embodiment, in the game processing described below, the emulator processing is executed using the operation history information of other users, thereby reproducing the play details of other users in the competition. As will be described later, by displaying an emulator screen reproducing the play details of other users and an emulator screen generated by the user's own operations in parallel, it is possible to provide a playing experience that feels like playing against other users in the same competition. Furthermore, the user's own operation history information can also be used as the operation history information. In this case, emulator screens reproducing the user's past play details are displayed in parallel, providing a playing experience that feels like playing against one's past self.

[0091] [Screenshots of the competition] Next, an example of a game screen when the emulation target game is played as the competition is shown in Fig. 14. In Fig. 14, an emulator screen 210, an operation information image 213, and elapsed time information 214 are displayed.

[0092] The emulator screen 210 is a display area where a game image based on the processing results of the emulator is displayed. When operation data output from the controller is used as input in the emulator processing, an emulator screen processed based on the operation data is displayed. Also, when operation history information is used as input as described above, an emulator screen processed based on the operation history information is displayed.

[0093] The operation information image 213 is an image that resembles the controller of the emulator target game machine. The operation information image 213 is an image for visually displaying the operation content input to the emulator. For example, the operation information image 213 visually indicates to the user which key or button is currently being pressed by changing the display color of the button operated by the 1P user. For example, as shown in FIG. 15, the operation information image 213 indicates that the button is being pressed by changing the display color or display mode of the portion corresponding to the pressed button.

[0094] The elapsed time information 214 is a counter that indicates the elapsed time from the start of the competition.

[0095] [About the rewind function] As described above, this game involves competing to see who can clear the game the fastest, and the elapsed time from the start of the game is measured. In this regard, for example, consider a game in which an enemy character appears and the PC 201 makes a mistake when it touches the enemy character. While this game is a time attack game, even if a mistake is made, the game is not ended immediately. Instead, the game state is automatically restored to the state before the mistake occurred and play is resumed. In other words, if a game state occurs in which the clearing condition of the game cannot be achieved, such as when a mistake is made, the game state is automatically restored to the state before the mistake occurred and play continues until the clearing condition is achieved. In this example, it is assumed that the emulation target game machine does not have such a function. Therefore, this control is performed as processing of a game program that controls the overall game processing according to this embodiment, including emulator control. Furthermore, in this game, the measurement of the elapsed time includes the time required for the transition of the game state. In other words, even if a mistake is made during the game, the game is automatically restarted until the clearing condition is achieved, and the time required for the restart is included in the measurement of the clearing time.

[0096] Note that, in the same way as in the case of determining the clear condition, the determination of whether the above-mentioned clear condition has been achieved is made by monitoring a specific address in the emulator memory. Hereinafter, the address to be monitored will be referred to as the "return determination address." There may be multiple addresses for the return determination address. Furthermore, the process of transitioning the game state to the previous state will be referred to as the "state return process." Furthermore, the conditions that make it necessary to perform the state return process, such as the occurrence of the above-mentioned mistake, will be referred to as the "redo condition."

[0097] Furthermore, in this embodiment, the state revert process is not initiated immediately after the replay condition is satisfied, but rather after a predetermined waiting time has elapsed. Here, the waiting time may be set to a different time depending on the game. By providing such a waiting time, the user can more reliably recognize that the replay condition has been satisfied. In other words, if the state revert process is initiated immediately after the replay condition is satisfied, depending on the timing and the game situation, the state revert process may appear to the user to have started suddenly, which may confuse the user and prevent them from understanding why the revert occurred. Therefore, by providing the above-described waiting time when the replay condition is satisfied, the user can recognize that the replay condition has been satisfied, for example, when the PC 201 makes contact with an enemy character and makes a mistake.

[0098] An example of the operation of the rewind function will be described below with reference to Figs. 16 to 24. Here, an example where the PC 201 comes into contact with an enemy character will be described as an example of a replay condition. That is, an example is shown in which the PC 201 comes into contact with an enemy character, and then after a waiting time, the game state is rewound to the state before the contact. Note that the point to which the game state is transitioned in the state rewind process may differ depending on the game to be emulated.

[0099] FIG. 16 shows an example of a 1P game screen and elapsed time information 214 at the start of a predetermined game. In FIG. 16, a PC 201, a terrain object 204, and an enemy character 205 are displayed. From this state, it is assumed that the PC 201 is moved onto the terrain object as shown in FIG. 17. At this time, the enemy character 205 is also approaching the PC 201. Here, it is assumed that the user wants to make the PC 201 jump from the terrain object 204 so as to jump over the enemy character 205. However, it is assumed that the jump operation is not performed properly, and the PC 201 falls from the terrain object 204, causing the enemy character 205 to collide with the PC 201, as shown in FIG. 18. The occurrence of this collision means that a mistake has occurred, and the replay condition is satisfied.

[0100] After this, after a predetermined waiting time has elapsed, the state return process is initiated. If the emulation target game is configured to display a miss animation upon contact with an enemy character, the emulator process will play back the miss animation during the waiting time. In other words, the emulator process itself continues to run during the waiting time. Figure 19 shows an example in which such a miss animation playback process is executed during the waiting time. After that, once the waiting time has elapsed, the state return process is initiated. Depending on the length of the waiting time that has been set, the state return process may start in the middle of the miss animation. Alternatively, the waiting time may be set in advance so that the state return process starts when the miss animation ends.

[0101] 20 to 22 are examples of screens during the state return process. FIG. 20 also shows a reverse playback mark and a horizontal line effect image indicating that the game state is being transitioned to the previous state. FIG. 20 shows a state in which the game state has transitioned to just before the PC 201 and the enemy character 205 come into contact with each other. The game state transitions further from this state, and FIG. 21 shows the game state transitioned to just before the PC 201 falls from the land object 204. Finally, as shown in FIG. 22, the state transitions to a state in which the PC 201 has moved to the top of the land object 204, at which point the state return process ends. During this state return process, user operations on the PC 201 are not accepted. Once the state return process is complete, operations on the PC 201 can be accepted, and play resumes. Thereafter, as shown in FIG. 23, the user can continue the game by making the PC 201 jump over the enemy character 205.

[0102] FIG. 24 shows an example of the relationship between the clear time and the state reset process. FIG. 24 shows a game in which two mistakes are made before the game is cleared. In FIG. 24, the state reset process is initiated due to the first mistake six seconds after the start of the game. This state reset process takes two seconds. The elapsed time continues to be measured during this state reset process (see, for example, FIGS. 20 to 22 above). Play then resumes eight seconds after the start of the game, and state reset process is initiated due to the second mistake at 20 seconds. Play then resumes 22 seconds after the state reset process ends, and the clear condition is finally achieved in 35 seconds. This 35-second clear time includes the four seconds required for the two state reset processes.

[0103] The specific method of the state revert process is not limited, but the state revert process in this example is performed as follows. In this example, the game state, in this case the state of the emulation memory, is saved for several to several tens of frames during the processing of each frame in the emulation process. The number of frames saved may vary depending on the game being emulated. In the state revert process, first, the game processing on the emulator is paused, and then the saved game state is loaded into the emulation memory frame by frame in chronological order, and the emulator images are displayed in sequence. This controls the gameplay content immediately before the replay condition is satisfied to be played back in reverse and displayed. Then, when the transition to the point at which the game is to be resumed is reached, the emulator processing is resumed.

[0104] In the above-mentioned state return process, the speed at which the game transitions to the previous state (i.e., reverse playback speed) may be displayed as transitioning to the previous state at the same speed as in normal play, or may be displayed as transitioning at a different speed such as double speed or triple speed. When displaying the transition at a different speed, the saved game state may be read by skipping two frames at a time, for example, at double speed.

[0105] In addition to the above-described collision with the enemy character 205, other modes of the retry condition include the following. For example, the retry condition may be determined to be satisfied when the PC 201 collides with a predetermined object other than the enemy character 205 that inflicts damage on the PC 201. Furthermore, a parameter called a "stamina value" may be provided for the PC 201, and the retry condition may be determined to be satisfied when the PC 201 receives damage and the stamina value becomes 0. The retry condition may also be determined to be satisfied when the PC 201 falls into a pitfall, as described below. Examples other than "mistakes" include the following. First, in a competition where obtaining a predetermined item is an essential condition for clearing the game, the retry condition may be determined to be satisfied when the PC 201 moves to a position where the item cannot be obtained. Furthermore, for example, in a competition using a scene where the course branches midway, the retry condition may be determined to be satisfied when it is determined that the PC 201 has entered a course or area where the clearing condition cannot be achieved. Furthermore, in a competition where the clearing condition is that the PC 201 is in a specific state, if the specific state is changed, it may be determined that the retry condition has been met.

[0106] Furthermore, in this example, the state restoration process not only restores the game state frame by frame as described above, but also performs a "restart" process depending on the game situation. For example, suppose one of the above-mentioned retry conditions is that PC 201 falls into a pitfall and moves off the stage. When this condition is met, the elapsed time is not reset, but is continued to be measured and the game is restarted from the start of the competition. In other words, the game state is not restored frame by frame, but is restarted from the beginning. In this case, the restart may be performed over several seconds, for example, with a blackout effect. In this case, the time required for the restart effect is included in the measurement of the elapsed time. In addition, when other unexpected behavior occurs, the retry condition may be treated as being satisfied, and the game may be restarted.

[0107] In the following explanation, with regard to the above-mentioned state rewind processing, the processing of rewinding the game state by a predetermined number of frames will be referred to as the "rewind processing," and the processing of restarting from the start of the competition will be referred to as the "restart processing."

[0108] Furthermore, multiple types of retry conditions may be set for one competition. For example, two retry conditions may be set for a certain competition: one for when the character collides with an enemy character 205 and the other for when the character falls into a pitfall, and the above-mentioned "return determination address" corresponding to each condition may be defined. Furthermore, the state return process executed when each condition is satisfied may be either a rewind process or a restart process. For example, within the same competition, a rewind process may be executed when the character collides with an enemy character 205, and a restart process may be executed when the character falls into a pitfall.

[0109] [About the game modes in this game] As described above, the game according to this embodiment is a time attack game in which players compete to achieve clear conditions using a portion of the emulation target game. In this embodiment, three game modes are provided for this game. Specifically, three game modes are provided: (1) time attack mode, (2) survival mode, and (3) tournament mode. In this embodiment, the user's operation history information is saved and uploaded to the server 1000 in each mode. Furthermore, when playing each mode, operation history information corresponding to the competition being played, which is saved in the server 1000, is downloaded from the server 1000 as needed. As described above, by using the operation history information as operation input in the emulator process, an emulator screen can be displayed that reproduces the play content of the user or other users in the past.

[0110] Below, an overview of each mode will be explained.

[0111] [Time Attack Mode] First, the time attack mode (hereinafter abbreviated as TA mode) will be described. TA mode is a game mode in which a user (hereinafter referred to as the 1P user) plays alone, selecting a predetermined event and playing that event. FIG. 25 shows an example of a game screen related to the TA mode. In FIG. 25, the screen is largely divided into left and right halves, with a 1P emulator screen 211 displayed on the left and an emulator screen (hereinafter referred to as the replay screen) 112 based on the 1P user's own operation history information displayed on the right. The 1P emulator screen 211 displays a game image based on the processing results of an emulator (hereinafter referred to as the 1P emulator) that operates based on the 1P user's operation input. The replay screen 212 is based on the processing results of an emulator (hereinafter referred to as the 1P replay emulator) that operates based on the 1P user's operation history information. Therefore, the state shown in FIG. 25 is a state in which processing related to two emulators, the 1P emulator and the 1P replay emulator, is being executed in parallel.

[0112] Here, the operation history information used for the 1P user is the operation history information that records the play that resulted in the player's personal best time in the competition being played (hereinafter referred to as "personal best play"). In other words, the TA mode provides the user with a playing experience that is similar to playing against themselves when they achieved their best time.

[0113] 25, operation information images 213A and 213B are displayed below the 1P emulator screen 211 and the replay screen 212, respectively. The operation information image 213A presents the operation content of the 1P user. The operation information image 213B presents the operation content related to the personal best play. That is, the display content of the operation information image 213B changes based on the operation history information related to the personal best play.

[0114] In the following description, the 1P emulator screen 211 and operation information image 213A may be collectively referred to as the "1P game screen." The replay screen 212 and operation information image 213B may be collectively referred to as the "1P replay screen." The entire game screen, including the 1P game screen, 1P replay screen, and elapsed time information 214, as shown in FIG. 25, may be referred to as the "TA mode screen."

[0115] Next, an overview of the processing in the TA mode will be described. In the TA mode, the processing related to the two emulators is executed in parallel as described above. The 1P emulator controls the operation of the PC 201 based on the operation of the 1P user. The 1P replay emulator controls the operation of the PC 201 based on the operation history information related to the personal best play. When the competition starts, the processing related to the 1P emulator and the processing related to the 1P replay emulator are started simultaneously and executed in parallel. In this embodiment, since the processing related to the 1P emulator and the processing related to the 1P replay emulator are started simultaneously, it is possible to prevent a time lag from occurring between the 1P game screen and the 1P replay screen. This makes it possible to play in a state where it is easy to accurately compare the player's current play with their personal best play. Furthermore, if the clear time is updated as a result of the play, the operation history information treated as the personal best play is also updated.

[0116] The 1P replay screen is based on the 1P user's operation history information, and if a rewind process occurs during a personal best play, the 1P replay screen will reproduce the 1P user's play, including this rewind process. As a result, images related to the rewind process may also be displayed on the 1P replay screen.

[0117] [About Survival Mode] Next, an overview of survival mode (hereinafter abbreviated as SV mode) will be described. SV mode is a game mode in which the 1P user competes in a knockout tournament against, for example, up to seven opponents. The knockout tournament is a game consisting of a set of multiple competitions, with the first round being competition A, the second round being competition B, and the final round being competition C, and so on. FIGS. 26 to 28 show examples of game screens in SV mode (hereinafter referred to as SV mode screens). FIG. 26 shows an example screen of the first round, FIG. 27 shows an example screen of the second round, and FIG. 28 shows an example screen of the final round. In FIG. 26, a 1P emulator screen 211 and an operation information image 213A are displayed. Also, 2P emulator screens 222 to 8P emulator screens 228, which are emulator screens for the opponents, are displayed, each having the same size as the 1P emulator screen 211. Also, operation information images 213B to 213H are displayed for each opponent in the operation information image 213. Hereinafter, the 2P emulator screen 222 to the 8P emulator screen 228 and the operation information images 213B to 213H may be collectively referred to as opponent screens. Elapsed time information 214 is also displayed in the lower left corner of the screen. In SV mode, one emulator process is assigned to each opponent. In the example shown in FIG. 26, eight emulator processes are running in parallel. FIG. 27 shows a second round being played by four users who won the first round. In FIG. 27, in the same screen layout as FIG. 26, game screens are displayed on the emulator screens of the four users who won, while no game screen is displayed on the emulator screens of eliminated users (emulator processes are stopped). Note that the emulator screens of eliminated users may display a predetermined message indicating their elimination. In addition, FIG. 28 shows a final round being played by two users who won the second round. In the same screen layout as FIG. 26, the game screens of eliminated users are not displayed.

[0118] The layout of each emulator screen from the second round onwards may be such that emulator screens of eliminated users are not displayed. For example, in the second round, only the emulator screens of the four winning users may be displayed in a horizontal row, as shown in FIG. 29. Alternatively, although not shown, they may be displayed in a 2x2 layout. Furthermore, in the final round, for example, only the emulator screens of the two users who won the second round may be displayed horizontally, as shown in FIG. 30. In either case, each emulator screen is displayed at the same size.

[0119] [About opponents in SV mode] Here, opponents in SV mode will be described. In the SV mode of this embodiment, emulator processing related to opponents is performed based on operation history information related to other users downloaded from the server 1000 as described above. The downloaded operation history information of other users is, for example, the most recent operation history information uploaded to the server and used in SV mode. The 2P emulator screens 222 to 228 each display an image generated by emulator processing based on the downloaded operation history information. In other words, opponents in SV mode are not other live users, but rather data reproducing the play of other users. Using such data, the play of other users is reproduced and displayed in parallel with the play of the 1P user, providing a sense of tension similar to that of a real-time online battle. Furthermore, in the SV mode, for example, when an eight-person battle is desired, the waiting time required for other users to join the battle can be reduced, allowing the tournament to begin promptly. Furthermore, the same operation history information of opponents is used for each competition constituting the tournament during the same tournament. For example, if the operation history information of user B is used as the opponent, the operation history information of user B is used in both the first and second rounds of the competition, thereby providing a playing experience in which the player feels as if they are playing against the same opponent throughout the knockout tournament.

[0120] As described above, in SV mode, emulator processing is performed for the opponent based on the operation history information of other users. Therefore, as part of the processing of the game program that controls the entire SV mode, each emulator process monitors the "clear determination address" and the "return determination address." Then, each emulator process determines whether the game has been cleared or whether the state return process should be performed. Therefore, an image related to the state return process may also be displayed on the opponent screen.

[0121] Furthermore, since SV mode is a knockout tournament, rankings are determined in the order in which the clearing conditions are met. Then, for example, a ranking image is displayed on the emulator screen for which the clearing conditions have been met, as shown in FIG. 31. FIG. 31 shows that the rankings have been determined up to fourth place, and the remaining four players are still playing. Each ranking image shows the clear time and ranking. The ranking images are displayed superimposed on each emulator screen. In other words, they are not displayed as a function of the game console being emulated, but are displayed by processing of the game program that controls the entire SV mode.

[0122] In this example, if the 1P user does not win, he or she is considered to have lost, and the process related to the tournament ends there. In other words, the process of watching the tournament until the final round is not performed after the 1P user is defeated. In other embodiments, the 1P user may be able to watch the tournament until the final round even after being defeated.

[0123] [About Tournament Mode] Next, the tournament mode will be described. This mode allows a user to play a predetermined competition and transmit the play results (hereinafter, "play record") to the server 1000. Hereinafter, transmitting one's own play record to the server 1000 is referred to as "entry." The play record includes at least the above-mentioned operation history information, clear time information, and information about the user who transmitted it. The play records transmitted to the server 1000 are tallied over a predetermined period, such as one week. The tallied results for each competition are then announced at each predetermined interval, and the tallied results can be viewed on a viewing screen (not shown) in the tournament mode.

[0124] FIG. 32 shows an example of a screen in the tournament mode. This screen is an example of a screen on which the 1P user enters a predetermined competition. In FIG. 32, only the 1P game screen in the TA mode is displayed. Although not shown, before this screen is displayed, a screen for selecting a predetermined competition is displayed, and the 1P user can select the predetermined competition he or she wishes to enter from the selection screen. The 1P user plays the predetermined competition on this screen. Then, when the competition is cleared, a play record is generated based on the clear time and transmitted to the server 1000. Furthermore, the transmitted play record can be used as an "opponent" in the SV mode executed on another game device 1.

[0125] The processing according to this embodiment will be described in detail below.

[0126] Next, various data used by the server 1000 and the game device 1, and the processes performed by each, will be described in detail.

[0127] [Data used by Server 1000] First, a description will be given of the data used by the server 1000. Fig. 33 is a memory map showing an example of various data stored in the storage unit 1002 of the server 1000. The storage unit 1002 of the server 1000 stores at least a server program 301, entry data 302, and aggregated data 303.

[0128] The server program 301 is a program for executing server processing including a process for receiving and tallying play records, and a process for transmitting operation history information to a predetermined game device 1 for the SV mode.

[0129] The entry data 302 is data that records the play records transmitted from each game device 1. FIG. 34 shows an example of the data configuration of the entry data 302. The entry data 302 is a database that includes multiple play records 311. Each play record 311 includes at least a user ID 312, a competition ID 313, clear time information 314, operation history information 315, and entry date and time 316. The user ID 312 is an ID for identifying the user who transmitted the play record. The competition ID 313 is an ID for identifying which competition the play record pertains to. The clear time information 314 is information indicating the clear time of the competition related to the play record 311. The operation history information 315 is information indicating the operation history related to the play record 311. The entry date and time 316 is information indicating the date and time when the play record 311 was transmitted to the server 1000.

[0130] 33, the aggregated data 303 is data based on the results of aggregating the play records for each game. The contents of the aggregated data 303 are updated at predetermined intervals, such as once a week.

[0131] [Data used in game device 1] Next, a description will be given of data used in the game device 1. Fig. 35 is a memory map showing an example of various data stored in the DRAM 85 of the game device 1. The DRAM 85 of the game device 1 stores at least an overall control program 321, an emulator program 322, a game ROM data storage area 323, an emulator work area 325, and a management area 327.

[0132] The overall control program 321 is a program for managing and controlling the overall game processing according to this embodiment, including the processing of the TA mode, SV mode, and tournament mode.

[0133] The emulator program 322 is a program that emulates the operation of the game machine to be emulated.

[0134] The game ROM storage area 323 is an area for storing ROM data of the emulation target game. In this embodiment, a plurality of game ROMs 324 are stored. Each game ROM 324 includes a game program and game image data for executing game processing related to the emulation target game. The game program runs on the virtual emulation target game machine realized by execution of the emulator program 322.

[0135] The emulator work area 325 stores a plurality of emulator memory areas 326, corresponding to the number of the multiple emulators executed simultaneously. Each emulator memory area 326 is a memory space corresponding to the memory installed in the emulator target game machine. In this embodiment, when the emulator program 322 starts to execute, a process of loading a game ROM 324 is performed, and various data included in the game ROM 324 is read into the emulator memory area 326 corresponding to each emulator. In the following description, the emulator memory area 326 for each emulator will be referred to as the "nth emulator memory area." For example, the emulator memory area 326 corresponding to a 1P emulator will be referred to as the "first emulator memory area."

[0136] Various data used in processes other than emulator processing is stored in the management area 327. Specifically, the management area 327 stores 1P operation data 328, current operation history information 329, personal best information 330, other users' operation history information 331, entry play record 332, competition content definition data 333, state return buffer 334, return flag 335, etc.

[0137] The 1P operation data 328 is data obtained from the controller operated by the 1P user, that is, data indicating the operation content performed by the 1P user.

[0138] The current operation history information 329 is data that records the operation details of the 1P user related to the game currently being played.

[0139] The personal best information 330 is data that stores, for each competition, the clear time related to the 1P user's personal best play and operation history information at that time (hereinafter, personal best operation history).

[0140] The other user operation history information 331 is data to be used as the opponent's operation history information in the SV mode. The other user operation history information 331 is downloaded from the server 1000 and stored at a predetermined timing.

[0141] The entry play record 332 is the play record to be transmitted to the server 1000 in the tournament mode.

[0142] The competition content definition data 333 is data that defines the content of the various competitions described above. Specifically, the competition content definition data 333 includes summary information, start scene information, clear condition information, and replay-related information. The summary information includes information specifying the emulation target game used in the competition and information specifying the scene used in the competition. The start scene information includes game state data corresponding to the competition start scene (hereinafter, competition start scene data). The clear condition information includes the clear condition and information on the "clear determination address." The replay-related information includes the following information. First, information on the "rewind determination address" is included. The data also includes definitions of one or more of the rewind conditions and information specifying the mode of the state rewind process corresponding to each rewind condition. The data also includes information indicating the waiting time from when the rewind condition is satisfied until the state rewind process actually starts. The data also includes information indicating the number of frames of the game state to be stored for the rewind process, i.e., information indicating how far to rewind when performing the rewind process (hereinafter, "rewind frame number information").

[0143] The state rewind buffer 334 is an area for temporarily storing the game state used when a rewind process is performed as the state rewind process. The state rewind buffer 334 stores the game state from the present to a predetermined number of frames ago. The capacity of the state rewind buffer 334 may be determined based on the rewind frame count information.

[0144] The return flag 335 is a flag for indicating whether or not the above-mentioned state return process is to be executed in the process described later.

[0145] Next, an example of a flowchart of game processing in this embodiment will be described.

[0146] [Details of Processing Executed by Processor 81 of Game Device 1] First, we will explain the processing that is performed by the game device 1. As mentioned above, this game has three game modes: TA mode, SV mode, and tournament mode, and the processing corresponding to each mode is started when the 1P user selects an item corresponding to each mode from a predetermined menu screen (not shown). Below, we will explain the details of the processing for each mode in the order of TA mode, SV mode, and tournament mode.

[0147] [TA mode processing details] 36 and 37 are flowcharts showing the details of the TA mode processing. First, in step S11, processor 81 displays a game selection screen (not shown) and selects the game to be played this time based on 1P operation data 328.

[0148] Next, in step S12, processor 81 prepares to start the selected competition. Specifically, processor 81 allocates a first emulator memory area corresponding to the 1P emulator and a second emulator memory area corresponding to the 1P replay emulator. Next, processor 81 loads game ROM 324 data related to the competition into each emulator memory area 326. Next, processor 81 acquires the competition start scene data, the clear condition information, and the replay-related information corresponding to the selected competition from competition content definition data 333. Furthermore, processor 81 appropriately sets the size of state rewind buffer 334, etc., based on the rewind frame count information included in the replay-related information. Furthermore, processor 81 acquires personal best operation history corresponding to the competition from personal best information 330. Furthermore, processor 81 loads the competition start scene data into each emulator memory area 326 and sets the state of the emulator target game to the game state of the competition start scene. At this time, the operation of the emulator is stopped. Then, processor 81 generates a 1P emulator screen 111 and a personal best screen 112 relating to the competition start scene.

[0149] Next, in step S13, the processor 81 generates a TA screen including the operation information image 113 and the elapsed time information 114, and outputs it to the display unit 5.

[0150] Next, in step S14, processor 81 displays a countdown effect (not shown) for the start of the competition. After the countdown ends, processor 81 starts processing related to the 1P emulator (hereinafter referred to as 1P emulator processing) and processing related to the 1P replay emulator (hereinafter referred to as 1P replay emulator processing). Furthermore, processor 81 also starts measuring the operation history information of the 1P user and the elapsed time. This marks the start of the competition.

[0151] Next, in step S15, processor 81 determines whether return flag 335 is on. If the result of this determination is that return flag 335 is off (NO in step S15), in step S17, processor 81 acquires 1P operation data 328. Then, processor 81 executes 1P emulator processing based on the operation content indicated by this data. As a result, 1P emulator screen 111 is generated. In addition, processor 81 records the content of 1P operation data 328 in current operation history information 329.

[0152] Next, in step S18, processor 81 determines whether the retry condition is satisfied based on the value of the "address for return determination." If the result of this determination is that the condition is not satisfied (NO in step S18), then in step S22 of Figure 28, processor 81 determines whether the condition for clearing the game is satisfied based on the value of the "address for clear determination." If the result of this determination is that the condition is not yet satisfied (NO in step S22), then in step S24, processor 81 stores the game state of the 1P emulator at this point in time in state return buffer 334.

[0153] Next, in step S26, processor 81 continues to measure the elapsed time. Next, in step S28, processor 81 records the operation content indicated by the 1P operation data in current operation history information 329.

[0154] Next, in step S30, processor 81 updates the display content of operation information image 113A based on 1P operation data 328. Furthermore, processor 81 also updates the display content of elapsed time information 114.

[0155] Next, in step S31, processor 81 executes 1P replay emulator processing. Specifically, processor 81 operates PC 201 in the 1P replay emulator based on the personal best operation history, and executes various associated game processes. At this time, processor 81 also determines whether the redo condition is satisfied in the 1P replay emulator. If satisfied, processor 81 executes a state return process, described below, on the 1P replay emulator. Processor 81 also determines whether a clear condition is satisfied, and if satisfied, stops the 1P replay emulator. At this time, processor 81 also performs settings to display the clear time superimposed on the personal best screen. Then, processor 81 generates personal best screen 112 based on the results of these processes.

[0156] Next, in step S32, the processor 81 generates the TA screen and outputs it to the display unit 5. Thereafter, the process returns to step S15, and the process is repeated.

[0157] Next, the process when the result of the determination in step S18 above is that the redo condition is satisfied (YES in step S18) will be described. In this case, in step S19, it is determined whether the waiting time defined in the redo condition information has elapsed since the redo condition was satisfied. If the waiting time has not elapsed (NO in step S19), the process proceeds to step S26 above. On the other hand, if the waiting time has elapsed (YES in step S19), then in step S20, processor 81 sets return flag 335 to ON. Furthermore, processor 81 determines the processing mode of the state return processing based on the redo condition information. In this example, it is assumed that either the rewind processing or the restart processing is determined.

[0158] Next, in step S21, the processor 81 temporarily suspends the progress of the 1P emulator process, after which the process proceeds to step S26.

[0159] Next, the process when, as a result of the determination in step S15 above, return flag 335 is on (YES in step S15) will be described. In this case, in step S16, processor 81 executes state return processing. FIG. 38 is a flowchart showing the details of this state return processing. First, in step S41, processor 81 determines whether the processing mode of the state return processing determined in step S20 above is rewind processing or not. If the result of this determination is rewind processing (YES in step S41), in step S43, processor 81 refers to state return buffer 334, and loads the game state one frame before the current game state into the 1P emulator memory area. Then, processor 81 generates a 1P emulator screen based on this state.

[0160] Next, in step S45, processor 81 determines whether the game state has been rewound to the timing at which the rewind process should be terminated. This timing is determined, for example, based on the rewind frame count information. If the result of this determination is that the game state has been rewound to the timing at which the rewind process should be terminated (YES in step S45), then in step S47, processor 81 sets rewind flag 335 to OFF. Furthermore, in step S48, processor 81 resumes the 1P emulator process that was paused. Thereafter, the rewind process ends.

[0161] On the other hand, if it is not yet time to end the rewinding process (NO in step S45), the processes in steps S47 and S48 are skipped and the rewinding process ends.

[0162] On the other hand, if the result of the determination in step S41 above is that the processing mode of the state return processing determined in step S20 above is not rewind processing (NO in step S41), restart processing is executed. First, in step S42, processor 81 performs settings to display a restart effect on 1P emulator screen 111 during a predefined waiting time until restart (hereinafter, restart waiting time). The restart effect is, for example, an effect in which the screen is darkened during the restart waiting time.

[0163] Next, in step S44, processor 81 determines whether or not the restart waiting time has elapsed, and if not (NO in step S44), ends the return process. On the other hand, if the restart waiting time has elapsed (YES in step S44), in step S46, processor 81 loads the competition start scene data into the 1P emulator memory area and generates 1P emulator screen 111. This displays a screen in which PC 201 is in the competition start scene. Thereafter, processing proceeds to step S47.

[0164] Returning to FIG. 36, once the state restoration process is completed, the process proceeds to step S26.

[0165] Next, the processing when the clear condition is met as a result of the determination in step S22 above (YES in step S22) will be described. In this case, first, in step S23, processor 81 stops measuring the elapsed time and determines the clear time for this competition. Processor 81 also stops recording of operation history information. Next, in step S25, processor 81 stops the 1P emulator processing. Furthermore, processor 81 displays a clear effect, for example, superimposed on the 1P emulator screen.

[0166] Next, in step S27, processor 81 compares personal best information 330 with the confirmed current clear time, and determines whether or not the personal best clear time has been updated. If the result of this determination is that the personal best clear time has been updated (YES in step S27), in step S29, processor 81 updates the content of personal best information 330 with the clear time for the current competition and the operation history information. At this time, the 1P user may be asked whether or not to transmit the current record to server 1000. If the 1P user instructs that the information should be transmitted, the operation history information, etc. may be transmitted to server 1000. On the other hand, if the personal best clear time has not been updated (NO in step S27), the processing of step S29 is skipped. Thereafter, processor 81 ends the TA mode processing.

[0167] [SV mode processing] Next, the details of the SV mode processing will be explained. Figures 39 to 41 are flowcharts showing the details of the SV mode processing. Note that in these flowcharts, some of the processing is the same as in the TA mode processing described above, so the same reference numerals are used for the same processing and detailed explanations will be omitted. Here, the parts that are different from the TA mode processing will mainly be explained.

[0168] 39, first, in step S51, processor 81 displays a tournament selection screen (not shown) and selects the tournament to be played this time based on 1P operation data 328.

[0169] Next, in step S52, processor 81 requests operation history information of an opponent in SV mode from server 1000. In response to the request, server 1000 selects operation history information of the opponent. Then, processor 81 downloads the operation history information selected by server 1000. The downloaded operation history information is stored in DRAM 85 as other user operation history information 331.

[0170] Note that, in this embodiment, an example has been shown in which operation history information is downloaded in step S52 above, but the timing for downloading the operation history information is not limited to this. For example, in the process of starting the game according to this embodiment (for example, before the title screen is displayed, etc.), operation history information corresponding to all the sports in SV mode may be downloaded in advance from the server 1000 and stored in the DRAM 85. Then, in step S52 above, the process may simply involve reading the other user's operation history information 331 that has been downloaded in advance.

[0171] Next, in step S53, processor 81 prepares emulator processing for the opponents in the current round of competition. Specifically, similar to the processing in step S12 above, a first emulator memory area corresponding to the 1P emulator is allocated, and emulator memory areas 326 corresponding to the number of opponents are also allocated. Processor 81 then loads data from game ROM 324 related to the current competition into each emulator memory area 326. Processor 81 also acquires various information related to the current competition from competition content definition data 333. Processor 81 then loads competition start scene data into each emulator memory area 326 and generates each emulator screen related to the competition start scene.

[0172] Next, in step S54, the processor 81 generates the SV screen including the operation information image 113 and the elapsed time information 114, and outputs it to the display unit 5.

[0173] Next, in step S55, processor 81 performs a countdown effect to start the competition, and then starts 1P emulator processing and processing related to the emulators of each opponent (hereinafter collectively referred to as opponent emulator processing). Furthermore, processor 81 also starts measuring elapsed time.

[0174] Next, as shown in Figures 40 and 41, the processes of steps S15 to S30 are executed. That is, the processes related to the 1P user are executed. Note that in SV mode, the operation history of the 1P user may not be recorded.

[0175] Next, after step S30 in FIG. 41, in step S58, processor 81 executes opponent emulator processing based on the opponent's operation history information. In this processing, the same processing as in the 1P emulator described above is basically performed. Therefore, the state return processing described above is also executed as necessary. However, in this processing, recording of operation history and measurement of elapsed time are not performed. As a result of the opponent emulator processing, an emulator screen for each opponent is generated. Furthermore, if the clear condition is achieved in the opponent's emulator processing, processor 81 stops the emulator processing for that opponent. Processor 81 also performs settings to superimpose the ranking image (see FIG. 31) on the emulator screen for each opponent. The clear time may be displayed based on other user operation history information 331, or measurement of the elapsed time for each opponent may be started in the processing of step S55 described above and the measured time may be displayed.

[0176] Next, in step S60, the processor 81 generates an SV screen including the above-mentioned emulator screens and outputs it to the display unit 5. Thereafter, the process returns to step S15, and the process is repeated.

[0177] Next, the processing performed after step S25 in FIG. 41 will be described. That is, the processing after the 1P user has achieved the clear condition will be described. After the processing of step S25, in step S56, processor 81 determines the ranking of the 1P user and superimposes the ranking image on the 1P emulator screen. Next, in step S57, processor 81 determines whether all of the opponents for this competition have achieved the clear condition. If the result of this determination is that there is an opponent who has not yet achieved the clear condition (NO in step S57), in step S59, processor 81 continues various processes related to that opponent until all of the opponents have achieved the clear condition.

[0178] On the other hand, if all of the opponents have achieved the clear condition (YES in step S57), in step S61, processor 81 displays a final result screen showing the final rankings of the current competition, etc.

[0179] Next, in step S62, processor 81 determines whether user 1P has won the current competition (whether user 1P has defeated the opponent in the case of the final). If the result of this determination is that user 1P has not won the current competition (NO in step S62), processor 81 displays a defeat effect or the like and then terminates the SV mode processing. On the other hand, if user 1P has won the current competition (YES in step S62), processor 81 determines in step S63 whether all competitions related to the current tournament have ended. If the result of this determination is that they have not yet ended, the process returns to step S53, and the above-described processing is performed for the next competition. On the other hand, if all competitions have ended, processor 81 displays a final results screen for the tournament and then terminates the SV mode processing.

[0180] [Tournament mode processing] Next, the details of the tournament mode processing will be explained. Figures 42 and 43 are flowcharts showing the details of the tournament mode processing. Note that even in these flowcharts, some of the processing is the same as the TA mode processing described above, so the same reference numerals will be used for the same processing and detailed explanations will be omitted. Here, the parts that differ from the TA mode processing will mainly be explained.

[0181] 42, first, in step S81, processor 81 displays a game selection screen (not shown) and selects the game that the player wishes to play and enter this time based on 1P operation data 328.

[0182] Next, in step S82, processor 81 prepares to start the competition. Basically, the same processing as in step S12 above is performed, but here, processing related to the personal best screen is omitted.

[0183] Next, in step S83, the processor 81 generates a tournament mode screen as shown in FIG.

[0184] Next, in step S84, processor 81 performs a countdown effect for the start of the competition, and then starts 1P emulator processing. Furthermore, processor 81 also starts measuring the elapsed time.

[0185] After that, various processes related to the 1P user are executed in steps S15 to S30. Unlike the TA mode, after step S30, processor 81 generates a tournament mode screen and outputs it to display unit 5 in step S86.

[0186] Furthermore, after user 1P achieves the clear condition and the clear effect is displayed in step S25, in step S85, processor 81 generates entry play record 332 based on the operation history information and clear time recorded this time. Then, processor 81 transmits this entry play record to server 1000. After that, processor 81 ends the tournament mode processing.

[0187] This concludes the detailed description of the processing related to the game device 1.

[0188] [Server 1000 processing] Next, details of the processing executed by the server 1000 will be described. FIG. 44 is a flowchart showing details of the processing related to the server 1000. In FIG. 44, first, in step S91, the processor 1001 of the server 1000 determines whether or not a request for operation history information of an opponent in SV mode has been received from a predetermined game device 1. If not received (NO in step S91), the process proceeds to step S94, which will be described later. If received (YES in step S91), the processor 1001 selects a user to be the opponent in step S92. The selection method is not limited, and, for example, a user who entered the tournament close to the time the request was received may be given priority. Furthermore, the processor 1001 references the entry data 302 and selects operation history information 315 based on the user ID 312 of the selected user and the competition IDs 313 of each competition constituting the tournament, which are included in the request. As a result, operation history information of the same user is selected for each competition in the tournament.

[0189] Next, in step S93, the processor 1001 transmits the operation history information 315 to the game device 1 that has made the request.

[0190] Next, in step S94, the processor 1001 determines whether or not the entry play record 332 has been received. If the result of this determination is that the entry play record 332 has been received (YES in step S94), the processor 1001 registers the received entry play record 332 in the entry data 302 in step S95. Thereafter, the processor 1001 returns to step S91 and repeats the process. If the entry play record 332 has not been received (Nfd0 in step S94), the process of step S95 is skipped and the process returns to step S91. This concludes the detailed description of the process related to the server 1000.

[0191] As described above, in this embodiment, game processing is performed using an emulator. During this process, not only the emulator processing of the 1P user but also the emulator processing using the operation history information is performed in parallel. The processing results of each emulator are displayed as individual game images. The operation history information can be based on the 1P user's past play content (the TA mode) or on the play content of other users (the SV mode). In the TA mode, the 1P user's past play content is displayed alongside the current play screen, providing an environment that makes it easy to play while comparing the two. In addition, in the SV mode, the SV mode avoids the time-consuming wait for an opponent to join in online play via a network, allowing for a quick start to a (pseudo) multiplayer game. In either mode, the start timing of the game processing related to the 1P user and the game processing using the operation history information is synchronized, providing competitive play without time lags due to, for example, network delays.

[0192] In addition, in the SV mode, the 1P emulator screen and the opponent's emulator screen are displayed at equal sizes, which makes it possible to create a sense of realism similar to that of an offline gaming tournament, where eight game consoles are lined up in the same venue and all game screens are displayed on a single large monitor.

[0193] Furthermore, by displaying the operation information image 113 showing the operation content, it is possible to understand how the 1P user and the opponent operated the controller during their personal best play, which can be used as a reference for operations to shorten the clear time.

[0194] Furthermore, in this embodiment, even if a mistake or the like occurs during a game, the game is not ended at that point, but the game state is transitioned to the state before the mistake occurred, and play continues. In other words, play related to the game continues until the clearing conditions are met. Furthermore, the time taken for the transition of the game state is also included in the measurement of the clear time. This provides an environment where more appropriate measurement can be performed, especially in games where time is a competitive factor, such as time attack.

[0195] [Variations] In the above embodiment, the elapsed time information 114 is displayed in each game mode, but the elapsed time information 114 may be controlled not to be displayed.

[0196] In addition, in the above-mentioned TA mode, an example has been given in which a personal best screen is displayed based on operation history information relating to a personal best play. In other embodiments, in the TA mode, operation history information of other users may be used instead of operation history information relating to a personal best play. For example, operation history information of users ranked high in the results of the tournament mode tally may be downloaded and used. Alternatively, only the replay screen 212 may be displayed, and only the play content may be reproduced using the operation history information.

[0197] In addition, in the TA mode, a plurality of types of competitions may be played as one set.

[0198] In the above embodiment, when the redo condition is satisfied, the state return process is started after a predetermined waiting time has elapsed, such as waiting for the completion of playback of the error animation. In other embodiments, depending on the content of the game, the state return process may be started immediately when the redo condition is satisfied, without providing such a waiting time.

[0199] Furthermore, the operation history information used in the SV mode may be, for example, operation history information recorded in each tournament in a knockout tournament, uploaded to the server 1000, and then downloaded and used. That is, in the SV mode, the operation history information may be managed for each tournament. For example, if a knockout tournament A is made up of tournaments B, C, and D, the operation histories of the 1P user for tournaments B, C, and D may be recorded in the SV mode, and transmitted as a set to the server 1000 for storage. Then, when the operation history information is downloaded to another game device 1, the operation history information of the 1P user for the set of tournaments B, C, and D may be downloaded as the operation history information for the knockout tournament A.

[0200] In the above embodiment, the case where the above game processing is executed by a single game device 1 has been described. The game device 1 may include multiple storage devices and processors. The above game processing may be executed by sharing the processing among these devices. The above processing may also be executed in a distributed system consisting of multiple information processing devices including a server. [Explanation of symbols]

[0201] 1. Game device 2 Main unit 3 Left Controller 4 Right Controller 81 processors 84 Flash memory 85 DRAM 1000 servers 1001 processor 1002 Storage section 1003 Communications Department

Claims

1. A gaming system including a processor, The processor: Start the first game, processing the first game based on a user's operation input; generating a game image including a first image based on the first game; when a game state in the first game satisfies a first condition, transitioning the game state to a state before the first condition was satisfied; When the game state in the first game satisfies a second condition, stopping or terminating processing of the first game. Game system.

2. The game system according to claim 1 , wherein the processor measures the time elapsed from the start of the first game to the satisfaction of the second condition, including the time required for the transition of the game state.

3. 2. The game system according to claim 1, wherein the first condition is a condition that is satisfied when at least one of the following occurs: a playable character that moves based on the operation input falls, receives damage, or enters a location other than a pre-designated location.

4. 2. The game system according to claim 1, wherein the processor stores the game state for each frame from the current frame in the first game up to a predetermined period prior, and when the first condition is satisfied, transitions to the game state at a predetermined frame prior to the first condition being satisfied.

5. 5. The game system according to claim 4, wherein, when the game state satisfies the first condition, the processor transitions to the game state before the first condition was satisfied by sequentially transitioning to the game state of each frame up to the predetermined period prior.

6. 5. The game system according to claim 4, wherein, when the game state satisfies the first condition, the processor transitions the game state to the game state before the first condition was satisfied after a predetermined waiting period has elapsed.

7. The game system according to claim 1 , wherein the processor transitions the game state to a game state at the start of the first game when the game state satisfies the first condition.

8. The game system according to claim 1 , wherein the processor runs the first game using an emulator.

9. The processor: simultaneously starting the first game and at least one second game which is the same as the first game and operates based on operation history information which is a history of operation inputs; processing the at least one second game based on at least one piece of operation history information; generating the game image including at least one second image based on the second game; When the first condition is satisfied in the second game, the game state is transitioned to a game state before the first condition was satisfied; When the second condition is satisfied in the second game, the processing of the second game is stopped or ended. The game system according to claim 1 .

10. The game system according to claim 1 , wherein the processor stores a history of the operation inputs in the first game as the operation history information.

11. The game system according to claim 9 , wherein the processor processes the second game based on the operation history information stored by another of the game systems.

12. 11. The game system according to claim 10, wherein the processor processes the second game based on the operation history information when the time elapsed from the start of the first game until the second condition is satisfied is shortest.

13. 12. The game system according to claim 11, wherein the processor starts the next one of the first games and the second games only when a third condition is satisfied in a series of games in which a plurality of types of the first games and the second games are played consecutively in a predetermined order.

14. 14. The gaming system according to claim 13, wherein the third condition is that, in rankings based on the results of predetermined first and second games in the series of games, the ranking based on the result of the first game is within a predetermined ranking.

15. The game system described in claim 13, wherein the processor processes each of the plurality of types of second games executed in a predetermined order in the series of games based on the operation history information of the plurality of types of second games stored in another single game system.

16. The game system includes: a plurality of game devices each having the processor; and a server; the processor causes the server to upload play record data including information on the elapsed time from the start of the first game until the second condition is satisfied in the first game; The game system according to claim 1 , wherein the server determines rankings based on the uploaded play record data.

17. The processor of the game system Let the first game begin, processing the first game based on a user's operation input; generating a game image including a first image based on the first game; when a game state in the first game satisfies a first condition, transitioning the game state to a state before the first condition was satisfied; when the game state in the first game satisfies a second condition, stopping or terminating the processing of the first game; Game program.

18. 18. The game program according to claim 17, wherein the processor measures the time elapsed from the start of the first game to the satisfaction of the second condition, including the time required for the transition of the game state.

19. 18. The game program according to claim 17, wherein the first condition is a condition that is satisfied when at least one of the following occurs: a playable character that moves based on the operation input falls, receives damage, or enters a location other than a pre-designated location.

20. 18. A game program as described in claim 17, wherein the processor stores the game state for each frame from the current frame in the first game up to a predetermined period before, and when the first condition is satisfied, transitions to the game state at a predetermined frame before the first condition is satisfied.

21. 21. The game program of claim 20, wherein the processor, when the game state satisfies the first condition, transitions to the game state before the first condition was satisfied by sequentially transitioning to the game state of each frame up to the predetermined period prior.

22. 21. The game program according to claim 20, wherein the processor, when the game state satisfies the first condition, transitions the game state to the game state before the first condition was satisfied after a predetermined waiting period has elapsed.

23. 18. The game program according to claim 17, further comprising causing the processor to transition the game state to a game state at the start of the first game when the game state satisfies the first condition.

24. The game program according to claim 17, wherein the program causes the processor to run the first game using an emulator.

25. the processor, simultaneously starting the first game and at least one second game which is the same as the first game and operates based on operation history information which is a history of operation inputs; processing the at least one second game based on at least one piece of operation history information; generating the game image including at least one second game image based on the second game; When the first condition is satisfied in the second game, the game state is transitioned to a game state before the first condition was satisfied; When the second condition is satisfied in the second game, the processing of the second game is stopped or ended; 18. The game program according to claim 17.

26. The game program according to claim 17 , wherein the processor stores a history of the operation input in the first game as the operation history information.

27. The game program according to claim 17 , further comprising causing the processor to process the second game based on the operation history information stored by another of the game systems.

28. 27. The game program according to claim 26, wherein the processor processes the second game based on the operation history information when the time elapsed from the start of the first game to the second condition being satisfied is shortest.

29. 28. The game program according to claim 27, wherein the processor is caused to start the next first game and the next second game in a series of games in which a plurality of types of the first game and the second game are played consecutively in a predetermined order only when a third condition is satisfied.

30. 30. The game program according to claim 29, wherein the third condition is that, in rankings based on results of predetermined first games and second games in the series of games, the ranking based on the result of the first game is within a predetermined ranking.

31. 30. A game program as described in claim 29, which causes the processor to process each of the plurality of types of second games executed in a predetermined order in the series of games based on the operation history information of the plurality of types of second games stored in another single game system.

32. The game system includes: a plurality of game devices each having the processor; and a server; 18. The game program according to claim 17, further comprising causing the processor to upload to the server play record data including information on the elapsed time from the start of the first game until the second condition is satisfied in the first game.

33. The processor of the game system Let the first game begin, processing the first game based on a user's operation input; generating a game image including a first image based on the first game; when a game state in the first game satisfies a first condition, transitioning the game state to a state before the first condition was satisfied; when the game state in the first game satisfies a second condition, stopping or terminating the processing of the first game; Game processing method.

34. 34. The game processing method according to claim 33, wherein the processor measures the time elapsed from the start of the first game to the satisfaction of the second condition, including the time required for the transition of the game state.

35. 34. The game processing method according to claim 33, wherein the first condition is a condition that is satisfied when at least one of the following occurs: a playable character that moves based on the operation input falls, receives damage, or enters a location other than a pre-designated location.

36. 34. The game processing method according to claim 33, wherein the processor stores the game state in each frame from the current frame in the first game up to a predetermined period before, and when the first condition is satisfied, transitions to the game state in a predetermined frame before the first condition is satisfied.

37. 37. The game processing method according to claim 36, wherein, when the game state satisfies the first condition, the processor transitions to the game state before the first condition was satisfied by sequentially transitioning to the game state of each frame up to the predetermined period prior.

38. 37. The game processing method according to claim 36, wherein, when the game state satisfies the first condition, the processor causes the game state to transition to the game state before the first condition was satisfied after a predetermined waiting period has elapsed.

39. 34. The game processing method according to claim 33, wherein the processor causes the game state to transition to the game state at the start of the first game when the game state satisfies the first condition.

40. 34. The method of claim 33, further comprising causing the processor to run the first game using an emulator.

41. the processor, simultaneously starting the first game and at least one second game which is the same as the first game and operates based on operation history information which is a history of operation inputs; processing the at least one second game based on at least one piece of operation history information; generating the game image including at least one second game image based on the second game; When the first condition is satisfied in the second game, the game state is transitioned to a game state before the first condition was satisfied; When the second condition is satisfied in the second game, the processing of the second game is stopped or ended; 34. The game processing method according to claim 33.

42. 34. The game processing method according to claim 33, wherein the processor stores a history of the operation input in the first game as the operation history information.

43. 34. The game processing method according to claim 33, wherein the processor processes the second game based on the operation history information stored by another of the game systems.

44. 43. The game processing method according to claim 42, wherein the processor processes the second game based on the operation history information when the time elapsed from the start of the first game until the second condition is satisfied is shortest.

45. 44. The game processing method according to claim 43, wherein the processor is caused to start the next first game and the next second game in a series of games in which a plurality of types of first games and a plurality of types of second games are played consecutively in a predetermined order only when a third condition is satisfied.

46. 46. The game processing method according to claim 45, wherein the third condition is a condition that, in rankings based on results at the end of predetermined first games and second games in the series of games, the ranking based on the result at the end of the first game is within a predetermined ranking.

47. 46. A game processing method as described in claim 45, wherein the processor processes each of the plurality of types of second games executed in a predetermined order in the series of games based on the operation history information of the plurality of types of second games stored in another single game system.

48. The game system includes: a plurality of game devices each having the processor; and a server; 34. The game processing method according to claim 33, further comprising causing the processor to upload to the server play record data including information on the elapsed time from the start of the first game until the second condition is satisfied in the first game.

49. A gaming device including a processor, The processor: Start the first game, processing the first game based on a user's operation input; generating a game image including a first image based on the first game; When a game state in the first game satisfies a first condition, the game state is transitioned to a state before the first condition was satisfied; When the game state in the first game satisfies a second condition, stopping or terminating processing of the first game. Game device.

50. A gaming system including a processor, The processor: starting a first game that is processed based on a user's operation input and that ends when a first condition is met; measuring the elapsed time from the start of the first game until the first condition is achieved is started at the same time as the start of the first game; generating a game image including a first image based on the first game; When a game state in the first game satisfies a second condition, the game state is automatically transitioned to a state before the second condition was satisfied; A game system that performs an evaluation process to evaluate the elapsed time measured, including the time required to transition the game state, when the first condition is satisfied in the first game.

51. The processor of the game system starting a first game that is processed based on a user's operation input and that ends when a first condition is met; measuring the elapsed time from the start of the first game until the first condition is achieved is started at the same time as the start of the first game; generating a game image including a first image based on the first game; When a game state in the first game satisfies a second condition, the game state is automatically transitioned to a state before the second condition was satisfied; A game program that, when the first condition is satisfied in the first game, performs an evaluation process that evaluates the elapsed time measured, including the time required to transition the game state.

52. The processor of the game system starting a first game that is processed based on a user's operation input and that ends when a first condition is met; measuring the elapsed time from the start of the first game until the first condition is achieved is started at the same time as the start of the first game; generating a game image including a first image based on the first game; When a game state in the first game satisfies a second condition, the game state is automatically transitioned to a state before the second condition was satisfied; A game processing method comprising: when the first condition is satisfied in the first game, performing an evaluation process to evaluate the elapsed time measured, including the time required to transition the game state.

53. A gaming device including a processor, The processor: starting a first game that is processed based on a user's operation input and that ends when a first condition is met; measuring the elapsed time from the start of the first game until the first condition is achieved is started at the same time as the start of the first game; generating a game image including a first image based on the first game; When a game state in the first game satisfies a second condition, the game state is automatically transitioned to a state before the second condition was satisfied; A game device that, when the first condition is satisfied in the first game, performs an evaluation process to evaluate the elapsed time measured, including the time required to transition the game state.

Images