JP6790180B2 - Game control methods, computers and control programs - Google Patents

Description

The present invention relates to game control methods, computers and control programs.

In recent years, servers that provide games to mobile terminals via communication networks have become widespread. As a game provided by such a server, a game in which a plurality of players can participate (so-called "social game") is known. The game provided as a social game includes a so-called RAID battle in which a plurality of players participate and fight against a common enemy character.

For example, Patent Document 1 describes a server system that executes an online game in which a plurality of players participate and a common event for defeating a common enemy character is activated. In this server system, a player who has already obtained the right to participate in a common event requests another player to participate in the common event, and the other player who receives the participation request has an event activation condition in his / her main game. Get the right to participate in common events even if you do not meet the above requirements.

Japanese Unexamined Patent Publication No. 2014-140557

In the server system of Patent Document 1, a player who has obtained the right to participate in a common event requests another player to participate in the common event, so that a common event in which a plurality of players participate is carried out. However, players of various levels participate in online games. Therefore, in a common event, only strong players may participate and easily defeat the enemy character, and conversely, only weak players may participate and cannot defeat the enemy character, which may cause the game balance to be lost. There is.

The present invention has been made to solve such a problem, and provides a game control method, a computer, and a control program capable of appropriately maintaining a game balance in a competitive game in which a plurality of players participate. The purpose is.

The game control method according to the present invention is a game control method in a computer having a storage unit and executing a battle game, and a plurality of setting values set for each player are stored in the storage unit for each of a plurality of players. Start a match between a specific player's game medium and an enemy game medium according to a request from a specific player among the specific players, and play against another player among a plurality of players according to a request from the specific player. This includes notifying the participation request of the player and accepting the participation of other players in the match within the range in which the total of the set values set for each player participating in the match does not exceed the predetermined upper limit value.
The computer may be a mobile terminal, a stationary terminal, a server, or the like as long as the above procedure can be executed.

Further, in the game control method according to the present invention, it is preferable that the set value is set to a smaller value as the strength of each player in the competitive game is higher.

Further, in the game control method according to the present invention, the strength of each player is the parameters of the game medium owned by each player, the items owned by each player, the number of times each player has participated in the battle, and the past battle game. It is preferable that the determination is based on at least one of the results of each player in.

Further, in the game control method according to the present invention, it is preferable that a predetermined upper limit value is set according to at least one of the parameters of the enemy game medium and the parameters of the game medium of a specific player.

Further, in the game control method according to the present invention, it is preferable that the predetermined upper limit value is changed according to the passage of time from the start of the battle.

Further, in the game control method according to the present invention, the computer further has a communication unit, and further, information relating to each battle in which the participation request is notified to the player is transmitted to the terminal of the player to which the participation request is notified. , The remaining physical strength of the enemy game medium of each battle, the remaining time of each battle, and the display data for displaying in order based on at least one of the rewards obtained in each battle are transmitted via the communication unit. Is preferable.

The computer according to the present invention is a computer that executes a battle game, and is a storage unit that stores setting values set for each player for each of a plurality of players, and a request from a specific player among the plurality of players. According to the battle execution unit that starts the battle between the game medium of the specific player and the enemy game medium, and the participation that notifies the other player among the plurality of players of the participation request to the battle according to the request from the specific player. It includes a request notification unit and a participation reception unit that accepts participation of other players in the battle within a range in which the total of the set values set for each player participating in the battle does not exceed a predetermined upper limit value.

The control program according to the present invention is a control program of a computer having a storage unit and executing a battle game, and stores the set value set for each player in the storage unit for each of a plurality of players, and a plurality of players. Start a match between a specific player's game medium and an enemy game medium according to a request from a specific player, and participate in a match with another player among a plurality of players according to a request from a specific player. The request is notified, and the computer is made to accept the participation of other players in the battle within the range where the total of the set values set for each player participating in the battle does not exceed the predetermined upper limit value.
Further, the game control method according to the present invention is a game control method in a computer having a storage unit and executing a battle game, and is used for each of a plurality of players according to the strength of each player in the battle game. The set value set in the above is stored in the storage unit, a battle between the game medium of the specific player and the enemy game medium is started according to a request from a specific player among the plurality of players, and the result of the battle is determined. After that, according to the request from a specific player specified for the screen displayed according to the result of the battle, the other players among the multiple players are notified of the request to participate in the battle and participate in the battle. The first set value sets the predetermined upper limit value, including accepting participation in the battle of other players within the range where the total of the set values set for each player does not exceed the predetermined upper limit value. With the maximum number of players participating in the battle being accepted, it is set so that the player who has a second set value smaller than the first set value can be accepted to participate in the battle.
Further, the computer according to the present invention is a computer that executes a battle game, and is a storage unit that stores a set value set for each of a plurality of players according to the strength of each player in the battle game. And, according to the request from a specific player among a plurality of players, the battle execution unit that starts the battle between the game medium of the specific player and the enemy game medium, and the result of the battle after the result of the battle is determined. A participation request notification unit that notifies other players among a plurality of players of a request to participate in a match according to a request from a specific player specified for the screen displayed in response, and each participating in the match. A participation reception unit that accepts participation of other players in a match is provided within a range in which the total of the set values set for the player does not exceed the predetermined upper limit value, and the predetermined upper limit value is the first set value. It is set so that it is possible to accept the participation of the player who has the second set value smaller than the first set value in the match in the state where the maximum number of the set players participate in the match is accepted.
Further, the control program according to the present invention is a control program of a computer having a storage unit and executing a battle game, and is set for each of a plurality of players according to the strength of each player in the battle game. The set value is stored in the storage unit, a battle between the game medium of the specific player and the enemy game medium is started according to a request from a specific player among the plurality of players, and after the result of the battle is determined. According to the request from a specific player specified for the screen displayed according to the result of the battle, each of the other players among the multiple players is notified of the request to participate in the battle and participates in the battle. The computer is made to execute that the total of the set values set in the player does not exceed the predetermined upper limit value to accept the participation of other players in the battle, and the predetermined upper limit value is the first set value. It is set so that it is possible to accept participation of a player having a second set value smaller than the first set value in a match while accepting the maximum number of participation of the set player in the match.

The game control method, computer, and control program according to the present invention accept participation in the battle from each player within a range in which the total of the set values set for each player participating in the battle does not exceed the upper limit value. It is possible to properly maintain the game balance in the competitive game in which the player participates.

It is a figure which shows an example of the schematic structure of a game system. It is a figure which shows an example of the schematic structure of a mobile terminal. (A) and (b) are schematic diagrams for explaining a game provided by a game system. (A) to (d) are diagrams showing an example of a screen displayed on a mobile terminal. (A) to (c) are diagrams showing an example of a screen displayed on a mobile terminal. It is a figure which shows an example of the schematic structure of a server. (A) to (c) are diagrams showing an example of the data structure of each table. (A) to (c) are diagrams showing an example of the data structure of each table. It is a figure which shows an example of the operation sequence which concerns on a game processing. It is a figure which shows an example of the operation sequence which concerns on the list screen display processing. It is a figure which shows an example of the operation sequence which concerns on a participation process. It is a figure which shows an example of the operation flow of a battle process. It is a figure which shows an example of the operation flow of participation request processing. It is a figure which shows an example of the operation flow of the 2nd participation request processing. It is a figure which shows an example of the operation flow of the participation reception process. It is a figure which shows an example of the operation flow of a group classification process.

Hereinafter, various embodiments of the present invention will be described with reference to the drawings. However, it should be noted that the technical scope of the present invention is not limited to those embodiments, but extends to the inventions described in the claims and their equivalents.

1. 1. Outline of the present embodiment In the game system of the present embodiment, the player plays a game provided by the server using a mobile terminal. The game provided by the server includes a quest that progresses according to a game scenario, a normal battle in which players fight each other, and a battle event that is executed as an event.

A quest is generally also called a search, a mission, or the like, and has a plurality of floors (stages) in each of a plurality of dungeons, and processes of each floor are sequentially executed. The processing of each floor includes a battle between a character owned by the player and an enemy character, granting a privilege such as a specific item to the player, and the like. A normal battle is a battle executed by characters possessed by each player. A battle event is a so-called RAID battle in which a plurality of players cooperate to fight an enemy character (so-called non-player character), and is an example of a battle game.

The character is an example of a game medium. The game medium is electronic data used in a game, and includes, for example, cards, items, characters, avatars, and the like. Further, the game medium is electronic data that can be acquired, owned, used, managed, exchanged, synthesized, strengthened, sold, discarded, and / or gifted by the player in the game according to the progress of the game. The usage mode of the game medium is not limited to that specified in the present specification.

The player character or enemy character used in the battle has a battle parameter. The parameters for battle are, for example, attack power, defense power, physical strength (or HP (hit point)), attribute (for example, fire, water, thunder, etc.), rarity (for example, normal, rare, S (super) rare, etc. SS (double super) rare, SSS (triple super) rare, legend, etc.), skill (special effect) activation rate, attack speed (number of attacks in one turn, number of turns until attack, etc.), number of defenses in a pair battle Parameters and / or jobs (eg, occupation, type of soldier, etc.), etc.

The server classifies a plurality of players into a plurality of groups in advance in order to execute a battle event. Then, the server first notifies each player belonging to the group to which the player belongs, in accordance with the participation request from the player participating in the battle event, of the request to participate in the battle. Further, each time the notification time elapses, the server sequentially selects a group for which the participation request has not yet been notified, and notifies each player belonging to the selected group of the participation request for the match. In this way, the server will prevent the competition event from being flooded with a large number of players, while ensuring the number of participants even if each player notified of the participation request does not notice the participation request. We will try to appropriately notify each player of the request to participate in.

Further, the server sets each player with a participation value used for determining whether or not to participate in each battle event according to the strength of each player in the battle event. Then, the server accepts participation in the battle from each player within a range in which the total of the participation values set for each player participating in the battle does not exceed a predetermined upper limit value. In this way, the server suppresses that only strong players participate and easily defeat the enemy character in the battle event, and conversely, only weak players participate and cannot defeat the enemy character. Try to maintain proper game balance.

