JP7653036B2 - Information processing device, information processing method, and program - Google Patents

Description

The present invention relates to an information processing device, an information processing method, and a program.

In games played by multiple players together, each player is assigned a role in the game, and the assigned role of each player may be changed during game play (see, for example, Patent Document 1). Patent Document 1 describes how, in order to improve game playability, the role of each player is changed during game play depending on the progress of in-game missions.

JP 2014-124489 A

When playing a game cooperatively, it is expected that if players with different roles can cooperate with each other, cooperative play can be encouraged (stimulated).

In view of the above, the present invention aims to provide an information processing device, an information processing method, and a program that can encourage cooperative play by multiple players in a game in which roles are assigned to each player.

An information processing device according to one aspect of the present invention is characterized by having a role setting unit that sets a role to be played by each of a plurality of players who play a game together during game play, and a role swapping unit that swaps the role of the first player with the role of the second player when a predetermined condition is met while a first player and a second player, to whom different roles have been set, are playing a game together.

According to one aspect of the present invention, in cooperative play of a game, when a predetermined condition is met, the first player and the second player can switch roles, allowing players with different roles to cooperate with each other, thereby encouraging cooperative play of the game.

FIG. 2 is a diagram showing an example of a playable area in a game. 13 is an example of a play screen displayed when playing a game in a first role. 13 is an example of a play screen displayed when playing the game in a second role. FIG. 13 is an explanatory diagram of a plugging operation. 13A and 13B are diagrams showing an example of a change request screen (left diagram) and an inquiry screen (right diagram). FIG. 13 illustrates an example of a return instruction screen. 1 is a conceptual diagram showing a configuration of an information processing system including an information processing device according to a first embodiment of the present invention. FIG. 2 is a diagram showing functions of the information processing device according to the first embodiment of the present invention. FIG. 11 is a diagram showing an example of player information. FIG. 13 is a diagram showing a role setting flow. FIG. 13 shows screen transitions before game play begins. FIG. 11 is a diagram showing a first screen display flow. FIG. 11 is a diagram showing a flow of a second screen display flow. FIG. 11 is a diagram showing a flow of a role exchange flow according to the first embodiment. FIG. 11 is a diagram showing a flow of a role switching flow according to the second embodiment. FIG. 13 is a diagram showing a procedure for switching roles in the third embodiment. FIG. 13 is a diagram illustrating functions of an information processing device according to a fourth embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An information processing device, an information processing method, and a program according to the present invention will now be described with reference to the accompanying drawings in relation to a number of preferred embodiments (referred to as first to fourth embodiments).
The embodiment described below is merely one of the specific examples given to facilitate understanding of the present invention, and is not intended to limit the present invention. In other words, the present invention may be modified or improved from the embodiment described below without departing from the spirit of the present invention. In addition, the present invention naturally includes its equivalents.
In addition, the screen examples shown in the drawings referenced in the following description are merely examples, and the screen configuration examples, the content of the information displayed, and the GUI (Graphical User Interface), etc. can be freely designed according to the content of the information processing, the design specifications of the system, and the preferences of the player, and can be changed as appropriate.

[Games that can be played with this invention]
A game that can be played through the information processing device of the present invention (hereinafter simply referred to as a "game") will be described with reference to Figures 1 to 4. Figure 1 is a diagram showing an example of an area that can be played in the game, and more specifically, shows an overall image of the area. Figures 2 and 3 are examples of play screens for the game. Figure 4 is an explanatory diagram of an input operation, which will be described later.

A game is content that a player plays while viewing a screen on a gameplay control terminal, and more specifically, is an online game that uses data communication. Online games include browser games that use a web browser, social games provided on SNS (Social Networking Service), games that can be played by downloading dedicated application software such as mobile games, and regularly updated online games such as play-by-web (PBW). There are no particular limitations on the genre (classification) of games.

Players can choose to play the game in either a single-player mode or a simultaneous play mode (multiplayer mode) with multiple players.

A player who selects the single play mode operates a specific in-game character (hereinafter referred to as a field-moving character J1) during game play. The field-moving character J1 corresponds to the first in-game character, and moves on a field set within the area shown in FIG. 1 based on the player's operation (hereinafter referred to as a movement operation). A game area is an in-game space set for the purpose of clearing it, and there may be one or more of these in the game. A field is a terrain set for each area, and is, for example, a two-dimensional area such as a floor, ground, or water surface.

The appearance (display image) of the field moving character J1 can be set arbitrarily depending on the content of the game, but in the following explanation, it will be assumed to be humanoid as shown in Figures 1 and 2. Also, the number of field moving characters J1 that can be operated by one player may be one or two or more, but in the following explanation, it will be assumed to be one.

As shown in FIG. 1, enemy characters E appear on the field, and auxiliary objects H are arranged according to certain rules or irregularly. The enemy characters E appear on the field as spawn characters and interfere with the player's gameplay (specifically, the movement and other actions of the field-moving character J1). The auxiliary objects H are used by the player during gameplay, and the effects of the auxiliary objects H are imparted to the player when, for example, the field-moving character J1 approaches or comes into contact with the auxiliary objects H. The effects of the auxiliary objects H include, for example, the impartation of benefits or items that can be used in the game, parameter changes such as the recovery of physical strength, changes to the field situation such as a reduction in the number of enemy characters E appearing on the field, and the occurrence of a predetermined event such as the appearance of a boss enemy.

In the single play mode, the player performs a movement operation (corresponding to a first operation) on the field moving character J1 while viewing the field moving character J1 on the game play screen. At this time, the play screen shows a portion of the field as shown in FIG. 2, specifically a certain range including the current position of the field moving character J1 (the area surrounded by a dashed line in FIG. 1).

As an example of a movement operation, as shown in FIG. 2, an operation of touching the field moving character J1 displayed on the screen and dragging it to the destination (the position indicated by the dashed line in FIG. 2) is given. The method of performing the movement operation is not particularly limited, but examples include a method using the directional keys of a controller (not shown), a method using voice input, or a method analyzing the brain waves of the player during game play.

When the field-moving character J1 moves on the field in response to a movement operation, the part of the field displayed on the screen changes accordingly. The player can grasp the current position of the field-moving character J1 (the position after the movement) through the screen after the change.

Note that the screen shown in FIG. 2 is a screen when a portion of the field is viewed from directly above, but is not limited to this. The screen displayed during game play may be a screen when a portion of the field is viewed from any line of sight (view angle), and the angle may be changeable as desired by the player during game play.

In the game, parameters are set for the field-moving character J1. Parameters are values or status that the player monitors (checks) and manages while playing the game, and include, for example, values indicating the state (current state) of the field-moving character J1, such as its stamina and hunger level, values indicating its abilities, such as its attack power and movement speed, its type and attributes, its screen display size, and other characteristics.

During game play, the parameters change (are updated) in conjunction with the progress of the game, specifically, the movements and state changes of the field-moving character J1. For example, when the field-moving character J1 moves on the field or is affected by an enemy character E on the field (specifically, an attack or obstruction), one of the parameters, stamina, decreases. Then, when the field-moving character J1's state reaches 0 (zero) stamina (which corresponds to an example of a predetermined state), play cannot continue, i.e., the game is over.

