Game program, game system, and game processing method

Abstract

To provide a game program, a game system, and a game processing method that can reduce the obstruction of a player's own gameplay experience due to the actions of other players.SOLUTION: When a mistake happens in a game stage, if another player object exists within a predetermined range, the player object is shifted into a special state where it is immune to damage. In the special state, the player object touches another player object, the player object is returned from the special state to its normal state. On the other hand, if the other player objects do not exist within the predetermined range, or the player object fails to touch another player object in the special state, the play of the game stage is terminated.SELECTED DRAWING: Figure 42

Description

[Technical field]

[0001] The present disclosure relates to multiplayer gaming. [Background technology]

[0002] Conventionally, a game system for playing a multiplayer game has been known (for example, Non-Patent Document 1). In this game, up to four players can play simultaneously on one game device. In this game, the player characters can enter a state called "bubble" in which they are temporarily immune to damage. By becoming a "bubble", a certain player character can leave difficult places to other players and have the "bubble" carry them around. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] Nintendo Co., Ltd., “New Super Mario Bros. Wii”, [online], [searched June 5, 2023], Internet (URL: https: / / www.nintendo.co.jp / wii / smnj / play / kyouryoku.html) Summary of the Invention [Problem to be solved by the invention]

[0004] However, for a player who wants to move forward, there are situations where he or she has to wait for other players to catch up to the position he or she has progressed to, for example, by helping other players. This may cause the player to feel that the tempo of the game is slowing down. In other words, there is a possibility that the player's play may be hindered by other players. [Means for solving the problem]

[0005] In view of the above problems, for example, the following configuration example is given.

[0006] (Configuration 1) Configuration 1 is a game program executed by a computer of a game device that executes a process of generating a game stage including a player object whose movement can be controlled based on a player's operation and another player object whose movement is controlled based on information received from another game device connected via a network, and causes the computer of the game device to function as: auxiliary object determination means for determining whether a resurrection assist object including another player object exists within a predetermined range from the player object when a mistake occurs in a predetermined game stage; transition means for transitioning the player object to a special state in which the player object does not receive damage within the game space when the auxiliary object determination means determines that a resurrection assist object exists within a predetermined range from the player object; resurrection means for returning the player object from the special state to a normal state in which the player object can receive damage within the game stage without ending play of the game stage when the player object touches the resurrection assist object while in the special state; and termination means for ending play of the game stage when the auxiliary object determination means determines that no resurrection assist object exists within the predetermined range from the player object or when the player object does not touch the resurrection assist object while in the special state.

[0007] According to the above configuration, even when a mistake occurs, if a resurrection assist object exists within a predetermined range, the play is not immediately ended, but is transitioned to a special state. Then, if the player comes into contact with the resurrection assist object in the transition state, the player can be resurrected to the normal state. Therefore, if there is another player object nearby in the game stage, the player is given an opportunity to continue playing without immediately ending the play even if the player makes a mistake. This provides a motivation to play online with other players in order to obtain such an opportunity. In addition, when another player generates an event that may end the play, if the distance between the player object and the other player object is outside the predetermined range, the player will not have the opportunity to resurrect in the first place, so the player can continue playing the game at his own pace without worrying too much about other players.

[0008] (Configuration 2) Configuration 2 is the same as configuration 1 above, in which the player object can be operated even while in the special state, the player object continues to be in the special state for a predetermined time, and the termination means may terminate play of a predetermined stage if the player object does not touch the revival assist object within the predetermined time after transitioning to the special state.

[0009] According to the above configuration, since there is a time limit for remaining in the special state, it is possible to add tension to the game and make it more entertaining.

[0010] (Configuration 3) Configuration 3 is based on configuration 2 above, and in a case where a transition to the special state occurs multiple times in the same game stage, the predetermined time may be gradually shortened as the number of transitions to the special state increases.

[0011] According to the above configuration, if the player transitions to a special state multiple times, the chances of reviving will gradually decrease, which can add tension to the gameplay.

[0012] (Configuration 4) In the configuration 4, in the above configuration 1, the game program may further cause the computer to function as a ghost appearance means for making a ghost character appear in the game space, the ghost character acting based on replay data for replaying the play contents of other players. Furthermore, the resurrection assist object may also include a ghost character related to another player.

[0013] According to the above configuration, the ghost character can be made to appear in place of other player objects. This makes it possible to provide the experience of playing online with other players, even in a situation where the player continues playing without meeting other players, by making the ghost character appear.

[0014] (Configuration 5) In configuration 5, in the above configuration 4, the game program may further cause the computer to function as replay transmitting means for recording the action contents of the player object during a predetermined period as replay data and transmitting the replay data to a predetermined server at a predetermined timing, and replay acquiring means for acquiring replay data transmitted by other players from the server at a predetermined timing after the player starts playing a game stage. And the ghost appearance means may cause a ghost character to act based on the replay data acquired from the server.

[0015] (Configuration 6) Configuration 6 may be such that in configuration 1, the other player objects have no effect on the player object in a normal state.

[0016] According to the above configuration, under normal circumstances, there is no interference from other players' characters, so that one's gameplay is not hindered by the play of other players. Therefore, while the progress of the game stage itself can proceed at one's own pace, when an event occurs that may end the game, it is possible for the player to get help from other players. This provides the benefits of playing online and promotes online play.

[0017] (Configuration 7) Configuration 7 based on configuration 6, the other player objects may be displayed in a semi-transparent manner when the player objects are in a normal state, and in an opaque manner when the player objects are in a special state.

[0018] According to the above configuration, when a player object is in a special state, it is possible to allow the player to intuitively understand that something will happen if the player object comes into contact with another player object.

[0019] (Configuration 8) In configuration 8, in configuration 7, when the player object is in a special state, the game screen may be displayed with the saturation of the game stage reduced, except for the revival assist object.

[0020] According to the above configuration, when the player object is in a special state, the revival target object can be made visually prominent.

[0021] (Configuration 9) In configuration 9, in the above configuration 1, the game program may further cause the computer to function as a placement means for causing the player object to place a placement object at a predetermined position in the game stage based on a predetermined operation. When the player object in a special state touches an object placed by another player object, the player object may return from the special state to a normal state.

[0022] According to the above configuration, the player object can be restored from the special state to the normal state not only by other player objects but also by placed objects placed by other players. This allows the player object to indirectly help the restoration by using placed objects even in a situation where the player object and other player objects are apart from each other.

[0023] (Configuration 10) Configuration 10 may be such that in the above configuration 9, when a player object in a special state touches a placed object placed by a player object, the player object is not returned to the normal state.

[0024] According to the above configuration, the difficulty level of the game can be set appropriately, and a decrease in interest in the game can be prevented.

[0025] (Configuration 11) In the above-mentioned configuration 9, the game program may further cause the computer to function as a transmitting means for transmitting, to a predetermined server, placement information including at least position information of the placed object when the player object places the placed object. The placing means may place the placed object in the game stage based on the placement information stored in the predetermined server.

[0026] According to the above configuration, even if there are no other players on the same game stage, it is possible to place an object. In addition, since the object can be used to restore the normal state from the special state, it is possible to improve convenience for the player.

[0027] (Configuration 12) Configuration 12 is such that, in configuration 11 above, a placement object placed based on placement information stored in a specified server does not function as a revival assist object at the time of placement, and the function as a revival assist object is enabled when a player object comes into contact with the placement object.

[0028] According to the above configuration, the game balance can be optimized by controlling the object so that it does not function as a revival assist object at first. Also, a game can be provided in which an object placed based on the placement information stored in the server is treated as a checkpoint, which can improve the interest of the game.

[0029] (Configuration 13) Configuration 13 is configured as in configuration 11 above, wherein the placement means may place a placement object in the game stage based on placement information stored in a specified server when there is no placement object in the game stage at a specified timing.

[0030] According to the above configuration, even if there are no other player objects in the same game stage, the player is given an opportunity to return from a special state to the normal state, or the opportunity can be increased. (Configuration 14) Configuration 14 is based on configuration 1 above, and the restoring means may, when restoring the player object to the normal state, place the player object in the normal state at a position where the mistake does not occur immediately after the player object is restored to the normal state.

[0031] According to the above configuration, it is possible to suppress the occurrence of mistakes when returning from a special state to a normal state. Effect of the Invention

[0032] According to the present disclosure, if a player makes a mistake, the play is not immediately ended and the player is given an opportunity to continue playing if there is another player object nearby. [Brief description of the drawings]

[0033] [Figure 1] FIG. 1 is a schematic diagram showing an overall view of a game system according to an embodiment of the present invention; [Diagram 2] Block diagram showing the hardware configuration of game server 1 [Diagram 3] A block diagram showing the hardware configuration of the game device 3. [Figure 4] An example of a game screen [Diagram 5] An example of a game screen [Figure 6] An example of a game screen [Figure 7] An example of a game screen [Figure 8] An example of a game screen [Figure 9] An example of a game screen [Figure 10] An example of a game screen [Figure 11] An example of a game screen [Figure 12] State transition and explanation diagram [Figure 13] FIG. 13 is a diagram for explaining a restoration position; [Figure 14] FIG. 13 is a diagram for explaining a restoration position; [Figure 15] FIG. 13 is a diagram for explaining a restoration position; [Figure 16] FIG. 13 is a diagram for explaining a restoration position; [Figure 17] FIG. 13 is a diagram for explaining a restoration position; [Figure 18] FIG. 13 is a diagram for explaining a restoration position; [Figure 19] FIG. 13 is a diagram for explaining a restoration position; [Figure 20] FIG. 13 is a diagram for explaining a restoration position; [Figure 21] FIG. 13 is a diagram for explaining a restoration position; [Figure 22] An example of a special status effect [Figure 23] Diagram to explain the panel [Figure 24] Diagram to explain the panel [Diagram 25] Diagram to explain the panel [Figure 26] Diagram to explain the panel [Figure 27] A memory map showing an example of various data stored in the memory unit 12 of the game server 1. [Figure 28]An example of the data configuration of the stage room management data 304 [Figure 29] An example of the data configuration of the replay management data 305 [Diagram 30] An example of the data configuration of the panel management data 306 [Diagram 31] A memory map showing an example of various data stored in the storage unit 32 of the game device 3. [Diagram 32] An example of the data structure of remote character data 361 [Diagram 33] An example of the data configuration of the player / actor management data 363 [Diagram 34] An example of the data structure of Panel Data 364 [Diagram 35] A flowchart showing details of the game processing executed by the game device 3. [Diagram 36] A flowchart showing details of the game processing executed by the game device 3. [Figure 37] Flowchart showing details of stage preparation process [Figure 38] Flowchart showing details of entrance / exit check processing [Figure 39] Flowchart showing details of entrance / exit check processing [Diagram 40] Flowchart showing details of remote panel check processing [Diagram 41] Flowchart showing details of normal state processing [Diagram 42] Flowchart showing details of normal state processing [Diagram 43] Flowchart showing details of own panel arrangement processing [Diagram 44] Flowchart showing details of special state processing [Diagram 45] Flowchart detailing the Replay Ghost process [Figure 46] Flowchart showing details of stage clear processing [Figure 47] Flowchart showing details of restart processing [Figure 48]A flowchart showing details of the game server process executed by the game server 1. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] An embodiment of the present invention will be described below. FIG. 1 is a schematic diagram showing an overall image of an information processing system (game system) according to this embodiment. The information processing system 100 of this embodiment includes a game server 1 and a plurality of information processing terminals 3. The game server 1 and the information processing terminal 3 are configured to be able to communicate with each other via a network 10 such as the Internet. In this embodiment, information processing is executed with such a configuration, and below, game processing will be described as an example of the information processing. Specifically, a game program is installed on the information processing terminal 3, and game processing is executed while communicating with the game server 1 as necessary.

