Information processing device, information processing method, and program

Abstract

To inhibit recruitment of a multi-play designating a group from being useless.SOLUTION: An information processing device is provided, including a display control unit for displaying information about easiness of establishing a multi-play for each group on a screen for receiving the designation of a group recruiting the multi-play in which a plurality of users jointly perform a game from a first user, and a recruitment control unit for recruiting the multi-play to a second user belonging to at least one group designated by the first user.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, an information processing method, and a program.

Background Art

[0002] There is known a game in which a quest is cleared using a team composed of a plurality of characters called a deck. Also, there is known a game method called multiplayer in which a plurality of users play a single quest jointly. For example, Patent Document 1 discloses a game in which a quest is executed using a player character possessed by a user.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] When playing a game in multiplayer, it is common for the host user to recruit guest users who participate in the multiplayer. Here, when performing multiplayer, it is desirable to perform multiplayer between users whose proficiency levels and play purposes are similar because it becomes easier to cooperate within the team. Therefore, it is conceivable to form groups in advance among similar users and perform multiplayer among the users within the group.

[0005] However, when groups are formed, some groups may be very active (for example, groups with many users playing the game) while others are not (for example, groups with few users playing the game). Therefore, when a host user is recruiting guest users to participate in multiplayer, if they recruit guests from a group that is not very active, it is possible that no guest users will apply, and the multiplayer session will not be able to take place.

[0006] Therefore, the present invention aims to provide a technology that can prevent the wastefulness of recruiting players for multiplayer games. [Means for solving the problem]

[0007] An information processing device according to one aspect of the present invention includes a display control unit that displays information regarding the ease with which a multiplayer game can be formed for each group on a screen that receives a designation from a first user for a group to recruit for a multiplayer game in which multiple users play a game together, and a recruitment control unit that recruits second users belonging to at least one group designated by the first user for the multiplayer game. [Effects of the Invention]

[0008] According to the present invention, it is possible to provide a technology that can prevent the wastefulness of recruiting players for multiplayer games. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows an example of the system configuration of the game system according to this embodiment. [Figure 2] A diagram showing an example of the hardware configuration of a game server and terminal. [Figure 3] A diagram showing an example of the functional block structure of a game server. [Figure 4] A diagram showing an example of the functional block configuration of a terminal. [Figure 5]A diagram showing an example of a user management database and a user group management database. [Figure 6] A diagram showing an example of a character ownership management database. [Figure 7] A flowchart illustrating an example of the process a user follows when creating a user group. [Figure 8] A flowchart illustrating an example of the process for a user to join a user group. [Figure 9] This diagram shows an example of the screen display when joining a user group. [Figure 10] A flowchart illustrating an example of the processing procedure when conducting multiplayer within a user group. [Figure 11] This diagram shows an example of a screen used when recruiting players for multiplayer games. [Figure 12] An example of the screen when joining a multiplayer game. [Modes for carrying out the invention]

[0010] Embodiments of the present invention will be described with reference to the attached drawings. In each drawing, components denoted by the same reference numerals have the same or similar configurations.

[0011] <System Configuration> Figure 1 shows an example of the system configuration of the game system 1 according to this embodiment. The game system 1 shown in Figure 1 comprises a game server 10 (game device) and a plurality of terminals 20. The game server 10 and the terminals 20 are connected to each other so as to be able to communicate via a communication network N such as the Internet, intranet, wireless LAN, or mobile communication.

[0012] The game server 10 is a device that performs some of the functions necessary for the terminal 20 to provide the game, such as managing various information about the player or executing some of the game's processing. The game server 10 may consist of one or more information processing devices, or it may be configured using a virtual server (such as a cloud server).

[0013] The terminal 20 is an information processing device that provides games to players. Players can execute the game according to this embodiment by operating the terminal 20. The terminal 20 is, for example, a computer such as a mobile phone (including a smartphone), a tablet, a personal computer, an arcade game device, or a consumer game device. The terminal 20 notifies the game server 10 of its own position detected using GPS (Global Positioning System) or the like.

[0014] <Game Overview> Next, the overview of the game provided by the game system 1 according to this embodiment will be described. In the game provided by the game system 1, a user (which may also be referred to as a player) can obtain new game media and items by compiling a deck using a game media selected from a plurality of game media possessed by the user and clearing quests using the compiled deck. In addition, the user can generate a stronger character by synthesizing a plurality of obtained game media, or challenge quests with a higher difficulty level by strengthening the attributes of the game media using items. The game media may also be referred to as a game object. The game media may also be a character, a game card, or the like.

[0015] A quest is a term that means a task that can be cleared by satisfying a predetermined set of conditions. Quests are generally also called explorations, tasks, and missions. A user who plays a quest can clear the quest by satisfying the said set of conditions. When a quest is cleared, a reward is given to the user, or the game story progresses. Although it is assumed in this embodiment that various quests are provided in the game, this embodiment is not limited to this. The term "quest" in this embodiment may also mean the game itself.

[0016] A "deck" is a term that means a team formed by combining a plurality of game media. When a user executes a quest, the user selects game media with suitable capabilities to clear the quest, forms a deck, and plays the quest. The game server 10 can store a plurality of decks compiled by the user, and the user can select one deck from the plurality of stored decks and play the quest. In this embodiment, the act of a user playing a quest may be referred to as executing the quest. Also, in this embodiment, playing a quest may be referred to as playing a game or executing a game.

[0017] Multiple users can play a quest jointly. Hereinafter, the act of multiple users playing a quest jointly is referred to as "multiplayer". Multiplayer may also be called co-play. On the other hand, a user playing a quest alone may be referred to as single-play. In multiplayer, each user can operate the character assigned to oneself among the plurality of characters forming the deck. For example, for a deck composed of characters A to D, assume that character A is assigned to user A (the self-user), and characters B to D are assigned to other users B to D, respectively. In this case, after user A finishes operating character A, user B operates character B, and then user C operates character C, and so on, and each user operates the characters forming the deck in order. The user who recruits multiplayer may be called the host or host user. On the other hand, the user who participates in the multiplayer recruited by the host may be called the guest or guest user. Recruiting multiplayer may also be read as recruiting participation in multiplayer, convening multiplayer, soliciting multiplayer, etc.

[0018] In multiplayer, the plurality of characters forming the deck may be composed of characters possessed by the host user, or may be composed of characters selected by each of the host and guest users from the characters they possess.