In addition, the parameters can be changed by utilizing an auxiliary object H placed on the field, or an input object T (described below) that is inserted onto the field. For example, when an auxiliary object H or an input object T that corresponds to a stamina recovery item is used, the stamina of the field-moving character J1 can be increased (recovered).
It should be noted that the parameters do not necessarily have to be changed in conjunction with the movement of the field-moving character J1, and may be changed, for example, in response to the content of the operation (movement operation, etc.) of the player controlling the field-moving character J1.

The player can clear an area when the clearing conditions for that area are met, such as when the field-moving character J1 reaches a specific position on the field or when a specific enemy character E that appears on the field is defeated. In addition, the player can move on to the next area by clearing an area, and move the field-moving character J1 on the field set in the area after the move.

Next, we will explain the multiplayer mode. In the multiplayer mode, multiple players can play together in the same area at the same time (i.e., at the same time). Here, "cooperative play" means that players cooperate with each other to play with the common goal of clearing the area.

In multi-play mode, each of multiple players playing together selects a role before the start of the joint play. A role is a game role that each of multiple players playing together takes on, and in the present invention, each player selects either a "first role" or a "second role" before the start of the joint play. Note that "before the start of the joint play" refers to a point in time before multiple players start playing in an area of the game, specifically, before they start operating the field moving character J1 or the support character J2 described below.

After each player selects a role, the role of each player is set according to the selection result of each player, and joint play begins. In joint play, each player plays the game in the role that has been set. Specifically, the first role is the role of operating the above-mentioned field-moving character J1 to progress the game. During joint play, a part of the field corresponding to the current position of the field-moving character J1 is displayed on the play screen (hereinafter also referred to as the first screen G1) of the player set to the first role (see FIG. 2). While looking at the first screen G1, the player set to the first role performs a movement operation as a first operation on the field-moving character J1.

The second role is a role that assists (supports) the player set to the first role during cooperative play. Assisting the player set to the first role means playing the game from a different perspective than the player set to the first role, specifically, playing the game in a way that gives the player set to the first role an advantage in the game.

To explain the second role in more detail, during cooperative play, a player set to the second role operates a support character J2 different from the field-moving character J1 while viewing the game play screen (hereinafter also referred to as the second screen G2). The support character J2 corresponds to a second in-game character, and is based on an air vehicle such as a UAV (Unmanned Aerial Vehicle). The number of support characters J2 that can be operated by one player set to the second role may be one or more than two, but in the following explanation, it will be assumed that there is one.

During cooperative play, the play screen of the player assigned to the second role, i.e., the second screen G2, displays an overhead view of the area of the field corresponding to the position of the support character J2, as shown in FIG. 3. The player assigned to the second role performs operations (hereinafter referred to as flight operations) on the support character J2 while watching the screen. The flight operations correspond to the second operations.

As an example of a flight operation, as shown in FIG. 3, an operation of touching the support character J2 displayed on the screen and dragging it to a destination is given. The method of performing the flight operation is not particularly limited, but examples include a method using the directional keys of a controller (not shown), a method using voice input, or a method analyzing the brain waves of the player during game play.

The support character J2 moves (flies) within the area where the field-moving character J1 exists based on flight operations. More specifically, the field-moving character J1 and the support character J2 exist in different hierarchical levels (layers) in the same area. The hierarchical level to which the support character J2 can move is higher than the hierarchical level to which the field-moving character J1 can move, and is strictly speaking located in the space above the field virtually set in the game (i.e., above the field). Therefore, the support character J2 can move throughout the entire range of the field, and can move freely even in areas of the field where the field-moving character J1 cannot move. For example, the field-moving character J1 cannot move in areas of the field where obstacles are placed due to restrictions such as obstacles, whereas the support character J2 is not restricted in movement by the obstacles.

When the support character J2 flies above the field in response to flight operations, the portion of the field displayed on the second screen G2 changes accordingly. This allows the player set to the second role to grasp the current position (position after movement) of the support character J2 through the second screen G2 after switching. Also, the player set to the second role can check the movement of the field-moving character J1 while the field-moving character J1 is displayed on the second screen G2. This allows the player set to the second role to watch (spectate) the play by the player set to the first role during cooperative play.

Note that the second screen G2 shown in FIG. 3 is a screen when a portion of the field is viewed from directly above, but is not limited to this. The second screen G2 may be a screen when a portion of the field is viewed from any line of sight (view angle), and the angle may be able to be changed at will during game play according to the preferences of the player assigned to the second role.

The second screen G2 may show a portion of the field or the entire field. For example, when a player set to the second role performs an operation for enlarging the display, a portion of the field may be enlarged and displayed on the screen at a magnification corresponding to the amount of operation. Conversely, when an operation for reducing the display is performed, a portion or the entire field may be reduced and displayed on the screen according to the amount of operation.

As described above, the player set to the second role can use flying operations to move (fly) the support character J2 above the field, thereby checking each area of the field through the second screen G2 and, for example, finding the location on the field where the field-moving character J1 is located.

On the other hand, the support character J2 cannot attack the enemy character E on the field, and cannot be affected by the enemy character E (specifically, attacks, interference, etc.). Furthermore, the support character J2 cannot use the auxiliary object H or the input object T. In other words, the player set to the second role cannot enjoy the effects of the auxiliary object H and the input object T. Instead, the player set to the second role can perform an operation (hereinafter referred to as an input operation) to input the input object T onto the field as a support item for the player set to the first role during cooperative play.

The throw-in operation is performed through the second screen G2 as shown in Fig. 4. Specifically, the player set to the second role selects one of the objects possessed in the game, and clicks the object selection button corresponding to the type of the selected object among the object selection buttons displayed on the screen as shown in the left diagram of Fig. 4. The player set to the second role then specifies the placement position of the throw-in object T on the field. By performing the throw-in operation in this manner, the throw-in object T is thrown from the support character J2 onto the field as shown in the right diagram of Fig. 4. As described above, the throw-in object T is used by the player set to the first role, and is used when the field moving character J1 operated by that player approaches the throw-in object T.
In addition, the object used as the throw-in object T and the position of the throw-in object T are not limited to being determined based on the will of the player assigned to the second role, but may be determined automatically, for example, by lottery.

Furthermore, the player set to the second role can purchase objects that can be used as input objects T at an in-game shop or the like during game play, and can input the purchased objects onto the field as input objects T. Objects are purchased using currency possessed by the player in the game (in-game currency), i.e., by consuming in-game currency.
Note that objects that can be used as the investment object T may be acquired by means of methods other than purchase, for example, by playing a lottery event held within the game.

In a cooperative play, when a player set to the first role uses an input object T, the player is given an effect according to the input object T. The effect according to the input object T varies depending on the type of the input object T, and the content of the effect (i.e., the type of object) can be arbitrarily determined depending on the content of the game.
In addition, the thrown-in objects T may include objects that hinder the play of the player set to the first role, in addition to objects that assist the player set to the first role.

As described above, when playing together in multi-play mode, each of the multiple players plays the game in either the first role or the second role, and controls one of the in-game characters corresponding to the role, i.e., the field moving character J1 or the support character J2.

In the multiplayer mode, multiple players can select the first role and play the game. In this case, a field moving character J1 exists on the field for each player set to the first role, and each player set to the first role operates their own field moving character J1. At this time, multiple players set to the first role may cooperate to clear the same area, may compete with each other in the same area, or may be divided into multiple teams and play against each other in the same area.

