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

Abstract

To provide a game system which makes it easy to compare a game play operating with operation history information with one's own play.SOLUTION: The game system simultaneously starts a first game and one or more second games operating based on operation history information that is a history of operation inputs, processes the first game based on an operation input by a user, processes the one or more second games based on one or more pieces of the operation history information, generates an entire game image including a first game image based on the first game and one or more second game images based on the second games, and suspends or finishes the processing of each game when the game states of the first game and the second games respectively satisfy a first condition.SELECTED DRAWING: Figure 27

Description

Technical Field

[0001] The present disclosure relates to game processing using data recording user operations.

Background Art

[0002] Conventionally, in a competitive racing game, a game is known that reproduces replay data of a player ranked at the top and simultaneously executes gameplay by the player (for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In a game as described above, a pseudo battle with replay data was possible. However, the battle opponent object by reproducing the replay data and the player object operated by the player were displayed within the same game screen (one screen). Therefore, for example, in the case of a racing game, only the battle opponent object by the replay data advanced to the front of the course, and there was also a situation where only the player object was displayed within the game screen. Therefore, it was sometimes difficult to compare, for example, the play state of the player and the play state by the replay data.

Means for Solving the Problems

[0005] In view of the above points, for example, the following configuration examples are disclosed.

[0006] (Configuration 1) Configuration 1 is a game system comprising a processor, the processor simultaneously starts a first game and at least one second game which is the same game as the first game and operates based on operation history information which is a history of operation inputs, processes the first game based on user operation inputs, processes the at least one second game based on at least one piece of operation history information, generates an overall game image which includes a first game image based on the first game and at least one second game image based on the second game, and stops or terminates the processing of each game when the game states of the first game and the second game each satisfy a first condition.

[0007] With the above configuration, the second game is processed based on the operation history information, allowing the game to start without waiting for the opponent to join. Furthermore, the overall game image, which includes both the first and second game images, allows players to compare their own gameplay with that of other users. Additionally, the first and second games start simultaneously. Therefore, in games that use elapsed time from the start of play, for example, the game can proceed in an environment where time measurement is more accurate than in online matches where time lags can occur.

[0008] (Configuration 2) Configuration 2 is the configuration in which the processor generates an overall game image that further includes images showing the time elapsed since the start of the first and second games.

[0009] The above configuration makes it easier to keep track of the elapsed time.

[0010] (Composition 3) Configuration 3 is a configuration in which, after the game states of the first game and the second game each satisfy the first condition, the processor may further generate an overall game image that includes an image showing the time elapsed from the start of each of the first and second games until the first condition is satisfied.

[0011] With the above configuration, the elapsed time until the first condition is met can be tracked for both the user themselves and other users.

[0012] (Composition 4) Configuration 4 is the configuration in which the processor stores the history of operation inputs in the first game as operation history information.

[0013] With the above configuration, the game can be automatically recorded while the user is playing.

[0014] (Composition 5) Configuration 5 is an example where, in Configuration 1, the processor processes the second game based on operation history information stored by another game system.

[0015] With the above configuration, the second game is executed using the operation history of other users, providing a gameplay experience that feels like playing against other users in real time.

[0016] (Composition 6) Configuration 6, in Configuration 5, may further include an overall game image that includes images showing the input for at least one of the first game and the second game.

[0017] The above configuration can serve as a reference for what operations a user should perform.

[0018] (Composition 7) Configuration 7 is the same as in Configuration 1 above, in which the processor may run the first game and the second game using separate emulators.

[0019] (Composition 8) In configuration 8, the processor may instruct the emulator to start the first game and the second game from a predetermined point in a predetermined game.

[0020] According to the above configuration, the first game and the second game that utilize only one scene or a part of a predetermined game can be executed. As a result, diverse first games and second games can be provided by reusing the predetermined game.

[0021] (Configuration 9) In Configuration 9, based on the operation history information in the case where the time elapsed from the start of the first game until the first condition is satisfied is the shortest in the above Configuration 4, the processor may process the second game.

[0022] According to the above configuration, a time attack-style game in which the time until the first condition is satisfied is competed can be provided.

[0023] (Configuration 10) In Configuration 10, in a series of games in which the processor continuously plays a plurality of types of first games and second games in a predetermined order, the processor may start the first game and the second game in the next order only when the second condition is satisfied.

[0024] (Configuration 11) In Configuration 11, in the above Configuration 10, the second condition may be the condition that the rank based on the result of the end of the first game is within a predetermined rank in the rank based on the results of the end of a predetermined first game and second game in a series of games.

[0025] According to the above configuration, a knockout-style game can be provided.

[0026] (Configuration 12) In Configuration 12, in the above Configuration 10, the processor may cause each of the plurality of types of second games executed in a predetermined order in the above series of games to be processed based on the operation history information of the plurality of types of second games stored in another single game system.

[0027] With the above configuration, in a knockout-style game, players can continue to face the same opponent each time they advance, providing a gameplay experience that feels like playing a knockout tournament against the same opponent.

[0028] (Composition 13) Configuration 13 is a configuration in which, in any of the above configurations 1 to 12, the processor may, in each of the first and second games, transition the game state to the game state before the second condition was met if the game state satisfies the second condition.

[0029] With the above configuration, it becomes possible to automatically restart the game when the second condition is met.

[0030] (Composition 14) Configuration 14, in Configuration 13, may measure the time elapsed from the start of the game, including the time related to state transitions, until the first condition is met.

[0031] With the above configuration, in a time-attack style game where time is the limit, the time taken to complete the game, including time spent restarting after making a mistake, can be measured. Furthermore, it is possible to provide a time-attack style game where players can restart as many times as needed until they complete it, and the time taken to complete it can be accurately measured. [Effects of the Invention]

[0032] According to this disclosure, it is possible to provide an environment in which players can compare in real time the gameplay of the second game, which is processed based on the user's input information, with that of the first game, which is processed by the user's own operations. [Brief explanation of the drawing]

[0033] [Figure 1] A schematic diagram showing the overall structure of the game system according to this embodiment. [Figure 2] Block diagram showing the hardware configuration of Server 1000 [Figure 3]This diagram shows an example of the main unit 2 with the left controller 3 and right controller 4 attached. [Figure 4] This diagram shows an example of the state in which the left controller 3 and right controller 4 have been removed from the main unit 2. [Figure 5] A six-view drawing showing an example of the main unit 2. [Figure 6] A six-view drawing showing an example of the left controller 3. [Figure 7] A six-view drawing showing an example of the right controller 4. [Figure 8] Block diagram showing an example of the internal configuration of the main unit 2. [Figure 9] Block diagram showing an example of the internal configuration of the main unit 2, left controller 3, and right controller 4. [Figure 10] A diagram illustrating the competition in this embodiment. [Figure 11] A diagram illustrating the competition in this embodiment. [Figure 12] A diagram illustrating the competition in this embodiment. [Figure 13] A diagram illustrating the competition in this embodiment. [Figure 14] Example of a game screen [Figure 15] Example of an operation information image [Figure 16] Diagram to explain the state restoration process. [Figure 17] Diagram to explain the state restoration process. [Figure 18] Diagram to explain the state restoration process. [Figure 19] Diagram to explain the state restoration process. [Figure 20] Diagram to explain the state restoration process. [Figure 21] Diagram to explain the state restoration process. [Figure 22] Diagram to explain the state restoration process. [Figure 23] Diagram to explain the state restoration process. [Figure 24]Diagram to explain the state restoration process. [Figure 25] An example of the Time Attack mode screen. [Figure 26] An example of a survival mode screen. [Figure 27] An example of a survival mode screen. [Figure 28] An example of a survival mode screen. [Figure 29] An example of a survival mode screen. [Figure 30] An example of a survival mode screen. [Figure 31] An example of a survival mode screen. [Figure 32] Example of a tournament mode screen [Figure 33] A memory map showing an example of various data stored in the storage unit 1002 of server 1000. [Figure 34] An example of the data structure for entry data 302 [Figure 35] A memory map showing an example of various data stored in the DRAM85 of game device 1. [Figure 36] A flowchart showing the details of the time attack mode processing. [Figure 37] A flowchart showing the details of the time attack mode processing. [Figure 38] A flowchart showing the details of the state return process. [Figure 39] A flowchart illustrating the details of the survival mode process. [Figure 40] A flowchart illustrating the details of the survival mode process. [Figure 41] A flowchart illustrating the details of the survival mode process. [Figure 42] Flowchart showing details of tournament mode processing [Figure 43] Flowchart showing details of tournament mode processing [Figure 44] A flowchart showing the details of the server processing performed on server 1000. [Modes for carrying out the invention]

[0034] The following describes one embodiment. Figure 1 is a schematic diagram showing the overall structure of the 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 communicate with each other via a network such as the Internet. In this embodiment, we will illustrate game processing that is performed by each game device 1 communicating with the server 1000 as needed in this configuration.

[0035] [Server hardware configuration] Next, the hardware configuration of the server 1000 will be described. Figure 2 is a block diagram showing the hardware configuration of the server 1000. The server 1000 comprises 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. The communication unit 1003 connects to the network by wired or wireless connection and sends and receives predetermined data to and from the game device 1. In this embodiment, an example of a single server 1000 is shown, but the server 1000 may be a single server or may be configured as a group of servers that perform distributed processing.

[0036] Next, the game device 1 described above will be explained. An example of the game device 1 in this embodiment is a game device that includes a main unit 2, a left controller 3, and a right controller 4. The left controller 3 and the right controller 4 are 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. Alternatively, the game device 1 can be used with the main unit 2 and the left controller 3 and right controller 4 as separate components (see Figure 4).

[0037] Figure 3 shows an example of the main unit 2 with the left controller 3 and right controller 4 attached. As shown in Figure 3, the left controller 3 and right controller 4 are attached to the main unit 2 and integrated together. The main unit 2 is a device that executes game processing. The main unit 2 is equipped with a display 12. The left controller 3 and right controller 4 are devices equipped with operation parts for player input.

[0038] Figure 4 shows an example of the left controller 3 and right controller 4 being removed from the main unit 2. As shown in Figures 3 and 4, the left controller 3 and right controller 4 are detachable from the main unit 2. In the following, the left controller 3 and right controller 4 will be collectively referred to as "controllers".

[0039] Figure 5 is a six-view drawing showing an example of the main unit 2. As shown in Figure 5, the main unit 2 includes a roughly 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 roughly rectangular in shape.

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

[0041] As shown in Figure 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.

[0042] Furthermore, the main unit 2 is equipped with 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 capacitive touch panel). However, the touch panel 13 may be of any type, for example, a type that allows single-touch input (for example, a resistive touch panel).

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

