Game program, game system, and game processing method

Abstract

To provide a game program, a game system, and a game processing method that enable the user to readily distinguish its own operated character.SOLUTION: A first game device and a second game device are matched through a network. A first player character operated by a player of the first game device and a second player character operated by a player of the second game device are selected from a character group including a plurality of different character groups, respectively. If the selected characters are the same character, a game space is depicted for the first game device so that the second player character is substituted with a character different from the first player character in the character group. For the second game device, the game space is depicted so that the first player character is substituted with a character different from the second player character in the character group.SELECTED DRAWING: Figure 40

Description

[Technical field]

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

[0002] Conventionally, there have been games in which a game stage is played by multiple players (for example, Patent Document 1). Among such games, online multiplayer games in which multiple players play via a network such as the Internet are also known. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2020-124286 A Summary of the Invention [Problem to be solved by the invention]

[0004] Here, for example, in a fighting game, there is also a type of game in which a player selects a character to be operated from among a plurality of types of characters prepared in advance. In such a game in which a player selects a character to be operated, when attempting to perform online multiplayer, the character selected by the player and the character selected by another player may be the same character. In this case, multiple identical characters are displayed on the same game screen, and it may be difficult to distinguish which character the player is operating. [Means for solving the problem]

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

[0006] (Configuration 1) Configuration 1 is a game system in which a multiplayer game is played between players of a plurality of game devices matched via a network, and includes a first game device and a second game device connected to the first game device via the network. In the first game device, a first player character whose movement is controlled based on an operation of a player of the first game device is selected from a character group including a plurality of different characters, and in the second game device, a second player character whose movement is controlled based on an operation of a player of the second game device is selected from the character group. If the selected first player character and the second player character are the same character, in the first game device, the second player character is replaced with a character from the character group different from the first player character, and a game space including the first player character and the second player character is rendered. In addition, in the second game device, the first player character is replaced with a character from the character group different from the second player character, and a game space including the first player character and the second player character is rendered.

[0007] According to the above configuration, it is possible to prevent a character that is the same as a character operated by a player from being displayed, thereby making it easier for the player to distinguish between the characters they are operating.

[0008] (Configuration 2) In a second embodiment of the first embodiment, the game system further includes a third game device. In the third game device, a third player character whose movement is controlled based on an operation of a player of the third game device may be selected from the group of characters. If the selected third player character is the same as the first player character or the replaced second player character, the first game device may replace the third player character with a character from the group of characters that is different from the first player character and the replaced second player character, and render a game space including the first player character, the second player character, and the third player character.

[0009] According to the above configuration, it is possible to prevent the same characters operated by different players from being displayed, thereby making it easier for the players to distinguish between the characters.

[0010] (Configuration 3) In the configuration 3, in the above configuration 1, the game system may further acquire replay data including at least an operation history of a predetermined player and information indicating a character used in the operation from a predetermined server, and place a replay character whose movement is controlled based on the replay data in the game space. Then, in the first game device, when the character used indicated in the acquired replay data is the same character as the first player character, the replay character may be replaced with a character from the character group different from the first player character and placed in the game space.

[0011] According to the above configuration, it is possible to prevent a replay character that is the same as a player character from being displayed, which makes it easier for the player to distinguish between the characters.

[0012] (Configuration 4) Configuration 4 may be configured in the above configuration 1 to have a first or second player character place an installation object having an appearance corresponding to each of a group of a plurality of characters at a predetermined position in the game space based on a predetermined operation. Then, in the first game device, when the second player character who placed the predetermined installation object is the replaced character, the second player character may be caused to place an installation object having an appearance corresponding to the replaced character.

[0013] According to the above configuration, when an object whose appearance differs depending on the character is placed in the game space, the object can be placed in a manner that matches the appearance of the character, making it possible to easily convey to the player which character placed the object.

[0014] (Configuration 5) Configuration 5 is configured as follows: in configuration 4, when a first game device is connected to a second game device based on matching and a multiplayer game is started, if an installation object placed by a character other than the first player character already exists in the game space and the character who placed the installation object is the same character as the first player character, then the installation object may be replaced with an installation object corresponding to a character other than the first player character.

[0015] According to the above configuration, it is possible to prevent the occurrence of a situation in which, for example, an installation that a player does not remember installing appears to already exist even though the player has just started a multiplayer game.

[0016] (Configuration 6) In the sixth aspect of the first aspect, the game system may display a message corresponding to a predetermined player character in response to an action of the player character during play of the multiplayer game. In addition, in the first game device, when a second player character that has performed an action for which a predetermined message is displayed is a replaced character, the game system may display a message corresponding to the replaced character.

[0017] According to the above configuration, it is possible to prevent a message regarding a player character that has performed a predetermined action from being displayed with a name different from that of the character in question, thereby making it possible to display the message in a visually natural manner.

[0018] (Configuration 7) In configuration 7, in configuration 1, the game space may include a stage space in which a first predetermined number of people can participate by matching, and a world space in which a second predetermined number of people greater than the first predetermined number of people can participate by matching and in which a player can select a stage to play. When rendering the world space in the first game device, a world space including the first player character may be rendered without rendering a second player character that is the same as the first player character, and when rendering the stage space in the first game device, for a second player character that is the same as the first player character, the second player character may be replaced with a character different from the first player character, and a stage space including the first player character and the second player character may be rendered.

[0019] According to the above configuration, on the game screen in the world space, it is possible to prevent the same character as the character used by the player from being displayed multiple times, and to avoid the player becoming confused about the object of his / her control. Also, on the game screen in the stage space, where the number of participants is relatively small compared to the world space, it is possible to avoid the player becoming confused about the object of his / her control, and further to ensure the feeling of multiplayer play with multiple players. Effect of the Invention

[0020] According to the present disclosure, it is possible to prevent the player from becoming confused about the character he or she is controlling, while suppressing waiting for matching due to overlapping characters. [Brief description of the drawings]