In addition, in the multiplayer mode, when multiple players select the first role and one or more players select the second role, during gameplay, the player set to the second role will assist a designated player among the multiple players set to the first role, and will play cooperatively with the player to be supported. The player to be supported may be designated before cooperative play begins, or may be designated during cooperative play. The player to be supported may be selected randomly from among the multiple players set to the first role, or by lottery, regardless of the intention of the player participating in the second role.

In addition, in the multiplayer mode, a minimum required number of players (lower limit) who play the game in the first role is determined, and cooperative play can be started only when the number of players who have selected the first role is equal to or greater than the lower limit.
On the other hand, there is no minimum limit on the number of players playing the game in the second role, and as long as the number of players selecting the first role is equal to or greater than the minimum limit, a cooperative play can be started even if the number of players selecting the second role is any number, for example, 0. However, this is not limited to this, and a minimum required number (minimum number) may also be determined for the number of players playing the game in the second role.
In addition, for each of the first role and the second role, the maximum number (upper limit) of players who can play simultaneously in one collaborative play is not particularly limited, but may be set to a number based on the game specifications, for example.

[Regarding the first embodiment]
In the present invention, during cooperative play, when a predetermined condition (hereinafter, "switching condition") is met, the roles can be switched between a player set to a first role and a player set to a second role.
Hereinafter, the switching of roles between players according to the first embodiment of the present invention will be described with reference to FIG.

In the following, among multiple players playing together, a player who is set to either the first role or the second role will be called the first player, and a player who has a different role from the first player will be called the second player.

The first player and the second player play together with different roles, but in the following explanation, we assume that the role of the first player is set to the first role (operating a field-moving character J1) and the role of the second player is set to the second role (operating a support character J2).
However, the contents described below may also be applied to the opposite case, that is, the role of the first player is set to the second role and the second player is set to the first role.

From the start of cooperative play of the game until the switching conditions are met, the first player performs movement operations on the field-moving character J1, and the second player performs flying operations on the support character J2. In addition, when the switching conditions are met during cooperative play, the roles can be swapped between one first player and one second player.

In the first embodiment, a change request by one player can trigger a switch between players. Specifically, each player playing cooperatively can make a change request operation while playing the game. The change request operation is performed through a change request screen shown in the left diagram of FIG. 5. On the change request screen, players playing cooperatively in roles different from the player's own are displayed as candidates for role swapping partners. A player making a change request operation specifies one of the candidate players displayed on the change request screen through the change request screen. For example, when a player set to the first role makes a change request operation, he or she specifies one of the players set to the second role.

When a first player performs a change request operation, if a player with a different role than the first player (i.e., a player set to the second role) has not performed a change request operation at that time, a second player is selected from among the second players based on the designation of the first player. Here, selecting a second player based on the designation of the first player in the change request operation corresponds to selecting a second player according to a predetermined criterion.

On the other hand, if the selected second player accepts the role change requested by the first player, he or she performs an acceptance operation for that role. The acceptance operation is performed through the inquiry screen shown in the right diagram of FIG. 5, and specifically, corresponds to the operation of clicking the acceptance button (button marked "Yes") on the screen. Conversely, if the selected second player declines the role change, he or she clicks the rejection button (button marked "No") on the screen.

When a change request operation is received from one first player and an acceptance operation is received from a second player designated by the first player, a switching condition is met, and the first and second players switch roles as a result of the condition being met. As a result of the role switching, in the subsequent joint play, the first player who made the change request operation plays the second role and performs flying operations on the support character J2, and the second player who made the acceptance operation plays the first role and performs movement operations on the field-moving character J1. In other words, as a result of the role switching, the field-moving character J1, which had been operated by the first player, is now operated by the second player, and the support character J2, which had been operated by the second player, is now operated by the first player.

As described above, when the switching condition is met, players (the first player and the second player) who have been assigned different roles can switch roles. This allows the first player and the second player to cooperate (cooperate) during game play, and, for example, in a situation where it becomes difficult for the first player to perform a movement operation on the field-moving character J1, the first player can perform the movement operation on behalf of the second player. As a result, cooperative play of the game can be promoted, leading to the revitalization of the game (specifically, an increase in the number of players of the game).

In the above case, the first player makes a change request operation and the second player designated by the change request operation makes an acceptance operation, but this is not limited to the above. In other words, the second player may make a change request operation and the first player designated by the second player at the time of the change request operation may make an acceptance operation. In this case, a switching condition is met by accepting operations from both players, and the roles of the first player and second player may be switched in response to the condition being met.

In the above case, a second player whose role will be swapped with the first player is selected from among players (i.e., second players) who have a different role from the first player based on the designation result of the first player, but this is not limited to the above. There are other criteria (corresponding to predetermined criteria) for selecting a second player. For example, a second player designated by the first player before the start of cooperative play (e.g., a second player designated as a support target) may be registered in advance, and the second player may be selected as the role swap partner. Also, a second player selected randomly or by lottery or the like may be selected as the role swap partner.

In the first embodiment, if a return condition is met after the first player and second player switch roles, the first player's role and the second player's role can be returned to the roles before the switch (returned to their original roles). An example of a return condition is that the first player or the second player performs a return operation after the role switch and the return operation is accepted. The return operation is performed through the return instruction screen shown in FIG. 6, and specifically corresponds to the operation of clicking the return instruction button (the button marked "Yes") on the screen.

Other examples of return conditions include the passage of a certain amount of time after the first player's role is swapped with the second player's role, or the first and second players clearing the area in which they were playing at the time of the role swap.

In the first embodiment, while the roles of the first player and the second player are being swapped (while their roles are being changed from their original roles), the swapping of the swapped roles of the first player and the second player with the roles of other players is restricted. The other players are players who play together with the first player and the second player whose roles have been swapped, i.e., the first player and the second player whose roles have not yet been swapped.

[Regarding the information processing device of the first embodiment and the operation terminal of each player]
Next, the information processing device according to the first embodiment and the operation terminal of each player will be described. In the following, a scene will be described in which four players A to D play together in the same area in multiplay mode. Among them, players A and C are set to a first role at the start of the joint play, and players B and D are set to a second role at the start of the joint play.
It should be noted that the contents described below can be broadly applied to cases in which a first player and a second player play together, including the above case.

Each player has an operation terminal 11-14 for the game. Each operation terminal 11-14 is a client terminal, and specifically, is composed of a personal computer, a smartphone, a mobile phone, a tablet terminal, a game machine, a television receiver capable of inputting information, a wearable terminal, or the like. Each operation terminal 11-14 is communicatively connected to the server 10 via a communication network 15 as shown in FIG. 7. The communication network 15 is a communication line network consisting of, for example, the Internet or a mobile communication network, and may include a LAN (Local Area Network), a WAN (Wide Area Network), an intranet, Ethernet (registered trademark), and the like.

The server 10 is an example of the "information processing device" of the present invention, and is a computer that generates, transmits, and receives data necessary for the game progress, and executes various information processes related to the game progress, and is, more specifically, an SNS server, for example. The server 10 may be composed of one computer, or may be composed of multiple computers distributed in parallel. The server 10 may also be a server computer for ASP (Application Service Provider), SaaS (Software as a Service), PaaS (Platform as a Service), or IaaS (Infrastructure as a Service). In this case, a series of information processes related to the game progress (excluding information input and display) are executed by the server 10, so that each player's operation terminal 11 to 14 only needs to input information to be handed over to the server 10 and output information distributed from the server 10.