[0044] Furthermore, the main unit 2 is equipped with a left terminal 17, which is a terminal for the main unit 2 to communicate with the left controller 3 via wired connection, and a right terminal 21, which is for the main unit 2 to communicate with the right controller 4 via wired connection.

[0045] As shown in Figure 5, the main unit 2 is equipped with a slot 23. The slot 23 is located 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. The predetermined type of storage medium is, for example, a storage medium (e.g., a dedicated memory card) specifically for the game device 1 and similar information processing devices. 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 is also equipped with a power button 28.

[0046] The main unit 2 is equipped with a lower terminal 27. The lower terminal 27 is a terminal for the main unit 2 to communicate with the cradle. In this embodiment, the lower terminal 27 is a USB connector (more specifically, a female connector). When the integrated device or the main unit 2 alone is placed on the cradle, the game device 1 can display the 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 integrated 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).

[0047] Figure 6 is a six-view drawing showing an example of the left controller 3. As shown in Figure 6, the left controller 3 includes a housing 31. In this embodiment, the housing 31 has a vertically elongated shape, that is, it is long in the vertical direction (the z-axis direction shown in Figure 6). When the left controller 3 is detached from the main device 2, it can also be held in a vertically elongated orientation. The housing 31 is shaped and sized to be held with one hand, especially the left hand, when held in a vertically elongated orientation. The left controller 3 can also be held in a horizontally elongated orientation. When the left controller 3 is held in a horizontally elongated orientation, it may be held with both hands.

[0048] 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 Figure 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 direction. The player can input direction (and magnitude according to the angle of tilt) by tilting the left stick 32. In addition, the left controller 3 may be equipped with a directional pad or a slide stick that allows slide input instead of an analog stick as the directional input unit. Furthermore, in this embodiment, input by pressing the left stick 32 is also possible.

[0049] The left controller 3 is equipped with various operation buttons. The left controller 3 has four operation buttons 33-36 (specifically, a right direction button 33, a down direction button 34, an up direction button 35, and a left direction button 36) on the main surface of the housing 31. Furthermore, the left controller 3 is 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 side of the side of the housing 31. In addition, the left controller 3 is equipped with a second L button 43 and a second R button 44 on the side of the housing 31 that is attached when mounted to the main unit 2. These operation buttons are used to give instructions according to various programs (e.g., OS programs and application programs) executed on the main unit 2.

[0050] Furthermore, the left controller 3 is equipped with a terminal 42 for wired communication between the left controller 3 and the main unit 2.

[0051] Figure 7 is a six-view drawing showing an example of the right controller 4. As shown in Figure 7, the right controller 4 includes a housing 51. In this embodiment, the housing 51 has a vertically elongated shape, that is, it is long in the vertical direction in Figure 7 (the z-axis direction shown in Figure 6). The right controller 4 can also be held in a vertically elongated orientation when detached from the main unit 2. The housing 51 is shaped and sized to be held with one hand, especially the right hand, when held in a vertically elongated orientation. The right controller 4 can also be held in a horizontally elongated orientation. When the right controller 4 is held in a horizontally elongated orientation, it may be held with both hands.

[0052] The right controller 4, like the left controller 3, 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 directional pad or a slide stick capable of slide input instead of the analog stick. The right controller 4, like the left controller 3, is equipped with four operation buttons 53-56 (specifically, A button 53, B button 54, X button 55, and Y button 56) on the main surface of the housing 51. Furthermore, the right controller 4 is 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 side of the housing 51. The right controller 4, like the left controller 3, is also equipped with a second L button 65 and a second R button 66.

[0053] Furthermore, the right controller 4 is equipped with a terminal 64 for wired communication between the right controller 4 and the main unit 2.

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

[0055] The main unit 2 includes a processor 81. The processor 81 is an information processing unit that performs various information processing operations performed in the main unit 2, and may consist of, for example, only a CPU (Central Processing Unit), or it may consist of an SoC (System-on-a-chip) that includes multiple functions such as CPU function and GPU (Graphics Processing Unit) function. The processor 81 performs various information processing operations by executing information processing programs (for example, game programs) stored in a storage unit (specifically, an internal storage medium such as flash memory 84, or an external storage medium installed in slot 23).

[0056] The main unit 2 includes, as an example of an internal storage medium built into itself, a flash memory 84 and a DRAM (Dynamic Random Access Memory) 85. The flash memory 84 and DRAM 85 are connected to the processor 81. The flash memory 84 is a memory mainly used to store various types of data (which may be programs) stored in the main unit 2. The DRAM 85 is a memory used to temporarily store various types of data used in information processing.

[0057] The main unit 2 is equipped with 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 slot 23 and reads and writes data to a predetermined type of storage medium (for example, a dedicated memory card) installed in slot 23, according to instructions from the processor 81.

[0058] The processor 81 performs the above-mentioned information processing by appropriately reading and writing data to and from the flash memory 84 and DRAM 85, as well as to each of the above-mentioned storage media.

[0059] 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, wirelessly). In this embodiment, the network communication unit 82 communicates with external devices by connecting to a wireless LAN using a method compliant with the Wi-Fi standard as a first communication mode. The network communication unit 82 also performs wireless communication with other main unit 2 of the same type using a predetermined communication method (for example, communication using a proprietary protocol or infrared communication) as a second communication mode. The wireless communication using the second communication mode is possible with other main unit 2 located within a closed local network area, and realizes a function that enables so-called "local communication" in which data is sent and received by communicating directly between multiple main unit 2.

[0060] The main unit 2 includes a controller communication unit 83. The controller communication unit 83 is connected to the processor 81. The controller communication unit 83 communicates wirelessly with the left controller 3 and / or the right controller 4. The communication method between the main unit 2 and the left controller 3 and the right controller 4 is arbitrary, but in this embodiment, the controller communication unit 83 communicates with the left controller 3 and with the right controller 4 in accordance with the Bluetooth® standard.

[0061] The processor 81 is connected to the left terminal 17, right terminal 21, and lower terminal 27 described above. When the processor 81 communicates with the left controller 3 via a wired connection, it 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 the processor 81 communicates with the right controller 4 via a wired connection, it 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 the processor 81 communicates with the cradle, it transmits data to the cradle via the lower terminal 27. Thus, in this embodiment, the main unit 2 can perform both wired and wireless communication with the left controller 3 and the right controller 4, respectively. Furthermore, when the left controller 3 and the right controller 4 are mounted on the main unit 2 as an integrated unit, or when the main unit 2 alone is mounted on 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.

