Information processing device, information processing method, and program

By displaying and controlling the ease of multiplayer game information in the game system, the problem of difficulty for host users to recruit users with similar skills and goals is solved, and the success rate and efficiency of multiplayer games are improved.

JP7624143B2Active Publication Date: 2025-01-30MIXI INC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
JP2021179302
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2021-11-02
Publication Date
2025-01-30
Estimated Expiration
2041-11-02

AI Technical Summary

Technical Problem

In multiplayer games, it is difficult for host users to effectively recruit skills and passenger aircraft users with similar goals to their multiplayer cooperation, resulting in waste of multiplayer recruitment.

Method used

By introducing a display control unit and a recruitment control unit in the game system, displaying the ease of multiplayer games and conducting recruitment control for specific user groups, ensuring the similarity between user group members and game purpose, and improving the success rate of multiplayer games.

Benefits of technology

It effectively reduces the waste of multiplayer game recruitment, improves the efficiency of cooperation among user groups, and ensures the smooth progress of multiplayer games.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007624143000001
    Figure 0007624143000001
  • Figure 0007624143000002
    Figure 0007624143000002
  • Figure 0007624143000003
    Figure 0007624143000003
Patent Text Reader

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
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

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

[0002] There is a known game in which a player clears a quest using a team of multiple characters called a deck. There is also a known game format called multiplay in which multiple users play a quest together. For example, Patent Document 1 discloses a game in which a user executes a quest using a player character owned by the user. [Prior art documents] [Patent documents]

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

[0004] When playing a game in a multiplayer mode, it is common for a host user to invite guest users to participate in the multiplayer mode. In this case, it is preferable for users with similar skills and playing purposes to play together, as this makes it easier for them to cooperate with each other within the team. Therefore, it is possible to form groups of similar users in advance and have the users in the group play the multiplayer mode.

[0005] However, when groups are formed, there may be some groups that are active (for example, a group with many users playing a game) and some groups that are not active (for example, a group with few users playing a game). Therefore, when a host user invites guest users to participate in a multiplayer game, if the host invites guest users from a group that is not active, there may be no applications from guest users and the multiplayer game may not be established.

[0006] Therefore, an object of the present invention is to provide a technique that can prevent a multiplayer invitation from going to waste. [Means for solving the problem]

[0007] An information processing device according to one embodiment of the present invention has a display control unit that displays information regarding the ease of establishing a multiplayer game for each group on a screen that accepts, from a first user, the designation of a group to invite users to a multiplayer game in which multiple users play a game together, and a recruitment control unit that invites second users who belong to at least one group designated by the first user to invite users to the multiplayer game. Effect of the Invention

[0008] According to the present invention, it is possible to provide a technique that makes it possible to prevent a multiplayer invitation from going to waste. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram showing an example of a system configuration of a game system according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram showing an example of the hardware configuration of a game server and a terminal. [Diagram 3] FIG. 2 is a diagram showing an example of a functional block configuration of a game server. [Figure 4] FIG. 2 is a diagram showing an example of a functional block configuration of a terminal. [Diagram 5]4A and 4B are diagrams showing examples of a user management DB and a user group management DB. [Figure 6] FIG. 13 is a diagram showing an example of an owned character management DB. [Figure 7] 11 is a flowchart showing an example of a processing procedure when a user creates a user group. [Figure 8] 11 is a flowchart showing an example of a processing procedure when a user joins a user group. [Figure 9] FIG. 13 is a diagram showing an example of a screen display when joining a user group. [Figure 10] 11 is a flowchart showing an example of a processing procedure when a multiplay is performed within a user group. [Figure 11] FIG. 13 shows an example of a screen when inviting players to play multiplayer. [Figure 12] FIG. 13 shows an example of a screen when joining a multiplayer game. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described with reference to the accompanying drawings, in which the same reference numerals denote the same or similar configurations.

[0011] <System configuration> Fig. 1 is a diagram showing an example of a system configuration of a game system 1 according to this embodiment. The game system 1 shown in Fig. 1 includes 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 with each other via a communication network N such as the Internet, an intranet, a wireless LAN, or mobile communication.

[0012] The game server 10 is a device that performs some of the functions required for the terminal 20 to provide a game, such as managing various information related to players and executing some of the game processing. The game server 10 may be composed of one or more information processing devices, or may be composed of a virtual server (such as a cloud server).

[0013] The terminal 20 is an information processing device that provides a game to a player, and the player 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 a GPS (Global Positioning System) or the like.

[0014] <Game Overview> Next, an 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 be called a player) can obtain new game media and items by organizing a deck with game media selected from a plurality of game media owned by the user and clearing quests using the organized deck. In addition, the user can generate a stronger character by synthesizing the plurality of game media obtained, or can challenge a quest with a higher level of difficulty by strengthening the attributes of the game media using items. The game media may be referred to as game objects. In addition, the game media may be characters, game cards, etc.

[0015] A quest is a term meaning a task that can be cleared by satisfying certain predetermined conditions. A quest is also generally called a search, a task, or a mission. A user playing a quest can clear the quest by satisfying the certain conditions, and when the user clears the quest, a reward is given to the user and the story of the game progresses. Note that, although this embodiment assumes that various quests are provided in the game, this embodiment is not limited to this. The term "quest" in this embodiment may mean the game itself.

[0016] A deck is a term meaning a team made up of multiple game media. When a user executes a quest, the user selects game media having the appropriate abilities to clear the quest, organizes a deck, and plays the quest. The game server 10 can store multiple decks organized by users, and the user can select one deck from the multiple stored decks to play a quest. In this embodiment, the user playing a quest may be referred to as executing a quest. Also, in this embodiment, playing a quest may be referred to as playing a game or executing a game.

