JP6634534B1 - Information processing program, game terminal device, and information processing system - Google Patents

Abstract

A time required to start a communication game can be reduced. An information processing program includes: a request information transmission unit that transmits request information to an external device in response to a request operation input from an operation unit; and a play state update that updates a play state based at least on a game play state. Unit 66a, an invitation information receiving unit 68a that can receive invitation information from an external device when the play state is the permitted state, and an invitation information notifying unit that notifies reception of the invitation information when or after receiving the invitation information. 70a, an operation permitting unit 72a that enables input of a predetermined participation operation at the time of or after notification of reception of the invitation information, and a connection operation with another player terminal when a participation operation is input and a predetermined start condition is satisfied. The computer functions as the game execution unit 60a that executes the communication game. [Selection diagram] FIG.

Description

  The present invention relates to an information processing program, a game terminal device, and an information processing system.

  2. Description of the Related Art Conventionally, a communication game in which a plurality of players can participate (hereinafter, referred to as multiplayer) has been known. In multiplayer, it is necessary to match those who want to participate in the game. For example, Patent Literature 1 proposes a game system that accepts an application for a match from another player (subsequent player) while a preceding player is playing a game.

  According to this game system, an image notifying of an application for a match is displayed on the game screen of the preceding player. Then, when the preceding player performs an operation of receiving an application, the multiplayer starts after waiting for the end of the game being played by the preceding player.

JP-A-2000-140413

  According to the above-mentioned game system, multiplayer cannot be started until the preceding player ends the game being played. As described above, depending on the play situation of the preceding player, it may take a long time to start multi-play.

  An object of the present invention is to provide an information processing program, a game terminal device, and an information processing system that can reduce the time required to start a communication game in which a plurality of players can participate.

In order to solve the above problem, the information processing program, an input of the request operation from the operation unit of the player terminal, the plurality players playable and invite invitation information to join the communication game, the other plurality of time request information requests that the storage in association with the receiving terminal at the server, a request information transmitting unit for transmitting to the server, based on the play status of at least a game, to receive the invitation information from the server as the receiving terminal A status update unit for storing play status information including enable status information to enable, and disable status information to disable the reception of invitation information from the server, and if the enable status information is stored as play status information, communicates to check invitation information as the receiving terminal in the server are stored in association, if the invitation information is stored, invited from the server Receive information, a receiver you store the invitation information storage unit of the player terminal, after receiving the time or reception of the invitation information, and a notification unit for notifying the reception of the invitation information, the notification time or notifying the reception of the invitation information Later, when a participation operation is input and a predetermined start condition is satisfied, a game execution unit that executes a communication game causes the player terminal to function.

In order to solve the above problem, the information processing program, an input of the request operation from the operation unit of the player terminal, the plurality players playable and invite invitation information to join the communication game, the other plurality of time request information requests that the storage in association with the receiving terminal at the server, a request information transmitting unit for transmitting to the server, the communication to check whether the invitation information as the reception terminal is stored in association with the server carried receives the invitation information from the server if the invitation information is stored, a receiving unit that be stored in the invitation information storage unit of the player terminal, based on the play status of at least the game, receives invitation information from the server A state update unit that stores play state information that includes permission state information that can notify the user, and state information that indicates that reception of the invitation information from the server cannot be notified. At the time of or after receiving the invitation information, when the permission state information is stored as the play state information, a notification unit that notifies the reception of the invitation information, and a predetermined time when the reception of the invitation information is notified or after the notification. An operation permission unit that enables the input of a participation operation, and a game execution unit that executes a communication game when a participation operation is input and a predetermined start condition is satisfied, thereby causing the player terminal to function.

The state updating unit holds the impossible state information as play state information for a first time after the end of the communication game , and stores at least the game play state and the storage of the invitation information in the invitation information storage unit. The play state information may be updated based on the presence or absence .

Also, the operation permitting unit enables input of a rejection operation for rejecting participation in the communication game at the time of or after the notification of the reception of the invitation information, and the state updating unit performs the second operation after inputting the rejection operation. Over time, the impossible state information may be held as the play state information .

Also, the operation permission unit enables input of a predetermined hold operation at the time of or after the notification of the reception of the invitation information. When the hold operation is input, the notification unit continues the notification and participates in the communication game. The notification may be terminated when the participation impossible information that can be received when the communication becomes impossible is received from the server .

  In order to solve the above problems, a game terminal device including a storage medium storing the above information processing program may be provided.

In order to solve the above-mentioned problems, an information processing system is provided in a server, a storage unit that stores predetermined player information in a storage unit for each player, and a storage unit that is provided in a player terminal, and a request from an operation unit of the player terminal. the input of the operation, the join to invite invitation information of a plurality of players to play available communication game simultaneously, in association with a plurality of other receiving terminals request information requests that the memory in the server, the server A request information transmitting unit that transmits to the player terminal, permission state information that enables reception of invitation information from a server as a receiving terminal, based on at least a game play state of the player terminal; and A state updating unit configured to store play state information including impossible state information that disables reception of invitation information; Upon receiving the al request information, based on the player information stored in at least the storage unit, in association with a plurality of player terminals and invitation information, the player terminal to which the invitation information is associated, the invitation information A setting unit for setting an extraction terminal capable of receiving the information , and provided in the player terminal, and when permission state information is stored as play state information, whether the player terminal is set as the extraction terminal as a reception terminal. communicates to check if they are configured to extract the terminal receives the invitation information from the server, a receiver you store the invitation information storage unit of the player terminal, is provided to the player terminal, receiving the invitation information A notification unit for notifying reception of invitation information at the time or after reception, and input of a predetermined participation operation at the time of notification of reception of invitation information or after notification A communication game is executed between the operation permission unit that enables the operation, one or more player terminals provided with the participation information based on the input of the participation operation, and the player terminal that has transmitted the request information. And a game execution unit.

In order to solve the above-mentioned problems, an information processing system is provided in a server, a storage unit that stores predetermined player information in a storage unit for each player, and a storage unit that is provided in a player terminal, and a request from an operation unit of the player terminal. the input of the operation, the join to invite invitation information of a plurality of players to play available communication game simultaneously, in association with a plurality of other receiving terminals request information requests that the memory in the server, the server A request information transmitting unit for transmitting to the player terminal, permission state information capable of notifying reception of the invitation information from the server based on at least a game play state at the player terminal, and invitation information from the server. A state update unit for storing play state information including impossible state information for which reception cannot be notified; and a request information provided from a player terminal provided in the server. When receiving, based on the player information stored in at least the storage unit, in association with a plurality of player terminals and invitation information, the player terminal to which the invitation information is associated, capable of receiving said invitation information A setting unit for setting the extraction terminal, provided in the player terminal, when the player terminal is set as the extraction terminal, receives the invitation information from the server as a receiving terminal , and stores the invitation information in the invitation information storage unit of the player terminal. and you storage receiving unit, provided to the player terminal, after receiving the time or reception of the invitation information, if the permission status information as play status information is stored, and a notification unit for notifying the reception of the invitation information, the player An operation permitting unit that is provided in the terminal and that enables a predetermined participation operation to be input at the time of or after the notification of the reception of the invitation information; Comprising one or a plurality of player terminals any participation information is transmitted based on the force, and a game execution unit for executing a communication game with the player terminal that has transmitted the request information.

  According to the present invention, it is possible to reduce the time required to start a communication game in which a plurality of players can participate.

FIG. 1 is an explanatory diagram showing a schematic configuration of the information processing system. FIG. 2A is a diagram illustrating a hardware configuration of a player terminal. FIG. 2B is a diagram illustrating the configuration of the hardware of the server. FIG. 3A is a diagram showing an example of the party organization screen. FIG. 3B is a diagram illustrating an example of the information confirmation screen. FIG. 3C is a diagram illustrating an example of a battle game selection page on the quest screen. FIG. 3D is a diagram illustrating an example of a play content selection page on the quest screen. FIG. 4A is a diagram illustrating an example of a play content selection page when single play is selected. FIG. 4B is a diagram illustrating an example of the battle screen. FIG. 4C is a diagram illustrating an example of a result screen. FIG. 5A is a diagram illustrating an example of a play content selection page when multiplay is selected. FIG. 5B is a diagram illustrating an example of a room selection page. FIG. 5C is a diagram illustrating an example of the target person selection page. FIG. 5D is a diagram illustrating an example of the room detail page. FIG. 6A is a diagram illustrating an example of notification of reception of invitation information on a normal screen. FIG. 6B is a diagram illustrating an example of notification of reception of invitation information on the battle screen. FIG. 6C is a diagram illustrating an example of the invitation information dialog. FIG. 6D is a diagram illustrating an example of the screen after the hold operation. FIG. 7A is a diagram illustrating an example of a screen before a rejection operation. FIG. 7B is a diagram illustrating an example of the screen after the rejection operation. FIG. 7C is a diagram illustrating an example of a screen before the participation operation. FIG. 7D is a diagram illustrating an example of the screen after the participation operation. FIG. 8A is a diagram illustrating an example of a notification mode of reception of guidance information on a normal screen. FIG. 8B is a diagram illustrating an example of the guidance information dialog. FIG. 8C is a diagram illustrating an example of the screen after the non-display operation. FIG. 8D is a diagram illustrating an example of the screen after the browsing operation. FIG. 9A is a diagram illustrating the priority points. FIG. 9B is a diagram illustrating the update condition of the priority point. FIG. 10 is a first diagram illustrating the list update process. FIG. 11 is a second diagram illustrating the list update process. FIG. 12 is a third diagram illustrating the list update process. FIG. 13 is a fourth diagram illustrating the list update process. FIG. 14A is a diagram illustrating a play state of the player terminal. FIG. 14B is a diagram illustrating the timing of confirming the reception of the invitation information. FIG. 15 is a sequence diagram illustrating basic processing of the player terminal and the server. FIG. 16 is a sequence diagram illustrating processing of the player terminal and the server when multiplay is performed. FIG. 17 is a sequence diagram illustrating processing of the player terminal and the server when it is not possible to participate in multiplay. FIG. 18 is a sequence diagram illustrating processing of the player terminal and the server when the participation in multiplay is rejected. FIG. 19 is a diagram illustrating a configuration of a memory in a player terminal and a function as a computer. FIG. 20 is a flowchart illustrating an example of the terminal-side game process in the player terminal. FIG. 21 is a flowchart illustrating an example of a room creation-related process in the player terminal. FIG. 22 is a flowchart illustrating an example of the invitation information receiving process in the player terminal. FIG. 23 is a flowchart illustrating an example of the invitation information confirmation processing in the player terminal. FIG. 24 is a first flowchart illustrating an example of a process after receiving invitation information in a player terminal. FIG. 25 is a second flowchart illustrating an example of a process after receiving the invitation information in the player terminal. FIG. 26 is a flowchart illustrating an example of the multiplay end process in the player terminal. FIG. 27 is a diagram illustrating a configuration of a memory in a server and a function as a computer. FIG. 28 is a flowchart illustrating an example of a server-side game process in the server. FIG. 29 is a flowchart illustrating an example of the request information receiving process in the server. FIG. 30 is a flowchart illustrating an example of the information update process in the server. FIG. 31 is a flowchart illustrating an example of the multiplay end process in the server. FIG. 32 is a flowchart illustrating an example of the sorting process in the server. FIG. 33 is a flowchart illustrating an example of an invitation information receiving process according to a modification in the player terminal. FIG. 34 is a diagram illustrating a configuration of a memory of the second embodiment in a player terminal and a function as a computer. FIG. 35 is a diagram illustrating a configuration of a memory according to the second embodiment of the server and a function as a computer. FIG. 36A is a first sequence diagram illustrating processing of a player terminal and a server according to the second embodiment. FIG. 36B is a second sequence diagram illustrating processing of the player terminal and the server in the second embodiment. FIG. 36C is a third sequence diagram illustrating processing of the player terminal and the server in the second embodiment.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to the accompanying drawings. The dimensions, materials, other specific numerical values, and the like shown in the embodiments are merely examples for facilitating understanding, and do not limit the present invention unless otherwise specified. In the specification and the drawings, elements having substantially the same function and configuration will be denoted by the same reference numerals, and redundant description will be omitted. Elements not directly related to the present invention will be omitted. I do.

(Overall Configuration of Information Processing System S)
FIG. 1 is an explanatory diagram showing a schematic configuration of the information processing system S. The information processing system S is a so-called client-server system including the player terminal 1, the server 100, and a communication network 200 having a communication base station 200a.

  The player terminal 1 can establish communication with the server 100 via the communication network 200. The player terminal 1 broadly includes electronic devices that can be connected to the server 100 by wireless or wired communication. Examples of the player terminal 1 include a smartphone, a mobile phone, a tablet device, a personal computer, a game device, and the like. In the present embodiment, a case where a smartphone is used as the player terminal 1 will be described.

  The server 100 is connected for communication with a plurality of player terminals 1. The server 100 stores various information (player information) for each player who plays the game. Further, the server 100 updates the stored information and controls the progress of the game based on an operation input from the player terminal 1.

  The communication base station 200a is connected to the communication network 200, and transmits and receives information to and from the player terminal 1 by radio. The communication network 200 includes a mobile phone network, the Internet, a LAN (Local Area Network), a dedicated line, and the like, and realizes a wireless or wired communication connection between the player terminal 1 and the server 100.

  In the information processing system S of the present embodiment, the player terminal 1 and the server 100 function as a game device G. The role of controlling the progress of the game is assigned to the player terminal 1 and the server 100, respectively, and the cooperation of the player terminal 1 and the server 100 enables the game to proceed.