2. 2. Configuration of Game System 1 FIG. 1 is a diagram showing an example of a schematic configuration of game system 1.

The game system 1 includes at least one mobile terminal 2 and a server 3. The mobile terminal 2 and the server 3 are connected to each other via a communication network such as a base station 4, a mobile communication network 5, a gateway 6, and the Internet 7. The program executed on the mobile terminal 2 (for example, a browsing program) and the program executed on the server 3 (for example, a game program) use a communication protocol such as Hypertext Transfer Protocol (HTTP). Communicate.

The mobile terminal 2 is assumed to be a multifunctional mobile phone (so-called "smartphone"), but the present invention is not limited to this. The mobile terminal 2 may be a mobile phone (so-called "feature phone"), a mobile information terminal (Personal Digital Assistant, PDA), a portable game machine, a portable music player, a tablet terminal, a tablet, as long as the present invention can be applied. It may be a PC, a notebook PC, or the like.

2.1. Configuration of Mobile Terminal 2 FIG. 2 is a diagram showing an example of a schematic configuration of mobile terminal 2.

The mobile terminal 2 includes a terminal communication unit 21, a terminal storage unit 22, an operation unit 23, a display unit 24, and a terminal processing unit 25. The mobile terminal 2 requests the server 3 to proceed with the game in response to the operation of the operation unit 23 (button or the like) by the player. Further, the mobile terminal 2 receives and displays display data related to the progress of the game from the server 3.

The terminal communication unit 21 includes a communication interface circuit including an antenna having a predetermined frequency band as a sensitive band, and connects the mobile terminal 2 to a wireless communication network. The terminal communication unit 21 establishes a wireless signal line with the base station 4 by a CDMA (Code Division Multiple Access) method or the like via a channel assigned by the base station 4, and communicates with the base station 4. Do. Then, the terminal communication unit 21 transmits the data supplied from the terminal processing unit 25 to the server 3 or the like. Further, the terminal communication unit 21 supplies the data received from the server 3 or the like to the terminal processing unit 25. The terminal communication unit 21 may perform wireless communication with a Wifi (Wireless Fidelity) access point (not shown) by the wireless communication method of the IEEE802.11 standard.

The terminal storage unit 22 includes, for example, a semiconductor memory device. The terminal storage unit 22 stores operating system programs, driver programs, application programs, data, and the like used for processing in the terminal processing unit 25. For example, the terminal storage unit 22 stores, as a driver program, an input device driver program that controls the operation unit 23, an output device driver program that controls the display unit 24, and the like. Further, the terminal storage unit 22 stores, as an application program, a program for acquiring and displaying display data related to the progress of the game. The computer program is a terminal storage unit using a known setup program or the like from a computer-readable portable recording medium such as a CD-ROM (compact disk read only memory) or a DVD-ROM (digital versatile disk read only memory). It may be installed in 22. Further, the terminal storage unit 22 stores as data the player ID which is the identification information of the user of the mobile terminal 2, the display data related to the progress of the game, the video data, the image data, and the like. Further, the terminal storage unit 22 may temporarily store temporary data related to a predetermined process.

The operation unit 23 may be any device as long as the mobile terminal 2 can be operated, such as a touch panel and key buttons. The player can input characters, numbers, symbols, etc. using the operation unit 23. When operated by the player, the operation unit 23 generates a signal corresponding to the operation. Then, the generated signal is supplied to the terminal processing unit 25 as a player's instruction.

The display unit 24 may be any device as long as it can display an image, an image, or the like, and is, for example, a liquid crystal display or an organic EL (Electro-Luminescence) display. The display unit 24 displays an image corresponding to the image data supplied from the terminal processing unit 25, an image corresponding to the image data, and the like.

The terminal processing unit 25 includes one or a plurality of processors and peripheral circuits thereof. The terminal processing unit 25 is, for example, a CPU (Central Processing Unit), and controls the overall operation of the mobile terminal 2 in an integrated manner. The terminal processing unit 25 has a terminal communication unit 21 and a display unit so that various processes of the mobile terminal 2 are executed in an appropriate procedure based on a program stored in the terminal storage unit 22, an operation of the operation unit 23, and the like. Control the operation of 24 etc. The terminal processing unit 25 executes processing based on a program (operating system program, driver program, application program, etc.) stored in the terminal storage unit 22. Further, the terminal processing unit 25 can execute a plurality of programs (application programs and the like) in parallel.

2.1.1. Functions of Terminal Processing Unit 25 FIGS. 3A and 3B are schematic views for explaining a battle event provided by the game system 1. As shown in FIGS. 3A and 3B, this battle event has the following two characteristics.

The first feature is that the request for participation in each battle event is notified for each group that classifies each player participating in the game.

In the example shown in FIG. 3A, each player participating in the game is classified into a plurality of groups from group 1 to group N according to the timing when each player accesses the game system 1. When the participation request request is notified at time T from the mobile terminal 2 of the player A who is playing against the enemy character in the battle event, the server 3 first carries the mobile phones of each player belonging to the group K to which the player A belongs. Notify terminal 2 of the request to participate in the match. Next, on the server 3, at the time T + 1 when the notification time has elapsed from the time T, the battle event is still continuing (the enemy character has not been won) and the number of participants in the battle event has not reached the capacity. , Notify the mobile terminal 2 of each player belonging to the group (K-1) and the group (K + 1) adjacent to the group K of the request to participate in the match. After that, the server 3 is adjacent to the group that last notified the participation request each time the notification time elapses until the battle event ends (wins the enemy character) or the number of participants in the battle event reaches the capacity. Notify the mobile terminal 2 of each player belonging to the group to participate in the match.

Since the request to participate in the battle event is notified for each group, it is possible to prevent a large number of players from flooding into the battle with the enemy character and the processing load of the server 3 becomes too high. Furthermore, even if each player notified of the participation request does not notice the participation request, the participation request is notified to the players of other groups after the notification time has elapsed, so that the number of players participating in the battle event is small. The number of players participating in the battle event will be secured. Therefore, the server 3 can appropriately notify each player of the request for participation in the battle event.

The second feature is that participation in the battle event from each player is accepted within a range in which the total of the participation values set for each player participating in the battle event does not exceed a predetermined upper limit value.

As shown in FIG. 3B, each player participating in the game has a participation value used to determine whether or not to participate in the battle event according to the strength of each player in the battle event. It is set. In the example shown in FIG. 3B, a weaker player has a larger participation value, and a stronger player has a smaller participation value. The server 3 accepts participation of each player in the battle within a range in which the total of the participation values set for each player participating in the battle event does not exceed the upper limit value set for the battle event. That is, if player B having a participation value of 10 points and player C having a participation value of 5 points have already participated in a battle event with an enemy character having an upper limit value of 18 points, the participation value is 1 point. A strong player D can participate in the battle event, but a weak player E with a participation value of 10 points cannot participate in the battle event.

As a result, it is possible to prevent only weak players from participating in the battle event and defeating the enemy character. Conversely, by setting a larger participation value for stronger players and a smaller participation value for weaker players, it is possible to prevent only strong players from participating and easily defeating enemy characters in battle events. Will be done. Therefore, the server 3 can maintain the game balance appropriately.

FIG. 4A is a diagram showing an example of a home screen displayed on the display unit 24.

The home screen 400 shown in FIG. 4A is displayed at the start of a game or the like. Each screen described below is displayed based on the display data received from the server 3.

On the home screen 400, a quest button 401, a battle button 402, an event button 403, and the like are displayed.

When the quest button 401 is pressed, a screen (not shown) for executing the quest is displayed, and the player can execute the quest. In this embodiment, the search for the enemy character in the battle event is also performed in the quest, and when the enemy character is found in the quest, the battle preparation screen described later is automatically displayed, and the player executes the battle event. Can be done. When the battle button 402 is pressed, a screen (not shown) for executing a normal battle is displayed, and the player can execute the normal battle. When the event button 403 is pressed, a screen for executing the battle event is displayed, and the player can execute the battle event.

FIG. 4B is a diagram showing an example of an event screen displayed on the display unit 24.

The event screen 410 shown in FIG. 4B is displayed when the event button 403 is pressed on the home screen 400. On the event screen 410, a plurality of battle execution buttons 411, 412, a search button 413, a list button 414, a reward button 415, a result button 416, a home button 417, and the like for executing a battle event are displayed.

The battle execution button 411 is a button for executing a battle event with an enemy character discovered by the player among the battle events in which the player can participate. On the battle execution button 411, an image, a name, a level of an enemy character discovered by the player, the remaining time of the battle event, the discovered player name, and the like are displayed. The image of the enemy character includes a gauge that displays the maximum HP and the remaining HP of the enemy character in a band-shaped graph. The battle execution button 412 is a button for executing a battle event with an enemy character discovered by another player, that is, a battle event in which the player is notified of a participation request by the other player, among the battle events that the player can participate in. Is. On the battle execution button 412, the same information as the battle execution button 411 is displayed for the enemy character. The battle event executed by the battle execution button 412 is the most recommended battle event among the battle events in which the player is notified of the participation request. The most recommended battle event is a battle event with the highest or lowest HP of the enemy character, a battle event with the longest or shortest remaining time, or a battle event with the highest or lowest reward for winning the enemy character.

The battle execution button 411 is not displayed if the player has not found the enemy character. Note that the battle execution button 411 may function as a button for executing the second recommended battle event among the battle events in which the player is notified of the participation request when the player has not found the enemy character. Good.

When the search button 413 is pressed, the search for the enemy character is executed, and when the enemy character is found, the battle preparation screen described later is displayed. On the other hand, if the enemy character is not found, the event screen is displayed again, and the event screen displays that the enemy character was not found. When the search button 413 is pressed, a screen (not shown) for executing the quest is displayed, and the player may search for the enemy character by executing the quest.