As shown in FIG. 7, the server 10 has a processor 21, a memory 22, a communication interface 23, and a storage 24 as hardware devices, which are electrically connected via a bus 25. The processor 21 may be configured with a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), an MCU (Micro Controller Unit), a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), a TPU (Tensor Processing Unit), an ASIC (Application Specific Integrated Circuit), or the like.

The memory 22 may be configured with semiconductor memory such as a Read Only Memory (ROM) and a Random Access Memory (RAM).
The communication interface 23 may be, for example, a network interface card, a communication interface board, etc. The standard of data communication by the communication interface 23 is not particularly limited, and examples thereof include communication by a wireless LAN based on Wi-fi (registered trademark), communication by a mobile communication system of 3G to 5G or a later generation, or communication based on LTE (Long Term Evolution).

The storage 24 may be configured with a flash memory, a hard disc drive (HDD), a solid state drive (SSD), a flexible disc (FD), a magneto-optical disc (MO disc), a compact disc (CD), a digital versatile disc (DVD), a secure digital card (SD card), or a universal serial bus memory (USB memory). The storage 24 may be built into the server 10, or may be attached to the server body in an external format. The storage 24 may also be configured with an external computer (e.g., a database server) that is communicatively connected to the server body. A distributed ledger technology such as a blockchain may be used as a technology for recording various data in order to avoid unauthorized data tampering.

In addition, the server 10 has installed therein, as software, a program for an operating system (OS) and an information processing program for game progression. These programs correspond to the "programs" of the present invention, and are programs that control the server 10, which is a computer. In other words, the programs are executed by the processor 21, causing the server 10 to function as the information processing device of the present invention.

The program may be obtained by reading it from a computer-readable recording medium, or may be obtained (downloaded) via a network such as the Internet or an intranet.

The server 10 progresses the game by executing the above program during game play. Specifically, the server 10 accepts game progress operations from each of the players A to D and executes a series of processes to progress the game. For example, before the start of cooperative play, the server 10 executes a process to set roles for each of the players A to D. During cooperative play, the server 10 also executes a process to generate display data for the game play screen and transmit it to each player's operation terminal 11 to 14, and a process to change the state of the in-game characters, such as the stamina of the field-moving character J1, depending on the progress of the game.

When a switching condition is met during cooperative play, the server 10 executes a process of switching the roles between the first player and the second player. Furthermore, when a return condition is met after a switching condition is met during cooperative play, the server 10 executes a process of returning (returning) the roles after the switch to the roles before the switch.

To explain the configuration of the server 10 from a configuration perspective, as shown in FIG. 8, the server 10 has an operation reception unit 31, a role setting unit 32, a game progression unit 33, a display control unit 34, a memory unit 35, and a role switching unit 36. Of these functional units, the memory unit 35 is realized by the memory 22 or the storage 24, and the other functional units are realized by cooperation between the various hardware devices that make up the server 10 and the programs installed on the server 10. Each functional unit will be explained in detail below.

(Operation reception unit)
The operation acceptance unit 31 accepts operations performed by players during game play through the operation terminals 11 to 14, and more specifically, acquires data indicating the operation contents from the operation terminals 11 to 14 via the communication network 15. Furthermore, when the multiplay mode is selected, the operation acceptance unit 31 accepts operations for each player.

When cooperative play is performed in the multiplay mode, the operation acceptance unit 31 accepts role selection operations from each player before the start of cooperative play. In addition, from the start of cooperative play until the roles are switched between players A and B, the operation acceptance unit 31 accepts movement operations for the field-moving character J1 from player A and flight operations for the support character J2 from player B. In addition, if player B performs an operation to insert an input object T and an operation to purchase an object that can be used as an input object T during cooperative play, the operation acceptance unit 31 accepts these operations.

In addition, when a first player performs a role change request operation and a second player performs an acceptance operation for the role change during cooperative play, the operation acceptance unit 31 accepts each of the change request operation and the acceptance operation. For example, when player A performs a change request operation as the first player and player B performs an acceptance operation as the second player, the operation acceptance unit 31 accepts the change request operation from player A and the acceptance operation from player B.

Furthermore, after the roles are swapped, the operation reception unit 31 receives operations from the players whose roles have been swapped, according to the new roles. For example, when the roles are swapped between player A and player B, the operation reception unit 31 receives a movement operation from player B for the field-moving character J1, and a flying operation from player A for the support character J2.

In addition, when the first player or the second player performs a return operation after the roles are swapped between the first player and the second player, the operation receiving unit 31 receives the return operation.

(Role setting section)
Before the start of a cooperative play, the role setting unit 32 sets a role for each of the multiple players who will play cooperatively, based on a selection operation received from each player by the operation receiving unit 31. The role of each player is set to either a "first role" or a "second role." Note that the types of roles that can be set in a game are not limited to the above two types, and may be three or more types.

(Game Progression Department)
During cooperative play, the game progression unit 33 progresses the game in accordance with operations received from each player. For example, when a movement operation is received from a player set to the first role, the game progression unit 33 moves the field-moving character J1 corresponding to that player on the field in accordance with the movement operation. At this time, the game progression unit 33 may change the state of the field in conjunction with the movement of the field-moving character J1, and may, for example, change the appearance position of an enemy character E on the field.

The game progression unit 33 also changes the state and parameters of the field-moving character J1 depending on the progress of the game. For example, when the field-moving character J1 is attacked (acted upon) by an enemy character E, the game progression unit 33 executes a process to reduce the stamina of the field-moving character J1. When the player operating the field-moving character J1 uses an auxiliary object H or an inserted object T on the field, the game progression unit 33 gives an effect corresponding to the object to the player operating the field-moving character J1, and for example, when a stamina recovery object is used, the stamina of the field-moving character J1 is restored.

In addition, during cooperative play, when a flying operation is received from a player set to the second role, the game progression unit 33 causes the support character J2 corresponding to that player to fly (move) above the field in response to the flying operation.

(Display control unit)
During joint play, the display control unit 34 controls the operation terminals 11 to 14 of each player to display a play screen, and more specifically, generates display data for the play screen for each player and transmits the display data to the operation terminals 11 to 14 of each player. To be more specific, display data for a first screen G1 that displays a portion of the field corresponding to the current position of the field-moving character J1 is transmitted to the operation terminal of the player set to the first role. Display data for a second screen G2 that displays a portion of the field corresponding to the current position of the support character J2 is transmitted to the operation terminal of the player set to the second role.

In addition, when the field-moving character J1 moves on the field by receiving a movement operation from the player set to the first role, the display control unit 34 generates and transmits display data for the first screen G1 after the movement. The first screen G1, which is displayed based on this display data, shows a portion of the field corresponding to the position of the field-moving character J1 after the movement. As a result, when the field-moving character J1 moves, the portion of the field shown on the first screen G1 is switched from time to time in conjunction with the movement of the field-moving character J1.

Similarly, when support character J2 flies above the field by receiving a flying operation from the player set to the second role, the display control unit 34 generates and transmits display data for the second screen G2 after the movement. The second screen G2, which is displayed based on this display data, shows a portion of the field corresponding to the position of support character J2 after the movement. As a result, when support character J2 flies, the portion of the field shown on the second screen G2 changes from time to time in conjunction with the flight of support character J2.

(Memory unit)
The storage unit 35 stores various types of information necessary for the progress of the game. The information stored in the storage unit 35 includes area information and player information.