[0035] [Game server hardware configuration] Next, the hardware configuration of the game server 1 will be described. FIG. 2 is a block diagram showing the hardware configuration of the game server 1. The game server 1 includes at least a processor 11, a storage unit 12, and a communication unit 13. The processor 11 executes various programs for controlling each server. The storage unit stores various programs executed by the processor 11 and various data used. The communication unit 13 is connected to a network by wired or wireless communication, and transmits and receives predetermined data between the information processing terminal 3 or another server. Note that, although an example in which there is one game server 1 is illustrated in this embodiment, the game server 1 may be configured as a group of servers performing distributed processing.

[0036] [Game device hardware configuration] Next, the information processing terminal 3 will be described. The information processing terminal 3 is, for example, a smartphone, a stationary or portable game device, a tablet terminal, a mobile phone, a personal computer, a wearable terminal, etc. In this embodiment, a stationary game device (hereinafter simply referred to as a game device) will be described as an example of the information processing terminal 3.

[0037] FIG. 3 is a block diagram showing an example of a hardware configuration of the game device 3 according to this embodiment. In FIG. 3, the game device 3 includes a processor 31. The processor 31 is an information processing unit that executes various information processes executed in the game device 3, and may be composed of only a CPU (Central Processing Unit), or may be composed of a SoC (System-on-a-chip) including a plurality of functions such as a CPU function and a GPU (Graphics Processing Unit) function. The processor 31 executes various information processes by executing an information processing program (e.g., a game program) stored in the storage unit 32. Note that the storage unit 32 may be an internal storage medium such as a flash memory or a DRAM (Dynamic Random Access Memory), or may be configured to use an external storage medium or the like that is inserted into a slot not shown.

[0038] The game device 3 also includes a wireless communication unit 33 for wireless communication between the game device 3 and the server and other game devices 3. As the wireless communication, for example, Internet communication or short-distance wireless communication is used.

[0039] The game device 3 also includes a controller communication unit 34 for allowing the game device 3 to communicate with the controller 4 in a wired or wireless manner.

[0040] Furthermore, a display unit 5 (e.g., a television or the like) is connected to the game device 3 via an image / audio output unit 35. The processor 31 outputs images and sounds generated (for example, by executing the above-mentioned information processing) to the display unit 5 via the image / audio output unit 35.

[0041] Next, the controller 4 will be described. The controller 4 includes at least one analog stick 42, which is an example of a directional input device. The analog stick 42 can be used as a directional input unit capable of inputting a direction. By tilting the analog stick 42, the user can input a direction according to the tilt direction (and input a magnitude according to the tilt angle). The controller 4 also includes a button unit 43 including various operation buttons. For example, the controller 4 may include a plurality of operation buttons on the main surface of the housing.

[0042] The controller 4 also includes an inertial sensor 44. Specifically, the controller 4 includes an acceleration sensor and an angular velocity sensor as the inertial sensor 44. In this embodiment, the acceleration sensor detects the magnitude of acceleration along predetermined three axial directions. Furthermore, the angular velocity sensor detects angular velocity around the predetermined three axes.

[0043] The controller 4 also includes a communication unit 41 for performing wired or wireless communication with the controller communication unit 34. The directional input contents to the analog stick 42, information indicating the pressed state of the button unit 43, and various detection results by the inertial sensor 44 are repeatedly output to the communication unit 41 at appropriate timing and transmitted to the game device 3.

[0044] [Overview of information processing in this embodiment] Next, an overview of information processing according to this embodiment will be described. In this embodiment, as an example of information processing, a game processing in which a player operates a player character object (hereinafter referred to as a player character) existing in a virtual space to play is assumed and described. More specifically, in this embodiment, a side-scrolling action game (hereinafter referred to as this game) is assumed and described. In this game, a two-dimensional virtual space called a "stage" is prepared as the main stage for play. A start point and a goal point are set in this stage. Various enemy characters, obstacles, jump platforms, pitfalls, and other various gimmicks are placed between the start point and the goal point. This game is a game in which the player character reaches the goal point while defeating or avoiding these enemy characters. Note that the stage may be called a "course" or a "round" depending on the game. In addition, in this embodiment, a game in which a game screen is displayed on a 2D screen is exemplified, but in other embodiments, the virtual space may be a three-dimensional virtual space, and the game may be displayed on a 3D screen such as a first-person perspective or a third-person perspective.

[0045] FIG. 4 shows an example of a game screen (hereinafter, referred to as a stage screen) during the above stage is being played. The example in FIG. 4 is an example of a screen near the starting point, that is, a screen example immediately after starting to play the stage. In FIG. 4, a player character 201 and an enemy character 202 are displayed. In addition, various terrain objects such as blocks are also displayed. In this stage, the starting point is set near the left end of the stage, and the goal point is set near the right end of the stage. Therefore, the stage is configured such that the player character 201 advances toward the right direction of the screen as the overall game progresses. In such a stage screen, the player operates the player character 201 to move toward the goal point. In accordance with the movement of the player character, another part of the stage is displayed as the stage screen. Then, when the player character reaches the goal point, the stage is cleared.

[0046] Furthermore, in the above-mentioned stage, a "waypoint" is set at a position that is approximately halfway between the start point and the goal point. A waypoint object indicating that it is a waypoint is placed at the waypoint. When the player character comes into contact with the waypoint object, if a restart is made in the play from that point until the goal is reached, the player character can restart from the waypoint. Note that before reaching the waypoint, the player restarts from the start point. Note that the position set as the waypoint is not limited to a position that is approximately halfway between the start point and the goal point, and a predetermined position may be set as the waypoint as long as it is a position on the way between the start point and the goal point.

[0047] [Online play elements] The basic flow of the game progression is as described above, and the game can basically be played as if it were a single game. Furthermore, the game also allows for multiplayer. As an example, the game also has an online play element that allows the game to be played with other players by connecting to the server or other game devices 3 via the Internet.

[0048] The online play element of this game will be described below. First, the overall network configuration will be briefly described. The basic network configuration is as shown in FIG. 1 above. This game provides a game that utilizes the communication group configuration in so-called MO (Multiplayer Online) type online games. Specifically, communication groups (hereinafter referred to as stage rooms) corresponding to each stage can be appropriately generated and managed. In other words, a virtual space corresponding to each stage is prepared, and a predetermined number of players matched by the game server 1 connect to the virtual space. Also, multiple stage rooms can exist in parallel for the same stage.

[0049] Also, a maximum number of people that can enter a stage room is set. As an example, in this game, it is assumed that up to four people can enter one stage room. Also, in this game, as an example, it is assumed that game devices 3 in the same stage room are connected by a P2P (Peer to Peer) communication method. In other embodiments, a communication method via a server may be used.

[0050] 5 is an example of a stage screen output from the game device 3 of a player when the player enters a stage room in which another player has already entered. In FIG. 5, another player character 203 operated by the other player is displayed on the stage screen of the game device 3 operated by the player. Since the other player entered the room before the player and has started stage play, the other player character 203 is in a position slightly further ahead than the starting point toward the goal point. Also, in FIG. 5, the other player character 203 is displayed semi-transparently (indicated by a dotted line in the drawing).

[0051] In this game, multiple types of characters are available for use as player characters. For example, each player can select one of 12 different characters as the player character to be used by the player. Therefore, the other player character 203 may be a character selected by another player, and may be a character different from the player character 201.

[0052] In the following description, other players who have entered the same stage room are called "remote players," and the other player characters 203 operated by the remote players are called "remote characters." In addition, as will be described in detail later, a "replay ghost" may also appear on the stage screen as a player character related to a remote player. In addition, in the following, the player character, remote character, and replay ghost may be collectively referred to as "player actors." In this game, since up to four people can enter one room, a maximum of four player actors can exist in one room at the same time.

[0053] [About remote characters] Next, the remote characters will be described in more detail. In this game, the remote characters displayed in the stage room move in response to the operations of other players, but do not directly interfere with or affect the game play being executed on the game device 3 of the player. Specifically, between the game devices 3 connected to a certain stage room, the position information of each player's character and the position information of a predetermined object generated by each player character are basically shared. An example of a predetermined object generated by a player character is a "panel" to be described later. On the other hand, the state and position information of other objects such as enemy characters are not shared. For example, in each game device 3, the collision determination process with the stage object in the stage play is performed only for the player character 201 in each game device, and in principle, the collision determination process is not performed for the remote character. Therefore, even if the player character 201 overlaps with the position of the remote character, it will result in the character moving through without colliding (however, collision determination is exceptionally performed for special characters to be described later). Also, even if the remote character overlaps with an enemy character, collision judgment between the remote character and the enemy character is not performed, and the enemy character moves through the remote character. Also, for example, even if the player character 201 defeats the enemy character A, the state of this enemy character A is not reflected in the other game devices 3. In the other game devices 3, if the other players of the other game devices have not defeated the enemy character A, the enemy character A is controlled in a state in which it still exists. In other words, the progress management of the stage play itself is performed individually on each game device, and at this time, if there is a remote character, it is controlled so that only the display of the remote character is performed. Also, in order to make it easy to understand that the remote character does not interfere, the remote character is basically displayed in a semi-transparent manner. Therefore, each player can basically play the stage with the same feeling as single play without being affected by the actions of the other players and without hindering the actions of the other players.In other words, the player can experience the feeling of playing the game alone while being aware of the presence of remote characters, in other words, other players.

[0054] Also, as mentioned above, each player can play the game independently without being influenced by the other players. Therefore, it is not the case that stage play cannot start unless four players are present, and stage play can start even if there is only one player in the stage room. After that, up to four other players can enter the room in a mid-game manner. For example, if player B enters the room when player A has progressed to about one-third of the stage, player B's player character will start moving from the starting point. In other words, from player B's perspective, the stage play will start with player A's player character in a position that has progressed to a certain extent. Also, from player A's perspective, player B's entry into the room does not impede his play, and he can continue playing.

