Game program, game system, and game processing method

Abstract

To provide a game program, a game system, and a game processing method which enable a character to appear at an appropriate position.SOLUTION: A predetermined position within a game space is set as a scheduled appearance position for a predetermined character. If the scheduled appearance position is a position where the predetermined character can appear, the character is allowed to appear at the position, but if the position is a position where the predetermined character cannot appear, the following process is repeated: an object under search is placed at the position, the object under search is allowed to move by a predetermined distance within the game space until it reaches a position where the predetermined character can appear, and determination is made as to whether the predetermined character can appear at the position to which the object under search has moved. Then, if the object under search has reached the position where the predetermined character can appear, the predetermined character is allowed to appear at the position.SELECTED DRAWING: Figure 46

Description

[Technical Field]

[0001] The present disclosure relates to a game process for making a predetermined character appear at a predetermined position in a game space. [Background technology]

[0002] Conventionally, games have been known in which a player character is respawned at a position based on an operation by the player (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2022-47434 Summary of the Invention [Problem to be solved by the invention]

[0004] However, no special consideration was given to the situation where the respawn point was in a place where a character could not be placed. [Means for solving the problem]

[0005] In view of the above, the following configuration example can be given.

[0006] (Configuration 1) In the configuration 1, a computer of the game device includes: A predetermined position in the game space is set as a predetermined appearance position of a predetermined character, and if the predetermined appearance position is a position where the predetermined character can appear, the character is made to appear at the predetermined appearance position. On the other hand, if the predetermined appearance position is a position where the predetermined character cannot appear, an object being searched for is placed at the predetermined appearance position, and the object being searched for is moved a predetermined distance in the game space until it reaches a position where the predetermined character can appear, and a process of determining whether the predetermined character can appear at the position after the movement is repeated. Then, when the object being searched for reaches a position where the predetermined character can appear, the predetermined character is made to appear at the position of the object being searched.

[0007] According to the above configuration, it is possible to search for an appropriate appearance position for a predetermined character through simple processing. Furthermore, by moving the object being searched, the search process is visually presented, which gives the player a sense of satisfaction as to why that position was decided as the appearance position.

[0008] (Configuration 2) In a second aspect of the present invention, in the first aspect, the computer may move the object under search along a path that moves the object under search away from the position where the object under search is placed.

[0009] According to the above configuration, it is possible to gradually expand the search range, and it is also possible to preferentially determine the appearance position as close as possible to the position where the object being searched is placed.

[0010] (Configuration 3) In configuration 3, in configuration 1 or 2 above, when the computer repeats the process of determining whether a specified character can appear, it may move the object being searched while changing the direction of movement so that the direction of movement is different from the direction of movement when the determination process was performed the previous time.

[0011] According to the above configuration, the object being searched for is moved while changing the direction of movement, thereby improving search efficiency.

[0012] (Configuration 4) In a fourth aspect of the present invention, in the third aspect, the computer may move the object being searched along a spiral path.

[0013] According to the above configuration, possible appearance positions can be searched for more efficiently.

[0014] (Configuration 5) In configuration 5, in configuration 1, when the computer repeats the process of determining whether a specified character can appear, it may determine whether the specified character can appear based on whether space corresponding to the size of the specified character is secured at the position after the object being searched is moved.

[0015] According to the above configuration, it is possible to determine an appropriate appearance position for a game in which characters of various sizes appear.

[0016] (Configuration 6) In configuration 6, in configuration 1, the predetermined character is a player character whose movement is controlled based on the player's operation and for which collision detection with objects in the game space can be performed, and the player character may be made to appear at a planned appearance position in a state in which the movement of the player character can be controlled.

[0017] According to the above configuration, it is possible to prevent the player character from appearing in a position where it cannot be moved after appearing, and to make the player character appear in an appropriate position.

[0018] (Configuration 7) In configuration 7, in configuration 1, the object being searched for may be an object for which collision detection with other objects in the game space is not performed.

[0019] According to the above configuration, the processing load can be reduced and the search efficiency can be improved. [Effects of the Invention]

[0020] According to the present disclosure, when a predetermined character is made to appear in a game space, it can be made to appear in an appropriate position. [Brief explanation of the drawings]

[0021] [Figure 1] FIG. 1 is a schematic diagram showing an overall view of a game system according to the present embodiment. [Figure 2] Block diagram showing the hardware configuration of game server 1 [Figure 3] A block diagram showing the hardware configuration of the game device 3. [Figure 4] An example of a game screen [Figure 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 transitions and explanatory diagrams [Figure 13] A diagram for explaining the restoration position [Figure 14] A diagram for explaining the restoration position [Figure 15] A diagram for explaining the restoration position [Figure 16] A diagram for explaining the restoration position [Figure 17] A diagram for explaining the restoration position [Figure 18] A diagram for explaining the restoration position [Figure 19] A diagram for explaining the restoration position [Figure 20]A diagram for explaining the restoration position [Figure 21] A diagram for explaining the 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 [Figure 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 [Figure 30] An example of the data configuration of panel management data 306 [Figure 31] A memory map showing an example of various data stored in the storage unit 32 of the game device 3. [Figure 32] An example of the data structure of remote character data 361 [Figure 33] An example of the data configuration of the player-actor management data 363 [Figure 34] An example of the data structure of Panel Data 364 [Figure 35] A flowchart showing details of the game processing executed by the game device 3. [Figure 36] A flowchart showing details of the game processing executed by the game device 3. [Figure 37] Flowchart showing details of stage preparation processing [Figure 38] Flowchart showing details of the entry / exit check process [Figure 39] Flowchart showing details of the entry / exit check process [Figure 40] Flowchart showing details of remote panel check processing [Figure 41]Flowchart showing details of normal state processing [Figure 42] Flowchart showing details of normal state processing [Figure 43] Flowchart showing details of own panel arrangement processing [Figure 44] Flowchart showing details of special state processing [Figure 45] Flowchart showing details of special state processing [Figure 46] Flowchart showing details of search processing [Figure 47] Flowchart detailing the Replay Ghost process [Figure 48] Flowchart showing details of stage clear processing [Figure 49] Flowchart showing details of restart processing [Figure 50] A flowchart showing details of the game server process executed by the game server 1. DETAILED DESCRIPTION OF THE INVENTION

[0022] 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 terminals 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 this configuration, and the following description will take game processing as an example of the information processing. Specifically, the example illustrates game processing in which a game program is installed on the information processing terminal 3 and is executed while communicating with the game server 1 as necessary.

[0023] [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 by the processor 11. The communication unit 13 is connected to a network via wired or wireless communication, and transmits and receives predetermined data to and from the information processing terminal 3 or other servers. Note that, although the present embodiment illustrates an example in which there is one game server 1, the game server 1 may also be configured as a group of servers that perform distributed processing.

[0024] [Game device hardware configuration] Next, a description will be given of the information processing terminal 3. 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.

[0025] FIG. 3 is a block diagram showing an example of the hardware configuration of a 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 types of information processing executed in the game device 3, and may be composed of, for example, only a CPU (Central Processing Unit), or may be composed of an SoC (System-on-a-chip) that includes multiple functions such as a CPU function and a GPU (Graphics Processing Unit) function. The processor 31 executes various types of information processing by executing an information processing program (e.g., a game program) stored in a storage unit 32. The storage unit 32 may be, for example, 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 inserted into a slot (not shown).

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

[0027] The game device 3 also includes a controller communication unit 34 for the game device 3 to communicate with the controller 4 via wired or wireless communication.

[0028] Furthermore, the game device 3 is connected to a display unit 5 (e.g., a television or the like) via an image and 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 and audio output unit 35.

[0029] Next, the controller 4 will be described. The controller 4 includes at least one analog stick 42, which is an example of a direction input device. The analog stick 42 can be used as a direction input unit that can input directions. By tilting the analog stick 42, the player 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 that includes various operation buttons. For example, the controller 4 may include a plurality of operation buttons on the main surface of the housing.

[0030] 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 three predetermined axial directions. The angular velocity sensor detects angular velocity around three predetermined axes.

[0031] 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.

[0032] [Outline 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 process will be described in which a player controls a player character object (hereinafter referred to as a "player character") that exists in a virtual space. More specifically, in this embodiment, a side-scrolling action game (hereinafter referred to as this game) will be described. In this game, a two-dimensional virtual space called a "stage" is prepared, which serves as the main setting for play. A start point and a goal point are set in this stage. Various enemy characters, obstacles, jump platforms, pitfalls, and other 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 by defeating or avoiding these enemy characters. Note that, depending on the game, the stage may also be called a "course" or a "round." Furthermore, this embodiment illustrates a game in which the game screen is displayed on a 2D screen. However, in other embodiments, the virtual space may be a three-dimensional virtual space, and the game may be displayed on a 3D screen from a first-person perspective, a third-person perspective, or the like.

[0033] FIG. 4 shows an example of a game screen (hereinafter referred to as a stage screen) during play of the above stage. The example in FIG. 4 is a screen near the starting point, i.e., an example of a screen immediately after play of the stage has begun. 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 edge of the stage, and the goal point is set near the right edge of the stage. Therefore, the stage is configured so that the overall game progresses by moving the player character 201 toward the right of the screen. In this stage screen, the player controls the player character 201 to move toward the goal point. As the player character moves, different parts of the stage are displayed on the stage screen. When the player character reaches the goal point, the stage is cleared.

[0034] 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 required in the play from that point until the goal, 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 any predetermined position on the way between the start point and the goal point may be set as the waypoint.

[0035] [Online play elements] The basic game progression of this game is as described above, and the game can basically be played as if it were a single player. Furthermore, this game also allows for multiplayer. For example, this game also has an online play element, which allows players to connect to the server or other game devices 3 via the Internet and play with other players.

[0036] The online play elements of this game will be explained below. First, a brief description will be given of the overall network configuration. The basic network configuration is as shown in Figure 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 generated and managed as appropriate. 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 this virtual space. Furthermore, multiple stage rooms can exist in parallel for the same stage.

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

[0038] 5 is an example of a stage screen output from the game device 3 of a player when the player enters a stage room where another player is already in the room. 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 located a little further towards the goal point than the starting point. In addition, in FIG. 5, the other player character 203 is displayed semi-transparently (indicated by a dotted line in the drawing).

[0039] 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 they will use. Therefore, the other player character 203 displayed may be a character selected by another player, and may be a character different from the player character 201.

[0040] In the following description, other players who have entered the same stage room will be referred to as "remote players," and the other player characters 203 operated by the remote players will be referred to as "remote characters." Furthermore, as will be described in detail later, "replay ghosts" may also appear on the stage screen as player characters related to remote players. Furthermore, hereinafter, player characters, remote characters, and replay ghosts may be collectively referred to as "player actors." In this game, up to four people can enter one room, meaning that up to four player actors can exist in one room at the same time.

[0041] [About remote characters] Next, the remote characters will be described in more detail. In this game, remote characters displayed in a stage room move in response to the operations of other players, but do not directly interfere with or affect game play being executed on the game devices 3 of the players. Specifically, between game devices 3 connected to a certain stage room, position information of each player's character and position information of predetermined objects generated by each player's character are basically shared. An example of a predetermined object generated by a player character is a "panel," which will be described later. On the other hand, the status and position information of other objects, such as enemy characters, are not shared. For example, in each game device 3, collision detection processing with stage objects, etc., during stage play is performed only for the player character 201 of that game device; in principle, collision detection processing is not performed for remote characters. Therefore, even if the player character 201 overlaps the position of a remote character, it will result in the character passing through without colliding (however, collision detection is performed exceptionally for special characters, which will be described later). Furthermore, even if a remote character overlaps with an enemy character, collision detection between the remote character and the enemy character is not performed, resulting in the enemy character passing through the remote character. For example, even if the player character 201 defeats enemy character A, the state of this enemy character A is not reflected on the other game devices 3. On the other game devices 3, if another player of the other game device has not defeated enemy character A, the enemy character A is controlled to still exist. In other words, the progress of the stage play itself is managed individually on each game device, and if a remote character is present, it is only displayed. Furthermore, to make it easy to understand that the remote character does not interfere, the remote character is basically displayed semi-transparently. Therefore, each player can play the stage with the same feeling as in single play, without being affected by the actions of other players or interfering with their actions.In other words, you can get a gameplay and gaming experience where you can play the game alone while being aware of the presence of remote characters, in other words, other players.

[0042] As mentioned above, each player can progress through the game independently without being influenced by other players. Therefore, stage play does not require four players to be present before it can begin; it can begin even if only one player is in the stage room. After that, up to four other players can join in mid-game. For example, if player B enters the room when player A has progressed about one-third of the way through the stage, player B's character will begin moving from the starting point. In other words, from player B's perspective, player A's character will begin stage play at a position some distance ahead. Furthermore, player A's play is not interrupted by player B's entry, and he or she can continue playing.

[0043] [About Replay Ghost] Next, the replay ghost will be described. A replay ghost is a ghost that plays back replay data of another player. In this embodiment, the play from the waypoint to the goal point is stored as replay data on the game server 1. Then, when a certain level of progress has been reached in the game stage, a replay ghost appears. More specifically, when a single player enters the stage room and progresses to the waypoint, that is, when the player progresses to the waypoint without being matched with another player, replay data is downloaded from the game server 1 and played back. This allows the character of the other player based on the replay data to be displayed as a ghost. This is the replay ghost. Furthermore, since the replay ghost plays back the replay, it ultimately behaves in the same way as the remote character. This allows a situation to be created in which, if no other player has entered the room until the waypoint, the player plays back the ghost of the other 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.

[0044] Here, the replay ghosts are basically indistinguishable from the remote characters in appearance. For example, FIG. 6 shows an example of a screen displaying replay ghosts. In FIG. 6, three replay ghosts are displayed, which are translucent like the remote characters. Their appearances are also identical to those of the remote characters. Because the remote characters are controlled by live humans, they can be manipulated to display emotes, such as facial images that express emotions. Therefore, although each game device 3 individually manages play, players can communicate with each other to some extent through such manipulations. On the other hand, replay ghosts cannot communicate in this way. Therefore, it is possible to distinguish between remote characters and replay ghosts. For example, when a player approaches a remote character, a sign image, such as the player's name, may be displayed to indicate that the character is a remote character. On the other hand, it is possible for a replay ghost to not display such a sign image even when the player approaches. This allows the player to distinguish between a remote character and a replay ghost based on the presence or absence of the sign image.

[0045] In this embodiment, more precisely, a replay ghost appears when the player character 201 comes into contact with the waypoint object. This is because it is easy for the player to understand that the replay ghost appears when the player passes through a waypoint. In addition, in this example, the progress of play is explained using the case where the waypoint is passed 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 elapsed time from the start of stage play or the degree of achievement of events within the stage.

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

[0047] [About recording replays] First, the recording of replay data will be described. In this embodiment, the recording of replay data begins 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 stops 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.

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

[0049] Furthermore, if a "mistake event" occurs between passing the waypoint and reaching the goal, recording of replay data is temporarily stopped at that point. Such a mistake event will be described later; for example, it may occur when the player character 201 is defeated by an enemy character. Furthermore, if a mistake event occurs and certain conditions are met, play is temporarily interrupted, the player character 201's remaining number of lives (i.e., remaining lives) is reduced, and the game restarts from the waypoint. In this case, the replay data before the restart is basically discarded, and recording of replay data begins anew from the point of restart. However, in this embodiment, there is a certain probability that the replay data before the restart is not discarded but is retained, and recording of replay data from the point of restart is not performed. As described above, replay data is transmitted to the server upon reaching the goal. However, if a restart occurs during play due to the control described above, the following two types of replay data may be transmitted. The first type is replay data representing the progress up to the goal, i.e., replay data representing the progress of clearing the stage. The second type is replay data in which a mistake event occurs during the game, i.e., replay data in which the stage was not cleared. This allows for a greater variety in the content of the replay data.

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

[0051] [About downloading and playing replays] Next, the downloading and playback of replay data will be described. Replay data is transmitted to the game server 1 as described above, but in this embodiment, the replay data is linked to each waypoint object (stage) and managed in the game server 1. More specifically, the game server 1 stores the most recent 30 pieces of replay data for each stage.

[0052] Then, when the player character 201 passes the waypoint, the game device 3 transmits a request for replay data to the game server 1. The game server 1 transmits 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 (in this example, the stage room has a capacity of four people) to use 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 selection. In other words, the player's own replay data is prevented from being selected.

[0053] The selected replay data is then played back as a replay ghost. If multiple replay ghosts are used, the playback start timing should 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 could appear five seconds after the first replay ghost appears, and the third ghost could appear another five seconds after the second one appears.

[0054] Additionally, 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 are present.

[0055] Furthermore, if a mistake event occurs and the game is restarted from a midpoint, the replay data must be downloaded again. Therefore, when restarting, different replay ghosts may appear before and after the restart. However, if a predetermined amount of 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 amount of time that has passed, or, conversely, the initially downloaded data may be reused regardless of the amount of time that has passed.

[0056] [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, each game device manages the game progress individually, and the only information shared is basically the position information of each player's character. Furthermore, replay ghosts are not synchronized with other game devices 3 but are managed locally on each game device 3. Now, consider a situation in which another player enters a room when replay ghosts have already appeared. In this case, adjustments are made so that the number of player actors on the stage is four or less. For example, consider a situation in which player A is playing with three replay ghosts and player B enters the room. In this case, the following processing is performed on player A's game device 3. First, the replay ghost located farthest from the current position of player character 201 is erased. This frees up one slot for a player actor. Next, a remote character related to player B is generated and made to appear on 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 joining the room, resulting in a total of three player actors.

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

[0058] [About the cooperative 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 makes a mistake, which allows players to influence each other.

[0059] A specific example of revival assistance will be described below. First, assume that a mistake event occurs with respect to the player character 201. In this embodiment, the mistake event is an in-game event that reduces the player character's remaining number of lives (loses the remaining lives). Specifically, as shown in FIG. 7, for example, this is a case where the player character 201 comes into contact with an enemy character 202. In the case of offline single-player mode, this is an in-game event in which play with the currently used player character 201 ends and the player character 201's remaining number of lives is reduced by one (hereinafter, this will be referred to as "lost"). After being lost, this is an in-game event that leads to restarting from a predetermined point or to a game over. Other examples of mistake events include, for example, when HP or lives become 0 and the player is lost, or when the player falls off the stage by falling into a trap, etc. Note that if the player receives damage but still has HP or lives remaining, this does not yet result in a loss, and therefore is not considered a mistake event (it is treated as simply receiving damage).

[0060] In this game, in offline single-player mode, the occurrence of the above-mentioned error event directly leads to the player being lost. However, when playing while connected online, even if a mistake event occurs, the player is not immediately lost if a certain condition is met. In this embodiment, the certain condition is the presence of a "revival support object" (described later) within a certain range of the player character 201. If the certain condition is met, the player character 201 transforms into a character object with a different appearance, as shown in FIG. 8, for a certain period of time. Hereinafter, this transformed character object will be referred to as a "special character." Furthermore, the state of the player character 201 that has transformed into a special character will be referred to as a "special state," and the state of the player character 201 that has not undergone this transformation will be referred to as a "normal state." Note that during the special state, the remote character 203 is displayed opaque rather than translucent; this point will be discussed later.

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

[0062] In other embodiments, the special characters may be subjected to collision detection with objects other than the resurrection assist object. Furthermore, movement control may be performed under the influence of gravity in the virtual space.

[0063] Assume that 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, as shown in FIG. 10, the position of the remote character 203 and the position of the special character overlap before a predetermined time has elapsed. In other words, the revival assist object and the special character come into contact. Then, as shown in FIG. 11, the player character 201 can be returned to its normal state without losing the player character 201. In other words, it is possible to "revive" the player character 201 in which a mistake event has occurred without losing the player character 201. In the following explanation, the predetermined time is referred to as the "revival possible time." Note that the special character and the revival assist object are not limited to coming into contact with each other, but may also be revived by being in close proximity or adjacent to each other.

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

[0065] In this embodiment, while the player character has changed 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.

[0066] The predetermined range is, for example, a range that is equal to or shorter than the upper limit of the distance that the player character 201 in the normal state can reach or approach the position of the revival assist object if the player character 201 moves the revival time. In other words, it is a range that allows the player character 201 to be revived from the special state to the normal state within the revival time, as viewed from the position where the mistake event occurred.

[0067] Therefore, for example, if the player character 201 and the remote characters move together to a certain extent, recovery from a mistake event becomes easier while still allowing for a single-player feel. In other words, online benefits are available that are not available in offline single-player games. Also, while special states occur in single-player mode, which would be treated as "miss events" or "lost" and cause play to be interrupted, online play does not cause such interruptions and does not impede the player's play. By incorporating such cooperative play elements, there is room for cooperation with other players in certain situations. This creates a situation in which the game can be progressed primarily as a single-player game, but if multiple players are matched and enter the stage room, cooperation with other players becomes easier.

[0068] Furthermore, by providing the above-described predetermined range, it is possible to prevent a situation in which the player character 201, when entering a special state, has to travel a long distance to seek help from a remote character or the like. For example, if the player had progressed a certain distance through the stage and had to return to the starting point where the remote character is located, the tempo of the game would be slowed down. Conversely, if the player were allowed to skip over various stage gimmicks and move to the position of a remote character who has progressed further than the player, the game would lose its appeal. To prevent such a situation, the special state is entered only when a resurrection assist object is present within the predetermined range, as described above.

[0069] FIG. 12 shows a diagram summarizing the relationship between the normal state, special state, and lost state transitions described above. In FIG. 12, when a miss event occurs in the normal state, it is first determined whether 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 returns to the normal state, and 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.

[0070] In this embodiment, the revival time may vary depending on the number of times the character changes to a special state. Specifically, the more times the character changes to a special state during one play (for example, from the start of play until one player character 201 is lost), the shorter the revival time becomes. For example, assume that the revival time is counted to 10. When the character changes to a special state for the first time, the 10-count interval is counted at 2-second intervals (revival time = 20 seconds). When the character subsequently revives and changes to a special state again, the 10-count interval is counted at 1.5-second intervals (revival time = 15 seconds). When the character changes to a special state for the third time, the 10-count interval is counted at 1-second intervals (revival time = 10 seconds), and when the character changes to a special state for the fourth time, the 10-count interval is counted at 0.5-second intervals (revival time = 5 seconds). Once the counting intervals become shorter to a certain extent, they are not shortened any further. For example, a 0.5-second interval may be set as the lower limit. This makes it gradually more difficult for the player to recover if they repeatedly make a mistake, which can add a certain amount of tension to the gameplay.

[0071] Here, we will provide additional information regarding the resurrection position when resurrected by the resurrection function. Here, we will consider the processing on the game device 3 that has entered the special state as the basis. In other words, we will consider the game screen of the device controlling the special character as the basis. First, we will consider a case where both the special character and the resurrection target object are outside the terrain. In this case, if their positions overlap, the player character 201 will be resurrected at the overlapping position. Next, we will consider a case where 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 detection between the special character and terrain objects, etc., this situation can occur. In this case, the player character 201 will be resurrected at the location of the remote character, as shown in FIG. 14.

[0072] Next, assume that the special character is outside the terrain and the resurrection target object (remote character 203) is inside the terrain, as shown in FIG. 15 . This can occur in the following cases. As described above, in this game, game progress management itself is performed on each player's game device. For example, if there is a destructible terrain object, a situation may occur in which the terrain object has not yet been destroyed in player A's gameplay but has been destroyed in player B's gameplay. 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 player B, corresponding to the situation in FIG. 15 , is as shown in FIG. 16 . On player B's game screen, the terrain object has already been destroyed, and player B's player character 201 is located in its remains. Furthermore, as described above, the remote characters only share position information, and collision detection with the terrain is not performed on player A's game device 3. Therefore, the screen viewed by player A may appear as shown in FIG. 15 . Now, let us consider a case where player B jumps the remote character towards the special character in this state. As a result, the remote character and the special character come into contact with each other, as shown in Figure 17. In this case, player character 201 is revived on the spot, as shown in Figure 18.

[0073] Next, assume that on the screen of the special character's player, both the special character and the resurrection target object are located within the terrain, as shown in FIG. 19 . Furthermore, assume that their positions overlap within the terrain. In this case, since both are within the terrain, neither position can be used as a resurrection position. Therefore, a location that can be used as the resurrection position is searched for. In this embodiment, the location that can be used as a resurrection position is a "location outside the terrain (the space outside the terrain object)" and a "location where space is secured for the player character restored to its normal state." For example, assume a location where a small player character can be placed when the player character restored to its normal state, but where there is insufficient space for a large player character, such as a gap between obstacles. In this case, the location can be determined as a resurrection position for a small player character, but will not be determined as a resurrection position for a large player character.

[0074] A specific example of the operation related to the search for the resurrection position will be described. In this embodiment, first, the special character is changed to a search object (for example, a ball of light). Like the special character, the search object is not subjected to collision determination with the terrain object. Next, as shown in FIG. 20, the search object is moved outward from its current position along a spiral trajectory (path). During this movement, it is determined whether the position of the search object satisfies the resurrection position conditions described above. Then, the first position found to satisfy the resurrection position conditions is determined as the resurrection position, and the player character 201 is resurrected at that position. As a result, for example, the player character 201 is resurrected at a position outside the terrain as shown in FIG. 21.

[0075] If the above-mentioned resurrection position includes an object such as an enemy character that may cause a mis-event if the player character collides with the enemy character, the resurrection position may be further shifted to a position where the player character will not collide with the enemy character. In other words, the resurrection position may ultimately be determined to be a position free of obstacles such as terrain objects and enemy characters.

[0076] [About the resurrection aid object] Next, the revival assist object will be described. In this embodiment, the revival 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.

[0077] [Resurrection Support Object: Remote Character] First, a detailed description of the remote character has been provided above, so a further explanation will be omitted, but a supplementary explanation will be provided regarding its display mode. As described above, the remote character is generally displayed in a semi-transparent display mode. However, while the player character 201 has transformed into a special character, it is displayed in an opaque mode, rather than a semi-transparent mode. Furthermore, while the remote character is displayed in an opaque mode, a collision determination is performed between the remote character and the special character. In other words, while in a special state, the remote character appears to be materialized. Furthermore, at this time, the remote character is in a state in which it can directly affect the player character 201 by reviving the player character 201, as described above. Furthermore, as described above, in this embodiment, while the player character 201 has transformed 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 mode within a monochrome image, making the remote character more noticeable. This makes the player realize that if they come into contact with the remote character, something will happen or they will be revived, and visually shows the player in an easy-to-understand way where they should go.

[0078] When the above-mentioned mistake event occurs and the player character 201 changes into a special character, an effect 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 may be shown to change into the special character upon receiving the ball of light. 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, the player can be made to recognize the causal relationship between the revival assist object and the change into a special character.

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

[0080] [About the panel] Next, an overview of the panels will be described. The panels are objects that can be placed by the player character 201 and that the player character 201 can touch. Furthermore, the panels are objects that remain in the stage room even after the player leaves the room. For example, when a player performs a panel placement operation on a game screen such as that shown in FIG. 23, a panel such as that shown in FIG. 24 can be placed. The panel placed by the player is also displayed on the game screen of other players who subsequently enter the stage room. Conversely, panels placed by other players (remote characters) are displayed on the player's game screen and can be touched. Furthermore, the panels function as the resurrection assist object. Therefore, if a special character touches a panel within the resurrection time, the player's character 201 can be revived. However, in this embodiment, special characters cannot touch panels that the player placed. In other words, the only panels that special characters can touch are remote panels, which are panels placed by remote characters, and server panels, which will be described later. This is because, while panels function as the above-mentioned revival assist objects, if a panel placed by the player is treated as a revival assist object, the game difficulty may not be properly balanced, for example, making the game too easy. For this reason, in this embodiment, the panel placed by the player cannot be touched (cannot be used as a revival assist object).

[0081] 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.

[0082] Furthermore, the panel-like design described above is merely an example, and the appearance does not have to be like that of a panel.

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

[0084] [About panel synchronization with other game consoles] Furthermore, as described above, the panel placed by one player 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 "a panel has been placed" and the placement position (coordinates) to the other game devices. Upon receiving this information, the other game devices 3 perform processing to place the panel in their local game processing. However, such synchronization is performed only when the panel is placed; subsequent deletion of the panel, etc., is managed locally by each game device 3. Therefore, for example, when a new panel is placed, the placement of that panel is synchronized, but depending on the subsequent development of game play on each game device, a situation may arise in which the panel remains on one game device but has been deleted on another game device.

[0085] [Resurrection Aid 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 while 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 and touches the panel within the above-mentioned revival time, the player can be revived in the same way as a remote character. In other words, when a player places a panel, it becomes a remote panel as seen by other players, and the player can indirectly help other players even if the player is not on the same screen. For example, by placing a panel in a location where the player thinks the above-mentioned mistake events will occur frequently, the player can expect to indirectly help other players.

[0086] [Resurrection Auxiliary Object: Server Panel] Next, the server panel will be described. In the game according to this embodiment, a large number of various stages are prepared, from which the player can select the stage he or she wants to play. However, while a large number of stages are prepared, there is a possibility that the number of players playing some stages 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 referred to as panel information) is stored in the game server 1. Then, by using the panel information when a new stage room is created, a state in which panels are placed on the stage is created. The panels placed based on the panel information stored in the game server 1 are called server panels. The server panels will be described in detail below.

[0087] [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 that player is transmitted to the game server 1. Leaving a stage room occurs, for example, when 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, if the panel placed by that player has already been deleted when the player leaves the stage room, the panel information is not transmitted. Furthermore, if panel information placed by the player himself / herself on that stage is already stored on the game server 1, the existing panel information is deleted and a new panel is registered. This is to prevent a situation in which, for example, a stage that is not often played becomes filled with panels related to the same player if a single player repeatedly "enters the stage, places a panel, and leaves the stage."

[0088] [About receiving and placing server panels] Next, the use of the panel information transmitted to the game server 1 as described above will be explained. First, if there are zero panels placed on the stage when a player enters a stage room, panel information is obtained from the game server 1. The situation in which there are zero panels upon entry can occur, for example, in the following cases: First, when a new stage room is created. Second, when an existing stage room is entered, there are no panels 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.

[0089] Furthermore, in the present embodiment, panel information is acquired from the game server 1, and the most recent 30 pieces of panel information associated with that stage are acquired from the game server 1. As described above, if the same player transmits panel information multiple times for the same stage, only the most recent panel information is stored in the game server 1. Therefore, the acquired group of panel information does not contain multiple pieces of panel information related to the same player. From this, up to four pieces of panel information are selected. In this embodiment, the stage room has a maximum capacity of four people, so the maximum number of pieces of panel information is set to four to match this number of people. However, it goes without saying that the number of pieces selected may be more or less than four. The selection method may be, for example, random selection.

[0090] Next, server panels are generated based on the selected panel information. The server panels are then placed at the positions indicated by the panel information. It is possible that a panel previously placed by the player himself / herself may exist as a server panel when the player enters the stage. 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 removed.

[0091] [About enabling the server panel] Next, we will explain how to enable a server panel. Although a server panel can be placed as described above, the server panel is initially disabled. In other words, when placed, it does not function as the resurrection assist object described above. FIG. 25 shows an example of a disabled server panel. As shown in FIG. 25, a disabled server panel is displayed in a blacked-out display mode. Note that the display mode indicating a disabled state is not limited to a blacked-out display mode, and any display mode may be used. When the player character 201 comes into contact with the disabled server panel, the server panel can be enabled, as shown in FIG. 26. FIG. 26 shows that the blacked-out display mode is canceled, and the server panel is displayed in the normal display mode. In this way, only enabled server panels function as the resurrection assist object described above. Therefore, if a miss event occurs near a disabled server panel, the player character is lost without changing into the special character described above.

[0092] Furthermore, once a server panel is enabled, it remains enabled even if the player character 201 moves away from the 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.

[0093] The reason why the server panels are initially disabled and then enabled upon contact with the player character 201 is as follows. First, when a character becomes a special character, collision detection with enemy characters or terrain is not performed. Therefore, if the server panels were enabled from the beginning, depending on the placement of the server panels, the player might intentionally transform into a special character and move to a location (where the server panel is located) that would not have been reached under normal circumstances. In other words, it is conceivable that a shortcut could be taken to a location that the player would not have progressed to. To prevent this situation from occurring, the server panels are disabled by default. Note that this applies to stage rooms where no other players are present. For example, with regard to remote panels placed in real time by a remote character, such shortcuts are allowed to allow the player to experience the benefits of online play and cooperative play elements. Therefore, the remote panels are enabled from the moment they are placed.

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

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

[0096] [Data used on Game Server 1] First, we will explain the data used by 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. The storage unit 12 of the game server 1 stores 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.

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

[0098] The player database 302 is a database related to each player playing the game according to this embodiment. The database includes multiple pieces of player data 303. Each piece of player data 303 includes, for example, a player ID 307 for identifying each player, a player name 308 of each player, and the like.

[0099] 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 single stage may include multiple pieces of stage room information 312. 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, etc. 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.

[0100] Returning to FIG. 27 , the replay management data 305 stores the replay data transmitted from the game device 3, 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 on 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. The replay content 325 is data indicating the content of the replay. For example, the replay content 325 is data in which information indicating the position information and status of the character involved in the replay is arranged in chronological order and stored. The replay content 325 may also be, for example, key data. In other words, the replay content 325 may be any data content as long as it is data that allows the player's operation history to be understood.

[0101] Returning to FIG. 27, the panel management data 306 stores 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, placement player information 334, and placement 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 placement player information 334 is information about the player who placed the panel related to the panel information 332. The placement position 335 is information indicating the placement position of the panel related to the panel information 332.

[0102] Although not shown in the drawings, various data necessary for performing player matching processing and the like may also be stored in the storage unit 12 as appropriate.

[0103] [Data used in game device 3] Next, a description will be given of the 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 selected flag 366, and a placement completion flag 367.

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

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

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

[0107] The player character data 354 is data related to the player character 201 controlled by the player. The player character data 354 includes data such as player position information 355, special state flag 356, number of times the special state has occurred 357, intermediate pass flag 358, replay recording data 359, lost occurrence flag 360, and search flag 368. The player position information 355 is data indicating the position of the player character 201 in the stage being played. The number of times the special state has occurred 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 on and a normal state when off. The number of times the special state has occurred 357 is counted up by one each time the player character 201 changes into a special character. The number of times the special state has occurred 357 is also reset when the player character 201 is lost. The intermediate pass flag 358 is a flag indicating whether the player character 201 has come into contact with the intermediate point object. It is set to ON when the player touches a waypoint object. The replay recording data 359 is data for recording replay data for the player character 201. The lost occurrence flag 360 is a flag for indicating that a situation resulting in the player character 201 described above has occurred. If it is ON, it indicates that a situation resulting in the player character 201 has occurred. The search flag 368 is a flag for indicating whether or not the player is currently searching for a position where the player character can be restored in the state of a search object, as described in FIG. 20 above.

[0108] Next, remote character data 361 is data on a remote character associated with a remote player who is in the same stage room. FIG. 32 shows an example of the data configuration of remote character data 361. In this example, a maximum of four people can enter the stage room, and therefore, remote character data 361 stores data on a maximum of three remote characters. Each piece of data is generated when a remote player enters the room and appropriately deleted when the remote player leaves the room. Each piece of 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 identifying the remote player 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 the character used by each remote player as a player character. The remote position information 374 is information indicating the position of the remote character within the stage.

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

[0110] The player actor management data 363 is data for managing the allocation relationship between player actor slots, remote characters, and replay ghosts. FIG. 33 shows an example of the data configuration of the player actor management data 363. The actor slot number 381 is the slot number of the player actor. In this example, a case will be described in which four player actor slots are prepared. The allocation target 382 is information for identifying the player actor assigned to that slot. First, one slot is assigned to the player character 201. Therefore, the remaining three slots store information for identifying either a remote character or a replay ghost. Furthermore, when a remote character or a replay ghost is not assigned, a null value is set.

[0111] Returning to FIG. 31 , panel data 364 is data for managing the above-mentioned panels. FIG. 34 shows an example of the data configuration of panel data 364. Panel data 364 includes own panel data 391, remote panel data 394, and server panel data 400. In this example, three pieces of remote panel data 394 and three pieces of server panel data 400 are prepared. Own panel data 391 is information about a panel placed by the player character 201 (hereinafter, "own panel"). Own panel data 391 includes own panel placement position 392 and own panel placement date / time 393. Own panel placement position 392 indicates the placement position of the own panel, and own panel placement date / time 393 indicates the date and time when the own panel was placed. In addition, if panels are placed multiple times, the latest placement content is saved in own panel data 391.

[0112] The remote panel data 394 is information relating to 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 relating to another player who placed the remote panel.

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

[0114] 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 placed 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 placed, the contents of each data are deleted and generated as appropriate so that the maximum number of panels is four.

[0115] 31, the operation data 365 is data obtained from the controller 4 operated by the player. That is, it is data indicating the operation content performed by the player.

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

[0117] 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, and replay data downloaded from the server, may also be generated as needed and stored in the memory unit 32.

[0118] 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.

[0119] [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 processor 31 of 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 steps. Therefore, the processing order of each step may be changed as long as the same results are obtained. Furthermore, the values ​​of variables and thresholds used in the determination steps are merely examples, and other values ​​may be used as necessary.

[0120] 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 processing to enter a stage room. Specifically, first, processor 31 requests matching processing from game server 1. Then, processor 31 executes processing to enter a stage room determined based on the matching result. At this time, if processor 31 enters an existing room, it also transmits information about the character that processor 31 uses as player character 201 to game device 3 associated with a player who has already entered the room.

[0121] 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, processor 31 receives information on the remote character and remote panel from other game device 3. Then, various characters are placed in the stage.

[0122] Next, in step S23, processor 31 determines whether 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, which will be described later. On the other hand, if the result 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 about a panel previously placed by the player himself is included, this information is stored as own panel data 391. Then, processor 31 places the server panels based on panel data 364.

[0123] Next, in step S26, if there are other players 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 approximately the same time and both perform processes related to the server panel, the information about one of the players' server panel is given priority.

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

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

[0126] Next, in step S33, processor 31 determines whether the number of players in the room has reached four. If the result of this determination is that the number has not reached four (NO in step S33), the process proceeds to step S36, which will be described later. 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 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 farthest from player character 201. That is, the data related to this 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.

[0127] 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 the 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.

[0128] 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.

[0129] Next, in step S39 of FIG. 39, processor 31 determines whether any remote player has left the room. In addition, processor 31 also determines whether playback of the 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 the 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, it deletes the replay ghost whose playback has ended and the corresponding replay data.

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

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

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

[0133] [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 deletes the data of the existing 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.

[0134] 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.

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

[0136] 41, if the result of the determination in step S62 above is 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 the position information of player character 201 and state information indicating whether the state is a normal state or a special state.

[0137] 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 status of the remote character. Note that, instead of the position information, for example, information about an operation performed by a remote player may be received. In this case, the movement of the remote character may be controlled based on the received operation information. Furthermore, if a replay ghost exists, processor 31 continues playback based on the replay data. This controls the movement of the replay ghost.

[0138] Next, in step S66, processor 31 controls the actions of enemy characters, etc. Furthermore, processor 31 determines whether player character 201 has collided with an enemy character, a remote panel, etc., and appropriately executes game processing according to the result of the determination. 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. Furthermore, 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. Furthermore, as a result of this game processing, the above-mentioned miss event may occur.

[0139] Next, in step S67, processor 31 determines whether 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 passage flag 358 on. Accordingly, subsequent restart points are also set to the positions of the waypoint objects. Next, in step S69, processor 31 starts recording replay data related to player character 201 using replay recording data 359. At this time, if the situation is one in which the game has restarted from a waypoint, control may be performed so that recording of replay data is not started with a certain probability, as described above.

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

[0141] Next, in step S70 of Figure 42, processor 31 determines whether or not 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 not been contact (NO in step S70), the processing of step S71 is skipped.

[0142] Next, in step S72, processor 31 determines whether or not the above-mentioned miss event has occurred. If the result of this determination shows 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 the 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 the player character 201. If the result of this determination shows that the condition for entering a special state is satisfied (YES in step S74), processor 31 performs settings to place the player character 201 in a special state and various settings associated with this in step S75. Specifically, processor 31 sets special state flag 356 to ON. Furthermore, processor 31 changes the 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, and then the normal state processing ends.

[0143] 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. Thereafter, the normal state processing ends.

[0144] 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.

[0145] [Processing in special situations] Next, the special state processing will be described. Figure 44 is a flowchart showing the details of the special state processing. First, in step S91, processor 31 determines whether search flag 368 is on. If the result of this determination is off (NO in step S91), then in step S92, processor 31 acquires operation data 365. Next, in step S93, processor 31 moves the special character based on the operation data. As described above, while the special character is in play, no collision determination with the terrain or enemy characters is made.

[0146] Next, in step S94, 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.

[0147] Next, in step S95, processor 31 determines whether or not the counting of the special counter has finished. If the result of this determination shows that the counting has not finished yet (NO in step S95), then in step S96, processor 31 determines whether or not the resurrection condition has been satisfied. That is, it 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 shows that the condition has been satisfied (YES in step S96), then in step S97 of FIG. 45, processor 31 determines whether or not it is necessary to search for a resurrection position. That is, it determines whether or not the situation is such that the special character and the contacted resurrection target object are both located within the terrain, as shown in FIG. 19 above. If the result of this determination shows that such a situation exists (YES in step S97), then in step S98, processor 31 sets search flag 368 to ON. Next, in step S99, processor 31 changes the player character from the special character to the search object. Thereafter, processing proceeds to step S102, which will be described later.

[0148] On the other hand, if the result of the determination in step S97 above is that there is no need to search for a resurrection position (NO in step S97), in step S100, processor 31 sets special state flag 356 to OFF. 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 S101, processor 31 places player character 201 at the resurrection position. In this case, the resurrection position is determined as follows. First, a ray is cast from the contacted resurrection target object to the special character, and it is determined whether or not it hits the terrain. As a result, if it hits the terrain, the position of the resurrection assist object is set as the resurrection position. If it does not hit the terrain, the position of the special character is set as the resurrection position. As a result, a position such as that shown in FIGS. 13 to 18 above is determined as the resurrection position. Then, processing proceeds to step S102, which will be described later. Note that if 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 hit 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.

[0149] As mentioned above, the size of the player character returned to its normal state is also taken into consideration when determining the resurrection position. In other words, the resurrection position is determined to be a position that has enough space to prevent the player character returned to its normal state from getting stuck in an obstacle or the like.

[0150] On the other hand, if the result of the determination in step S95 above is that the counting of the special counter has ended (YES in step S96), in step S103, processor 31 sets ON lost occurrence flag 360. Thereafter, the process proceeds to step S102, which will be described later.

[0151] Next, a description will be given of the process when search flag 368 is on as a result of the determination in step S91 above (YES in step S91). In this case, in step S102 of FIG. 44, processor 31 executes search process. This process is the process of searching for a resurrection position as described above with reference to FIG. 20. FIG. 46 is a flowchart showing details of the search process. In FIG. 46, first, in step S171, processor 31 moves the search object a predetermined distance so as to move outward in a spiral trajectory from the position where the special character and the resurrection target object made contact.

[0152] Next, in step S172, processor 31 determines whether the position after movement satisfies the conditions for a resurrection position. Specifically, first, processor 31 sets the position after movement as the planned resurrection position. Then, it is determined whether the planned resurrection position is a "position outside the terrain" and a "position where space is secured for the player character returned to the normal state to be placed." If the result of this determination is that the conditions for a resurrection position are satisfied (YES in step S172), in step S173, processor 31 determines the current position of the search object (the planned resurrection position) as the resurrection position. Next, in step S174, processor 31 sets search flag 368 to OFF. Next, in step S175, processor 31 sets special state flag 356 to OFF and changes the search object to player character 201 in the normal state. Furthermore, processor 31 cancels the monochrome display setting of the game screen and sets it to a normal display. In the following step S176, processor 31 places player character 201 at the determined restoration position. After that, processor 31 ends the search process.

[0153] On the other hand, if the result of the determination in step S172 above is that the position after movement does not satisfy the conditions for a respawn position (NO in step S172), then in step S177, processor 31 determines whether the search object has moved to a position that is an edge of the screen (edge ​​of the display area). That is, it determines whether the spiral movement has reached any edge portion of the same screen. Note that in another embodiment, instead of reaching the edge of the screen, it may be determined whether the search object has moved a predetermined distance. If the result of this determination is that the search object has moved to a position that is an edge of the screen (YES in step S177), then in step S178, processor 31 sets search flag 368 to OFF. Subsequently, in step S179, processor 31 resets the special count and changes the search object from the player character to a special character. That is, if a position that satisfies the conditions for a respawn position is not found even after reaching the edge of the screen, the search is temporarily stopped there, and the character is returned to the special character. Then, the search process ends.

[0154] On the other hand, if the result of the determination in step S177 above is that the object has not moved to a position that is an edge of the screen (NO in step S177), the processes in steps S178 to S179 above are skipped. That is, in this case, the search continues. Thereafter, the search process ends.

[0155] Returning to FIG. 45, next, in step S102, 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.

[0156] Next, in step S103, processor 31 controls the actions of enemy characters, etc., and performs various associated game processes, after which the special state process ends.

[0157] 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), the process proceeds to step S10, which will be described later. On the other hand, if there has been contact (YES in step S8), in step S9, processor 31 executes replay ghost processing.

[0158] FIG. 47 is a flowchart showing details of the replay ghost processing. First, in step S111, processor 31 determines whether or not the placement completion flag 367 is on. If it is on (YES in step S111), processor 31 ends the replay ghost processing. On the other hand, if it is off (NO in step S111), processor 31 determines whether or not the selected flag 366 is on (YES in step S112), the processing proceeds to step S117, which will be described later. If it is off (NO in step S112), processor 31 determines in step S113 whether or not the download of the replay data from the game server 1 has been completed. If the result of this determination shows that it has not yet been completed (NO in step S113), processor 31 starts downloading the replay data from the game server 1 in step S115. Alternatively, if it has already started, processor 31 continues the download. Thereafter, the replay ghost processing ends.

[0159] On the other hand, if the download of the replay data is complete (YES in step S113), then in step S114, processor 31 determines whether or not a remote player is present at this time. 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 complete, the placement of a replay ghost will not actually be performed. Thereafter, the replay ghost processing ends.

[0160] On the other hand, if there are no remote players (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.

[0161] Next, in step S117, processor 31 determines whether 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, processor 31 is controlled to place the replay ghosts one by one while slightly shifting the timing of placement.

[0162] On the other hand, once all of the selected replay ghosts have been placed within the stage (YES in step S117), the process proceeds to step S119, where the placement completion flag 367 is set to ON. Thereafter, the replay ghost process ends.

[0163] 36, processor 31 determines whether 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. Thereafter, the process returns to step S2, and the processing is repeated.

[0164] On the other hand, if the goal is reached (YES in step S10), in step S12, processor 31 executes stage clear processing. Figure 48 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 indicating 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.

[0165] 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.

[0166] Next, in step S14, processor 31 performs processing to exit the stage room, after which the stage processing ends.

[0167] Next, a description will be given of the process 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 restart processing in step S17.

[0168] Figure 49 is a flowchart showing the details of the restart process. In Figure 49, first, in step S131, processor 31 sets lost occurrence flag 360 to OFF. At this time, processor 31 also sets special state transition count 357 to 0. In other words, upon restart, the count of the number of times a change to a special state occurs is reset. In this regard, in other embodiments, special state transition count 357 may be carried over after restart without being reset.

[0169] Next, in step S132, processor 31 initializes the selected flag 366 and the placement completion flag 367. This allows replay data to be downloaded again and new replay ghosts to be placed again when restarting from the midpoint.

[0170] 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 processing.

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

[0172] 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. Thereafter, the process proceeds to step S13 above. In this case, the flow is to transmit information about the player's own panel to game server 1 and then exit the stage room.

[0173] This concludes the detailed explanation of the stage play process.

[0174] [Game Server 1 Processing] Next, the details of the processing executed by game server 1 will be described. FIG. 50 is a flowchart showing the details of the processing related to game server 1. In FIG. 50, first, in step S151, processor 11 of game server 1 executes matching processing. In this processing, in response to a request from a player to start a stage play, processing is executed to match players with each other, that is, to determine the stage room into which each player will enter. Processing is also executed to transmit the result of this to game device 3.

[0175] Next, in step S152, processor 31 performs a process for managing stage rooms. In this process, processes for managing each stage room are performed by appropriately updating stage room management data 304, such as creating a new room, adding a player, and deleting a room with no players.

[0176] Next, in step S153, processor 31 executes a process for managing panel information. In this process, processor 31 receives own panel data 391 transmitted from each game device 3, and registers or updates the panel data 306. In addition, processor 31 also executes a process for transmitting panel information 332, which is the basis of the server panel, in response to a request from a specific game device 3, as necessary.

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

[0178] 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.

[0179] As described above, in this embodiment, when a mistake event occurs to the player character 201, if there is a remote character nearby that is a revival assist object, the player character 201 is not lost, but is temporarily changed to a special state. Then, by coming into contact with the remote character during the revival-enabled 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 encourage online multiplayer gameplay.

[0180] In addition to the remote characters, the remote panels placed by each remote character and the server panel also function as the revival assist objects. Therefore, if a player places a remote panel, the remote panel can be expected to function as an aid to other players on his / 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 through the game at his / her own pace.

[0181] Furthermore, in this embodiment, as described above, a replay ghost appears when the player passes the midpoint of a stage. At first glance, the replay ghost is indistinguishable from the remote character. The replay ghost also functions as the resurrection assist object. Therefore, even if the player does not encounter other players until halfway through the stage, the player is connected online with other players in the latter half of the stage, providing the player with the experience of playing together in the same stage room. In other words, from the start of stage play until the player reaches the midpoint, the player is given a sense of anticipation of meeting other players. For example, in the first half of the stage, it is quite possible that the remote character of a player who joins later will catch up. Therefore, rather than appearing immediately after the start of stage play, the ghost waits for a while for other players to enter the room and for a remote character to appear. On the other hand, if the player reaches the midpoint from the start of stage play but no other players have entered the room, the replay ghost appears, providing the player with the experience of progressing through the stage together with the remote character. This gives meaning to playing online and encourages players to actively play online. Also, if another player joins the room after a replay ghost appears, the replay ghost will disappear and a remote character will appear depending on the number of players who have joined. This allows players to prioritize playing with remote characters with whom they can communicate.

[0182] Furthermore, when the resurrection assist object is used to resurrect the player character from a special state to a normal state, the resurrection position is searched for by moving the search object as described above. In this case, the process for each frame related to the search for the resurrection position simply involves determining whether the position of the search object satisfies the conditions for the resurrection position. Therefore, compared to, for example, searching for possible resurrection positions within the stage and then reviving the character, the process for searching for the resurrection position can be executed with a lighter processing load for each frame. Furthermore, by showing the player how the searching object is moved and searched (the search process), the player can easily find the resurrection position, and the player can be given a sense of satisfaction as to why the resurrection position was selected.

[0183] [Variations] It should be noted that, for example, the replay ghost may be the same character as the character used by the player as the player character 201. 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 if there is a replay ghost that is the same character as the player character 201, as it may be difficult to distinguish them in some cases.

[0184] In the above example, the timing for making the replay ghost appear was when the player character reached the midpoint. However, in a specific stage, the replay ghost may be made to appear from the starting point. In this case, recording of the replay data for that specific stage may also start from the starting point.

[0185] In the above example, the replay ghost appears identical to the remote character, but in other embodiments, the replay ghost may appear differently so that the player can distinguish between the remote character and the replay ghost.

[0186] Also, in the above example, a replay ghost is not made to appear (a replay is not played) 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 about a replay ghost made to appear on one game device may be shared with other game devices. For example, when a process for making a replay ghost appear is performed in the game processing of game device A, the same replay ghost may appear on other game devices in the same stage room by sharing location information or the replay data itself, for example.

[0187] 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 predetermined conditions. In this regard, in other embodiments, the player may be able to change to the special state voluntarily by performing a predetermined operation. However, reviving from a special state to the normal state may not be achieved by a voluntary operation, but may require contact with a revival assist object within the revival time, as described above. This allows the player to strategically intentionally enter a special state when conquering a stage, and then revive after passing through a difficult part of the stage. This makes it possible to broaden the scope of play while maintaining the benefits of online play.

[0188] 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.

[0189] Furthermore, in the above example, the timing of transmitting the panel information to the game server 1 is explained 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. Furthermore, it may be possible to register multiple pieces of panel information for the same player in the game server 1.

[0190] Also, in the above embodiment, an example was described in which collision detection between the player character 201 in a 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 so that the remote character does not directly affect the gameplay of the player. For example, when the player character 201 in a normal state comes into contact with a (semi-transparent) remote character, processing may be performed such that the remote character's reaction is displayed as if it is being slightly pushed, and the name of the remote player associated with the remote character is temporarily displayed.

[0191] In the above embodiment, the description is based on the assumption that each game device has one player. However, two players may simultaneously participate in stage play on one game device. For example, game device A may display player A and player B's respective player characters, player character A and player character B, on the same game screen in a two-player simultaneous play mode (local multiplayer). In this case, player character A and player character B may not be displayed translucently like remote characters, but may be displayed opaquely. Player character A and player character B may function as each other's resurrection support object. Regarding the panel arrangement, each player may treat the panel placed by the other player as the remote panel. Alternatively, only the panel placed by one player's character may be treated as the remote panel.

[0192] In the case of local multiplayer as described above, the panel information transmitted to the server may be limited to the panel information placed by one of the players. A maximum of two of the above-mentioned server panels may be arranged.

[0193] Furthermore, the number of player actors in each room is adjusted to a maximum of four, so it is sufficient to place up to two replay ghosts.

[0194] 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 they may be able to be revived using the remote characters or remote panels.

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

[0196] In the above embodiment, a search object is used to search for a position where a character can be resurrected in a situation such as that shown in FIG. 19 . The above-described position search process is not limited to a resurrection position, but can also be applied to searching for a position where a specific character is desired to appear or be placed. For example, if a player character or enemy character is desired to appear at a random position in the game space at the start of the game, the above-described search object may be used to search for the appearance position. Also, for example, suppose there is an in-game gimmick that warps or teleports the player character to a position different from the current position. When searching for such a warp / teleport destination, the above-described search object may be used to search for the appearance position.

[0197] In addition, in the above example of the search process, a special character is changed to the object being searched. In other embodiments, the object being searched may be, for example, a player character in a normal state with a changed display mode. For example, a semi-transparent version of the player character in a normal state may be used as the object being searched. [Explanation of symbols]

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

Claims

1. The computer of the game device moving the player object in the first state in response to an operation by the player within the game space; determining whether or not a candidate position that will have a second positional relationship with the predetermined object satisfies an object placement condition under which the player object in the second state can be placed when the player object in the first state and a predetermined object have a first positional relationship; If the candidate position satisfies the object placement condition, placing the player object in the second state at the candidate position; If the candidate position does not satisfy the object placement condition, placing a second object at a position based on the candidate position; moving the second object along a predetermined trajectory; repeatedly determining whether the position of the second object satisfies the object placement condition while the second object is moving; When the position of the second object satisfies the object placement condition, placing the player object in the second state at a position based on the position of the second object. Game program.

2. causing the computer to receive, from another game device connected via a network, operation information of another player operating the other game device; The game program according to claim 1 , wherein the predetermined object is placed in the game space of the other player based on operation information of the other player.

3. The game program according to claim 1 , wherein the predetermined trajectory is a trajectory that moves away from a position where the second object is placed.

4. The game program according to claim 3 , wherein the predetermined trajectory is a spiral trajectory.

5. 2. The game program according to claim 1, wherein the computer determines whether the object placement condition is satisfied based on whether a space according to the size of the player object in the second state is secured at the position after the second object is moved.

6. The game program according to claim 1 , wherein the second object is an object for which collision detection with other objects in the game space is not performed.

7. at least one processor; The processor: moving the player object in the first state in response to an operation by the player within the game space; determining whether or not a candidate position that has a second positional relationship with the predetermined object satisfies an object placement condition under which the player object in the second state can be placed when the player object in the first state and a predetermined object have a first positional relationship; If the candidate position satisfies the object placement condition, placing the player object in the second state at the candidate position; If the candidate position does not satisfy the object placement condition, placing a second object at a position based on the candidate position; moving the second object along a predetermined trajectory; repeatedly determining whether the position of the second object satisfies the object placement condition while the second object is moving; placing the player object in the second state at a position based on the position of the second object when the position of the second object satisfies the object placement condition; Game system.

8. The computer of the game device moving the player object in the first state in response to an operation by the player within the game space; determining whether or not a candidate position that will have a second positional relationship with the predetermined object satisfies an object placement condition under which the player object in the second state can be placed when the player object in the first state and a predetermined object have a first positional relationship; If the candidate position satisfies the object placement condition, placing the player object in the second state at the candidate position; If the candidate position does not satisfy the object placement condition, placing a second object at a position based on the candidate position; moving the second object along a predetermined trajectory; repeatedly determining whether the position of the second object satisfies the object placement condition while the second object is moving; When the position of the second object satisfies the object placement condition, placing the player object in the second state at a position based on the position of the second object. Game processing method.

Images