The area information is information about each of the multiple areas, and is stored in the memory unit 35 for each area. The area information includes the identification number of each area, information about the fields within the area, and the conditions for clearing the area. The information about the field includes the topography of the field, the type and position of the auxiliary object H placed on the field, and the type and position of the enemy character E that appears on the field.

The player information is information about each of the multiple players who play together, and is stored in the memory unit 35 for each player. As shown in FIG. 9, the player information includes each player's name, identification ID, the area in which they are playing, the type and number of objects (items) they possess, the type and amount of in-game currency they possess, and their currently set role.

9, the player information of the player set to the first role further includes information on the field-moving character J1 to be operated, such as the current state and parameters of the field-moving character J1, the current position on the field, etc. The player information of the player set to the second role further includes information on the support character J2 to be operated, such as the current position of the support character J2 in the area, the type and position of the inserted object T inserted by the support character J2, and information on the player designated as the support target (for example, name or identification ID), etc.
Note that the player information is not limited to the information shown in FIG. 9, and may further include information other than the information shown in FIG.

(Role Swap Department)
When a switching condition is satisfied during cooperative play, the role switching unit 36 switches the role of the first player with the role of the second player. In the first embodiment, the role switching unit 36 switches the roles between the first player who performed a change request operation during cooperative play and the second player who performed an acceptance operation during cooperative play.

Let us now consider a situation in which a change request operation is received from player A, one of players A to D who are playing together during joint play. Let us also assume that in the change request operation, player A designates player B as the second player with whom to swap roles. In this case, if no change request operation has been received from players B and D, who have roles different from player A, at the time the change request operation is received from player A, the role swapping unit 36 selects player B as the second player whose role can be swapped with player A.

When an acceptance operation is received from player B, the role switching unit 36 switches the roles between player A, who is the first player, and player B, who is the second player designated by player A. In this case, players C and D correspond to the "other players."

In addition, in the first embodiment, if a return condition is met after the roles of player A and player B are swapped, for example, if a return operation is received from player A or player B, the role swapping unit 36 restores the roles of players A and B to the roles they had before the swap.

In addition, in the first embodiment, when the role switching unit 36 switches the roles of player A and player B, switching between the respective switched roles of players A and B and the roles of players C and D (other players) is restricted while the joint play being performed at the time of the role switching continues.

[Regarding the information processing method according to the first embodiment]
Next, as an example of the information processing method of the present invention, an information processing flow for game progress executed by the computer constituting the information processing device of the first embodiment, i.e., the server 10, will be described. Note that the information processing flow described below is merely an example, and unnecessary steps may be deleted, new steps may be added, or the order of steps may be changed, without departing from the spirit of the present invention.

The following mainly describes the flow of information processing for game progression, including the flow related to role setting (hereinafter referred to as the role setting flow), the flow related to displaying the play screen (hereinafter referred to as the screen display flow), and the flow related to role switching (hereinafter referred to as the role switching flow).

(Role setting flow)
The role setting flow proceeds as shown in FIG. 10. The role setting flow starts with the server 10 accepting a mode selection operation from the player (S001). More specifically, when the player logs into the game using the operation terminal, the play mode selection screen shown in the left diagram of FIG. 11 is displayed on the operation terminal. The player selects either the single play mode or the multiplay mode, and touches one of the two mode selection buttons displayed on the screen. The player's selection is converted into data by the player's operation terminal and transmitted to the server 10. The server 10 then accepts the mode selection operation from the player.

When the server 10 receives a mode selection operation from a player who has selected multiplay mode, it identifies that player and determines within a certain period of time whether or not there is more than one player who has selected multiplay mode (S002). Then, once the certain period of time has elapsed, the number of players playing the game in multiplay mode (number of players) is determined. The following explanation assumes a situation in which four players, A to D, are playing the game in multiplay mode.

The server 10 accepts a role selection operation from each of the players A to D (S003). More specifically, the server 10 causes the operation terminal of each of the players A to D to display a role selection screen shown in the right diagram of FIG. 11. Each of the players A to D selects either the first role or the second role, and touches one of the two role selection buttons displayed on the role selection screen that corresponds to the selected role. In the example screen shown in FIG. 10, the button labeled "Field Movement" corresponds to the first role, and the button labeled "Support" corresponds to the second role.

The selection results of each player are digitized by the operation terminal of the player and transmitted to the server 10. The server 10 then accepts role selection operations from each player. After accepting role selection operations from all of players A to D (S004), the server 10 sets the roles of each of players A to D based on the role selection operations accepted for each player (S005).

When role setting for each player is complete, game play in multiplay mode, i.e., cooperative play, can begin. Note that a minimum required number of players (lower limit) may be set for players playing the first role in multiplay mode. In that case, the game will wait until the number of players selecting the first role exceeds the lower limit, and cooperative play can begin when the number of players selecting the first role exceeds the lower limit.

In addition, after cooperative play has begun, a new player may be able to join the ongoing (in-play) cooperative play. Alternatively, the joining of a new player may be restricted (or not permitted) from the time cooperative play begins until it ends.

(Screen display flow)
The screen display flow includes a screen display flow for a player set to a first role (hereinafter referred to as a first screen display flow) and a screen display flow for a player set to a second role (hereinafter referred to as a second screen display flow).

The first screen display flow proceeds as shown in FIG. 12 and is implemented via data communication between the server 10 and the operation terminal of the player who is set to the first role. Here, player A is taken to be the representative of the players who are set to the first role, and the first screen display flow implemented between the server 10 and the operation terminal 11 of player A will be described.

In the first screen display flow, the server 10 first generates display data for the first screen G1 and transmits it to the operation terminal 11 of player A (S011). As a result, the operation terminal 11 displays the first screen G1 showing the field-moving character J1 operated by player A and a part of the field (S012). Note that the first screen G1 displayed at the start of joint play shows a part of the field that corresponds to the initial position (start position) of the field-moving character J1.

During joint play, player A performs movement operations on the field-moving character J1 from time to time while viewing the first screen G1 (S013). The server 10 accepts the movement operation from player A through communication with the operation terminal 11 (S014), and moves the field-moving character J1 on the field in accordance with the accepted movement operation (S015). The server 10 then generates display data for the first screen G1 (hereinafter referred to as the "first screen G1 after movement") that shows a portion of the field corresponding to the position of the field-moving character J1 after the movement, and transmits this data to the operation terminal 11 (S016). As a result, the first screen G1 after the movement is displayed on the operation terminal 11 (S017).

After that, steps S014 to S017 are repeated each time player A performs a movement operation, and the first screen G1 displayed on the operation terminal 11 is updated as needed. The first screen display flow continues while joint play is taking place, and ends when the game ends (S018). The game ends when a condition for ending joint play is met, such as when a specified area is cleared, when a preset joint play time (time limit) has elapsed, or when player A discontinues (retires) joint play.

Although not specifically shown, during cooperative play, the server 10 appropriately changes the state and parameters of the field-moving character J1 in accordance with the progress of the game, and accordingly updates the user information of player A stored in the memory unit 35.

The second screen display flow proceeds as shown in FIG. 13 and is implemented via data communication between the server 10 and the operation terminal of the player who is set to the second role. Here, player B is taken to be the representative of the players who are set to the second role, and the second screen display flow implemented between the server 10 and the operation terminal 12 of player B will be described.