[0019] In this embodiment, users can join groups (hereinafter referred to as "user groups"). Each user can create one or more user groups. Also, each user can join one or more user groups. A user who creates a user group may be called a creating user or group owner. A user who joins a created user group may be called a joining user or similar. In the following description, unless otherwise specified, creating users and joining users will be referred to as users belonging to a user group or members of a user group.

[0020] Users who create user groups can assign arbitrary tags to the user groups they create. Users who wish to join a user group can find the group they want to join by searching for the tags assigned to it. Tags may include tags predetermined by the game operator, etc., and / or arbitrary strings.

[0021] While any user can join a user group, in this embodiment, it is assumed that users who share similar levels of game experience, preferences, or gameplay goals will form groups. For example, during the period when event quest A is available, a user group tagged with "I want to clear quest A" could be created, and users who want to clear quest A could join that user group and aim to clear quest A. Similarly, a user group tagged with "Heavy users level 50 and above only" is expected to be joined by users who are level 50 or above.

[0022] In this embodiment, a user can recruit players for multiplayer by specifying the user group to which they belong (i.e., a user group they created or a user group they are a member of). When recruiting for multiplayer by specifying a user group, only users belonging to the specified user group can participate in that multiplayer session. This makes it easier for users with similar levels of experience, preferences, or goals to play together in multiplayer.

[0023] Furthermore, game server 10 displays "information regarding the likelihood of a multiplayer match being formed" for each user group on the screen where users can specify a user group to recruit for multiplayer. Naturally, a multiplayer match cannot be formed unless users who wish to participate appear. Therefore, users can refer to this information and recruit for multiplayer by specifying a user group that they believe is likely to form a match. This helps to prevent situations where a multiplayer match cannot be formed and the recruitment is wasted.

[0024] <Hardware Configuration> Figure 2 shows an example of the hardware configuration of the game server 10 and terminal 20. The game server 10 and terminal 20 consist of a processor 11 such as a CPU (Central Processing Unit) and a GPU (Graphical Processing Unit), a storage device 12 such as memory, an HDD (Hard Disk Drive) and / or an SSD (Solid State Drive), and a communication interface for wired or wireless communication. The interface (13) includes an input device 14 that accepts input operations and an output device 15 that outputs information. The input device 14 is, for example, a keyboard, a touch panel, a mouse, and / or a microphone. The output device 15 is, for example, a display, a touch panel, and / or a speaker.

[0025] <Functional Block Configuration> (Game Server) Figure 3 shows an example of the functional block configuration of the game server 10. The game server 10 includes a storage unit 100 and a control unit 101. The storage unit 100 can be implemented using a storage device 12 provided by the game server 10. The control unit 101 can be implemented by the processor 11 of the game server 10 executing a program stored in the storage device 12. This program can be stored in a storage medium. The storage medium on which the program is stored may be a non-transitory computer-readable medium. The non-transitory storage medium is not particularly limited, but may be, for example, a USB memory stick or a CD-ROM.

[0026] The memory unit 100 stores the game data necessary for the game server 10 to run the game. The game data includes various databases.

[0027] The control unit 101 performs various processes related to the execution of the game. For example, it performs processes such as executing quests specified by the user and granting rewards to the user. The control unit 111 also includes the display control unit 102, the group control unit 103, and the recruitment control unit 104. The control unit 101 may also be called the game execution unit or execution unit.

[0028] The display control unit 102 displays various game-related screens on the terminal 20's display. For example, the display control unit 102 displays information regarding the ease of establishing a multiplayer game for each user group on the screen where the host user specifies the user group to recruit for multiplayer. The host user may also be referred to as the "first user."

[0029] The group control unit 103 is responsible for creating and managing user groups. For example, the group control unit 103 performs processes such as creating new user groups in response to instructions from users, and managing the association between a user and a user group when a user requests to join a user group.

[0030] The recruitment control unit 104 performs various processes related to recruiting for multiplayer. For example, the recruitment control unit 104 recruits users belonging to at least one group specified by the host user (first user) for multiplayer. Users belonging to the group specified by the host user may be referred to as "recruitment target users" or "second users." Recruiting for multiplayer may include notifying recruitment target users of an invitation to participate in multiplayer and accepting participation from recruitment target users.

[0031] Furthermore, the recruitment control unit 104 may also recruit users for multiplayer matches from each of the multiple groups specified by the host user (first user).

[0032] The display control unit 102 may be part of the group control unit 103 and the recruitment control unit 104. For example, among the various processes related to user groups, the display control unit 102 may perform the screen display-related processes, while the group control unit 103 may perform processes other than screen display, such as accessing the database. Similarly, among the various processes related to recruiting for multiplayer, the display control unit 102 may perform the screen display-related processes, while the recruitment control unit 104 may perform processes other than screen display, such as accessing the database and managing multiplayer games that are currently recruiting participants. However, the system is not limited to these examples, and the display control unit 102 may be an individual functional block rather than part of the group control unit 103 and the recruitment control unit 104.

[0033] (terminal) Figure 4 shows an example of the functional block configuration of terminal 20. Terminal 20 includes a storage unit 200, a communication unit 201, a UI (User Interface) unit 202, and a control unit 203. The storage unit 200 can be implemented using a storage device 12 provided by terminal 20. The communication unit 201, the UI unit 202, and the control unit 203 can be implemented by the processor 11 of terminal 20 executing a program stored in the storage device 12. This program can be stored in a storage medium. The storage medium on which the program is stored may be a computer-readable non-temporary storage medium. The non-temporary storage medium is not particularly limited, but may be, for example, a USB memory or a CD-ROM.

[0034] The memory unit 200 stores the game data necessary for the control unit 203 to execute the game. The game data includes image data, game scenarios, and the like.

[0035] The communication unit 201 has the function of performing various types of communication with the game server 10 using the communication IF 13.

[0036] The UI unit 202 has the function of receiving various inputs from the user and displaying various game screens on the display. The UI unit 202 also displays the game screen on the output device 15 (display) of the terminal 20 according to the instructions of the game server 10.

[0037] The control unit 203 works in conjunction with the game server 10 to provide various functions necessary for running the game. For example, the control unit 203 provides functions such as obtaining various information (icon image data, text data, etc.) from the game server 10 for drawing on the game screen.

[0038] Regarding the functional block configuration described above, it is also possible to configure the game server 10 to have all or part of the memory unit 100, control unit 101, display control unit 102, group control unit 103, and recruitment control unit 104 in the terminal 20 as being provided in the memory unit 200 or control unit 203. In other words, the various processes according to this embodiment may be executed on the game server 10, on the terminal 20, or by the game server 10 and the terminal 20 working together.