[0055] [About Replay Ghost] Next, the replay ghost will be described. The replay ghost reproduces the replay data of another player as a ghost. In this embodiment, the play from the midpoint to the goal point is stored as replay data in the game server 1. Then, when the play of the game stage reaches a certain progress, the replay ghost is made to appear. More specifically, when the game progresses to the midpoint with only one player in the stage room, that is, when the game progresses to the midpoint without matching with another player, the replay data is downloaded from the game server 1 and reproduced. As a result, the character of another player based on the replay data can be displayed as a ghost. This is the replay ghost. Moreover, since the replay ghost reproduces the replay, it behaves in the same manner as the remote character. As a result, when another player does not enter the room until the midpoint, it is possible to create a situation in which the player plays together with the ghost of another player. This can prevent players from feeling that there is little point in playing online due to the difficulty in matching with other players depending on the stage.

[0056] Here, the replay ghost is basically indistinguishable from the remote character in appearance. For example, FIG. 6 shows an example of a screen on which a replay ghost is displayed. In FIG. 6, three replay ghosts are displayed, and they are displayed semi-transparently like the remote characters. Also, their appearance is the same as that of the remote characters. And, since the remote characters are operated by living humans, for example, an operation to display an emote such as a facial image showing an emotion is possible. Therefore, although each game device 3 individually manages the play, such an operation allows players to communicate with each other to a certain extent. On the other hand, such communication is not possible for the replay ghost. Therefore, it is possible to distinguish between the remote character and the replay ghost. For example, when a remote character is approached, a sign image such as a user name that indicates that it is a remote character may be displayed. On the other hand, for the replay ghost, such a sign image may not be displayed even when the player approaches. In this way, the player can determine whether the character is a remote character or a replay ghost depending on the presence or absence of the sign image.

[0057] In this embodiment, more precisely, when the player character 201 comes into contact with the waypoint object, the replay ghost appears. This is because it is easy for the player to understand that the replay ghost appears when the waypoint is passed. In this example, the play progress is explained by taking the waypoint as an example, but in other embodiments, the progress that triggers the appearance of the replay ghost may be determined based on, for example, the time elapsed since the start of the stage play or the achievement level of an event in the stage.

[0058] Replay Ghost will be explained in more detail below.

[0059] [About recording replays] First, the recording of replay data will be described. In this embodiment, the recording of replay data is started when the player character 201 comes into contact with the waypoint object (hereinafter, this may be expressed as "passing through the waypoint"). Then, the recording is stopped when the player character 201 reaches the goal point. Thereafter, the replay data is transmitted to the game server 1 in conjunction with the stage clear process.

[0060] The reason why the timing for starting and stopping the recording of replay data is the contact with the waypoint object and the arrival at the goal point is that the recording can be started and stopped by natural actions of the player character 201. Also, there is no need to place a separate object dedicated to controlling the recording of replay data.

[0061] Also, if a "mis-event" occurs between passing the waypoint and reaching the goal, the recording of the replay data is temporarily stopped at that point. The mis-event will be described later, but for example, it is when the player character 201 is defeated by an enemy character. Also, when a mis-event occurs, if a certain condition is met, the play is temporarily interrupted, the remaining number of the player character 201 (so-called remaining lives) is reduced, and the game is restarted from the waypoint. In this case, basically, the replay data before the restart is discarded, and the recording of the replay data is started again from the point of the restart. However, in this embodiment, at this time, with a certain probability, the replay data before the restart is not discarded but is retained, and the recording of the replay data from the point of the restart is not performed. As described above, the replay data is transmitted to the server when the goal is reached, but if a restart occurs during the play due to the above control, the following two types of replay data can be transmitted. The first type is replay data of the content of reaching the goal, that is, replay data of the content of clearing the stage. The second type is replay data in which a mistake event occurs midway through the game, that is, replay data in which the stage was not cleared. This allows the content of the replay data to be diversified.

[0062] In addition, in this embodiment, the description is given assuming that only one waypoint is set, but there may be a stage with two or more waypoints set. In this case, recording starts from the first waypoint passed. If a mis-event occurs during the game, the game restarts from the last waypoint passed. Then, the recording of replay data related to the restart starts again from the last waypoint passed.

[0063] [About downloading and playing replays] Next, the download and playback of replay data will be described. The replay data is transmitted to the game server 1 as described above, and in this embodiment, the replay data is linked to each of the waypoint objects (stages) and managed in the game server 1. More specifically, the game server 1 holds the most recent 30 replay data for each stage.

[0064] Then, when the player character 201 passes the waypoint, a request for replay data is sent from the game device 3 to the game server 1. The game server 1 sends the most recent 30 replay data items corresponding to that stage, which are received by the game device 3. The game device 3 randomly selects up to three replay data items (since the stage room has a capacity of four people in this example) to be used as replay ghosts from the received 30 data items. At this time, replay data sent from the same source as the player who sent the request is excluded from the selection. In other words, one's own replay data is not selected.

[0065] Then, the selected replay data will start playing as a replay ghost. If multiple replay ghosts are used, the playback start timing will be staggered every few seconds. For example, if three replay ghosts are used, instead of generating and appearing all three at the same time, the second replay ghost will appear 5 seconds after the first replay ghost appears, and the third ghost will appear another 5 seconds after the second ghost appears, etc.

[0066] Also, if a remote character is present when replay data is downloaded and playback begins, the replay will not be played. For example, this may occur if another player enters the room at roughly the same time as the player passes the waypoint. This is because we want players to be able to communicate with remote characters if they exist.

[0067] Also, if a mistake event occurs and the game is restarted from a midpoint, the replay data is downloaded again. Therefore, when the game is restarted, different replay ghosts may appear before and after the restart. However, if a predetermined time has not passed since the previous download was completed, the downloaded data may be reused. Of course, the game may be re-downloaded every time regardless of the elapsed time, or conversely, the initially downloaded data may be reused regardless of the elapsed time.

[0068] [Number of replay ghosts and synchronization] Next, management of the number of replay ghosts and synchronization with other game devices 3 will be described. As described above, in this game, the progress of the game is managed individually on each game device, and the only information shared is basically the position information of each player's character. The replay ghost is also managed locally on each game device 3 without synchronization with other game devices 3. Here, assume that another player enters the room when a replay ghost has already appeared. In this case, adjustment is made so that the number of player actors in the stage is four or less. For example, assume that player A is playing with three replay ghosts and player B enters the room. In this case, the following process is performed on the game device 3 of player A. First, the replay ghost located at the farthest position from the current position of the player character 201 is erased. This leaves one frame for a player actor. Next, a remote character related to player B is generated and made to appear in the stage. At this time, if there is a replay ghost of the same character as the remote character, this replay ghost is also erased. Therefore, in this example, two replay ghosts may be deleted for every one new player. In this case, the total number of player actors will be three.

[0069] On the other hand, in the game processing in the game device 3 of the player B, the replay ghost does not exist, and the game progress is managed assuming that the player character 201 of the player A exists within the stage as a remote character.

[0070] [About the cooperation elements] As mentioned above, basically, each player can progress through the game independently without being influenced by other players. However, this game has elements of cooperative play in the following ways. Specifically, this game has a function called "revival assistance" that can help a player who has made a mistake, making it possible for players to influence each other.

[0071] A specific example of the revival assistance will be described below. First, a case where a mistake event occurs for the player character 201 is assumed. In this embodiment, the mistake event is an in-game event that reduces the remaining number of the player character (loses the remaining lives). Specifically, for example, as shown in FIG. 7, the mistake event is a case where the player character 201 comes into contact with an enemy character 202, and if it is assumed that a single play is being performed offline, the in-game event is a case where the play by the currently used player character 201 ends once, and the remaining number of the player character 201 decreases by one (hereinafter, this is called "lost"). After being lost, the in-game event is a restart from a specified point, or an event that leads to a game over. Other examples of the mistake event include, for example, a case where HP or life becomes 0 and the player is lost, or a case where the player falls into a pitfall and falls outside the stage. Note that, if HP or life still remains even after receiving damage, a loss does not yet occur, and therefore this is not considered to be a mistake event (it is treated as simply receiving damage).

[0072] In this game, in the case of offline single play, the occurrence of the above-mentioned mistake event leads directly to the above-mentioned loss, but in the case of playing while connected online, even if a mistake event occurs, if a certain condition is met, the player will not immediately become lost. In this embodiment, the certain condition is that a "revival assistance object" (described later) exists within a certain range from the player character 201. If the certain condition is met, the player character 201 changes into a character object with a different appearance as shown in FIG. 8 for a certain period of time. Hereinafter, the changed character object will be called a "special character". In addition, the state of the player character 201 that has changed into a special character will be called a "special state", and the state of the player character 201 that has not changed will be called a "normal state". In addition, during the special state, the remote character 203 is displayed in an opaque mode rather than a semi-transparent mode, which will be described later.

[0073] For the special characters, no collision judgment is performed with objects other than the revival assist object. Therefore, the special characters do not receive damage from enemy characters and the like, and can move by slipping through enemy characters 202 and terrain objects. Furthermore, while they are special characters, they can move in the air without being restricted by gravity in the virtual space. In other words, the player can freely move the special characters without worrying about collision judgment. For example, it is possible to move the special characters in a straight line aiming at the revival assist object. However, in the state of a special character, even if the special character reaches the goal point, it is not considered to have reached the goal, and the stage cannot be cleared.

[0074] In addition, in other embodiments, the special characters may be subjected to collision determination with objects other than the revival assist object. Also, the movement control may be performed under the influence of gravity in the virtual space.

[0075] After the player character 201 changes into a special character, the special character is moved toward the revival assist object (here, the remote character 203) as shown in FIG. 9. As a result, the position of the remote character 203 and the position of the special character overlap as shown in FIG. 10 before a predetermined time has elapsed. In other words, the revival assist object and the special character come into contact with each other. Then, as shown in FIG. 11, the player character 201 can be returned to the normal state without causing the player character 201 to be lost. In other words, it is possible to "revive" the player character 201 in which a miss event has occurred without causing the player character 201 to be lost. In the following description, the predetermined time is called the "revival possible time." It should be noted that the special character and the revival assist object may be revived by being in close proximity or adjacent to each other, not limited to being in contact with each other.

[0076] On the other hand, if the revival assist object is not present within the above-mentioned predetermined range when a mistake event occurs, no change to a special state occurs and the above-mentioned lost state is confirmed, resulting in a restart or game over.

[0077] In this embodiment, while the player character is transformed into a special character, the game screen is displayed in monochrome except for the revival assist object, i.e., the saturation of the terrain objects, enemy characters, etc. is reduced.

[0078] The above-mentioned predetermined range is, for example, a range that is equal to or shorter than the upper limit of the distance that is assumed to enable the player character 201 in the normal state to reach or approach the position of the revival assist object if the player character 201 moves the above-mentioned revival possible time. In other words, it is assumed that the range is within which the player character can revive from the special state to the normal state within the revival possible time, as viewed from the position where the mis-event occurred.

