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

Abstract

To enable reduction in time to initiation of a communication game.SOLUTION: An information processing program causes a computer to function as: a request information transmitting unit 64a for transmitting request information to an external device in response to an input of a request operation from an operating unit; a play state updating unit 66a for updating a play state, at least on the basis of a play status of a game; an invitation information receiving unit 68a capable of receiving invitation information from the external device if the play state is a permitted state; an invitation information reporting unit 70a for reporting receipt of the invitation information either when or after the invitation information is received; an operation permitting unit 72a permitting input of a prescribed participation operation, either when or after the receipt of the invitation information is reported; and a game executing unit 60a for executing a communication game with another player terminal if the participation operation has been input and a prescribed start condition is satisfied.SELECTED DRAWING: Figure 19

Description

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

Conventionally, a communication game (hereinafter referred to as multi-play) in which a plurality of players can participate is known. In multiplayer, it is necessary to match the participants of the game. For example, Patent Document 1 proposes a game system that accepts a competition application from another player (succeeding player) while the preceding player is playing the game.

According to this game system, an image for notifying the competition application is displayed on the game screen of the preceding player. Then, when the preceding player performs an operation of receiving the application, the multi-play is started after waiting for the end of the game being played by the preceding player.

JP 2000-140413 A

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

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

In order to solve the above problem, the information processing program updates a play state based on at least a play state of a game, and a request information transmitting section that transmits request information to an external device by inputting a required operation from an operating section. A state updating unit, a receiving unit that can receive invitation information from an external device when the play state is a permitted state, a notification unit that notifies reception of invitation information when or after receiving invitation information, and invitation information When a notification is received or after the notification, an operation permission unit that enables input of a predetermined participation operation, and a game that executes a communication game with another player terminal when the participation operation is input and a predetermined start condition is satisfied. The computer functions as an execution unit.

In order to solve the above problem, the information processing program updates a play state based on at least a play state of a game, and a request information transmitting section that transmits request information to an external device by inputting a required operation from an operating section. A state updating unit, a receiving unit that can receive invitation information from an external device, and a notification unit that notifies reception of invitation information when the play state is a permitted state at the time of or after receiving the invitation information. , When the notification of the reception of the invitation information is given or after the notification is given, and the operation permission section that enables the input of the predetermined participation operation, and the predetermined start condition is satisfied, the communication game with the other player terminal is started. It functions as a game execution unit that executes a computer.

Further, the state update unit may set the play state to the impossible state in which it is impossible to receive the invitation information or to notify the reception of the invitation information for the first time period after the end of the communication game.

In addition, the operation permission unit enables input of a refusal operation for refusing to participate in the communication game at the time of or after the notification of the reception of the invitation information, and the state update unit allows the second operation after the refusal operation is input. The play state may be set to an impossible state in which reception of invitation information or notification of reception of invitation information is disabled over time.

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

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

In order to solve the above problems, an information processing system includes a storage unit that stores predetermined player information in a storage unit for each player, and a state update unit that updates a play state based at least on a play state of a game on a player terminal. A request information transmitting unit that transmits request information by inputting a request operation in the operation unit of the player terminal and a plurality of player terminals based on at least the player information accumulated in the storage unit when the request information is received from the player terminal. A setting unit that sets the extraction information that can receive the invitation information, a reception unit that can receive the invitation information in the extraction terminal whose play state is in the permitted state, and a reception unit that receives the invitation information when or after the invitation information is received. Any one of a notification unit that notifies reception, an operation permission unit that enables input of a predetermined participation operation at or after notification of reception of invitation information, and participation information that is transmitted based on the input of the participation operation. Alternatively, it includes a plurality of extraction terminals and a game execution unit that executes a communication game with the player terminal that has transmitted the request information.

In order to solve the above problems, an information processing system includes a storage unit that stores predetermined player information in a storage unit for each player, and a state update unit that updates a play state based at least on a play state of a game on a player terminal. A request information transmitting unit that transmits request information by inputting a request operation in the operation unit of the player terminal and a plurality of player terminals based on at least the player information accumulated in the storage unit when the request information is received from the player terminal. Is set in the extraction terminal that can receive the invitation information, the receiving unit that can receive the invitation information in the extraction terminal, and the extraction terminal when the invitation information is received or after the reception state In some cases, a notification unit that notifies reception of invitation information, an operation permission unit that enables input of a predetermined participation operation at the time of notification of reception of invitation information, or after notification, participation information based on input of participation operation Any one or a plurality of extraction terminals that have transmitted the request information, and a game execution unit that executes a communication game with the player terminal that has transmitted the request information.

According to the present invention, it is possible to shorten 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 an information processing system. FIG. 2A is a diagram illustrating a hardware configuration of the player terminal. FIG. 2B is a diagram illustrating the hardware configuration of the server. FIG. 3A is a diagram showing an example of a party organization screen. FIG. 3B is a diagram illustrating an example of the information confirmation screen. FIG. 3C is a diagram showing 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 the result screen. FIG. 5A is a diagram illustrating an example of a play content selection page when multi-play is selected. FIG. 5B is a diagram illustrating an example of the room selection page. FIG. 5C is a diagram illustrating an example of a 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 the reject operation. FIG. 7B is a diagram illustrating an example of the screen after the reject 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 a 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 priority points. FIG. 9B is a diagram illustrating a priority point update condition. 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 confirmation of reception of invitation information. FIG. 15 is a sequence diagram illustrating the 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 executed. FIG. 17 is a sequence diagram illustrating processing of the player terminal and the server when the player cannot participate in the multi-play. FIG. 18 is a sequence diagram illustrating processing of the player terminal and the server when the participation in the multi-play is rejected. FIG. 19 is a diagram illustrating the configuration of the memory in the player terminal and the function of the computer. FIG. 20 is a flowchart illustrating an example of terminal-side game processing 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 invitation information reception processing in the player terminal. FIG. 23 is a flowchart illustrating an example of invitation information confirmation processing in the player terminal. FIG. 24 is a first flowchart illustrating an example of post-invitation information reception processing in the player terminal. FIG. 25 is a second flowchart illustrating an example of processing after receiving invitation information in the player terminal. FIG. 26 is a flowchart illustrating an example of multi-play ending processing in the player terminal. FIG. 27 is a diagram illustrating the configuration of the memory in the server and the function of the computer. FIG. 28 is a flowchart illustrating an example of server-side game processing in the server. FIG. 29 is a flowchart illustrating an example of request information reception processing in the server. FIG. 30 is a flowchart illustrating an example of information update processing in the server. FIG. 31 is a flowchart illustrating an example of multi-play end processing in the server. FIG. 32 is a flowchart illustrating an example of rearrangement processing in the server. FIG. 33 is a flowchart illustrating an example of a modified invitation information reception process in the player terminal. FIG. 34 is a diagram for explaining the configuration of the memory and the function as a computer of the second embodiment in the player terminal. FIG. 35 is a diagram illustrating a configuration of a memory and a function as a computer in the server according to the second embodiment. FIG. 36A is a first sequence diagram illustrating processing of the player terminal and the server according to the second embodiment. FIG. 36B is a second sequence diagram illustrating the processing of the player terminal and the server according to the second embodiment. FIG. 36C is a third sequence diagram illustrating processing of the player terminal and the server according to the second embodiment.

Hereinafter, one aspect of an embodiment of the present invention will be described in detail with reference to the accompanying drawings. The dimensions, materials, and other specific numerical values shown in the embodiments are merely examples for facilitating understanding, and do not limit the present invention unless otherwise specified. In this specification and the drawings, elements having substantially the same function and configuration are denoted by the same reference numerals to omit redundant description, and elements not directly related to the present invention are omitted. To 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 the communication network 200 having the communication base station 200a.

The player terminal 1 can establish communication with the server 100 via the communication network 200. The player terminal 1 includes a wide range of 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 machine, and the like. In this embodiment, a case where a smartphone is used as the player terminal 1 will be described.

The server 100 is communicatively connected to a plurality of player terminals 1. The server 100 accumulates various information (player information) for each player who plays the game. The server 100 also updates the accumulated information and controls the progress of the game based on the operation input from the player terminal 1.

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

In the information processing system S of this embodiment, the player terminal 1 and the server 100 function as the game device G. The player terminal 1 and the server 100 are divided into roles for controlling the progress of the game, and the game can be progressed by the cooperation of the player terminal 1 and the server 100.

(Hardware Configuration of Player Terminal 1 and Server 100)
FIG. 2A is a diagram illustrating a hardware configuration of the player terminal 1. Further, FIG. 2B is a diagram illustrating a hardware configuration of the 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. To be 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.

The configurations and functions of the CPU 110, 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 of the server 100 are the CPU 10 of the player terminal 1, the memory 12, and the memory unit 12, respectively. 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 are substantially the same. Therefore, the hardware configuration of the player terminal 1 will be described below, 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 composed of 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 the bus 14.

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