(Hardware configuration of player terminal 1 and server 100)
FIG. 2A is a diagram illustrating a hardware configuration of the player terminal 1. FIG. 2B is a diagram illustrating a hardware configuration of server 100. As shown in FIG. 2A, the player terminal 1 includes a CPU (Central Processing Unit) 10, a memory 12, a bus 14, an input / output interface 16, a storage unit 18, a communication unit 20, an input unit 22, and an output unit 24. Is done.

  Further, as shown in FIG. 2B, the server 100 includes a CPU 110, a memory 112, a bus 114, an input / output interface 116, a storage unit 118, a communication unit 120, an input unit 122, and an output unit 124.

  Note that the configuration and functions of the CPU 110 of the server 100, the memory 112, the bus 114, the input / output interface 116, the storage unit 118, the communication unit 120, the input unit 122, and the output unit 124 correspond to the CPU 10, the memory 12, They are substantially the same as the bus 14, the input / output interface 16, the storage unit 18, the communication unit 20, the input unit 22, and the output unit 24. Therefore, hereinafter, the hardware configuration of the player terminal 1 will be described, and the description of the server 100 will be omitted.

  The CPU 10 operates a program stored in the memory 12 to control the progress of the game. The memory 12 is configured by a ROM (Read Only Memory) or a RAM (Random Access Memory), and stores programs and various data necessary for controlling the progress of the game. The memory 12 is connected to the CPU 10 via a bus 14.

  An input / output interface 16 is connected to the bus 14. The storage unit 18, the communication unit 20, the input unit 22, and the output unit 24 are connected to the input / output interface 16.

  The storage unit 18 is configured by a semiconductor memory such as a DRAM (Dynamic Random Access Memory) and stores various programs and data. In the player terminal 1, the programs and data stored in the storage unit 18 are loaded into the memory 12 (RAM) by the CPU 10.

  The communication unit 20 is wirelessly connected to the communication base station 200a, and transmits and receives information such as various data and programs to and from the server 100 via the communication network 200. In the player terminal 1, a program or the like received from the server 100 is stored in the memory 12 or the storage unit 18.

  The input unit 22 includes, for example, a touch panel, a button, a keyboard, a mouse, a cross key, an analog controller, and the like to which an operation of the player is input (accepts the operation). Further, the input unit 22 may be a dedicated controller provided in the player terminal 1 or connected to (externally attached to) the player terminal 1. Furthermore, the input unit 22 may be configured by an acceleration sensor that detects the inclination or movement of the player terminal 1, or a microphone that detects the voice of the player. That is, the input unit 22 broadly includes a device capable of identifiably inputting a player's intention.

  The output unit 24 includes a display device and a speaker. Note that the output unit 24 may be a device connected (externally) to the player terminal 1. In the present embodiment, the player terminal 1 includes a display 26 as the output unit 24, and includes a touch panel provided to overlap the display 26 as the input unit 22.

(Game content)
Next, the content of the game provided by the information processing system S (game device G) of the present embodiment will be described using an example. In the present embodiment, a so-called battle game in which an ally character battles an enemy character is provided. Specifically, in the game of the present embodiment, a plurality of ally characters are provided. The player selects a plurality (here, three) of the provided ally characters to form a party. Further, the player can play a plurality of types of battle games having different enemy characters and difficulty levels. In the battle game, a player operates a teammate character formed in a party and defeats an enemy character to obtain a reward.

  FIG. 3A is a diagram showing an example of the party organization screen. FIG. 3B is a diagram illustrating an example of the information confirmation screen. FIG. 3C is a diagram illustrating an example of a battle game selection page on the quest screen. FIG. 3D is a diagram illustrating an example of a play content selection page on the quest screen. A game screen as shown in FIGS. 3A, 3B, 3C, and 3D is displayed on the display 26 of the player terminal 1. In the present embodiment, the game screen is roughly divided into a normal screen and a battle screen.

  The normal screen is mainly a screen for the player to confirm various settings and information. On the other hand, the battle screen is a screen displayed on the display 26 from the start to the end of the battle game. Here, all screens other than the battle screen are normal screens. The normal screen is roughly divided into four screens: a home screen (not shown), a party organization screen shown in FIG. 3A, an information confirmation screen shown in FIG. 3B, and a quest screen shown in FIGS. 3C and 3D.

  Note that the party organization screen and the quest screen are composed of a plurality of pages, and the pages are switched by the operation of the player. On the normal screen, a header display area 30 is provided above the display 26. In the header display area 30, a stamina display bar 32 indicating the stamina of the player is displayed.

  Note that stamina is a parameter necessary for playing the battle game. In the present embodiment, a plurality of types of battle games are provided, and a stamina consumption value required for play is set in each battle game. Since the player consumes the stamina and plays the battle game, the player cannot play the battle game if the stamina is insufficient.

  Although a detailed description is omitted, the player can acquire a predetermined value as the player experience value when winning in the battle game. Each time the player experience value reaches a certain value, the player level increases. An upper limit of stamina is set at the player level, and as the player level increases, the upper limit of stamina also increases. The stamina recovers by a predetermined value (for example, one point) every predetermined time (for example, 5 minutes) within the range of the upper limit value. The stamina display bar 32 is displayed so that the current remaining amount of the stamina can be visually grasped with respect to the upper limit value of the stamina.

  At the left end of the header display area 30, a notification image 34 is displayed. As will be described in detail later, the notification image 34 notifies the player of reception of battle game invitation information or event guide information. In a state where neither the invitation information nor the guidance information has been received, the notification image 34 is displayed in a non-notifying manner. Note that the notification image 34 in the non-notification mode is displayed in a light color as a whole. On the other hand, when at least one of the invitation information and the guidance information is received, the notification image 34 is displayed in a notification manner. The notification image 34 of the notification mode is highlighted in a color more conspicuous than the non-report mode.

  On the normal screen, a menu bar 36 is displayed below the display 26. The menu bar 36 is provided with a plurality of operation units that can be operated (tapped) by the player. Here, as an example of the operation unit, a home screen selecting unit 36a marked “Home”, a party organization screen selecting unit 36b marked “Party”, and a quest screen marked “Quest” are displayed on the menu bar 36. A selection unit 36c and an information confirmation screen selection unit 36d marked “Info” are provided.

  When the home screen selection unit 36a is tapped, a home screen is displayed on the display 26. In addition, when the party formation screen selection unit 36b is tapped, the party formation screen shown in FIG. 3A is displayed on the display 26. Similarly, when the information confirmation screen selection unit 36d is tapped, the information confirmation screen shown in FIG. 3B is displayed on the display 26, and when the quest screen selection unit 36c is tapped, the quest screen (battle game selection) shown in FIG. Page) is displayed on the display 26.

  As described above, the normal screen is roughly divided into four screens. In the menu bar 36, the operation unit corresponding to each screen is highlighted so that the screen displayed on the display 26 can be identified. When a page changes within the normal screen or when the screen changes to a different normal screen, the stamina display bar 32, the notification image 34, and the menu bar 36 remain displayed. That is, in the screen transition of the normal screen, images other than the header display area 30 and the menu bar 36 are switched.

  On the party formation screen shown in FIG. 3A, all the ally characters possessed by the player are displayed. The player can form one party by selecting three ally characters from the displayed ally characters. Here, up to six parties can be organized and stored. An experience value and a level are stored in association with each ally character. The experience value increases when a battle game described later is won or when a predetermined item is used. The level is set according to the experience value, and increases each time the experience value reaches a predetermined value. Note that an upper limit of the level is set for each ally character, and the level increases only within the range of the upper limit.

  In addition, base values of combat power such as life points, attack power, and defense power are set for the ally characters in accordance with the level. The player can advantageously advance the battle game as the fighting power of the ally character increases. Each base value set for the ally character increases as the level increases.

  Further, on the party formation screen, the player can equip (set) equipment such as weapons and armor to the ally characters incorporated in the party. Each equipment is set with an added value to the attack power and the defense power. When the equipment is equipped, the added value of each equipment is added to the above base value, so that the fighting power of the ally character can be increased.

  On the information confirmation screen shown in FIG. 3B, player information relating to the player is displayed. As the player information, for example, a player name, a player experience value, a player level, a player rank, the number of held characters (the number of friendly characters held by the player), the number of followers, and the number of mutual followers are displayed. In the present embodiment, the follower indicates another player set as a so-called favorite or a friend by the player. Further, in the present embodiment, the mutual followers indicate players who are set as followers with each other.

  On the battle game selection page of the quest screen shown in FIG. 3C, a plurality of selection tabs 38 indicating the type of the provided battle game, that is, the battle game name are displayed. Here, ten types of battle games are provided, and ten selection tabs 38 are displayed. Each battle game has an open condition. The release conditions include, for example, that the player experience value, the player level, and the player rank are equal to or higher than a predetermined value, and that another predetermined battle game is completed.

  The player can play only the battle game satisfying the opening condition. Therefore, on the battle game selection page, the selection tab 38 of the battle game that does not satisfy the opening condition is displayed with a key as shown in the figure. Further, only the selection tab 38 of the battle game that satisfies the opening condition accepts the operation (tap) of the player.

  When the selection tab 38 is tapped on the battle game selection page, a play content selection page shown in FIG. 3D is displayed. On this play content selection page, a party used in the battle game can be selected from the parties organized on the party organization screen. Further, in the present embodiment, as a play type, a single play in which a player plays a battle game alone, and a multi-play in which a player plays a battle game in cooperation with another player through communication are provided. A single play tab 40a and a multi play tab 40b are displayed on the play content selection page.

  FIG. 4A is a diagram illustrating an example of a play content selection page when single play is selected. FIG. 4B is a diagram illustrating an example of the battle screen. FIG. 4C is a diagram illustrating an example of a result screen. As shown in FIG. 4A, when the type of the battle game and the party to be used in the battle game are selected and the single play tab 40a is operated, the single play is started. In the following, a friendly character included in a party used in the battle game, that is, a friendly character operated by the player in the battle game is referred to as a “player character”. In the battle game, the player operates the input unit 22 of the player terminal 1 to operate the player character.

  During the battle game, a battle screen is displayed as shown in FIG. 4B. On the battle screen, the player character and the enemy character are displayed on the display 26. The player character operates according to the operation of the player, and damages the enemy character or receives damage from the enemy character. Also, the enemy character operates under computer control, and damages the player character or receives damage from the player character.

  When a damage point is given to the enemy character, the damage point is subtracted from the life point of the enemy character. Similarly, when a damage point is given to a player character, the damage point is subtracted from the life point of the player character. When the life point of the enemy character becomes 0, the player wins, and when the life points of all player characters become 0, the player loses.

  Here, on the battle screen, as shown in FIG. 4B, the menu bar 36 displayed on the normal screen is not displayed. In the header display area 30, the stamina display bar 32 is not displayed, and the life point for each player character is displayed. Further, an operation tab 42 is displayed in the header display area 30 on the battle screen. The display position of the operation tab 42 is the same as the position in the header display area 30 where at least a part of the notification image 34 is displayed on the normal screen.

  When the operation tab 42 is tapped during the battle game, the battle game is interrupted. At this time, an unillustrated interruption screen is superimposed on the battle screen on the display 26. The interruption screen is provided with a retirement operation unit and a restart operation unit, and the player can select retirement (end) or restart of the battle game by tapping these operation units.

  When the battle game ends normally (ends normally), a result screen is displayed on the display 26 as shown in FIG. 4C. In the present embodiment, the normal end of the battle game includes three end patterns of a halfway end due to retirement, a victory end in which the victory is determined in the battle game, and a defeat end in which the defeat is determined in the battle game. FIG. 4C shows a result screen at the end of the victory as an example, but the result screen is different for each end pattern.

  On the result screen, an end operation unit 44 with “close” is displayed, and when the end operation unit 44 is tapped, the display on the display 26 switches from the battle screen to the normal screen. That is, the result screen is a part of the battle screen. The normal screen that switches from the result screen may be the screen that was displayed immediately before switching to the battle screen, or may be a predetermined screen such as a home screen. Thus, the battle game ends with the end of the display of the result screen.

  FIG. 5A is a diagram illustrating an example of a play content selection page when multiplay is selected. FIG. 5B is a diagram illustrating an example of a room selection page. FIG. 5C is a diagram illustrating an example of the target person selection page. FIG. 5D is a diagram illustrating an example of the room detail page. As shown in FIG. 5A, it is assumed that the type of the battle game and the party to be used in the battle game are selected and the multiplayer tab 40b is tapped.

  In this case, a room selection page of the quest screen is displayed as shown in FIG. 5B. On the room selection page, a room creation tab 46 labeled "Room creation" is displayed. In the present embodiment, the “room” indicates a place where all players participating in the multiplay share information, and may indicate an area secured in the server 100 for performing the multiplay.

  The player can create a room by himself / herself by tapping the room creation tab 46 (inputting a request operation) when performing the multiplay. In the following, a player who has created a room in multiplayer is referred to as a host player. A player who has entered a room created by another player is called a guest player.

  When the room creation tab 46 is tapped, a target person selection page of the quest screen is displayed as shown in FIG. 5C. On the target person selection page, a follower tab 48a marked "follower", a mutual follower tab 48b marked "mutual follower", and a random tab 48c marked "random" are displayed. The player who creates the room can select a target person (guest player) to be invited to the room created by himself on the target person selection page.

  Specifically, when the follower tab 48a is operated, the player who has been set as a follower by the player who creates the room is set as the target person who can receive the invitation information. In the present embodiment, only the player set as the target person can receive the invitation information, and the player not set as the target person does not receive the invitation information. As will be described in detail later, the target person does not receive the invitation information unless a certain condition is satisfied. Therefore, the target person can be said to be a player who has just obtained the right to receive the invitation information.

  When the mutual follower tab 48b is operated, the player who is set as the mutual follower by the player who creates the room is set as the target person. On the other hand, when the random tab 48c is operated, the target person is set from all the players registered in the server 100. The player terminal 1 of the player set as the target receives the invitation information when communicating with the server 100. The target person who has received the invitation information can determine whether to enter the room, that is, whether to participate in multiplayer. Thus, entering the room is limited to the player who has received the invitation information.

  For example, when the random tab 48c is tapped as shown in FIG. 5C, a room detail page of the quest screen is displayed as shown in FIG. 5D. On the room detail page, various information (room information) including party information indicating the party selected by the host player is displayed. In addition, a start tab 50 indicating "ready" is displayed on the room detail page of the host player. When the host player taps the start tab 50, multi play is started.

  FIG. 6A is a diagram illustrating an example of notification of reception of invitation information on a normal screen. FIG. 6B is a diagram illustrating an example of notification of reception of invitation information on the battle screen. FIG. 6C is a diagram illustrating an example of the invitation information dialog 52. FIG. 6D is a diagram illustrating an example of the screen after the hold operation. For example, as shown in FIG. 6A, it is assumed that an information confirmation screen is displayed on the display 26 in the player terminal 1 of the target person. In this state, when the player terminal 1 receives the invitation information, the notification image 34 is switched from the non-notification mode to the notification mode in the header display area 30 as illustrated.

  6B, a battle screen is displayed on the display 26 of the player terminal 1 of the target person. As described above, on the battle screen, the operation tab 42 is normally displayed in the header display area 30 (see FIG. 4B). However, when the player terminal 1 receives the invitation information, the operation tab 42 is displayed as illustrated. Is switched to the notification image 34 of the notification mode.

  When the notification image 34 displayed in the notification mode is tapped, the invitation information dialog 52 is displayed (opened) as shown in FIG. 6C. The invitation information dialog 52 is superimposed on the screen displayed when the notification image 34 is tapped. When the notification image 34 is tapped during the battle game, the battle game is interrupted in the same manner as when the operation tab 42 is tapped, and the invitation information dialog 52 is displayed on the battle screen at the time of the interruption. You.

  In the invitation information dialog 52, as the quest information, for example, information such as the player rank of the host player, the player name, and the type of the battle game played in the multiplayer are displayed. Also, the invitation information dialog 52 is provided with a participation tab 52a marked "join", a reject tab 52b marked "don't join", and a hold tab 52c marked "close". .

  The participation tab 52a receives a participation operation for participating in multiplay, that is, a request to enter the invited room. The rejection tab 52b receives a rejection operation for rejecting participation in multiplay. Further, the hold tab 52c receives a hold operation for holding or not participating in multiplay.

  For example, it is assumed that the hold tab 52c is tapped after opening the invitation information dialog 52, and a hold operation is input. When the hold operation is input, the invitation information dialog 52 is closed (not displayed) as shown in FIG. 6D. However, when the hold operation is input, the notification image 34 continues to be displayed in the notification mode. When a hold operation is input while the invitation information dialog 52 is displayed during the battle game, the battle game is restarted at the same time as the invitation information dialog 52 is closed. Also in this case, the notification image 34 continues to be displayed in the notification mode.

  FIG. 7A is a diagram illustrating an example of a screen before a rejection operation. FIG. 7B is a diagram illustrating an example of the screen after the rejection operation. As shown in FIG. 7A, it is assumed that the rejection tab 52b is tapped after the invitation information dialog 52 is opened, and a rejection operation is input. When the rejection operation is input, as shown in FIG. 7B, at the same time as the invitation information dialog 52 is closed (hidden), the notification image 34 is switched to the non-notification mode.

  If a rejection operation is input while the invitation information dialog 52 is displayed during the battle game, the battle game is restarted at the same time as the invitation information dialog 52 is closed. In this case, in the header display area 30, the notification image 34 is not displayed, and the operation tab 42 is displayed.

  FIG. 7C is a diagram illustrating an example of a screen before the participation operation. FIG. 7D is a diagram illustrating an example of the screen after the participation operation. As shown in FIG. 7C, it is assumed that the participation tab 52a is tapped after the invitation information dialog 52 is opened, and a participation operation is input. When the participation operation is input, the participation information is transmitted from the player terminal 1 of the target person to the server 100. When the participation information is input, the server 100 determines whether it is possible to enter the invited room.

  Specifically, in the invited room, when multiplayer has already started (during play), when the maximum number of guest players has entered the room (full), when the room has disappeared (dissolution) ), It is determined that it is impossible to enter the room. In this case, a dialog (not shown) indicating that entry into the room is not possible is displayed on the display 26 of the player terminal 1.

  On the other hand, it is assumed that the server 100 determines that it is possible to enter the room. In this case, the player information of the target person who transmitted the participation information is added to the room, and the room information is updated. As described above, when the participation operation is performed and the room can be entered, the target person is set as the guest player. When the room information is updated, the host player and all the guest players receive the updated room information.

  At this time, a room detail page is displayed on the player terminal 1 of the guest player (hereinafter, referred to as “guest terminal”), as shown in FIG. 7D. With the updated room information, the player information of the host player and the player information of all the guest players are displayed on the room detail page. As described above, the start tab 50 is provided on the room detail page displayed on the player terminal 1 of the host player (hereinafter, referred to as “host terminal”). On the other hand, as shown in FIG. 7D, the start tab 50 is not provided on the room detail page displayed on the guest terminal. Therefore, only the host player can start multi-play.

  Note that the room detail page displayed on the guest terminal is not provided with an operation unit for receiving an operation of leaving the room. That is, the guest player cannot formally leave the room in which he / she entered. As a result, the situation in which the guest player repeatedly enters and leaves the room is suppressed, and early start of multiplayer is realized. However, an operation unit for exit may be provided on the room detail page of the guest terminal so that the guest player can exit. An operation unit for intentionally disbanding a room may be provided on the room detail page displayed on the host terminal.

  Although not shown, when the notification image 34 displayed in the non-notification mode is tapped, a dialog for notifying that there is no invitation information is displayed. As described above, when the rejection operation is performed, the notification image 34 is switched to the non-notification mode. Therefore, even if the notification image 34 is operated immediately after the rejection operation is input, the notification that the invitation information does not exist is provided. Done. That is, the target person cannot participate in the multiplay for which the participation has been refused once.

  On the other hand, when the above-described hold operation is performed, the notification image 34 is displayed in the notification mode even after the invitation information dialog 52 is closed. Therefore, if the notification image 34 is tapped again after performing the hold operation, the invitation information dialog 52 is displayed again, and the target person can input a participation operation for the invited multiplay. However, as described above, if the invited room is in play, full, or disappeared, it is determined that it is impossible to enter the room, and it is impossible to enter the room Is displayed.

  FIG. 8A is a diagram illustrating an example of a notification mode of reception of guidance information on a normal screen. FIG. 8B is a diagram illustrating an example of the guidance information dialog 54. FIG. 8C is a diagram illustrating an example of the screen after the non-display operation. FIG. 8D is a diagram illustrating an example of the screen after the browsing operation. In the present embodiment, the player terminal 1 receives the guidance information of the event. The guide information is set in the server 100 by the operator, and the player terminal 1 receives the guide information from the server 100 when communicating with the server 100.

  The reception of the guidance information is notified to the player by the notification image 34, similarly to the reception of the invitation information. For example, as shown in FIG. 8A, when the guide information is received in a state where the information confirmation screen is displayed on the display 26, the notification image 34 is switched to the notification mode. When the notification image 34 is tapped in this state, the guidance information dialog 54 is displayed (opened) as shown in FIG. 8B. The guidance information dialog 54 is superimposed on the screen displayed when the notification image 34 is tapped. If the notification image 34 is tapped during the battle game, the battle game is interrupted, and the guidance information dialog 54 is displayed superimposed on the battle screen at the time of the interruption.

  The guidance information dialog 54 displays, for example, information about quests that are regularly held. In addition, the guidance information dialog 54 includes a non-display tab 54a indicating "close" and a browsing tab 54b indicating "to event". The non-display tab 54a receives a non-display operation for ending the display of the guidance information dialog 54. The browsing tab 54b receives a browsing operation for browsing event information.

  For example, it is assumed that the non-display tab 54a is tapped after the guidance information dialog 54 is opened, and a non-display operation is input. When the non-display operation is input, the guidance information dialog 54 is closed (not displayed) as shown in FIG. 8C. However, when the non-display operation is input, the notification image 34 continues to be displayed in the notification mode. If a non-display operation is input while the guidance information dialog 54 is displayed during the battle game, the battle game is restarted at the same time as the guidance information dialog 54 is closed. Also in this case, the notification image 34 continues to be displayed in the notification mode. However, when the non-display operation is input from the non-display tab 54a, the notification image 34 may be switched from the notification mode to the non-report mode.

  On the other hand, it is assumed that the browsing tab 54b is tapped after the guidance information dialog 54 is opened and a browsing operation is input. When a browsing operation is input, an event guide screen on which event information that can be participated is displayed is displayed as shown in FIG. 8D. Although detailed description is omitted, on the event guide screen, a player's operation input can be performed, and participation in the event can be performed by the input operation. When the event guide screen is displayed, the notification image 34 switches to the non-notification mode.

  As described above, the notification image 34 notifies the reception of the two types of information, the invitation information and the guidance information. Here, the notification image 34 is displayed in a common notification mode regardless of the type of the received information. It is assumed that the notification image 34 displayed in the notification mode is tapped when both the invitation information and the guidance information are received. In this case, an invitation information dialog 52 is displayed on the display 26. That is, the invitation information (the invitation information dialog 52) is displayed with priority over the guidance information (the guidance information dialog 54).

  However, when both the invitation information and the guidance information are received, the guidance information (the guidance information dialog 54) may be displayed with higher priority than the invitation information (the invitation information dialog 52). Alternatively, guidance information (guidance information dialog 54) and invitation information (invitation information dialog 52) may be displayed simultaneously. Furthermore, the notification image 34 may notify only the reception of the invitation information. Further, the notification image 34 may notify the reception of the invitation information and the reception of the guidance information in a distinguishable manner. Here, the player terminal 1 receives the guidance information, but the guidance information is not essential.

  Here, in the present embodiment, a multiplayer can be executed by a plurality of players for the first time by the host player inviting the target person and entering the room as a guest player. The authority to start multiplay is given only to the host player. Therefore, if the guest player leaves the room without operating the start tab 50 even though the guest player enters the room and is ready to start the multiplayer, the multiplayer is not started forever, and stress is imposed on the guest player. Will be given. Therefore, in the present embodiment, the extraction of the target person in the server 100 and the reception and notification of the invitation information in the player terminal 1 are performed as follows in order to reduce the neglect by the host player. Hereinafter, first, a method of extracting a target person in the server 100 will be described, and then, a method of receiving and notifying the invitation information in the player terminal 1 will be described.