[0062] Here, the main unit 2 can communicate simultaneously (in other words, in parallel) with multiple left controllers 3. Furthermore, the main unit 2 can 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 respective sets of left controllers 3 and right controllers 4. For example, while the first player inputs to the main unit 2 using the first set of left controllers 3 and right controllers 4, the second player can input to the main unit 2 using the second set of left controllers 3 and right controllers 4.

[0063] The main unit 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 signals from the touch panel 13, the touch panel controller 86 generates data indicating, for example, the position where a touch input occurred, and outputs it to the processor 81.

[0064] The display 12 is also connected to the processor 81. The processor 81 displays images generated (for example, by performing the above information processing) and / or images acquired from an external source on the display 12.

[0065] 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 terminals 25, as well as to the processor 81. The codec circuit 87 is a circuit that controls the input and output of audio data to the speakers 88 and the audio input / output terminals 25.

[0066] The main unit 2 comprises 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 in the figures, the power control unit 97 is also connected to various parts of the main unit 2 (specifically, the parts that receive power from the battery 98, the left terminal 17, and the right terminal 21). Based on commands from the processor 81, the power control unit 97 controls the power supply from the battery 98 to the aforementioned parts.

[0067] The battery 98 is also connected to the lower terminal 27. When an external charging device (for example, a cradle) is connected to the lower terminal 27 and power is supplied to the main unit 2 via the lower terminal 27, the supplied power charges the battery 98.

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

[0069] The left controller 3 includes a communication control unit 101 that communicates with the main unit 2. As shown in Figure 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 by wired communication via the terminal 42 and by wireless communication without using the terminal 42. The communication control unit 101 controls the method of communication that the left controller 3 performs 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 according to, for example, the Bluetooth® standard.

[0070] The left controller 3 also includes a memory 102, such as flash memory. The communication control unit 101 is composed of, for example, a microcontroller (also called a microprocessor) and performs various processes by executing firmware stored in the memory 102.

[0071] The left controller 3 is equipped with buttons 103 (specifically, buttons 33-39, 43, 44, and 47). The left controller 3 is also equipped with a left stick 32. Each button 103 and the left stick 32 repeatedly output information about the operations performed on them to the communication control unit 101 at appropriate intervals.

[0072] 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 Figure 6). Note that the acceleration sensor 104 may also detect acceleration in 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 Figure 6). Note that the angular velocity sensor 105 may also 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 from the acceleration sensor 104 and the angular velocity sensor 105 are repeatedly output to the communication control unit 101 at appropriate timings.

[0073] The communication control unit 101 acquires information related to input (specifically, information related to operation or detection results from sensors) from each input unit (specifically, each button 103, the 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 processing on the acquired information), to the main unit 2. The operation data is transmitted repeatedly at a rate of once per predetermined time. The interval at which information related to input is transmitted to the main unit 2 may or may not be the same for each input unit.

[0074] When the above operation data is transmitted 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 the left stick 32 based on the operation data. In addition, 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).

[0075] The left controller 3 includes a power supply unit 108. In this embodiment, the power supply unit 108 includes 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).

[0076] As shown in Figure 9, the right controller 4 includes a communication control unit 111 that communicates with the main unit 2. The right controller 4 also includes a memory 112 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 the 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 by wired communication via the terminal 64 and by wireless communication without the terminal 64 (specifically, communication according to the Bluetooth® standard), and controls the method of communication that the right controller 4 performs with the main unit 2.

[0077] The right controller 4 is equipped with the same inputs as the left controller 3. Specifically, it includes buttons 113, a right stick 52, and inertial sensors (accelerometer 114 and angular velocity sensor 115). Each of these inputs has the same function and operates in the same way as the inputs of the left controller 3.

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

[0079] [Overview of information processing in this embodiment] Next, we will describe the operation overview of the information processing according to this embodiment. In this embodiment, as an example of information processing, we will describe a game process as described below. The game assumed in this embodiment is a time attack type game. In this game, there are multiple games called "competitions". Each competition has its own clear conditions, and the user competes to achieve the clear conditions of each competition from the start of the competition (hereinafter referred to as the clear time). In other words, this game is a game in which the clear time is evaluated. This evaluation involves processes such as presenting the clear time in comparison to past records, or, if there are opponents, determining rankings based on the clear time.

[0080] Let's explain the "competition" mentioned above in more detail. First, in this embodiment, the various games implemented as a competition are executed using an emulator program. That is, in this embodiment, the emulator program is executed to emulate a predetermined game process that is performed on a predetermined game device. This predetermined game device is an existing game device different from the game device 1 mentioned above, and in this embodiment, an 8-bit CPU game device is assumed as an example of this predetermined game device. Hereafter, this game device will be referred to as the emulation target game machine. Here, the game device 1 assumed in this embodiment is assumed to have higher processor performance and image processing performance than the emulation target game machine. Here, the game to be emulated (hereinafter referred to as the emulation target game) was originally an existing game for the emulation target game machine. The game software medium was provided as a cartridge and a disk, for example. In this embodiment, multiple emulation target games are used. In this embodiment, the data of each emulation target game is stored in the DRAM 35 as a game ROM 324, which will be described later. Then, the game ROM 324 is loaded into the emulator program, and the game program contained within the game ROM 324 is executed to run each emulated game. In this embodiment, when running each emulated game, the correspondence between a predetermined button on the controller and various buttons on the controller of the emulated game machine is predefined. For example, input of button A 53 on the right controller is treated as input of button A on the controller of the emulated game machine.

[0081] Next, the game played as a competition utilizes a portion of the emulation target game described above. For example, suppose a certain emulation target game is a side-scrolling action game. And suppose one of the multiple stages included in this game has a stage configuration as shown in Figure 10. In this embodiment, the competition may use only a portion of that stage, for example, a portion near the center of the stage in Figure 10. Figure 11 shows an example screen related to the competition. Figure 11 is a game image related to a portion of the above stage, and it is a scene in which a player character (hereinafter abbreviated as PC) 201 and multiple items 202 are displayed. The competition that utilizes this scene is a game in which players compete to see who can acquire all of the multiple items 202 the fastest. Therefore, the processing related to this competition is to load the game state corresponding to a scene like the one in Figure 11 into the emulator and start emulation from this point. In other words, the competition starts not from the beginning of the stage, but from a scene in the middle of the stage, as shown in Figure 11. In this example, the game state is assumed to be the state of the emulated game machine's memory at a predetermined timing, saved as data (hereinafter referred to as "game start data"). In the following explanation, the memory of the emulated game machine reproduced on the DRAM 85 of game device 1 is referred to as emulator memory. The scene in which the game is started based on the above game start data is referred to as the "game start scene".

[0082] In addition, as another example of how to use the stages for the competition, one entire stage from the above-mentioned stages may be used. Alternatively, a competition that spans multiple stages may be held. For example, if the game to be emulated has a total of eight stages, the competition may use only the second and third stages.

[0083] The criteria for determining whether the above clear conditions have been met can be set in various ways depending on the competition. In the example in Figure 11, the determination of whether all of the multiple items 202 have been acquired is, for example, determined by monitoring a specific address in the emulator memory. This specific address is, for example, an address that stores a value that may change depending on whether all of the multiple items 202 have been acquired. When the value at this specific address becomes a value that indicates all of the multiple items 202 have been acquired, it is determined that the clear condition has been met. Hereafter, this specific address will be referred to as the "clear determination address". There may be multiple addresses or combinations thereof as the clear determination address. In this embodiment, the competition is run using a part or a scene of the game to be emulated. The game is provided in which players compete to see who can achieve the clear conditions set for each competition in the shortest amount of time.

[0084] Here, we will give some specific examples of competitions other than those mentioned above. First, there is a competition where the clear condition is to defeat a designated enemy character. This enemy character is, for example, a boss character. To give a specific example, let's assume the emulation target game is an overhead-view action RPG. This game includes stages composed of multiple areas, as shown in Figure 12. In this stage, gameplay starts from the first area, and the stage is cleared by moving PC201 to the boss area and defeating the boss character. Also, in this game, each area is displayed as a single game screen, and when moving between areas, the screen scrolls area by area. For example, when PC201 reaches the right edge of the first area, the screen scrolls to the left edge of the second area. One type of competition using an emulation target game that includes such stages is one in which the competition starts from the moment PC201 enters the boss area, as shown in Figure 13, and the competition is judged on the time it takes to defeat the boss character. In other words, this is a competition that uses only the boss area portion of the above stage. In this case, the scene immediately after entering the boss area is the start of the competition as described above.

[0085] Another example of a competition is one in which players compete to reach a predetermined point within a game stage in the shortest amount of time. In such a competition, for example, the starting point of the competition would be when the player character is in a predetermined position within the stage. The competition then begins from this point, and the clear condition is when PC201 reaches the predetermined point. For example, in the case of a stage structure like that shown in Figure 12 above, the starting point of the competition would be when PC201 is in the second area, and the competition would be to compete to reach the fourth area in the shortest amount of time.