When the list button 414 is pressed, a screen showing a list of enemy characters that can be currently battled by the battle event is displayed. When the reward button 415 is pressed, a screen (not shown) displaying a list of rewards (points) given when the battle event is won is displayed for each enemy character and its level. When the result button 416 is pressed, a screen (not shown) showing the rank of each player (for example, a list of each player name from the first rank to the predetermined rank) calculated based on the game points given in the battle event is displayed. Is displayed. When the home button 417 is pressed, the home screen 400 is displayed again.

4 (c) and 4 (d) are diagrams showing an example of a battle preparation screen displayed on the display unit 24.

The battle preparation screen 420 shown in FIG. 4C shows the battle execution button 411, 412 pressed on the event screen 410, the search button 413 pressed and the enemy character found, or the enemy character in the quest. Is displayed when is found. The battle preparation screen 440 shown in FIG. 4D is displayed when the battle preparation screen 420 is scrolled. On the battle preparation screen 420, the player name 421 that found the enemy character, the name of the enemy character 422, the level 423, the image 424, the HP 425, the remaining time of the battle event 426, and the like are displayed. Further, on the battle preparation screen 420, an attack button 427, an item button 428, a participation request button 429, a recovery button 430, a setting button 431, a list button 432, a reward button 433, a result button 434, and the like are displayed. In addition, a reward 441, a participating player 442, an event button 443, a home button 444, and the like are displayed on the battle preparation screen 440.

As HP425, the maximum HP and the remaining HP of the enemy character are displayed as a band-shaped graph (gauge) and numerical values. When the attack button 427 is pressed, a battle event with the enemy character is executed, and a screen showing the result of the battle is displayed after the production image of the battle showing the change in the HP of the player character and the enemy character is displayed by animation or the like. Is displayed. When the item button 428 is pressed, a screen that displays a list of items owned by the player that can activate special effects such as effects that increase attack power or defense power in battles with enemy characters (not shown). ) Is displayed. The player can activate a special effect by selecting a specific item from the displayed screen.

When the participation request button 429 is pressed, the server 3 is requested to request other players to participate in the battle event, and the battle preparation screen is displayed again. In the present embodiment, the player who has found the enemy character is a player who can request participation. Further, a player who participates in the battle event, a player who attacks an enemy character, a player randomly selected from these players, or the like may be a player who can request participation. The number of times each player can request participation may be limited to a predetermined number (for example, 3) or less. The participation request button 429 is displayed so that only a player who can request a participation request can press it. When a new player participates in a match event, the participating player 442 is updated.

When the recovery button 430 is pressed, a screen (not shown) displaying a list of recovery items that can recover the HP of the player's character among the items owned by the player is displayed. The player can recover the HP by selecting a recovery item from the displayed screen. When the setting button 431 is pressed, a screen (not shown) displaying a list of characters owned by the player is displayed. The player can select a character to play against the enemy character from the displayed screen. The list button 432, the reward button 433, and the result button 434 have the same functions as the list button 414, the reward button 415, and the result button 416 on the event screen 410, respectively.

The reward 441 is the total number of game points that the player has acquired so far in the battle event. Participating player 442 is a list of players who are currently executing a battle event with an enemy character. When the event button 443 is pressed, the event screen 410 is displayed again. When the home button 444 is pressed, the home screen 400 is displayed again.

The battle result screens 500 and 510 shown in FIGS. 5A and 5B are displayed after the battle effect image is displayed by animation or the like when the attack button 427 is pressed on the battle preparation screen 420. The battle result screen 500 is displayed when the enemy character is defeated, and the battle result screen 510 is displayed when the enemy character is defeated.

On the battle result screen 500, the player name 501 that found the enemy character, the name of the enemy character 502, the level 503, the image 504, HP505, the image 506 of the player character, HP507, the result 508, the back button 509, etc. are displayed. ..

As the HP 505 of the enemy character and the HP 507 of the player character, the maximum HP and the remaining HP are displayed as a band-shaped graph (gauge) and numerical values in the same manner as the HP 425 displayed on the battle preparation screen 440. On the battle result screen 500, the HP 505 of the enemy character is not yet 0, but the HP 507 of the player character is 0, and the result 508 indicates that the player has been defeated. When the back button 509 is pressed, the battle preparation screen 440 is redisplayed, and the player can play against the enemy character again.

On the battle result screen 510, the player name 501 that found the enemy character, the enemy character name 502, level 503, image 504, HP515, the player character image 506, HP517, the result 518, the back button 509, and the like are displayed. ..

On the battle result screen 510, the HP517 of the player's character is not 0, but the HP515 of the enemy character is 0, and as a result 518, the fact that the player has won and the reward given to the player are displayed. ing. When the back button 509 is pressed, the event screen 410 is redisplayed.

The list screen 520 shown in FIG. 5C is displayed when the list button 414 is pressed on the event screen 410, or when the list button 432 is pressed on the battle preparation screen 420. On the list screen 520, information 521 and a selection button 522 related to each battle event are displayed for each battle event in which the player can participate, and a sort button 523 and a back button 524 are displayed. The battle event in which the player can participate is a battle event with an enemy character discovered by the player, or a battle event in which another player notifies the player of a participation request.

The information 521 related to each battle event includes the name of the player who found the enemy character, the image of the enemy character, the name, the level, the HP, the remaining time of the battle event, and the like. When the selection button 522 is pressed, the battle preparation screens 420 and 440 for executing the battle event with the enemy character corresponding to the pressed selection button 522 are displayed. The rearrangement button 523 is a button for changing the order in which the information 521 and the selection button 522 related to each battle are arranged. The sort button 523 includes a button for arranging the remaining HP (physical strength) of the enemy character in each battle, the remaining time of each battle event, or the reward obtained in each battle event in ascending or descending order. When the sort button 523 is pressed, the information 521 and the selection button 522 related to each battle event are arranged and redisplayed in the order corresponding to the pressed buttons on the list screen 520. When the back button 524 is pressed, the event screen 410 or the battle preparation screen 420 is displayed again.

In this way, on the list screen 520, the information 521 related to each battle event and the selection button 522 are included in the remaining physical strength of the enemy character in each battle, the remaining time of each battle event, and the reward obtained in each battle event. They are displayed in order based on at least one of.

When the player discovers an enemy character, it is considered that the player has not yet participated in the battle event with the discovered enemy character. When the battle execution button 411 on the event screen 410, the selection button 522 on the list screen 520, or the attack button 427 on the battle preparation screen 420 for the battle event is pressed, the player participates in the battle event with the discovered enemy character. It is considered to have been done.

2.1.2. Configuration of Terminal Processing Unit 25 The terminal processing unit 25 includes at least a browsing execution unit 251. The browsing execution unit 251 is a functional module realized by a program executed by a processor included in the terminal processing unit 25. Alternatively, the browsing execution unit 251 may be mounted on the mobile terminal 2 as firmware.

The browsing execution unit 251 acquires and displays display data related to the progress of the game. That is, the browsing execution unit 251 transmits a display data acquisition request related to the progress of the game to the server 3 via the terminal communication unit 21 in response to an instruction from the player. Further, the browsing execution unit 251 receives the corresponding display data from the server 3 via the terminal communication unit 21. The browsing execution unit 251 creates drawing data based on the received display data. That is, the browsing execution unit 251 analyzes the received display data, specifies the control data and the content data, lays out the similarly specified content data based on the specified control data, and creates drawing data. Then, the browsing execution unit 251 outputs the created drawing data to the display unit 24. Further, the browsing execution unit 251 stores each information included in the display data in the terminal storage unit 22 while the communication connection with the server 3 is established.

2.2. Configuration of Server 3 FIG. 6 is a diagram showing an example of a schematic configuration of server 3. 7 (a) to 7 (c) and 8 (a) to 8 (c) are diagrams showing an example of the data structure of various tables stored in the server storage unit 32.

The server 3 includes a server communication unit 31, a server storage unit 32, and a server processing unit 33. The server 3 advances the game in response to a request from the mobile terminal 2. Further, the server 3 creates display data related to the progress of the game and transmits it to the mobile terminal 2.

The server communication unit 31 is an example of an output unit, includes a communication interface circuit for connecting the server 3 to the Internet 7, and communicates with the Internet 7. Then, the server communication unit 31 supplies the data received from the mobile terminal 2 or the like to the server processing unit 33. Further, the server communication unit 31 transmits the data supplied from the server processing unit 33 to the mobile terminal 2 or the like.

The server storage unit 32 includes, for example, at least one of a magnetic tape device, a magnetic disk device, and an optical disk device. The server storage unit 32 stores an operating system program, a driver program, an application program, data, and the like used for processing in the server processing unit 33. For example, the server storage unit 32 stores, as an application program, a game program or the like that advances the game and creates display data related to the result. The computer program may be installed in the terminal storage unit 22 from a computer-readable portable recording medium such as a CD-ROM or a DVD-ROM using a known setup program or the like.

Further, as data, the server storage unit 32 includes a player table shown in FIG. 7A, a battle information table shown in FIG. 7B, a battle table shown in FIG. 7C, and a group shown in FIG. 8A. The table, the character table shown in FIG. 8B, the item table shown in FIG. 8C, the image data of each player, various image data related to the progress of the game, and the like are stored. Further, the server storage unit 32 may temporarily store temporary data related to a predetermined process.

FIG. 7A shows a player table that manages players. In the player table, for each player, the identification number (player ID), password, name, image data file name, owned character information, used ID, owned item information, player level, player ID of the related player, etc. Information is associated and stored.

In the possessed character information, an identification number (ownership ID) for managing the possessed character, an identification number (character ID) of the character, and the like are stored in association with each character owned by the player. The used ID is an identification number of the used character used in the battle, and is the owned ID of the character used in the battle among the characters included in the owned character information. In the owned item information, an identification number (ownership ID) for managing the owned item, an identification number (item ID) of the item, and the like are stored in association with each item owned by the player. Items are, for example, a drug capable of activating special effects such as an effect of increasing attack power or defense power in a battle with an enemy character, a medicine for recovering battle points, and the like.