(Method of extracting target persons)
FIG. 9A is a diagram illustrating the priority points. FIG. 9B is a diagram illustrating the update condition of the priority point. The server 100 stores player information for each player (player ID). The player information includes, for example, various information necessary for playing the game, such as a player experience value, a player level, a player rank, a possessed character, a follower, a mutual follower, and party information.

  The player information includes priority information as information for extracting a target person to receive the invitation information. The server 100 stores the player information including the priority information in the storage unit 118 for each player, and updates the priority information according to a preset update condition.

  In the present embodiment, a priority point is provided as priority information. As shown in FIG. 9A, the priority point has a maximum value set to 999 points and a minimum value set to 0 points, and is updated in the range of 0 to 999. Also, 100 points are set as an initial value for the priority point, and when a predetermined update condition is satisfied, the priority point is updated to the initial value.

  When the random tab 48c is tapped when creating a room, the server 100 randomly extracts a target person who can receive the invitation information from all the players. At this time, the server 100 preferentially sets the player with the higher priority point as the target person. Therefore, the player with a higher priority point is more likely to receive the invitation information.

  The update condition of the priority point is set as shown in FIG. 9B. Specifically, when the invitation information is received as the target person, the priority point of the target person is subtracted by “4”. When the target person taps the notification image 34 to open the invitation information dialog 52 after receiving the invitation information, the priority point of the target person is incremented by “1”.

  In addition, when the target person taps the participation tab 52a of the invitation information dialog 52 to perform the participation operation, but cannot participate in the multiplay, the priority point of the target person is added by “4”. Note that the case where the user cannot participate in the multi-play includes the case where the room cannot be entered during the play or the room is full, and the case where the room is dissolved before the start of the multi-play after entering the room. Here, the priority point of the target person is added when the user cannot participate in the multi play, but instead, for example, when the user cannot enter the room, the priority point of the target person is added. You may.

  Further, it is assumed that the battle game in the multi-play has been normally terminated (including the termination by retirement, the victory termination and the defeat termination). At this time, if the priority point of the guest player at the end of the battle game is larger than the initial value, the priority point of the guest player is reset to the initial value.

  When a room is created as a host player, the priority point of the host player is subtracted by “4”. At this time, when the random tab 48c is tapped to randomly extract a target person to receive the invitation information, the priority point of the host player is added by "1". In addition, when the multiplayer is started, the priority point of the host player is added by “1”.

  Furthermore, when the battle game based on multi-play ends with victory or loss, damage given to the enemy character (hereinafter referred to as “damage”) is given a priority point for all players who have 20% or more of all damage. Is added by “3”.

  According to the above update conditions, for example, when the target person attempts to participate in multi-play but cannot participate, reception of the invitation information (-4), opening of the invitation information (+1), and failure to participate in the multi-play By (+4), the priority point increases by “1” on the basis of before the reception of the invitation information. This makes it easier for players who have attempted to participate in multiplayer but failed to participate to receive the invitation information. In addition, when the priority game has exceeded the initial value and the battle game by multi-play ends normally, the initial value is reset. As a result, the opportunity to receive the invitation information is equally given to many players.

  Also, in the guest player who participated in the multi-play, if the damage given becomes 20% or more of the total damage, the invitation information is received (-4), the invitation information is opened (+1), and the damage given is 20% or more (+3). Priority points will be plus or minus zero based on before multiplayer participation. On the other hand, the guest player whose damage is less than 20% of the total damage receives the invitation information (−4) and opens the invitation information (+1), so that the priority point is “3” on the basis of before the multiplayer participation. Is subtracted. That is, a guest player who is not cooperative in multiplayer has a lower priority, and is less likely to be set as a target person. As described above, by changing the priority points based on the game result during the communication game, a cooperative player is relatively easily set as the target person.

  Further, the host player decrements the priority point by “4” when the room is created. However, if the multiplayer is started and the damage given becomes 20% or more of the total damage, the priority point does not decrease. Specifically, when the target person is randomly extracted, the room is created (−4), the target person is randomly extracted (+1), the multiplayer is started (+1), and the damage given is 20% or more (+3). The priority point increases by “1” on the basis of before the creation of the room. Also, when the target person is set to follower or mutual follower, the priority point is set based on the state before the creation of the room by creating the room (−4), starting the multi-play (+1), and giving the damage of 20% or more (+3). Is plus or minus zero. Accordingly, when the multiplayer is properly started and played cooperatively as the host player, the host player is considered to be a good player, and the opportunity to participate in the multiplay as a guest player is also secured.

  On the other hand, when the room is created but the multiplayer is not started, for example, by creating the room (−4) and randomly extracting the target person (+1), priority is given based on before the creation of the room. Points are reduced by "3". In addition, even when the damage given to the host player is less than 20% of the total damage, for example, the room creation (-4), the target person is randomly extracted (+1), and the multi-play start (+1) is performed before the room creation. , The priority point is reduced by “2”. This makes it difficult for a player who leaves the room or intentionally disbands the room or a non-cooperative player to participate in multiplayer as a guest player.

  According to the present embodiment in which the update conditions are set as described above, the invitation information can be easily delivered to a player who seems to be cooperative or excellent, and appropriate matching can be realized. Hereinafter, processing of the server 100 when setting a target person from all players will be described.