[0079] Therefore, for example, if the player character 201 and the remote characters move together to some extent, recovery from a mistake event can be made easier while playing as if playing a single game. In other words, advantages of online play that are not available in the case of offline single-play games can be obtained. Also, while a special state occurs in a single game, it is treated as a "miss event" or "lost" and the gameplay is interrupted, but in the online game, such interruptions do not occur and do not hinder the player's play. By providing such a cooperative play element, there is room for cooperation with other players in certain situations. This creates a situation in which the game is basically played as a single game, but if multiple players enter the stage room through matching, it becomes easier to cooperate with other players.

[0080] Furthermore, by providing the above-mentioned predetermined range, when the player character 201 is in a special state, it is possible to suppress the occurrence of a situation in which the player character 201 moves a large distance to seek help from a remote character or the like that is far away. For example, if the player character 201 returns to the vicinity of the starting point where the remote character is located even though the player character has progressed to a certain extent in the stage, the tempo of the game progresses poorly. Conversely, if the player character 201 is allowed to move to the position of a remote character that has progressed further than the player character, skipping various gimmicks in the stages along the way, the interest of the game is lost. In order to prevent such a situation, the player character 201 is shifted to a special state only when a revival assist object is present within the predetermined range as described above.

[0081] FIG. 12 shows a diagram summarizing the relationship between the normal state, special state, and lost state transitions. In FIG. 12, first, when a miss event occurs in the normal state, it is determined whether or not there is a revival assist object within a predetermined range. If there is, the state changes to a special state. In the special state, if the player can move to the position of the revival assist object, the player will be revived to the normal state. On the other hand, if there is no revival assist object within the predetermined range, the player will be lost. In this case, if there are any remaining player characters 201, the remaining number is reduced by one, the state becomes normal, and the play restarts from a predetermined restart point. If there are no remaining player characters 201, the game is over and the player is forced to leave the stage room.

[0082] In this embodiment, the revival time may change depending on the number of times the state changes to the special state. Specifically, the more times the state changes to the special state in one play (for example, from the start of play to the loss of one player character 201), the shorter the revival time will be in stages. For example, assume that the revival time is counted to 10. When the state changes to the special state for the first time, the 10 counts are counted at 2-second intervals (revival time = 20 seconds). When the state is revived and changes to the special state again, the counts are counted at 1.5-second intervals (revival time = 15 seconds). When the state changes to the special state for the third time, the counts are counted at 1-second intervals (revival time = 10 seconds), and when the state changes to the special state for the fourth time, the counts are counted at 0.5-second intervals (revival time = 5 seconds). When the counting intervals become shorter to a certain extent, the counts are not shortened any further. For example, the lower limit is set to 0.5-second intervals. This allows the player to make repeated mistake events, which makes it gradually more difficult to revive, thus adding a certain degree of tension to gameplay.

[0083] Here, a supplementary explanation will be given regarding the resurrection position when resurrected by the resurrection function. Here, the processing in the game device 3 that has entered the special state is considered as the basis. In other words, the game screen of the device in which the special character is being operated is considered as the basis. First, a case is assumed in which the special character and the resurrection target object are both outside the terrain. In this case, if the positions of the two overlap, the player character 201 is resurrected at the overlapping position. Next, a case is assumed in which the special character is located within the terrain and the resurrection target object, the remote character 203 in FIG. 13, is outside the terrain, as shown in FIG. 13. As described above, since there is no collision judgment with the terrain object or the like between the special character, such a situation may occur. In this case, the player character 201 is resurrected at the position of the remote character, as shown in FIG. 14.

[0084] Next, as shown in FIG. 15, assume that the special character is outside the terrain and the object to be revived (remote character 203) is inside the terrain. This can occur in the following cases. As described above, in this game, the game progress management itself is performed by each game device. And, for example, when there is a destructible terrain object, for example, a situation may occur in which the terrain object has not yet been destroyed in the game play of player A, but has been destroyed in the game play of player B. For example, assume that the player of the special character in FIG. 15 is player A, and the player of the remote character 203 is player B. In this case, the game screen viewed by the player B, which corresponds to the situation in FIG. 15, is a game screen as shown in FIG. 16. In the game screen of player B, the terrain object has been destroyed, and the player character 201 of player B is in the ruins. Also, as described above, the remote character only shares position information, and collision judgment with the terrain is not performed in the game device 3 of player A. Therefore, when viewed from player A, the screen may be as shown in FIG. 15. In this state, assume that player B makes the remote character jump towards the special character. As a result, the remote character and the special character come into contact with each other, as shown in Fig. 17. In this case, the player character 201 is revived on the spot, as shown in Fig. 18.

[0085] Next, assume that on the screen of the special character's player, as shown in FIG. 19, both the special character and the object to be revived are located within the terrain. Then, assume that their positions overlap within the terrain. In this case, a point where the player character 201 can be revived (a point outside the terrain) is searched for. For example, as shown in FIG. 20, a position outside the terrain is searched for while moving an invisible search pointer so as to expand in a spiral from the special character. Then, the player character 201 is revived at the first position outside the terrain found. As a result, the player character 201 is revived at a position as shown in FIG. 21.

[0086] If an object such as an enemy character that may cause a mis-event if it collides with the player character in the normal state at the revival position described above is present, the revival position may be further shifted to a position where the player character does not collide with the enemy character. In other words, the revival position may ultimately be determined to be a position free of obstacles such as terrain objects and enemy characters.

[0087] [About resurrection support objects] Next, the resurrection assist object will be described. In this embodiment, the resurrection assist object is one of the following three types of objects. (1) Remote Character (2) Replay Ghost (3) Panel The above panels are further divided into two types: "remote panels" and "server panels." Each will be explained below.

[0088] [Resurrection Support Object: Remote Character] First, the remote character has been described above, so a detailed description will be omitted, but the display mode will be supplemented. As described above, the remote character is basically displayed in a semi-transparent display mode. However, while the player character 201 is changed into a special character, it is displayed in an opaque mode, not a semi-transparent display mode. Also, while the remote character is displayed in an opaque mode, a collision determination between the remote character and the special character is performed. In other words, while in a special state, the remote character appears to be materialized. Also, the remote character at this time is in a state in which it can directly affect the player character 201 by reviving the player character 201 as described above. Also, as described above, in this embodiment, while the player character 201 is changed into a special character, the game screen is displayed in monochrome except for the revival assist object. Therefore, the remote character is displayed in an opaque and colored manner in a monochrome image, and the presence of the remote character can be made more noticeable. This makes the player aware that something will happen or that the player will be revived if he or she comes into contact with the remote character, and can visually show the player in an easy-to-understand manner where to go.

[0089] When the above-mentioned mistake event occurs and the player character 201 changes into a special character, a performance may be added in which a ball of light is thrown from the nearest revival assist object to the player character 201 as shown in FIG. 22. Then, the player character 201 that receives the ball of light may be shown to change into the special character. This makes it possible for the player to imagine that he or she may be saved if he or she comes into contact with the revival assist object that threw the ball of light. In other words, it is possible to make the player recognize the causal relationship between the revival assist object and the change into a special character.

[0090] [Resurrection Support Object: Replay Ghost] Next, the replay ghost also functions as a revival assist object. This is because the replay ghost behaves in the same way as the remote character, as described above. Therefore, the replay ghost as a revival assist object is controlled in the same way as the remote character. Therefore, when a miss event occurs, if the remote character or the replay ghost is within a specified range of the player character 201, it can change into a special character.

[0091] [About the panel] Next, an overview of the panel will be described. The panel is an object that the player character 201 can place and that the player character 201 can touch. The panel is an object that continues to remain in the stage room even after the player leaves the stage room. For example, when the player performs a panel placement operation on a game screen as shown in FIG. 23, a panel as shown in FIG. 24 can be placed. The panel placed by the player is also displayed on the game screen of other players who enter the stage room after that. In other words, the panel placed by other players (remote characters) is displayed on the game screen of the player, and can be touched. The panel also functions as the resurrection assist object. Therefore, when the player is a special character, the player can revive the player character 201 by touching the panel within the resurrection possible time. However, in this embodiment, the special character cannot touch the panel that the player placed. In other words, the panels that the special character can touch are only the remote panel that is the panel placed by the remote character, and the server panel described later. This is because, while the panels function as the above-mentioned revival assist objects, if the panels that the player has placed are treated as revival assist objects, the game difficulty may not be appropriately balanced, for example, because the game may become too easy. For this reason, in this embodiment, the panels that the player has placed are made in such a way that they cannot be touched (they cannot be used as revival assist objects).

[0092] In this embodiment, the locations where the player character 201 can place panels are limited to locations where there is a foothold, and it is not possible to place panels in the air, for example.

[0093] Furthermore, the above panel-like design is just one example, and the appearance does not have to be like that of a panel.

[0094] [Number of panels that can be placed] In this embodiment, it is assumed that a maximum of four panels can be placed on one stage. Also, it is assumed that each player can only place one panel. Therefore, if a player performs a new panel placement operation in a different location after placing a panel once, the previously placed panel is erased and a new panel is placed in the new location.

[0095] [Panel synchronization with other game devices] Furthermore, as described above, the panel that one player has placed is also displayed on the game screens of the other players. That is, in this embodiment, the position of the placed panel is also shared. Specifically, the game device 3 of the player who placed the panel transmits "placement event information" indicating "that the panel has been placed" and the placement position (coordinates) to the other game devices. In the other game devices 3 that receive this, processing to place the panel is performed in local game processing. However, such synchronization is performed only when the panel is placed, and subsequent deletion of the panel, etc. is managed locally in each game device 3. Therefore, for example, when a new panel is placed, the placement of the panel is synchronized, but depending on the subsequent development of game play in each game device, a situation may occur in which the panel remains in one game device but has been deleted in another game device.

[0096] [Resurrection Auxiliary Object: Remote Panel] Next, of the above panels, the remote panel will be described. As described above, the remote panel is a panel placed by the remote character. When the player character 201 touches the remote panel in a normal state, a reaction occurs in which the panel shakes, and the name of the remote player who placed the panel is displayed. Also, when the player character 201 is in a special state, if the player touches the panel within the above-mentioned revival possible time, the player can be revived in the same way as the remote character. In other words, when the player himself places a panel, this becomes a remote panel as seen by other players, and the player can indirectly help other players even if he is not on the same screen. For example, by placing a panel in a place where the player thinks that the above-mentioned mistake events will occur frequently, it is expected that the player can indirectly help other players.