The player level is the level of the player in the quest or the normal battle, and is determined according to the points given to the player in the quest or the normal battle. A related player is another player associated with that player. Related players are, for example, other players who belong to the same group as the player, other players who have a friendship with the player, other players who rescued the player in the battle with the enemy character in the past, and the battle in the past. Other players who have played and / or other players who belong to a group that has played in the past, other players who have sent or received messages in the past, and the like.

FIG. 7B shows a battle information table that manages information on battle events for each player. In the battle information table, information such as the player ID, battle points, participation value, result information, discovery battle ID, participation battle ID, participation request battle ID, and past results of the player is stored in association with each other.

The battle points are points for executing a battle event with an enemy character, and are consumed each time the battle event is executed. In addition, the battle points are recovered by the passage of a certain period of time or the use of a specific item. The participation value is a value used for determining whether or not a player can participate when participating in a battle event, and is an example of a set value set for the player. The participation value is set according to the strength of each player in the battle event. For example, the higher the strength of each player, the smaller the value is set. Alternatively, the participation value may be set to a smaller value as the strength of each player is lower.

The result information includes game points, the number of wins, the number of participations, and the like. The game points are cumulative values of points given to each player when the enemy character is damaged in a battle event or when the enemy character is defeated. The number of wins is the number of battle events in which the player has won the enemy character. The number of participation is the number of competition events in which the player has participated. The discovery battle ID is an identification number of a battle event in which the player has found an enemy character. The participation battle ID is an identification number of the battle event in which the player is participating. The participation request battle ID is an identification number of the battle event for which the player has received a participation request. In the past results, the identification number (event ID) for managing the event, the ranking of the players in the event, etc. are stored in association with each event in the predetermined event period in which the battle event was held in the past. .. The ranking is determined by the game points acquired by the player at the event.

FIG. 7C shows a battle table that manages each battle event. In the battle table, for each battle event, the identification number (competition ID) for managing the battle event, the enemy character name, the level, the HP, the total participation value, the discovery time, the end flag, the discovery player ID, and the participating player ID , Participation request player ID, reward points, participation request start time, etc. are stored.

The enemy character name is the name of the enemy character who will be competing in the battle event. The level is the level of the enemy character who will be competing in the battle event. As the HP, the remaining HP and the maximum HP of the enemy character are stored. The total participation value indicates the total participation value of the players participating in the event. The discovery time is the time when the enemy character is discovered, that is, the time when the battle event starts. The end flag indicates whether or not the battle event has ended, and is set to OFF at the start of the battle event, and turns ON after a certain period of time (for example, 30 minutes) has passed from the discovery time or when the player wins the enemy character. Set.

The discovery player ID is the player ID of the player who discovered the enemy character. The participating player ID is the player ID of the player participating in the battle event. The participation request player ID is the player ID of the player who has been notified of the participation request for the battle event. The reward points are points given to the player when the enemy character is defeated. The participation request start time is the time when the participation request request from the player is first notified, and if the participation request request has not been notified yet, a blank is stored in the participation request start time.

FIG. 8A shows a group table in which each player manages each group classified. In the group table, the player IDs and the like of the players belonging to the group are stored in association with each group.

FIG. 8B shows a character table that manages characters. For each character, the character ID, name, file name and rarity of image data, attack power, defense power, attributes, parameters such as consumption value, and the like are stored in association with each character in the character table. The consumption value indicates the value consumed from the player's battle points when the character is used in the battle event.

FIG. 8C shows an item table for managing items. For each item, the item ID, name, image data file name, type, etc. of the item are stored in association with each other in the item table.

2.2.1. Configuration of Server Processing Unit 33 The server processing unit 33 includes a progress control unit 331, a main game execution unit 332, a battle execution unit 333, a participation request notification unit 334, a participation reception unit 335, and a classification unit 336. Each of these units is a functional module realized by a program executed by a processor included in the server processing unit 33. Alternatively, each of these parts may be mounted on the server 3 as firmware.

The progress control unit 331 controls the start and progress of the game, and appropriately instructs the main game execution unit 332, the battle execution unit 333, the participation request notification unit 334, and the participation reception unit 335 to execute the process. The progress control unit 331 exchanges necessary data with the mobile terminal 2 via the server communication unit 31.

When the request for each screen described with reference to FIGS. 4 (a) to 5 (c) is received from the mobile terminal 2, the progress control unit 331 has a button for receiving an instruction from the player and character information to be notified to the player. , Create display data for displaying images and the like in a layout corresponding to the screen, or instruct each part, and transmit the data to the mobile terminal 2. Then, when any button is pressed on the screen displayed on the mobile terminal 2 and a request for the next screen corresponding to the button is received from the mobile terminal 2, the progress control unit 331 similarly displays the next screen. The data is created or instructed to each part, and the data is transmitted to the mobile terminal 2.

In particular, when the player performs an operation of starting a game using the mobile terminal 2 or an operation of transitioning to the home screen and a home screen request corresponding to the operation is received from the mobile terminal 2, the progress control unit 331 returns the home. Create display data for displaying the screen 400. Then, the progress control unit 331 transmits the created display data to the mobile terminal 2.

Further, when the quest button 401 or the battle button 402 is pressed on the home screen 400 displayed on the mobile terminal 2 and the corresponding quest request or normal battle request is received from the mobile terminal 2, the progress control unit 331 receives the main game. Instruct the execution unit 332 to execute a quest or a normal battle. Then, the progress control unit 331 transmits the display data for executing the quest or the normal battle created by the main game execution unit 332 to the mobile terminal 2.

Further, when the event button 403 is pressed on the home screen 400 displayed on the mobile terminal 2 and the corresponding event screen request is received from the mobile terminal 2, the progress control unit 331 displays the event screen 410 on the battle execution unit 333. Instructs the creation of display data for display. Then, the progress control unit 331 transmits the display data created by the battle execution unit 333 to the mobile terminal 2.

Further, when the search button 413 is pressed on the event screen 410 displayed on the mobile terminal 2 and the corresponding search request is received from the mobile terminal 2, the progress control unit 331 executes the search process to the battle execution unit 333. Instruct. Then, the progress control unit 331 transmits the display data for displaying the event screen 410 or the battle preparation screens 420 and 440 created by the battle execution unit 333 according to the result of the search process to the mobile terminal 2.

Further, when the attack button 427 is pressed on the battle preparation screen 420 displayed on the mobile terminal 2 and the corresponding battle request is received from the mobile terminal 2, the progress control unit 331 executes the battle to the battle execution unit 333. Instruct. Then, the progress control unit 331 carries display data for displaying the battle production image created by the battle execution unit 333 according to the battle execution result, and display data for displaying the battle result screens 500 and 510. Send to terminal 2.

Further, when the participation request button 429 is pressed on the battle preparation screen 420 displayed on the mobile terminal 2 and the corresponding participation request request is received from the mobile terminal 2, the progress control unit 331 participates in the participation request notification unit 334. Instructs the execution of request processing. Further, the progress control unit 331 instructs the battle execution unit 333 to create the display data of the battle preparation screens 420 and 440, and transmits the display data created by the battle execution unit 333 to the mobile terminal 2.

Further, when the list button 414 of the event screen 410 displayed on the mobile terminal 2 or the list button 432 of the battle preparation screen 420 is pressed and the corresponding list screen request is received from the mobile terminal 2, the progress control unit 331 receives the corresponding list screen request. Instruct the battle execution unit 333 to create display data for displaying the list screen 520. Then, the progress control unit 331 transmits the display data created by the battle execution unit 333 to the mobile terminal 2.

Further, when the battle execution button 411, 412 on the event screen 410 displayed on the mobile terminal 2 or the selection button 522 on the list screen 520 is pressed and the corresponding participation response is received from the mobile terminal 2, the progress control unit 331 , Instruct the participation reception unit 335 to execute the participation reception process. When the participation reception unit 335 accepts the participation, the progress control unit 331 instructs the battle execution unit 333 to create the display data of the battle preparation screens 420 and 440 corresponding to the battle event for which the participation is accepted, and the battle The display data created by the execution unit 333 is transmitted to the mobile terminal 2. On the other hand, when the participation reception unit 335 does not accept the participation, the progress control unit 331 instructs the battle execution unit 333 to create the display data of the event screen 410, and the display data created by the battle execution unit 333 is used as the mobile terminal. Send to 2.

When the progress control unit 331 instructs the execution of the quest or the normal battle, the main game execution unit 332 specifies the player ID included in the quest request or the normal battle request, and corresponds to the specified player ID in the player table. Each information such as possessed character information is extracted. Further, the main game execution unit 332 extracts information about the character corresponding to the extracted possessed character information from the character table. The main game execution unit 332 creates display data for executing a quest or a normal battle based on each extracted information, and passes the created display data to the progress control unit 331. After that, a quest or a normal battle is executed using the created display data.

When the progress control unit 331 instructs the battle execution unit 333 to create the display data of the event screen 410, the battle execution unit 333 identifies the player ID included in the event screen request, and participates in the battle information table in association with the specified player ID. It is determined whether or not the battle ID is stored.

When the participation battle ID is stored in association with the specified player ID, that is, when the player has already participated in the battle event, the battle execution unit 333 reads each information corresponding to the participation battle ID from the battle table. , Create the display data of the battle preparation screen 420 representing each of the read information. Then, the battle execution unit 333 passes the created display data to the progress control unit 331.

On the other hand, when the participation battle ID is not stored in association with the specified player ID, that is, when the player has not yet participated in the battle event, the battle execution unit 333 creates the display data of the event screen 410. In that case, the battle execution unit 333 extracts from the battle information table the battle event in which the player has found an enemy character and the battle event in which the player is notified of the participation request and the player can participate.

In the battle information table, the battle execution unit 333 extracts the battle event corresponding to the discovery battle ID stored in association with the specified player ID as the battle event in which the player is notified of the participation request. Further, the battle execution unit 333 extracts the battle event corresponding to the participation request battle ID stored in association with the specified player ID as the battle event in which the player is notified of the participation request in the battle information table. Further, in the battle execution unit 333, the end flag is set to OFF in the battle table, the number of participating player IDs has not reached the upper limit of the number of players, and the participation value of the players is added to the total value of the participation values. Is extracted as a battle event in which the player can participate in the battle event that does not exceed the predetermined upper limit value.