[0017] A quest can be played by multiple users together. Hereinafter, playing a quest by multiple users together is referred to as "multiplay". Multiplay may be called cooperative play. On the other hand, playing a quest by a single user may be called single play. In multiplay, each user can operate a character assigned to him / herself among multiple characters that make up a deck. For example, assume that a deck is made up of characters A to D, and character A is assigned to user A (own 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, each user operates the characters that make up the deck in turn. A user who invites for a multiplay may be called a host or a host user. On the other hand, a user who participates in a multiplay invited by a host may be called a guest or a guest user. Invite for a multiplay may be read as invite to participate in a multiplay, convene a multiplay, invite a multiplay, etc.

[0018] In multiplayer mode, the multiple characters making up the deck may be made up of characters owned by the host user, or the deck may be made up of characters selected by each of the host and guest users from among the characters they own.

[0019] In this embodiment, users can participate in groups (hereinafter referred to as "user groups"). Each user can create one or more user groups. Also, each user can participate in one or more user groups. A user who creates a user group may be called a creating user or a group owner. A user who joins a created user group may be called a joining user. In the following description, when there is no particular distinction between a creating user and a joining user, they will be called a user belonging to a user group or a joining user.

[0020] A user who creates a user group can assign any tag to the user group that he or she creates. Furthermore, a user who wants to join a user group can find the user group that he or she wants to join by searching for the tag assigned to the user group. The tag may include a tag predetermined by a game operator or the like and / or any character string, etc.

[0021] Any user can join a user group, but in this embodiment, it is assumed that users who have a common level of experience with games, interests, or goals in gameplay will form a group. For example, during the period when event quest A is provided, a user group with a tag of "I want to clear quest A" is created, and users who want to clear quest A join the user group and aim to clear quest A. In addition, it is assumed that users who are level 50 or above will participate in a user group with a tag of "Limited to heavy users above level 50."

[0022] In this embodiment, a user can invite users to a multiplayer game by specifying a user group to which the user belongs (i.e., a user group that the user created or a user group in which the user participates). When inviting users to a multiplayer game by specifying a user group, only users who belong to the specified user group can participate in the multiplayer game. This makes it easy for users who share a common level of experience, tastes, or playing goals to play together.

[0023] Furthermore, the game server 10 displays "information regarding the ease of establishing a multiplayer game" for each user group on a screen where a user group is specified and a multiplayer game is solicited. Naturally, a multiplayer game cannot be established unless a user who wishes to participate appears. Therefore, a user can refer to the information and specify a user group with which a multiplayer game is likely to be established, and solicit a multiplayer game. This makes it possible to prevent a multiplayer game from not being established and a multiplayer game solicitation from going to waste.

[0024] <Hardware configuration> 2 is a diagram showing an example of the hardware configuration of the game server 10 and the terminal 20. The game server 10 and the terminal 20 each have a processor 11 such as a CPU (Central Processing Unit) or a GPU (Graphical Processing Unit), a storage device 12 such as a memory, an HDD (Hard Disk Drive) and / or an SSD (Solid State Drive), a communication IF (Interface) 13 for wired or wireless communication, an input device 14 for accepting input operations, and an output device 15 for outputting 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] <Function block configuration> (Game Server) FIG. 3 is a diagram showing an example of a 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 realized by using a storage unit 12 included in the game server 10. The control unit 101 can be realized by the processor 11 of the game server 10 executing a program stored in the storage unit 12. The program can be stored in a storage medium. The storage medium storing the program may be a non-transitory computer readable medium. The non-transitory storage medium is not particularly limited, and may be, for example, a storage medium such as a USB memory or a CD-ROM.

[0026] The storage unit 100 stores game data necessary for the game server 10 to execute 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, the control unit 101 performs a process of executing a quest designated by the user, a process of granting a reward to the user, etc. The control unit 101 also includes a display control unit 102, a group control unit 103, and a recruitment control unit 104. The control unit 101 may be called a game execution unit, an execution unit, etc.

[0028] The display control unit 102 displays various screens related to the game on the display of the terminal 20. For example, the display control unit 102 displays information regarding the ease of establishing a multiplay for each user group on a screen that accepts, from the host user, the designation of a user group for which a multiplay is being invited. The host user may be referred to as the "first user."

[0029] The group control unit 103 creates and manages user groups. For example, the group control unit 103 performs a process of creating a new user group in response to an instruction from a user, and a process of managing a user in association with the user group when a request to join a user group is received from the user.

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

[0031] Furthermore, the recruitment control unit 104 may be configured to recruit users to play a multiplayer game from among users to be recruited who belong to each of a plurality of groups designated by the host user (first user).

[0032] The display control unit 102 may be a part of the group control unit 103 and the recruiting control unit 104. For example, among various processes related to a user group, the display control unit 102 may perform a process related to screen display, and the group control unit 103 may perform processes other than screen display, such as accessing a database. Similarly, among various processes related to recruiting for a multi-play, the display control unit 102 may perform a process related to screen display, and the recruiting control unit 104 may perform processes other than screen display, such as accessing a database and managing a multi-play in which participating users are being recruited. However, this is not limited to the above, and the display control unit 102 may be an individual functional block rather than a part of the group control unit 103 and the recruiting control unit 104.

[0033] (Terminal) FIG. 4 is a diagram showing an example of a functional block configuration of the terminal 20. The 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 realized by using a storage unit 12 included in the terminal 20. The communication unit 201, the UI unit 202, and the control unit 203 can be realized by the processor 11 of the terminal 20 executing a program stored in the storage unit 12. The program can be stored in a storage medium. The storage medium storing the program may be a computer-readable non-transitory storage medium. The non-transitory storage medium is not particularly limited, and may be, for example, a storage medium such as a USB memory or a CD-ROM.

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

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

[0036] The UI unit 202 has a function of accepting various inputs from a 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 instructions from the game server 10.

[0037] The control unit 203 provides various functions necessary for executing a game by cooperating with the game server 10. For example, the control unit 203 provides a function for acquiring various information (icon image data, text data, etc.) for drawing on a game screen from the game server 10.

[0038] Regarding the functional block configuration described above, all or some of the memory unit 100, the control unit 101, the display control unit 102, the group control unit 103, and the recruitment control unit 104 included in the game server 10 may be configured to be provided in the memory unit 200 or the control unit 203 of the terminal 20. In other words, various processes according to this embodiment may be executed by the game server 10, may be executed by the terminal 20, or may be executed by the game server 10 and the terminal 20 in cooperation with each other.

[0039] <Processing Procedure> Next, a specific process performed by the game system 1 will be described. In the following description, the "game media" used to organize a deck and the "game media" obtainable when a quest is cleared will be described as characters.

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

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