[0039] <Processing Procedure> Next, we will explain the specific processing steps performed by Game System 1. In the following explanation, the "game medium" used for deck formation and the "game medium" obtained upon clearing quests will be described as characters.

[0040] Here, the storage unit 100 of the game server 10 stores a user management DB (Data Base) 100a that manages each user's game data, a user group management DB 100b that manages data related to user groups, and a character ownership management DB 100c that manages data related to characters owned by each user.

[0041] Figure 5 shows an example of the user management DB 100a and the user group management DB 100b. The user management DB 100a stores, for example, an identifier that uniquely identifies a user (user ID), a nickname used as a username in the game, a friend registration list showing other users who have a predetermined relationship (e.g., friendship) with the user, location information showing the location of the terminal 20 used by the user (e.g., current location), various parameters such as the user's experience points, level, stamina, and the number of points the user possesses, items the user possesses, and the login status to the game, all associated with each other. Online means the user is logged into the game, and offline means the user is not logged into the game.

[0042] The user group management DB100b stores, in association with a unique identifier for each user group (user group ID), the identifier of the user who created the user group (user ID), the user group name, the identifiers of users participating in the user group (participating users), tags associated with the user group, and the execution history of multiplayer activities currently or previously taking place within the user group.

[0043] Tags may include, for example, one or more categories selected from a predetermined set of categories, or keywords that are arbitrary strings of characters. Category names may include, for example, the names of quests that are playable for a limited time, or terms used in the game, or other content that may be of interest to users playing the game.

[0044] The multiplayer execution history stores information indicating whether multiplayer is currently running or has already ended, the user IDs of participating users, information identifying the quest being played or a quest that has been played (such as a quest identifier), and the date and time of the quest (such as the quest start and end times).

[0045] Figure 6 shows an example of the owned character management DB 100c. The owned character management DB 100c stores identifiers that uniquely identify users (user ID), identifiers that uniquely identify characters (character ID), and various parameters that indicate the strength of the characters (level, luck, HP (hit points), attack power, speed, etc.). MAX indicates that the parameter value is the upper limit. Here, a larger value for a character's parameters means that the character is stronger, and it may be possible to increase this by combining identical characters. In other words, it may be possible to generate stronger characters by repeatedly combining characters. Note that identical characters may mean, for example, characters that have at least the same character identifier or character name. In other words, if the character ID or character name is the same, they may be considered the same character even if the parameter values ​​are different.

[0046] (Creating a user group) Figure 7 is a flowchart showing an example of the process steps when a user creates a user group.

[0047] In step S10, the group control unit 103 receives a request from a user who wishes to create a user group to create a new user group. In step S11, the group control unit 103 determines whether or not to allow the user to create a new user group. For example, if there is a limit to the number of user groups that can be created for each user, the group control unit 103 may not allow the creation of more user groups than the limit.

[0048] In step S12, if the group control unit 103 permits the creation of a user group, it creates a new user group and registers a new record in the user group management DB 100b. In step S13, if the group control unit 103 does not permit the creation of a user group, it notifies the user that they cannot create a user group and terminates the process.

[0049] (Joining a user group) Figure 8 is a flowchart showing an example of the process when a user joins a user group.

[0050] In step S20, when the group control unit 103 receives a search request from the user that includes search criteria for user groups, it accesses the user group management DB 100b and retrieves data (user group name, number of members, etc.) related to user groups that match the search criteria. The search criteria include tags specified or entered by the user.

[0051] In step S21, the display control unit 102 displays the acquired user group data on the terminal 20 screen as a list of user groups that the user can specify. The group control unit 103 then accepts the user's selection of a user group from the list of user groups that the user can specify displayed on the screen.

[0052] In step S22, the group control unit 103 accesses the user group management DB 100b and adds the user to the "Participating Users" section of the record for the specified user group.

[0053] Figure 9 shows an example of the screen display when joining a user group. When a tag to search for is specified on the search tag list screen M100, the group control unit 103 searches the "tags" in the user group management DB 100b and extracts one or more user groups that contain the specified tag. The extracted user groups are displayed on the user group list screen M101. The user group list screen M101 displays the number of users belonging to the group, the maximum number of users that can belong, the user group name, and tags (categories and keywords), etc., listed for each user group. The search tag list screen M100 already displays the tags to be searched, but it may also be possible to input any string that indicates the tags to be searched.

[0054] Next, when a user selects a user group they wish to join on the user group list screen M101, the system transitions to the user group details screen M102. The user group details screen M102 displays details such as the user who created the user group and the users who are participating in the user group. When "Yes" is pressed on the user group details screen M102, the group control unit 103 adds the user to the "Participating Users" in the user group management DB 100b.

[0055] (Multiplayer within a user group) Figure 10 is a flowchart showing an example of the processing procedure when conducting multiplayer within a user group. In step S30, the recruitment control unit 104 receives a request from a user who is recruiting for multiplayer. The host user (i.e., the recruiting control unit) accepts the designation of a quest to be played in multiplayer mode. In step S31, the recruiting control unit 104 accepts the host user's designation of a user group to recruit for multiplayer mode.

[0056] In step S32, the recruitment control unit 104 refers to the user group management DB 100b and extracts users belonging to the specified user group (i.e., users to be recruited). Specifically, the recruitment control unit 104 extracts users other than the host user from among the users stored in the "creating user" and "participating user" fields of the specified user group record in the user group management DB 100b as users to be recruited. Subsequently, the recruitment control unit 104 notifies the extracted users to join the multiplayer game. This notification may be made, for example, by displaying the user group name and the host user's username on the "Participating User Recruitment List" screen displayed on the terminal 20 of the users to be recruited.

[0057] In step S33, if the recruitment control unit 104 receives a request to join the multiplayer game from one or more of the recruiting users (i.e., guest users), it proceeds to step S34. On the other hand, if the recruitment control unit 104 does not receive a request to join the multiplayer game from any of the recruiting users, it proceeds to step S35. The recruitment control unit 104 may also proceed to step S35 if it has not received a request to join the multiplayer game for a predetermined period of time after receiving the user group designation from the host user in the processing procedure of step S31.

[0058] In step S34, the control unit 101 executes a quest in multiplayer mode with the host user and guest users.