(List update processing of server 100)
FIG. 10 is a first diagram illustrating the list update process. The storage unit 118 of the server 100 is provided with a player information storage unit 160 (see FIG. 27) for storing player information for each player. In the server 100, every time communication is performed with the player terminal 1, a player information updating process for updating player information in the player information storage unit 160 is performed. The storage unit 118 is provided with an extraction list. In the server 100, a list update process for updating the extraction list is constantly performed based on the player information in the player information storage unit 160.

  For example, in an extraction list provided in the storage unit 118, as shown in FIG. 10, a player (player ID), invitation information (room number), a status flag, and a wait time are stored in each of a large number of storage areas with addresses. Is set. Note that the extraction list shown in FIG. 10 and the information set in the extraction list are merely examples. For example, a priority point and a player rank are not indispensable as information set in the extraction list, and the information set in the extraction list can be appropriately designed. Also, in FIG. 10, the numbers described in the addresses correspond to the priorities, and the storage areas with smaller numbers have higher priorities.

  The extraction list is provided for each player rank. For example, a plurality of extraction lists are provided, such as an extraction list in which players with player ranks of 1 to 10 are listed and an extraction list in which players with player ranks of 11 to 20 are listed. Here, an explanation will be given using an extraction list in which players with player ranks of 11 to 20 are listed.

  In the extraction list, the player with a higher priority point is listed in a storage area with an address with a higher priority. For example, suppose that the priority point of “165” has the highest value among the players having the player ranks of 11 to 20. It is also assumed that five players have the highest priority points. In this case, the player information of the player whose priority point is “165” is set in the storage areas of addresses 1 to 5. When there are a plurality of players having the same priority point, an address (priority) is determined according to a predetermined condition. As described above, in the list update processing, based on the player information in the player information storage unit 160, the processing of listing in the extraction list in order from the player having the highest priority point is performed.

  FIG. 11 is a second diagram illustrating the list update process. For example, it is assumed that request information for requesting creation of a room and transmission of invitation information is transmitted from any of the player terminals 1. The request information is identifiably provided for each of the follower tab 48a, the mutual follower tab 48b, and the random tab 48c. Upon receiving the request information, the server 100 performs a room setting process for creating and setting a room. At this time, if the received request information is the request information for the random tab 48c, the target person is set in the list update processing as follows.

  That is, as shown in FIG. 11, the invitation information is set up to a predetermined number (here, 100) of storage areas in order from the storage area to which the address with the highest priority is assigned. However, the storage area in which the invitation information is set is determined based on the status flag.

  Specifically, the status flag identifies the reception status of the invitation information. In this example, the status flag is identified as four reception statuses of “settable”, “receivable”, “not receivable”, and “received”. Is done. "Setting possible" in the reception status indicates that setting of the invitation information is possible. In the storage area, when the area in which the status flag is stored is blank (when the status flag is off), the reception status is “settable”. Further, the reception status “receivable” indicates that the reception of the set invitation information is permitted when the reception is confirmed from the player terminal 1 set as the target person (hereinafter, referred to as “target person terminal”). It indicates that you want to. The “reception impossible” of the reception status indicates that the reception of the set invitation information is restricted when the reception is confirmed from the target person terminal. “Received” in the reception status indicates that the target terminal has received the invitation information.

  The server 100 sequentially searches the storage areas to which the reception status is “settable”, that is, the storage areas whose status flags are blank, from the storage areas to which the addresses with the higher priority are assigned, and sets the invitation information. For example, in the state shown in FIG. 10, the status flags are blank in all storage areas at addresses 1 to 100. In this state, when the request information for the random tab 48c is received from the player terminals 1 of the players with the player ranks of 11 to 20, the invitation information is set in the storage area of the addresses 1 to 100 as shown in FIG. .

  A status flag is set in the storage area where the invitation information is set. At this time, a status flag indicating “receivable” is set in the storage area having the highest priority point among the storage areas in which the invitation information is set. Further, a status flag indicating “impossible to receive” is set in the other storage areas in which the invitation information is set. Further, a wait time is set in each of the storage areas in which the “reception impossible” status flag is set.

  This wait time is the time until the reception status is switched from “non-reception” to “reception possible”. In other words, when the status flag of “reception impossible” is set, the status flag is switched to “reception possible” after the wait time has elapsed. Each storage area is grouped for each priority point, and the same wait time is set for the storage areas classified into the same group. In addition, the wait time is set shorter in a group with a relatively high priority point than in a group with a relatively low priority point.

  In the example shown in FIG. 11, the wait time is set to 5 seconds for the group whose priority point is “164”, and the wait time is set to 10 seconds for the group whose priority point is “163”. Thus, the wait time becomes shorter as the priority point is higher, and becomes longer as the priority point is lower.

  FIG. 12 is a third diagram illustrating the list update process. It is assumed that, for example, 5 seconds have elapsed after the invitation information, the status flag, and the wait time are set as shown in FIG. As described above, in the storage areas at addresses 6 to 99, the wait time is set to 5 seconds. When the wait time of 5 seconds elapses, the status flags of the storage areas at addresses 6 to 99 are switched to "receivable" as shown in FIG. Since the wait time is initially set to 10 seconds in the storage area at the address 100, the reception status remains "reception disabled" and the wait time is updated to 5 seconds.

  As described above, when the reception status is “reception impossible”, although the invitation information is set, the player terminal 1 cannot receive the invitation information. That is, even if reception confirmation is performed from the player terminal 1 in a state where the invitation information is set, the player terminal 1 does not receive the invitation information. As described above, when the target person is set by setting the invitation information, the server 100 allows the player with a higher priority point to receive the invitation information earlier. This makes it easier for a player with a higher priority to participate in multiplay.

  Further, it is assumed that request information for the random tab 48c is newly transmitted from another player terminal 1 in the above state. In this case, as shown in FIG. 12, the invitation information is set in the storage areas of the addresses 101 to 200. Note that the priority points of the storage areas at addresses 101 to 200 are all 163. Therefore, in this case, the “receivable” status flag is set in all of the storage areas at addresses 101 to 200.

  FIG. 13 is a fourth diagram illustrating the list update process. For example, in the state shown in FIG. 12, it is assumed that the reception of the invitation information has been confirmed from the target terminal set as the target in the storage areas of the address 1 and the address 3. In this case, the target terminal of both players receives the invitation information set in the storage area. When the invitation information is received, the server 100 switches the status flag from “receivable” to “received” as shown in the upper diagram of FIG.

  Further, as described above, when the target person receives the invitation information, the priority point of the target person is reduced by “4”. The server 100 updates the priority point to “161” in the storage areas of the address 1 and the address 3. After that, the server 100 performs a sorting process based on the priority points. As a result of this sort processing, the information stored in the storage areas of address 1 and address 3 is moved to an address (storage area) having a lower priority, as shown in the lower diagram of FIG.

  As will be described in detail later, when the request information for the follower tab 48a is transmitted, the invitation information is set in the storage area of the player set in the follower. When the request information for the mutual follower tab 48b is transmitted, the invitation information is set in the storage area of the player set in the mutual follower.

  According to the above list updating process, a player who has a high desire to participate in multiplay easily receives the invitation information. When the player who has a high desire to participate receives the invitation information, the time until the multiplayer starts is reduced.

  Further, in the present embodiment, the invitation information is received in accordance with the playing situation of the game on the player terminal 1. More specifically, the reception of the invitation information is notified when the player is playing a battle game (single play) or under a situation in which it is considered that the player is watching the screen to play the game. That is, the player terminal 1 is notified of the reception of the invitation information in a situation in which it is considered that there is a high willingness to participate in multiplay and a high response to the invitation is considered. As a result, the time required for the players participating in the multiplay to gather can be reduced, and the time required for starting the multiplay can be reduced.

(Play state of player terminal 1)
FIG. 14A is a diagram illustrating a play state of the player terminal 1. FIG. 14B is a diagram illustrating the timing of confirming the reception of the invitation information. The player terminal 1 updates the play state based on the play state of the game and the reception state of the invitation information. As shown in FIG. 14A, five play states managed by the player terminal 1 are a receivable state, an unopened state, an opened state, a participation state, and a non-receivable state. That is, in the player terminal 1, the play state is set to one of the five play states. The player terminal 1 executes a process related to receiving the invitation information based on the set play state.

  Each play state is associated with whether the invitation information can be received. When the play state is set to the receivable state or the unopened state, the player terminal 1 may receive the invitation information from the server 100. That is, of the play states, the receivable state and the unopened state can be said to be the permission states in which the reception of the invitation information is permitted. On the other hand, the player terminal 1 does not receive the invitation information from the server 100 when the play state is set to the opened state, the participation state, or the unacceptable state. That is, among the play states, the opened state, the participation state, and the unacceptable state can be said to be unacceptable states in which invitation information cannot be received.

  For example, in the server 100, it is assumed that a player is set as a target person and invitation information for the player is set in the server 100. At this time, if the play state is set to the receivable state or the unopened state in the player terminal 1, the player terminal 1 receives the invitation information from the server 100. On the other hand, even if the invitation information is set in the server 100, the player terminal 1 does not receive the invitation information from the server 100 if the play state is set to the opened state, the participation state, or the unacceptable state. In other words, when the play state is set to the opened state, the participation state, or the unacceptable state, the player terminal 1 does not execute the reception confirmation of the invitation information.

  Although detailed description is omitted, even if the play state is the permission state, the player terminal 1 may not receive the invitation information depending on the set invitation information. For example, when the guest player participates in the battle game multiplay, the invitation information to the battle game of the same type as the battle game is not received for 60 minutes after the end of the participating multiplay. In this way, when the play state is the permitted state, the invitation information can be received in principle, but the reception of some invitation information may be restricted depending on the content of the invitation information.

  As shown in FIG. 14A, a setting condition is provided for each of the above play states. The player terminal 1 determines whether or not the setting condition is satisfied, and sets the play state based on the determination result. In the receivable state, setting conditions include that the invitation information has not been received, that the user has not entered a multi-play room, and that a setting condition of a non-receivable state described later is not satisfied. In the unopened state, the setting conditions that the invitation information is received and that the invitation information dialog 52 is unopened are set.

  In the opened state, the setting conditions are that the invitation information dialog 52 is being displayed and that a hold operation has been input (the hold tab 52c of the invitation information dialog 52 has been tapped). In the participation state, it is set as a setting condition that the user is in a multi-play room. In the non-receivable state, setting conditions are that five minutes have not elapsed since the normal end of the multiplay and a predetermined time has not elapsed since the rejection operation. If a rejection operation is input twice within 30 minutes, the rejection operation is maintained for 60 minutes from the second rejection operation, and in other cases, the rejection operation is maintained for 5 minutes after the rejection operation. You.

  When the play state is set to the permission state, the player terminal 1 confirms the reception of the invitation information to the server 100. At this time, if the invitation information for itself is set, the player terminal 1 receives the set invitation information. That is, the reception of the invitation information is performed when the reception of the invitation information is confirmed. Therefore, strictly speaking, it can be said that whether or not the reception of the invitation information can be confirmed is set in advance for each play state.

  As described above, in the server 100, a player who has a high desire to participate in multiplay is set as a target person. However, even a player who has a high desire to participate may not be able to immediately participate in the multi-play depending on the playing situation of the game on the player terminal 1. For example, during a short movement or immediately after the end of the multiplay, the willingness to participate in the multiplay decreases. As described above, if the user participates in the multiplay in a state where the willingness to participate in the multiplay is low, cooperative play may not be performed.

  In the present embodiment, the invitation information is received in accordance with the play situation of the game on the player terminal 1. That is, even if the invitation information is set in the server 100, the invitation information is not received depending on the game play status of the player terminal 1. That is, when there is a high possibility that the player terminal 1 will not participate in multiplay, the player terminal 1 is prevented from receiving the invitation information in the first place. As a result, the possibility that a player who is less willing to participate in multiplayer is reduced. Also, since the invitation information is not received many times without being able to participate in the multiplayer, it is possible to prevent the player from feeling annoyed.

  Here, the reception confirmation of the invitation information in the player terminal 1 is performed as shown in FIG. 14B. That is, when the battle screen is displayed on the display 26 of the player terminal 1, reception of the invitation information is confirmed at intervals of 15 seconds. However, when the display 26 transitions from the normal screen (a screen other than the battle screen) to the battle screen, after the screen transition, the timing for first confirming the reception of the invitation information is randomly selected from 1 to 15 seconds by lottery. It is determined.

  When a normal screen (a screen other than the battle screen) is displayed on the display 26 of the player terminal 1, reception of the invitation information is confirmed at intervals of 10 seconds. However, when the display 26 transitions from the battle screen to the regular screen, the regular screen transitions to another regular screen, or the page transitions within the regular screen, the reception of the invitation information is performed first after the screen transition. The timing at which the confirmation is performed is randomly determined by lottery between 1 and 10 seconds.

  As described above, by first randomly determining the timing of confirming the reception of the invitation information after the screen transition, it is possible to prevent the player's operation of transitioning the screen only to receive the invitation information. Thereby, unnecessary communication with the server 100 is suppressed, and the load on the server 100 is reduced.

  During the display of the battle screen, the reception confirmation interval of the invitation information is set to be longer than during the display of the normal screen. Accordingly, execution of an unnecessary battle game for the purpose of receiving the invitation information is suppressed, and an increase in the load on the server 100 can be suppressed.

  Next, communication processing between the player terminal 1 and the server 100 for executing the above-described multiplay will be described. Here, an example of a basic communication process for advancing a game and an example of a main communication process related to multiplay will be described, and a description of other processes will be omitted.