[0042] The user group management DB 100b stores, in association with one another, an identifier (user group ID) that uniquely identifies a user group, an identifier (user ID) of the user who created the user group, a user group name indicating the name of the user group, identifiers of users participating in the user group (participating users), tags associated with the user group, and execution history of multiplay currently taking place or that has taken place in the past within the user group.

[0043] The tag may include, for example, one or more categories selected from a number of predetermined categories, or a keyword that is an arbitrary character string. The category name may be content that may be of interest to users who play the game, such as the name of a quest that can be played for a limited time, or a term used in the game.

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

[0045] FIG. 6 is a diagram showing an example of the owned character management DB 100c. The owned character management DB 100c stores an identifier (user ID) that uniquely identifies a user, an identifier (character ID) that uniquely identifies a character, various parameters (level, luck (luck), HP (hit points), attack power, speed, etc.) that indicate the strength of the character, and the like. MAX indicates that the parameter value is the upper limit value. Here, the larger the value of the parameter of the character, the stronger the character is, and it may be possible to increase the parameter value by synthesizing the same character. In other words, it may be possible to generate a stronger character by repeatedly synthesizing characters. Note that the same character 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, the character may be considered to be the same even if the parameter value is different.

[0046] (Create a user group) FIG. 7 is a flowchart showing an example of a processing procedure when a user creates a user group.

[0047] In step S10, the group control unit 103 receives an instruction to create a new user group from a user who wishes to create a user group. In step S11, the group control unit 103 determines whether or not to permit the user to create a new user group. For example, if an upper limit is set for the number of user groups that can be created for each user, the group control unit 103 may not permit the creation of user groups in excess of the upper 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 the user group cannot be created, and ends the process.

[0049] (Participate in user groups) FIG. 8 is a flowchart showing an example of a processing procedure when a user joins a user group.

[0050] In step S20, when the group control unit 103 receives a search request including a search condition for a user group from a user, it accesses the user group management DB 100b and acquires data on the user group that matches the search condition (user group name, number of users belonging, etc.). The search condition includes a tag specified or input by the user.

[0051] In step S21, the display control unit 102 displays the acquired data on the user group as a list of user groups that the user can specify on the screen of the terminal 20. Furthermore, the group control unit 103 accepts the specification of a user group that the user wishes to join 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" field of the record of the specified user group.

[0053] 9 is a diagram showing an example of a screen display when joining a user group. When a tag to search is specified on the search tag list screen M100, the group control unit 103 searches for "tag" in the user group management DB 100b and extracts one or more user groups that include the specified tag. The extracted user groups are displayed on the user group list screen M101. On the user group list screen M101, the number of users belonging, the maximum number of users that can belong, the user group name and tags (categories and keywords), etc. are displayed for each user group. On the search tag list screen M100, the tag to search is displayed in advance, but any character string indicating the tag to search may be input.

[0054] Next, when a user group that the user wants to join is selected on the user group list screen M101, the screen transitions to a user group details screen M102. The user group details screen M102 displays details of the user who created the user group and the users 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 "Participating Users" in the user group management DB 100b.

[0055] (Multiplayer within a user group) 10 is a flowchart showing an example of a processing procedure when a multiplay is performed within a user group. In step S30, the recruitment control unit 104 accepts a designation of a quest to be played in a multiplay from a user (i.e., a host user) who is recruiting for a multiplay. In step S31, the recruitment control unit 104 accepts a designation of a user group who is recruiting for a multiplay from the host user.