[0059] In step S35, the recruitment control unit 104 determines that the multiplayer session did not start and cancels the recruitment for the multiplayer session, ending the process. At this time, the recruitment control unit 104 (display control unit 102) may delete the user group name, the host user's username, etc. from the "Participating User Recruitment List" screen, etc., displayed on the terminal 20 of the recruiting user. The recruitment control unit 104 may also store information indicating that the multiplayer session did not start, and the date and time when it was determined that the multiplayer session did not start, in the "Multiplayer Execution History" of the user group management DB 100b.

[0060] Figure 11 shows an example of the screen when recruiting for multiplayer. When the host user selects a quest on the quest selection screen M200, the screen transitions to screen M201, where the host user can specify the method for recruiting for multiplayer. On screen M201, the host user can select one of the following methods for recruiting for multiplayer: recruiting users who are friends and are physically close, recruiting via social networking services, or recruiting by specifying a user group. When the host user presses the "User Group" button to recruit by specifying a user group, the screen transitions to the user group specification screen M202. The user group specification screen M202 accepts the specification of the user group to recruit for multiplayer, and displays a list of available user groups. Once the host user selects a user group on the user group specification screen M202, the screen transitions to the guest user participation status screen M203. The guest user participation status screen M203 displays a list of users (guest users) who have requested to participate among the recruited users. In the example in Figure 11, the host user... This indicates that there have been no participation requests yet from users who were invited to join the multiplayer game hosted by (aaa). The multiplayer game will start once at least one participation request has been received from an invited user, and the host user presses the "Start" button.

[0061] Here, the user group selection screen M202 displays "information regarding the likelihood of a multiplayer game being established" for each user group. For example, in the example in Figure 11, the information regarding the likelihood of a multiplayer game being established is the elapsed time since the last multiplayer game ended within the user group. In the case of Group A, it is displayed as "Elapsed time: 48 hours ago," indicating that no multiplayer games have been played for two days. On the other hand, Group B shows that a multiplayer game was played just 5 minutes ago. In this case, the host user can determine that it is more likely to be successful to recruit players for a multiplayer game targeting Group B or C rather than Group A.

[0062] Figure 12 shows an example of the screen when joining a multiplayer game. When the "Join Multiplayer" button is pressed on the game screen M300 displayed on the recruiting user's terminal 20, the screen transitions to the multiplayer recruitment list screen M301, which displays a list of multiplayer games that are recruiting participants. The multiplayer recruitment list screen M301 displays recruitment for multiplayer games that specify a user group, recruitment for multiplayer games from users who are friends and are physically close to the user, and recruitment for multiplayer games via social networking services, each in a distinct manner. Recruitment for multiplayer games that specify a user group, as displayed on the multiplayer recruitment list screen M301, is displayed when a multiplayer game is being recruited by the user group to which the recruiting user belongs. Users can join a multiplayer game by selecting the multiplayer game they wish to join from the list. If the "Join Multiplayer" button is pressed on the game screen M300 and there are no available multiplayer games, a message indicating that there are no available multiplayer games will be displayed, as shown in screen M302.

[0063] <Information regarding the ease of establishing multiplayer matches> Next, we will explain several display examples regarding the ease of establishing a multiplayer game. The display examples described below can be combined as desired.

[0064] (Example 1) When the display control unit 102 receives a selection of a quest (game) from the host user for which it is recruiting for multiplayer, it may display information regarding the ease of establishing multiplayer, specifically information about users who do not meet the requirements for possessing characters obtainable in the selected quest, for each user group. The characters obtainable in the selected quest may, for example, be characters given to each user who participates in multiplayer upon clearing the quest.

[0065] Furthermore, the "possession requirement" may be that the player possesses a character obtainable in the selected quest that meets a predetermined condition. The predetermined condition may be, for example, that the predetermined parameter value, which increases by combining identical characters, is at its maximum value.

[0066] In other words, the display control unit 102 may display, for each group, the number of users belonging to the group who do not possess a character that is obtainable in the quest selected by the host user and whose predetermined parameter values ​​are at their maximum, as information regarding the ease of establishing a multiplayer game.

[0067] For example, let's assume that the character name of the character obtainable in Quest A, selected by User X who is recruiting for multiplayer, is Character A. Let's also assume that Group 1, to which User X belongs, has 10 other users, and that 3 of these users possess Character A with the specified parameter values ​​at their maximum (MAX). Let's also assume that Group 2, to which User X belongs, has 13 other users, and that 10 of these users possess Character A with the specified parameter values ​​at their maximum.

[0068] In this case, the display control unit 102 may display information on the ease of establishing multiplayer on the user X's screen (for example, M202 in Figure 11), such as "Max character owned: 7 users" for group 1 and "Max character owned: 3 users" for group 2.

[0069] Users who already possess a character with maximum parameter values ​​are unlikely to want to play multiplayer, as they do not need to acquire and synthesize that character. On the other hand, users who do not possess a character with maximum parameter values ​​are likely to want to participate in multiplayer in order to acquire that character as synthesis material. Therefore, user X can determine that it is more likely to successfully arrange multiplayer matches by specifying a user group with a large number of users who do not possess a character with maximum parameter values ​​and recruiting them for multiplayer.

[0070] As another example, the "possession requirement" described above may be that the player possesses a predetermined number of characters obtainable in the selected quest. The predetermined number may be, for example, the number of characters required to maximize a predetermined parameter value that is increased by combining identical characters.

[0071] In other words, the display control unit 102 may display, for each group, the number of users belonging to the group who do not possess a predetermined number of characters that are obtainable in the quest selected by the host user, as information regarding the ease of establishing a multiplayer game.

[0072] For example, let's assume that combining identical characters increases a predetermined parameter value by 1 each time. We also assume that the minimum value of the predetermined parameter value is 1 and the maximum value is 99. Furthermore, we assume that the predetermined parameter value of a character obtained upon clearing a quest is 1 (i.e., the minimum value). In this case, combining 99 characters will bring the predetermined parameter value to its maximum value. Therefore, the "predetermined number" can be 99.

[0073] Users who already possess a certain number of characters obtainable from quests offering multiplayer opportunities are unlikely to want to participate in multiplayer, as they can maximize the parameter values ​​of those characters by combining them. On the other hand, users who do not possess a certain number of characters obtainable from quests offering multiplayer opportunities are likely to want to participate in multiplayer in order to collect more characters. Therefore, user X can determine that it is more likely to successfully arrange multiplayer matches by specifying a user group with a large number of users who do not possess a certain number of characters obtainable through multiplayer.