[0086] Another example of a competition is one in which participants compete to see who can change PC201 the fastest. For example, imagine an emulation target game in which PC201 transforms when a specific item is acquired. In such a game, the competition starts from the beginning of the competition when PC201 is in its pre-transformation state, and participants compete to see who can acquire the specified item and complete the transformation the fastest.

[0087] Here, we will provide some supplementary information regarding the operation input to the emulator processing in this embodiment. In this embodiment, in addition to the operation data output from the controller, "operation history information" can also be used as input for the emulator processing. This operation history information is data that records the user's operations as key log data. As will be described in detail later, in this embodiment, in the game processing described below, the gameplay of other users in the above competition can be reproduced by executing the emulator processing using the operation history information of other users. As will be described later, by displaying the emulator screen that reproduces the gameplay of other users and the emulator screen of the user's own operations in parallel, it is possible to provide a gameplay experience that feels like competing against other users in the same competition. It is also possible to use the user's own operation history information as the operation history information. In this case, the emulator screen that reproduces the user's past gameplay will be displayed in parallel, providing a gameplay experience that feels like competing against one's past self.

[0088] [Example of a game screen] Next, Figure 14 shows an example of the game screen when playing the emulated game as part of the above competition. In Figure 14, the emulator screen 210, the operation information image 213, and the elapsed time information 214 are displayed.

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

[0090] The operation information image 213 is an image that mimics the controller of the game console being emulated. This operation information image 213 is an image that visually displays the operations input to the emulator. In the operation information image 213, for example, the display color of the button operated by the 1P user is changed to visually show the user which key or button is currently pressed. For example, as shown in Figure 15, in the operation information image 213, the display color and display pattern of the part corresponding to the pressed button are changed to indicate that the button is being pressed.

[0091] The elapsed time information 214 is a counter that shows the elapsed time since the start of the competition.

[0092] [About the rewind function] Here, as described above, this game is a competition to see who can complete it the fastest, and the elapsed time from the start of the competition is measured. In this regard, for example, we envision a competition using a scenario where an enemy character appears, and if PC201 comes into contact with that enemy character, it results in a game over. As described above, this game is a time attack game, but even if a game over occurs, the game state is automatically transitioned to the state before the game over occurred, and play is resumed. In other words, if a game state occurs in which the clear conditions of the competition cannot be met, such as when a game over occurs, the game state is automatically returned to the state before the game over occurred, and play continues until the clear conditions are met. In this example, we assume that the emulated game machine does not have such a function. Therefore, this control is performed as part of the game program that controls the entire game processing according to this embodiment, including emulator control. Furthermore, in this game, the elapsed time is measured including the time taken for the transition of the game state. In other words, even if a game over occurs along the way, the game is controlled to automatically restart until the clear conditions are met, and the clear time is measured including the time taken for the restart.

[0093] Furthermore, the determination of whether the above clear conditions have been met is made by monitoring a specific address in the emulator memory, similar to the determination of the clear conditions. Hereafter, the address to be monitored will be referred to as the "return determination address." There may be multiple return determination addresses. The process of transitioning the game state back to a previous state will be called the "state return process." The conditions that necessitate the state return process, such as the occurrence of the above-mentioned mistake, will be called the "retry condition."

[0094] Furthermore, in this embodiment, the state reverting process is not started immediately after the retry condition is met, but rather after a predetermined waiting time has elapsed. Here, the waiting time may be set to a different duration depending on the competition. By providing such a waiting time, it is possible to make the user more certain that the retry condition has been met. In other words, if the state reverting process is started immediately after the retry condition is met, depending on the timing and the game situation, it may appear to the user that the state reverting process has started abruptly, and the user may be confused as they do not understand why the rollback occurred. Therefore, by providing the above-mentioned waiting time when the retry condition is met, the user is made aware that the retry condition has been met, for example, when PC201 made contact with an enemy character and a mistake occurred.

[0095] The following examples illustrate the operation of the rewind function using Figures 16 to 24. Here, we will explain using the example of PC201 coming into contact with an enemy character as an example of a redo condition. That is, we will show an example where PC201 comes into contact with an enemy character, and then, after a waiting period, the game is rewound to the state before the contact. Note that the point to which the game state is transitioned during this state rewind process may vary depending on the game being emulated.

[0096] Figure 16 shows an example of the 1P game screen and elapsed time information 214 at the start of a given competition. In Figure 16, PC 201, terrain object 204, and enemy character 205 are displayed. Suppose that PC 201 is moved onto the terrain object, as shown in Figure 17. At this time, enemy character 205 is also approaching PC 201. Now, suppose the user wants to make PC 201 jump from terrain object 204 so that it jumps over enemy character 205. However, suppose the jump operation is unsuccessful, and PC 201 falls from terrain object 204, as shown in Figure 18, and PC 201 collides with enemy character 205. This collision results in a mistake, and the condition for restarting is met.

[0097] After this, the state return process will begin after a predetermined waiting period. If the emulated game is designed to display a miss animation when the player comes into contact with an enemy character, the emulator will play this animation during the waiting period. In other words, the emulator continues to run even during the waiting period. Figure 19 shows an example of this miss animation playback process being performed during the waiting period. After the waiting period has elapsed, the state return process will begin. Depending on the length of the set waiting period, the state return process may begin in the middle of the miss animation. Alternatively, the waiting period may be pre-set so that the state return process begins at the same time as the miss animation finishes.

[0098] Figures 20-22 show examples of screens during the state reset process. Figure 20 also shows a reverse playback mark and a horizontal line effect image to indicate that the game state is being reset to a previous state. Figure 20 shows the game state when PC201 is about to make contact with enemy character 205. The game state is reset further from this state, and Figure 21 shows that the game state has reset to just before PC201 falls from terrain object 204. Finally, as shown in Figure 22, the state resets to when PC201 has moved to the top of terrain object 204, and the state reset process ends at this point. During this state reset process, user input on PC201 is not accepted. Once the state reset process is complete, input on PC201 becomes available again, and gameplay resumes. After that, as shown in Figure 23, the user can continue the game by having PC201 jump over enemy character 205.

[0099] Figure 24 shows an example of the relationship between the clear time and the state reset process. Figure 24 shows gameplay where two mistakes occur before clearing the competition. In Figure 24, the state reset process begins 6 seconds after the start of the competition due to the first mistake. This state reset process is assumed to take 2 seconds. The elapsed time is measured continuously during this state reset process (see, for example, Figures 20 to 22 above). Then, gameplay resumes 8 seconds after the start of the competition, and the state reset process begins 20 seconds after the second mistake. Then, gameplay resumes 22 seconds after the state reset process is completed, and the clear condition is finally achieved in 35 seconds. The clear time of 35 seconds includes the 4 seconds spent on the two state reset processes mentioned above.

[0100] While the specific method for the state restoration process described above is not limited, in this example, the state restoration process is performed as follows. In this example, during the processing of each frame in the emulation process, the game state, in this example the state of the emulation memory, is saved for several to tens of frames. The number of frames saved may vary depending on the game being emulated. In the state restoration process, first, the game processing on the emulator is temporarily paused, and then the saved game state is loaded into the emulation memory one frame at a time in reverse chronological order, and the emulator images are displayed sequentially. This controls the system to display the gameplay content immediately before the restart condition is met in reverse. Then, once the system has transitioned to the point where the restart should be resumed, the emulator processing is restarted.

[0101] Regarding the speed at which the game transitions to the previous state during the state reset process described above (i.e., the reverse playback speed), it may be displayed as transitioning to the previous state at the same speed as normal gameplay, or it may be displayed as transitioning at a different speed, such as 2x or 3x. If you want to display the transition at a different speed, you can load the saved game state by skipping two frames at a time, for example, when using double speed.

[0102] Furthermore, regarding the conditions for restarting, in addition to collisions with enemy character 205 as described above, there are other forms such as the following. For example, if PC201 collides with a predetermined object that inflicts damage on PC201, which is different from enemy character 205, it may be determined that the restart condition has been met. Also, if PC201 is given a parameter called "health value," and as a result of PC201 taking damage, the health value may be determined that the restart condition has been met. Also, if PC201 falls into a pit, as described later, it may be determined that the restart condition has been met. In addition, there are other examples besides "misses." First, in a competition where obtaining a predetermined item is an essential condition for clearing the game, if PC201 moves to a position where it is not possible to obtain that item, it may be determined that the restart condition has been met. Also, for example, in a competition using a course that branches midway, if it is determined that PC201 has entered the course or area that will prevent the clear condition from being met, it may be determined that the restart condition has been met. Furthermore, in a competition where the clear condition is that PC201 is in a specific state, if it changes from that specific state, it may be determined that the condition for restarting has been met.