[0097] [Resurrection Auxiliary Object: Server Panel] Next, the server panel will be described. In the game according to this embodiment, many different stages are prepared, and the player can select the stage he / she wants to play from among these. However, while many stages are prepared, depending on the stage, the number of players playing may be relatively small, and the panels may not be placed very often. Therefore, in this embodiment, information about the panels placed by each player (hereinafter, panel information) is stored in the game server 1. Then, the information about the panels is used when a new stage room is created, etc., to create a state in which the panels are placed on the stage. The panels placed based on the panel information stored in the game server 1 are the server panels. Details of the server panels will be described below.

[0098] [About sending information to the server] First, the transmission of panel information to the game server 1 will be described. In this embodiment, when a player leaves a stage room, panel information about a panel placed by the player is transmitted to the game server 1. The player leaves the stage room when, for example, the player reaches the goal or retires without clearing the game due to game over or the like. The panel information includes at least information indicating the stage on which the panel was placed and the placement position. However, when the player leaves the stage room, if the panel placed by the player has already been erased, the panel information is not transmitted. Also, if panel information placed by the player himself is already held in the game server 1 in that stage, the existing panel information is deleted and a new panel information is registered. This is to prevent the occurrence of a situation in which, for example, in a stage that is not often played, all the panels related to the stage are filled with panels related to the same player by a single player repeatedly "entering the stage, placing a panel, and leaving the stage."

[0099] [About receiving and placing server panels] Next, the use of the panel information transmitted to the game server 1 as described above will be described. First, if the number of panels placed on the stage is zero when the player enters the stage room, panel information is obtained from the game server 1. The situation in which the number of panels is zero when entering the room can occur, for example, in the following cases. First, a new stage room is created. Second, when an existing stage room is entered and no panels have been placed on the stage at that time. In other words, a server panel can be placed only when there are no panels on the stage when the player enters the room.

[0100] Regarding the acquisition of panel information from the game server 1, in this embodiment, the most recent 30 pieces of panel information linked to the stage are acquired from the game server 1. As described above, when the same player transmits panel information multiple times in the same stage, only the latest panel information is stored in the game server 1. Therefore, the acquired group of panel information does not include multiple pieces of panel information related to the same player. Then, from among these, up to four pieces of panel information are selected. In this embodiment, the capacity of the stage room is an example of a maximum of four people, so the maximum number of pieces of panel information is set to four according to this number of people, but it goes without saying that the number of pieces selected may be four or more or four or less. The selection method may be, for example, random selection.

[0101] Next, a server panel is generated based on the selected panel information. Then, the server panel is placed at the position indicated by each piece of panel information. Here, when entering the stage, it is possible that a panel previously placed by the player himself / herself exists as a server panel. In this case, the server panel previously placed by the player himself / herself is determined to be the player's panel, and if the player subsequently places a new panel, the server panel is made to disappear.

[0102] [About enabling the server panel] Next, the activation of the server panel will be described. Although the server panel can be arranged as described above, the server panel is in an inactive state as an initial state. That is, when the server panel is arranged, the server panel does not function as the above-mentioned revival assist object. FIG. 25 shows an example of an inactive server panel. As shown in FIG. 25, the inactive server panel is displayed in a black-filled display mode. Note that the display mode indicating the inactive state is not limited to black-filled, and any display mode may be used. Then, when the player character 201 comes into contact with the inactive server panel, the server panel can be activated as shown in FIG. 26. FIG. 26 shows that the black-filled display mode is released, and the server panel is displayed in the same display mode as normal. In this way, only the activated server panel functions as the above-mentioned revival assist object. Therefore, when a miss event occurs near an inactive server panel, the character is lost without changing into the special character as described above.

[0103] In addition, once a server panel is enabled, it remains enabled even if the player character 201 moves away from that server panel. Also, even if the game is restarted, a server panel that has been enabled once will not be disabled again and will remain enabled.

[0104] The reason why the server panel is initially disabled and enabled by contact with the player character 201 is as follows. First, when the character becomes a special character as described above, collision judgment with enemy characters or terrain is not performed. Therefore, if the server panel is enabled from the beginning, depending on the relationship of the placement position of the server panel, the player may intentionally change into a special character and move as a special character to a location (where the server panel is) that has not yet been reached in the normal state. In other words, it is conceivable that a shortcut can be taken to a location that has not yet been reached. In order to prevent such a situation from occurring, the server panel is disabled in the initial state. Note that this is about a stage room where there are no other players. For example, for a remote panel placed in real time by a remote character, the above-mentioned shortcut is permitted in order to make the player feel the benefits of online play and the elements of cooperative play. Therefore, the remote panel is enabled from the time of placement.

[0105] In addition, the server panel itself is disabled in the initial state, with the aim of providing a way to play the game by passing through it like a checkpoint.

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

[0107] [About the data used on Game Server 1] First, an explanation will be given of the data used in the game server 1. Fig. 27 is a memory map showing an example of various data stored in the storage unit 12 of the game server 1. At least a game server program 301, a player database 302, stage room management data 304, replay management data 305, and panel management data 306 are stored in the storage unit 12 of the game server 1.

[0108] The game server program 301 is a program that causes the game server 1 to function in order to realize the game processing as described above.

[0109] The player database 302 is a database related to each player who plays the game according to this embodiment. The database includes a plurality of player data 303. Each player data 303 includes, for example, a player ID 307 for identifying each player, a player name 308 of each player, and the like.

[0110] The stage room management data 304 is a database for managing the stage rooms. FIG. 28 shows an example of the data configuration of the stage room management data 304. In FIG. 28, the stage room management data 304 includes stage room information 312 for each stage number 311 that identifies each stage. A plurality of pieces of stage room information 312 may be included for one stage. Each piece of stage room information 312 is information corresponding to the stage room. Each piece of stage room information 312 includes a room ID 313, entering player information 314, and the like. The room ID 313 is an ID for uniquely identifying the stage room. The entering player information 314 is information about a player currently entering the stage room. For example, the entering player information 314 stores the player ID 307.

[0111] Returning to FIG. 27, the replay management data 305 is a data in which the replay data transmitted from the game device 3 is stored as described above. FIG. 29 shows an example of the data configuration of the replay management data. The replay management data 305 includes one or more replay data 322 for each stage number 321. Each replay data 322 includes at least a registration date and time 323, registered player information 324, and replay content 325. The registration date and time 323 indicates the date and time when the replay data was registered in the game server 1. The registered player information 324 is information about the player who generated the replay data. The registered player information 324 includes, for example, the player ID 307 and the like. The replay content 325 is data for indicating the content of the replay. For example, the replay content 325 is data in which information indicating the position information and state of the character related to the replay is arranged in chronological order and stored. The replay content 325 may also be, for example, key data or the like. In other words, the replay content 325 may be any data content as long as it is data that allows the operation history of the player to be understood.

[0112] Returning to FIG. 27, the panel management data 306 stores the panel information transmitted from the game device 3 as described above. FIG. 30 shows an example of the data configuration of the panel management data 306. The panel management data 306 includes one or more pieces of panel information 332 for each stage number 331. Each piece of panel information 332 includes at least a registration date and time 333, arranged player information 334, and arranged position 335. The registration date and time 333 indicates the date and time when the panel information 332 was registered in the game server 1. The arranged player information 334 is information about the player who arranged the panel related to the panel information 332. The arranged position 335 is information indicating the arranged position of the panel related to the panel information 332.

[0113] In addition, although not shown in the figures, various data necessary for performing player matching processing and the like may also be stored in the storage unit 12 as appropriate.

[0114] [Data used in game device 3] Next, a description will be given of data used in the game device 3. Fig. 31 is a memory map showing an example of various data stored in the storage unit 32 of the game device 3. The storage unit 32 of the game device 3 stores at least a game program 351, stage data 352, object data 353, player character data 354, remote character data 361, replay ghost data 362, player actor management data 363, panel data 364, operation data 365, a selection flag 366, and an arrangement completion flag 367.

[0115] The game program 351 is a program for executing the game processing in this embodiment in the game device 3.

[0116] The stage data 352 includes data for constructing the stage to be played on. Specifically, the stage data 352 includes, for each stage, data indicating the position information of the start point and goal point, and various objects to be placed in the stage, such as waypoint objects.

[0117] The object data 353 is master data that indicates the appearance of various objects arranged in the stage and character objects displayed as remote characters and replay ghosts. Specifically, the object data 353 includes model data and texture data of each object.

[0118] The player character data 354 is data related to the player character 201 that is the object of operation by the player. The player character data 354 includes data such as player position information 355, special state flag 356, number of times of special state 357, intermediate passing flag 358, replay recording data 359, and lost occurrence flag 360. The player position information 355 is data indicating the position of the player character 201 in the stage to be played. The number of times of special state 357 is a counter for recording the number of times the player character 201 has changed into the special character. The special state flag 356 is a flag indicating a special state when it is on and a normal state when it is off. The number of times of special state 357 is counted up by one each time the player character 201 changes into a special character. In addition, when the lost occurs, it is reset. The intermediate passing flag 358 is a flag for indicating whether the player character 201 has come into contact with the intermediate point object. When the player character 201 comes into contact with the intermediate point object, the flag is set to on. The replay recording data 359 is data for recording replay data of the player character 201. The loss occurrence flag 360 is a flag for indicating that the situation resulting in the above-mentioned loss has occurred. If it is on, it indicates that a situation resulting in a loss has occurred.

[0119] Next, the remote character data 361 is data of a remote character related to a remote player who has entered the same stage room. FIG. 32 shows an example of the data configuration of the remote character data 361. In this example, since a maximum of four people can enter the stage room, the remote character data 361 stores data of a maximum of three remote characters. Each data is generated when a remote player enters the room, and is appropriately deleted when the remote player leaves the room. Each data includes at least an identification name 371, remote player information 372, used character information 373, and remote position information 374. The identification name 371 is an identifier for uniquely identifying each remote character. The remote player information 372 is information for specifying a remote player who is operating each remote character. The used character information 373 is information for specifying a character displayed on the screen as a remote character. In other words, it is information indicating a character used by each remote player as a player character. The remote position information 374 is information indicating the position of the remote character in the stage.

[0120] 31, the replay ghost data 362 is data about the replay ghost. Specifically, the replay ghost data 362 stores up to three of the replay data 322 used as the replay ghost.

[0121] The player actor management data 363 is data for managing the allocation relationship between the frame of the player actor, the remote character, and the replay ghost. FIG. 33 shows an example of the data configuration of the player actor management data 363. The actor frame number 381 is the frame number of the player actor. In this example, a case where four frame of the player actor are prepared will be described as an example. The allocation target 382 is information for identifying the player actor assigned to that frame. First, one frame is assigned to the player character 201. Therefore, for the remaining three frames, information for identifying either the remote character or the replay ghost is stored. Also, when a remote character or a replay ghost is not assigned, a Null value is set.