The storage unit 18 is composed of 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 communicatively connected to the communication base station 200a, and exchanges information such as various data and programs with the server 100 via the communication network 200. In the player terminal 1, the 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 through which a player's operation is input (operation is received), a button, a keyboard, a mouse, a cross key, an analog controller, and the like. The input unit 22 may be a dedicated controller provided in the player terminal 1 or connected (externally attached) to the player terminal 1. Furthermore, the input unit 22 may be configured by an acceleration sensor that detects the tilt or movement of the player terminal 1, or a microphone that detects the voice of the player. That is, the input unit 22 includes a wide range of devices that allow the player's intention to be input in a distinguishable manner.

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

(Game content)
Next, the contents of the game provided by the information processing system S (game device G) of the present embodiment will be described using an example. In this embodiment, a so-called battle game in which a teammate character plays against an enemy character is provided. Specifically, in the game of this embodiment, a plurality of teammate characters are provided. The player organizes a party by selecting a plurality (here, three bodies) from the provided teammate characters. In addition, the player can play a plurality of types of battle games with different enemy characters and different difficulty levels. In a battle game, a player operates a team-side character formed in a party to defeat an enemy character and obtain a reward.

FIG. 3A is a diagram showing an example of a party organization screen. FIG. 3B is a diagram illustrating an example of the information confirmation screen. FIG. 3C is a diagram showing 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. On the display 26 of the player terminal 1, a game screen as shown in FIGS. 3A, 3B, 3C and 3D is displayed. 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 check 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.

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 showing the stamina of the player is displayed.

The stamina is a parameter required to play the battle game. In this embodiment, a plurality of types of battle games are provided, and the consumption value of stamina required for play is set in each battle game. Since the player consumes the stamina and plays the battle game, when the stamina is insufficient, the player cannot play the battle game.

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

A notification image 34 is displayed at the left end of the header display area 30. As will be described later in detail, the notification image 34 notifies the player of the invitation information of the battle game or the guidance information of the event. When neither invitation information nor guidance information is received, the notification image 34 is displayed in a non-notification mode. It should be noted that the notification image 34 in the non-notification mode is displayed in 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 the notification mode. The notification image 34 in the notification mode is highlighted in a color that is more noticeable than in 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 the player can operate (tap). Here, as an example of the operation unit, in the menu bar 36, a home screen selection unit 36a described as "Home", a party organization screen selection unit 36b described as "Party", and a quest screen described as "Quest" A selection unit 36c and an information confirmation screen selection unit 36d labeled "Info" are provided.

When the home screen selection unit 36a is tapped, the home screen is displayed on the display 26. When the party organization screen selection unit 36b is tapped, the party organization 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 shown in FIG. 3C (battle game selection Page) is displayed on the display 26.

As described above, the normal screen is roughly divided into four screens. On the menu bar 36, the operation unit corresponding to each screen is highlighted so that the screen being displayed on the display 26 can be identified. Note that when the page transitions within the normal screen, or when transitioning 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, the images other than the header display area 30 and the menu bar 36 are switched.

On the party organization screen shown in FIG. 3A, all teammate characters possessed by the player are displayed. The player can organize three parties by selecting three teammate characters from the displayed teammate characters. Here, up to 6 parties can be organized and stored. An experience value and a level are stored in association with each teammate character. The experience value increases when a player wins a battle game described below or when a predetermined item is used. The level is set corresponding to the experience value, and the level increases every time the experience value reaches a predetermined value. An upper limit value of the level is set for each ally character, and the level increases only within the range of the upper limit value.

In addition, base values of combat strength such as life points, offensive strength, and defense strength are set for the teammate character according to the level. The higher the fighting power of the teammate character, the more advantageous the player can proceed with the battle game. Further, each base value set for the teammate character increases as the level increases.

Further, on the party organization screen, the player can equip (set) the equipment such as weapons and armor to the teammate characters incorporated in the party. Each equipment item has an added value for offensive power, defense power, and the like. When the equipment is equipped, the added value of each equipment is added to the above base value, and the combat power of the teammate character can be increased.

On the information confirmation screen shown in FIG. 3B, player information regarding 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 possessed characters (the number of ally characters held by the player), the number of followers, and the number of mutual followers are displayed. In the present embodiment, the follower refers to another player that the player has set as a so-called favorite or a friend. In addition, in the present embodiment, the mutual followers indicate players who are set to follow each other.

On the battle game selection page of the quest screen shown in FIG. 3C, a plurality of selection tabs 38 in which the types of battle games being provided, that is, battle game names are displayed are displayed. Here, 10 types of battle games are provided, and 10 selection tabs 38 are displayed. Opening conditions are set for each battle game. Examples of the opening condition include that the player experience value, the player level, the player rank is equal to or higher than a predetermined value, that another predetermined battle game is cleared, and the like.

The player can play only the battle game satisfying the opening condition. Therefore, in 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 illustrated. Further, only the selection tab 38 of the battle game satisfying the opening condition accepts the operation (tap) by the player.

When the selection tab 38 is tapped on the battle game selection page, the play content selection page shown in FIG. 3D is displayed. On this play content selection page, the party used for the battle game can be selected from the parties organized on the party organization screen. Further, in the present embodiment, the play types are provided as single play in which the player plays the battle game alone, and multiplayer in which the player plays the battle game in cooperation with other players through communication. 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 the result screen. As shown in FIG. 4A, when the type of battle game and the party used in the battle game are selected and the single play tab 40a is operated, single play is started. In the following, a teammate character included in a party used in the battle game, that is, a teammate 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, damages the enemy character, and receives damage from the enemy character. In addition, the enemy character operates under computer control to damage the player character or receive damage from the player character.

When damage points are given to the enemy character, the damage points are subtracted from the life points of the enemy character. Similarly, when the damage points are given to the player character, the damage points are subtracted from the life points of the player character. When the life point of the enemy character becomes 0, the player wins, and when the life points of all the 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 hidden. Further, in the header display area 30, the stamina display bar 32 is hidden and the life points for each player character are displayed. Further, on the battle screen, the operation tab 42 is displayed in the header display area 30. The display position of the operation tab 42 is the same as the position where at least a part of the notification image 34 is displayed on the normal screen in the header display area 30.

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

When the battle game ends normally (normal end), 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, that is, an intermediate end due to retirement, a win end in which the victory is confirmed in the battle game, and a defeat end in which the defeat is confirmed in the battle game. FIG. 4C shows, as an example, a result screen at the end of victory, but the result screen is different for each end pattern.

On the result screen, the end operation unit 44 marked “CLOSE” is displayed, and when the end operation unit 44 is tapped, the display on the display 26 is switched 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 the home screen. In this way, the battle game ends when the result screen is displayed.

FIG. 5A is a diagram illustrating an example of a play content selection page when multi-play is selected. FIG. 5B is a diagram illustrating an example of the room selection page. FIG. 5C is a diagram illustrating an example of a 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 multi-play tab 40b is tapped in a state where the type of battle game and the party used in the battle game are selected.

In this case, as shown in FIG. 5B, the room selection page of the quest screen is displayed. 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 refer to an area secured by the server 100 for performing the multiplay.

The player can create a room by tapping the room creation tab 46 (inputting a requested operation) when performing multi-play. In addition, below, the player who created the room in the multi-play is called 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 user selection page of the quest screen is displayed as shown in FIG. 5C. On the target person selection page, a follower tab 48a labeled "follower", a mutual follower tab 48b labeled "mutual follower", and a random tab 48c labeled "random" are displayed. The player who creates a room can select a target person (guest player) to invite to the room created by himself/herself on the target person selection page.

Specifically, when the follower tab 48a is operated, the player who is set as the follower by the player who creates the room is set as the target person who can receive the invitation information. In this embodiment, the invitation information can be received only by the player set as the target person, and the player who is not set as the target person does not receive the invitation information. Further, as will be described later in detail, the subject does not receive the invitation information unless certain conditions are met. Therefore, it can be said that the target person is the player who has 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 person receives the invitation information when communicating with the server 100. The target person who has received the invitation information can decide whether to enter the room, that is, whether to participate in the multi-play. In this way, entry into 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, the 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. Further, on the room detail page of the host player, a start tab 50 described as "ready" is displayed. 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 subject. When the player terminal 1 receives the invitation information in this state, the notification image 34 is switched from the non-notification mode to the notification mode in the header display area 30 as illustrated.

Further, as shown in FIG. 6B, it is assumed that a battle screen is displayed on the display 26 in the player terminal 1 of the subject. As described above, in the battle screen, the operation tab 42 is normally displayed in the header display area 30 (see FIG. 4B), but when the player terminal 1 receives the invitation information, the operation tab 42 is displayed as illustrated. , And 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 and displayed 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 as in the case where the operation tab 42 is tapped, and the invitation information dialog 52 is displayed so as to be superimposed on the battle screen at the time of interruption. It