The battle execution unit 333 determines the most recommended battle event among the extracted battle events based on each information stored in the battle table. The battle execution unit 333 reads the information on the battle event in which the player has found the enemy character and the information on each determined battle event from the battle table, and the event screen 410 representing the battle execution buttons 411 and 421 corresponding to each battle event. Create display data for. Then, the battle execution unit 333 passes the created display data to the progress control unit 331.

Further, when the battle execution unit 333 is instructed to execute the search process by the progress control unit 331, the player uses a pseudo-random number generated by using, for example, the current clock counter value of the server 3 as a seed, and the player selects the enemy character. Execute a lottery to select whether or not it was found. When the battle execution unit 333 wins the lottery, the battle execution unit 333 further determines the enemy character and its level using a pseudo-random number generated by using the current clock counter value of the server 3 as a seed. The battle execution unit 333 may determine the enemy character as an enemy character whose level is one level higher than the enemy character discovered immediately before by the player.

In the battle table, the battle execution unit 333 newly registers each information regarding the battle event with the determined enemy character, with the player ID of the player as the discovery player ID and the current time as the discovery time. Further, the battle execution unit 333 stores the battle ID of the newly registered battle event as the discovery battle ID in association with the player in the battle information table. Then, the battle execution unit 333 creates display data of the battle preparation screens 420 and 440 representing each information corresponding to the battle event. On the other hand, if the battle execution unit 333 does not win the lottery, the battle execution unit 333 recreates the display data of the event screen 410. Then, the battle execution unit 333 passes the created display data to the progress control unit 331.

Further, when the progress control unit 331 instructs the battle execution unit 333 to execute the battle, the battle execution unit 333 specifies the player ID and the battle ID included in the battle request, and from the player table, the use ID associated with the specified player ID is used. Is extracted, and the battle points associated with the specified player ID are extracted from the battle information table. Further, the battle execution unit 333 extracts the consumption value of the character associated with the extracted use ID from the character table. Next, the battle execution unit 333 determines whether or not the extracted consumption value is equal to or less than the battle points. When the consumption value is larger than the battle points, the battle execution unit 333 does not execute the battle event and creates display data of the battle preparation screen indicating that the battle points are insufficient.

On the other hand, when the consumption value is equal to or less than the battle points, the battle execution unit 333 subtracts the consumption value from the battle points in the battle information table. Next, the battle execution unit 333 determines whether or not the participation battle ID associated with the specified player ID is the same as the battle ID included in the battle request in the battle information table, and the player participates in the battle event. It is determined whether or not it is. When the player is not a participating player of the battle event, the battle execution unit 333 determines whether or not the discovery battle ID associated with the specified player ID is the same as the battle ID included in the battle request in the battle information table. It is determined whether or not the player is the discovering player of the battle event. If the player is not the discovery player of the battle event, the battle execution unit 333 does not execute the battle event and creates display data of the battle preparation screen indicating that the player has not participated in the battle event.

On the other hand, when the player is the discovering player of the battle event, the battle execution unit 333 stores the specified battle ID as the participation battle ID in the battle information table in association with the specified player ID, and further, in the battle table. , The specified player ID is stored as a participating player ID in association with the specified battle ID. As a result, the battle execution unit 333 causes the player to participate in the battle event.

When the player is a participating player of the battle event, the battle execution unit 333 executes the battle event. The battle execution unit 333 determines the amount of damage to be given to the enemy character based on the attack power of the player character and the defense power of the enemy character, and subtracts the determined damage amount from the HP of the enemy character in the battle table. On the other hand, the battle execution unit 333 determines the amount of damage to be given to the player's character based on the attack power of the enemy character and the defense power of the player's character, and subtracts the determined damage amount from the HP of the player's character. The battle execution unit 333 determines that the player has won when the HP of the enemy character becomes 0 first, and determines that the player has been defeated when the HP of the player's character becomes 0 first.

When a player wins, the battle execution unit 333 sets the end flag corresponding to the battle event to ON in the battle table, and the discovery battle ID, participation battle ID, and participation of each player who participated in the battle event in the battle information table. Delete the battle ID of the battle event from the requested battle ID. Similarly, when a certain time has passed from the discovery time, the battle execution unit 333 sets the end flag corresponding to the battle event to ON in the battle table, and each player who participates in the battle event in the battle information table The battle ID of the battle event is deleted from the discovery battle ID, the participation battle ID, and the participation request battle ID.

Further, the battle execution unit 333 reads the reward points from the battle table, adds the read reward points to the game points of each player who participated in the battle event in the battle information table, and increments (+1) the number of wins. Further, the battle execution unit 333 determines the item to be given to each player by lottery, and adds it to the item information owned by each player in the player table. In addition, the battle execution unit 333 creates display data for displaying the production image of the battle and display data for displaying the battle result screens 500 and 510 according to the result of the battle event. In this way, the battle execution unit 333 starts and executes a battle between the character of the specific player and the enemy character in accordance with the request from the specific player.

Further, the battle execution unit 333 specifies the order specified by the player ID and the sort button 523 included in the list screen request when the progress control unit 331 instructs the creation of the display data of the list screen 520. In the same manner as when the battle execution unit 333 creates the display data of the event screen 410, the battle event in which the specified player finds the enemy character and the participation request are notified to the player from the battle information table, and the player is notified. Extract all the competition events that can participate in. The battle execution unit 333 reads the information related to each of the extracted battle events from the battle table, creates the display data of the list screen 520 in which the information related to each battle event is arranged in the specified order, and creates the created display data. It is passed to the progress control unit 331.

The participation request notification unit 334 specifies the player ID and the battle ID included in the participation request request when the progress control unit 331 instructs the execution of the participation request processing. Next, the participation request notification unit 334 can request the player depending on whether or not the discovered player ID or the participating player ID associated with the specified battle ID and the specified player ID are the same in the battle table. Determine if you are a player. If the player is not a requestable player, the participation request notification unit 334 does not notify other players of the participation request for the battle event.

On the other hand, when the player is a player that can be requested, the participation request notification unit 334 specifies a group including the specified player ID in the group table, and each player other than the requesting player belongs to the specified group. Player ID is extracted. Next, the participation request notification unit 334 reads the total participation value associated with the specified battle ID from the battle table, and reads the participation value associated with each extracted player ID from the battle information table. The participation request notification unit 334 determines whether or not the value obtained by adding the participation value of the player to the total participation value is equal to or less than the predetermined upper limit value, and only when the value is equal to or less than the upper limit value, the player is sent to the battle event. Notify the participation request.

The participation request notification unit 334 stores the player ID of the player who notified the participation request as the participation request player ID in the battle table in association with the specified battle ID, and stores the specified battle ID in the battle information table as the participation request battle. It is stored as an ID in association with the player ID. As a result, when the player next displays the event screen 410 or the list screen 520 on the mobile terminal 2, the battle event corresponding to the specified battle ID is displayed on each screen so that the player can select it. You will be notified of your request for participation. Further, the participation request notification unit 334 may directly notify the player of the participation request for the battle event by transmitting an e-mail or the like to the player's mobile terminal 2 via the server communication unit 31. In this way, the participation request notification unit 334 notifies the players included in the group including the requesting player of the participation request to the battle event in accordance with the request from the requesting player.

Next, the participation request notification unit 334 stores the current time as the participation request start time in the battle table in association with the specified battle ID. Next, the participation request notification unit 334 recreates the display data of the battle preparation screens 420 and 440, and passes the created display data to the progress control unit 331.

After that, the participation request notification unit 334 periodically determines whether or not the battle event is being executed depending on whether or not the end flag associated with the specified battle ID is OFF in the battle table. When the battle event is being executed, the participation request notification unit 334 still notifies the participation request every time the notification time elapses from the participation request start time, that is, when the notification time elapses after the previous notification of the participation request. Other groups that have not been selected are sequentially selected, and the player IDs included in the selected group are extracted. Next, the participation request notification unit 334 reads the total participation value associated with the specified battle ID from the battle table, and reads the participation value associated with each extracted player ID from the battle information table. The participation request notification unit 334 determines whether or not the value obtained by adding the participation value of the player to the total participation value exceeds a predetermined upper limit value, and only if the upper limit value is not exceeded, the player participates in the battle event. Notify the request. In this way, each time the notification time elapses, the participation request notification unit 334 sequentially selects a group other than the group including the requesting player, and requests the players included in the selected group to participate in the battle event. Notice.

In addition, the participation request notification unit 334 selects each group adjacent to the group that notified the participation request immediately before as the group that notifies the participation request next. As will be described later, each group is classified so that the latest time when the player to which the player belongs has accessed the battle event is evenly distributed, so that the player who notifies the participation request is only the recently accessed player, or It is suppressed that only players who are not accessing are used.

In addition, the notification time that defines the interval for notifying the participation request can be a predetermined fixed time (for example, 1 minute). The notification time is the number of players who participated in the battle event in response to the participation request, the number of players who are executing the battle event, the number of characters of the requesting player who won the battle event, and the requesting source. It may be changed based on at least one of the number of characters of the player who participated in the battle event, the level of the requesting player, and the number of messages sent by the requesting player to other players.

For example, the participation request notification unit 334 increases the notification time as the number of players who participated in the battle event in response to the participation request increases, and the notification time increases as the number of players who participate in the battle event in response to the participation request decreases. shorten. As a result, when many players have already participated in the battle event, the participation of further players is restricted, and it is possible to prevent the players from flooding into one battle event. On the other hand, if the number of players participating in the battle event is still small, more players can be participated immediately, and it is possible to prevent it from taking a long time to defeat the enemy character.