[0122] Returning to FIG. 31, next, the panel data 364 is data for managing the above-mentioned panels. FIG. 34 shows an example of the data configuration of the panel data 364. The panel data 364 includes the own panel data 391, the remote panel data 394, and the server panel data 400. In this example, three pieces of the remote panel data 394 and the server panel data 400 are prepared. The own panel data 391 is information on the panel (hereinafter, the own panel) arranged by the player character 201. The own panel data 391 includes the own panel arrangement position 392 and the own panel arrangement date and time 393. The own panel arrangement position 392 indicates the arrangement position of the own panel, and the own panel arrangement date and time 393 indicates the date and time when the own panel was arranged. In addition, when the panel arrangement is performed multiple times, the latest arrangement content is saved in the own panel data 391.

[0123] The remote panel data 394 is information about a panel placed by a remote character. The remote panel data 394 includes a remote panel placement position 396, placement player information 397, and remote panel placement date and time 398. The remote panel placement position 396 indicates the placement position of the remote panel, and the remote panel placement date and time 398 indicates the date and time when the remote panel was placed. The placement player information 397 is information about another player who placed the remote panel.

[0124] The server panel data 400 is data related to the server panel. The server panel data 400 includes a server panel arrangement position 402 and an activation flag 403. The server panel arrangement position 402 indicates the position where the server panel is arranged. The activation flag 403 is a flag indicating whether the server panel is activated or not. The initial value of the activation flag 403 is off, and is set to on when activated.

[0125] 34, panel data 364 can store data for a total of seven panels, including the local panel, remote panel, and server panel. However, as mentioned above, since only a maximum of four panels can be arranged on a stage, the data that is actually used is a maximum of four of the data for the seven panels. In other words, as panels are arranged, the contents of each data are deleted and generated as appropriate so that the maximum number of panels is four.

[0126] Returning to Fig. 31, the operation data 365 is data obtained from the controller 4 operated by the player. That is, it is data indicating the content of the operation performed by the player.

[0127] The selected flag 366 and the placement completion flag 367 are flags used in the process of placing a replay ghost. The selected flag 366 is a flag for indicating whether or not the selection of a replay ghost from the downloaded replay data has been completed. The placement completion flag 367 is a flag for indicating whether or not all the selected replay ghosts have been placed within the stage.

[0128] In addition, although not shown in the figure, various data required for game processing, such as transmission data for transmitting various data to other game devices, received data received from other game devices 3, replay data downloaded from the server, etc., may also be generated as needed and stored in the memory unit 32.

[0129] Next, details of the game processing in this embodiment will be described. First, details of the processing performed by the game device 3 will be described, and then the processing by the game server 1 will be described.

[0130] [Details of Processing Executed by Processor 31 of Game Device 3] 35 and 36 are flowcharts showing details of the game device side processing executed by the processor 31 of the game device 3. In this embodiment, one or more processors read and execute the above program stored in one or more memories, thereby realizing the flowchart shown below. Note that the flowchart shown below is merely an example of the processing procedure. Therefore, the processing order of each step may be changed as long as the same result is obtained. In addition, the values ​​of the variables and the threshold values ​​used in the determination steps are merely examples, and other values ​​may be adopted as necessary.

[0131] When a player instructs game device 3 to play a predetermined stage, first, in step S1, processor 31 executes stage start processing. FIG. 37 is a flowchart showing details of the stage preparation processing. In FIG. 37, first, in step S21, processor 31 executes entry processing into a stage room. Specifically, first, processor 31 requests matching processing from game server 1. Then, processor 31 executes entry processing into a stage room determined based on the matching result. At this time, when entering an existing room, processor 31 also transmits information of the character used by processor 31 as player character 201 to game device 3 associated with a player who has already entered the room.

[0132] Next, in step S22, processor 31 generates a stage (virtual space) to be played this time, based on stage data 352. Furthermore, when entering an existing stage room, information on a remote character and a remote panel is received from another game device 3. Then, various characters are arranged in the stage.

[0133] Next, in step S23, processor 31 determines whether or not the number of panels in the stage is 0. If the result of this determination is not 0 (NO in step S23), processing proceeds to step S27 described below. On the other hand, if the number is 0 (YES in step S23), processor 31 acquires the most recent 30 pieces of panel information from game server 1 in step S24. Next, in step S25, processor 31 randomly selects four pieces of panel information from the acquired panel information. Then, processor 31 stores the selected panel information as server panel data 400. At this time, if information on a panel previously placed by the player himself is included, this is stored as own panel data 391. Then, processor 31 places the server panels based on panel data 364.

[0134] Next, in step S26, if there is another player in the stage room, processor 31 transmits information about the placed server panel (and possibly its own panel data) to the other game devices. That is, the information about the server panel is shared with remote players in the same stage room. Note that, for example, if two players enter the room at almost the same time and both perform processes related to the server panel, the information about the server panel of one of the players is given priority.

[0135] Next, in step S27, processor 31 generates a game screen and displays it on display unit 5. This starts the stage play.

[0136] Returning to FIG. 35, next, in step S2, processor 31 executes entry / exit check processing. This is processing for checking entry / exit of other players that occurs after a player enters the room. FIGS. 38 and 39 are flowcharts showing details of the entry / exit check processing. First, in step S31, processor 31 determines whether or not a new player without a corresponding remote character has entered the room. If the result of the determination is that there is no new player entering the room (NO in step S31), processor 31 advances the processing to step S39 described below. On the other hand, if a new player has entered the room (YES in step S31), processor 31 transmits information on the server panel and remote panel that have been installed at that time to game device 3 of the player who has entered the room, as necessary, in step S32. Note that the information transmission processing may be performed by any of game devices 3 of players who have previously entered the room.

[0137] Next, in step S33, processor 31 determines whether or not the number of players in the room has reached four. If the result of this determination is that the number of players has not reached four (NO in step S33), the process proceeds to step S36 described below. On the other hand, if the number of players has reached four (YES in step S33), in step S34, processor 31 refers to player actor management data 363 and determines whether or not there is an empty slot for a player actor. If the result of this determination is that there is no empty slot (NO in step S34), it is considered that a replay ghost exists. Therefore, in step S35, processor 31 deletes the replay ghost that is located farthest from player character 201. That is, data related to the replay ghost is deleted from replay ghost data 362 and player actor management data 363. Then, the process proceeds to step S36. On the other hand, if the result of the above determination is that there is an empty slot for a player actor (YES in step S34), the process of step S35 is skipped.

[0138] Next, in step S36, based on the information received from the game device of the player who has joined the room, processor 31 adds data of a remote character corresponding to the player who has joined the room to remote character data 361. Then, based on remote character data 361, processor 31 places the remote character corresponding to the player who has joined the room.

[0139] Next, in step S37, processor 31 determines whether or not a replay ghost of the same player as the currently placed remote character exists. If the result of this determination is that a replay ghost exists (YES in step S37), processor 31 deletes the replay ghost of the same player in step S38. That is, processor 31 deletes the data of the replay ghost from replay ghost data 362. On the other hand, if a replay ghost of the same player does not exist (NO in step S37), the processing of step S38 is skipped.

[0140] Next, in step S39 of FIG. 39, processor 31 determines whether or not any remote player has left the room. In addition, processor 31 also determines whether or not playback of a replay ghost that exists at that time has ended. If the result of this determination is that a remote player has left the room or playback of a replay ghost has ended (YES in step S39), in step S40, processor 31 deletes the remote character associated with the player who has left the room. Alternatively, processor 31 deletes the replay ghost whose playback has ended and the corresponding replay data.

[0141] On the other hand, if neither the remote player has left the room nor the replay ghost has finished playing (NO in step S39), the process of step S40 is skipped. After that, processor 31 ends the entry / exit check process.

[0142] Returning to FIG. 35, next, in step S3, processor 31 executes remote panel check processing. This is processing for reflecting a panel placed by a remote player in its own game processing when the panel is placed. FIG. 40 is a flowchart showing details of the remote panel check processing. First, in step S51, processor 31 determines whether or not the above-mentioned arrangement event information has been received from another game device 3. If the result of the determination is that the information has been received (YES in step S51), processor 31 updates the contents of panel data 364 based on the arrangement event information in step S52. For example, if the same player re-places a panel, a process is performed to delete the already placed panel and replace it with data of a new panel. Also, if a new panel is placed, data related to the panel is newly created. Then, processor 31 appropriately places a remote panel based on panel data 364. On the other hand, if the result of the above-mentioned determination is that the arrangement event information has not been received, the process of step S52 is skipped. Thereafter, the remote panel check processing ends.

[0143] Returning to FIG. 35, next, in step S4, processor 31 refers to special state flag 356 and determines whether or not player character 201 is in a special state. If the result of the determination is that the player character 201 is not in a special state (NO in step S4), in step S5, processor 31 executes normal state processing. On the other hand, if the player character 201 is in a special state (YES in step S4), in step S6, processor 31 executes special state processing. Each process will be described below.

[0144] [Processing under normal conditions] 41 and 42 are flowcharts showing details of the normal state processing. In FIG. 41, first, in step S61, processor 31 acquires operation data 365. Next, in step S62, processor 31 determines whether or not a panel arrangement operation has been performed. If the result of the determination is that a panel arrangement operation has been performed (YES in step S62), processor 31 executes own panel arrangement processing in step S64. FIG. 43 is a flowchart showing details of the own panel arrangement processing. First, in step S81, processor 31 refers to panel data 364 and determines whether or not an existing own panel exists. If it exists (YES in step S81), processor 31 erases the existing data of the own panel from panel data 364 in step S82. On the other hand, if it does not exist (NO in step S81), the processing of step S82 is skipped.

[0145] Next, in step S83, processor 31 places the own panel at the position where the panel placement operation was performed. That is, processor 31 generates data related to the own panel in panel data 364, and places the own panel on the stage based on the data.

[0146] Next, in step S84, processor 31 generates arrangement event information relating to the own panel, and transmits it to the other game devices 3. This ends the own panel arrangement processing.

[0147] 41, if it is determined in step S62 that a panel arrangement operation has not been performed (NO in step S62), in step S63, processor 31 controls the movement of player character 201 based on the operation content indicated by operation data 365. Furthermore, processor 31 transmits to other game device 3 position information of player character 201 and state information indicating whether the state is a normal state or a special state.

[0148] Next, in step S65, processor 31 receives information about the remote character from another game device 3, and moves the remote character. The information about the remote character is information indicating the position information and state of the remote character. Note that, instead of the position information, for example, operation information performed by the remote player may be received. In this case, the movement of the remote character may be controlled based on the received operation information. Also, if a replay ghost exists, processor 31 continues playback based on the replay data. This causes the movement of the replay ghost to be controlled.

[0149] Next, in step S66, processor 31 controls the actions of enemy characters, etc. Furthermore, processor 31 performs collision determination between player character 201 and an enemy character, a remote panel, etc., and appropriately executes game processing according to the result. For example, when a remote panel is contacted, a process is performed to temporarily display the name of the remote player who placed the remote panel. Also, for example, when an enemy character is contacted, a process is performed to inflict damage on the enemy character, or a process is performed in which player character 201 receives damage, and as a result of this game processing, the above-mentioned miss event may occur.