[0074] Furthermore, the "specified number" mentioned above may be 1. In the game, there are users who play with the sole purpose of collecting many characters without synthesizing them. Such users are unlikely to want to participate in multiplayer if they already possess the characters obtainable in the quests that can be played in multiplayer, as they have no need to play those quests. Therefore, setting the "specified number" to 1 will display the number of users who do not possess any characters obtainable in the quests for each user group. Consequently, user X can determine that it is easier to find a multiplayer match by specifying a user group with a large number of users who do not possess characters obtainable in multiplayer and recruiting for multiplayer.

[0075] Furthermore, as another condition, the "possession condition" mentioned above may be that the character is obtainable in the selected quest, and when all of the characters already owned by the user are combined, the predetermined parameter values ​​of that character will reach their maximum values.

[0076] In other words, the display control unit 102 may display, for each group, the number of users belonging to the group who, even after combining all the characters they already possess, are unable to create a character whose predetermined parameter values ​​are at their maximum, as information regarding the ease of establishing a multiplayer game.

[0077] Users who can create a character with maximum parameter values ​​by combining characters they already own are unlikely to want to play multiplayer, as they do not need to acquire that character further. On the other hand, users who cannot create a character with maximum parameter values ​​by combining characters they already own are likely to want to participate in multiplayer in order to acquire that character further. Therefore, user X can determine that it is more likely to successfully arrange multiplayer matches by specifying a user group with a large number of users who cannot create a character with maximum parameter values ​​by combining characters they already own.

[0078] As shown in the example display 1 described above, since a user group is specified after a quest is designated to recruit players for multiplayer, it becomes possible to use quest-related information for recruiting players for multiplayer.

[0079] (Example 2) When the display control unit 102 receives a selection of a quest (game) for which a host user (first user) is recruiting for multiplayer, it may display information about users who meet the participation conditions for the selected quest for each user group as information about the ease of establishing multiplayer. The participation conditions for a quest can be any conditions, but for example, the user's parameters (e.g., level, experience points, etc.) may be above a predetermined value, or the parameters of the character owned may be above a predetermined value.

[0080] For example, if a quest requires users to be level 50 or higher, a user group with many level 50 users is more likely to have more users wanting to participate in multiplayer than a user group with very few level 50 users. Therefore, users can determine that it is easier to find a group for multiplayer by specifying a user group with many users who meet the participation requirements.

[0081] (Example 3) When the display control unit 102 receives a selection of a quest (game) for which a host user (first user) is soliciting multiplayer players, it may display information about users who meet the clearing conditions of the selected quest for each user group as information about the ease of establishing a multiplayer game. The clearing conditions for a quest are the minimum level of users who can clear the quest, and may be predetermined for each quest by the game administrator or the like. For example, the user's parameters (e.g., level, experience points, etc.) may be above a predetermined value, or the parameters of the characters that make up the deck may be above a predetermined value.

[0082] For example, if a quest's completion requirement is set to level 50 or higher, users below level 50 may determine that completing the quest is difficult and may not participate in multiplayer. In other words, a user group with many level 50 users is more likely to have users who want to participate in multiplayer than a user group with very few level 50 users. Therefore, users can determine that it is easier to find a match by specifying a user group with many users who meet the completion requirements when recruiting for multiplayer.

[0083] (Example 4) When the display control unit 102 receives a selection of a quest (game) for which a host user (first user) is soliciting multiplayer players, it may display information about users who do not meet the clearing conditions of the selected quest, broken down by user group, as information regarding the likelihood of successful multiplayer play. The quest clearing conditions are the same as those in Display Example 3, so their explanation is omitted.

[0084] For example, if a quest's completion requirement is set to level 50 or higher, users below level 50 may determine that completing the quest is difficult and therefore not participate in multiplayer. However, if the host user is level 50 or higher, users below level 50 may believe they can complete the quest with the host user's help and therefore participate in multiplayer. Consequently, users can determine that it is more likely to result in successful multiplayer matches if they specify a user group with many users who do not meet the completion requirements when recruiting for multiplayer.

[0085] (Example 5) The display control unit 102 may also display information regarding the ease of establishing a multiplayer game, specifically information about users who have previously played multiplayer with the host user (first user), for each user group. This information may be the number of users belonging to a user group who have played multiplayer with the host user (first user).

[0086] For example, let's assume that in Group 1, there are 5 users other than User X who have previously played multiplayer with User X, while in Group 2, there are none. In this case, a user group with many users who have previously played multiplayer with User X is likely to have more users who will participate in multiplayer with User X in the future compared to a user group with few users who have previously played multiplayer with User X. Therefore, a user can determine that it is more likely to successfully arrange a multiplayer session by specifying a user group with many users who have previously played multiplayer with them.

[0087] (Example 6) The display control unit 102 may display information regarding the ease of establishing a multiplayer game for each user group, such as the frequency with which multiplayer games are played within the user group, the elapsed time since the most recent multiplayer game in the user group ended, or the history of multiplayer games played within the user group. The frequency with which multiplayer games are played within a user group may be, for example, the number of times multiplayer games have been played within a predetermined period in the past. For example, if the predetermined period in the past is set to 24 hours, the display control unit 102 may display the number of times multiplayer games have been played within the last 24 hours from the current time for each user group. The history of multiplayer games may include information about the most recent multiplayer game (start time, end time, number of guest users, etc.) for a predetermined number of times (for example, 1 to 3 times ago). A user group that frequently plays multiplayer is more likely to have more users wanting to participate in multiplayer than a user group that plays less frequently. Similarly, a user group that hasn't played multiplayer in a long time is more likely to have more users wanting to participate than a user group that hasn't played multiplayer in a long time. Therefore, users can determine that they are more likely to find a match by specifying a user group that plays multiplayer frequently or has played multiplayer recently when recruiting for a game.

[0088] (Example 7) The display control unit 102 may also display information regarding the ease of establishing a multiplayer game, such as the number of online users (i.e., the number of users logged into the game) or the percentage of online users (the percentage of users online out of all users belonging to the user group), for each user group. Since online users are presumably operating the terminal 20 to open the game screen, user groups with many online users are likely to have more users participating in multiplayer than user groups with few online users. Therefore, users can determine that it is easier to establish a multiplayer game by specifying a user group with many logged-in users when recruiting for a multiplayer game.