In the invitation information dialog 52, as the quest information, for example, the player rank and the player name of the host player, the type of the battle game played in the multiplayer, and the like are displayed. Further, the invitation information dialog 52 is provided with a participation tab 52a described as "participate", a rejection tab 52b described as "do not participate", and a hold tab 52c described as "close". ..

The participation tab 52a accepts participation in multi-play, that is, a participation operation that desires to enter the invited room. Further, the refusal tab 52b accepts a refusal operation for refusing to participate in the multiplayer. Further, the hold tab 52c receives a hold operation in which whether or not to participate in the multi-play is treated as a hold.

For example, assume 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 (hidden) as shown in FIG. 6D. However, when the hold operation is input, the notification image 34 continues to be displayed in the notification mode. If the hold operation is input while the invitation information dialog 52 is displayed during the battle game, the invitation game is closed and the battle game is restarted at the same time. In this case also, the notification image 34 continues to be displayed in the notification mode.

FIG. 7A is a diagram illustrating an example of a screen before the reject operation. FIG. 7B is a diagram illustrating an example of the screen after the reject operation. As illustrated in FIG. 7A, it is assumed that the rejection operation is input by tapping the rejection tab 52b after opening the invitation information dialog 52. When the refusal 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.

In addition, when the refusal 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 hidden 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 a 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 the 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 or not to enter the invited room.

Specifically, in the invited room, if multiplayer has already started (playing), the maximum number of guest players are in the room (full room), or the room has disappeared (disbanded). ), it is determined that the room cannot be entered. In this case, the display 26 of the player terminal 1 displays a dialog (not allowed entry screen) notifying that entry into the room is impossible.

On the other hand, it is assumed that the server 100 determines that the room can be entered. In this case, the player information of the target person who has transmitted the participation information is added to the room, and the room information is updated. In this way, when the participation operation is performed and the user can enter the room, the target person is set as the guest player. When the room information is updated, the host player and all 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 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 the multi-play.

The room detail page displayed on the guest terminal is not provided with an operation unit that accepts an operation to leave the room. That is, the guest player cannot officially leave the room where he/she entered. As a result, the situation in which the guest player repeatedly enters and leaves the room is suppressed, and the multiplayer can be started early. However, an exit operation unit may be provided on the room detail page of the guest terminal so that the guest player can exit the room. Further, the room detail page displayed on the host terminal may be provided with an operation unit for intentionally breaking up the room.

Although illustration is omitted, 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 refusal 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 input of the refusal operation, the notification that the invitation information does not exist is given. Done. In other words, the target person cannot participate in the multi-play which is once refused to participate.

On the other hand, when the hold operation is performed, the notification image 34 is displayed in the notification mode even after the invitation information dialog 52 is closed. Therefore, when 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 the participation operation for the invited multiplayer. However, as described above, if the invited room is playing, fully occupied, 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 this embodiment, the player terminal 1 receives the guide 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 while 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 and displayed on the screen displayed when the notification image 34 is tapped. In addition, when the notification image 34 is tapped during the battle game, the battle game is interrupted, and the guidance information dialog 54 is displayed so as to be superimposed on the battle screen at the time of interruption.

The guidance information dialog 54 displays, for example, information about quests that are held regularly. In addition, the guidance information dialog 54 is provided with a non-display tab 54a labeled "Bind" and a browsing tab 54b labeled "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 the event information.

For example, it is assumed that the non-display tab 54a is tapped after opening the guidance information dialog 54 and a non-display operation is input. When the non-display operation is input, the guide information dialog 54 is closed (non-display) 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 guidance information dialog 54 is closed and the battle game is restarted. In this case also, 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 opening the guidance information dialog 54 and a browsing operation is input. When the browsing operation is input, as shown in FIG. 8D, an event guide screen in which event information that can be participated is written is displayed. Although detailed description is omitted, the event guidance screen allows the player to input an operation, and the input operation enables participation in the event. 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 reception of two types of information, that is, invitation information and guidance information. Here, the notification image 34 is displayed in a common notification mode regardless of the type of the received information. In addition, when both the invitation information and the guidance information are received, it is assumed that the notification image 34 displayed in the notification mode is tapped. In this case, the invitation information dialog 52 is displayed on the display 26. That is, the invitation information (invitation information dialog 52) is displayed with priority over the guidance information (guidance information dialog 54).

However, when both the invitation information and the guidance information are received, the guidance information (guidance information dialog 54) may be displayed with priority over the invitation information (the invitation information dialog 52). Alternatively, the guidance information (guidance information dialog 54) and the invitation information (invitation information dialog 52) may be displayed at the same time. 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. Although the player terminal 1 receives the guidance information here, the guidance information is not essential.

Here, in the present embodiment, the host player invites the target person, and the target person enters the room as the guest player, whereby the multi-play can be executed by a plurality of players for the first time. Further, the authority to start the multi-play is given only to the host player. Therefore, even if the guest player enters the room and is ready to start the multiplayer, if the host player leaves the start tab 50 without operating it, the multiplayer will not be started forever and the guest player will be stressed. Will be given. Therefore, in the present embodiment, in order to reduce the left-over by the host player, 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 the following, first, a method of extracting a target person in the server 100 will be described, and then a method of receiving and notifying invitation information in the player terminal 1 will be described.

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

In addition, the player information includes priority information as information for extracting a target person who receives 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 this embodiment, priority points are provided as priority information. As shown in FIG. 9A, the priority points are set to have a maximum value of 999 points and a minimum value of 0 points, and are updated in the range of 0 to 999. In addition, 100 points are set as initial values for the priority points, and the priority points are updated to the initial values when a predetermined update condition is satisfied.

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

The priority point update conditions are set as shown in FIG. 9B. Specifically, when the invitation information is received as the target person, “4” is subtracted from the priority point of the target person. In addition, when the subject receives the invitation information and then opens the invitation information dialog 52 by tapping the notification image 34, “1” is added to the priority point of the subject.

Further, 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 multiplayer, “4” is added to the priority point of the target person. In addition, as a case where it is not possible to participate in the multi-play, there are a case where the room cannot be entered during the play or the room is full, and a case where the room is dissolved after the room is entered and before the multi-play is started. Here, the priority point of the target person is added when the player cannot participate in the multiplayer, but instead of this, for example, when the room cannot be entered, the priority point of the target person is added. May be.

In addition, it is assumed that the multiplayer battle game ends normally (including midway termination due to retirement, end of victory and end of defeat). 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 the host player, the priority point of the host player is decremented by "4". In addition, at this time, when the random tab 48c is tapped and the target person who receives the invitation information is randomly extracted, the priority point of the host player is incremented by "1". When multi-play is started, the priority point of the host player is incremented by "1".

Furthermore, when a battle game in multiplayer ends with victory or defeat, damage given to the enemy character (hereinafter referred to as "damage") is 20% or more of all damage, and priority points are given to all players. Is added by "3".

According to the above update condition, for example, when the target person tries to participate in the multi-play but cannot participate, the invitation information is received (-4), the invitation information is opened (+1), and the multi-play cannot be participated. By (+4), the priority point is increased by "1" with reference to before the reception of the invitation information. As a result, a player who attempts to participate in the multiplayer but cannot participate in the multiplayer easily receives the invitation information. Also, when the priority game exceeds the initial value and the battle game in multiplayer ends normally, it is reset to the initial value. As a result, many players are given equal opportunity to receive the invitation information.

In addition, in guest players participating in multiplayer, if the damage caused is 20% or more of the total damage, the invitation information is received (-4), the invitation information is opened (+1), and the damage caused is 20% or more (+3). , Prioritized points will be plus or minus zero based on before participation in multiplayer. 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), and the priority point is "3" before the participation in the multiplayer. "Subtracted. That is, the guest player who is uncooperative in the multiplayer has a low priority and is unlikely 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 subtracts “4” from the priority points at the time of creating the room, but if multiplayer play is started and the damage caused is 20% or more of the total damage, the priority points will not decrease. Specifically, when the target person is randomly extracted, a room is created (-4), a target person is randomly selected (+1), multiplayer start (+1), and damage caused is 20% or more (+3). The priority point increases by "1" based on the time before creating the room. In addition, when the target person is set to follower or mutual follower, room creation (-4), multiplayer start (+1), damage caused by 20% or more (+3), the priority point is based on the room before creation. Is plus or minus zero. As a result, when the host player appropriately starts the multi-play and plays cooperatively, the player is considered to be a good player, and the opportunity to participate in the multi-play as the guest player is 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), the room is prioritized before the creation of the room. The points are reduced by "3". Even when the damage done by the host player is less than 20% of the total damage, for example, by creating a room (-4), randomly extracting a target person (+1), and starting multiplay (+1), the room is not created yet. As a reference, the priority points are decreased by "2". This makes it difficult for a player who leaves a room or intentionally breaks up a room or a non-cooperative player to participate in multi-play as a guest player.