In the second screen display flow, the server 10 first generates display data for the second screen G2 and transmits it to the operation terminal 12 of player B (S021). As a result, the operation terminal 12 displays the second screen G2, which shows the support character J2 operated by player B and a part of the field (S022). Note that the second screen G2 displayed at the start of joint play shows a part of the field that corresponds to the initial position (start position) of the support character J2.

During joint play, player B performs flight operations on support character J2 at any time while viewing the second screen G2 (S023). The server 10 accepts flight operations from player B through communication with the operation terminal 12 (S024), and moves support character J2 above the field in accordance with the accepted flight operations (S025). The server 10 then generates display data for the second screen G2 (hereinafter referred to as the "second screen G2 after movement") that shows a portion of the field corresponding to the position of support character J2 after the movement, and transmits this data to the operation terminal 12 (S026). As a result, the second screen G2 after the movement is displayed on the operation terminal 12 (S027).

After that, steps S024 to S027 are repeated each time Player B performs a flight operation, and the second screen G2 displayed on the operation terminal 12 is updated accordingly. The second screen display flow continues while joint play is being performed, and ends when the game ends (S028).

Although not specifically shown, when player B performs a throw-in operation to throw an throw-in object T onto the field during cooperative play, the server 10 accepts the throw-in operation from player B and performs processing to throw (place) the throw-in object T onto the field. In response to this, the server 10 generates display data for the first screen G1 and the second screen G2 when the throw-in object T is placed on the field, and transmits the generated display data to the operation terminals 11 and 12. As a result, the field with the throw-in object T thrown in is displayed on the first screen G1 and the second screen G2.

(Role Swap Flow)
The role-swapping flow proceeds as shown in Fig. 14. The role-swapping flow starts with the first player making a change request operation (S031). Here, it is assumed that player A corresponds to the first player, and player A makes a change request operation and designates player B as the second player with whom the role will be swapped. The designation result is converted into data by player A's operation terminal 11 and transmitted to the server 10. As a result, the server 10 accepts the change request operation from player A (S032).

When the server 10 receives a change request operation from player A, it determines whether or not a change request operation has been received at that time from a player with a different role from player A, i.e., a second player (S033). If a change request operation has not been received from the second player, the server 10 selects player B, specified in player A's change request operation, as the second player whose role will be swapped with player A's (S034).

An inquiry screen (the right diagram in Figure 5) is displayed on the operation terminal 12 of the selected player B, and player B selects whether or not to accept the role change requested by player A, and if he accepts, performs an acceptance operation, specifically, an operation of clicking the accept button on the screen. When player B performs an acceptance operation for the role change (S035), the server 10 accepts the acceptance operation from player B (S036). As described above, when the server 10 accepts the change request operation from player A and accepts the acceptance operation from player B designated by player A, the swap condition for players A and B is established.

Then, when the switching condition is met, the server 10 switches the roles between player A and player B (S037). As a result of the role switching, in the subsequent cooperative play, the field moving character J1 that was previously controlled by player A will be controlled by player B. Also, the support character J2 that was previously controlled by player B will be controlled by player A.
In other words, in the joint play after the role exchange, the server 10 displays the first screen G1 on the operation terminal 12 of the player B and accepts a movement operation for the field-moving character J1 from the player B. On the other hand, the server 10 displays the second screen G2 on the operation terminal 11 of the player A and accepts a flying operation for the support character J2 from the player A. Furthermore, by exchanging the roles, the player A is now able to perform an insertion operation for the insertion object T, and the server 10 is now able to accept such an operation from the player A.

In addition, during cooperative play, if a return condition is met after the role swap (S038), the server 10 returns the roles of player A and player B after the swap to the roles before the swap (S039). As described above, examples of the return condition include receiving a return operation from the first player A or B after the role swap, or the passage of a certain amount of time after the role swap.

In addition, if players A and B switch roles during cooperative play, there will be restrictions on switching between the roles of players A and B after the switch and the roles of other players C and D.

[Regarding the second embodiment of the present invention]
In the first embodiment, when a change request operation is received from a first player and an acceptance operation is received from a second player designated in the change request operation, the first player and the second player switch roles. That is, in the first embodiment, the change request operation is performed by only one of the two players (the first player) whose roles are to be switched, but this is not limited to this and other forms may be considered. Such a form is referred to as a second embodiment, and the second embodiment will be described below.

In the following, the second embodiment will be mainly described in terms of the differences from the first embodiment, and the commonalities with the first embodiment will not be described. In the following, we will assume a scene in which players A to D play together, with player A set to the first role and player B set to the second role.

In the second embodiment, when a change request operation is received from both the first player and the second player, the server 10 switches the roles between the first player and the second player. To be more specific, in the role switching flow according to the second embodiment, as shown in FIG. 15, the player set to the first role performs a change request operation in the same manner as in the first embodiment, and the server 10 accepts the change request operation from that player (S041, S042). Here, it is assumed that player A performs a change request operation, and server A accepts the change request operation from player A.

Then, the server 10 waits for a change request operation from the player set to the second role, and if, for example, player B performs a change request operation (S043), it accepts the change request operation from player B (S044) and matches the players requesting a role change (i.e., players A and B). Then, the server 10 (more specifically, the role switching unit 36) switches the roles between the matched players A and B, as shown in FIG. 15 (S045).

As described above, in the second embodiment, when a change request operation is received from both of two players who have been set to different roles, this triggers the two players to switch roles. Note that in the second embodiment, as in the first embodiment, if a return condition is met after a role switch in cooperative play (S046), the roles of the players after the switch may be restored to the roles before the switch (S047).

In addition, when roles are swapped between players A and B during cooperative play, restrictions may be placed on switching between the roles of players A and B after the swap and the roles of other players C and D.

[Regarding the third embodiment of the present invention]
In the above embodiment, each player in a joint play can perform a change request operation at any timing, in other words, the server 10 (more specifically, the operation receiving unit 31) can receive a change request operation from the first player and/or the second player at any timing during the joint play. However, this is not limited to this, and other forms may be considered. Such a form is referred to as a third embodiment, and the third embodiment will be described below with reference to FIG. 16.

In the following, the third embodiment will be mainly described with respect to the differences from the first and second embodiments, and the description of the points in common with the first and second embodiments will be omitted. In addition, in the following, a scene will be described assuming that the first player, player A, plays the first role, and the second player, player B, plays the second role, in a joint play. However, the contents described below can also be applied to a case where the player A plays the second role, and the player B plays the first role, in a joint play.
16A to 16C show screen transitions on the player A's side, and FIG. 16D to 16F show screen transitions on the player B's side.

In the third embodiment, during cooperative play, if the state of the field-moving character J1 operated by the first player becomes a predetermined state, for example a state in which his stamina is reduced to zero and he is unable to continue playing, the first player and second player can switch roles.

Specifically, as shown in FIG. 16, when the stamina of the field-moving character J1 operated by player A becomes 0 (FIG. 16(a)), a change request screen is displayed on player A's operation terminal 11 (FIG. 16(b)). At this point, player A can perform a change request operation, and the server 10 (more specifically, the operation reception unit 31) can accept the change request operation from player A. In other words, in the third embodiment, a change request operation from the first player can be accepted on the condition that the state of the field-moving character J1 operated by the first player becomes a predetermined state.