[0089] (Example 8) The display control unit 102 may also display, as information regarding the ease of establishing a multiplayer game, the number of users who are online and not currently playing any quest, for each user group. "Any quest" includes all quests, not just those selected by the host user (the same applies in the following explanation). As mentioned above, online users are presumably operating the terminal 20 to open the game screen. Also, users who are not currently playing a quest can immediately join a multiplayer game. Therefore, user groups with many users who are online and not playing a quest are likely to have more users available to participate in multiplayer than user groups with few users who are either online or not playing a quest. Consequently, users can determine that it is easier to establish a multiplayer game by specifying a user group with many users who are online and not playing a quest when recruiting for a multiplayer game.

[0090] (Example 9) The display control unit 102 may also display the number of multiplayer games currently running among users belonging to each user group, as information regarding the ease of establishing a multiplayer game. Multiplayer games are played by multiple users, and one user cannot participate in multiple multiplayer games simultaneously. Therefore, user groups with many multiplayer games running are likely to have fewer users available to participate in multiplayer games than user groups with fewer running multiplayer games. Consequently, users can determine that it is easier to establish a multiplayer game by specifying a user group with fewer currently running multiplayer games when recruiting players for a multiplayer game.

[0091] (Example 10) When the display control unit 102 receives a selection of a quest (game) for which a host user (first user) is recruiting for multiplayer, it may display the number of users who possess characters effective for clearing the quest for each user group as information regarding the likelihood of a multiplayer session being established. "Characters effective for clearing the quest" are characters that, when included in a deck, can give the player an advantage in the quest. For example, these may be characters with the same attribute as the quest, characters with higher parameter values ​​than the enemy characters appearing in the quest, or characters with an attribute that can inflict more damage than other attributes on enemy characters appearing in the quest. Users who possess characters effective for clearing the quest are likely to be able to clear the quest easily and are therefore more likely to participate in multiplayer. Consequently, a user can determine that it is easier to establish a multiplayer session by specifying a user group with a large number of users who possess characters effective for clearing the quest when recruiting for multiplayer.

[0092] (Example 11) When the display control unit 102 receives a selection of a quest (game) for which a multiplayer game is to be recruited from the host user (first user), it may display the number of users who have previously cleared the quest for each user group as information regarding the likelihood of a multiplayer game being formed. Users who have previously cleared the quest are likely to challenge the quest again. Therefore, a user can determine that it is easier to form a multiplayer game by specifying a user group with a large number of users who have previously cleared the quest when recruiting for a multiplayer game.

[0093] (Example 12) In addition to the display examples described above, the display control unit 102 may also display information indicating that a predetermined percentage of users are currently playing a given quest, and the estimated time until the percentage of users playing that quest falls below a predetermined level, for groups where a predetermined percentage of users are currently playing that quest. The display control unit 102 may also predict the time when each quest will end using a predetermined average play time for each quest, and calculate the estimated time until the percentage of users playing that quest falls below a predetermined level based on the predicted end time of each quest. This makes it possible for users to avoid user groups where a predetermined percentage of users are already playing a quest (i.e., user groups where multiplayer is unlikely to be established) when recruiting for multiplayer. Furthermore, even if a user wants to specify a user group where a predetermined percentage of users are currently playing a quest, they can control the process to make it easier for multiplayer to be established by waiting until the estimated time until the percentage of users playing the quest falls below a predetermined level before recruiting for multiplayer.

[0094] <About the User Group Selection Screen> Next, we will explain several display examples for the user group specification screen (for example, M202 in Figure 11), which accepts the host user's specification of a user group to recruit for multiplayer.

[0095] (Example A) The display control unit 102 may also display the user groups to which the host user (first user) belongs on the user group selection screen, as user groups that the host user (first user) can specify to recruit players for multiplayer. For example, if user X belongs to user group 1, user group 2, and user group 3, the display control unit 102 may display user group 1, user group 2, and user group 3 as a list on user X's user group selection screen.

[0096] (Display example B) The display control unit 102 may also display, on the user group selection screen, user groups that satisfy the first predetermined condition but to which the host user (first user) does not belong, in addition to the user group to which the host user (first user) belongs. Since the user groups that satisfy the first predetermined condition but to which the host user does not belong are user groups that are displayed in addition to the user group selection screen, they will be referred to as "additional groups" in the following description. For example, in the user group selection screen M202 of Figure 11, the display control unit 102 may also display the group name, etc., of the user groups that correspond to additional groups in addition to the user group to which the host user belongs.

[0097] A group that satisfies the first predetermined condition may be a user group whose indicator of user group activity is above a predetermined value. The higher the value of the indicator, the more active the user group is.

[0098] The indicators showing the activity status of a user group may be any of the following indicators No. 1 to No. 4. No. 1. An indicator showing the frequency of multiplayer games being played within the user group. The higher the frequency, the larger the value of this indicator. The frequency of multiplayer games being played may be the same as explained in Display Example 6.

[0099] No. 2. An indicator showing the elapsed time since the last multiplayer session within a user group. The longer the elapsed time, the smaller the value. No. 3. The number of users who are online, or the percentage of users in a user group who are online. No. 4. The number of users who are online but not playing a quest, or the percentage of users in a user group who are online but not playing a quest.

[0100] Furthermore, a group that meets the first predetermined condition may be a user group that is highly likely to have users who wish to participate when a multiplayer session is advertised. For example, it may be one of the user groups No. 5 to No. 11 shown below. No. 5. A user group in which the number of users who do not meet the requirements for possessing a character obtainable in a quest selected by the host user is a predetermined number or more, or the proportion of users belonging to the user group who do not meet the requirements for possessing a character obtainable in a quest selected by the host user is a predetermined proportion or more. The requirements for possession may be the same as those explained in Display Example 1.

[0101] No. 6. A user group in which the number of users who meet the participation requirements for a quest selected by the host user is greater than or equal to a predetermined number, or in which the proportion of users belonging to the user group who meet the participation requirements for a quest selected by the host user is greater than or equal to a predetermined proportion. The participation requirements may be the same as those explained in Display Example 2.

[0102] No. 7. A user group in which the number of users who meet the completion conditions of the quest selected by the host user is greater than or equal to a predetermined number, or in which the proportion of users belonging to the user group who meet the completion conditions of the quest selected by the host user is greater than or equal to a predetermined proportion. The completion conditions may be the same as those explained in Display Example 3.

[0103] No. 8. A user group in which the number of users who have previously played multiplayer with the host user is greater than or equal to a specified number, or in which the proportion of users belonging to the user group who have previously played multiplayer with the host user is greater than or equal to a specified percentage.

[0104] No. 9. User groups in which the number of currently running multiplayer games among users belonging to the user group is below a specified number.