According to the present embodiment in which the update conditions are set as described above, the invitation information can easily reach the players who seem to be cooperative or excellent, and proper matching can be realized. The processing of the server 100 when setting the target person from all the players will be described below.

(List update process 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) that stores player information for each player. The server 100 performs a player information update process for updating the player information in the player information storage unit 160 each time communication is performed with the player terminal 1. Further, the storage unit 118 is provided with an extraction list. In the server 100, the list update process of updating the extraction list is constantly performed based on the player information in the player information storage unit 160.

For example, in the 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 assigned to each of a number of storage areas having addresses. Is set. The extraction list shown in FIG. 10 and the information set in the extraction list are merely examples. For example, as the information set in the extraction list, the priority points and the player rank are not essential, and the information set in the extraction list can be designed as appropriate. Further, in FIG. 10, the numbers written in the addresses correspond to the priorities, and the smaller the number, the higher the priority.

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, description will be given using an extraction list in which players with player ranks of 11 to 20 are listed.

In the extraction list, a player having a higher priority point is listed in a storage area having an address with a higher priority. For example, it is assumed that the priority point of “165” is the highest value among the players having the player ranks of 11 to 20. It is also assumed that there are five players with 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, the address (priority order) is determined according to a predetermined condition. As described above, in the list update process, a process of listing in the extraction list is performed in order from the player with the highest priority point based on the player information in the player information storage unit 160.

FIG. 11 is a second diagram illustrating the list update process. For example, it is assumed that request information requesting the creation of a room and the sending of invitation information is transmitted to any of the player terminals 1. The request information is provided so that it can be identified for each follower tab 48a, mutual follower tab 48b, and 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 request information for the random tab 48c, the target person is set in the list update process 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 higher 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. Here, the status flag identifies four reception statuses of “setting is possible”, “reception is possible”, “reception is not possible”, and “reception is completed”. To be done. “Settable” in the reception status indicates that invitation information can be set. 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”. In addition, the “reception possible” of the reception status permits the reception of the set invitation information when the reception confirmation is made from the player terminal 1 set as the target person (hereinafter referred to as “target person terminal”). It shows that you do. Further, the reception status of "reception not possible" indicates that the reception of the set invitation information is restricted when the reception confirmation is received from the subject terminal. Further, the reception status “received” indicates that the subject terminal has received the invitation information.

The server 100 sequentially searches the storage areas to which the reception status is “settable”, that is, the status flag is blank, from the storage areas to which the addresses with the highest priority are assigned, and sets the invitation information. For example, in the state shown in FIG. 10, the status flags are blank in all the storage areas of 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 player ranks of 11 to 20, as shown in FIG. 11, the invitation information is set in the storage areas of the addresses 1 to 100. ..

A status flag is set in the storage area in which 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. In addition, a status flag indicating "unreceivable" is set in the other storage areas in which the invitation information is set. Further, the wait time is set in each of the storage areas in which the status flag of "not receivable" is set.

This wait time is the time until the reception status is switched from "reception not possible" to "reception possible". That is, when the status flag of "reception not possible" is set, the status flag is switched to "reception possible" after the wait time has elapsed. The respective storage areas are grouped for each priority point, and the same wait time is set for the storage areas classified into the same group. Further, the weight time is set shorter in a group having a relatively high priority point than in a group having 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". In this way, the wait time becomes shorter as the priority point becomes higher, and becomes longer as the priority point becomes lower.

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

As described above, when the reception status is “reception not possible”, the invitation information is set, but the player terminal 1 cannot receive the invitation information. That is, even if the player terminal 1 confirms the reception with the invitation information set, the player terminal 1 does not receive the invitation information. In this way, the server 100 allows the player having a higher priority point to receive the invitation information earlier when the target person is set by setting the invitation information. This makes it easier for a player having a higher priority to participate in the multiplayer.

In addition, in the above state, it is assumed that the request information for the random tab 48c is newly transmitted from another player terminal 1. In this case, as shown in FIG. 12, invitation information is set in the storage areas of addresses 101 to 200. The priority points of the storage areas of the addresses 101 to 200 are 163. Therefore, in this case, the status flag of “receivable” is set in all the storage areas of the 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 invitation information is confirmed to be received from the subject terminal set as the subject in the storage areas of the addresses 1 and 3. In this case, the target terminals of both players receive 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 part of FIG.

Further, as described above, when the target person receives the invitation information, the priority point of the target person is decremented by "4". The server 100 updates the priority point to “161” in the storage areas of the addresses 1 and 3. After that, the server 100 performs the 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 later in detail, when the request information for the follower tab 48a is transmitted, the invitation information is set in the storage area of the player set as the follower. Further, 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 as the mutual follower.

According to the list update process described above, a player who is highly motivated to participate in the multiplayer can easily receive the invitation information. When the player who has a strong desire to participate receives the invitation information, the time required to start the multi-play is shortened.

Furthermore, in the present embodiment, the invitation information is received according to the playing status of the game on the player terminal 1. Specifically, the reception of the invitation information is notified when the player is playing the battle game (single play) or under the situation where the player is watching the screen to play the game. That is, in the player terminal 1, the reception of the invitation information is notified in a situation in which it is considered that there is a high willingness to participate in the multi-play and a high responsiveness to the invitation. As a result, the time required for gathering the players who participate in the multi-play can be shortened, and the time required for starting the multi-play can be shortened.