When player A designates player B as the partner for role swapping in the change request operation, as shown in FIG. 16, an inquiry screen is displayed on the operation terminal 12 of player B, who operates the support character J2 in joint play ((d) and (e) of FIG. 16). When player B permits the role change requested by player A, he performs an acceptance operation for the role change, and the server 10 (more specifically, the operation acceptance unit 31) accepts the acceptance operation from player B. Note that a change request screen may be displayed on player B's operation terminal 12 instead of the inquiry screen, in which case player B performs the change request operation, and the server 10 accepts the change request operation from each of players A and B, and the two players are matched.

When a change request operation is received from player A and an acceptance operation or a change request operation is received from player B, the server 10 (more specifically, the role switching unit 36) switches the roles between players A and B. As a result, in subsequent joint play, player A plays the second role and performs flying operations on the support character J2 (FIG. 16(c)), and player B plays the first role and performs movement operations on the field-moving character J1 (FIG. 16(f)).

In addition, when the server 10 (more specifically, the game progression unit 33) resumes the game after the role switch, it returns the state of the field-moving character J1, which has reached a predetermined state, to the state before the predetermined state was reached, for example, the state before the stamina became zero, and then resumes the game. As a result, after the role switch, player B becomes able to control the field-moving character J1 in the state before the stamina became zero (i.e., a state in which game play can be continued), as shown in FIG. 16(f).

In the third embodiment, the number of times the vitality is returned to the state before it becomes 0 when switching roles, i.e., the number of times the vitality is restored, may be set in advance in association with the field-moving character J1. In this case, if the number of times the vitality is restored is a predetermined number or more, the roles can be switched, and when the roles are switched, the number of times the vitality is restored is consumed by a predetermined number (for example, 1 time). In other words, when the vitality of the field-moving character J1 operated by player A becomes 0, if the number of times the field-moving character J1 has its vitality restored is 1 or more, the roles can be switched between the field-moving character J1 and player A, and when the roles are switched, the number of times the vitality is restored associated with the field-moving character J1 of player A is reduced by 1.
On the other hand, for a player whose associated field-moving character J1 has a stamina recovery count of 0, even if the stamina of that field-moving character J1 becomes 0, role switching is restricted and the player will not be able to continue cooperative play after the stamina becomes 0.

[Regarding the fourth embodiment of the present invention]
In the above embodiment, the first player performs a change request operation, and in the change request operation, the first player designates a player (i.e., a second player) with whom to exchange roles, and the roles are exchanged between the designated second player and the first player. However, this is not limited to this, and other forms may be considered. Such a form is referred to as a fourth embodiment, and the fourth embodiment will be described below.
In the following, the second embodiment will be described mainly in terms of the differences from the first to third embodiments, and a description of the points in common with the first embodiment will be omitted.

In the fourth embodiment, before communal play begins, each player designates one or more players other than himself/herself and is associated with the designated players. To be more specific, the server 10x constituting the information processing device according to the fourth embodiment further has an association unit 37 in addition to the functions described above, as shown in FIG. 17. The association unit 37 associates the first player and the second player in advance before commencing communal play.

More specifically, in multiplayer mode, each player can register one player from among players who have a different role from the player himself/herself through a specified registration screen. This registration operation is accepted by the operation acceptance unit 31, and may be performed by either the first player or the second player. The purpose of the registration is not particularly limited, and may be to register a companion (friend) in the game, or to register a person to be assisted in cooperative play.

When the registration operation is accepted, the association unit 37 associates the player who performed the registration operation with the registered player. That is, the player who performed the registration and the registered player are associated with each other, and information about the association (i.e., the registration contents) is stored in the storage unit 35 of the server 10.

In the fourth embodiment, when a predetermined condition is met in joint play, the server 10x (more specifically, the role swapping unit 36) swaps the roles between the first player and the second player associated by the association unit 37. For example, in joint play, when the state of the field-moving character J1 operated by the first player becomes a predetermined state (specifically, a state in which the stamina is 0), the roles are swapped between the first player and the second player previously registered by the first player.

As described above, in the fourth embodiment, roles are swapped between players who are associated with each other. Note that players may be associated with each other before the start of game play (more specifically, joint play), or during joint play (in play).

[Other embodiments]
Up to this point, several specific embodiments of the information processing device, information processing method, and program of the present invention have been described, but the above-described embodiments are merely examples and other embodiments may be considered.

In the above embodiment, the server 10, 10x, which is an example of a computer, functions as the information processing device of the present invention, but some of the functions of the server 10, 10x may be provided on the player's operation terminal. For example, the game progression unit 33 may be provided on the player's operation terminal, in which case, in collaborative play, the operation terminal of each player receives data for game progression from the server 10, 10x and executes processing to progress the game in accordance with each player's play operation.

In the above embodiment, the communication method used by each of the operation terminals of multiple players playing together is a method via the servers 10, 10x (client-server method), but it may also be a P2P (peer-to-peer) method that does not involve the servers 10, 10x. In that case, the operation terminals of each player will cooperate to function as the information processing device of the present invention.

[summary]
The present invention is achieved by the following configurations [1] to [13], and each of the configurations can provide various effects.

[1] An information processing device of the present invention is characterized in having a role setting unit that sets a role to be assumed by each of a plurality of players who play a game together during play of the game, and a role swapping unit that swaps the role of the first player with the role of the second player when a predetermined condition is satisfied while a first player and a second player, to whom different roles have been set, are playing the game together.
According to the above configuration, when a predetermined condition is met in a joint game play, the first player and the second player switch roles, thereby encouraging cooperation between the players. This allows each of the first player and the second player to play the game in multiple roles. As a result, it is possible to provide each player with a variety of ways to enjoy the game (game experience) while maintaining a balance between the multiple roles in the joint play.

[2] In the information processing device of the present invention, the role switching unit may switch roles between the first player and a second player designated by the first player.
According to the above configuration, the role of the first player is swapped with the role of the second player designated by the first player, thereby making it possible to avoid a situation in which roles are swapped between the first player and a player with whom the first player does not wish to be swapped during cooperative play of a game.

[3] In the information processing device of the present invention, the role switching unit may, when receiving an acceptance operation for the role change from the second player designated by the first player, switch roles between the first player and the second player designated by the first player.
According to the above configuration, the roles are swapped between the first player and the second player after an acceptance operation from the second player is received, so that the roles can be swapped between the first player and the second player at the time when an agreement is reached between both the first player and the second player.

[4] In the information processing device of the present invention, an association unit that associates a first player with a second player before play of a game begins may be provided, and a role switching unit may switch roles between the first player and the second player associated by the association unit when a predetermined condition is satisfied.
According to the above configuration, by associating the first player and the second player in advance, when a predetermined condition is met in a joint play, the first player and the second player who are associated with each other can smoothly switch roles. This makes it possible to omit the operation required for the switching, and reduces the burden on the players involved in the operation.

[5] In the information processing device of the present invention, when a change request operation is received from a first player during cooperative play of a game, but a change request operation is not received from a player having a different role from the first player, the role switching unit may switch the roles between the first player and a second player selected according to a predetermined criterion from among players who have been set a role different from that of the first player.
According to the above configuration, when a change request operation of the first player is accepted, unless there is a change request operation from another player (strictly speaking, a player having a different role from the first player), the roles can be swapped between the second player selected according to a predetermined criterion and the first player. This makes it possible to avoid a role swap that is undesirable for the first player due to a role swap between the second player and the first player who do not satisfy the predetermined criterion.