[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 as users to be recruited from among the users stored in the "creating user" and "participating users" of the record of the specified user group in the user group management DB 100b. Next, the recruitment control unit 104 notifies the extracted users to be recruited that users to participate in multiplay are being recruited. The notification that a multiplay is being recruited may be made, for example, by displaying the user group name, the user name of the host user, etc. on a "participating user recruitment list" screen or the like displayed on the terminal 20 of the users to be recruited.

[0057] In step S33, if there is a request to participate in a multiplay from one or more users (i.e., guest users) among the users being recruited, the recruitment control unit 104 proceeds to step S34. On the other hand, if there is no request to participate in a multiplay from any of the users being recruited, the recruitment control unit 104 proceeds to step S35. The recruitment control unit 104 may proceed to step S35 if there is no request to participate in a multiplay within a predetermined time period after accepting the designation of a user group from the host user in the processing procedure of step S31.

[0058] In step S34, the control unit 101 executes a quest in multiplay between the host user and the guest user.

[0059] In step S35, the recruitment control unit 104 determines that a multiplay has not been established, stops recruiting for a multiplay, and ends the process. At this time, the recruitment control unit 104 (display control unit 102) may delete the user group name, the host user's user name, and the like from the "Participating User Recruitment List" screen, etc., displayed on the terminal 20 of the recruited user. In addition, the recruitment control unit 104 may store information indicating that a multiplay has not been established and the date and time when it has been determined that a multiplay has not been established in the "multiplay execution history" of the user group management DB 100b.

[0060] FIG. 11 is a diagram showing an example of a screen when soliciting for a multiplayer game. When a host user selects a quest on the quest selection screen M200, the screen transitions to a screen M201 for specifying a method for soliciting for a multiplayer game. On the screen M201, the user can select one of a method for soliciting for a multiplayer game from users who are in a friend relationship and are physically close to each other, a method for soliciting via a social network service, and a method for soliciting by specifying a user group. When the host user presses a "user group" button to solicit a user group by specifying a user group, the screen transitions to a user group specification screen M202. The user group specification screen M202 is a screen for accepting the specification of a user group for soliciting for a multiplayer game, and displays a list of user groups that can be specified. When a user group is selected by the host user on the user group specification screen M202, the screen transitions to a guest user participation status screen M203. On the guest user participation status screen M203, a list of users (guest users) who have requested to participate among users to be solicited is displayed. In the example of Figure 11, the host user (aaa) invites a multiplayer game, but there are no requests from users who are the target of the game to join. After one or more users have requested to join, the host user presses the "Start" button to start the multiplayer game.

[0061] Here, the user group designation screen M202 displays "information regarding the ease of establishing a multiplay" for each user group. For example, in the example of FIG. 11, the time elapsed since the last multiplay ended among the user groups is displayed as information regarding the ease of establishing a multiplay. In the case of group A, "elapsed time: 48 hours ago" is displayed, which indicates that a multiplay has not been held for two days. On the other hand, group B indicates that a multiplay was held five minutes ago. In this case, the host user can determine that a multiplay is more likely to be established if the host user invites a multiplay to group B or C rather than group A.

[0062] FIG. 12 is a diagram showing an example of a screen when participating in a multiplay. When the "Join Multiplay" button is pressed on the game screen M300 displayed on the terminal 20 of the user to be recruited, the screen transitions to a multiplay recruitment list screen M301 that displays a list of multiplays in which participating users are being recruited. On the multiplay recruitment list screen M301, a recruitment for a multiplay with a specified user group, a recruitment for a multiplay from a user who is in a friend relationship and is in a nearby physical location, and a recruitment for a multiplay via a social network service are displayed in a differentiated manner. A recruitment for a multiplay with a specified user group displayed on the multiplay recruitment list screen M301 is displayed when a multiplay is being recruited by a user group to which the user to be recruited belongs. The user can participate in a multiplay by specifying a multiplay to which the user wants to participate from the list. If the "Join Multiplay" button is pressed on the game screen M300 and there is no recruitment for a multiplay that can be participated in, a message indicating that there is no recruitment for a multiplay is displayed as shown on the screen M302.

[0063] <Information on the ease of establishing a multiplayer game> Next, a number of display examples of information regarding the likelihood of a multi-play being established will be described. The display examples described below can be combined in any manner.

[0064] (Display example 1) When the display control unit 102 receives a selection of a quest (game) for which multiplayer is being invited from the host user, the display control unit 102 may display, for each user group, information about users who do not satisfy the conditions for possessing characters available in the selected quest as information regarding the ease of establishing a multiplayer game. The characters available in the selected quest may be, for example, characters that are granted to each user who has participated in a multiplayer game when the quest is cleared.

[0065] The "possession condition" may be a condition in which a character that is obtainable in the selected quest satisfies a predetermined condition. The predetermined condition may be, for example, a condition in which a predetermined parameter value that is increased by combining the same characters is a maximum value.

[0066] In other words, the display control unit 102 may display, for each group, as information regarding the ease of establishing a multiplayer game, the number of users belonging to the group who do not possess a character that is available in the quest selected by the host user and has the maximum value of a specified parameter value.

[0067] For example, assume that the character name of the character available in quest A selected by user X who is looking for a multiplayer game is character A. Also assume that group 1 to which user X belongs has 10 other users in addition to user X, and that there are 3 users who possess character A whose predetermined parameter value is at the maximum value (MAX). Also assume that group 2 to which user X belongs has 13 users in addition to user X, and that there are 10 users who possess character A whose predetermined parameter value is at the maximum value.

[0068] In this case, the display control unit 102 may display, on the user X's screen (e.g., M202 in FIG. 11) information regarding the ease of establishing a multiplayer game, for group 1, "Maximum characters owned: 7 users," and for group 2, "Maximum characters owned: 3 users."

[0069] A user who already has a character with the maximum parameter value is likely not interested in multiplay because there is no need to obtain the character and synthesize it. On the other hand, a user who does not have a character with the maximum parameter value is likely to want to participate in multiplay in order to obtain the character as a synthesis material. Therefore, User X can determine that it is easier to establish a multiplay by designating a user group with a large number of users who do not have a character with the maximum predetermined parameter value and inviting users to participate in multiplay.

[0070] As another example, the "possession condition" may be that a player possesses a predetermined number of characters available 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 who belong to the group and who have characters that can be obtained in a quest selected by the host user but do not possess a specified number of such characters, as information regarding the ease of establishing a multiplayer game.

[0072] For example, assume that by combining identical characters, the predetermined parameter value increases by 1. Also assume that the minimum value of the predetermined parameter value is 1 and the maximum value is 99. Also assume that the predetermined parameter value of a character granted upon clearing a quest is 1 (i.e., the minimum value). In this case, by combining 99 characters, the predetermined parameter value can be increased to the maximum value. Therefore, the "predetermined number" may be 99.

[0073] A user who has a certain number of characters available in a quest inviting multiplayer play is likely not to want to participate in a multiplayer play, because the parameter value can be maximized by combining the characters. On the other hand, a user who does not have a certain number of characters available in a quest inviting multiplayer play is likely to want to participate in a multiplayer play in order to collect more characters. Therefore, User X can determine that a multiplayer play is more likely to be established if he or she invites a multiplayer play by specifying a user group with a large number of users who do not have a certain number of characters available in a multiplayer play.

[0074] The "predetermined number" may be 1. In a game, there are users who play simply to collect many characters without synthesizing characters. If such users already possess a character that can be obtained in a quest to be played in multiplayer, they are likely not to wish to participate in the multiplayer because they do not need to play the quest. Therefore, if the "predetermined number" is set to 1, the number of users who do not possess any characters that can be obtained in a quest will be displayed for each user group. Therefore, User X can determine that it is easier to establish a multiplayer game if he / she invites users to a multiplayer game by specifying a user group with a large number of users who do not possess characters that can be obtained in multiplayer.

[0075] As another condition, the above-mentioned "possession condition" may be a character that can be obtained in the selected quest, and when all of the characters that the user already possesses are combined, the predetermined parameter value of the character may become the maximum value.

[0076] In other words, the display control unit 102 may display, for each group, as information regarding the ease of establishing a multiplayer game, the number of users belonging to the group who are unable to generate a character with the maximum value of a specified parameter even if they combine all of the characters that are available in a quest selected by the host user and that each user already possesses.

[0077] A user who can generate a character with the maximum parameter value by combining characters that he or she already owns is likely not interested in multiplayer because he or she does not need to obtain additional characters. On the other hand, a user who cannot generate a character with the maximum parameter value by combining characters that he or she already owns is likely to want to participate in multiplayer in order to obtain more characters. Therefore, User X can determine that it is easier to establish a multiplayer game if he or she invites users to a user group that includes a large number of users who cannot generate a character with the maximum parameter value by combining characters that they already own.

[0078] According to the display example 1 described above, after a quest is specified, a user group is specified and a multiplayer invitation is made, so that information related to the quest can be used for the invitation to multiplayer.

[0079] (Display example 2) When the display control unit 102 receives a selection of a quest (game) for which multiplayer is being invited from a host user (first user), it may display information about users who meet the participation conditions of the selected quest for each user group as information regarding the ease of establishing a multiplayer game. The participation conditions of a quest may be any condition, and may be, for example, that the user's parameters (e.g., level, experience points, etc.) are equal to or greater than a predetermined value, or that the parameters of a character owned are equal to or greater than a predetermined value.

[0080] For example, if a condition for participating in a quest is that the user must be level 50 or above, a user group with many level 50 users is more likely to have more users wishing to participate in a multiplayer game than a user group with few level 50 users. Therefore, a user can determine that a multiplayer game is more likely to take place if the user requests a multiplayer game by specifying a user group with many users who meet the participation condition.

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

[0082] For example, if the clearing condition for a quest is set to level 50 or above, users below level 50 may determine that it is difficult to clear the quest and may not participate in the multiplay. In other words, a user group with many level 50 users is more likely to have more users who wish to participate in the multiplay than a user group with few level 50 users. Therefore, a user can determine that it is easier to establish a multiplay by requesting a multiplay by specifying a user group with many users who meet the clearing condition.

[0083] (Display example 4) When the display control unit 102 receives a selection of a quest (game) for which multiplayer is being invited from the host user (first user), it may display information about users who do not 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 of the quest are the same as those in display example 3, so a description thereof will be omitted.

[0084] For example, if the clearing condition for a quest is set to level 50 or above, users below level 50 may judge the quest to be difficult to clear and may not participate in the multiplayer game. However, if the host user's level is 50 or above, users below level 50 may think they can clear the quest with the host user's help and participate in the multiplayer game. Therefore, a user may determine that it is easier to have a multiplayer game if they invite users to participate in a multiplayer game by specifying a user group with many users who do not meet the clearing condition.

[0085] (Example 5) The display control unit 102 may display, for each user group, information about users who have played multiplay with the host user (first user) in the past, as information about the ease of establishing a multiplay. The information may be the number of users who have played multiplay with the host user (first user) among users belonging to the user group.

[0086] For example, assume that group 1 includes five users other than user X who have played multiplayer games in the past with user X who is seeking a multiplayer game, and that group 2 includes none. In this case, a user group with many users who have played multiplayer games with user X in the past is likely to have more users who will continue to participate in multiplayer games together in the future, compared to a user group with few users who have played multiplayer games with user X in the past. Therefore, a user can determine that a multiplayer game is more likely to be established if the user seeks a multiplayer game by specifying a user group with many users who have played multiplayer games with the user.

[0087] (Example 6) The display control unit 102 may display, for each user group, the frequency at which multiplay is performed within the user group, the time elapsed since the time when the most recent multiplay performed in the user group ended, or the history of multiplay performed within the user group, as information regarding the ease of establishing a multiplay. The frequency at which multiplay is performed within a user group may be, for example, the number of times multiplay has been performed within a predetermined period of time in the past. For example, if the predetermined period of time in the past is set to 24 hours, the display control unit 102 may display, for each user group, the number of times multiplay has been performed within the past 24 hours from the current time. The history of multiplay may include information regarding the most recent multiplay (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 games is more likely to have more users who wish to participate in a multiplayer game than a user group that does not play multiplayer games frequently. Also, a user group that has not played a multiplayer game for a long time is more likely to have more users who wish to participate in a multiplayer game than a user group that has not played a multiplayer game for a long time. Therefore, a user can determine that a multiplayer game is more likely to be established by inviting users to play a multiplayer game by specifying a user group that frequently plays multiplayer games or a user group that has not played a multiplayer game for a long time.

[0088] (Example 7) The display control unit 102 may display, for each user group, the number of online users (i.e., the number of users logged in to the game) or the percentage of online users (the percentage of online users out of all users belonging to the user group) as information regarding the ease of establishing a multiplay. Since online users are considered to at least operate the terminal 20 to have the game screen open, a user group with many online users is considered to have more users participating in multiplay than a user group with few online users. Therefore, a user can determine that it is easier to establish a multiplay if he or she requests a multiplay by specifying a user group with many logged-in users.

[0089] (Example 8) The display control unit 102 may display, for each user group, the number of users who are online and not playing any quest, as information regarding the ease of establishing a multiplay. The term "any quest" is not limited to the quest selected by the host user, but includes any quest (the same applies in the following explanation). As described above, it is considered that an online user at least operates the terminal 20 to open the game screen. In addition, a user who is not playing a quest can immediately participate in a multiplay. Therefore, a user group with many users who are online and not playing a quest is considered to have more users who can participate in a multiplay than a user group with few users who are online or not playing a quest. Therefore, a user can determine that a multiplay is more likely to be established by designating a user group with a large number of users who are online and not playing a quest and inviting a multiplay.

[0090] (Example 9) The display control unit 102 may display, for each user group, the number of multiplays currently being performed by users belonging to the user group as information regarding the ease of establishing a multiplay. A multiplay is performed by multiple users, and one user cannot participate in multiple multiplays at the same time. Therefore, a user group in which many multiplays are being performed is considered to have fewer users who can participate in a multiplay than a user group in which few multiplays are being performed. Therefore, a user can determine that it is easier to establish a multiplay by requesting a multiplay by specifying a user group with a small number of currently performing multiplays.

[0091] (Example 10) When the display control unit 102 receives a selection of a quest (game) for which a multiplay is solicited from a host user (first user), the display control unit 102 may display, for each user group, the number of users who possess characters effective for clearing the quest as information regarding the ease of establishing a multiplay. A "character effective for clearing a quest" is a character that can be incorporated into a deck to advantageously advance the quest, and may be, for example, a character having the same attribute as an attribute associated with the quest, a character having a parameter value higher than the parameter value of an enemy character appearing in the quest, or a character having an attribute capable of inflicting more damage than other attributes on an enemy character appearing in the quest. A user who possesses a character effective for clearing a quest can easily clear the quest, and is therefore considered to be more likely to participate in a multiplay. Therefore, a user can determine that a multiplay is more likely to be established if a user group with a large number of users possessing characters effective for clearing a quest is specified and a multiplay is solicited.

[0092] (Example 11) When the display control unit 102 receives a selection of a quest (game) for which multiplayer is being invited 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 ease of establishing a multiplayer game. Users who have previously cleared the quest may be likely to challenge the quest again. Therefore, the user can determine that it is easier to establish a multiplayer game by designating a user group with a large number of users who have previously cleared the quest and inviting players for a multiplayer game.

[0093] (Example 12) In addition to the above-described display examples, the display control unit 102 may display, for a group in which the users playing a given quest are at a predetermined rate or more, information indicating that the users playing the given quest are at a predetermined rate or more and a predicted time until the users playing the given quest fall below the predetermined rate. The display control unit 102 may predict the time at which each quest will end using a predetermined average play time for one quest, and calculate a predicted time until the users playing the given quest fall below the predetermined rate based on the predicted time at which each quest will end. This allows the user to invite multiplayer while avoiding a user group in which the users already playing a quest are at a predetermined rate or more (i.e., a user group in which multiplayer is unlikely to be established). Even if the user wants to specify a user group in which the users playing a quest are at a predetermined rate or more, the user can control the system so that multiplayer is more likely to be established by waiting until the predicted time until the users playing the quest fall below the predetermined rate before inviting multiplayer.

[0094] <About the user group selection screen> Next, a number of display examples will be described regarding the user group designation screen (for example, M202 in FIG. 11) that accepts designation of a user group from which a host user is solicited for a multiplayer game.

[0095] (Display example A) The display control unit 102 may display groups to which the host user (first user) belongs on a user group designation screen as user groups that the host user can designate and that are inviting users for multiplay. For example, if user X belongs to user group 1, user group 2, and user group 3, the display control unit 102 may display a list of user group 1, user group 2, and user group 3 on the user group designation screen for user X.

[0096] (Display example B) The display control unit 102 may display, in addition to the user group to which the host user (first user) belongs, a user group to which the host user does not belong that satisfies a first predetermined condition on the user group designation screen. A group to which the host user does not belong that satisfies a first predetermined condition is a user group to be added and displayed on the user group designation screen, and therefore is referred to as an "additional group" in the following description. For example, the display control unit 102 may display, in addition to the user group to which the host user belongs, the group name, etc. of the user group corresponding to the additional group on the user group designation screen M202 of FIG. 11.

[0097] The group that satisfies the first predetermined condition may be a user group for which an index indicating an activity status of the user group is equal to or greater than a predetermined value. The index may indicate that the user group is more active as the value becomes larger.

[0098] The index indicating the activity status of the user group may be, for example, any one of the following indexes No1 to No4. No. 1. An index showing the frequency of multiplay within a user group. The higher the frequency, the larger the value of this index. The frequency of multiplay may be the same as that explained in display example 6.

[0099] No. 2. An indicator of the amount of time that has elapsed since the last multiplayer game 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 who are online among users belonging to a user group. No. 4. The number of users who are online and not playing a quest, or the percentage of users in a user group who are online and not playing a quest.

[0100] The group that satisfies the first predetermined condition may be a user group that is likely to have users who wish to participate in a multiplayer game when the group is invited to play. For example, the group may be 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 possession conditions for the characters available in the quest selected by the host user is a predetermined number or more, or the ratio of users who do not meet the possession conditions for the characters available in the quest selected by the host user among the users belonging to the user group is a predetermined ratio or more. The possession conditions may be the same as those described in display example 1.

[0101] No. 6. A user group in which the number of users who meet the participation conditions of the quest selected by the host user is a predetermined number or more, or the ratio of users who meet the participation conditions of the quest selected by the host user among the users belonging to the user group is a predetermined ratio or more. The participation conditions may be the same as those described in display example 2.

[0102] No. 7. A user group in which the number of users who satisfy the clearing conditions of the quest selected by the host user is a predetermined number or more, or the ratio of users who satisfy the clearing conditions of the quest selected by the host user among the users belonging to the user group is a predetermined ratio or more. The clearing conditions may be the same as those described in display example 3.

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

[0104] No. 9. A user group in which the number of currently active multiplayer games between users belonging to the user group is below a certain number.

[0105] No. 10. A user group in which the number of users who possess characters that are effective for clearing the quest selected by the host user is equal to or greater than a predetermined number, or the percentage of users who possess characters that are effective for clearing the quest selected by the host user among the users belonging to the user group is equal to or greater than a predetermined percentage. The characters that are effective for 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 specified number, or 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 specified percentage.

[0107] Furthermore, in the display example B, the group that satisfies the first predetermined condition may be a user group to which a tag that is entirely or partially the same as a tag that is assigned to a user group to which the host user belongs. According to the display example B described above, the host user can designate user groups to which he or she does not belong that are active as user groups looking for multiplayer games, in addition to the user groups to which he or she belongs.

[0108] (Display example C) The display control unit 102 may display the additional group on the user group designation screen when the information on the ease of establishing a multiplay in the user group to which the host user belongs does not satisfy a second predetermined condition. More specifically, the display control unit 102 may display the additional group on the user group designation screen when the information on the ease of establishing a multiplay 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 the additional group on the user group designation screen when the information on the ease of establishing a multiplay in all user groups to which the host user belongs does not satisfy the second predetermined condition.

[0109] The case where the information on the ease of establishing a multiplay does not satisfy the second predetermined condition may be when the indicator showing the activity status of the user group is less than 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 described in the display example B.

[0110] In addition, a case where the information on the ease of establishing a multiplayer game does not satisfy the second predetermined condition may be a case where even if a multiplayer game is invited, there is a low possibility that there will be users who wish to participate (i.e., a multiplayer game is difficult to establish). Specifically, this may be the case of No. 12 to No. 18 shown below. Note that No. 12 to No. 18 correspond to No. 5 to No. 11 described above, respectively. No. 12. When the number of users who do not meet the possession conditions for the characters available in the quest selected by the host user is less than a specified number, or when the ratio of users who do not meet the possession conditions for the characters available in the quest selected by the host user among the users belonging to the user group is less than a specified ratio. The possession conditions may be the same as those described in display example 1.

[0111] No. 13. When the number of users who meet the participation conditions of the quest selected by the host user is less than a specified number, or when the ratio of users who meet the participation conditions of the quest selected by the host user among the users belonging to the user group is less than a specified ratio. The participation conditions may be the same as those described in display example 2.

[0112] No. 14. When the number of users who satisfy the clearing conditions of the quest selected by the host user is less than a specified number, or when the ratio of users who belong to the user group who satisfy the clearing conditions of the quest selected by the host user is less than a specified ratio. The clearing conditions may be the same as those described in display example 3.

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

[0114] No. 16. When the number of currently active multiplayer games between users belonging to a user group is less than a specified number.

[0115] No. 17. When the number of users who possess characters that are effective for clearing the quest selected by the host user is less than a predetermined number, or when the ratio of users who possess characters that are effective for clearing the quest selected by the host user among the users belonging to the user group is less than a predetermined ratio. The characters that are effective for clearing the quest may be the same as those explained in display example 10.

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

[0117] Furthermore, the additional group in display example C may be another user group to which a tag that is the same in whole or in part as the tag that is assigned to the user group to which the host user belongs. According to the display example C described above, if the user group to which the host user belongs is not active, the host user can designate a user group to which the host user does not belong that is active as a user group looking for multiplayer games.

[0118] (Display example D) When the solicitation for a multi-play made to the solicited user (second user) is not successful, the display control unit 102 may additionally display another user group different from at least one user group designated by the host user as a solicited target, as a group for which a multi-play is solicited that the host user can specify. When the solicitation for a multi-play is not successful, it may be, for example, as described in step S33 of FIG. 10, when there is no request to participate in a multi-play until a predetermined time has elapsed since the host user accepted the designation of a user group for which a multi-play is solicited. Moreover, the other user group may be the same as the additional group described in display example B.

[0119] This allows the host user to invite users to multiplayer games by specifying another user group even if the invitation for a multiplayer game is not accepted. Also, even if the invitation for a multiplayer game is not accepted, the host user can invite users to multiplayer games by specifying another user group with which the invitation for a multiplayer game is likely to be accepted.

[0120] (Display example E) When the information on the ease of establishing a multiplay in the group to which the host user belongs does not satisfy the second predetermined condition, the display control unit 102 may display information on the screen of the terminal 20 that recommends the host user to 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). Also, when the information on the ease of establishing a multiplay does not satisfy the second predetermined condition, the explanation may be the same as that in display example C.

[0121] For example, the display control unit 102 may display a message on the screen M302 in FIG. 12 recommending that the user belong to an additional group in addition to / in place of the user group to which the user currently belongs.

[0122] This allows a user to change his / her affiliation from a user group with which multiplay is difficult to establish to a user group with which multiplay is easy to establish.

[0123] <Summary> According to the embodiment described above, when a user requests a multiplayer game, the game server 10 prevents the request from being sent to a user group with which a multiplayer game is unlikely to be established. This makes it possible to provide a technology that can prevent a multiplayer game request from going to waste.

[0124] The above-described embodiment is intended to facilitate understanding of the present invention, and is not intended to limit the present invention. The flow charts, sequences, elements included in the embodiment, and their arrangements, materials, conditions, shapes, sizes, etc. described in the embodiment are not limited to those exemplified, and may be modified as appropriate.

[0125] <Additional Notes> <Appendix 1> a display control unit that displays, for each group, information regarding the ease of establishing a multiplay on a screen that accepts, from a first user, a designation of a group inviting a plurality of users to play a game together; a recruitment control unit that recruits second users who belong to at least one group designated by the first user to play the multiplayer game; An information processing device having the above configuration. According to Appendix 1, it is possible to prevent a multiplayer recruitment request specifying a group from going to waste.

[0126] <Appendix 2> the display control unit, when accepting a selection of a game for which a multiplayer game is to be solicited from the first user, displays, by group, information about users who do not satisfy a possession condition for game media available in the selected game. 2. An information processing device according to claim 1. According to Addendum 2, the first user can specify groups to invite for multiplayer games after obtaining information about users who do not meet the conditions for owning the game media available for the game selected by the first user, on a group-by-group basis.

[0127] <Appendix 3> the display control unit, when accepting a selection of a game for which multiplayer play is being solicited from the first user, displays information about users who meet a participation condition for the selected game for each group. 3. The information processing device according to claim 1 or 2. According to Supplementary Note 3, the first user can specify a group to which he or she is inviting users for multiplayer play after obtaining information about users who meet the participation conditions for the game selected by the first user, group by group.

[0128] <Appendix 4> The display control unit displays, for each group, information about users who have previously played multiplay with the first user. 4. The information processing device according to claim 1, According to Supplementary Note 4, the first user can specify a group to which he / she is inviting users to play multiplayer games after grasping information about users who have played multiplayer games with the first user in the past, group by group.

[0129] <Appendix 5> The display control unit displays, on the screen, a group to which the first user belongs as a group inviting the first user to play in a multiplayer game that the first user can specify. 5. The information processing device according to any one of claims 1 to 4. According to Supplementary Note 5, the first user is able to specify a group to which he or she belongs that is looking for players to play multiplayer games.

[0130] <Appendix 6> the display control unit displays, on the screen, in addition to a group to which the first user belongs, an additional group to which the first user does not belong that satisfies a first predetermined condition. 6. The information processing device according to claim 5. According to Supplementary Note 6, the first user can specify a group from among the group to which the first user belongs and additional groups to which he or she is inviting users for multiplayer play.

[0131] <Appendix 7> the display control unit displays the additional group on the screen when the information regarding the likelihood of establishing a multiplay in the group to which the first user belongs does not satisfy a second predetermined condition. 7. The information processing device according to claim 6. According to Addendum 7, when the information regarding the ease of establishing a multiplayer game in the group to which the first user belongs does not satisfy the second specified condition, the first user can specify a group from among the additional groups from which to invite users for a multiplayer game.

[0132] <Appendix 8> the display control unit, when the invitation for a multiplay made to the second user is not successful, displays another group different from the at least one group as a group inviting the first user to designate a multiplay; 8. The information processing device according to any one of claims 1 to 7. According to Appendix 8, if a request for a multiplayer game is not successful, the first user can specify a group to which a request for a multiplayer game will be sent from among groups other than the group that requested the multiplayer game.

[0133] <Appendix 9> The recruitment control unit recruits the second users who belong to each of the multiple groups designated by the first user to play in a multiplayer game. An information processing device according to any one of appendix 1 to 8. According to Supplementary Note 9, the first user can specify multiple groups and invite people to play in a multiplayer game.

[0134] <Appendix 10> the display control unit, when the information regarding the likelihood of establishing a multiplay in the group to which the first user belongs does not satisfy a second predetermined condition, displays on the screen information recommending that the first user change the group to which the first user belongs to an additional group to which the first user does not belong that satisfies a first predetermined condition; 10. The information processing device according to any one of claims 1 to 9. According to Addendum 10, if the information regarding the ease of establishing a multiplayer game in the group to which the first user belongs does not satisfy the second specified condition, the first user can change the group to which the first user belongs to another group to which the first user does not belong and which satisfies the first condition.

[0135] <Appendix 11> displaying, for each group, information regarding the ease of establishing a multiplay on a screen that accepts, from a first user, a designation of a group inviting a plurality of users to play a game together; A step of inviting second users who belong to at least one group designated by the first user to participate in the multiplayer game; An information processing method comprising the steps of: According to Appendix 11, it is possible to prevent a multiplayer recruitment request specifying a group from going to waste.

[0136] <Appendix 12> a step of displaying, on a screen for receiving from a first user a designation of a group inviting a plurality of users to play a game together, information regarding the ease of establishing the multiplay for each group; A step in which the computer solicits second users who belong to at least one group designated by the first user to play the multiplayer game; A program for causing a computer to execute the following. According to Appendix 12, it is possible to prevent a multiplayer recruitment request specifying a group from going to waste. [Explanation of symbols]

[0137] 10...game server, 11...processor, 12...storage device, 13...communication IF, 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. a display control unit that displays, for each group, information that helps the first user to determine the ease of establishing a multiplay on a screen that accepts from the first user a designation of a group inviting a multiplay in which a plurality of users play a game together; a recruitment control unit that recruits second users who belong to at least one group designated by the first user to play the multiplayer game; having the display control unit, when receiving a selection of a game for which a multiplayer game is being solicited from the first user, displays, by group, information about users who do not satisfy a possession condition for a game medium available in the selected game, as information useful for determining the ease of establishing the multiplayer game; Information processing device.

2. A display control unit that displays, on a screen that accepts from a first user a group designation for a multiplayer game in which multiple users play a game together, information that helps the first user determine the ease with which the multiplayer game can be established for each group; a recruitment control unit that recruits second users who belong to at least one group designated by the first user to play the multiplayer game; having the display control unit, when receiving a selection of a game for which a multiplayer game is being solicited from the first user, displays, for each group, information about users who meet a participation condition for the selected game as information useful for determining the ease of establishing the multiplayer game; Information processing device.

3. A step in which a processor displays, on a screen that accepts from a first user a specification of a group inviting a plurality of users to play a game together, information for each group that helps the first user determine the ease with which the multiplayer game can be established; A step of inviting second users who belong to at least one group designated by the first user to participate in the multiplayer game by the processor; having The display step includes, when accepting a selection of a game for which a multiplayer game is to be invited from the first user, displaying, for each group, information about users who do not satisfy a possession condition for game media available in the selected game as information useful for determining the ease of establishing the multiplayer game. Information processing methods.

4. A step of causing a processor to display, on a screen that accepts from a first user a specification of a group inviting a plurality of users to play a game together, information for each group that helps the first user determine the ease with which the multiplayer game can be established; A step of inviting second users who belong to at least one group designated by the first user to participate in the multiplayer game; Run the command, The display step includes, when accepting a selection of a game for which a multiplayer game is to be invited from the first user, displaying, for each group, information about users who do not satisfy a possession condition for game media available in the selected game as information useful for determining the ease of establishing the multiplayer game. program.

5. A system comprising a server and a terminal device, The server, a display control unit that displays, on a screen of the terminal device that accepts from a first user a designation of a group inviting a multiplay in which a plurality of users play a game together, information that helps the first user to determine the ease of establishing a multiplay for each group; a recruitment control unit that recruits second users who belong to at least one group designated by the first user to play the multiplayer game; having the display control unit, when receiving a selection of a game for which a multiplayer game is being solicited from the first user, displays, by group, information about users who do not satisfy a possession condition for a game medium available in the selected game, as information useful for determining the ease of establishing the multiplayer game; Information processing system.

6. A step in which a processor displays, on a screen that accepts from a first user a specification of a group inviting a plurality of users to play a game together, information for each group that helps the first user determine the ease with which the multiplayer game can be established; A step of inviting second users who belong to at least one group designated by the first user to participate in the multiplayer game by the processor; having The display step includes, when receiving a selection of a game for which a multiplayer game is to be invited from the first user, displaying information about users who satisfy a participation condition for the selected game for each group as information useful for determining the ease of establishing the multiplayer game. Information processing methods.

7. A step of causing a processor to display, on a screen that accepts from a first user a specification of a group inviting a plurality of users to play a game together, information for each group that helps the first user determine the ease with which the multiplayer game can be established; A step of inviting second users who belong to at least one group designated by the first user to participate in the multiplayer game; Run the command, The display step includes, when receiving a selection of a game for which a multiplayer game is to be invited from the first user, displaying information about users who satisfy a participation condition for the selected game for each group as information useful for determining the ease of establishing the multiplayer game. program.

8. A system comprising a server and a terminal device, The server, a display control unit that displays, on a screen of the terminal device that accepts from a first user a designation of a group inviting a multiplay in which a plurality of users play a game together, information that helps the first user to determine the ease of establishing a multiplay for each group; a recruitment control unit that recruits second users who belong to at least one group designated by the first user to play the multiplayer game; having the display control unit, when receiving a selection of a game for which a multiplayer game is being solicited from the first user, displays, for each group, information about users who meet a participation condition for the selected game as information useful for determining the ease of establishing the multiplayer game; Information processing system.

Citation Information

Patent Citations

  • Game system, game device, and program

    JP2019088631A

  • Control program, game device, and control method

    JP2020044320A