[0103] Furthermore, in this example, as a state reset process, in addition to the process of resetting the game state one frame at a time as described above, a "restart" process is also performed depending on the game situation. For example, suppose one of the restart conditions is that PC201 falls into a pit and moves off the stage. When this condition is met, the elapsed time is not reset, and the game is restarted from the beginning of the competition. In other words, instead of resetting the game state one frame at a time, the control is to start over from the beginning. In addition, in this case, the restart may be performed over several seconds, for example, by inserting an effect such as the screen going dark. In this case, the time taken for the restart effect will also be included in the elapsed time measurement. Furthermore, if any other unexpected behavior occurs, the restart condition may be treated as being met, and the game may be restarted.

[0104] In the following explanation, the process of returning the game state by a predetermined number of frames may be referred to as "rewinding," and the process of restarting from the start of the game may be referred to as "restarting."

[0105] Furthermore, multiple restart conditions may be set for a single event. For example, for a certain event, two restart conditions may be set: one for collision with enemy character 205 and another for falling into a pit, and the corresponding "return judgment address" may be defined for each condition. Also, the manner in which the state restoration process is executed when each condition is met may be differentiated between rewind processing and restart processing. For example, within the same event, rewind processing may be executed when colliding with enemy character 205, and restart processing may be executed when falling into a pit.

[0106] [About the game modes in this game] As described above, the game according to this embodiment is a time-attack type game in which players compete to achieve clear conditions using a part of the emulated target game. In this embodiment, three game modes are provided for the game. Specifically, there are three game modes: (1) Time Attack Mode, (2) Survival Mode, and (3) Tournament Mode. In addition, in this embodiment, the user's operation history information is saved in each mode and uploaded to the server 1000. Furthermore, when playing each mode, operation history information corresponding to the competition being played is downloaded from the server 1000 as needed. As described above, by using the operation history information as operation input in the emulator processing, it is possible to display an emulator screen that reproduces the past gameplay of the user themselves or other users.

[0107] The following is an overview of each mode.

[0108] [Time Attack Mode] First, let's explain the Time Attack mode (hereinafter abbreviated as TA mode). TA mode is a game mode in which a single user (hereinafter referred to as 1P user) plays by selecting a predetermined competition. Figure 25 is an example of a game screen related to TA mode. In Figure 25, the screen is divided into two large sections, the 1P emulator screen 211 on the left and the emulator screen (hereinafter referred to as the replay screen) 112 based on the 1P user's own operation history information on the right. The 1P emulator screen 211 displays game images based on the processing results of the 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 the emulator (hereinafter referred to as the 1P replay emulator) that operates based on the 1P user's operation history information. Therefore, the state in Figure 25 is a state in which processing related to two emulators, the 1P emulator and the 1P replay emulator, is being executed in parallel.

[0109] Here, the operation history information used for the 1P user is the operation history information that records the actions taken during the play in the target competition when the user achieved their personal best time (hereinafter referred to as the personal best play). In other words, TA mode provides the user with a play experience that is like competing against themselves at the time they achieved their best record.

[0110] Furthermore, in Figure 25, operation information images 213A and 213B are displayed below the 1P emulator screen 211 and the replay screen 212, respectively. Operation information image 213A displays the actions taken by the 1P user. Operation information image 213B displays the actions taken in relation to the personal best play. In other words, the content displayed in operation information image 213B changes based on the operation history information related to the personal best play.

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

[0112] Next, an overview of the processing in the TA mode described above will be explained. In TA mode, the processing related to the two emulators is executed in parallel as described above. The 1P emulator controls the operation of PC201 based on the 1P user's operations. The 1P replay emulator controls the operation of PC201 based on the operation history information related to the personal best play described above. 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, no time lag occurs between the 1P game screen and the 1P replay screen. Therefore, it becomes possible to play in a state where it is easy to accurately compare the current play with the personal best play. In addition, 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.

[0113] Furthermore, the 1P replay screen shown above is based on the 1P user's operation history information. If a rewind process occurred during the user's best play, the 1P replay screen will reproduce the 1P user's gameplay, including this rewind process. As a result, images related to the rewind process, as described above, may also be displayed on the 1P replay screen.

[0114] [About Survival Mode] Next, we will explain the overview of Survival Mode (hereinafter abbreviated as SV Mode). SV Mode is a game mode in which a 1P user competes in a knockout tournament against, for example, up to 7 opponents. This knockout tournament is a game consisting of multiple types of competitions as one set, with the first round being competition A, the second round being competition B, the final round being competition C, and so on, with the player winning each competition. Figures 26 to 28 show examples of game screens in SV Mode (hereinafter referred to as SV Mode screens). Figure 26 is an example of the first round screen, Figure 27 is an example of the second round screen, and Figure 28 is an example of the final round screen. In Figure 26, the 1P emulator screen 211 and the operation information image 213A are displayed. Also, at the same size as the 1P emulator screen 211, the emulator screens for the opponents, namely the 2P emulator screen 222 to the 8P emulator screen 228, are displayed. In addition, operation information images 213B to 213H are displayed for each opponent. In the following, the 2P emulator screens 222 to 8P emulator screens 228, and the operation information images 213B to 213H may be collectively referred to as the 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 Figure 26, eight emulator processes are running in parallel. Figure 27 shows the second round being played by the four users who advanced from the first round. In Figure 27, using the same screen layout as Figure 26, the emulator screens for the four advanced users display the game screen, while the emulator screens for the eliminated users do not (the emulator process is stopped). Note that the emulator screens of eliminated users may display a predetermined indication of their elimination. Figure 28 shows the final match being played by the two users who advanced from the second round. Figure 28 also uses the same screen layout as Figure 26, but the game screens of the eliminated users are not displayed.

[0115] Regarding the layout of the emulator screens from the second round onward, the layout may be designed so that the emulator screens of eliminated users are not displayed. For example, in the second round, the emulator screens of the four winning users may be displayed in a single horizontal row, as shown in Figure 29. Alternatively, although not shown in the illustration, they may be displayed in a 2x2 layout. In the final round, for example, the emulator screens of the two users who advanced from the second round may be displayed side by side, as shown in Figure 30. In all cases, each emulator screen is displayed at the same size.

[0116] [Regarding opponents in SV mode] Here, we will explain the opponent in SV mode. In the SV mode of this embodiment, the emulator processing related to the opponent is performed based on operation history information related to other users, which is downloaded from the server 1000 as described above. As the operation history information of other users that is downloaded, for example, the most recent operation history information uploaded to the server is downloaded and used in SV mode. The 2P emulator screen 222 to the 8P emulator screen 228 each display images generated by the emulator processing based on the downloaded operation history information. In other words, the opponent in SV mode is not a real other user, but rather data that reproduces the gameplay of other users. By using such data to reproduce and display the gameplay of other users in parallel with the gameplay of the 1P user, a sense of tension similar to that of real-time online matches is provided. In addition, in the case of this SV mode, for example, when you want to play an 8-player match, it is possible to suppress the considerable waiting time that occurs while waiting for other users to join and for opponents to be assembled, and it is possible to start the knockout tournament quickly. Furthermore, during the same knockout tournament, the same opponent's operation history information is used for each competition that makes up the knockout tournament. For example, if the operation history information of user B is used as the opponent, this information will be used for both the first and second rounds of the competition. This provides a gameplay experience where players feel they are playing against the same opponent throughout the knockout tournament.

[0117] As described above, in SV mode, the emulator process for the opponent is performed based on the operation history information of other users. Therefore, as part of the game program's control over the entire SV mode, the "clear judgment address" and "return judgment address" are monitored in each emulator process. Then, in each emulator process, the clear judgment and the execution of the state return process described above are performed. Therefore, images related to the state return process may also be displayed on the opponent screen.

[0118] Furthermore, since SV mode is a knockout tournament, rankings are determined in the order in which players fulfill the clear conditions. For emulator screens where the clear conditions have been met, a ranking image is displayed, as shown in Figure 31, for example. Figure 31 shows that the rankings up to 4th place have been determined, and the remaining 4 players are still playing. Each ranking image shows the clear time and the rank. Note that these ranking images are displayed superimposed on each emulator screen. In other words, they are not displayed as a function of the emulated game console, but rather are displayed by the processing of the game program that controls the entire SV mode.

[0119] In this example, if a 1P user fails to advance, they are considered to have lost, and the process related to the tournament ends there. In other words, there is no process to allow a 1P user to watch the tournament up to the final round after they have been eliminated. In other embodiments, however, it may be possible to allow a 1P user to watch the tournament up to the final round even after they have been eliminated.