Further, for example, the participation request notification unit 334 lengthens the notification time as the number of players currently executing the battle event increases, and shortens the notification time as the number of players currently executing the battle event decreases. .. As a result, it is possible to prevent a flood of players who wish to participate during lunch breaks, commuting hours, etc., where a large number of players execute battle events, and to allow more players to participate at midnight, etc., when the number of players is small. It is possible to equalize the number of participants in each competition event.

Further, for example, the participation request notification unit 334 shortens the notification time as the number of wins or the number of participations of the requesting player in the battle event increases. As a result, the player participates more frequently in the battle event so that the participants in the battle event can be gathered and the enemy character can be defeated in a shorter time, so that the battle event can be activated.

Further, for example, the participation request notification unit 334 shortens the notification time as the player level of the requesting player in the battle event is higher. As a result, the player executes the quest or the normal battle more frequently so that the participants in the battle event can be gathered and the enemy character can be defeated in a shorter time, so that the quest or the normal battle can be activated. It becomes.

Further, for example, the participation request notification unit 334 shortens the notification time as the number of messages transmitted by the player to the related player or the number of messages transmitted by the player to the main game to the other player increases. As a result, the player sends a message more frequently so that the participants in the battle event can be gathered and the enemy character can be defeated in a shorter time, so that the communication between the players can be activated.

Further, the participation request notification unit 334 sets the group that first notifies the participation request when the progress control unit 331 instructs the execution of the participation request process to another group instead of the group that includes the requesting player. You may. For example, the group that first notifies the participation request is that at least one of the related players related to the requesting player, the players participating in the match, and the related players related to the players participating in the match. It may be a group to be included.

The participation reception unit 335 specifies the player ID and the battle ID included in the participation response when the progress control unit 331 instructs the execution of the participation reception process. The participation reception unit 335 reads out each information associated with the specified battle ID from the battle table.

The participation reception unit 335 determines whether or not the discovery player ID or the participation request player ID associated with the specified battle ID is the same as the player ID included in the participation response in the battle table, and the player participates in the battle event. It is determined whether or not the player is the player who has been notified of the participation request or the player who has been notified of the participation request. Further, the participation reception unit 335 determines whether or not the battle event is being executed depending on whether or not the end flag is set to OFF in the battle table. Further, the participation reception unit 335 identifies the number of participating players participating in the battle event from the participating player IDs stored in the battle table. Further, the participation reception unit 335 reads the total participation value associated with the specified battle ID from the battle table, and reads the participation value associated with the specified player ID from the battle information table.

Participation reception unit 335 is a player who has been notified of the discovery player of the battle event or a participation request, the battle event is being executed, the number of participating players has not reached the upper limit of the number of players, and the total participation Only when the value obtained by adding the participation value of the player to the value does not exceed the upper limit value, the player is accepted to participate in the battle event.

When the participation reception unit 335 accepts the participation of the player in the battle event, the participation reception unit 335 stores the specified battle ID as the participation battle ID in the battle information table in association with the specified player ID, and the participation associated with the player. Increment the number of times (+1). Further, the participation reception unit 335 stores the specified player ID as a participating player ID in association with the specified battle ID in the battle table, and adds the participation value of the newly joined player to the total participation value.

In this way, the participation reception unit 335 accepts participation of each player in the battle within a range in which the total of the participation values set for each player participating in the battle event does not exceed the upper limit value. The participation value is set to a smaller value as the strength of each player in the battle event is higher, and is set to a larger value as the strength of each player is lower. Therefore, it is suppressed that only weak players participate in a specific battle event and reach the upper limit of the number of players, and strong players cannot participate in the battle event, and as a result, the enemy character cannot be defeated. Alternatively, the participation value may be set to a larger value as the strength of each player in the battle event is higher, and may be set to a smaller value as the strength of each player is lower. In that case, it is possible to prevent only strong players from participating in a specific battle event and easily defeating the enemy character, and to maintain an appropriate game balance.

Alternatively, whether the participation value is set to a smaller value or a larger value as the strength of each player in the battle event is higher depends on the average time until the player wins the enemy character in the battle event. May be changed automatically. In that case, for example, when the average time until the player wins the enemy character is more than a predetermined time, the participation value is high for each player in the battle event so that more strong players can participate in the battle event. It is set to a small value. On the contrary, when the average time for a player to defeat an enemy character is less than a predetermined time, the participation value increases as the strength of each player in the battle event increases so that only strong players do not participate in the battle event. Set to a value.

The strength of each player is the parameters of the character owned by each player, the items owned by each player, the number of times each player has participated in the battle event or won the battle event, and each of the past battle events. Determined based on at least one of the player's performance.

For example, among the characters owned by each player, the higher the total of the parameters of a predetermined number of characters in descending order of parameters such as attack power, defense power, and HP, the higher the player's strength is set. Further, for example, the greater the number of items owned by each player that can activate special effects or items that recover battle points, the higher the player's strength is set. Further, for example, the greater the number of times each player participates or wins in a battle event, the higher the player's strength is set. Further, for example, the higher the performance of each player in the past battle event, the higher the player's strength is set. As a result, it becomes possible to disperse the players who are likely to cause a large amount of damage to the enemy character in a more balanced manner.

Further, when the participation value is set to a smaller value as the strength of each player in the battle event is higher, the upper limit of the total participation value is not divisible by the participation value set for the weak player, and the remainder is strong. It is set to a value that is equal to or greater than the participation value set for the player. For example, when the upper limit of the total participation value is set to 18, the participation value of a weak player is set to a value that is not divisible by 18, such as 10, and the participation value of a strong player is 18 to 10 such as 1. It is set to a value equal to or less than the remainder (8) divided. As a result, not only weak players participate in the battle event, but strong players can always participate. Conversely, if the lower the strength of each player in the battle event, the smaller the participation value is set, set the upper limit of the total participation value to a value that is not divisible by the participation value set for the strong player. By doing so, players who are vulnerable to battle events will be able to participate without fail.

The upper limit of the total participation value may be set according to at least one of a predetermined battle situation, an enemy character parameter, and a character parameter of the requesting player. The predetermined battle situation includes a battle with a predetermined enemy character, a battle in which a predetermined player participates, and a situation in at least one battle related to a combination of the predetermined enemy character and the player. For example, the upper limit is the upper limit in other battles in at least one of a battle with a predetermined enemy character, a battle in which a predetermined player participates, and a battle related to a combination of a predetermined enemy character and a player. Is set to a higher value. Alternatively, the upper limit value is the upper limit value in other battles in at least one battle among a battle with a predetermined enemy character, a battle in which a predetermined player participates, and a battle related to a combination of a predetermined enemy character and a player. It may be set to a value lower than. This makes it possible to improve the game quality in the battle event.

Further, for example, the upper limit value is set to a lower value as the parameters such as the attack power, defense power, and HP of the enemy character are higher. As a result, since only the stronger player participates in the battle event against the strong enemy character, the possibility of winning the enemy character can be increased. Further, for example, the upper limit value is set to a higher value as the parameters such as the attack power, defense power, and HP of the character of the requesting player are higher, and is set to a lower value as the parameters are lower. As a result, if the requesting player is strong, the weak player participates in the battle event, and if the requesting player is weak, the strong player participates in the battle event. Therefore, the strength of all the players participating in the battle event is uniform. It becomes possible to.

In addition, the upper limit of the total participation value may be changed according to the passage of time from the start of the battle event. For example, the participation reception unit 335 changes the upper limit value to a larger value each time the notification time elapses after the start of the battle event. As a result, if the enemy character is not defeated within a certain period of time, it is possible to add a player who participates in the battle event, and it is possible to increase the possibility of defeating the enemy character.

The classification unit 336 classifies each player into a plurality of groups based on the order in which each player accesses the battle event. When each player executes a specific action for a battle event, the classification unit 336 allocates each player to each group in the order in which the actions are executed. For example, the classification unit 336 first allocates the player of the mobile terminal 2 that has transmitted the event screen request to group 1, and then allocates the player of the mobile terminal 2 that has transmitted the event screen request to group 2. After that, the classification unit 336 allocates the player of the mobile terminal 2 that has transmitted the event screen request to the group next to the group to which the player was assigned immediately before. The classification unit 336 allocates each player to each group by adding the player ID of each player as the player ID belonging to each group in the group table.

Further, the classification unit 336 indicates that the player of the mobile terminal 2 that has transmitted the event screen request already belongs to a specific group, that is, the mobile terminal 2 of the player transmits the event screen request for the second time or later. The player is deleted from the group to which the player belongs, and the player is assigned to the group next to the group to which the player was assigned immediately before. As a result, each group is classified so that the latest time when the player to which the player belongs accesses the battle event is evenly distributed.

The classification unit 336 may classify each player in the order in which the access time to the battle event of each player is closer to the current time. In that case, a predetermined number of players whose access time is closest to the current time are classified into group 1, a predetermined number of players whose access time is next closest to the current time are classified into group 2, and group N is classified. , A predetermined number of players whose access time is farthest from the current time are classified. In addition, the participation request notification unit 334 notifies the participation request to the battle event in order from the players included in the group 1, that is, from the player whose access time is closest to the current time. As a result, the participation request can be preferentially notified to the players who are likely to participate in the battle event, so that the number of players participating in the battle event can be secured at an early stage.

Further, the classification unit 336 may classify each player based on the order in which each player logs in to the game. In that case, the classification unit 336 classifies each player so that the login times of the players included in each group to the game are evenly distributed. A player who has a short time after logging in is likely to have a long game duration, and is likely to have a high participation rate in a battle event. Therefore, it is possible to prevent the participation rate of the player who is notified of the participation request from being extremely biased in the competition event, and to maintain the game balance.

Alternatively, the classification unit 336 may classify each player into each group in the order in which the login time of the players included in each group to the game is closer to the current time. In that case, the participation request notification unit 334 notifies the participation request to the battle event in order from the players included in the group 1, that is, from the player whose login time is closest to the current time. As a result, the participation request is preferentially notified to the players who are likely to participate in the battle event, and it is possible to secure the number of players who participate in the battle event at an early stage.