[0105] No. 10. A user group in which the number of users possessing characters capable of clearing the quest selected by the host user is greater than or equal to a predetermined number, or in which the proportion of users belonging to the user group possessing characters capable of clearing the quest selected by the host user is greater than or equal to a predetermined proportion. The characters capable of clearing the quest may be the same as those described in Display Example 10.

[0106] No. 11. A user group in which the number of users who have previously completed a quest selected by the host user is greater than or equal to a predetermined number, or in which the number of users belonging to the user group who have previously completed a quest selected by the host user is greater than or equal to a predetermined percentage.

[0107] Furthermore, in Display Example B, the group that satisfies the first predetermined condition may be a user group to which tags are assigned that are all or partly identical to the tags assigned to the user group to which the host user belongs. As shown in the example B described above, the host user can designate not only the user group to which they belong, but also active user groups to which they do not belong, as user groups to which they will recruit for multiplayer.

[0108] (Display example C) The display control unit 102 may display additional groups on the user group selection screen if the information regarding the ease of establishing multiplayer in the user group to which the host user belongs does not satisfy the second predetermined condition. More specifically, the display control unit 102 may display additional groups on the user group selection screen if the information regarding the ease of establishing multiplayer in at least some of the user groups to which the host user belongs does not satisfy the second predetermined condition. Alternatively, the display control unit 102 may display additional groups on the user group selection screen if the information regarding the ease of establishing multiplayer in all user groups to which the host user belongs does not satisfy the second predetermined condition.

[0109] If the information regarding the ease of establishing multiplayer does not satisfy the second predetermined condition, it may also be the case that the indicator showing the activity status of the user group is below a predetermined value. In this case, the indicator showing the activity status of the user group may be the same as the indicators No. 1 to No. 4 explained in Display Example B.

[0110] Furthermore, if the information regarding the ease of establishing a multiplayer game does not meet the second predetermined condition, it may also mean that even if a multiplayer game is advertised, there is a low probability that there will be users who wish to participate (i.e., it is difficult to establish a multiplayer game). Specifically, this may include cases No. 12 to No. 18 shown below. Note that No. 12 to No. 18 correspond to No. 5 to No. 11 mentioned above, respectively. No. 12. If the number of users who do not meet the requirements for possessing a character obtainable in a quest selected by the host user is less than a predetermined number, or if the proportion of users belonging to a user group who do not meet the requirements for possessing a character obtainable in a quest selected by the host user is less than a predetermined proportion. The requirements for possession may be the same as those explained in Display Example 1.

[0111] No. 13. If the number of users who meet the participation requirements for a quest selected by the host user is less than the specified number, or if the percentage of users belonging to a user group who meet the participation requirements for a quest selected by the host user is less than the specified percentage. The participation requirements may be the same as those explained in Display Example 2.

[0112] No. 14. If the number of users who meet the completion conditions for the quest selected by the host user is less than a predetermined number, or if the percentage of users belonging to a user group who meet the completion conditions for the quest selected by the host user is less than a predetermined percentage. The completion conditions may be the same as those explained in Display Example 3.

[0113] No. 15. If the number of users who have previously played multiplayer with the host user is less than the specified number, or if the proportion of users belonging to a user group who have previously played multiplayer with the host user is less than the specified proportion.

[0114] No. 16. When the number of ongoing multiplayer games among users belonging to the user group is less than the specified number.

[0115] No. 17. If the number of users who possess a character capable of clearing the quest selected by the host user is less than the predetermined number, or if the proportion of users belonging to a user group who possess a character capable of clearing the quest selected by the host user is less than the predetermined proportion. The character capable of clearing the quest may be the same as described in Display Example 10.

[0116] No. 18. If the number of users who have previously completed a quest selected by the host user is less than a predetermined number, or if the number of users belonging to a user group who have previously completed a quest selected by the host user is less than a predetermined percentage.

[0117] Furthermore, the additional group in Display Example C may be another user group to which tags are assigned that are all or partly identical to the tags assigned to the user group to which the host user belongs. As shown in the example display C described above, if the host user's own user group is not actively operating, they can designate an active user group that they do not belong to as the user group to recruit for multiplayer.

[0118] (Display example D) If the recruitment of a multiplayer game for the target user (second user) is unsuccessful, the display control unit 102 may add and display other user groups, different from the at least one user group designated by the host user as the target of the recruitment, as groups that the host user can specify to recruit for multiplayer games. If the recruitment of a multiplayer game is unsuccessful, for example, as explained in step S33 of Figure 10, it may be the case that no request to participate in multiplayer games is received from the host user after a predetermined time has elapsed since the host user specified the user group to recruit for multiplayer games. Furthermore, the above-mentioned other user groups may be the same as the additional group explained in display example B.

[0119] This allows the host user to recruit other user groups for multiplayer even if the initial recruitment fails. Furthermore, even if the initial recruitment fails, the host user can recruit other user groups that are more likely to be recruited.

[0120] (Display example E) The display control unit 102 may, if the information regarding the ease of establishing multiplayer in the group to which the host user belongs does not satisfy the second predetermined condition, display information on the terminal 20 screen recommending that the host user change the user group to which the host user belongs to a user group to which the host user does not belong that satisfies the first predetermined condition (i.e., the same as the additional group described in Display Example B). Furthermore, if the information regarding the ease of establishing multiplayer does not satisfy the second predetermined condition, the explanation may be the same as in Display Example C.

[0121] For example, the display control unit 102 may display a message on screen M302 in Figure 12 recommending that the user join an additional group in addition to / change their current user group.

[0122] This will allow users to change their affiliation from a user group where multiplayer is difficult to establish to a user group where multiplayer is easier to establish.

[0123] <Summary> According to the embodiment described above, the game server 10 is configured to prevent recruiting users for multiplayer games from being sent to user groups where it is unlikely that a multiplayer game will be formed. This makes it possible to provide a technology that prevents multiplayer game recruitment from being wasted.

[0124] The embodiments described above are provided to facilitate understanding of the present invention and are not intended to limit its interpretation. The flowcharts, sequences, elements of the embodiments, and their arrangement, materials, conditions, shapes, and sizes described in the embodiments are not limited to those exemplified and can be modified as appropriate.

[0125] <Note> <Note 1> A display control unit that displays information regarding the ease of establishing a multiplayer game for each group on a screen where the first user requests a group to play a game together, A recruitment control unit that recruits a second user for the multiplayer game to a second user belonging to at least one group specified by the first user, An information processing device having According to Appendix 1, it becomes possible to prevent the waste of recruitment for multiplayer games that specify a group.