[0120] [About Tournament Mode] Next, the tournament mode will be explained. This mode allows players to play a designated competition and send the results of that play (hereinafter referred to as "play record") to server 1000. Hereafter, sending one's own play record to server 1000 will be referred to as "entry". The play record includes at least the above-mentioned operation history information, the clear time information, and the information of the user who submitted it. The play records sent to server 1000 are compiled over a predetermined period, such as one week. The compiled results for each competition are then announced at each predetermined period, and the compiled results can be viewed on the viewing screen (not shown in the diagram) in the tournament mode.

[0121] Figure 32 shows an example of a screen in tournament mode. This screen is an example of a screen used by a 1P user to register for a predetermined competition. In Figure 32, only the 1P game screen in TA mode is displayed. Although not shown in the illustration, a screen for selecting a predetermined competition is displayed before this screen is shown, and the 1P user can select the predetermined competition they wish to enter from this selection screen. The 1P user plays the predetermined competition on this screen. Once the competition is cleared, a play record is generated based on the clear time and sent to server 1000. This transmitted play record can be used as an "opponent" in SV mode executed on another game device 1.

[0122] The following describes the details of the process according to this embodiment.

[0123] Next, we will explain the various data used by server 1000 and game device 1, as well as the details of the processing performed by each.

[0124] [Regarding the data used on server 1000] First, let's explain the data used by server 1000. Figure 33 is a memory map showing an example of various data stored in the storage unit 1002 of server 1000. At least the server program 301, entry data 302, and aggregated data 303 are stored in the storage unit 1002 of server 1000.

[0125] The server program 301 is a program for executing server processing, including processing the reception and aggregation of play records, and processing to transmit operation history information to a predetermined game device 1 for the SV mode described above.

[0126] Entry data 302 is data that records the play records transmitted from each game device 1. Figure 34 shows an example of the data structure of entry data 302. Entry data 302 is a database containing 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. User ID 312 is an ID used to identify the user who transmitted the play record. Competition ID 313 is an ID used to identify which competition the play record pertains to. Clear time information 314 is information indicating the clear time for the competition related to play record 311. Operation history information 315 is information indicating the operation history related to play record 311. Entry date and time 316 is information indicating the date and time when the play record 311 was transmitted to server 1000.

[0127] Returning to Figure 33, the aggregated data 303 is data based on the results of aggregating the above play records for each competition. The contents of the aggregated data 303 are updated at a predetermined interval, for example, on a weekly basis.

[0128] [Regarding the data used in game device 1] Next, we will explain the data used in the game device 1. Figure 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 the overall control program 321, the emulator program 322, the game ROM data storage area 323, the emulator work area 325, and the management area 327.

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

[0130] The emulator program 322 is a program that emulates the operation of the above-mentioned target game console.

[0131] The game ROM storage area 323 is an area for storing ROM data of the game to be emulated. In this embodiment, multiple game ROMs 324 are stored. Each game ROM 324 also includes a game program and game image data for executing game processing related to the game to be emulated. The game program runs on the virtual game console to be emulated, which is realized by executing the emulator program 322.

[0132] The emulator work area 325 stores multiple emulator memory areas 326, corresponding to the number of emulators running simultaneously. Each emulator memory area 326 is a memory space corresponding to the memory installed in the game console being emulated. In this embodiment, when the emulator program 322 starts execution, the game ROM 324 is loaded, and the various data contained in the game ROM 324 is read into the emulator memory area 326 corresponding to each emulator. In the following description, when referring to the emulator memory area 326 for each emulator, it will be written as "the nth emulator memory area". For example, the emulator memory area 326 corresponding to the 1P emulator will be written as the first emulator memory area.

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

[0134] 1P operation data 328 is data obtained from the controller operated by the 1P user. In other words, it is data that indicates the operations performed by the 1P user.

[0135] This operation history information 329 is data that records the actions taken by the 1P user in the currently playing game.

[0136] Personal Best Information 330 is data that stores the clear time and operation history information (hereinafter referred to as Personal Best Operation History) for each competition for 1P users' personal best play.

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

[0138] Entry play record 332 is the play record to be sent to server 1000 in the tournament mode described above.

[0139] 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 overview information, starting scene information, clear condition information, and retry-related information. The overview information includes information that specifies the game to be emulated for the competition and information that identifies the scene to be used for the competition. The starting scene information includes data on the game state corresponding to the competition starting scene (hereinafter referred to as the competition starting scene data). The clear condition information includes the clear conditions and the "clear judgment address". The retry-related information includes the following information: First, it includes the "return judgment address". It also includes the definition of one or more of the above retry conditions and information that specifies the manner of state return processing according to each retry condition. It also includes information indicating the waiting time from when the retry condition is met until the state return processing actually starts. It also includes the number of game state frames to be stored in order to perform the rewind processing, that is, information indicating how far back to rewind when performing rewind processing (hereinafter referred to as the number of rewind frames information).

[0140] The state return buffer 334 is an area for temporarily storing the game state used when performing a rewind operation as part of the state return process. The state return buffer 334 stores the game state from the current state up to a predetermined number of frames prior. The capacity of the state return buffer 334 may also be determined based on the number of frames to be returned.

[0141] The return flag 335 is a flag that indicates whether or not to execute the state return process described later.

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

[0143] [Details of the processing performed by the processor 81 of game device 1] First, let's explain the processes performed by game device 1. As mentioned above, this game has three game modes: TA mode, SV mode, and tournament mode. The 1P user selects the item corresponding to each mode from a designated menu screen (not shown in the diagram), and the process corresponding to that mode begins. Below, we will explain the details of the processes for each mode in the order of TA mode, SV mode, and tournament mode.

[0144] [Details of TA mode processing] Figures 36 and 37 are flowcharts detailing the TA mode processing. First, in step S11, the processor 81 displays a competition selection screen (not shown) and selects the competition to be played based on the 1P operation data 328.

[0145] Next, in step S12, the processor 81 prepares to start the selected competition. Specifically, the 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, the processor 81 loads the game ROM 324 data related to the competition into each emulator memory area 326. Next, the processor 81 obtains the competition start scene data, the clear condition information, and the retry-related information corresponding to the selected competition from the competition content definition data 333. Furthermore, the processor 81 appropriately sets the size of the state return buffer 334, etc., based on the return frame count information included in the retry-related information. Furthermore, the processor 81 obtains the personal best operation history corresponding to the competition from the personal best information 330. Furthermore, the 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 emulator operation is stopped. The processor 81 then generates the 1P emulator screen 111 and the personal best screen 112 related to the start of the competition.

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

[0147] Next, in step S14, the processor 81 displays a countdown animation (not shown in the diagram) for the start of the competition. Furthermore, after the countdown ends, the 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). In addition, it starts measuring the operation history information of the 1P user and the elapsed time. This starts the competition.

[0148] Next, in step S15, the processor 81 determines whether the return flag 335 is on or off. If the result of this determination is off (NO in step S15), in step S17, the processor 81 obtains 1P operation data 328. Then, the processor 81 executes 1P emulator processing based on the operation content indicated by the data. This generates the 1P emulator screen 111. The processor 81 also records the contents of the 1P operation data 328 in the current operation history information 329.

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

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

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

[0152] Next, in step S31, the processor 81 executes the 1P replay emulator process. Specifically, the processor 81 operates the PC201 in the 1P replay emulator based on the above-mentioned personal best operation history and executes various game processes accordingly. At this time, the processor 81 also determines whether the above-mentioned restart conditions have been met in the 1P replay emulator. If they have been met, the processor 81 performs the state reset process described later, targeting the 1P replay emulator. The processor 81 also determines whether the clear conditions have been met, and if they have been met, stops the 1P replay emulator. At this time, the processor 81 also sets up the display of the clear time superimposed on the personal best screen. Then, the processor 81 generates the personal best screen 112 based on the results of these processes.

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

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

[0155] Next, in step S21, the processor 81 temporarily pauses the 1P emulator processing. After that, the process proceeds to step S26.

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

[0157] Next, in step S45, the processor 81 determines whether the game state has been rewound to the point where the rewind process should be terminated. This timing is determined, for example, based on the rewind frame count information described above. If, as a result of this determination, the game state has been rewound to the point where the rewind process should be terminated (YES in step S45), then in step S47, the processor 81 sets the return flag 335 to off. Furthermore, in step S48, the processor 81 resumes the 1P emulator processing that had been paused. After that, the return process is terminated.

[0158] On the other hand, if the timing to finish the rewind process has not yet been reached (NO in step S45), the processes in steps S47 and S48 are skipped, and the return process ends.