(Communication processing between player terminal 1 and server 100)
FIG. 15 is a sequence diagram illustrating basic processing of the player terminal 1 and the server 100. In the following description, when the host terminal, the guest terminal, and the target person terminal are not distinguished, the processing in the player terminal 1 is denoted by Pn (n is an arbitrary integer). The processing in the server 100 is indicated as Sn (n is an arbitrary integer). When the player starts the game application in the player terminal 1 (P1), the login information is transmitted from the player terminal 1 to the server 100. Upon receiving the login information, the server 100 identifies the player terminal 1 and performs a login process (S1). Here, the server 100 enables the player terminal 1 to download the player information corresponding to the specified player terminal 1 from the storage unit 118.

  Further, when the play state is the permission state, the player terminal 1 confirms reception of the invitation information at predetermined time intervals (P2). Here, the player terminal 1 transmits the reception confirmation information to the server 100. Upon receiving the reception confirmation information, the server 100 searches the extraction list for the presence or absence of the invitation information of the player terminal 1 (S2). At this time, if the invitation information is set and the reception status is set to “receivable”, the player terminal 1 receives the invitation information. Upon receiving the invitation information, the player terminal 1 displays the notification image 34 in a notification mode, and notifies that the invitation information has been received (P3).

  In the player terminal 1, it is assumed that the single play tab 40a is tapped from the play content selection page (see FIG. 4A), and a single play start operation is performed (P4). In this case, the start information is transmitted from the player terminal 1 to the server 100. The start information includes party information selected by the player, type information of the battle game, and the like. In the server 100, by inputting the start information, a battle game start process required to start the battle game is performed (S3). Here, for example, an area of the memory 112 for advancing the battle game is secured, information input from the player terminal 1 is stored, or a predetermined program is read from the storage unit 118 to the memory 112. In addition, the server 100 sets the player terminal 1 so that the player terminal 1 can receive data necessary for executing the battle game.

  Then, also in the player terminal 1, a battle game start process required to start the battle game is performed (P5). Here, for example, an area of the memory 12 for advancing the battle game is secured, and game play information is stored, and a program and image data downloaded from the server 100 are stored in the memory 12. Note that programs and the like necessary for the battle game may be read from the storage unit 18 to the memory 12.

  When the preparation for the battle game is completed as described above, a battle game control process for controlling the battle game in the single play is performed simultaneously and simultaneously in both the player terminal 1 and the server 100 (P6, S4). In the battle game control process, an update process for updating various information is repeatedly executed in frame units. The number of frames is not particularly limited. For example, the number of frames per second is 30 to 60. Therefore, during the battle game, the information is updated in the player terminal 1 and the server 100 about every 16 ms (milliseconds) to 33 ms.

  In the update process, transmission and reception of update information are performed between the player terminal 1 and the server 100. Here, the update processing and the transmission and reception of the update information are performed in frame units, but the update processing and the transmission and reception of the update information may be performed in a shorter or longer cycle than the frame unit. Also during the single-play battle game, the reception confirmation of the invitation information in the player terminal 1 (P7), the search of the invitation information in the server 100 (S5), and the notification of the reception of the invitation information in the player terminal 1 (P8) are periodically performed. Can be performed. Then, when the end condition of the battle game is satisfied, an end process for ending the battle game is performed in each of the player terminal 1 and the server 100 (P9, S6). In the termination processing (P9) of the player terminal 1, for example, a result screen is displayed on the display 26. In the termination processing (S6) of the server 100, for example, various types of player information such as items acquired in the battle game, player experience values, and character experience values are updated.

  FIG. 16 is a sequence diagram illustrating a process performed by the player terminal 1 and the server 100 when multiplay is performed. In the following description, the processing in the host terminal is indicated as HPn (n is an arbitrary integer), and the processing in the target person terminal and the guest terminal is indicated as GPn (n is an arbitrary integer).

  In the player terminal 1 (host terminal), it is assumed that the room creation tab 46 is tapped and a request operation is input (HP10). When the request operation is input, the player terminal 1 (host terminal) transmits, to the server 100, request information for requesting creation of a room and transmission of invitation information. The request information includes information about the party selected by the player, information indicating the type of the battle game, information indicating the tapped operation unit, and the like.

  When the server 100 receives the request information, the player information storage unit 160 performs a point update process of updating a priority point (indicated as UPDATE in the figure). Here, the priority point of the host player that transmitted the request information is subtracted by “4”. As will be described in detail later, when the point update processing is performed in the player information storage unit 160, the priority points of the extraction list are updated in the same manner as in the player information storage unit 160. In the extraction list, a sorting process is performed based on the updated priority points.

  Further, upon receiving the request information, the server 100 performs a room setting process for creating and setting a room (S10). Here, a processing area for executing multiplay, that is, a room, is secured, and various information included in the request information is stored in this room. The room number of the created room is set. The host terminal receives the room setting information set in the room setting process, and displays a room detail page on the display 26 (HP11).

  Further, the server 100 sets the target person (S11). Here, the invitation information, the status flag, and the counter value of the weight counter are set in the extraction list, and the target person is set. Thereafter, when the target terminal confirms the reception of the invitation information (GP10), the reception confirmation information is transmitted to the server 100. When receiving the reception confirmation information, the server 100 searches whether the invitation information is set for the target person (S12). Here, since the invitation information is set, the server 100 updates the reception status (status flag) of the target person to “received”. Further, the server 100 performs a point update process and subtracts “4” from the priority point of the target person who has received the invitation information.

  Upon receiving the invitation information, the target person terminal displays the notification image 34 in a notification mode, and notifies that the invitation information has been received (GP11). In addition, the target person terminal updates the play state from the receivable state to the unopened state (GP12). Thereafter, when the subject taps the notification image 34 and the invitation information dialog 52 is opened (GP13), the opening information is transmitted to the server 100. Upon receiving the opening information, the server 100 performs a point update process. Here, the priority point of the target person is added by “1”. In the target person terminal, the play state is updated to the opened state (GP14).

  Thereafter, when the participation tab 52a of the invitation information dialog 52 is tapped at the target person terminal, the participation information is transmitted from the target person terminal to the server 100 (GP15). The participation information includes information related to the party set by the target person. Upon receiving the participation information, the server 100 determines whether it is possible to enter the room, and updates the room information if entry into the room is possible (S13). Here, the server 100 is set so that the updated room information (room update information) is received by the host terminal and the target person terminal.

  Although FIG. 16 shows only one target person terminal (guest terminal), the same processing is performed on one room by a plurality of target person terminals (guest terminals). Therefore, when any of the target person terminals enters the room, the player terminals 1 of all the players entering the room receive the room update information.

  Upon receiving the room update information from the server 100, the host terminal updates and displays the room detail page (HP12). The target person terminal also receives the room update information. Here, the player terminal 1 (target person terminal) after receiving the room update information is referred to as a guest terminal. Upon receiving the room update information, the guest terminal updates the play state to the participation state (GP16) and displays a room detail page on the display 26 (GP17).

  Thereafter, in the host terminal, when the start tab 50 of the room detail page is tapped and a multiplayer start operation is input (HP13), start information is transmitted to the server 100. In the server 100, the point update processing is performed by inputting the start information. Here, “1” is added to the priority point of the host player.

  Then, in the host terminal, the server 100, and the guest terminal, the above-described battle game start processing (not shown) is performed, and thereafter, multiplayer control processing for controlling multiplayer is performed concurrently (HP14, S14, GP18). In the multi-play control process, an update process for updating various information is repeatedly executed in frame units. In this update processing, transmission and reception of update information are performed between the host terminal, the guest terminal, and the server 100. Then, when the condition for ending the battle game is satisfied, the host terminal, the guest terminal, and the server 100 perform an end process for ending the battle game (HP15, S15, GP19).

  At the end of the multiplay, the server 100 calculates, for each player who has participated in the multiplay, the damage given during all the damages (S16). Then, a point update process is performed based on the calculated damage. Here, “3” is added to the priority point for the player whose damage is 20% or more of the total damage. On the other hand, in the guest terminal, at the end of the multi-play, the play state is updated to a non-receivable state (GP20). Thereafter, in the guest terminal, after a predetermined time has elapsed, the play state is updated to a receivable state (GP21).

  FIG. 17 is a sequence diagram illustrating processing of the player terminal 1 and the server 100 when it is not possible to participate in multiplay. Note that, in FIG. 17, the processing up to input of the participation information from the target person terminal is the same as that in FIG. As described above, upon receiving the participation information, the server 100 determines whether it is possible to enter the room. At this time, if entry into the room is not possible, server 100 sets participation impossible information indicating that entry into the room is impossible. At this time, the server 100 performs a point update process and adds “4” to the priority point of the target person.

  Upon receiving the participation impossible information, the target person terminal displays a predetermined entry impossible screen on the display 26 (GP22). Further, the player terminal 1 of the target person updates the play state to a receivable state (GP23).

  FIG. 18 is a sequence diagram illustrating processing of the player terminal 1 and the server 100 when participation in multiplay is rejected. Note that, in FIG. 18, the processing until the rejection information is input from the target person terminal is the same as that in FIG. When the rejection tab 52b of the invitation information dialog 52 is tapped at the target person terminal, rejection information is transmitted from the target person terminal to the server 100 (GP24). In the target person terminal, the play state is updated to a non-receivable state (GP25).

  In the present embodiment, it is assumed that the server 100 does not perform any special processing even if the rejection information is received. However, when the rejection information is received, the server 100 may subtract the priority point of the target person or update the extraction list such as the reception status (status flag).

  Next, a functional configuration of the player terminal 1 and a specific process in the player terminal 1 will be described. In the following, the configuration and processing related to the invitation information will be described, and the description of the configuration and processing not related to the invitation information will be omitted.

(Functional configuration of player terminal 1)
FIG. 19 is a diagram illustrating a configuration of the memory 12 in the player terminal 1 and a function as a computer. The memory 12 includes a program storage area 12a and a data storage area 12b. The CPU 10 stores a terminal-side game control program (module) in the program storage area 12a at the start of multiplay or before the start of multiplay.

  The terminal-side game control programs include a game execution program 60, a battle game execution program 62, a request information transmission program 64, a play state update program 66, an invitation information reception program 68, an invitation information notification program 70, an operation permission program 72, A program 74 is included. Note that the programs listed in FIG. 19 are merely examples, and the terminal-side game control program includes many other programs.

  In the data storage area 12b, a game information storage section 80, a play state storage section 82, and an invitation information storage section 84 are provided as storage sections for storing data. Each of the above storage units is an example, and a number of other storage units are provided in the data storage area 12b.

  The CPU 10 operates each program stored in the program storage area 12a to update data in each storage unit in the data storage area 12b. Then, the CPU 10 causes the player terminal 1 (computer) to function as the terminal-side game control unit 1A by operating each program stored in the program storage area 12a. The terminal-side game control unit 1A includes a game execution unit 60a, a battle game execution unit 62a, a request information transmission unit 64a, a play state update unit 66a, an invitation information reception unit 68a, an invitation information notification unit 70a, an operation permission unit 72a, and a clock unit. 74a.

  Specifically, the CPU 10 operates the game execution program 60 to cause the computer to function as the game execution unit 60a. Similarly, the CPU 10 operates the battle game execution program 62, the request information transmission program 64, the play state update program 66, the invitation information reception program 68, the invitation information notification program 70, and the operation permission program 72, and the battle game execution section 62a The request information transmitting section 64a, the play state updating section 66a, the invitation information receiving section 68a, the invitation information notifying section 70a, the operation permitting section 72a, and the timer section 74a.

  The game execution unit 60a controls the progress of a game other than the battle game, such as, for example, organizing a party, strengthening an ally character, or the like, based on the operation of the player. The game execution unit 60a transmits information corresponding to the operation to the server 100 each time the operation is input to the player terminal 1. Further, when the information (game information) relating to the game is updated, the game execution unit 60a updates the information in the game information storage unit 80.

  The battle game execution unit 62a performs all controls for executing the battle game. For example, the battle game execution unit 62a transmits information to the server 100 based on an operation input to the player terminal 1, and receives various information from the server 100. Further, the battle game execution unit 62a updates the battle screen based on the operation input to the player terminal 1 and the information received from the server 100. That is, when a predetermined start condition is satisfied, the battle game execution unit 62a executes a single play or a multiplay with another player terminal 1. Further, the battle game execution section 62a updates the information in the game information storage section 80 when the battle game ends normally.

  When any one of the operation units of the follower tab 48a, the mutual follower tab 48b, and the random tab 48c is tapped, the request information transmitting unit 64a transmits a request signal corresponding to the operation unit to the server 100.

  The play state updating unit 66a updates the play state of the play state storage unit 82 based on the reception state of the invitation information and the play state of the game.

  When the play state is the permission state, the invitation information receiving unit 68a confirms reception of the invitation information at a timing set for each screen displayed on the display 26. Specifically, the invitation information receiving unit 68a transmits reception confirmation information to the server 100, receives the invitation information set in the server 100, and stores it in the invitation information storage unit 84.

  The invitation information notifying unit 70a switches the notification image 34 to the notification mode or the non-notification mode based on whether the invitation information is stored in the invitation information storage unit 84, that is, whether the invitation information is received.

  The operation permission unit 72a displays the invitation information dialog 52 when the notification image 34 is tapped, and allows the player to input a participation operation, a rejection operation, and a hold operation. Specifically, when the notification image 34 displayed in the notification mode is tapped, the server 100 checks whether a room corresponding to the received invitation information exists. When a room exists, the operation permission unit 72a displays the invitation information dialog 52 (FIGS. 6C, 7A, and 7C) on the display 26. In other words, by displaying the participation tab 52a, the rejection tab 52b, and the hold tab 52c in a tappable manner, a participation operation that desires to participate in multiplay, a rejection operation for rejecting participation in multiplay, and a hold on participation in multiplay It is possible to input a hold operation for setting a state.

  The timer 74a measures a prohibition time, a reception standby time, and a rejection time, which will be described later.