(Play state of the 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 confirmation of reception of invitation information. The player terminal 1 updates the play state based on the game play state and the invitation information reception state. As shown in FIG. 14A, the play states managed by the player terminal 1 are five: 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 any of the above five play states. The player terminal 1 executes a process related to reception of invitation information based on the set play state.

Whether or not the invitation information can be received is associated with each play state. The player terminal 1 can receive the invitation information from the server 100 when the play state is set to the receivable state or the unopened state. That is, of the play states, the receivable state and the unopened state can be said to be the permitted 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 unreceivable state. That is, among the play states, the opened state, the participation state, and the unreceivable state can be said to be impossible states in which the invitation information cannot be received.

For example, it is assumed that a player is set as a target person in the server 100 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 status is set to the opened status, the participation status, or the unacceptable status. In other words, the player terminal 1 does not execute the reception confirmation of the invitation information when the play state is set to the opened state, the participation state, or the unreceivable state.

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

As shown in FIG. 14A, setting conditions are provided for each of the 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 are that invitation information has not been received, that the user is not in a multi-play room, and that the setting condition of the unreceivable state, which will be described later, does not hold. The unopened state is provided with the setting condition that the invitation information is received and the invitation information dialog 52 is unopened.

In the opened state, the setting condition is that the invitation information dialog 52 is being displayed and that the hold operation is input (the hold tab 52c of the invitation information dialog 52 is tapped). The participation condition is set as a setting condition that the user is in a multi-play room. The unacceptable state is provided as setting conditions that 5 minutes have not elapsed from the normal end of the multiplayer and that a predetermined time has not elapsed from the refusal operation. If the refusal operation is entered twice within 30 minutes, it will be kept unacceptable for 60 minutes after the second refusal operation, and in other cases, it will be kept unacceptable for 5 minutes after the refusal operation. It

When the play state is set to the permitted state, the player terminal 1 confirms the reception of the invitation information with respect 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 triggered by the reception confirmation of the invitation information. Therefore, strictly speaking, it can be said that whether or not reception confirmation of invitation information can be confirmed is preset for each play state.

As described above, in the server 100, a player who is highly willing to participate in multiplayer is set as a target person. However, even a player who is highly motivated to participate may not be able to immediately participate in the multi-play depending on the play situation of the game on the player terminal 1. For example, the motivation to participate in the multi-play is reduced during a short period of movement or immediately after the multi-play is finished. As described above, if the player participates in the multiplayer with a low willingness to participate in the multiplayer, the cooperative play may not be performed.

In the present embodiment, the invitation information is received according to the playing status 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 play situation of the game on the player terminal 1. That is, when there is a high possibility that the player will not participate in the multiplayer, the player terminal 1 does not receive the invitation information in the first place. As a result, the possibility that a player whose participation will be reduced will participate in the multiplayer is reduced. Moreover, since the invitation information is not received many times in a state where the player cannot 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 confirmation of the invitation information is performed every 15 seconds. However, on the display 26, when the normal screen (screens other than the battle screen) transits to the battle screen, the timing for first confirming the reception of the invitation information after the screen transition is randomly selected by lottery within 1 to 15 seconds. It is determined.

Further, when the normal screen (screen other than the battle screen) is displayed on the display 26 of the player terminal 1, the reception confirmation of the invitation information is performed at intervals of 10 seconds. However, on the display 26, when the battle screen is changed to the normal screen, the normal screen is changed to another normal screen, or the page is changed in the normal screen, the invitation information is first received after the screen change. The confirmation timing is randomly determined by lottery within 1 to 10 seconds.

As described above, by randomly determining the timing of first 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. As a result, unnecessary communication with the server 100 is suppressed, and the load on the server 100 is reduced.

Further, during the display of the battle screen, the interval for confirming reception of invitation information is set longer than during the display of the normal screen. As a result, the execution of unnecessary battle games for the purpose of receiving the invitation information is suppressed, and the increase in load on the server 100 can be suppressed.

Next, a communication process of the player terminal 1 and the server 100 for executing the above multi-play will be described. In addition, here, an example of a basic communication process for advancing a game and an example of a main communication process regarding multi-play will be described, and description of other processes will be omitted.

(Communication process 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 process in the player terminal 1 is indicated as Pn (n is an arbitrary integer). In addition, the process in the server 100 is represented as Sn (n is an arbitrary integer). When the player activates 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 the login process (S1). Here, the server 100 allows 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 permitted state, the player terminal 1 confirms the reception of the invitation information every predetermined time (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 manner to notify that the invitation information has been received (P3).

Further, in the player terminal 1, 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 the party information selected by the player, the battle game type information, and the like. The server 100 performs the battle game start processing required to start the battle game by inputting the start information (S3). Here, for example, an area of the memory 112 for proceeding 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. Further, the server 100 sets the player terminal 1 so that the player terminal 1 can receive the data necessary for executing the battle game.

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

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

Further, in the update processing, the update information is transmitted and received between the player terminal 1 and the server 100. Here, the update processing and the transmission/reception of the update information are executed in frame units, but the update processing and the transmission/reception of the update information may be executed in a shorter cycle or a longer cycle than in the frame unit. Also during the single-player battle game, confirmation of reception of invitation information in the player terminal 1 (P7), retrieval of invitation information in the server 100 (S5), and notification of reception of invitation information in the player terminal 1 (P8) are regularly performed. Can be executed. Then, when the ending condition of the battle game is satisfied, an ending process of ending the battle game is performed in each of the player terminal 1 and the server 100 (P9, S6). In the ending process (P9) of the player terminal 1, for example, a result screen is displayed on the display 26. Further, in the ending process (S6) of the server 100, various 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 processing of the player terminal 1 and the server 100 when multiplay is executed. In the following description, the processing in the host terminal is shown as HPn (n is an arbitrary integer), and the processing in the subject terminal and the guest terminal is shown as GPn (n is an arbitrary integer).

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

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

Further, when the server 100 receives the request information, the server 100 performs a room setting process of creating and setting a room (S10). Here, a processing area for executing multi-play, that is, a room is secured, and various information included in the request information is stored in this room. Also, 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 the 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. After that, when the subject terminal confirms the reception of the invitation information (GP10), the reception confirmation information is transmitted to the server 100. When the server 100 receives 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”. In addition, the server 100 performs point update processing, and subtracts “4” from the priority points of the subject who received the invitation information.

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

After that, when the participation tab 52a of the invitation information dialog 52 is tapped on the target terminal, the target information is transmitted from the target terminal to the server 100 (GP15). The participation information includes information about the party set by the target person. Upon receiving the participation information, the server 100 determines whether the room can be entered, and if the room can be entered, updates the room information (S13). Here, the server 100 is set so that the updated room information (room update information) is received by the host terminal and the subject terminal.

Although only one target person terminal (guest terminal) is shown in FIG. 16, the same process is performed by a plurality of target person terminals (guest terminals) for one room. Therefore, when any of the target person terminals enters the room, the player terminals 1 of all the players who are in 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 terminal also receives the room update information. Note that, 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 status to the participation status (GP16) and displays the room detail page on the display 26 (GP17).

After that, when the start tab 50 of the room detail page is tapped on the host terminal and a multiplay start operation is input (HP13), the start information is transmitted to the server 100. In the server 100, point update processing is performed by inputting start information. Here, the priority point of the host player is incremented by "1".

Then, in the host terminal, the server 100, and the guest terminal, the above-mentioned battle game start processing (not shown) is performed, respectively, and thereafter, the multi-play control processing for controlling the multi-play is concurrently performed (HP14, S14, GP18). In this multi-play control process, the update process for updating various information is repeatedly executed in frame units. In this update process, update information is transmitted and received among the host terminal, guest terminal, and server 100. When the ending condition of the battle game is satisfied, the ending process of ending the battle game is performed in each of the host terminal, the guest terminal, and the server 100 (HP15, S15, GP19).

At the end of the multi-play, the server 100 calculates the damage given during the total damage for each player who participated in the multi-play (S16). Then, the point update processing is performed based on the calculated damage caused. Here, “3” is added to the priority points for the player who is dealt 20% or more of the total damage. On the other hand, in the guest terminal, the play state is updated to the unacceptable state at the end of the multi-play (GP20). After that, in the guest terminal, when the predetermined time has elapsed, the play state is updated to the receivable state (GP21).

FIG. 17 is a sequence diagram illustrating processing of the player terminal 1 and the server 100 when the player cannot participate in the multi-play. Note that, in FIG. 17, the processing until the participation information is input from the target person terminal is the same as that in FIG. 16, and thus the description thereof will be omitted. As described above, when the server 100 receives the participation information, the server 100 determines whether it is possible to enter the room. At this time, if it is impossible to enter the room, the server 100 sets participation impossible information indicating that the room cannot be entered. In addition, at this time, the server 100 performs a point update process to add “4” to the priority points of the target person.

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

FIG. 18 is a sequence diagram illustrating the processing of the player terminal 1 and the server 100 when the participation in the multiplayer is rejected. Note that, in FIG. 18, the processing up to the input of the refusal information from the subject terminal is the same as that in FIG. When the rejection tab 52b of the invitation information dialog 52 is tapped on the subject terminal, the rejection information is transmitted from the subject terminal to the server 100 (GP24). In addition, the play state is updated to the unreceivable state in the subject terminal (GP25).

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

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

(Functional configuration of the 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 is provided with 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 multi-play or before the start of multi-play.

The terminal-side game control program includes 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, and a timing. A program 74 is included. Note that the programs listed in FIG. 19 are merely examples, and the terminal-side game control program is provided with many other programs.

The data storage area 12b is provided with a game information storage section 80, a play state storage section 82, and an invitation information storage section 84 as storage sections for storing data. Note that each of the above storage units is an example, and a large number of storage units other than this are provided in the data storage area 12b.

The CPU 10 operates each program stored in the program storage area 12a and updates the data in each storage unit of 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 time measurement unit. 74a is included.

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 unit 62a. , Request information transmitting unit 64a, play state updating unit 66a, invitation information receiving unit 68a, invitation information notifying unit 70a, operation permitting unit 72a, and timer unit 74a.

The game execution unit 60a controls the progress of games other than the battle game, such as the formation of parties and the strengthening of teammate characters, based on the operation of the player. The game execution unit 60a transmits information corresponding to an operation to the server 100 each time an operation is input to the player terminal 1. Moreover, the game execution part 60a updates the information of the game information storage part 80, when the information (game information) regarding a game is updated.

The battle game execution unit 62a is responsible for 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, the battle game execution unit 62a executes single play or multi-play with another player terminal 1 when a predetermined start condition is satisfied. Further, the battle game execution unit 62a updates the information in the game information storage unit 80 when the battle game ends normally.

When one of the follower tabs 48a, the mutual follower tabs 48b, and the random tabs 48c is tapped, the request information sending unit 64a sends a request signal corresponding to the operation unit to the server 100.

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

The invitation information receiving unit 68a confirms the reception of the invitation information at the timing set for each screen displayed on the display 26 when the play state is the permitted state. Specifically, the invitation information receiving unit 68a transmits the 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 notification unit 70a switches the notification image 34 between the notification mode and the non-report mode based on whether or not the invitation information is stored in the invitation information storage unit 84, that is, whether or not the invitation information is received.

The operation permission unit 72a displays the invitation information dialog 52 when the notification image 34 is tapped, and enables the player to input the participation operation, the refusal operation, and the hold operation. Specifically, when the notification image 34 displayed in the notification mode is tapped, the server 100 is confirmed whether or not there is a room corresponding to the received invitation information. When the room exists, the operation permission unit 72a displays the invitation information dialog 52 (FIG. 6C, FIG. 7A, FIG. 7C) on the display 26. That is, by displaying the participation tab 52a, the refusal tab 52b, and the hold tab 52c so that they can be tapped, the participation operation that wants to participate in the multiplayer, the refusal operation for rejecting the participation in the multiplay, and the participation in the multiplay are suspended. It is possible to input the hold operation to be put into the status.

The timer unit 74a measures a prohibition time, a reception waiting time, and a refusal time, which will be described later.

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

FIG. 21 is a flowchart illustrating an example of room creation-related processing 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 the requested operation is input (YES in P110-2), the request information transmission unit 64a makes 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, when the terminal side game control unit 1A receives the room setting information (YES in P110-5), it displays the room detail page on the display 26 (P110-6). Further, when the terminal side game control unit 1A receives the room update information (YES in P110-7), the display of the room detail page is updated 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 section 1A transmits start information to the server 100 (P110-10), and multiplay is started. It waits until (P110-11). When the multiplayer can be started, the battle game is controlled by the multiplayer in the battle game execution process (P101).

FIG. 22 is a flowchart illustrating an example of invitation information reception processing in the player terminal 1. When the screen of the display 26 transitions (YES in P120-1), the timer unit 74a confirms the screen currently displayed on the display 26 (P120-7) and determines the initial counter value by lottery (P120-8). It should be noted that the initial counter value indicates an interval of confirmation of reception of 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 changed (NO in P120-1) and the play state stored in the invitation information storage unit 84 is the unacceptable state (NO in P120-2, P120-3). YES), the clock unit 74a decrements the counter value of the inhibition time counter (P120-4). As will be described later in detail, when a refusal operation is performed, a predetermined counter value is set in the inhibition time counter. That is, the prohibition time counter counts the elapsed time after the refusal operation is input. When the counter value of the prohibited time counter is updated to 0 (YES in P120-5), the play state updating unit 66a updates the play state in the play state storage unit 82 to the receivable state (P120-6).

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

Moreover, when the screen of the display 26 has not changed (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 unit 74a decrements the counter value of the reception standby counter (P120-10). Then, when the count value of the reception standby counter becomes 0 (YES in P120-11), the timer unit 74a resets the reception standby counter to the initial counter value stored in the initial value storage unit. The invitation information receiving unit 68a also executes the 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). If the invitation information that can be received (not received) 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 the invitation information storage unit 68a. It stores in 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). Further, the invitation information notification unit 70a displays the notification image 34 in the notification mode in the header display area 30 (P121-5).

FIG. 24 is a first flowchart illustrating an example of the post-invitation information reception process in the player terminal 1. FIG. 25 is a second flowchart illustrating an example of the post-invitation information reception processing in the player terminal 1. When the notification image 34 is tapped while the invitation information is stored in the invitation information storage unit 84 (YES in P130-1) (YES in P130-2), the invitation information receiving unit 68a causes the display 26 to display the invitation information. 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 open information to the server 100 (P130-5). Further, the play state updating unit 66a updates the play state to the opened state (P130-6).

In addition, when the participation information is stored in the invitation information storage unit 84 and the participation tab 52a is tapped and the participation operation is input while the invitation information dialog 52 is displayed (YES in P130-1, P130-1). -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). After that, the invitation information receiving unit 68a waits until the room update information or the participation impossible information is received (P130-10). When the room update information is received from the server 100 (YES in P130-11), the play status updating unit 66a updates the play status to the participation status (P130-12), and the invitation information receiving unit 68a causes the display 26 to display. A room detail page is displayed on the screen (P130-13). Further, here, the invitation information receiving unit 68a switches the notification image 34 to the 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-disabled screen on the display 26 (P130-14), and the invitation information storage unit. The invitation information is deleted from 84 (P130-15). Further, the invitation information notification 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 the receivable state (P130-17).

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

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

When the counter value of the refusal time counter is 0 (YES in P130-24), that is, when 30 minutes have elapsed since the last refusal operation was input, the timekeeping unit 74a displays 5 in the prohibition time counter. A counter value corresponding to minutes 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 refusal operation was last input, the timekeeping unit 74a displays the prohibition time counter. , A counter value corresponding to 60 minutes is set (P130-26). Further, the timer unit 74a sets a counter value of 5 minutes or 60 minutes to the inhibition time counter and then sets a counter value corresponding to 30 minutes to the refusal time counter (P130-27).

According to the above process, the operation permission unit 72a displays the invitation information dialog 52 at the time of notification of the reception of the invitation information or after the notification (P130-3), thereby denying the participation in the multiplayer. Input is enabled. After the refusal operation is input, the play state is maintained in the unreceivable state for 5 minutes (second time) or 60 minutes (second time), and after 5 minutes or 60 minutes has passed, the play state is changed. It is updated to the receivable state (P120-6). If the refusal operation is performed twice within 30 minutes, the invitation information will not be received for 60 minutes after the second refusal operation.

If the hold information is stored in the invitation information storage unit 84 and the hold information 52 is displayed and the hold tab 52c is tapped to enter a hold operation (YES in P130-1, P130). -2, NO in P130-7, NO in P130-8, NO in P130-18, YES in 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 a multi-play ending process in the player terminal 1. When the multiplayer 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 the multi-play as the guest player (YES in P140-3), the invitation information receiving unit 68a erases the invitation information from the invitation information storage unit 84 (P140-4). Further, the play state updating unit 66a updates the play state to the unreceivable state (P140-5), and the invitation information receiving unit 68a sets the counter value corresponding to 5 minutes in the prohibited time counter (P140-6). .. According to this multi-play end processing, the play state is maintained in the unreceivable state for 5 minutes (first time) after the end of the multi-play participating as the guest player.

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

(Functional configuration of the 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 multi-play or before the start of multi-play.

The server-side game control program includes 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 merely examples, and the server-side game control program includes many other programs.

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

The CPU 110 operates each program stored in the program storage area 112a to update the data in each storage unit of 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 update program 140 and causes the computer to function as the player information update 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 accumulated in the player information storage unit 160 every time communication is made with the player terminal 1. Further, the player information updating unit 140a performs a point updating process of updating the priority points in the player information storage unit 160.

The list updating 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 of replacing the storage area in which the player information is stored. The list updating unit 142a also 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 the games including the battle game based on the 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 game information storage unit 164 for each player in the multi-play. 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 processing 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). In addition, the player information update unit 140a updates the player information in the player information storage unit 160 based on the information input from the player terminal 1. Further, the server-side game control unit 100A executes request information reception processing (S110), information update processing (S120), multi-play end processing (P130), and rearrangement processing (S140) in the server-side game processing.

FIG. 29 is a flowchart illustrating an example of request information reception processing in the server 100. When the follower is selected as the person to be invited to the room, that is, when the request information for the follower tab 48a is received (YES in S110-1, YES in S110-2), the terminal setting unit 144a displays Invitation information, a status flag, and a counter value of a weight counter (hereinafter, referred to as "invitation information or the like") are set in the follower storage area (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), terminal setting. The unit 144a sets the invitation information and the like in the mutual follower storage area in the extraction list (S110-5).

It should be noted that when the invitation information is set in the follower or the mutual follower, it is not essential to set the counter value of the weight counter. That is, when followers or mutual followers are set as the target persons, all the target persons may be able to receive the invitation information at the same time. In addition, the counter value of the weight counter may be set based on the priority points, as in the case where the target person is randomly set.

When it is selected to randomly extract the target person 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). The terminal setting unit 144a sets invitation information and the like in the storage area of the top 100 names whose reception status is "settable", that is, the status flag is blank in the extraction list (S110-6).