[0159] On the other hand, if the result of the determination in step S41 is that the processing mode of the state return process determined in step S20 is not a rewind process (NO in step S41), then a restart process is executed. First, in step S42, the processor 81 sets up the 1P emulator screen 111 to display a restart effect during a predetermined waiting time until the restart (hereinafter referred to as the restart waiting time). The restart effect is, for example, an effect such as darkening the screen during the restart waiting time.

[0160] Next, in step S44, the processor 81 determines whether the restart waiting time has elapsed. If it has not elapsed (NO in step S44), it terminates the return process. If it has elapsed (YES in step S44), in step S46, the processor 81 loads the game start scene data into the 1P emulator memory area and generates the 1P emulator screen 111. This displays a screen where PC201 is in the game start scene. After that, the process proceeds to step S47.

[0161] Returning to Figure 36, once the state restoration process is complete, the process proceeds to step S26 described above.

[0162] Next, we will explain the process when the clear conditions are met as a result of the judgment in step S22 (YES in step S22). In this case, first, in step S23, the processor 81 stops measuring the elapsed time and determines the clear time for this competition. The processor 81 also stops recording the operation history information. Next, in step S25, the processor 81 stops the 1P emulator processing. Furthermore, the processor 81 displays the clear animation, for example, by superimposing it on the 1P emulator screen.

[0163] Next, in step S27, the processor 81 compares the personal best information 330 with the clear time determined above and determines whether the personal best clear time has been updated. If the result of this determination is that it has been updated (YES in step S27), in step S29, the processor 81 updates the contents of the 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 send the current record to the server 1000. If the 1P user instructs to send, the above operation history information, etc. may be sent to the server 1000. On the other hand, if the personal best clear time has not been updated (NO in step S27), the process in step S29 is skipped. After that, the processor 81 terminates the TA mode processing.

[0164] [SV mode processing] Next, we will explain the details of the SV mode processing. Figures 39 to 41 are flowcharts detailing the SV mode processing. Note that some processes in these flowcharts are the same as those in the TA mode processing described above. Therefore, the same reference numerals are used for the same processes, and detailed explanations are omitted. Here, we will mainly explain the parts that differ from the TA mode processing.

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

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

[0167] In this embodiment, an example of downloading operation history information in step S52 is shown, but the timing of downloading 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), operation history information corresponding to all competitions in SV mode may be downloaded in advance from the server 1000 and stored in the DRAM 85. Then, in step S52, the process may be limited to simply reading the previously downloaded other user operation history information 331.

[0168] Next, in step S53, the processor 81 prepares the emulator processing for each opponent in the current round of the competition. Specifically, similar to the processing in step S12 above, it allocates a first emulator memory area corresponding to the 1P emulator, and further allocates emulator memory areas 326 according to the number of opponents. Furthermore, the processor 81 loads the game ROM 324 data related to the current competition into each emulator memory area 326. Furthermore, the processor 81 obtains various information related to the current competition from the competition content definition data 333. Then, the processor 81 loads the competition start scene data into each emulator memory area 326 and generates each emulator screen related to the competition start scene.

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

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

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

[0172] Next, after step S30 in Figure 41, in step S58, the processor 81 executes opponent emulator processing based on the opponent's operation history information. This processing is basically the same as the 1P emulator process described above. Therefore, the state return process described above is also executed as needed. However, this process does not record the operation history or measure the elapsed time. As a result of this opponent emulator processing, each opponent's emulator screen is generated. If the clear condition is met in the opponent's emulator processing, the processor 81 stops the emulator processing for that opponent. The processor 81 also sets up the display of the ranking image (see Figure 31) overlaid on each opponent's emulator screen. The clear time may be displayed based on the other user operation history information 331, or the elapsed time for each opponent may be measured in step S55 and the measured time may be displayed.

[0173] Next, in step S60, the processor 81 generates an SV screen including each of the emulator screens described above and outputs it to the display unit 5. After that, the process returns to step S15 and is repeated.

[0174] Next, we will explain the process that takes place after step S25 in Figure 41. That is, we will explain the process after the 1P user has achieved the clear conditions. After the process in step S25, in step S56, the processor 81 determines the 1P user's ranking and overlays the ranking image onto the 1P emulator screen. Next, in step S57, the processor 81 determines whether all of the opponents have achieved the clear conditions for this competition. If, as a result of this determination, there are still opponents who have not achieved the clear conditions (NO in step S57), in step S59, the processor 81 continues various processes related to those opponents until all of them have achieved the clear conditions.

[0175] On the other hand, if all opponents have achieved the clear conditions (YES in step S57), in step S61, processor 81 displays the final results screen showing the final rankings for this competition.

[0176] Next, in step S62, the processor 81 determines whether the 1P user has won the current competition (or defeated their opponent in the case of the final match). If the result of this determination is that the 1P user has not won the current competition (NO in step S62), the processor 81 displays a defeat animation, etc., and then terminates the SV mode processing. On the other hand, if the user has won the current competition (YES in step S62), in step S63, the processor 81 determines whether all the competitions related to this knockout tournament have finished. If the result of this determination is that they have not finished, the process returns to step S53, and the above processing is executed for the next competition. On the other hand, if all the competitions have finished, the processor 81 displays the final result screen of the knockout tournament and then terminates the SV mode processing.

[0177] [Tournament Mode Processing] Next, we will explain the details of the tournament mode processing. Figures 42 and 43 are flowcharts detailing the tournament mode processing. Note that some of the processing in these flowcharts is the same as that in the TA mode processing described above. Therefore, the same reference numerals are used for the same processing, and detailed explanations are omitted. Here, we will mainly explain the parts that differ from the TA mode processing.

[0178] In Figure 42, first, in step S81, the processor 81 displays a competition selection screen (not shown) and selects the competition that the player wants to play and enter based on the 1P operation data 328.

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

[0180] Next, in step S83, the processor 81 generates a tournament mode screen as shown in Figure 32 and outputs it to the display unit 5.

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

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

[0183] Furthermore, after the 1P user achieves the clear conditions and the clear animation is displayed in step S25, in step S85, the processor 81 generates an entry play record 332 based on the recorded operation history information and clear time. Then, it sends the entry play record to the server 1000. After that, the processor 81 terminates the tournament mode processing.

[0184] This concludes the detailed explanation of the processing related to game device 1.

[0185] [Processing by Server 1000] Next, the details of the processing performed by the server 1000 will be explained. Figure 44 is a flowchart detailing the processing performed by the server 1000. In Figure 44, first, in step S91, the processor 1001 of the server 1000 determines whether or not it has received a request for operation history information for an opponent in SV mode from a predetermined game device 1. If it has not received the request (NO in step S91), the process proceeds to step S94, which will be described later. If it has received the request (YES in step S91), in step S92, the processor 1001 selects a user to be the opponent. The method of selection is not limited, but for example, a user who entered the game at a time close to the time the request was received may be given priority. Furthermore, the processor 1001 refers to the entry data 302 and selects operation history information 315 based on the user ID 312 of the selected user and the competition ID 313 of each competition that constitutes the knockout tournament included in the request. As a result, the operation history information of the same user is selected for each round of the knockout tournament.

[0186] Next, in step S93, the processor 1001 sends the above operation history information 315 to the requesting game device 1.

[0187] Next, in step S94, the processor 1001 determines whether or not it has received the entry play record 332. If it has been received (YES in step S94), in step S95, the processor 1001 registers the received entry play record 332 in the entry data 302. After that, the process returns to step S91 and is repeated. If it has not been received (NfdO in step S94), the process in step S95 is skipped and the process returns to step S91. This concludes the detailed explanation of the process related to the server 1000.

[0188] As described above, this embodiment performs game processing using an emulator. In this case, not only is emulator processing for the 1P user performed, but emulator processing using the above operation history information is also performed in parallel. The processing results of each emulator are then displayed as individual game images. Furthermore, the operation history information can be based on the 1P user's past gameplay (TA mode above) or on the gameplay of other users (SV mode above). In TA mode, the user's past gameplay is displayed side by side with their current gameplay screen, providing an environment that makes it easy to play while comparing the two. In SV mode, for example, it avoids situations where players have to wait for opponents to join in online play via a network, allowing for a quick start to a (pseudo) multiplayer game. In both modes, the start timing of the game processing for the 1P user and the game processing using operation history information are synchronized, so it is possible to provide competitive play under conditions where time lag due to network delays, for example, does not occur.

[0189] Furthermore, in the SV mode described above, the 1P emulator screen and the opponent's emulator screen are displayed at equal sizes. This provides a sense of realism, as if playing at an offline game tournament, where eight game consoles are lined up in the same venue and all their game screens are displayed together on one large monitor.