(Specific processing of player terminal 1)
FIG. 20 is a flowchart illustrating an example of the terminal-side game process in the player terminal 1. In the terminal-side game process, the game execution unit 60a performs a game progress process and controls the progress of games other than the battle game (P100). Further, the battle game execution unit 62a performs control for executing a single game or multiplayer battle game (P101). In the terminal-side game process, the terminal-side game control unit 1A executes a room creation-related process (P110), an invitation information receiving process (P120), a process after receiving the invitation information (P130), and a multiplay end process (P140). .

  FIG. 21 is a flowchart illustrating an example of a room creation-related process in the player terminal 1. When the quest screen is displayed on the display 26 (YES in P110-1), when the room creation tab 46 is tapped and a request operation is input (YES in P110-2), the request information transmitting unit 64a sends a request. The information is transmitted to the server 100 (P110-3). At this time, the terminal-side game control unit 1A displays a predetermined standby screen on the display 26 (P110-4).

  Further, upon receiving the room setting information (YES in P110-5), the terminal-side game control unit 1A displays a room detail page on the display 26 (P110-6). Further, upon receiving the room update information (YES in P110-7), the terminal-side game control unit 1A updates the display of the room detail page based on the received room update information (P110-8).

  When the start tab 50 is tapped and a start operation is input (YES in P110-9), the terminal-side game control unit 1A transmits start information to the server 100 (P110-10), and multiplayer is started. Wait (P110-11). When multiplayer can be started, in the above-described battle game execution processing (P101), control of the battle game by multiplayer is performed.

  FIG. 22 is a flowchart illustrating an example of the invitation information receiving process in the player terminal 1. When the screen of the display 26 transitions (YES in P120-1), the timer unit 74a checks the screen displayed on the display 26 (P120-7), and determines an initial counter value by lottery (P120-8). It should be noted that the initial counter value indicates the interval of reception confirmation of the invitation information. Here, if the normal screen is displayed, a value corresponding to any of 1 to 10 seconds is determined as the initial counter value, and if the battle screen is displayed, it corresponds to any of 1 to 15 seconds. The value is determined as the initial counter value. The timer unit 74a stores the determined initial counter value in a predetermined storage unit (initial value storage unit) of the data storage area 12b, and sets it in the reception standby counter (P120-9).

  In addition, when the screen of the display 26 has not transitioned (NO in P120-1), and the play state stored in the invitation information storage unit 84 is a non-receivable state (NO in P120-2, P120-3). YES), the timer 74a decrements the counter value of the prohibition time counter (P120-4). As will be described in detail later, when a rejection operation is performed, a predetermined counter value is set in the prohibition time counter. That is, the prohibition time counter counts the time elapsed since the rejection operation was input. When the count value of the prohibition time counter is updated to 0 (YES in P120-5), the play state update unit 66a updates the play state in the play state storage unit 82 to a receivable state (P120-6).

  As a result, the play state is maintained in an unacceptable state until a predetermined time elapses after the rejection operation is performed. Then, when a predetermined time elapses after the rejection operation is performed, the play state is switched to a receivable state. When the play state is switched to the receivable state, the initial counter value is determined based on the screen displayed on the display 26 and set in the reception standby counter as described above (from P120-7). P120-9).

  Further, when the screen of the display 26 has not transitioned (NO in P120-1), and the play state stored in the invitation information storage unit 84 is the receivable state or the unopened state (YES in P120-2). ), The timer 74a decrements the counter value of the reception standby counter (P120-10). Then, when the counter value of the reception standby counter becomes 0 (YES in P120-11), the timer 74a sets the initial counter value stored in the initial value storage unit to the reception standby counter again. In addition, the invitation information receiving unit 68a performs an invitation information confirmation process (P121).

  FIG. 23 is a flowchart illustrating an example of the invitation information confirmation process in the player terminal 1. The invitation information receiving unit 68a transmits the reception confirmation information to the server 100 (P121-1). When the receivable (unreceived) invitation information is set in the server 100 (YES in P121-2), the invitation information receiving unit 68a receives the invitation information set in the server 100 and sends the invitation information to the invitation information storage unit 68a. 84 (P121-3). In addition, the invitation information receiving unit 68a updates the play state of the play state storage unit 82 to the unopened state (P121-4). In addition, the invitation information notification unit 70a displays the notification image 34 in a notification manner in the header display area 30 (P121-5).

  FIG. 24 is a first flowchart illustrating an example of a process after receiving the invitation information in the player terminal 1. FIG. 25 is a second flowchart illustrating an example of a process after receiving the invitation information in the player terminal 1. When the notification image 34 is tapped (YES in P130-2) in a state where the invitation information is stored in the invitation information storage unit 84 (YES in P130-1), the invitation information receiving unit 68a displays the invitation information on the display 26. The dialog 52 is displayed (P130-3). At this time, if the play state is the unopened state (YES in P130-4), the invitation information receiving unit 68a transmits the opened information to the server 100 (P130-5). The play state updating unit 66a updates the play state to the opened state (P130-6).

  Further, when the invitation information is stored in the invitation information storage unit 84 and the participation tab 52a is tapped and a participation operation is input while the invitation information dialog 52 is displayed (YES in P130-1, P130 -2, NO in P130-7, YES in P130-8), the invitation information receiving unit 68a transmits the participation information to the server 100 (P130-9). Thereafter, the invitation information receiving unit 68a waits until room update information or participation impossible information is received (P130-10). Then, when room update information is received from the server 100 (YES in P130-11), the play state updating unit 66a updates the play state to the participation state (P130-12), and the invitation information receiving unit 68a displays the display 26. To display the room details page (P130-13). Here, the invitation information receiving unit 68a switches the notification image 34 to a non-display mode.

  On the other hand, when the participation impossible information is received from the server 100 (NO in P130-11), the invitation information receiving unit 68a displays an entry impossible screen on the display 26 (P130-14), and the invitation information storage unit The invitation information is deleted from 84 (P130-15). In addition, the invitation information notifying unit 70a switches the notification image 34 from the notification mode to the non-report mode (P130-16). Further, the play state updating unit 66a updates the play state of the play state storage unit 82 to a receivable state (P130-17).

  Also, when the invitation information is stored in the invitation information storage unit 84 and the rejection tab 52b is tapped and a rejection operation is input while the invitation information dialog 52 is displayed (YES in P130-1, P130 (NO at -2, YES at P130-7, NO at P130-8, YES at P130-18 in FIG. 25), the invitation information receiving unit 68a ends the display of the invitation information dialog 52 (P130-19). In addition, the invitation information notifying unit 70a ends the display of the notification image 34 in the notification mode, and displays the notification image 34 in the non-report mode or the operation tab 42 (P130-20).

  Further, the invitation information receiving unit 68a deletes the invitation information from the invitation information storage unit 84 (P130-21), and the play state update unit 66a updates the play state to a non-receivable state (P130-22). Further, the invitation information receiving unit 68a transmits the rejection information to the server 100 (P130-23). Further, the timer 74a determines whether the counter value of the refusal time counter is 0 (P130-24). The rejection time counter counts the time elapsed since the rejection operation was input. Although a detailed description is omitted, the counter value set in the refusal time counter is decremented each time the terminal-side game process is executed. Here, the counter value of the refusal time counter becomes 0 when 30 minutes have elapsed since the rejection operation was input.

  If the counter value of the refusal time counter is 0 (YES in P130-24), that is, if 30 minutes have elapsed since the last rejection operation was input, the timer 74a sets the prohibited time counter to 5 A counter value corresponding to the minute is set (P130-25). If the counter value of the refusal time counter is not 0 (NO in P130-24), that is, if 30 minutes have not elapsed since the last rejection operation was input, the timer 74a sets the prohibited time counter to , A counter value corresponding to 60 minutes is set (P130-26). After setting the counter value of 5 minutes or 60 minutes in the prohibition time counter, the timer unit 74a sets the counter value corresponding to 30 minutes in the rejection time counter (P130-27).

  According to the above-described processing, the operation permission unit 72a displays the invitation information dialog 52 at the time of or after the notification of the reception of the invitation information (P130-3), thereby performing the rejection operation for rejecting the participation in the multiplay. Can be input. Then, after input of the rejection operation, the play state is maintained in the unreceivable state for 5 minutes (second time) or 60 minutes (second time), and when 5 minutes or 60 minutes elapse, the play state is changed. It is updated to a receivable state (P120-6). If the rejection operation is performed twice within 30 minutes, the invitation information is not received for 60 minutes after the second rejection operation.

  Also, when the invitation information is stored in the invitation information storage unit 84 and the hold tab 52c is tapped and a hold operation is input in a state where the invitation information dialog 52 is displayed (YES in P130-1, P130 (NO at -2, YES at P130-7, NO at P130-8, NO at P130-18, YES at P130-28), the invitation information receiving unit 68a ends the display of the invitation information dialog 52 (P130-29). ).

  FIG. 26 is a flowchart illustrating an example of the multiplay ending process in the player terminal 1. When the multi-play ends (YES in P140-1), the invitation information receiving unit 68a displays a result screen on the display 26 (P140-2). At this time, when participating in multiplay as a guest player (P140-3: YES), the invitation information receiving unit 68a deletes the invitation information from the invitation information storage unit 84 (P140-4). Further, the play state updating unit 66a updates the play state to a non-receivable state (P140-5), and the invitation information receiving unit 68a sets a counter value corresponding to 5 minutes to the inhibition time counter (P140-6). . According to the multiplay ending process, the play state is maintained in a non-receivable state for 5 minutes (first time) after the end of the multiplay that has participated as a guest player.

  Next, a functional configuration of the server 100 and a specific process in the server 100 will be described. In the following, the configuration and processing related to the setting of the target person who can receive the invitation information will be described, and the description of the other configurations and processing will be omitted.

(Functional configuration of server 100)
FIG. 27 is a diagram illustrating a configuration of the memory 112 in the server 100 and a function as a computer. The memory 112 is provided with a program storage area 112a and a data storage area 112b. The CPU 110 stores a server-side game control program (module) in the program storage area 112a at the start of the multiplay or before the start of the multiplay.

  The server-side game control programs include a player information update program 140, a list update program 142, a terminal setting program 144, and a game execution program 146. Note that the programs listed in FIG. 27 are examples, and many other programs are provided in the server-side game control program.

  In the data storage area 112b, a player information storage section 160, an extraction list storage section 162, a game information storage section 164, and a room information storage section 166 are provided as storage sections for storing data. Note that each of the above storage units is an example, and many other storage units are provided in the data storage area 112b.

  The CPU 110 operates each program stored in the program storage area 112a to update data in each storage unit in the data storage area 112b. Then, the CPU 110 causes the server 100 (computer) to function as the server-side game control unit 100A by operating each program stored in the program storage area 112a. The server-side game control unit 100A includes a player information update unit 140a, a list update unit 142a, a terminal setting unit 144a, and a game execution unit 146a.

  Specifically, the CPU 110 operates the player information updating program 140 to cause the computer to function as the player information updating unit 140a. Similarly, the CPU 110 operates the list update program 142, the terminal setting program 144, and the game execution program 146 to function as the list update unit 142a, the terminal setting unit 144a, and the game execution unit 146a, respectively.

  The player information updating unit 140a updates the player information for each player stored in the player information storage unit 160 every time communication is performed with the player terminal 1. Further, the player information updating section 140a performs a point updating process for updating the priority points in the player information storage section 160.

  The list update unit 142a updates the extraction list stored in the extraction list storage unit 162 based on the player information (priority points) stored in the player information storage unit 160. For example, the list update unit 142a executes a sort process for exchanging a storage area in which information of a player is stored. Further, the list updating unit 142a updates the invitation information, the status flag, and the weight counter of the extraction list.

  The terminal setting unit 144a sets the invitation information, the status flag, and the counter value of the weight counter in the extraction list based on the input of the request information. That is, the terminal setting unit 144a sets the target person in the extraction list.

  The game execution unit 146a controls the progress of all games including the battle game based on information input from the player terminal 1. Further, the game execution unit 146a stores various information updated during the game in the game information storage unit 164. Here, the game execution unit 146a stores the damage given to the enemy character in the multi-play in the game information storage unit 164 for each player. However, the information stored in the game information storage unit 164 is not limited to this, and can be appropriately set based on the content of the game.

(Specific processing of server 100)
FIG. 28 is a flowchart illustrating an example of the server-side game process in the server 100. In the server-side game process, the game execution unit 146a performs a battle game execution process for executing a battle game (S100). Further, the player information updating unit 140a updates the player information of the player information storage unit 160 based on the information input from the player terminal 1. In the server-side game process, the server-side game control unit 100A executes a request information receiving process (S110), an information updating process (S120), a multiplay end process (P130), and a rearrangement process (S140).

  FIG. 29 is a flowchart illustrating an example of the request information receiving process in server 100. When the follower is selected as the target person to be invited to the room, that is, when the request information for the follower tab 48a is received (YES in S110-1 and YES in S110-2), the terminal setting unit 144a determines in the extraction list that The invitation information, the status flag, and the counter value of the weight counter (hereinafter, referred to as “invitation information etc.”) are set in the storage area of the follower (S110-3).

  When the mutual follower is selected as the target person to be invited to the room, that is, when the request information for the mutual follower tab 48b is received (YES in S110-1, NO in S110-2, YES in S110-4), the terminal setting is performed. The unit 144a sets the invitation information and the like in the storage area of the mutual follower in the extraction list (S110-5).

  When the invitation information is set in the follower or the mutual follower, the setting of the counter value of the weight counter is not essential. That is, when the follower or the mutual follower is set as the target person, the situation may be such that all the target persons can receive the invitation information at the same time. Further, similarly to the case where the target person is set at random, the counter value of the weight counter may be set based on the priority point.

  When it is selected to randomly extract the persons to be invited to the room, that is, when the request information for the random tab 48c is received (YES in S110-1, NO in S110-2, NO in S110-4) Then, the terminal setting unit 144a sets the invitation information and the like in the storage area of the top 100 persons whose reception status is “settable”, that is, the status flag is blank in the extraction list (S110-6).

  When the target person is set at random, the player information updating unit 140a adds “1” to the priority point of the host player in the player information storage unit 160 (S110-8). When the request information is received (YES in S110-1), the server-side game control unit 100A performs a room setting process for setting a room (S110-8). Here, a room (predetermined storage area) is set in the room information storage unit 166, and information on the host player is stored in the room based on the request information. Here, the server-side game control unit 100A sets the room information so that the host terminal can receive it. Further, the player information updating unit 140a subtracts “4” from the priority point of the host player in the player information storage unit 160 regardless of the type of the request information (S110-9).

  FIG. 30 is a flowchart illustrating an example of the information update process in server 100. When receiving the reception confirmation information from the player terminal 1 (YES in S120-1), the server-side game control unit 100A searches the extraction list and searches whether the invitation information for the player terminal 1 is set (S120-). 2). At this time, if the invitation information is set (YES in S120-3) and the reception status (status flag) is set to “reception possible” (YES in S120-4), the server-side game control unit 100A Perform Invitation Information Output Processing (S120-5) Here, the invitation information is set to be receivable by the player terminal 1 that has transmitted the reception confirmation information.

  Further, the player information updating unit 140a subtracts “4” from the priority point of the target person stored in the player information storage unit 160 (S120-6). In addition, the list update unit 142a updates the reception status (status flag) of the target person terminal to “received” in the extraction list.

  When receiving the opening information from the player terminal 1 (target person terminal) (YES in S120-8), the player information updating unit 140a sets the priority point of the target person stored in the player information storage unit 160 to “1”. The addition is performed (S120-9).

  Further, when the participation information is received from the player terminal 1 (target person terminal) (YES in S120-10), if it is possible to enter the room (YES in S120-11), the server-side game control unit 100A transmits the room information The room information in the storage unit 166 is updated (S120-12). In addition, the server-side game control unit 100A performs a room update information output process. Here, the server-side game control unit 100A sets the room update information to be receivable by the host terminal and all guest terminals (including the target person terminal that transmitted the participation information) (S120-13).

  On the other hand, if it is not possible to enter the room (NO in S120-11), the player information updating unit 140a adds “4” to the priority point of the subject who transmitted the participation information in the player information storage unit 160 (S120-14). ). Also, the server-side game control unit 100A sets the target person to be able to receive the participation impossible information (S120-15).

  When the start information is received from the host terminal (YES in S120-16), the player information updating unit 140a adds “1” to the priority point of the host player in the player information storage unit 160 (S120-17). Then, the server-side game control unit 100A executes a battle game start process for starting a battle game by multi-play (S120-18).

  FIG. 31 is a flowchart illustrating an example of the multiplay end processing in server 100. In the battle game execution process (S100), if the multiplay ends normally except for the halfway end (retirement) (YES in S130-1, NO in S130-2), the server-side game control unit 100A determines that the damage given is 20 % Or more players are specified (S130-3). In the battle game execution process (S100), the damage given to each player is stored in the game information storage unit 164 during the execution of the multiplay.

  The player information updating unit 140a adds “3” to the priority point of the specified player in the player information storage unit 160 (S130-4). Also, at the end of the multiplay, the player information updating unit 140a resets (sets to 100) the priority points of all the players whose priority points exceed the initial value (S130-5).

  FIG. 32 is a flowchart illustrating an example of the sorting process in server 100. The list updating unit 142a updates the priority points of the extraction list stored in the extraction list storage unit 162 to the priority points stored in the player information storage unit 160 (S140-1). In addition, the list updating unit 142a performs a sorting process of changing the priority order based on the priority points of the extraction list (S140-2). Thereby, the priority of the player is updated based on the priority points.

  Further, the list update unit 142a performs a list information update process for updating the information of the extraction list (S140-3). For example, the list updating unit 142a updates the counter value of the weight counter, and updates the status flag of the storage area whose counter value has been updated to “0” from “non-receivable” to “receivable”. In addition, the list update unit 142a updates the status flag from “receivable” to “received” for the target person who has received the invitation information. Further, the list updating unit 142a updates the invitation information, the status flag, and the weight counter from the extraction list when the multiplay is completed, when the room is disbanded, or when a predetermined time has elapsed since the invitation information was set. .

  As described above, the player terminal 1 is provided with a program for executing multiplay as a host terminal and a program for executing multiplay as a guest terminal. Then, the player terminal 1 functions as a request information transmitting unit 64a that transmits request information to the server 100 by inputting a request operation from the room creation tab 46 (operation unit). In the present embodiment, the server 100 is provided as an external device, and the plurality of player terminals 1 can execute multi-play via the server 100 as the external device. However, the external device is not limited to the server 100. For example, the player terminal 1 may have the above-described functions of the server 100, and one of the player terminals 1 may function as an external device.

  Further, the player terminal 1 functions as a play state update unit 66a (state update unit) that updates the play state based on the play state of the game. In the present embodiment, five play states are provided, but the number of play states and the setting conditions of the play states are merely examples, and can be appropriately designed. For example, the play status (play status) includes a login status, and the play status may be made different depending on whether or not the user is logged in. In any case, the play state may be provided with a permission state in which invitation information can be received and a non-permission state in which invitation information cannot be received.

  In the present embodiment, the play state is set and updated based on the game play status and whether or not the invitation information has been received. However, the play state update unit 66a only needs to be updated based on at least the play situation of the game.

  Further, the player terminal 1 functions as an invitation information receiving unit 68a (receiving unit) that can receive invitation information from the server 100 (external device) when the play state is the permitted state. In the present embodiment, the invitation information is set in the server 100, and the player terminal 1 receives the invitation information by confirming the reception from the player terminal 1. However, the process in which the invitation information receiving unit 68a receives the invitation information is not limited to this.

  For example, when the target person is set in the server 100, the invitation information is transmitted from the server 100 to the target person terminal. At this time, if the play state of the target person terminal is the permitted state, the invitation information may be received. If the play state is not possible, the reception of the invitation information may be refused. In any case, the invitation information receiving unit 68a only needs to receive the invitation information from the server 100 (external device) when the play state is the permitted state, and the processing or method is not limited.

  Further, the player terminal 1 functions as an invitation information notifying unit 70a (notifying unit) that notifies reception of the invitation information. In the present embodiment, the invitation information notifying unit 70a notifies the reception of the invitation information by switching the display mode of the notification image 34. However, the method of notifying the reception of the invitation information is not limited to this. For example, the reception of the invitation information may be notified by forcibly displaying the invitation information dialog 52 when or after receiving the invitation information. In any case, the invitation information notifying unit 70a may notify the reception of the invitation information when or after receiving the invitation information, and the mode of the notification may be appropriately designed.

  In addition, the player terminal 1 functions as an operation permission unit 72a that enables input of a participation operation. In the present embodiment, the operation permitting unit 72a provides the invitation information dialog 52 with the participation tab 52a, the rejection tab 52b, and the hold tab 52c, thereby enabling the input of the participation operation, the rejection operation, and the hold operation. However, the operation permission unit 72a only needs to be able to input a participation operation, a rejection operation, and a hold operation, and the method or process can be appropriately designed. The operation permission unit 72a only needs to be able to input at least the participation operation, and it is not essential to accept the rejection operation and the hold operation. In any case, the operation permitting unit 72a may be capable of inputting a predetermined participation operation at the time of or after the notification of the reception of the invitation information.

  Further, the player terminal 1 functions as a game execution unit 60a that executes multi-play (communication game) with another player terminal 1. Note that the content of the game in the present embodiment is merely an example, and the content of the game is not particularly limited. The content of the game may be, for example, an action game, a role playing game, a racing game, or the like. In any case, the content of the communication game is not particularly limited as long as the communication game can be executed by the plurality of player terminals 1. Therefore, the content of the communication game may be such that a plurality of players cooperate, or a plurality of players may compete against each other. In any case, the game execution unit 60a widely includes a game execution unit that executes a communication game with another player terminal 1 when a participation operation is input and a predetermined start condition is satisfied.

  Further, in the present embodiment, the state in which the invitation information can be received and the state in which the reception of the invitation information can be notified match. Therefore, when receiving the invitation information, the player terminal 1 always immediately notifies that the invitation information has been received. However, the state in which the invitation information can be received and the state in which the reception of the invitation information can be notified may be different. For example, it is assumed that the reception of the invitation information is confirmed based on the above five play states. In addition, the player terminal 1 functions as a notification permission / prohibition state setting unit that sets a notification permission / prohibition state separately from the play state. As the notification availability state, for example, a notification enabled state and a notification disabled state are provided.

  The notification permission / prohibition state setting unit switches the notification permission / prohibition state based on, for example, a screen transition being displayed on the display 26. Specifically, the notification permission / prohibition state setting unit sets the notification permission / prohibition state to the notification permission state when the screen transits to a screen where the notification image 34 of the notification mode or the invitation information dialog 52 may be displayed. On the other hand, the notification permission / prohibition state setting unit sets the notification permission / prohibition state to the notification prohibition state when the screen transits to the notification image 34 of the notification mode or the screen on which the invitation information dialog 52 should not be displayed.

  Then, upon receiving the invitation information, the invitation information notifying unit 70a checks the notification permission / prohibition state, and if the notification is possible, displays the notification image 34 of the notification mode or the invitation information dialog 52 on the display 26. On the other hand, if the notification availability state is the notification disabled state when the invitation information is received, the notification image 34 in the non-notification mode is kept displayed. In this case, even if the invitation information is received, the player is not notified of the presence of the invitation information. Then, the invitation information notifying unit 70a checks the notification permission / prohibition state at a predetermined timing such as when the screen changes, and if the notification is possible, at that time, the notification image 34 of the notification mode or the invitation information A dialog 52 is displayed.

  As described above, the play state in which the reception of the invitation information is specified and the notification state in which the reception of the invitation information is specified may be provided. Further, the state in which the invitation information can be received may be different from the state in which the reception of the invitation information can be notified.

  Further, the play state may specify the reception notification of the invitation information. That is, the invitation information notifying unit 70a may notify the reception of the invitation information when or after the reception of the invitation information and the play state is the permission state. This modification will be described with reference to the drawings.