When the target person is randomly set, 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). If 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 related to the host player is stored in the room based on the request information. In addition, here, the server-side game control unit 100A sets the room information so that the host terminal can receive the room information. 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 request information (S110-9).

FIG. 30 is a flowchart illustrating an example of information update processing in the server 100. When the reception confirmation information is received from the player terminal 1 (YES in S120-1), the server-side game control section 100A searches the extraction list to see if the invitation information for this 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 "receivable" (YES in S120-4), the server-side game control unit 100A determines. Invitation information output processing is performed (S120-5). Here, the invitation information is set to be receivable by the player terminal 1 that 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 updating unit 142a updates the reception status (status flag) of the subject terminal to "received" in the extraction list.

When the opening information is received 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”. Add (S120-9).

In addition, 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 determines 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 room update information output processing. Here, the server-side game control unit 100A sets the room update information so that it can be received 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 the player cannot 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). ). In addition, 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 multi-player battle game (S120-18).

FIG. 31 is a flowchart illustrating an example of multi-play end processing in the server 100. In the battle game execution process (S100), if the multiplayer ends normally except during the midway termination (retirement) (YES in S130-1 and NO in S130-2), the server-side game control unit 100A causes the total damage to be 20. % Or more players are identified (S130-3). In addition, in the battle game execution process (S100), the damage done for each player is stored in the game information storage unit 164 at the time of executing the multi-play.

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