[0190] Furthermore, by displaying the operation information image 113 shown above, it is possible to understand how the 1P user and their opponents are operating the controller during their personal best play. This can be used as a reference for improving the operation to shorten the clear time.

[0191] Furthermore, in this embodiment, even if a mistake occurs during the game, the game is not ended there. Instead, the game state is transitioned to the state before the mistake occurred, allowing the player to continue playing. In other words, the game continues until the clear conditions are met. Moreover, the time taken for the transition of the game state is also included in the measurement of the clear time. This provides an environment for more accurate measurement, especially in games where time is a factor, such as time attack challenges.

[0192] [Differentiation] In the above embodiment, an example was given in which the elapsed time information 114 is displayed in each game mode, but the system may be controlled so that the elapsed time information 114 is not displayed.

[0193] Furthermore, in the TA mode described above, an example was given in which the personal best screen is displayed based on the operation history information related to the personal best play. In other embodiments, in TA mode, operation history information of other users may be used instead of operation history information related to the personal best play. For example, operation history information of top-ranked users in the results of the tournament mode may be downloaded and used. Alternatively, only the replay screen 212 may be displayed, and only the gameplay content may be reproduced using the operation history information.

[0194] Furthermore, in the TA mode described above, multiple types of competitions may be played as a single set.

[0195] Furthermore, in the above embodiment, when the above-mentioned retry condition was met, the state restoration process was started only after a predetermined waiting period had elapsed, such as waiting for the playback of the error animation to finish. In other embodiments, depending on the game content, the state restoration process may be started immediately when the retry condition is met, without providing such a waiting period.

[0196] Furthermore, the operation history information used in the SV mode described above may be managed by uploading the operation history information recorded for each competition in a knockout tournament to the server 1000 and then downloading and using it. In other words, the operation history information may be managed on a knockout tournament basis in the SV mode. For example, if knockout tournament A consists of competitions B, C, and D, the operation history of the 1P user for competitions B, C, and D may be recorded in SV mode and sent to the server 1000 as a set for storage. When downloaded by another game device 1, the operation history information for the 1P user for the set of competitions B, C, and D should be downloaded as operation history information related to knockout tournament A.

[0197] Furthermore, the above embodiment described a case in which the game processing described above is performed on a single game device 1. The game device 1 may include multiple storage devices and processors. The game processing may be performed by distributing the processing among these devices. The above processing may also be performed in a distributed system consisting of multiple information processing devices, including a server. [Explanation of Symbols]

[0198] 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 game system equipped with a processor, The aforementioned processor, The first game and the second game are run using separate emulators. 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, are started simultaneously. The first game is processed based on the user's input, The at least one of the second games is processed based on at least one of the operation history information, A total game image is generated, which includes a first game image based on the first game and at least one second game image based on the second game. If the game states of the first game and the second game each satisfy the first condition, the processing of each game is stopped or terminated. Game system.

2. The game system according to claim 1, wherein the processor generates the overall game image, further including an image showing the time elapsed since the start of the first game and the second game.

3. The game system according to claim 1, wherein the processor generates the overall game image, which further includes an image showing the time elapsed from the start of each of the first and second games until the first condition is met, after the game states of the first and second games have each met the first condition.

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

5. The game system according to claim 1, wherein the processor processes the second game based on the operation history information stored by the other game system.

6. The game system according to claim 1, wherein the processor generates the overall game image, further including images indicating operation inputs in at least one of the first game and the second game.

7. The game system according to claim 1, wherein the processor causes the emulator to start the first game and the second game from a predetermined scene of a predetermined game.

8. The game system according to claim 4, wherein the processor processes the second game based on the operation history information in the case where the time elapsed from the start of the first game until the first condition is met is the shortest.

9. The game system according to claim 5, wherein the processor starts the next order of the first and second games only when the second condition is met in a series of games in which multiple types of the first and second games are played in a predetermined order.

10. The game system according to claim 9, wherein the second condition is that, in the rankings based on the results of the first game in the series of games, the ranking based on the results of the first game is within a predetermined rank.

11. The game system according to claim 9, wherein the processor processes each of the plurality of types of second games that are 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.

12. The game system according to any one of claims 1 to 11, wherein the processor, in each of the first game and the second game, transitions the game state to the game state before the third condition was met when the game state satisfies the third condition.

13. The game system according to claim 12, wherein the processor measures the time elapsed from the start of the game, including the time related to the state transition, until the first condition is met.

14. The game system's processor, The first game and the second game are run using separate emulators. 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, are started simultaneously. The first game is processed based on the user's input. The at least one of the second games is processed based on at least one of the operation history information, A total game image is generated that includes a first game image based on the first game and at least one second game image based on the second game. If the game states of the first game and the second game each satisfy the first condition, the processing of each game is stopped or terminated. Game program.

15. The game program according to claim 14, wherein the processor generates the overall game image, which further includes an image showing the time elapsed since the start of the first game and the second game.

16. The game program according to claim 14, wherein the processor is instructed to generate the overall game image, which further includes an image showing the time elapsed from the start of each of the first and second games until the first condition is met, after the game states of the first and second games have each met the first condition.

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

18. The game program according to claim 14, wherein the processor processes the second game based on the operation history information stored by the other game system.

19. The game program according to claim 14, wherein the processor generates the overall game image which further includes images indicating operation inputs in at least one of the first game and the second game.

20. The game program according to claim 14, wherein the processor operates the emulator to start the first game and the second game from a predetermined scene of a predetermined game.

21. The game program according to claim 17, wherein the processor processes the second game based on the operation history information in the case where the time elapsed from the start of the first game until the first condition is met is the shortest.

22. The game program according to claim 18, wherein the processor is instructed to start the next order of the first and second games in a series of games in which multiple types of the first and second games are played in a predetermined order, only if the second condition is met.

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

24. The game program according to claim 22, wherein the processor is caused to process each of the plurality of types of second games that are 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.

25. The game program according to any one of claims 15 to 24, wherein the processor, in each of the first and second games, causes the game state to transition to the game state before the third condition was met if the game state satisfies the third condition.

26. The game program according to claim 25, wherein the processor measures the time elapsed from the start of the game, including the time related to the state transition, until the first condition is met.

27. The game system's processor, The first game and the second game are run using separate emulators. 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, are started simultaneously. The first game is processed based on the user's input. The at least one of the second games is processed based on at least one of the operation history information, A total game image is generated that includes a first game image based on the first game and at least one second game image based on the second game. If the game states of the first game and the second game each satisfy the first condition, the processing of each game is stopped or terminated. Game processing method.

28. The game processing method according to claim 27, wherein the processor generates the overall game image which further includes an image showing the time elapsed since the start of the first game and the second game.

29. The game processing method according to claim 27, wherein the processor generates the overall game image, which further includes an image showing the time elapsed from the start of each of the first and second games until the first condition is met, after the game states of the first and second games each satisfy the first condition.

30. The game processing method according to claim 27, wherein the processor stores the history of the operation inputs in the first game as operation history information.

31. The game processing method according to claim 27, wherein the processor processes the second game based on the operation history information stored by the other game system.

32. The game processing method according to claim 27, wherein the processor generates the overall game image which further includes images indicating operation inputs in at least one of the first game and the second game.

33. The game processing method according to claim 27, wherein the processor operates the emulator to start the first game and the second game from a predetermined scene of a predetermined game.

34. The game processing method according to claim 30, wherein the processor processes the second game based on the operation history information in the case where the time elapsed from the start of the first game until the first condition is met is the shortest.

35. The game processing method according to claim 31, wherein the processor is instructed to start the next order of the first and second games only when the second condition is met, in a series of games in which multiple types of the first and second games are played in a predetermined order.

36. The game processing method according to claim 35, wherein the second condition is that, in the rankings based on the results of the first game in the series of games, the ranking based on the results of the first game is within a predetermined rank.

37. The game processing method according to claim 35, wherein the processor is made to process each of the plurality of types of second games that are 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.

38. The game processing method according to any one of claims 27 to 37, wherein the processor, in each of the first and second games, transitions the game state to the game state before the third condition was met when the game state satisfies the third condition.

39. The game processing method according to claim 38, wherein the processor measures the time elapsed from the start of the game, including the time related to the state transition, until the first condition is met.

40. A game device equipped with a processor, The aforementioned processor, The first game and the second game are run using separate emulators. 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, are started simultaneously. The first game is processed based on the user's input, The at least one of the second games is processed based on at least one of the operation history information, A total game image is generated, which includes a first game image based on the first game and at least one second game image based on the second game. If the game states of the first game and the second game each satisfy the first condition, the processing of each game is stopped or terminated. Game device.

Images