[0126] <Note 2> When the display control unit receives a selection of a game from the first user for which to solicit multiplayer participation, it displays information about users who do not meet the requirements for possessing game media available for the selected game, grouped by type. The information processing device described in Appendix 1. According to Appendix 2, the first user will be able to identify groups of users who do not meet the requirements for possessing game media available in the game selected by the first user, and then specify which groups will be recruiting for multiplayer.

[0127] <Note 3> When the display control unit receives a selection of a game for which a multiplayer invitation is to be made from the first user, it displays information about users who meet the participation requirements for the selected game, grouped by type 9. The information processing device described in Appendix 1 or 2. According to Appendix 3, the first user will be able to identify groups of users who meet the participation requirements for the game they have selected, and then specify which groups will be recruiting players for multiplayer.

[0128] <Note 4> The display control unit displays information about users who have previously played multiplayer with the first user, grouped by type. An information processing device as described in any one of the appendices 1 to 3. According to Appendix 4, the first user will be able to access information about users who have previously played multiplayer with them, group by group, and then specify which group to recruit for multiplayer.

[0129] <Note 5> The display control unit displays the group to which the first user belongs on the screen as a group that recruits participants for the multiplayer game that the first user can specify. An information processing device as described in any one of the appendices 1 to 4. According to Appendix 5, the first user will be able to designate a group from among the groups to which they belong that is recruiting for multiplayer.

[0130] <Note 6> The display control unit displays on the screen, in addition to the group to which the first user belongs, additional groups that satisfy the first predetermined conditions but to which the first user does not belong. The information processing device described in Appendix 5. According to Appendix 6, the first user will be able to specify which group to recruit for multiplayer from among the group they belong to and any additional groups.

[0131] <Note 7> The display control unit displays the additional group on the screen if the information regarding the ease of establishing the multiplayer in the group to which the first user belongs does not satisfy the second predetermined condition. The information processing device described in Appendix 6. According to Appendix 7, if the information regarding the ease of forming a multiplayer game within the group to which the first user belongs does not meet the second predetermined condition, the first user will be able to designate a group from among the additional groups to recruit for multiplayer.

[0132] <Note 8> If the request for the multiplayer game made to the second user is unsuccessful, the display control unit will display a group other than the at least one group as a group that the first user can specify to request the multiplayer game. An information processing device as described in any one of the appendices 1 to 7. According to Appendix 8, if the first user fails to recruit players for multiplayer, they will be able to designate a different group from the one that originally recruited players for multiplayer.

[0133] <Note 9> The recruitment control unit makes a recruitment for the multiplayer game to the second user who belongs to each of the multiple groups specified by the first user. An information processing device as described in any one of the appendices 1 to 8. According to Appendix 9, the first user will be able to specify multiple groups and recruit players for multiplayer.

[0134] <Note 10> The display control unit, if the information regarding the ease of establishing the multiplayer in the group to which the first user belongs does not satisfy the second predetermined condition, displays information on the screen recommending that the first user change the group to which the first user belongs to an additional group that satisfies the first predetermined condition from among the groups to which the first user does not belong. An information processing device as described in any one of the appendices 1 to 9. According to Appendix 10, if the information regarding the ease of establishing multiplayer in the group to which the first user belongs does not satisfy the second predetermined condition, the first user may change their group to another group to which they do not belong, but which satisfies the first condition.

[0135] <Note 11> The process involves a screen where the first user requests a group to form a group for a multiplayer game where multiple users play together, and displays information regarding the likelihood of the multiplayer game being formed for each group. The steps include: making a request for the multiplayer game to a second user who belongs to at least one group specified by the first user; An information processing method having According to Appendix 11, it becomes possible to prevent the waste of recruitment for multiplayer games that specify a group.

[0136] <Note 12> The computer displays information regarding the ease with which a group can be formed for a multiplayer game, on a screen where the first user requests a group to form for a multiplayer game where multiple users play together. The computer makes a request for the multiplayer game to a second user who belongs to at least one group specified by the first user, A program that causes a computer to execute something. According to Appendix 12, it becomes possible to prevent the waste of recruitment for multiplayer games that specify a group. [Explanation of symbols]

[0137] 10...Game server, 11...Processor, 12...Storage device, 13...Communication interface, 14...Input device, 15...Output device, 20...Terminal, 100...Storage unit, 100a...User management DB, 100b...User group management DB, 100c...Owned character management DB, 101...Control unit, 102...Display control unit, 103...Group control unit, 104...Recruitment control unit, 200...Storage unit, 201...Communication unit, 202...UI unit, 203...Control unit

Claims

1. The first user's terminal displays a first screen for the first user to select a group to recruit opponents for multiplayer, and the first screen displays multiple groups, each containing one or more users, and text indicating the elapsed time since the end of multiplayer for each group. After the first user specifies a group on the first screen, a second screen is displayed on the first user's terminal to recruit users from among the users included in the specified group to participate in the quest specified by the first user. The second screen displays a list of users included in the specified group who have requested to participate. Information processing device.

2. The processor causes the first user's terminal to display a first screen for the first user to select a group to recruit opponents for multiplayer, the first screen displaying multiple groups, each containing one or more users, and text indicating the elapsed time since the end of multiplayer for each group. After the first user has specified a group on the first screen, the processor displays a second screen on the first user's terminal that recruits users from among the users in the specified group to participate in the quest specified by the first user, and the second screen displays a list of users from among the users in the specified group who have requested to participate. Information processing methods.

3. A first screen is displayed on the first user's terminal display for the first user to select a group to recruit opponents for multiplayer, and the first screen displays multiple groups, each containing one or more users, and text indicating the elapsed time since the end of multiplayer for each group. After the first user specifies a group on the first screen, a second screen is displayed on the display to recruit users from among the users included in the specified group to participate in the quest specified by the first user. The second screen displays a list of users included in the specified group who have requested to participate. A program that instructs the processor to perform a task.

4. Equipped with a server and terminals, The aforementioned server, A first screen is displayed on the first user's terminal for the first user to select a group to recruit opponents for multiplayer, and the first screen displays multiple groups, each containing one or more users, and text indicating the elapsed time since the end of multiplayer for each group. After the first user specifies a group on the first screen, the terminal displays a second screen that recruits users from among the users in the specified group to participate in the quest specified by the first user. The second screen displays a list of users from among the users in the specified group who have requested to participate. system.

Images