[0150] Next, in step S67, processor 31 determines whether or not player character 201 has come into contact with the waypoint object. If the result of this determination is that there has been contact (YES in step S67), in step S68, processor 31 sets middle pass flag 358 on. Accordingly, subsequent restart points are also set to the positions of the waypoint object. Next, in step S69, processor 31 uses replay recording data 359 to start recording replay data related to player character 201. At this time, if the situation is one in which the restart has been made from the waypoint, control may be performed so that recording of replay data is not started with a certain probability, as described above.

[0151] On the other hand, if the result of the determination in step S67 above is that the waypoint object is not in contact (NO in step S67), the processes in steps S68 and S69 above are skipped.

[0152] Next, in step S70 of Figure 42, processor 31 determines whether or not the player character 201 has come into contact with an invalid server panel. If the result of this determination is that there has been contact (YES in step S70), processor 31 sets ON the activation flag 403 of the contacted server panel in step S71. On the other hand, if there has been no contact (NO in step S70), the processing of step S71 is skipped.

[0153] Next, in step S72, processor 31 determines whether or not the above-mentioned miss event has occurred. If the result of the determination indicates that the miss event has occurred (YES in step S72), processor 31 stops recording of replay data in step S73. Next, in step S74, processor 31 determines whether or not a condition for player character 201 to enter a special state is satisfied. That is, processor 31 determines whether or not any revival assist object exists within a predetermined range from player character 201. If the result of the determination indicates that the condition for entering a special state is satisfied (YES in step S74), processor 31 performs a setting for placing player character 201 in a special state and various settings associated therewith in step S75. Specifically, processor 31 sets special state flag 356 to ON. Furthermore, processor 31 changes player character 201 to a special character. Furthermore, processor 31 adds 1 to special state count 357. Furthermore, processor 31 performs display settings for the game screen so that the game screen is displayed in monochrome except for the revival assist object. After that, the normal state processing ends.

[0154] On the other hand, if the condition for entering the special state is not satisfied (NO in step S74), in step S76, processor 31 sets ON lost occurrence flag 360. After that, the normal state processing ends.

[0155] On the other hand, if the result of the determination in step S72 above is that a miss event has not occurred (NO in step S70), the normal state process ends.

[0156] [Processing in special situations] Next, the special state processing will be described. Fig. 44 is a flow chart showing details of the special state processing. First, in step S91, processor 31 acquires operation data 365. Next, in step S92, processor 31 moves the special character based on the operation data. As described above, while the special character is in the state, no collision determination with the terrain or enemy characters is performed.

[0157] Next, in step S93, processor 31 controls the remote character. While player character 201 is in the special state, as described above, the remote character is controlled to be displayed opaquely, not semi-transparently. Also, control is performed so that a collision determination is performed between the remote character and the special character. Also, if a replay ghost exists, the replay ghost is controlled in the same way as the remote character.

[0158] Next, in step S94, processor 31 controls the actions of enemy characters and the like, and performs various types of game processing associated therewith.

[0159] Next, in step S95, processor 31 advances the count of a special counter for counting the time during which recovery from the special state is possible. At this time, processor 31 advances the count after appropriately changing the time interval for one count based on special state occurrence count 357.

[0160] Next, in step S96, processor 31 determines whether or not the count of the special counter has ended. If the result of this determination is that the count has not yet ended (NO in step S96), processor 31 determines whether or not the resurrection condition has been satisfied (NO in step S96). In other words, processor 31 determines whether or not the special character has been able to come into contact with any of the resurrection target objects within the resurrection possible time. If the result of this determination is that the condition has been satisfied (YES in step S97), processor 31 sets special state flag 356 to OFF (step S98). Furthermore, processor 31 changes the special character to player character 201 in a normal state. Furthermore, processor 31 cancels the monochrome display setting of the game screen and sets it to normal display. Next, in step S99, player character 201 is placed at a predetermined resurrection position. The resurrection position is determined, for example, by shooting a ray from the contacted resurrection target object to the special character and determining whether or not it hits the terrain. If it hits the terrain, the position of the resurrection assist object is set as the resurrection position. If it does not hit, the position of the special character is set as the resurrection position. As a result, the positions shown in Figs. 13 to 18 are determined as the resurrection positions. However, as shown in Fig. 19, when both are within the terrain, the search pointer is expanded in a spiral shape to search for the resurrection position. When an enemy character or the like is present at the determined or searched resurrection position, the resurrection position may be shifted to a position that does not contact the enemy character. In other words, a position where a mis-event does not occur immediately after returning to the normal state may be determined as the resurrection position, and the player character 201 may be placed there.

[0161] In addition, when determining the resurrection position, the size of the player character returned to the normal state is also taken into consideration. In other words, a position where there is enough space to prevent the player character returned to the normal state from getting stuck in an obstacle or the like is determined as the resurrection position. For example, a position such as a gap between obstacles that can be placed for a small player character but does not have enough space for a large player character is assumed. In this case, even if such a gap position is found, if it is determined that there is not enough space in consideration of the size of the player character, the search for other positions continues. On the other hand, if it is determined that there is enough space, this gap position is determined as the resurrection position.

[0162] On the other hand, if it is determined in step S96 that the special counter has finished counting (YES in step S96), in step S100, processor 31 sets lost occurrence flag 360 to ON. Then, the special state process ends.

[0163] Returning to FIG. 35, next, in step S7, processor 31 determines whether lost occurrence flag 360 is on or not. If it is not on (NO in step S7), in step S8, processor 31 determines whether player character 201 has already contacted the waypoint object based on middle passage flag 358. If the result of this determination is that there has not yet been contact (NO in step S8), processing proceeds to step S10 described below. On the other hand, if there has been contact (YES in step S8), in step S9, processor 31 executes replay ghost processing.

[0164] FIG. 45 is a flowchart showing details of the replay ghost process. First, in step S111, the processor 31 determines whether or not the arrangement completion flag 367 is on. If it is on (YES in step S111), the processor 31 ends the replay ghost process. On the other hand, if it is off (NO in step S111), the processor 31 determines whether or not the selection completion flag 366 is on (YES in step S112), the process proceeds to step S117 described below. If it is off (NO in step S112), the processor 31 determines whether or not the download of the replay data from the game server 1 is completed (step S113). If it is not yet completed as a result of the determination (NO in step S113), the processor 31 starts downloading the replay data from the game server 1 (step S115). Alternatively, if it has already started, the processor 31 continues the download. Thereafter, the replay ghost process ends.

[0165] On the other hand, if the download of the replay data is completed (YES in step S113), then in step S114, processor 31 determines whether or not a remote player is present at this point. If the result of this determination is that a remote player is present (YES in step S114), in step S119, processor 31 sets placement completion flag 367 to ON. In this case, for example, if a remote player enters the room during download, even if the download of the replay data is completed, the replay ghost will not actually be placed. Then, the replay ghost processing ends.

[0166] On the other hand, if there is no remote player (NO in step S114), in step S116, processor 31 randomly selects up to three pieces of replay data to be used as replay ghosts from the downloaded replay data. At this time, processor 31's own replay data is excluded from the selection. Then, processor 31 sets selected flag 366 to ON.

[0167] Next, in step S117, processor 31 determines whether or not all of the selected replay ghosts have been placed on the stage. If not all have been placed yet (NO in step S117), in step S118, processor 31 generates one replay ghost and places it on the stage. At this time, as described above, the replay ghosts are controlled to be placed one by one while slightly shifting the timing of placement.

[0168] On the other hand, when all the selected replay ghosts are placed within the stage (YES in step S117), the process proceeds to step S119, where the placement completion flag 367 is set to ON. After that, the replay ghost process ends.

[0169] 36, processor 31 determines whether or not player character 201 has reached the goal. If the result of this determination is that player character 201 has not yet reached the goal (NO in step S10), processor 31 generates and displays a game screen that reflects the above processing in step S11. Then, the process returns to step S2, and the processing is repeated.

[0170] On the other hand, if the goal is reached (YES in step S10), in step S12, processor 31 executes stage clear processing. FIG. 46 is a flowchart showing the details of the stage clear processing. First, in step S141, processor 31 stops recording of replay data to replay recording data 359. Next, in step S142, processor 31 displays an effect that the stage has been cleared. Next, in step S143, processor 31 transmits replay recording data 359 to game server 1. Thereafter, the stage clear processing ends.

[0171] Returning to FIG. 36, next, in step S13, processor 31 transmits own panel data 391 to game server 1 if the own panel placed by processor 31 remains on the stage.

[0172] Next, in step S14, processor 31 performs a process to exit the stage room, after which the stage process ends.

[0173] Next, a process will be described when the result of the determination in step S7 above is that lost occurrence flag 360 is on (YES in step S7). In this case, first, in step S15, processor 31 subtracts 1 from the remaining number of player characters 201. Next, in step S16, processor 31 determines whether the remaining number of player characters 201 is 0 or not. If the result of this determination is not 0 (NO in step S16), processor 31 executes a restart process in step S17.

[0174] Fig. 47 is a flowchart showing details of the restart process. In Fig. 47, first, in step S131, processor 31 sets lost occurrence flag 360 to OFF. At this time, special state change count 357 is also set to 0. In other words, the count of the number of changes to the special state is reset in association with the restart. In this regard, in other embodiments, special state change count 357 may be carried over after the restart without being reset.

[0175] Next, in step S132, the processor 31 initializes the selected flag 366 and the arrangement completion flag 367. This allows replay data to be downloaded again and a new replay ghost to be rearranged when restarting from the midpoint.

[0176] Next, in step S133, processor 31 places player character 201 at a predetermined restart point. In addition, in conjunction with this, the virtual camera is also moved to a position where player character 201 is within the imaging range. Next, in step S134, processor 31 generates and displays a game screen. This ends the restart process.

[0177] Returning to FIG. 36, when the restart process is completed, the process returns to step S2 and the process is repeated.

[0178] On the other hand, if the result of the determination in step S16 above is that the remaining number of player characters 201 is 0 (YES in step S16), processor 31 displays a game over effect in step S18. Then, the process proceeds to step S13 above. In this case, the information of the player's panel is transmitted to game server 1, and then the player leaves the stage room.

[0179] This completes the detailed explanation of the stage play process.

[0180] [Game Server 1 Processing] Next, the details of the process executed by the game server 1 will be described. FIG. 48 is a flowchart showing the details of the process related to the game server 1. In FIG. 48, first, in step S151, processor 11 of game server 1 executes a matching process. In this process, in response to a request from a player to start a stage play, matching between players, that is, a process of determining a stage room into which each player will enter, is executed. In addition, a process of transmitting the result to game device 3 is also executed.