[0021] [Figure 1] FIG. 1 is a schematic diagram showing an overall view of a game system according to an embodiment of the present invention; [Diagram 2] Block diagram showing the hardware configuration of game server 1 [Diagram 3] A block diagram showing the hardware configuration of the game device 3. [Figure 4] An example of a game screen [Diagram 5] An example of a game screen [Figure 6] An example of a game screen [Figure 7] An example of a game screen [Figure 8] An example of a panel [Figure 9] Diagram showing the relative positions in the world [Figure 10] An example of a game screen [Figure 11] An example of a game screen [Figure 12] An example of a game screen [Figure 13] An example of a game screen [Figure 14] Diagram showing the relative positions in the world [Figure 15] An example of a game screen [Figure 16] An example of a game screen [Figure 17] An example of a game screen [Figure 18] An example of a game screen [Figure 19] An example of a game screen [Figure 20] An example of a game screen [Figure 21] An example of a message [Figure 22] An example of a message [Figure 23] A memory map showing an example of various data stored in the memory unit 12 of the game server 1. [Figure 24] An example of the data configuration of the world room management data 304 [Diagram 25] An example of the data configuration of the world entry player information 314 [Figure 26] An example of the data configuration of the stage room management data 305 [Figure 27] An example of the data configuration of the replay management data 306 [Figure 28] A memory map showing an example of various data stored in the storage unit 32 of the game device 3. [Figure 29] An example of the data configuration of the player character master data 404 [Diagram 30] An example of the data configuration of the installation master data 405 [Diagram 31] An example of the data configuration of the display object management data 410 [Diagram 32] An example of the data configuration of the remote player data 413 [Diagram 33] An example of the data configuration of the player actor management data 415 [Diagram 34] An example of the data configuration of the installation management data 416 [Diagram 35] A flowchart showing details of a world map process executed by the game device 3. [Diagram 36] A flowchart showing details of a world map process executed by the game device 3. [Figure 37] Flowchart showing details of display target determination processing [Figure 38] Flowchart showing details of stage play processing [Figure 39] Flowchart showing details of stage play processing [Diagram 40] Flowchart showing details of the character disguise determination process [Diagram 41] Flowchart showing details of installation camouflage processing [Diagram 42]Flowchart showing details of entrance / exit check processing [Diagram 43] Flowchart showing details of entrance / exit check processing [Diagram 44] Flowchart detailing the ghost placement procedure [Diagram 45] Flowchart showing details of the installation process [Diagram 46] A flowchart showing details of the game server process executed by the game server 1. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[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 terminal 3 are configured to be able to communicate with each other via a network 10 such as the Internet. In this embodiment, information processing is executed with such a configuration, and below, game processing will be described as an example of the information processing. Specifically, a game program is installed on the information processing terminal 3, and game processing is executed while communicating with the game server 1 as necessary.

[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. The communication unit 13 is connected to a network by wired or wireless communication, and transmits and receives predetermined data between the information processing terminal 3 or another server. Note that, although an example in which there is one game server 1 is illustrated in this embodiment, the game server 1 may be configured as a group of servers performing distributed processing.

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

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

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

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

[0028] Furthermore, a display unit 5 (e.g., a television or the like) is connected to the game device 3 via an image / audio output unit 35. The processor 31 outputs, for example, images and sounds generated by executing the above-mentioned information processing to the display unit 5 via the image / 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 directional input device. The analog stick 42 can be used as a directional input unit capable of inputting a direction. By tilting the analog stick 42, the user can input a direction according to the tilt direction (and input a magnitude according to the tilt angle). The controller 4 also includes a button unit 43 including various operation buttons. For example, the controller 4 may include a plurality of operation buttons on the main surface of the housing.

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

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

[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 made in the play from that point until the goal is reached, the player character can restart from the waypoint. Note that before reaching the waypoint, the player restarts from the start point. Note that the position set as the waypoint is not limited to a position that is approximately halfway between the start point and the goal point, and a predetermined position may be set as the waypoint as long as it is a position on the way between the start point and the goal point.

[0035] [About the World Map] In addition, in this game, a plurality of the above stages are prepared. Then, before playing each stage, a screen called a "world map screen" is displayed as a screen having a function of allowing the player to select a stage to be played. FIG. 5 is an example of the world map screen. In FIG. 5, a screen showing a virtual space "world" from above is displayed. The virtual space may be a two-dimensional space or a three-dimensional space. The drawing method and display mode of the "world" and the "stage" may be different. For example, the stage may be drawn by projecting it from the front direction using orthogonal projection, and the world may be drawn by photographing it from above and taking a bird's-eye view. A plurality of stage objects 204 that serve as entrances to the above stages are arranged in the world. Also, a portal object 205 for moving to another world is arranged. Also, a player character 201 is displayed on the world map screen. The player can move the player character 201 on the world map screen by operating the controller 4. Furthermore, the player can select a stage corresponding to one of the stage objects 204 by moving the player character 201 so that the player touches the stage object 204. Then, by performing a predetermined operation for starting play of the stage (hereinafter referred to as a stage start operation), the player can start play of the stage corresponding to the stage object 204. Specifically, when the stage start operation is performed, a predetermined effect is displayed, and then the screen switches to a stage screen in which the player character 201 is positioned at the start point of the stage.

[0036] [About the relationship between worlds and stages] In addition, in this game, multiple worlds are prepared for the above-mentioned "world." In this game, as an example, it is assumed that there are five worlds (World 1 to World 5), and each world contains four stages. One of the five worlds is displayed as the world map screen.

[0037] When moving from one world to another, the player first moves the player character 201 onto the portal object 205 on the world map screen. Then, the player performs a predetermined operation (hereinafter, referred to as a world movement operation) to move the player character to another world associated with the portal object 205. For example, when a world movement operation is performed on the portal object 205 associated with World 2 on the world map screen of World 1, the player character moves to World 2, and the world map screen is switched to the world map screen related to World 2.

[0038] The basic flow of the game is to select the stage you want to play on the world map screen, clear the stage to unlock the unlocked stages, clear all stages in the world to unlock the next world, and clear the stages in each world to unlock the next world, with the goal of clearing the final stage of the final world.

[0039] [Online play elements] This game also allows for multiplayer play. For example, this game allows players to connect to the server or other game devices 3 via the Internet and play with other players.

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

[0041] Also, each room has a maximum number of people that can enter it. As an example, in this game, it is assumed that a maximum of 30 people can enter one world room. Also, it is assumed that a maximum of 4 people can enter one stage room. Also, in this game, rooms are divided for each world and each stage, but multiple world rooms and stage rooms can exist in parallel. As an example, in this game, it is assumed that a connection mode (client-server mode) in which communication is performed via a server is used for world rooms, and a mode in which game devices 3 are connected to each other by a P2P (Peer to Peer) communication mode is used for stage rooms.

[0042] 6 shows an example of a world map screen when entering a world room where a predetermined number of players are already in the room. In addition to the player character 201, the screen also displays multiple other player characters 211 operated by other players who have entered the same world room.

[0043] 7 is an example of a stage screen output from the game device 3 of a player when the player enters a stage room in which another player has already entered. In Fig. 7, another player character 211 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 started stage play, the other player character 211 is in a position slightly further ahead toward the goal point than the starting point.

[0044] In the following description, other players who have entered the same world room or stage room are called "remote players", and the other player characters 211 operated by the remote players are called "remote characters". In addition, the player himself in the game device 3 is sometimes called the "local player" in relation to the remote player, and the player character 201 operated by the local player is sometimes called the "local character". In addition, a "replay ghost" may also appear as a player character related to the remote player in the stage play. In the following, the local character, remote character, and replay ghost are sometimes collectively called "player actors". In this game, since up to four people can enter one stage room, a maximum of four player actors can exist in one room at the same time. On the other hand, since up to 30 people can enter the world room, a maximum of 30 player actors can exist in total, including local characters and remote characters. However, as described later, the number of player characters displayed at the same time is up to 12.

[0045] [About Replay Ghost] Next, we will explain the replay ghosts that appear in stage play. Replay ghosts are ghosts that play back other players' replay data. Therefore, in principle, the appearance of the replay ghost will be the character that was used when the replay was recorded (however, in some cases, it may be a "fake character" as described below).

[0046] In this embodiment, the play from the midpoint to the goal point is stored as replay data in the game server 1. Then, when a predetermined condition is met, a replay ghost is made to appear. Specifically, the predetermined condition is when the local player is the only player in the stage room and the game proceeds to the midpoint. In other words, when the game proceeds to the midpoint without matching with another player, the replay data is downloaded from the game server 1 and played. This allows the other player's character based on the replay data to be displayed as a ghost.

[0047] [About installation objects] Also, in the above stage, each player can set a predetermined installation object on the stage by performing a predetermined operation during stage play. The installation object is, for example, an object that can have an advantageous effect on the player. For example, the installation object is an item or a panel-type object (hereinafter, simply referred to as a panel). In the case of an item, the player can obtain an item set by another player by touching the item with the player character. In other words, by using this, it is possible to transfer items between players. In addition, in the case of a panel, it is possible to have an advantageous effect such as powering up the player character that has come into contact with the panel or eliminating an unfavorable state (such as an abnormal state) that has occurred to the player character. In other words, it is also possible to indirectly help other players by setting up a panel. In this embodiment, an image corresponding to the player character who set up the installation object is prepared for the appearance of the installation object. FIG. 8 shows an example of the above panel. FIG. 8 shows an example of a panel A set up by character A, which is a local character, and a panel B set up by character B, which is a remote character. Both are treated as the same installation object in terms of functionality, but as shown in Figure 8, their appearances are different, and they are designed to make it easy to identify which player character placed the panel. Also, for some installation objects (panels in this example), each player can only place one. Therefore, if the same player places a panel multiple times in the same stage room, the previously placed panel is erased and only the most recent panel is displayed. Also, once an installation object has been placed, it will remain on the stage as long as the stage room remains, even after the player who placed it has left the stage room.

[0048] [About available player characters] In this game, the characters that can be used as player characters are selected from a number of types of characters prepared in advance. Different types of characters are characters that differ at least in appearance (outward appearance) to the extent that they can be recognized as "different characters." In this game, the character performance, etc. are also different. In the following, when we say "the same character," we mean characters of the same type, and when we say "different characters," we mean characters of different types.

[0049] Each player needs to select a character to be used when playing this game. In this embodiment, as an example, a case will be described in which 12 different characters, "character A" to "character L", are prepared. Then, the player selects one of these 12 characters as the player character to be used by the player. Therefore, the remote character 211 may be a character selected by another player, and may be a character different from the player character 201.

[0050] In the case of online multiplayer where players are matched with an unspecified number of opponents, since the number of selectable characters is limited, different players may select the same character and play in the same room. In this regard, if multiple characters with the same appearance are displayed at the same time on the world map screen or stage screen, it may be difficult for the player to know which character they are controlling.

[0051] In view of the above, it is possible to adjust the matching of players so that their characters do not overlap. This can prevent players who have selected the same character from being matched with each other, and can prevent multiple characters with the same appearance from being displayed at the same time. However, in this case, it may be difficult to match players because the character you selected overlaps with another player's, for example, you may not be able to enter a room with the same character, and the waiting time for matching may become longer.

[0052] Therefore, in this embodiment, without carrying out control such as the above-mentioned restriction on matching of the same characters, control is performed so that the same player character is not displayed more than once on the game screen of each player's game device. Specifically, the following control is performed on each of the world map screen and the stage screen to suppress simultaneous display of multiple characters of the same character.

[0053] [Character display control on the world map screen] First, an overview of the display control of the player characters on the world map screen will be described. In this embodiment, when the same type of player characters exist (overlap) on the world map screen, control is performed so that only one of them is preferentially displayed on the game screen of each player. Specifically, when the player characters of the local player and the remote player overlap, the display of the player character (local character) of the local player is prioritized. As an example, assume that three players (hereinafter, each will be referred to as 1P, 2P, and 3P) each select character A. In this case, assume that the positions of each player on the world map at a certain timing are in a positional relationship as shown in FIG. 9. In this case, since all three players select the same character, only character A, which is the operation target of 1P, is displayed on the game screen of 1P (when 1P is the local player), as shown in FIG. 10. Also, on the game screen of 2P (when 2P is the local player), only character A, which is the operation target of 2P, is displayed, as shown in FIG. 11. On the 3P game screen (when the 3P is the local player), only character A, which is the object of operation by the 3P, is displayed, as shown in FIG.

[0054] Next, consider a case where there is no overlap with the local character, but the remote characters of the remote players overlap. For example, consider a case where 1P, the local player, selects character A, and 2P and 3P select character B. In such a case, of the overlapping remote characters, the display of the remote character closest to the local character is prioritized on the game screen of 1P. For example, assuming the same positional relationship as in FIG. 9 above, character B operated by 2P, which is closer to the local character, is displayed on the game screen of 1P, as shown in FIG. 13.

[0055] Also, let us assume that the positional relationship between 2P and 3P has changed from the situation in Figure 9 to that shown in Figure 14. In other words, let us assume that 3P has moved closer to 1P, and 2P has moved farther away from 1P. In this case, as shown in Figure 15, character B operated by 3P, who is now closer to the local character, is displayed, and character B operated by 2P is hidden.

[0056] Thus, in this embodiment, in a situation where there are multiple identical characters in the same world room, only one of them is displayed, and control is performed so that the same character is not displayed multiple times. Therefore, regardless of the actual number of people entering the room, the number of player characters displayed on the world map screen is a maximum of 12 (each different character). Note that this example illustrates a case where there are 12 characters to select from, so the maximum number is 12, but if the number of selectable characters is greater, the maximum number displayed on the world map screen will be the same as the number of selectable characters.

[0057] As described above, in this embodiment, in a situation where there are overlapping remote characters on the world map screen, the remote character closest to the position of the local character is controlled to be preferentially displayed. Here, in order to determine whether the overlapping remote character is closest to the position of the local character, a process of determining the distance between each of the overlapping remote characters and the local character is performed. In this embodiment, this distance determination is performed at a predetermined time interval (for example, every few seconds). In other words, even if a change occurs in the positional relationship between the overlapping remote character and the local character, the switching of the remote character to be preferentially displayed is not necessarily reflected in real time. This is to prevent the switching of the displayed remote character from occurring too frequently. If the switching occurs too frequently, the remote character may appear to be flashing, which may cause the player to feel uncomfortable or make the screen difficult to view, and this is to prevent such a situation.

[0058] Furthermore, in this embodiment, when performing the distance determination as described above, the actual distance between the local character and the remote character being displayed by priority is corrected to a shorter distance, and then the distance determination is performed. For example, assume that the above-mentioned 2P and 3P have both selected character B, and character B of 2P is the target of priority display. Then, assume that the distance between 1P and 2P is 10m in the game, and the distance between 1P and 3P is 12m in the game. In this case, when performing the above distance determination, the distance between 2P and 1P being displayed by priority is corrected to, for example, 70% of the distance, and then the distance determination is performed. That is, the distance is corrected from 10m to 7m, and then the distance determination is performed. As a result, character B of 3P, which is not the target of display, is less likely to be selected as the target of priority display. This is to provide continuity to the display of the currently displayed character, particularly when the difference in distance between 2P and 3P is small, and to prevent the remote character being displayed from being switched frequently.

[0059] In this embodiment, even if a remote character is a display priority target, if it has not been operated for a certain period of time, it will be hidden. This is because displaying a remote character that is currently being operated takes precedence over displaying a remote character that has been left unoperated. Note that local characters are always displayed regardless of whether they are being operated or not.

[0060] [Character display control in stage rooms] Next, the display control of player characters etc. in a stage room will be explained. In the case of a stage room, unlike the case of the world room described above, duplicate player characters are replaced (substituted) with images of other characters so that the same player character is not displayed. Hereinafter, this image replacement will be referred to as "disguise". In the case of a stage room, unlike the world room, the maximum number of people that can enter the room is relatively small at four, so if duplicate characters were not displayed, the feeling of playing together with other players in online multiplayer would be lost.

[0061] The above-mentioned disguise process is performed individually as a process in each game device. In other words, the disguise contents are not synchronized between the game devices in the stage room. Therefore, the disguise contents may differ between the game devices. The objects to be disguised are remote characters, replay ghosts, and placement objects. The timing of the process is when a remote character is generated in each game device 3. Specifically, the process is performed when a local player newly enters the stage room (if there is an existing remote player, the remote character is generated), and when a remote player enters the room thereafter. In the following description, the character actually selected by each player (the character before disguise) is called the "actually selected character", and the disguised character is called the "disguised character".

[0062] An example of the above disguise will be described below. First, assume that three players have entered a certain stage room, and all of them have selected character A. In other words, assume that there is a remote player whose actual selected character overlaps with that of the local player. In this case, on each game device, the remote character operated by the remote player is disguised as a character other than character A and displayed. In this case, a screen such as that shown in FIG. 16 may be displayed as the game screen of 1P, who is the local player. In FIG. 16, the operated character of 1P is character A, the operated character of 2P is disguised as character B, and the operated character of 3P is disguised as character C. In other words, the actually selected character is displayed for the operated character (local character) of 1P, and the disguised characters are displayed for the remote characters of 2P and 3P, not the actually selected character. Also, in the same situation, a screen such as that shown in FIG. 17 is displayed on the game screen of 2P (when 2P becomes the local player). In FIG. 17, the operated character of 2P is character A, the operated character of 1P is character C, and the operated character of 3P is character B disguised. In the same situation, the game screen for 3P will display a screen like that shown in Figure 18. In Figure 18, the character operated by 3P is character A, the character operated by 1P is disguised as character B, and the character operated by 2P is disguised as character D.

[0063] Also, if 1P, whose selected character is character A, enters a stage room after 2P, whose selected character is character A, the character operated by 2P will be disguised as a character other than character A on 1P's game screen. Conversely, the character operated by 1P will be disguised as a character other than character A on 2P's game screen.

[0064] [About overlaps between remote players] Next, consider a case where the actual selected characters overlap only between remote players. In this case, of the remote players with the overlapping actual selected characters, one of them will keep the remote character as the actual selected character, and the remaining remote players will disguise their remote characters. For example, consider a case where, in a stage room with four players, the actual selected character of 1P is character A, and the actual selected characters of 2P, 3P, and 4P are character B. In this case, for example, on the game screen of 1P, the remote character of 2P will be displayed as character B, and the remote characters of 3P and 4P will be disguised as character C and character D, respectively. This prevents the same character from being displayed more than once at the same time.

[0065] Also, once a character is disguised, the disguise will not be changed within that stage, even if the overlap is resolved later. For example, consider a case where the actual characters selected by 2P and 3P are character B, and the character operated by 3P is disguised as character C. In this case, even if 2P reaches the goal and leaves the stage room, and the overlap between the actual characters selected by 2P and 3P is resolved, the disguise for 3P will continue.

[0066] [Decision on the destination of the counterfeit goods] Here, we will provide additional information on how to determine the impersonation content (impersonation destination). In this embodiment, data called a "impersonation list" is defined in advance. The contents of the impersonation list are the IDs of the above 12 characters arranged in a predetermined order. When determining the impersonation destination, the impersonation list is referenced in the processing of each game device, and the IDs are checked in order according to the order of the list. The first character found that does not overlap with existing characters in the room is determined as the impersonation destination. Note that when checking the IDs in the impersonation list in order, the starting ID (initial candidate for the impersonation destination) is determined randomly when the game app of this embodiment is launched on each game device.

[0067] [About Replay Ghost Impersonation] As described above, the replay ghost is also included as a target for disguise. Disguise of the replay ghost is the same as that of the remote player described above. In other words, the replay ghost is also treated as a remote player (remote character). For example, assume that the character actually selected by the player is character A, and the replay data downloaded from the game server 1 also uses character A. In this case, the appearance of the replay ghost that appears is disguised as a character other than character A, but the action content of the replay ghost itself is based on the downloaded replay data (replay data using character A).

[0068] [About disguising installed objects] Next, the disguise of an installation object will be described. As described above, the installation objects of this game include objects that are treated as the same object in terms of their function and effectiveness, but have designs that correspond to the 12 characters (for example, the above panels). Also, once an installation object is installed, it remains on the stage even after the player who installed it leaves the stage room. Therefore, for example, in the case of the above panels, 3P who was playing using character A installs panel A corresponding to character A, clears the stage, and leaves the stage room. There may be a case where 1P enters the same stage room with character A as the actual selected character (a situation where there is no overlap of the actual selected character). In this case, from 1P's point of view, it will be a situation where panel A that he does not remember installing already exists. In consideration of such a case, in this embodiment, when a player enters a stage room, if a character corresponding to an existing installation object in the room overlaps with the player's actual selected character (local character), a process is performed to disguise the existing installation object as an installation object corresponding to another character. For example, if 1P enters a room containing panel A placed by character A as the actual selected character, panel A will be disguised as panel B on 1P's game screen, as shown in Figure 19. On the other hand, if 1P enters a room with a character other than character A as the actual selected character, panel A will be displayed without being disguised, as shown in Figure 20.

[0069] Also, for example, when a 1P whose actual selected character is character A enters a room in which a 3P using character A is present, the character A operated by the 3P is displayed on the 1P's game screen disguised as, for example, character C. In this case, any installed objects that the 3P has already placed or will subsequently place will also be disguised as installed objects corresponding to character C.

[0070] Also, as in the case of the remote character (replay ghost) described above, once a disguised installation object has been disguised, the disguised location will not be changed even if the overlapping state is subsequently released.

[0071] [About spoofed in-game messages] In this game, when the above-mentioned installation object is placed, a message indicating that is displayed on the game screen. For example, as shown in FIG. 21, a message such as "Character C has placed item X" is displayed in the form of a telop. In addition, even in other cases, a message using the character name may be displayed based on a predetermined action performed by the player character. The above-mentioned disguise of the character is also reflected in such messages. For example, suppose that the actual selected characters of 1P and 2P are the same character A, and the operated character of 2P is disguised as character B in the game processing on the 1P side. In this case, as shown in FIG. 22, a message using the name of the disguised character is displayed on the game screen of 1P. In other words, when a character is disguised, the character name as it appears is used in the message in the processing of each game device.

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

[0073] [About the data used on Game Server 1] First, a description will be given of the data used in the game server 1. Fig. 23 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, world room management data 304, stage room management data 305, and replay management data 306.

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

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

[0076] The world room management data 304 is a database for managing the world room. FIG. 24 shows an example of the data configuration of the world room management data 304. In FIG. 24, the world room management data 304 includes one or more pieces of world room information 312 for each world. Each piece of world room information 312 includes a world room ID 313, world entry player information 314, and the like. The world room ID 313 is an ID for uniquely identifying the world room. The world entry player information 314 is information about a player currently entering the world room. FIG. 25 shows an example of the data configuration of the world entry player information 314. The world entry player information 314 is data in a table format including at least the items of a world player ID 315, a selected character ID 316, and world position information 317. The world player ID 315 is an ID of a player who has entered the world room, and corresponds to the player ID 308. The selected character ID 316 is an ID for identifying the character selected by each player as the character to be used, and is information corresponding to the player character ID 421 of the player character master data 404 described later. The world position information 317 is information indicating the position of the character operated by each player within the world map.

[0077] Returning to FIG. 23, the stage room management data 305 is a database for managing the stage rooms. FIG. 26 shows an example of the data configuration of the stage room management data 305. In FIG. 26, the stage room management data 305 includes stage room information 322 for each stage number 321 that identifies each stage. A plurality of pieces of stage room information 322 may be included for one stage. Each piece of stage room information 322 is information corresponding to the stage room. Each piece of stage room information 322 includes a stage room ID 323, stage entry player information 324, and the like. The stage room ID 323 is an ID for uniquely identifying the stage room. The stage entry player information 324 is information about a player currently entering the stage room. For example, the stage entry player information 324 stores information for identifying a player (player ID 308) and information indicating a selected character (player character ID 421).

[0078] Returning to FIG. 23, the replay management data 306 is a data structure in which replay data transmitted from the game device 3 is stored as described above. FIG. 27 shows an example of the data configuration of the replay management data 306. The replay management data 306 includes one or more replay data 332 for each stage number 331. Each replay data 332 includes at least a registration date and time 333, registered player information 334, used character ID 335, and replay content 336. The registration date and time 333 indicates the date and time when the replay data was registered in the game server 1. The registered player information 334 is information indicating the player who generated the replay data. The used character ID 335 is an ID for identifying the character used in the replay. The replay content 336 is data for indicating the content of the replay. For example, the replay content 336 is data in which information indicating the position information and state of the character related to the replay is arranged in chronological order and stored. The replay content 336 may also be, for example, key data. In other words, the replay content 336 may be any data content as long as it is data that allows the operation history of the player to be understood.

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

[0080] [Data used in game device 3] Next, a description will be given of data used in the game device 3. Fig. 28 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 401, world map master data 402, stage master data 403, player character master data 404, installation master data 405, other object data 406, message master data 407, world map management data 408, stage play management data 412, and operation data 418.

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

[0082] The world map master data 402 is the data on which the world map screen is based. It includes image data for each world map screen and configuration information for each world (such as the number of stages).

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

[0084] The player character master data 404 is data defining the above-mentioned 12 characters that can be selected as player characters. FIG. 29 shows an example of the data configuration of the player character master data 404. The player character master data 404 is data in a table format having at least a player character ID 421 and character appearance data 422. The player character ID 421 is an ID for uniquely identifying the 12 types of characters. In this example, it is a numerical value from "01" to "12". The character appearance data 422 is image data showing the appearance of each character. Although not shown, the character appearance data 422 may also include information defining the performance of each character.

[0085] Returning to FIG. 28, the installation master data 405 is master data of various installation objects that may appear in the play of the stage room. FIG. 30 shows an example of the data configuration of the installation master data 405. The installation master data 405 is data in a table format having at least an installation ID 431, a corresponding character ID 432, and installation appearance data 433. The installation ID 431 is an ID for identifying each installation object that may appear in the game. The corresponding character ID 432 and the installation appearance data 433 are data indicating the appearance prepared individually for each character for the installation object specified by the installation ID 431. The corresponding character ID 432 corresponds to the player character ID 421, and the installation appearance data 433 is image data of the appearance. In this example, the installation appearance data 433 corresponding to 12 characters is prepared for one installation ID 431. In the example of FIG. 30, for example, the installation object with installation ID 431 of "01" is the above-mentioned "panel." It is shown that different appearances are prepared for the installation object "panel" for each of 12 characters. Furthermore, when each character places a panel, they can only place a panel with an appearance that corresponds to themselves, and they cannot voluntarily place a panel for another character. For example, when character A places a panel, he cannot place a panel with an appearance that corresponds to character B or character C. Furthermore, although not shown in the figure, the installation master data 405 also includes data that defines the action and effect of each installation.

[0086] Returning to Fig. 28, the other object data 406 is data on various objects other than the player character and the installation object, such as enemy characters.

[0087] The message master data 407 is master data for various messages displayed during the game. For example, in the case of messages such as those shown in Figs. 21 and 22 above, character string data such as "ChrStr placed ItemStr" is defined in the message master data 407 in association with a message ID. Here, "ChrStr" and "ItemStr" are variables, and when actually displayed, the name of the character and the name of the installed object are substituted and displayed.

[0088] The world map management data 408 is management data used when the game device 3 executes processing of the world map screen. The world map management data 408 includes at least room status data 409, display target management data 410, and world map player character data 411. The room status data 409 is obtained by acquiring and storing the world room information 312 related to the world room to which the player has entered from the game server 1. The display target management data 410 is data used for display control of overlapping characters as described above. FIG. 31 shows an example of the display target management data 410. The display target management data 410 includes at least a world management player ID 441 and a display flag 442. The world management player ID 441 is data corresponding to the world player ID 315 in the world entry player information 314 included in the world room information 312 acquired from the game server 1. The display flag 442 is a flag indicating whether or not to display a character related to the player. If the display flag 442 is true, it is displayed, and if it is false, it is not displayed.

[0089] 28, the world map player character data 411 is information on the player character displayed on the world map screen, and includes the player character ID 421 of the character being used, position information on the world map, and the like.

[0090] Next, the stage play management data 412 is management data used when executing a process related to a stage play in the game device. The stage play management data 412 includes at least remote player data 413, replay ghost data 414, player actor management data 415, installation management data 416, and disguise list data 417.

[0091] The remote player data 413 is data for managing the remote player currently in the stage room. FIG. 32 shows an example of the data configuration of the remote player data 413. The remote player data 413 is data in a table format including items of remote player information 451 and actual selection ID 452. The remote player information 451 is information corresponding to the player ID 308 of the remote player. The actual selection ID 452 is the player character ID 421 of the actual selected character of the remote player. In other words, it indicates the player character ID 421 of any one of the above 12 characters selected by the remote player to be used as a player character.

[0092] Returning to FIG. 28, the replay ghost data 414 is the replay data 332 obtained from the game server 1 and stored.

[0093] The player actor management data 415 is data for managing local characters, remote characters, and replay ghosts that appear in stage play. FIG. 33 is a diagram showing an example of the data configuration of the player actor management data 415. The player actor management data 415 is data in a table format including at least the following items: actor frame number 461, allocation target 462, used character ID 463, and stage position information 464. As described above, the game has a maximum of four player actors, so the player actor management data 415 is also data for a maximum of four actors. The actor frame number 461 is a number (actor frame) for managing the four player actors. The allocation target 462 is data indicating a target to be assigned to the actor frame. In this example, information indicating any one of the players or the replay ghost is set. The used character ID 463 is the player character ID 421 of the character to be displayed as the player actor. If the actually selected character is not duplicated and not disguised, the player character ID 421 of the actually selected character is set. If the character is disguised due to duplication, the player character ID 421 of the disguised character is set. The stage position information 464 is information indicating the current position of each player actor within the stage. Although not shown in the figure, the player actor management data 415 may also include items indicating the "status" of each player actor.

[0094] Returning to FIG. 28, the installation management data 416 is data for managing the installation objects installed in the stage. FIG. 34 shows an example of the data configuration of the installation management data 416. The installation management data 416 is data in a table format including at least the items of an installation management number 471, installer information 472, installation identification information 473, and installation position 474. The installation management number 471 is a number for uniquely identifying an installation object placed in the stage. The installer information 472 is information indicating the player who installed the installation. The installation identification information 473 is information for identifying the installed installation object (the appearance of the object). In this example, it is identified by a combination of the installation ID 431 and the corresponding character ID 432 of the installation master data 405. The installation position 474 is information indicating the position in the stage where the installation object is installed.

[0095] 28, the disguise list data 417 is the data of the above-mentioned disguise list. That is, it is data in a list format in which the above-mentioned player character IDs 421 are arranged in a predetermined order.

[0096] The operation data 418 is data obtained from the controller 4 operated by the player. That is, it is data indicating the content of the operation performed by the player.

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

[0098] Next, details of the game processing in this embodiment will be described. Here, mainly, the processing related to the display control of overlapping characters as described above will be described, and detailed explanations of other game processing will be omitted. In addition, in this embodiment, the flowchart shown below is realized by one or more processors reading and executing the above program stored in one or more memories. Note that the flowchart shown below is merely an example of the processing process. Therefore, the processing order of each step may be changed as long as the same result is obtained. In addition, the values ​​of the variables and the threshold values ​​used in the determination step are merely examples, and other values ​​may be adopted as necessary.

[0099] [Details of Processing Executed by Processor 31 of Game Device 3] 35 and 36 are flowcharts showing details of the world map processing executed by the processor 31 of the game device 3. This processing is processing on the world map screen described above.

[0100] When a game is started by a player on game device 3, first, in step S1, processor 31 executes processing for entering a world room. In this processing, processing for connecting to game server 1 is performed, and then processing for allowing the player to select a character to be used as a player character is executed. Once the character to be used is selected, processing for determining the world room to enter (matching processing) is then executed. Then, processing for entering the determined world room, i.e., processing for establishing a session with a communication group corresponding to the world room, is executed.

[0101] Next, in step S2, processor 31 acquires world room information 312 related to the entered world room from game server 1, and stores it as room status data 409.

[0102] Next, in step S3, processor 31 executes processing for determining display targets for overlapping characters in the world room (display target determination processing). FIG. 37 is a flowchart showing details of the display target determination processing. In FIG. 37, first, in step S21, processor 31 lists player characters that overlap in the world room based on room status data 409. At this time, processor 31 excludes remote characters (abandoned characters) that have not been operated for a certain period of time or more from the targets of the listing. Therefore, as a result of the listing, a list that does not include abandoned characters is created.

[0103] Next, in step S22, processor 31 determines to hide player characters that overlap with local characters, that is, to preferentially display local characters.

[0104] Next, in step S23, if there is an overlapping character other than the local character, processor 31 determines, among the overlapping characters, the player's character that is closest to the local character as the preferential display target. At this time, as described above, for the currently displayed character, the distance to the local character on the world map is corrected to be shorter than the actual distance, and then the distance to the local character is determined.

[0105] Next, in step S24, processor 31 reflects the above-mentioned determination in display object management data 410. That is, among the players with overlapping characters, display flag 442 of the players who have not been determined as the preferential display object is set to false, and display flag 442 of the other players is set to true. At this time, processor 31 also sets the above-mentioned idle characters to be hidden. This ends the display object determination process.

[0106] Returning to FIG. 35, next, in step S4, processor 31 places the local character at a predetermined initial position in the world map. Then, processor 31 draws a world map screen based on display target management data 410. As a result, for overlapping characters, a world map screen is output in which only one of the characters is displayed. In addition, this screen becomes the world map screen in the state immediately after entering the world room.

[0107] Next, in step S5, the processor 31 acquires the world room information 312 from the game server 1, and stores it as room situation data 409. That is, the situation of the world room is updated to the latest information.

[0108] Next, in step S6, processor 31 determines whether or not an operation (stage-in operation) for instructing to start playing a predetermined stage has been performed based on operation data 418. If the result of this determination is that no operation has been performed (NO in step S6), processor 31 determines in step S7 whether or not the timing for executing the above-mentioned display object determination process has arrived. As described above, in this embodiment, the display object determination process is executed not in real time but every few seconds from the viewpoint of preventing the characters to be displayed from being switched frequently. Therefore, here, the timing is assumed to be every few seconds. Of course, the timing is arbitrary, and may be any timing as long as it is in line with the above viewpoint. If the result of this determination is that the timing for executing the display object determination process has arrived (YES in step S7), processor 31 executes the above-mentioned display object determination process in step S8. On the other hand, if the timing for executing the display object determination process has not arrived (NO in step S7), the process of step S8 is skipped.

[0109] Next, in step S9 of FIG. 36, processor 31 controls the movement of each player character within the world map, based on operation data 418 and room situation data 409.

[0110] Next, in step S10, processor 31 executes various game processes other than those described above as necessary.

[0111] Next, in step S11, processor 31 draws a world map screen based on display object management data 410.

[0112] Next, in step S12, processor 31 determines whether or not a condition for ending the game has been satisfied, and if not (NO in step S12), the process returns to step S5 and repeats the process, or if the condition has been satisfied (YES in step S12), the world map process ends.

[0113] Next, a process will be described when the result of the determination in step S6 above is that a stage-in operation has been performed. In this case, in step S13, processor 31 performs a process of leaving the world room.

[0114] Next, in step S14, processor 31 executes a stage play process. When the stage play process ends, the process returns to step S1 and the process is repeated.

[0115] Next, the details of the stage play process will be described. FIG. 38 and FIG. 39 are flow charts showing the details of the stage play process. First, in step S31, the processor 31 executes a process of entering a stage room. Specifically, the processor 31 first requests a matching process to the game server 1. Then, the processor 31 executes a process of entering a stage room determined based on the matching result. At this time, when entering an existing room, various information indicating the status of the room is received from one of the game devices 3 related to the players who have entered the room. For example, information such as information on the remote players who have entered the room and the placed object objects is received. Then, based on the received information, the remote player data 413, the player actor management data 415, and the installed object management data 416 are appropriately generated. In addition, the processor 31 also transmits information on the character that the processor 3 uses as a player character to the game device 3 related to the player who has entered the room. Note that, when entering a new room instead of an existing room, the reception of various information indicating the status of the room and the generation process based on the received information are not required.

[0116] Next, in step S32, processor 31 executes a character disguise determination process. FIG. 40 is a flowchart showing the details of the process. First, in step S51, processor 31 determines whether or not there is a player whose actual selected character is the same as the player who has newly entered the stage room. When the local player newly enters the stage room, the "player who has newly entered the stage room" corresponds to the local player. Also, when a remote player newly enters the stage room after the local player has entered, the remote player corresponds. As a result of the determination, when there is a player whose actual selected character is the same as the player who has newly entered the stage room (YES in step S51), in step S52, processor 31 determines a character to be disguised based on the disguise list as described above. That is, processor 31 searches the list in order from the character that is the starting point, and searches for a character that does not overlap with an existing player character existing in the stage room. Then, the processor 31 determines the first non-overlapping character found as the disguise destination, and updates the player actor management data 415 based on the determination. Specifically, when the local player newly enters the stage room, the processor 31 performs disguise setting for data related to the remote player who entered the room earlier. Specifically, the processor 31 sets the player character ID 421 determined as the disguise destination to the used character ID 463 of the player actor management data 415 corresponding to the remote player whose actual selected character is the same as that of the local player. In addition, when there are multiple remote players whose actual selected character is the same as that of the local player, the processor 31 determines the disguise destination so that the characters do not overlap among the remote players. In addition, when a new remote player enters the room, the processor 31 sets the player character ID 421 determined as the disguise destination to the used character ID 463 of the player actor management data 415 corresponding to the newly entered remote player. In other words, the processor 31 disguises the operated character of the remote player who entered later.

[0117] When a new remote player enters the room, the destination to impersonate may be determined by taking into consideration not only existing player characters but also existing installed objects. Alternatively, the destination to impersonate may be determined so as to avoid overlap with existing player characters without taking into consideration existing installed objects.

[0118] On the other hand, if the result of the above determination is that there is no player whose actual selected character is the same as the player who has just entered the stage room (NO in step S51), the process of step S52 is skipped. This is the end of the character disguise determination process.

[0119] Returning to FIG. 38, next, in step S33, processor 31 executes an installation object disguise process. FIG. 41 is a flowchart showing details of the process. In FIG. 41, in step S61, processor 31 determines whether an installation object corresponding to a local character exists in the stage room. If the result of the determination is that the installation object exists (YES in step S61), in step S62, processor 31 uses the above-mentioned disguise list to determine the disguise destination of the character corresponding to the existing installation. Then, based on the determination content, an image of the installation object to be the disguise destination is determined, and installation object management data 416 is updated. Specifically, based on the player character ID 421 of the disguise destination, the content of installation object identification information 473 (combination of installation object ID 431 and corresponding character ID 432) for the corresponding installation object in installation object management data 416 is updated. For example, when a panel corresponding to character A is disguised as a panel corresponding to character C, the content of installation object identification information 473 is updated from "01-01" to "01-03". This makes it possible to determine the installation object appearance data 433 to be used for camouflage.

[0120] On the other hand, if the installation object corresponding to the local character does not exist in the stage room (NO in step S61), the process of step S62 is skipped. This is the end of the installation disguise process.

[0121] Returning to FIG. 38, next, in step S34, processor 31 renders game images relating to stage play based on player actor management data 415 and installation management data 416. As a result, the image of each player actor is displayed as the image of the character specified by used character ID 463 of player actor management data 415. As described above, when no disguise is performed, the ID of the actually selected character is set in used character ID 463, and when disguise is performed, the ID of the disguised character is set. Also, for images of existing installation objects, images are rendered using installation appearance data 433 specified by installation specification information 473 of installation management data 416. Here too, when disguise is performed, installation appearance data 433 corresponding to the disguised character is used.

[0122] Next, in step S35, processor 31 executes an entry / exit check process. This is a process for checking entry / exit of other players after the local player enters the room. FIGS. 42 to 43 are flowcharts showing details of the entry / exit check process. First, in step S71, processor 31 determines whether or not a new remote player has entered the room. If the result of this determination is that there is no new player entering the room (NO in step S71), processor 31 proceeds to the process in step S78 described below. On the other hand, if a new remote player has entered the room (YES in step S71), then processor 31 determines in step S72 whether or not the number of players in the room has reached four. If the result of this determination is that the number of players has not reached four (NO in step S72), the process proceeds to step S75 described below. On the other hand, if the number of players has reached four (YES in step S72), in step S73, processor 31 refers to player actor management data 415 and determines whether or not there is an empty slot for a player actor. If the result of this determination is that there is no empty slot (NO in step S73), it is considered that three replay ghosts exist. Therefore, in step S74, processor 31 deletes the replay ghost that is farthest from the local character. That is, data relating to this replay ghost is deleted from replay ghost data 414 and player actor management data 415. Then, the process proceeds to step S75. 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 S73), the process of step S74 is skipped.

[0123] Next, in step S75, processor 31 updates remote player data 413 based on the information received from the game device of the remote player who has joined the room. Processor 31 also updates player actor management data 415 based on the information. Therefore, at this point in time, an ID identifying the actual selected character selected by the remote player is registered in used character ID 463.

[0124] Next, in step S76, processor 31 executes a character disguise determination process. This process is similar to the process of step S32 described above, and therefore detailed description will be omitted, but this process determines whether or not disguise is required for a remote player who has newly entered the room. That is, if the actual selected character of the newly entered remote player overlaps with an existing remote character or replay ghost in the stage room, settings are made to disguise the remote character of the remote player. Specifically, as this setting, player actor management data 415 is updated as described above.

[0125] Next, in step S77, processor 31, based on player / actor management data 415, places a remote character corresponding to the player who has entered the room.

[0126] Next, in step S78 of FIG. 43, processor 31 determines whether or not any remote player has left the room. In addition, processor 31 also determines whether or not playback of a replay ghost that exists at that time has ended. If the result of the determination is that a remote player has left the room or playback of a replay ghost has ended (YES in step S78), in step S79, processor 31 deletes data of the remote character related to the player who has left the room from player actor management data 415. Alternatively, processor 31 deletes data of a replay ghost whose playback has ended from player actor management data 415.

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

[0128] Returning to FIG. 38, next, in step S36, processor 31 determines whether or not the condition for making a replay ghost appear has been satisfied. In this example, when the local player is the only one in the stage room and has progressed to the midpoint as described above, the condition is determined to be satisfied. If the result of the determination is that the condition is not satisfied (NO in step S36), processing proceeds to step S38, which will be described later. On the other hand, if the condition is satisfied (YES in step S36), in step S37, processor 31 executes ghost placement processing.

[0129] 44 is a flowchart showing details of the ghost placement process. First, in step S81, processor 31 acquires replay data relating to the stage currently being played from game server 1. The acquired replay data may contain any content, but for example, replay data randomly selected by game server 1 is acquired. Here, it is assumed that replay data for three bodies is acquired. Then, processor 31 registers information about the replay ghosts in player actor management data 415 based on the replay data.

[0130] Next, in step S82, processor 31 executes the character disguise determination process. In this process, the acquired replay data is regarded as a remote player who has newly entered the room, and the character disguise determination process is executed. Therefore, if the character used in the acquired replay data is the same as the local character, settings are made to cause a disguised replay ghost to appear.

[0131] Next, in step S83, processor 31 places the replay ghost on the stage based on player actor management data 415. Then, processor 31 starts playing the replay. This causes the replay ghost to appear on the stage. This ends the ghost placement process.

[0132] Next, in step S38 of FIG. 39, processor 31 receives other-apparatus status data indicating the operation contents of the remote player from other game apparatuses 3 in the same stage room. Next, in step S39, processor 31 determines whether or not any of the players has performed an operation to install an installation object based on operation data 418 and the other-apparatus status data received from the other game apparatuses. If the result of the determination is that an installation operation has been performed (YES in step S39), processor 31 executes installation processing in step S40. FIG. 45 is a flowchart showing details of the installation processing. In FIG. 45, first, in step S91, processor 31 acquires used character ID 463 of player actor management data 415 corresponding to the player who performed the installation operation. Next, in step S92, processor 31 determines the contents of installed object identification information 473 in installed object management data 416 based on installed object ID 431 indicating the installed object related to the installation operation and the acquired used character ID 463. Then, processor 31 updates installation object management data 416 using the determined content of installation object specification information 473 and the newly specified placement position information. As a result, when a disguised character installs an installation object, an installation object corresponding to the disguised character is installed. This is the end of the installation process.

[0133] Returning to FIG. 39, if the result of the determination in step S39 above is that the installation operation has not been performed (NO in step S39), the process in step S40 above is skipped.

[0134] Next, in step S41, processor 31 controls the movement of each player actor based on operation data 418, other machine status data, and replay data. Next, in step S42, processor 31 performs various other game processes. Specifically, collision determination of various objects and processing based on the determination results are performed. As part of these processes, processing is also performed to appropriately display the above-mentioned message based on message master data 407. At this time, if a character name is used in the message, the character name to be used is determined based on used character ID 463 of player actor management data 415. Therefore, the message is displayed reflecting the disguised content of the character.

[0135] Next, in step S43, processor 31 performs a drawing process of a game image based on player actor management data 415, installation object management data 416, and the results of the various game processes described above.

[0136] Next, in step S44, processor 31 determines whether or not the local character has cleared the stage. If the result of this determination is that the stage has not yet been cleared (NO in step S44), the process returns to step S35 and the process is repeated. On the other hand, if the stage has been cleared (YES in step S44), in step S45, processor 31 executes various processes associated with clearing the stage, and then executes a process to exit the stage room. Then, the stage process ends.

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

[0138] [Game Server 1 Processing] Next, the details of the processing executed by the game server 1 will be described. FIG. 46 is a flowchart showing the details of the processing related to the game server 1. In FIG. 46, first, in step S101, processor 11 of game server 1 executes matching processing. In this processing, in response to a matching request for a world room or stage room from a predetermined game device, matching between players, that is, processing for determining the world room or stage room to which each player will enter, is executed. In addition, processing for transmitting the result to game device 3 is also executed.

[0139] Next, in step S102, processor 11 performs processing for managing the world rooms and the stage rooms. In this processing, processing for managing each room, such as processing for creating a new room, processing for compensating for a player, and processing for deleting a room where no players remain, is performed.

[0140] Next, in step S103, processor 11 performs a process of managing the replay data. In this process, registration and updating of replay management data 306 is performed based on the replay data received from each game device 3. In addition, a process of transmitting replay data in response to a request from a game device 3 is also appropriately performed.

[0141] Then, the processor 11 returns to step S101 and repeats the process. This concludes the detailed description of the process related to the game server 1.

[0142] In this embodiment, in a multiplayer game in which a player selects a character to be used from a plurality of characters, two or more characters of the same type are not displayed. In the world map screen, when the character selected by the player overlaps with the character selected by another player, the character of the other player is not displayed. In addition, in the stage play, when the selected characters overlap, the characters operated by the other players are disguised as characters other than the selected characters, so that the same characters are not displayed in the stage. This makes it easier for the player to distinguish the characters operated by the player himself. In particular, in the stage play, the characters operated by the player himself are easier to distinguish, so that the play of each player is not hindered by the display of the same characters. In addition, since it is not necessary to consider whether the selected characters overlap when matching, there is no waiting for matching due to the selected characters overlapping.

[0143] [Variations] In the above embodiment, an example was described in which one of the 12 characters was selected as the character to be operated. Then, when deciding the disguise destination, an example was shown in which the character was selected from these 12 characters. In this regard, in another embodiment, the 12 characters may be further classified into a plurality of types, and when deciding the disguise destination, the character may be selected from the same type. For example, of the 12 characters, 6 are designed and classified as "human type" characters and 6 are "animal type" characters. Also, it is assumed that there is a difference in the performance (e.g., jumping power) of the characters between the human type characters and the animal type characters. In such a case, when deciding the disguise destination in the above process, if the actual selected character is a "human type", the disguise destination may also be selected from the "human type" characters, and if the actual selected character is an "animal type", the disguise destination may also be selected from the "animal type" characters. This makes it less likely that a sense of incongruity will occur when watching the movement of the disguised character when there is a difference in the performance of the characters for each type as described above.

[0144] Also, a game mode in which the display control as described above is performed and a game mode in which the display control is not performed may be used separately. For example, in the case of a game mode in which a multiplay is performed by matching with an unspecified number of players as described above, the display control such as disguise as described above is performed. On the other hand, the game mode in which the display control is not performed may include the following game modes. For example, instead of matching with an unspecified number of players as described above, a game mode in which a multiplay is performed by joining a communication group in which only specific players such as so-called "friends" gather. Also, for example, a game mode (local multiplay) in which a multiplay is performed by multiple players using multiple controllers on one game device without using a network may be included. In such a game mode, at the time of selecting a character, control may be performed so that the same character cannot be selected, and the processing related to the display control described above may not be performed. In this case, it is considered that direct communication between players can be achieved before starting to play the game, and it is also considered that the characters used by each player can be directly adjusted between the players. [Explanation of symbols]

[0145] 1 Game Server 3. Information processing terminal (game device) 4. Controller 5 Display section 11 Processors 12 Storage section 31 Processors 32 Storage section

Claims

1. a computer of the first game device; Selecting one character type from among a plurality of character types based on an operational input; placing a first type of character on a game stage based on the selected type of character; receiving first character information indicating a type of the character from a second game device; When the first character information and the first type of character are the same type, a second type of character different from the first type is placed; receiving second character information indicating a type of the character from a third game device; A game program that places a third type of character different from the second type when the second character information is received after the first character information and when the second character information and the second type of character are the same type.

2. placing the second type of character at a first timing; The game program according to claim 1 , wherein the third type of character is placed at a second timing that is later than the first timing.

3. The computer further comprises: acquires, from a predetermined server, replay data including at least information indicating an operation history of a predetermined user and characters used in the operation; 2. The game program according to claim 1, wherein, in the first game device, if the type of character used indicated in the replay data is the same type as the first type of character, a second type of character different from the first type is placed as a replay character whose movement is controlled based on the replay data.

4. an installation object having an appearance corresponding to each of the types of the plurality of characters; placing at least one of the first, second, and third types of characters at a predetermined position within the game space based on a predetermined operation; in the first game device, when the character that placed the installation object is the second or third type of character, placing an installation object having an appearance corresponding to the placed second or third type of character; The game program according to claim 1 .

5. The computer further comprises: During play of a multiplayer game between users of a plurality of game devices matched via a network, a message corresponding to a predetermined character is displayed in accordance with the action of the character; 2. The game program according to claim 1, wherein, in the first game device, if a character that has performed an action for which a predetermined message is displayed is a character of the second or third type, a message corresponding to the character of the second or third type is displayed.

6. A gaming system having at least a first gaming device, a second gaming device, and a third gaming device, The computer of the first game device Select one character type from among a plurality of character types based on operational input; placing a first type of character on the game stage based on the selected type of character; receiving first character information indicating the type of the character from a second game device; When the first character information and the first type of character are the same type, a second type of character different from the first type is arranged; receiving second character information indicating the type of the character from a third game device; When the second character information is received after the first character information and the second character information and the second type of character are the same type, a third type of character different from the second type is arranged. Game system.

7. a computer of the first game device; Selecting one character type from among a plurality of character types based on an operational input; placing a first type of character on a game stage based on the selected type of character; receiving first character information indicating a type of the character from a second game device; When the first character information and the first type of character are the same type, a second type of character different from the first type is placed; receiving second character information indicating a type of the character from a third game device; When the second character information is received after the first character information and the second character information and the second type of character are the same type, a third type of character different from the second type is placed. Game processing method.

Images