Further, the classification unit 336 may classify each player based on the strength of each player in the battle event. In that case, the classification unit 336 classifies each player so that the strengths of the players included in each group are evenly distributed. As a result, the strength of the players participating in the battle event is prevented from being extremely biased, and the game balance is prevented from being lost.

In addition, the classification unit 336 may classify each player based on the participation rate of each player in the battle event. In that case, the classification unit 336 classifies each player so that the participation rate of the players included in each group in the battle event is evenly distributed. As a result, it is possible to prevent the participation rate of the player who is notified of the participation request from being extremely biased in the competition event, and to maintain the game balance.

Alternatively, the classification unit 336 may classify each player into each group in descending order of participation rate of the players included in each group in the battle event. In that case, the participation request notification unit 334 notifies the participation request to the battle event in order from the player included in the group 1, that is, the player having the highest participation rate in the battle event. As a result, the participation request is preferentially notified to the players who are likely to participate in the battle event, so that it is possible to secure the number of players participating in the battle event at an early stage. Alternatively, the participation request notification unit 334 may notify the participation request to the battle event in order from the players included in the group N, that is, from the player having the lowest participation rate in the battle event. As a result, the player who is unlikely to participate in the battle event is notified of the participation request preferentially, and the battle event can be activated.

Further, in the present embodiment, the player who has already participated in a specific battle event is restricted so that he / she cannot participate in another battle event. Therefore, when the mobile terminal 2 of the player participating in the battle event transmits the event screen request, the classification unit 336 does not reclassify the player, but reclassifies the player when the battle event ends. That is, when the battle event ends, the classification unit 336 reclassifies at least a part of the players of the game, including each player who participated in the battle event. This prevents the player from being changed to another group while participating in the battle event, and prevents the player who cannot participate in the new battle event from being assigned the access time as the latest player.

FIG. 9 is a diagram showing an example of an operation sequence related to the game processing of the game system 1. This operation sequence collaborates with each element of the mobile terminal 2 and the server 3 mainly by the terminal processing unit 25 and the server processing unit 33 based on the programs stored in the terminal storage unit 22 and the server storage unit 32 in advance. Is executed.

First, when the player presses the event button 403 using the operation unit 23 while the home screen 400 is displayed on the display unit 24 of the mobile terminal 2, the viewing execution unit 251 of the mobile terminal 2 requests the event screen. It is transmitted to the server 3 via the communication unit 21 (step S101). When the progress control unit 331 of the server 3 receives the event screen request from the mobile terminal 2, the battle execution unit 333 creates the display data of the event screen 410 (step S102). Next, the battle execution unit 333 transmits the created display data to the mobile terminal 2 (step S103). When the display data is received from the server 3 via the terminal communication unit 21, the browsing execution unit 251 of the mobile terminal 2 creates drawing data based on the received display data and causes the display unit 24 to display the event screen 410. (Step S104).

Next, when the player presses the search button 413 using the operation unit 23 while the event screen 410 is displayed on the display unit 24 of the mobile terminal 2, the browsing execution unit 251 of the mobile terminal 2 sends a search request to the terminal. It is transmitted to the server 3 via the communication unit 21 (step S105). When the progress control unit 331 of the server 3 receives the search request from the mobile terminal 2, the battle execution unit 333 executes a lottery and determines whether or not the player has found an enemy character, the found enemy character, and its level. (Step S106). Next, the battle execution unit 333 creates display data for the battle preparation screen 420, 440 or the event screen 410, depending on whether or not the player has found an enemy character (step S107). Next, the battle execution unit 333 transmits the created display data to the mobile terminal 2 (step S108). When the display data is received from the server 3 via the terminal communication unit 21, the browsing execution unit 251 of the mobile terminal 2 creates drawing data based on the received display data and displays the battle preparation screens 420 and 440 on the display unit 24. Alternatively, the event screen 410 is displayed (step S109).

Next, when the player presses the attack button 427 using the operation unit 23 while the battle preparation screens 420 and 440 are displayed on the display unit 24 of the mobile terminal 2, the viewing execution unit 251 of the mobile terminal 2 battles. The request is transmitted to the server 3 via the terminal communication unit 21 (step S110). When the progress control unit 331 of the server 3 receives the battle request from the mobile terminal 2, the battle execution unit 333 executes the battle process (step S111). The details of the battle process will be described later. Next, the battle execution unit 333 creates display data of the production image of the battle and display data of the battle result screen 500 or 510 according to the result of the battle event (step S112). Next, the battle execution unit 333 transmits the created display data to the mobile terminal 2 (step S113). When the display data is received from the server 3 via the terminal communication unit 21, the viewing execution unit 251 of the mobile terminal 2 creates drawing data based on the received display data, and displays a battle effect image and a battle on the display unit 24. The result screen 500 or 510 is displayed (step S114).

After that, when the player presses the participation request button 429 using the operation unit 23 while the battle preparation screens 420 and 440 are displayed again on the display unit 24 of the mobile terminal 2, the viewing execution unit 251 of the mobile terminal 2 displays. The participation request is transmitted to the server 3 via the terminal communication unit 21 (step S115). When the progress control unit 331 of the server 3 receives the participation request request from the mobile terminal 2, the participation request notification unit 334 executes the participation request process (step S116). Details of the participation request processing will be described later. Next, the participation request notification unit 334 recreates the display data of the battle preparation screens 420 and 440 (step S117). Next, the battle execution unit 333 transmits the created display data to the mobile terminal 2 (step S118). When the display data is received from the server 3 via the terminal communication unit 21, the browsing execution unit 251 of the mobile terminal 2 creates drawing data based on the received display data and displays the battle preparation screens 420 and 440 on the display unit 24. Is displayed (step S119). This completes the operation sequence related to the game processing.

FIG. 10 is a diagram showing an example of an operation sequence related to the list screen display processing of the game system 1. This operation sequence cooperates with each element of the mobile terminal 2 and the server 3 mainly by the terminal processing unit 25 and the server processing unit 33 based on the programs stored in the terminal storage unit 22 and the server storage unit 32 in advance. Is executed.

First, when the player presses the list button 414 using the operation unit 23 while the event screen 410 is displayed on the display unit 24 of the mobile terminal 2, the browsing execution unit 251 of the mobile terminal 2 requests the list screen. It is transmitted to the server 3 via the communication unit 21 (step S201). When the progress control unit 331 of the server 3 receives the list screen request from the mobile terminal 2, the battle execution unit 333 creates the display data of the list screen 520 (step S202). Next, the battle execution unit 333 transmits the created display data to the mobile terminal 2 (step S203). When the display data is received from the server 3 via the terminal communication unit 21, the browsing execution unit 251 of the mobile terminal 2 creates drawing data based on the received display data and causes the display unit 24 to display the list screen 520. (Step S204). This completes the operation sequence related to the list screen display.

FIG. 11 is a diagram showing an example of an operation sequence related to the participation processing of the game system 1. This operation sequence cooperates with each element of the mobile terminal 2 and the server 3 mainly by the terminal processing unit 25 and the server processing unit 33 based on the programs stored in the terminal storage unit 22 and the server storage unit 32 in advance. Is executed.

First, when the player presses the battle execution button 411, 412 or the selection button 522 using the operation unit 23 while the event screen 410 or the list screen 520 is displayed on the display unit 24 of the mobile terminal 2, the mobile terminal 2 The browsing execution unit 251 transmits the participation response to the server 3 via the terminal communication unit 21 (step S301). When the progress control unit 331 of the server 3 receives the participation response from the mobile terminal 2, the participation reception unit 335 executes the participation reception process (step S302). Details of the participation reception process will be described later. Next, the battle execution unit 333 creates display data for the event screen 410 or the battle preparation screens 420 and 440 according to the result of the participation reception process (step S303). Next, the battle execution unit 333 transmits the created display data to the mobile terminal 2 (step S304). When the display data is received from the server 3 via the terminal communication unit 21, the browsing execution unit 251 of the mobile terminal 2 creates drawing data based on the received display data, and displays the event screen 410 or the battle preparation on the display unit 24. The screens 420 and 440 are displayed (step S405). This completes the operation sequence related to the participation process.

FIG. 12 shows an operation flow of the battle processing by the battle execution unit 333. The battle process shown in FIG. 12 is executed in step S111 of FIG.

The battle execution unit 333 first extracts each information associated with the player ID included in the battle request from the player table, the battle information table, and the character table (step S401). Next, the battle execution unit 333 determines whether or not the extracted consumption value is equal to or less than the battle points (step S402). When the consumption value is larger than the battle point (step S402-No), the battle execution unit 333 does not execute the battle event (step S403) and ends a series of steps. In this case, in step S112 of FIG. 9, the battle execution unit 333 is not the display data of the production image of the battle and the display data of the battle result screen 500 or 510, but the battle preparation screen indicating that the battle points are insufficient. Create display data.

On the other hand, when the consumption value is equal to or less than the battle points (step S402-Yes), the battle execution unit 333 subtracts the consumption value from the battle points in the battle information table. Next, the battle execution unit 333 determines whether or not the player is a participating player in the battle event (step S404). When the player is a participating player of the battle event (step S404-Yes), the battle execution unit 333 shifts the process to step S407. On the other hand, when the player is not a participating player of the battle event (step S404-No), the battle execution unit 333 determines whether or not the player is the discovering player of the battle event (step S405). If the player is not the discovery player of the battle event (step S405-No), the battle execution unit 333 does not execute the battle event (step S403) and ends a series of steps. In this case, the battle execution unit 333 creates display data of the battle preparation screen indicating that the player has not participated in the battle event in step S112 of FIG.

On the other hand, when the player is the discovering player of the battle event (step S405-Yes), the battle execution unit 333 causes the player to participate in the battle event (step S406). Next, the battle execution unit 333 executes the battle event (step S407). When the player is defeated in the battle event (step S408-No), the battle execution unit 333 ends a series of steps. In this case, in step S112 of FIG. 9, the battle execution unit 333 creates display data of the battle effect image indicating that the player has been defeated and display data of the battle result screen 500.