[0181] Next, in step S152, processor 31 performs a process of managing the stage rooms. In this process, processes of creating a new room, compensating for a player, deleting a room with no players, etc. are performed by appropriately updating stage room management data 304 to manage each stage room.

[0182] Next, in step S153, processor 31 executes a process for managing panel information. In this process, own panel data 391 transmitted from each game device 3 is received, and the data is registered or updated in panel management data 306. In addition, if necessary, a process for transmitting panel information 332 that is the basis of the server panel is also executed in response to a request from a specific game device 3.

[0183] Next, in step S154, processor 31 performs a process for managing the replay data. In this process, registration and updating of replay management data 305 is performed based on the replay data received from each game device 3.

[0184] After that, the processor 11 returns to step S151 and repeats the process. This concludes the detailed description of the process related to the game server 1.

[0185] In this manner, in this embodiment, when a mistake event occurs to the player character 201, if there is a remote character, which is a revival assist object, nearby, the player character 201 is not lost, but is temporarily changed to a special state. Then, by contacting the remote character during the revival possible time, the player can be revived to the normal state. This allows the player to progress through the game with the feeling of single play, while still being able to enjoy the benefits of playing online. This can promote online multiplayer gameplay.

[0186] In addition to the remote characters, the remote panels placed by each remote character and the server panel also function as the revival assistance objects. Therefore, if a player places a remote panel, he or she can expect it to function as a help for other players on his or her behalf. This prevents, for example, a situation in which a player becomes conscious of assisting the revival of another player and is unable to progress in the game at his or her own pace.

[0187] In addition, in this embodiment, as described above, a replay ghost is made to appear in response to passing the midpoint of the stage. The replay ghost is indistinguishable from the remote character at first glance. The replay ghost also functions as the resurrection assist object. Therefore, even if the player does not meet other players until the middle of the stage, the player is connected to other players online in the latter half of the stage, and the player can be provided with a play experience of playing together in the same stage room. In other words, from the start of stage play until the midpoint is reached, a sense of expectation is given that the player will meet other players. For example, in the first half of the stage, it is quite conceivable that the remote character of the player who entered the room later will catch up. Therefore, the ghost is not made to appear immediately after the start of stage play, but is made to wait for the entry of other players and the appearance of remote characters for a while. On the other hand, if the player does not enter the room even after the midpoint is reached from the start of stage play, the replay ghost is made to appear, providing a play experience as if the player is progressing through the stage together with the remote character. This gives meaning to playing online, and encourages players to play online proactively. Also, if other players enter the room after the replay ghost appears, the replay ghost is erased and a remote character appears according to the number of players who have entered the room. Therefore, it is possible to prioritize playing with a remote character with whom communication is possible.

[0188] [Variations] In addition, regarding the replay ghost, for example, a character that is the same as the character that the player uses as the player character 201 may be selected as the replay ghost. In this case, the appearance of the character related to the replay ghost may be changed to the appearance of another character. This is to prevent unnecessary confusion for the player, since if there is a replay ghost that is the same character as the player character 201, it may be difficult to distinguish them in some cases.

[0189] In the above example, the timing for making the replay ghost appear is when the player character reaches the midpoint. In this regard, the replay ghost may be made to appear from the start point in a specific stage. In this case, the recording of the replay data for the specific stage may also be made to start from the start point.

[0190] In the above example, the appearance of the replay ghost is the same as that of the remote character, but in other embodiments, the appearance may be different so that the player can distinguish between the remote character and the replay ghost.

[0191] Also, in the above example, a replay ghost is not made to appear (replay is not played back) when a remote character is present. In other embodiments, a replay ghost may be made to appear even when a remote character is present. For example, replay ghosts may be made to appear as many times as there are vacant seats in the stage room. Furthermore, in this case, information on a replay ghost made to appear on one of the game devices may be shared with other game devices. For example, when a process for making a replay ghost appear is performed in the game process of game device A, the same replay ghost may be made to appear on other game devices in the same stage room by sharing position information or the replay data itself, etc.

[0192] In the above embodiment, an example was given in which the player character 201 changes to a special state when a mistake event occurs under a predetermined condition. In this regard, in other embodiments, the player may perform a predetermined operation to spontaneously change to the special state. However, the player may not be able to spontaneously restore the normal state from the special state, but may need to contact the revival assist object within the revival possible time, as described above. This allows the player to strategically intentionally enter a special state when conquering a stage, and revive after passing through a difficult part on the stage. This makes it possible to broaden the scope of play while maintaining the benefits of online play.

[0193] In another embodiment, the remote panels may be controlled so that a remote panel placed by a player who has left the room is automatically erased when a predetermined time has elapsed since the player left the room.

[0194] In addition, in the above example, the timing of transmitting the panel information to the game server 1 is exemplified as being when the player leaves the stage room. In other embodiments, the panel information may be transmitted to the game server 1 each time a placement is performed. Also, multiple pieces of panel information for the same player may be registered in the game server 1.

[0195] Also, in the above embodiment, an example was described in which collision detection between the player character 201 in the normal state and a remote character is not performed. In this regard, in other embodiments, collision detection itself is performed, but processing may be performed such that the remote character does not directly affect the gameplay of the player. For example, when the player character 201 in the normal state comes into contact with a (semi-transparent) remote character, a processing may be performed in which the remote character's reaction is displayed as if it is being pushed slightly, while the name of the remote player associated with the remote character is temporarily displayed.

[0196] In the above embodiment, the description is given on the assumption that each game device has one player. In this regard, for example, two players may be allowed to participate in stage play at the same time on one game device. For example, in game device A, player A and player B may be allowed to display their respective player characters, player character A and player character B, on the same game screen in a two-player simultaneous play (local multiplay) mode. In this case, player character A and player character B may not be displayed semi-transparently like remote characters, but may be displayed in an opaque mode. Furthermore, player character A and player character B may function as resurrection assist objects for each other. Furthermore, with regard to the panel arrangement, each may treat the panel arranged by the other as the remote panel. Alternatively, only the panel arranged by one of the player characters may be treated as the remote panel.

[0197] In the case of local multiplayer as described above, the panel information transmitted to the server may be only information about the panels placed by any one of the players. Regarding the above-mentioned server panels, a maximum of two may be arranged.

[0198] In addition, the number of player actors in one room is adjusted to a maximum of four, so it is sufficient to place up to two replay ghosts in one room.

[0199] Also, if all player characters involved in local multiplayer are no longer in their normal state, and there are no special characters, the player characters involved in that local multiplayer will be lost at that point. On the other hand, if any of them are special characters, they will not be lost at this point. This is because there is a possibility that they can be revived by the remote characters or remote panels.

[0200] In the above embodiment, an example was given in which if the special character can come into contact with the resurrection assist object within the resurrection possible time, the player character is resurrected without reducing the remaining number of characters. In this regard, in other embodiments, the character may be resurrected after reducing the remaining number. Even in this case, the resurrection position will be a position near the resurrection assist object, which is more advantageous for the player than returning to the restart point and resurrecting. [Explanation of symbols]

[0201] 1. Game System 3. Information processing terminal (game device) 4. Controller 31 Processors 32 Storage section 33 Wireless Communication Department 34 Controller communication section

Claims

1. On the computer, moving a first player object within a game stage based on the first operation data; moving a second player object within the game stage based on second operation data; when a position of a revival assist object including at least a second player object in a first state satisfies a first condition and the first player object satisfies a second condition, transitioning the state of the first player object from the first state to a second state without subtracting a remaining number associated with the first player object; when the first player object in the second state and the revival assist object have a predetermined positional relationship, transitioning the state of the first player object from the second state to the first state without subtracting the remaining number; when the position of the resurrection assist object does not satisfy the first condition and the first player object satisfies the second condition, subtracting the remaining number and placing the first player object in the first state at a predetermined position within the game stage; determining that the game stage has been successfully cleared when a predetermined clearing condition is satisfied in the game stage; determining that the player has failed to clear the game stage when the remaining number reaches a predetermined value; Game program.

2. the game program causes the first player object or the second player object to place a placement object at a predetermined position within the game stage based on a predetermined operation; The game program according to claim 1 , wherein the resurrection assist object includes the placed object placed in the game stage by the second player object.

3. 2. The game program according to claim 1, wherein, if the first player object in the second state and the resurrection assist object do not attain a predetermined positional relationship within a predetermined time after the first player object has transitioned to the second state, the remaining number is subtracted and the first player object in the first state is placed at a predetermined position within the game stage.

4. 4. The game program according to claim 3, wherein, when a transition to the second state occurs multiple times within the same game stage, the predetermined time is gradually shortened as the number of transitions to the second state increases.

5. the game program further causes the computer to function as ghost appearance means for making a ghost character appear in the game space, the ghost character acting based on replay data for replaying play content of other players; The game program according to claim 1 , wherein the resurrection assist object also includes the ghost character associated with the other player.

6. The game program according to claim 1 , wherein when the first player object is in the second state, the game screen is displayed with the saturation of the game stage reduced except for the resurrection assist object.

7. 2. The game program according to claim 1, wherein, when returning the first player object in the second state to the first state, the computer places the first player object in the first state at a position such that the second condition is not satisfied immediately after the first state is returned to the first state.

8. 1. A gaming system comprising a computer including at least one processor, The computer moving a first player object within a game stage based on the first operation data; moving a second player object within the game stage based on second operation data; when a position of a revival assist object including at least a second player object in a first state satisfies a first condition and the first player object satisfies a second condition, transitioning the state of the first player object from the first state to a second state without subtracting a remaining number associated with the first player object; when the first player object in the second state and the revival assist object have a predetermined positional relationship, transitioning the state of the first player object from the second state to the first state without subtracting the remaining number; when the position of the revival assist object does not satisfy the first condition and the first player object satisfies the second condition, subtracting the remaining number and placing the first player object in the first state at a predetermined position within the game stage; determining that the game stage has been successfully cleared when a predetermined clearing condition is satisfied in the game stage; determining that the player has failed to clear the game stage when the remaining number reaches a predetermined value; Game system.

9. On the computer, moving a first player object within a game stage based on the first operation data; moving a second player object within the game stage based on second operation data; when a position of a revival assist object including at least a second player object in a first state satisfies a first condition and the first player object satisfies a second condition, transitioning the state of the first player object from the first state to a second state without subtracting a remaining number associated with the first player object; when the first player object in the second state and the revival assist object have a predetermined positional relationship, transitioning the state of the first player object from the second state to the first state without subtracting the remaining number; when the position of the resurrection assist object does not satisfy the first condition and the first player object satisfies the second condition, subtracting the remaining number and placing the first player object in the first state at a predetermined position within the game stage; determining that the game stage has been successfully cleared when a predetermined clearing condition is satisfied in the game stage; determining that the player has failed to clear the game stage when the remaining number reaches a predetermined value; Game processing method.

Images