FIG. 32 is a flowchart illustrating an example of rearrangement processing in the server 100. The list update 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). Further, 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). As a result, the priority of the player is updated based on the priority points.

The list update unit 142a also performs list information update processing 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 from “unreceivable” to “receivable” for the storage area whose counter value has been updated to 0. Further, 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 finished, the room is disbanded, or a predetermined time has elapsed since the invitation information was set. ..

As described above, the player terminal 1 is provided with a program that executes multiplay as a host terminal and a program that executes multiplay as a guest terminal. Then, the player terminal 1 functions as a request information transmission 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 multiplayer via the server 100 which is an external device. However, the external device is not limited to the server 100. For example, the player terminal 1 may include the above-described functions of the server 100, and any one of the player terminals 1 may function as an external device.

The player terminal 1 also functions as a play state updating unit 66a (state updating unit) that updates the play state based on the play state of the game. Although five play states are provided in the present embodiment, 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 changed 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 is not received.

Further, in the present embodiment, the play state is set and updated based on the play status of the game and the presence/absence of reception of invitation information. However, the play status update unit 66a may be updated based on at least the play status of the game.

Also, the player terminal 1 functions as an invitation information receiving unit 68a (reception 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 upon confirmation of 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 server 100 transmits the invitation information to the target person terminal. At this time, if the play state of the subject terminal is the permitted state, the invitation information may be received, and if the play state is the impossible state, the invitation information may be rejected. In any case, the invitation information receiving unit 68a may receive the invitation information from the server 100 (external device) when the play state is the permitted state, and the process or method thereof is not limited.

The player terminal 1 also functions as an invitation information notification unit 70a (notification unit) that notifies reception of invitation information. In the present embodiment, the invitation information notification unit 70a switches the display mode of the notification image 34 to notify reception of the invitation information. 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 notification unit 70a may notify the reception of the invitation information at the time of receiving the invitation information or after the reception of the invitation information, and the mode of notification can be appropriately designed.

The player terminal 1 also functions as an operation permission unit 72a that enables input of participation operation. In the present embodiment, the operation permission unit 72a provides a participation tab 52a, a rejection tab 52b, and a hold tab 52c in the invitation information dialog 52 to enable input of a participation operation, a rejection operation, and a hold operation. However, the operation permission unit 72a only needs to be able to input the participation operation, the refusal operation, and the hold operation, and the method or process thereof can be appropriately designed. Further, the operation permission unit 72a is only required to be able to input the participation operation, and it is not essential to accept the refusal operation and the hold operation. In any case, the operation permission unit 72a only needs to be able to input a predetermined participation operation when 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 a multi-play (communication game) with another player terminal 1. The content of the game in this embodiment is only 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 a game in which a plurality of players cooperate, or a game in which a plurality of players compete with each other. In any case, the game execution unit 60a broadly includes those that execute 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 are the same. 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 invitation information is confirmed to be received based on the above five play states. Further, the player terminal 1 functions as a notification enable/disable state setting unit that sets a notification enable/disable state separately from the play state. As the notification enable/disable state, for example, a notification possible state and a notification impossible state are provided.

The notification enable/disable state setting unit switches the notification enable/disable state based on, for example, a screen transition displayed on the display 26. Specifically, the notification permission/inhibition state setting unit sets the notification permission/inhibition state to the notification permission state when the notification image 34 in the notification mode or the screen in which the invitation information dialog 52 may be displayed. On the other hand, the notification permission/inhibition state setting unit sets the notification permission/inhibition state to the notification impossible state when the notification image 34 in the notification mode or the screen in which the invitation information dialog 52 is not displayed.

Then, when the invitation information notification unit 70a receives the invitation information, the invitation information notification unit 70a confirms the notification enable/disable state, and if the notification information is available, displays the notification image 34 of the notification mode or the invitation information dialog 52 on the display 26. On the other hand, when the notification enable/disable state is the notification impossible 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 notification unit 70a confirms the notification availability state at a predetermined timing such as when the screen changes, and if it is in the notification possible state, at that point, the notification image 34 of the notification mode or the invitation information. The dialog 52 is displayed.

As described above, the play state in which the acceptance of the invitation information is defined and the notification availability state in which the acceptance notification of the invitation information is defined may be provided. Further, 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.

Furthermore, the play state may define reception notification of invitation information. That is, the invitation information notification unit 70a may notify reception of the invitation information when the invitation information is received or after the invitation information is received. This modification will be described with reference to the drawings.

(Modification)
FIG. 33 is a flowchart illustrating an example of a modified invitation information reception process in the player terminal 1. The invitation information reception process of this modification is executed instead of the invitation information reception process of the above embodiment. Although detailed description is omitted, when the invitation information reception process of the modified example is executed, some processes are added or changed in the post-invitation information reception process and the multi-play end process of the above embodiment.

The invitation information notification unit 70a determines whether the screen displayed on the display 26 is a screen that can notify reception of the invitation information (P150-1). It should be noted that whether or not the reception of the invitation information can be notified is preset for each screen. When the screen has changed to a screen in which the reception of the invitation information cannot be notified (NO in P150-1), the play state updating unit 66a sets the play state in the play state storage unit 82 to the impossible state (P150-2).

On the other hand, when the screen being displayed on the display 26 is a screen capable of notifying the reception of the invitation information (YES in P150-1), the play state updating unit 66a sets the play state to the permitted state (P150-3). .. At this time, if uninformed (not notified of reception) invitation information is stored in the invitation information storage unit 84 (YES in P150-4), the invitation information notification unit 70a notifies the notification image 34 in the notification mode. Display (P150-5).

Further, the invitation information receiving unit 68a transmits the reception confirmation information to the server 100 (P150-6) and waits until the 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 notification unit 70a displays the notification image 34 in the notification mode (P150-11).

According to the above modification, the player terminal 1 receives the invitation information regardless of the play status (play status) of the game. Then, when the invitation information is received or after the invitation information is received and the play state is the permitted state, the invitation information notification unit 70a notifies the reception of the invitation information. This modification also achieves the same effects as the above embodiment.

In the above-described embodiment, the play state updating unit 66a sets the play state to the state where the invitation information cannot be received for 5 minutes (first time) after the end of the multiplayer (communication game). And Also in the modified example, the play state updating unit 66a sets the play state to the state of being unable to notify the reception of the invitation information for a predetermined time (first time) after the end of the multiplay (communication game). May be

Further, in the above-described embodiment, the play state updating unit 66a indicates that the play state is not received for 5 minutes (second time) or 60 minutes (second time) after the input of the refusal operation. Make it impossible. In the modification as well, the play state updating unit 66a may set the play state to the impossible state in which the notification of the reception of the invitation information is disabled for a predetermined time (second time) after the input of the refusal operation. ..

In addition, the server 100 accumulates predetermined player information in the player information storage unit 160 (storage unit) for each player, and updates the priority points (priority information) for each player according to preset update conditions. Function as a player information updating unit 140a (accumulation unit, updating unit). The update condition of the priority point can be designed as appropriate. Moreover, the priority point is merely an example of the priority information. For example, the playing 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 addition, in the above embodiment, the player information update unit 140a updates the priority points based on the ratio of damage in the multiplayer. That is, the player information update unit 140a updates the priority points (priority information) based on a predetermined result in the multiplayer (communication game). In this case, for example, the priority points may be updated based on the existence or nonexistence of the player character at the end of the multi-play, instead of the damage ratio. Further, for example, points obtained by multiplying the damage done by a predetermined coefficient may be added to or subtracted from the priority points. In any case, when the priority information is updated based on a predetermined result in the multi-play (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.

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

In addition, when the server 100 receives the request information from the player terminal 1, at least based on the priority points (priority information), the server 100 sets the plurality of player terminals 1 as the target person terminals (extraction terminals) that can receive the invitation information. It functions as a possible terminal setting unit 144a (setting unit). In the above embodiment, the terminal setting unit 144a may set the follower or the mutual follower to 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 regardless of the priority points. When the priority information is set for each player, the terminal setting unit 144a may set the subject terminal based on at least the priority information.

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

Further, the above-mentioned division of roles in the player terminal 1 and the server 100 is merely an example. In the above-described embodiment and modification, the play state is stored and updated in the player terminal 1. That is, in the above-described embodiment and modification, the player terminal 1 functions as the play state updating unit 66a (state updating unit). However, the play state may be stored and updated in the server 100.

The second embodiment in which the server 100 functions as a status updating unit (server-side status updating unit) will be described below. Note that, 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 the function of the 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 unit 67a.

The play state transmission unit 67a transmits the play state (play state information) in the player terminal 1 to the server 100. In the second embodiment, the play state is set and updated in the player terminal 1 as in the above embodiment. At this time, the setting condition for setting the play state may be the same as or different from that in the above embodiment. Further, here, it is assumed that the play state is stored in the play state storage unit 82, but the player terminal 1 does not have to store and update the play state. 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 status transmitting unit 67a transmits the play status information can be appropriately designed. For example, when the play state changes, the play state transmitting unit 67a transmits the 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 it communicates with the server 100.

In addition, in the second embodiment, as in the above-described embodiment, the play state is set to “receivable state”, “unopened state”, “opened state”, “participation state”, or “receivable state”. Two states shall be provided (see FIG. 14A). Therefore, the play state transmitting unit 67a transmits to the server 100 five types of play state information that are distinguishable from each other. However, in the second embodiment, the play state may be different from that in 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 the function as a computer. In the second embodiment, the server-side game control program further includes a play status reception program 147 and a play status update program 149 in addition to the above programs. Then, the CPU 110 operates the play state reception program 147 to function as the play state reception unit 147a. In addition, the CPU 110 operates the play status update program 149 to function as the play status update unit 149a.

The play state receiving unit 147a receives the 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. The play state may be stored in the player information storage unit 160 or the extraction list storage unit 162. Further, in addition to the player information storage unit 160 and the extraction list storage unit 162, a dedicated storage unit for storing the play state for each player terminal 1 may be provided in the data storage area 112b. In the second embodiment, as an example, a case where 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”, “not receivable”, and “received” are provided. Of these, the “permitted state” and the “impossible state” are provided in place of the “settable (blank)” in the above-described embodiment, and the “receivable”, “not receivable”, and “received” are the above-mentioned It is the 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 game execution on the server 100, and the management status.

The list update unit 142a sets the status flag of the extraction list to the “permitted state” for the player terminal 1 in which the player information storage unit 160 stores the play state of “acceptable state” or “unopened state”. In addition, the list update unit 142a sets the status flag of the extraction list to “for the player terminal 1 in which the player information storage unit 160 stores the play statuses of “opened status”, “participation status”, and “receivable status”. Impossible state".

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

Below, an example of processing of the player terminal 1 and the server 100 in 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 status is updated in the player terminal 1 (P201), the play status information is transmitted to the server 100. When the play status receiving unit 147a receives the play status information, the play status updating unit 149a updates the play status in the player information storage unit 160 (S201). Further, the list update 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 processing of the player terminal 1 and the server 100 according to the second embodiment. When the battle game control process by multiplayer is completed in the player terminal 1 and the server 100 (P205, S205), the play state update unit 149a updates the play state in the player information storage unit 160 to the "unacceptable state" (S206). .. Further, the list updating unit 142a updates the status flag of the extraction list to the "impossible state" for the players (at least one of the host player and the guest player) who participated in the multi-play (S207). At this time, the list updating unit 142a sets the wait counter to the first time as the wait time (S208).

FIG. 36C is a third sequence diagram illustrating the processing of the player terminal 1 and the server 100 according to the second embodiment. When a refusal operation is input on the player terminal 1 (P210), refusal information is transmitted to the server 100. When the refusal information is received, the play state updating unit 149a updates the play state in the player information storage unit 160 to the "unreceivable 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 updating unit 142a sets the second time as the wait time in the wait counter (S212).

Although detailed description is omitted, when the first time or the second time described above elapses, in the list information update processing (see FIG. 32), the list update unit 142a determines the play state of the player information storage unit 160. Check. At this time, if the play state is the “receivable state” or the “unopened state”, the list update unit 142a updates the status flag to the “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 updating unit 149a (state updating unit). The play state updating unit 149a updates the play state of the player terminal 1 based on the 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 playing status of the game on the player terminal 1.

In addition, in the second embodiment, the terminal setting unit 144a (setting unit), for the player terminal 1 in which the multi-play (communication game) is executed, at least until the first time elapses after the communication game ends. , Do not set it in the subject terminal (extraction terminal). In addition, the terminal setting unit 144a (setting unit) receives at least the second time for the player terminal 1 to which the refusal information indicating refusal to participate in the multiplayer (communication game) is transmitted after receiving the invitation information. Is not set in the subject terminal (extracting 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 the information received from the player terminal 1. In addition, the above-described modified example can also be applied to the second embodiment.

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

In addition, in the above-described embodiment, in addition to the play state being updated in the player terminal 1, the server 100 may also update the login state as the play state. 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 status of the game, that is, the play status, may be managed by the player terminal 1, the server 100, or both the player terminal 1 and the server 100. May be done. However, by managing the play state on the player terminal 1, the processing load on the server 100 is reduced. On the other hand, when the server 100 manages the play state, the server 100 can recognize the player terminal 1 that can immediately receive the invitation information or notify the reception of the invitation information. Therefore, only the player terminal 1 that can immediately receive the invitation information or notify the reception of the invitation information can be set as the target terminal. As a result, multiplayer can be started earlier.

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

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 this storage medium. Further, the above-described embodiments and modified examples may be information processing methods that realize each function and the steps shown in the flowcharts.

Although one aspect of the embodiment has been described with reference to the accompanying drawings, it goes without saying that the present invention is not limited to the above-described embodiment and modifications. It is obvious to those skilled in the art that various modifications and alterations can be conceived within the scope of the claims, and it is understood that these also belong to the technical scope of the present invention. To be 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 panel)
60a Game execution unit 64a Request information transmission unit 66a Play state update unit (state update unit)
68a Invitation information receiver (receiver)
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)

A request information transmission unit that transmits request information to an external device by inputting a required operation from the operation unit,
At least a status update unit that updates the play status based on the game play status,
A receiving unit that can receive invitation information from the external device when the play state is a permitted state,
A notification unit that notifies the reception of the invitation information when or after the reception of the invitation information,
At the time of notification of reception of the invitation information or after notification, an operation permission unit that enables 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 a communication game with another player terminal,
An information processing program that causes a computer to function. A request information transmission unit that transmits request information to an external device by inputting a required operation from the operation unit,
At least a status update unit that updates the play status based on the game play status,
A receiving unit capable of receiving invitation information from the external device,
At the time of receiving the invitation information or after the reception, when the play state is a permission state, a notification unit for notifying the reception of the invitation information,
At the time of notification of reception of the invitation information or after notification, an operation permission unit that enables 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 a communication game with another player terminal,
An information processing program that causes a computer to function. The state update unit sets the play state to an impossible state in which reception of the invitation information or notification of reception of the invitation information is disabled for a first time period after the end of the communication game. The information processing program according to item 1 or 2. The operation permission unit enables input of a refusal operation for refusing to participate in the communication game at or after notification of reception of the invitation information,
The state update unit sets the play state to an impossible state in which the reception of the invitation information or the notification of the reception of the invitation information is disabled for a second time after the input of the refusal operation. The information processing program according to any one of claims 1 to 3. The operation permission unit enables input of a predetermined hold operation when or after notification of reception of the invitation information,
The notification unit continues the notification when the holding operation is input, and ends the notification when the participation impossible information that can be received when the participation in the communication game becomes impossible is received. The information processing program according to any one of 1 to 4. A game terminal device including a storage medium in which the information processing program according to any one of claims 1 to 5 is stored. A storage unit that stores predetermined player information in the storage unit for each player,
A state update unit for updating the play state based on at least the play state of the game on the player terminal;
A request information transmission unit that transmits request information by inputting a required operation on the operation unit of the player terminal;
A setting unit that, upon receiving the request information from the player terminal, sets a plurality of player terminals as extraction terminals capable of receiving invitation information, based on at least the player information accumulated in the storage unit;
In an extraction terminal in which the play state is a permitted state, a receiving unit that can receive the invitation information,
A notification unit that notifies the reception of the invitation information when or after the reception of the invitation information,
At the time of notification of reception of the invitation information or after notification, an operation permission unit that enables input of a predetermined participation operation,
A game execution unit that executes a communication game between any one or a plurality of extraction terminals to which participation information has been transmitted based on the input of the participation operation and a player terminal that has transmitted the request information;
An information processing system including. A storage unit that stores predetermined player information in the storage unit for each player,
A state update unit for updating the play state based on at least the play state of the game on the player terminal;
A request information transmission unit that transmits request information by inputting a required operation on the operation unit of the player terminal;
When receiving the request information from the player terminal, based on at least the player information accumulated in the storage unit, a setting unit that sets a plurality of player terminals as extraction terminals that can receive invitation information,
In the extraction terminal, a receiving unit capable of receiving the invitation information,
In the extraction terminal at the time of receiving the invitation information or after the reception, when the play state is a permission state, a notification unit for notifying the reception of the invitation information,
At the time of notification of reception of the invitation information or after notification, an operation permission unit that enables input of a predetermined participation operation,
A game execution unit that executes a communication game between any one or a plurality of extraction terminals to which participation information has been transmitted based on the input of the participation operation and a player terminal that has transmitted the request information;
An information processing system including.

Images