(Modification)
FIG. 33 is a flowchart illustrating an example of the invitation information receiving process of the modification in the player terminal 1. The invitation information receiving process of this modification is executed in place of the invitation information receiving process of the above embodiment. Although the detailed description is omitted, when the invitation information receiving process of the modified example is executed, some processes are added or changed in the invitation information receiving process and the multiplay ending process of the above embodiment.

  The invitation information notifying unit 70a determines whether the screen displayed on the display 26 is a screen that can notify the reception of the invitation information (P150-1). Whether or not the reception of the invitation information can be notified is preset for each screen. When the screen transitions to a screen where the reception of the invitation information cannot be notified (NO in P150-1), the play state update unit 66a sets the play state of the play state storage unit 82 to the impossible state (P150-2).

  On the other hand, when the screen displayed on the display 26 is a screen that can notify the reception of the invitation information (YES in P150-1), the play state update unit 66a sets the play state to the permission state (P150-3). . At this time, if invitation information that has not been notified (the reception has not been notified) is stored in the invitation information storage unit 84 (YES in P150-4), the invitation information notification unit 70a displays the notification image 34 in a notification mode. It is displayed (P150-5).

  Further, the invitation information receiving unit 68a transmits reception confirmation information to the server 100 (P150-6), and waits until information is received from the server 100 (P150-7). When the invitation information is received (YES in P150-8), the received invitation information is stored in the invitation information storage unit 84 (P150-9). At this time, if the play state is the permitted state (YES in P150-10), the invitation information notifying unit 70a displays the notification image 34 in a notification mode (P150-11).

  According to the above-described modification, the player terminal 1 receives the invitation information regardless of the play situation (play state) of the game. Then, when the invitation information is received or after the reception, and the play state is the permission state, the invitation information notifying unit 70a notifies the reception of the invitation information. According to this modification, the same operation and effect as those of the above-described embodiment are realized.

  In the above-described embodiment, the play state updating unit 66a sets the play state to an impossible state in which the reception of the invitation information is disabled for 5 minutes (first time) after the end of the multi-play (communication game). And Also in the modified example, the play state updating unit 66a sets the play state to a state in which the notification of the reception of the invitation information is disabled for a predetermined time (first time) after the end of the multiplay (communication game). It may be.

  In the above-described embodiment, the play state updating unit 66a does not change the play state and the reception of the invitation information for 5 minutes (second time) or 60 minutes (second time) after the input of the rejection operation. It is set to the impossible state that can be made. Also in the modified example, the play state updating unit 66a may change the play state to an impossible state in which it is impossible to notify the reception of the invitation information for a predetermined time (second time) after the input of the refusal operation. .

  The server 100 also stores predetermined player information in the player information storage unit 160 (storage unit) for each player, and updates a priority point (priority information) for each player according to a preset update condition. Function as a player information updating unit 140a (accumulating unit, updating unit). The update condition of the priority point can be designed as appropriate. Further, the priority point is merely an example of the priority information. For example, the play time of the game, the player level, the player rank, the charge amount, and a combination thereof may be set as the priority information.

  In the above embodiment, the player information updating unit 140a updates the priority points based on the ratio of the damage given in multiplay. That is, the player information updating unit 140a updates the priority points (priority information) based on a predetermined result during the multiplay (communication game). In this case, for example, the priority points may be updated based on the existence or non-existence of the player character at the end of the multi-play, instead of the ratio of the applied damage. Further, for example, a point obtained by multiplying the given damage by a predetermined coefficient may be added to or subtracted from the priority point. In any case, when the priority information is updated based on a predetermined result during multiplay (communication game), the predetermined result can be appropriately designed. However, the result during multi-play is not essential for the update condition of the priority point.

  In the above embodiment, the player information updating unit 140a updates the priority point (priority information) based on information received from the target terminal (extraction terminal) after receiving the invitation information. Specifically, the priority point is updated when the participation information is input (however, when the room cannot be entered) and when the opening information is input. However, for example, after receiving the invitation information, the player information updating unit 140a may not update the priority points.

  Further, upon receiving the request information from the player terminal 1, the server 100 sets a plurality of player terminals 1 as target person terminals (extraction terminals) capable of receiving the invitation information based on at least the priority points (priority information). It functions as a terminal setting unit 144a (setting unit) that can perform the setting. In the above embodiment, the terminal setting unit 144a may set a follower or a mutual follower for the target person. That is, the terminal setting unit 144a may set the target person based on the priority points, or may set the target person irrespective of the priority points. When the priority information is set for each player, the terminal setting unit 144a may set the target person terminal based at least on the priority information.

  Further, the server 100 receives any one or more target person terminals (extraction terminals) to which the invitation information has been received and the predetermined participation information has been transmitted, and the player terminal 1 (host terminal) to which the request information has been transmitted. Function as a game execution unit 146a that executes multi-play (communication game). The content of the game provided by the game execution unit 146a is not particularly limited.

  Further, the above-mentioned role sharing between the player terminal 1 and the server 100 is merely an example. In the above embodiment and the modified example, the player terminal 1 stores and updates the play state. That is, in the above embodiment and the modified example, the player terminal 1 functions as a play state update unit 66a (state update unit). However, the play state may be stored and updated in the server 100.

  Hereinafter, a second embodiment in which the server 100 functions as a state update unit (server-side state update unit) will be described. In the following, the same components as those in the above embodiment are denoted by the same reference numerals, and detailed description thereof will be omitted.