On the other hand, when the player wins in the battle event (step S408-Yes), the battle execution unit 333 sets the end flag corresponding to the battle event to ON in the battle table, and ends the battle event (step S406). Next, the battle execution unit 333 updates the game points and the number of wins of each player who participated in the battle event in the battle information table, gives a privilege to the player (step S407), and ends a series of steps. In this case, in step S112 of FIG. 9, the battle execution unit 333 creates display data of the battle effect image indicating that the player has won and display data of the battle result screen 510.

FIG. 13 shows an operation flow of participation request processing by the participation request notification unit 334. The participation request process shown in FIG. 10 is executed in step S116 of FIG.

The participation request notification unit 334 first determines whether or not the player is a requestable player (step S501). If the player is not a requestable player, the participation request notification unit 334 does not notify another player of the participation request for the battle event, and ends the series of steps.

On the other hand, when the player is a requestable player, the participation request notification unit 334 specifies the group to which the player belongs in the group table (step S502). Next, the participation request notification unit 334 extracts players other than the requesting player who belong to the specified group (step S503). Next, the participation request notification unit 334 determines whether or not the value obtained by adding the participation value of the extracted player to the total participation value of the battle event notifying the participation request exceeds a predetermined upper limit value (step S504). .. When the added value is equal to or less than the upper limit value (step S504-Yes), the participation request notification unit 334 notifies the player of the participation request to the battle event (step S505). On the other hand, when the added value exceeds the upper limit value (step S504-No), the participation request notification unit 334 does not notify the player of the participation request for the battle event.

Next, the participation request notification unit 334 determines whether or not all the players other than the requesting player belonging to the specified group have been extracted (step S506). If all the players have not been extracted yet (step S506-No), the participation request notification unit 334 returns the process to step S503 and repeats the processes of steps S503 to S506. On the other hand, when all the players are extracted (step S506-Yes), the participation request notification unit 334 stores the current time as the participation request start time of the specified battle in the battle table (step S507), and performs a series of steps. finish.

FIG. 14 shows an operation flow of the second participation request processing by the participation request notification unit 334. The second participation request process shown in FIG. 14 is periodically executed after the execution of the participation request process shown in FIG.

The participation request notification unit 334 first determines whether or not the target battle event is being executed (step S601). When the target battle event is not being executed (step S601-No), the participation request notification unit 334 ends a series of steps. On the other hand, when the target battle event is being executed (step S601-Yes), the participation request notification unit 334 determines whether or not the notification time has elapsed since the previous notification of the participation request (step S602). .. When the notification time has not elapsed (step S602-No), the participation request notification unit 334 returns the process to step S601 and repeats the processes of steps S601 to S602. On the other hand, when the notification time has elapsed (step S602-Yes), the participation request notification unit 334 selects a group that has not yet notified the participation request (step S603).

Next, the participation request notification unit 334 extracts players belonging to the selected group (step S604). Next, the participation request notification unit 334 determines whether or not the value obtained by adding the participation value of the extracted player to the total participation value of the target battle event exceeds a predetermined upper limit value (step S605). When the added value is equal to or less than the upper limit value (step S605-Yes), the participation request notification unit 334 notifies the player of the participation request to the battle event (step S606). On the other hand, when the added value exceeds the upper limit value (step S605-No), the participation request notification unit 334 does not notify the player of the participation request for the battle event.

Next, the participation request notification unit 334 determines whether or not all the players belonging to the selected group have been extracted (step S607). If all the players have not been extracted yet (step S607-No), the participation request notification unit 334 returns the process to step S502 and repeats the processes of steps S604 to S607. On the other hand, when all the players are extracted (step S607-Yes), the participation request notification unit 334 ends a series of steps.

FIG. 15 shows an operation flow of the participation reception process by the participation reception unit 335. The participation acceptance process shown in FIG. 15 is executed in step S302 of FIG.

The participation reception unit 335 first determines whether or not the player is the player who discovered the battle event or the player who has been notified of the participation request (step S701). When the player is the discovery player of the battle event or the player notified of the participation request (step S701-Yes), the participation reception unit 335 determines whether or not the battle event is being executed (step S702). When the battle event is being executed (step S702-Yes), the participation reception unit 335 determines whether or not the number of participating players participating in the battle event is less than the upper limit of the number of players (step S703). When the number of participating players is less than the upper limit of the number of players (step S703-Yes), the participation reception unit 335 has a predetermined upper limit of the total participation value of the target battle event plus the participation value of the extracted players. It is determined whether or not the value is exceeded (step S704). When the added value is equal to or less than the upper limit value (step S704-Yes), the participation reception unit 335 accepts the player to participate in the battle event (step S705), and ends a series of steps.

On the other hand, if the player is not the discovering player of the battle event or the player notified of the participation request (step S701-No), or if the battle event is not being executed (step S702-No), the number of participating players limits the number of players. If it exceeds (step S703-No), or if the added value exceeds the upper limit (step S704-No), the participation reception unit 335 does not notify the player of the participation request for the battle event, and a series of steps. To finish.

FIG. 16 shows an operation flow of the group classification process by the classification unit 336. The group classification process shown in FIG. 16 is executed when each player executes a specific action for the battle event.

First, the classification unit 336 determines whether or not a player who has executed a specific action for the battle event participates in the battle event (step S801). When the player participates in the battle event (step S801-Yes), the classification unit 336 ends a series of steps without performing any particular processing. On the other hand, when the player has not participated in the battle event (step S801-No), the classification unit 336 determines whether or not the player already belongs to a specific group (step S802). If the player already belongs to a specific group (step S802-Yes), the classification unit 336 deletes the player from the group to which the player belongs (step S803). Next, the classification unit 336 allocates the player to the group next to the group to which the player was assigned immediately before (step S804), and ends a series of steps.

As described above, the server 3 classifies a plurality of players into a plurality of groups, sequentially selects the groups each time the notification time elapses, and requests the players included in the selected group to participate in the battle event. Notify. As a result, it is possible to prevent a large number of players from flooding the battle event, and even if each player notified of the participation request does not notice the participation request, the number of participants is secured, so that the participation request for the battle is made. Can be appropriately notified to each player.

Further, the server 3 accepts participation in the battle event from each player within a range in which the total of the participation values set for each player participating in the battle event does not exceed the upper limit value. As a result, in a battle event, it is suppressed that only strong players participate and the enemy character is easily defeated, and conversely, only weak players participate and the enemy character is not defeated, so that the game balance is properly balanced. It will be possible to maintain.

In addition, not only players who belong to the same group as the requesting player, limited players such as the requesting player and friend players, but all players are notified of the request to participate in the match. , Communication between players can be expanded.

The present invention is not limited to the present embodiment. For example, the game executed on the mobile terminal 2 may be a hybrid game in which the server 3 and the mobile terminal 2 each play a part in the processing. In that case, for example, each screen related to the progress of the game is a web display displayed on the mobile terminal 2 based on the display data generated by the server 3, and other menu screens and the like are native applications installed on the mobile terminal 2. The native display is displayed by.

It will be appreciated by those skilled in the art that various changes, substitutions, and modifications can be made to this without departing from the spirit and scope of the invention.

1 Game system 3 Server 31 Server communication unit 32 Server storage unit 33 Server processing unit 331 Progress control unit 332 Main game execution unit 333 Battle execution unit 334 Participation request notification unit 335 Participation reception unit 336 Classification unit

Claims (6)

It is a game control method in a computer that has a storage unit and executes a competitive game.
For each of the plurality of players, the set value set based on the item associated with each player is stored in the storage unit.
In response to a request from a specific player among the plurality of players, a battle between the game medium of the specific player and the enemy game medium is started.
In accordance with the request from the specific player, the other player among the plurality of players is notified of the request to participate in the battle.
Accepting participation of the other player in the battle within a range in which the total of the set values set for each player participating in the battle does not exceed a predetermined upper limit value.
Look at including it,
The predetermined upper limit value is a state in which the player whose first set value is set accepts the maximum number of participation in the battle, and the player whose second set value is set smaller than the first set value is set. It is set so that participation in the match can be accepted.
A game control method characterized by that. The predetermined upper limit value is set to a value that is not divisible by the first set value and the remainder obtained by dividing the predetermined upper limit value by the first set value is equal to or greater than the second set value. ,
The game control method according to claim 1 . The predetermined upper limit value is set according to at least one of a predetermined battle situation, a parameter of the enemy game medium, and a parameter of the game medium of the specific player, according to claim 1 or 2 . Game control method. The game control method according to any one of claims 1 to 3 , wherein the predetermined upper limit value is changed according to the passage of time from the start of the battle. A computer that runs a competitive game
A storage unit that stores setting values set based on items associated with each player for each of a plurality of players.
A battle execution unit that starts a battle between the game medium of the specific player and the enemy game medium in accordance with a request from a specific player among the plurality of players.
A participation request notification unit that notifies other players among the plurality of players of a request to participate in the battle in accordance with a request from the specific player.
A participation reception unit that accepts participation of the other players in the battle within a range in which the total of the set values set for each player participating in the battle does not exceed a predetermined upper limit value.
Equipped with a,
The predetermined upper limit value is a state in which the player whose first set value is set accepts the maximum number of participation in the battle, and the player whose second set value is set smaller than the first set value is set. It is set so that participation in the match can be accepted.
A computer that features that. A computer control program that has a storage unit and executes competitive games.
For each of the plurality of players, the set value set based on the item associated with each player is stored in the storage unit.
In response to a request from a specific player among the plurality of players, a battle between the game medium of the specific player and the enemy game medium is started.
In accordance with the request from the specific player, the other player among the plurality of players is notified of the request to participate in the battle.
Accepting participation of the other player in the battle within a range in which the total of the set values set for each player participating in the battle does not exceed a predetermined upper limit value.
Let the computer do that
The predetermined upper limit value is a state in which the player whose first set value is set accepts the maximum number of participation in the battle, and the player whose second set value is set smaller than the first set value is set. It is set so that participation in the match can be accepted.
A control program characterized by that.

Images