[6] In the information processing device of the present invention, when a change request operation is received from both a first player and a second player, who are assigned different roles, during collaborative play of a game, the role switching unit may switch the roles between the first player and the second player.
According to the above configuration, when a change request operation is received from both the first player and the second player, the roles can be swapped, and the roles can be swapped between players who wish to swap roles.

[7] In the information processing device of the present invention, the role switching unit may be capable of switching roles between the first player and the second player when a state of an in-game character operated by the first player reaches a predetermined state during collaborative play of a game.
According to the above configuration, when the state of the in-game character becomes a predetermined state, the first player and the second player can switch roles. As a result, for example, assume that the first player, who is a beginner at games (particularly in co-play), is playing a difficult scene during co-play, but the strength of the in-game character operated by the first player is significantly reduced due to an attack from an enemy character E, etc. In such a situation, the second player, who is an advanced player in the game, can operate the in-game character in place of the first player, making it easier for the first player to get through the difficult scene.
Also, suppose that a first player who is an advanced player is in a situation where he or she is progressing through the game to an advantage (for example, a situation where his or her vitality does not decrease even when attacked by enemy character E) by operating an in-game character during joint play and acquiring a specific item, etc. In such a situation, by allowing a second player who is a beginner to the game to operate the in-game character in place of the first player, it becomes possible to have the second player play scenes with a lower level of difficulty.

[8] The information processing device of the present invention may further include a game progression unit that progresses the game. In this case, when the role switching unit switches roles between the first player and the second player, the game progression unit may resume the game by restoring a state of the in-game character to a state before the predetermined state was reached.
According to the above configuration, when the state of the in-game character reaches a predetermined state and the first player and second player switch roles, in subsequent collaborative play, the in-game character is returned to the state it was in before it reached the predetermined state, and the second player can operate the in-game character in the returned state.

[9] The information processing device of the present invention may have an operation receiving unit that receives operations of each of a plurality of players. In this case, the operation receiving unit receives a first operation performed by a player assigned a first role on a first in-game character during a joint play of a game, and receives a second operation performed by a player assigned a second role on a second in-game character different from the first in-game character. Then, after the role switching unit switches roles between the first player assigned the first role and the second player assigned the second role, the operation receiving unit may accept a second operation by the first player and a first operation by the second player.
According to the above configuration, the first player and the second player whose roles have been swapped can play the game in their new roles, and specifically, can control an in-game character corresponding to their new roles.

[10] In the information processing device of the present invention, when a return condition is met after switching between the roles of the first player and the second player, the role switching unit may return the roles of the first player and the second player to the roles before the switching.
According to the above configuration, the roles of the first player and the second player that have been switched can be restored to the roles before the switch. This allows each of the first player and the second player to temporarily experience the switched roles and then return to their original roles, allowing players to casually enjoy switching roles during cooperative play (i.e., to try switching roles).

[11] In the information processing device of the present invention, after the role switching unit switches the roles of the first player and the second player with each other, during collaborative play of the game, switching of the respective switched roles of the first player and the second player with the roles of other players may be restricted.
According to the above configuration, since the role of each of the first player and the second player after the exchange is restricted from being exchanged with the role of another player, it is possible to prevent the role exchange situation from becoming complicated. For example, if the role of the first player is exchanged with the role of the second player and then further exchanged with the role of another player (third player), the situation becomes complicated because there are multiple players who have exchanged roles with the first player. In that case, for example, it becomes difficult to return the role to the role before the exchange.

[12] An information processing method of the present invention is characterized in that a computer assigns a role to each of a plurality of players who play a game together to be played by the player during play of the game, and when a predetermined condition is satisfied while a first player who has been assigned a first role and a second player who has been assigned a second role are playing the game together, the computer swaps the role of the first player with the role of the second player.
According to the above method, cooperation between players is encouraged through role switching between the players, and each of the first player and the second player can play the game in multiple roles during joint play. As a result, it is possible to provide each player with a variety of ways to enjoy the game (game experience) while maintaining a balance between the multiple roles in joint play.

[13] A program of the present invention is characterized in that it causes a computer to set, for each of a plurality of players playing a game jointly, a role to be assumed by the player during play of the game, and when a predetermined condition is satisfied while a first player to whom a first role has been assigned and a second player to whom a second role has been assigned are playing the game jointly, it causes the computer to switch the role of the first player with the role of the second player.
By executing the above program on a computer, it becomes possible for players to switch roles, which encourages cooperation between players and allows each of the first player and the second player to play the game in multiple roles. As a result, it is possible to provide each player with a variety of ways to enjoy the game (game experience) while maintaining a balance between the multiple roles in cooperative play.

10, 10x Information processing device 11, 12, 13, 14 Operation terminal 15 Communication network 21 Processor 22 Memory 23 Communication interface 24 Storage 25 Bus 31 Operation reception unit 32 Role setting unit 33 Game progression unit 34 Display control unit 35 Memory unit 36 Role switching unit 37 Association unit E Enemy character G1 First screen G2 Second screen H Auxiliary object J1 Field moving character (in-game character, first in-game character)
J2 Support character (second in-game character)
T Input object

Claims (5)

An information processing device including a processor,
The processor sets, for each of a plurality of players who play a game together, a role that the player will play during playing the game;
when a state of an in-game character operated by a first player becomes unable to continue playing while a first player and a second player, each assigned a different role, are playing the game together, the processor exchanges the role of the first player with the role of the second player, and returns the state of the in-game character to a state where play can be continued , thereby resuming the game;
the processor sets a role to be played by a player during play of the game from among two or more roles including a first role and a second role different from the first role;
Information processing device. when a state of the in-game character becomes the state in which play cannot be continued and the number of times the state of the in-game character is returned to the state in which play can be continued and the game is resumed is less than a preset number of times associated with the in-game character, the processor exchanges the role of the first player with the role of the second player.
The information processing device according to claim 1 . The processor sets, for each of a plurality of players who play the game together, a role that the player will play during playing the game;
a processor, when a state of an in-game character operated by a first player becomes unable to continue playing while a first player and a second player, each assigned a different role, are playing the game together, swaps the role of the first player with the role of the second player, and returns the state of the in-game character to a state where play can be continued , thereby resuming the game;
a processor sets a role to be played by a player during play of the game from among two or more roles including a first role and a second role different from the first role;
Information processing methods. causing a processor to set, for each of a plurality of players who play a game together, a role that the player will assume during play of the game;
a processor, when a state of an in-game character operated by a first player becomes unable to continue playing while a first player and a second player assigned different roles are playing the game together, causes the processor to switch the role of the first player with the role of the second player, and to return the state of the in-game character to a state where it is possible to continue playing , thereby resuming the game;
causing the processor to set a role to be played by a player during play of the game from among two or more roles including a first role and a second role different from the first role;
program. Equipped with a server and an operation terminal,
The server,
assigning a role to be played by each of a plurality of players who play a game together using the operation terminal during play of the game;
When a first player and a second player, each assigned a different role, are playing the game together, and a state of a game character operated by the first player becomes unable to continue playing , the role of the first player and the role of the second player are swapped, and the state of the game character is restored to a state where play can be continued , thereby resuming the game;
setting a role to be played by a player during playing of the game from among two or more roles including a first role and a second role different from the first role;
system.

Images