(Second embodiment)
FIG. 34 is a diagram illustrating the configuration of the memory 12 of the second embodiment in the player terminal 1 and functions as a computer. In the second embodiment, the terminal-side game control program further includes a play state transmission program 67 in addition to the above programs. Then, the CPU 10 operates the play state transmission program 67 to function as the play state transmission section 67a.

  The play state transmitting unit 67a transmits a play state (play state information) of the player terminal 1 to the server 100. In the second embodiment, the setting and updating of the play state are performed in the player terminal 1 as in the above-described embodiment. At this time, the setting condition for setting the play state may be the same as or different from the above embodiment. Here, it is assumed that the play state is stored in the play state storage unit 82, but the storage and update of the play state are not essential in the player terminal 1. In any case, the play state transmitting unit 67a may transmit the play state of the player terminal 1 to the server 100.

  The conditions under which the play state transmitting section 67a transmits the play state information can be appropriately designed. For example, when the play state changes, the play state transmitting unit 67a transmits play state information corresponding to the changed play state to the server 100. However, the play state transmitting unit 67a may transmit the play state information corresponding to the currently set play state to the server 100 at regular intervals. Alternatively, the play state transmitting unit 67a may transmit the play state information every time communication with the server 100 is performed.

  Further, in the second embodiment, as in the above-described embodiment, the play state includes five states of “receivable state”, “unopened state”, “opened state”, “participation state”, and “receivable state”. It is assumed that three states are provided (see FIG. 14A). Therefore, the play state transmitting unit 67a transmits five types of play state information that can be identified to each other to the server 100. However, in the second embodiment, the play state may be different from the above embodiment. For example, as the play state, two types of “permitted state” and “impossible state” shown in FIG. 14A may be set.

  FIG. 35 is a diagram illustrating the configuration of the memory 112 of the second embodiment in the server 100 and a function as a computer. In the second embodiment, the server-side game control program further includes a play state receiving program 147 and a play state update program 149 in addition to the above programs. Then, the CPU 110 operates the play state receiving program 147 to function as the play state receiving unit 147a. Also, the CPU 110 operates the play state update program 149 to function as the play state update unit 149a.

  The play state receiving unit 147a receives a play state (play state information) transmitted from the player terminal 1.

  The play state updating unit 149a updates the play state of the player terminal 1 based on the play state information received by the play state receiving unit 147a. Note that the play state may be stored in the player information storage unit 160 or may be stored in the extraction list storage unit 162. Further, a dedicated storage unit for storing a play state for each player terminal 1 may be provided in the data storage area 112b separately from the player information storage unit 160 and the extraction list storage unit 162. In the second embodiment, as an example, a case in which the play state updating unit 149a stores the play state of each player terminal 1 in the player information storage unit 160 will be described.

  Also in the second embodiment, the list updating unit 142a sets the status flag of the extraction list. However, in the second embodiment, five status flags of “permitted state”, “impossible state”, “receivable”, “receivable”, and “received” are provided. Of these, the “permitted state” and the “impossible state” are provided in place of “settable (blank)” in the above embodiment, and “receivable”, “receivable”, and “received” Same as the form. The list update unit 142a updates the status flag based on the play status stored in the player information storage unit 160, the operation information input from the player terminal 1, the execution of the game in the server 100, and the management status.

  The list update unit 142a sets the status flag of the extraction list to “permitted” for the player terminal 1 in which the play state of “receivable state” or “unopened state” is stored in the player information storage unit 160. In addition, the list update unit 142a sets the status flag of the extraction list for the player terminal 1 in which the play state of “opened state”, “participation state”, and “unreceivable state” is stored in the player information storage unit 160 as “ Set to "impossible state".

  When receiving the request information for the random tab 48c, the terminal setting unit 144a sets the invitation information and the like in the storage area of the top 100 persons whose status flags are “permitted” in the extraction list.

  Hereinafter, an example of a process performed by the player terminal 1 and the server 100 according to the second embodiment will be described.

  FIG. 36A is a first sequence diagram illustrating processing of the player terminal 1 and the server 100 according to the second embodiment. When the play state is updated in the player terminal 1 (P201), the play state information is transmitted to the server 100. When the play state receiving unit 147a receives the play state information, the play state update unit 149a updates the play state in the player information storage unit 160 (S201). In addition, the list updating unit 142a updates the status flag of the extraction list based on the play state stored in the player information storage unit 160.

  FIG. 36B is a second sequence diagram illustrating a process performed by the player terminal 1 and the server 100 according to the second embodiment. In the player terminal 1 and the server 100, when the battle game control processing by multi-play is completed (P205, S205), the play state updating unit 149a updates the play state in the player information storage unit 160 to a “non-receivable state” (S206). . In addition, the list update unit 142a updates the status flag of the extraction list to “impossible” for the players (at least one of the host player and the guest player) participating in the multiplay (S207). At this time, the list updating unit 142a sets the first time as the wait time in the weight counter (S208).

  FIG. 36C is a third sequence diagram illustrating processing of the player terminal 1 and the server 100 according to the second embodiment. When a rejection operation is input in the player terminal 1 (P210), rejection information is transmitted to the server 100. Upon receiving the refusal information, the play state updating unit 149a updates the play state in the player information storage unit 160 to the “non-receivable state” (S210). Further, the list updating unit 142a updates the status flag of the extraction list to “impossible state” (S211). At this time, the list update unit 142a sets the second time as the wait time in the weight counter (S212).

  Although a detailed description is omitted, when the first time or the second time elapses, in the list information update process (see FIG. 32), the list update unit 142a changes the play state of the player information storage unit 160. Confirm. At this time, if the play state is “receivable state” or “unopened state”, the list updating unit 142a updates the status flag to “permitted state”. On the other hand, if the play state is neither the “receivable state” nor the “unopened state”, the status flag is maintained in the “impossible state”.

  As described above, according to the second embodiment, the server 100 functions as the play state update unit 149a (state update unit). The play state updating unit 149a updates the play state of the player terminal 1 based on information received from the player terminal 1. Then, the terminal setting unit 144a (setting unit) sets the target person terminal (extraction terminal) based on at least the priority points (priority information) and the game play status of the player terminal 1.

  Further, in the second embodiment, the terminal setting unit 144a (setting unit) sets at least the player terminal 1 on which the multiplay (communication game) has been executed until the first time elapses after the end of the communication game. , Do not set the target person terminal (extraction terminal). In addition, after receiving the invitation information, the terminal setting unit 144a (setting unit) sets at least the second time period for the player terminal 1 to which the rejection information indicating the refusal to participate in the multiplay (communication game) has been transmitted. Is not set as the target person terminal (extraction terminal).

  In the second embodiment, the play state information is transmitted from the player terminal 1. However, the player terminal 1 may not manage the play state, and only the server 100 may update the play state of the player terminal 1 based on information received from the player terminal 1. Further, the above-described modified example can be applied to the second embodiment.

  Further, for example, the play state update unit 149a may update the login state of the player terminal 1 as a play state, that is, a play state. Then, the terminal setting unit 144a can set the player terminal 1 in the login state as the target terminal, and does not set the player terminal 1 not in the login state as the target terminal.

  In the above embodiment, in addition to the update of the play state in the player terminal 1, the login state may be updated as the play state in the server 100. In this case, the target person is set based on the play state managed by the player terminal 1 and the server 100 and the priority information managed by the server 100.

  As described above, the play state of the game, that is, the play state, may be managed by the player terminal 1 or the server 100, or may be managed by both the player terminal 1 and the server 100. May be done. However, by managing the play state in the player terminal 1, the processing load on the server 100 is reduced. On the other hand, when the play state is managed by the server 100, the server 100 can recognize the player terminal 1 that can immediately receive the invitation information or immediately report the reception of the invitation information. Therefore, only the player terminal 1 that can immediately receive the invitation information or report the reception of the invitation information can be set as the target person terminal. Thus, multiplayer can be started earlier.

  In each of the above embodiments and modifications, the information processing system S, which is a client server system, performs the above information processing. However, only the player terminal 1 in the above embodiment and the modified example may be provided as the game terminal device. The game terminal device is not limited to a smartphone as long as it has a communication function, and may be a dedicated game device. Further, only the server 100 in the above embodiment and the modified example may be provided as a server device.

  Further, the program in each of the above-described embodiments and modifications may be stored in a computer-readable storage medium and provided as a storage medium. Further, it may be provided as a game terminal device or a server device including the storage medium. Further, the above embodiments and modified examples may be information processing methods that realize the functions and the steps shown in the flowcharts.

  As mentioned above, although one aspect of the embodiment has been described with reference to the accompanying drawings, it is needless to say that the present invention is not limited to the above embodiment and the modification. It is clear that those skilled in the art can conceive various modifications or modifications within the scope of the claims, and those skilled in the art understand that they naturally belong to the technical scope of the present invention. Is done.

  The present invention can be used for an information processing program, a game terminal device, and an information processing system.

46 Room creation tab (operation part)
60a game execution section 64a request information transmission section 66a play state update section (state update section)
68a Invitation information receiving unit (receiving unit)
70a Invitation information notification unit (notification unit)
72a Operation permission unit 100 server (external device)
140a Player information update unit (storage unit)
144a Terminal setting unit (setting unit)
146a Game execution unit 149a Play state update unit (state update unit)
160 Player information storage unit (storage unit)
S Information processing system

Claims (8)

The input of the request operation from the operation unit of the player terminal, so that to store a plurality of players simultaneously and participate invite invitation information to the playable communication game, the server in association with a plurality of other receiving terminals request information for requesting the, a request information transmitting unit for transmitting to said server,
Based on at least the game play status, permission state information that enables reception of the invitation information from the server as the receiving terminal, and impossibility state information that disables reception of the invitation information from the server. A state updating unit that stores play state information including
If the permission state information is stored as the play state information, the server performs communication to confirm whether the invitation information is stored in association with the receiving terminal as the receiving terminal, and if the invitation information is stored, receives the invitation information from the server, a receiving unit that be stored in the invitation information storage unit of the player terminal,
At the time of or after receiving the invitation information, a notification unit that notifies the reception of the invitation information,
At the time of notification of the reception of the invitation information or after notification, an operation permission unit that allows input of a predetermined participation operation,
When the participation operation is input and a predetermined start condition is satisfied, a game execution unit that executes the communication game;
Information processing program that causes the player terminal to function. The input of the request operation from the operation unit of the player terminal, so that to store a plurality of players simultaneously and participate invite invitation information to the playable communication game, the server in association with a plurality of other receiving terminals request information for requesting the, a request information transmitting unit for transmitting to said server,
The server performs communication for confirming whether the invitation information is stored in association with the reception terminal. If the invitation information is stored, the server receives the invitation information from the server, and receives the invitation information of the player terminal. a receiving unit that be stored in the storage unit,
Based on at least a game play state, a play state including permission state information capable of notifying reception of the invitation information from the server, and impossibility state information disabling notification of reception of the invitation information from the server. A state update unit for storing information;
At the time of or after the reception of the invitation information, when the permission state information is stored as the play state information, a notification unit that notifies the reception of the invitation information,
At the time of notification of the reception of the invitation information or after notification, an operation permission unit that allows input of a predetermined participation operation,
When the participation operation is input and a predetermined start condition is satisfied, a game execution unit that executes the communication game;
Information processing program that causes the player terminal to function. The state updating unit holds the impossible state information as the play state information for a first time after the end of the communication game , at least a game play state, and the invitation information in the invitation information storage unit. The information processing program according to claim 1, wherein the play status information is updated based on whether or not the play status information is stored. The operation permitting unit, at the time of notification of the reception of the invitation information or after notification, enables input of a rejection operation for rejecting participation in the communication game,
4. The information processing program according to claim 1, wherein the state update unit holds the impossible state information as the play state information for a second time after the input of the refusal operation. 5. The operation permitting unit, at the time of notification of the reception of the invitation information or after notification, enables input of a predetermined hold operation,
The notification unit continues the notification when the hold operation is input, and terminates the notification when receiving from the server the participation disable information that can be received when participation in the communication game is disabled. The information processing program according to any one of claims 1 to 4.   A game terminal device including a storage medium storing the information processing program according to any one of claims 1 to 5. A storage unit provided in the server, for storing predetermined player information in a storage unit for each player;
Provided in the player terminal, and in response to input of a request operation from the operation unit of the player terminal , associating invitation information for inviting a plurality of players to participate in a communication game that can be simultaneously played with other plurality of receiving terminals. a request information transmitting unit that transmits request information requests that the memory in the server, the server Te,
Permission state information provided at the player terminal, based on at least a game play situation at the player terminal, permission state information enabling reception of the invitation information from the server as the receiving terminal, and transmission of the invitation information from the server. A state updating unit that stores play state information including impossible state information that makes reception impossible,
Provided in the server, upon receiving the request information from the player terminal, storing at least the plurality of player terminals and the invitation information in association with each other based on the player information stored in the storage unit; A setting unit that sets the player terminal associated with the information as an extraction terminal that can receive the invitation information,
Provided in the player terminal, if the permission condition information as prior Symbol play state information is stored, as the receiving terminal communicates said player terminal to confirm whether it is set to the extraction terminal, the if it is set to extract the terminal receives the invitation information from the server, a receiving unit that be stored in the invitation information storage unit of the player terminal,
At the player terminal, at or after receiving the invitation information, a notification unit that notifies the reception of the invitation information,
An operation permitting unit that is provided in the player terminal and that enables input of a predetermined participation operation at or after notification of the reception of the invitation information,
A game execution unit that is provided in the server and executes the communication game between one or more player terminals to which participation information has been transmitted based on the input of the participation operation and the player terminal that has transmitted the request information; ,
An information processing system comprising: A storage unit provided in the server, for storing predetermined player information in a storage unit for each player;
Provided to the player terminal, associated with the input of the request operation from the operation unit of the player terminal, the invite invitation information to join a plurality of players to play available communication games simultaneously, and another plurality of receiving terminals a request information transmitting unit that transmits request information requests that the memory in the server, the server Te,
Permission state information provided at the player terminal and capable of notifying reception of the invitation information from the server based on at least a play situation of a game at the player terminal, and impossibility of notifying reception of the invitation information from the server A state update unit that stores play state information including impossible state information,
Provided in the server, upon receiving the request information from the player terminal, storing at least a plurality of player terminals and the invitation information in association with each other based on at least the player information stored in the storage unit; A setting unit that sets the player terminal associated with the information as an extraction terminal that can receive the invitation information,
Provided in the player terminal, if the player terminal is set to the extraction terminal, as the receiving terminal receives the invitation information from the previous SL server, store the invitation information storage unit of the player terminal A receiving unit,
Provided in the player terminal, at the time of receiving the invitation information or after receiving, when the permission state information is stored as the play state information, a notification unit that notifies the reception of the invitation information,
An operation permitting unit that is provided in the player terminal and that allows input of a predetermined participation operation at or after notification of the reception of the invitation information,
A game execution unit that is provided in the server and that executes the communication game between one or more player terminals to which participation information has been transmitted based on the input of the participation operation and the player terminal that has transmitted the request information; ,
An information processing system comprising:

Images