JP7128247B2 - Game control method, computer and control program - Google Patents

Description

Article 30, Paragraph 2 of the Patent Act applied November 21, 2014 Released on the website (http://gunmas.gree-pf.net/?action_fleet_raid_top=true&dt=8d171)

The present invention relates to a game control method, computer and control program.

In recent years, servers that provide games to mobile terminals via communication networks have become widespread. Games in which a plurality of players can participate (so-called “social games”) are known as games provided by such servers. Games provided as social games include so-called RAID battles in which a plurality of players participate and fight common enemy characters.

For example, Patent Literature 1 describes a server system that executes an online game in which a plurality of players participate and a common event of defeating a common enemy character is triggered. In this server system, a player who has already obtained the right to participate in the common event requests another player to participate in the common event, and the other player who has received the participation request sets the event activation conditions in his/her own main game. Even if you do not meet the requirements, you will be able to participate in common events.

JP 2014-140557 A

In the server system of Patent Literature 1, a player who has obtained the right to participate in a common event requests another player to participate in the common event, thereby implementing a common event in which a plurality of players participate. However, in such a server system, when players who have obtained the right to participate in the common event and players who have been requested to participate in the common event rush to the common event, the processing load on the server device, etc. becomes too high. there was a case.

The present invention has been made to solve such problems, and provides a game control method, a computer, and a control program that can prevent the processing load of a computer such as a server device from becoming too high. intended to provide

A game control method according to the present invention is a game control method in a computer that includes a storage unit and executes a competitive game, wherein a setting value set for each player is stored in the storage unit for each of a plurality of players, and a plurality of In accordance with a request from a specific player among the players, a match between a specific player's game content and an enemy game content is started, and in accordance with a request from a specific player, another player among a plurality of players is allowed to compete. and accepting other players' participation in the competition within a range in which the sum of the set values set for each player participating in the competition does not exceed a predetermined upper limit.
The computer may be a mobile terminal, a stationary terminal, a server, etc., as long as it can execute the above procedure.

Moreover, in the game control method according to the present invention, the set value is preferably set to a smaller value as the strength of each player in the competitive game increases.

Further, in the game control method according to the present invention, the strength of each player includes parameters of game media owned by each player, items owned by each player, the number of times each player has participated in battles, and past battle games. is preferably determined based on at least one of each player's performance in .

Also, in the game control method according to the present invention, it is preferable that the predetermined upper limit is set according to at least one of parameters of the enemy game content and parameters of the specific player's game content.

Moreover, in the game control method according to the present invention, it is preferable that the predetermined upper limit value is changed according to the elapse of time after the match is started.

Further, in the game control method according to the present invention, the computer further has a communication unit, and further transmits, to the terminal of the player to whom the participation request has been notified, information related to each competition for which the player has been notified of the participation request. , the remaining physical strength of the enemy game media in each battle, the remaining time in each battle, and the reward obtained in each battle, and transmitting display data for displaying them in order based on at least one of them through the communication unit. is preferred.

A computer according to the present invention is a computer that executes a competitive game, and includes 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 above, a battle execution unit that starts a battle between a specific player's game content and an enemy game content, and a participation that notifies other players among the plurality of players of a request to participate in the battle according to a request from the specific player. A request notifying part and a participation receiving part for accepting participation in the competition by other players within a range in which the sum of set values set for each player participating in the competition does not exceed a predetermined upper limit.

A control program according to the present invention is a control program for a computer that includes a storage unit and executes a competitive game, and stores a setting value set for each player in the storage unit for each of a plurality of players. In response to a request from a specific player within the game, a match between a specific player's game content and an enemy game content is started, and in accordance with a request from the specific player, another player from among the plurality of players participates in the match. The request is notified, and the computer is made to accept the participation of other players in the competition within a range in which the sum of the set values set for each player participating in the competition does not exceed a predetermined upper limit.
Further, a game control method according to the present invention is a game control method in a computer that has a storage unit and executes a battle game, wherein for each of a plurality of players, each player is given a command according to the strength of each player in the battle game. A set value set by the above is stored in a storage unit, and a match between a specific player's game medium and an enemy game medium is started in accordance with a request from a specific player among a plurality of players, and the result of the battle is determined. According to a request from a specific player specified on the screen displayed according to the result of the match after the competition, other players among the plurality of players are notified of the request to participate in the match and participate in the match. Accepting other players' participation in the battle within a range in which the sum of the set values set for each player does not exceed a predetermined upper limit, and the predetermined upper limit is set by the first set value. It is set so that the participation in the competition of the players for which the second set value smaller than the first set value is set can be accepted in a state in which the maximum number of participation in the competition of the selected players is accepted.
Further, a computer according to the present invention is a computer that executes a competitive game, and is a storage unit that stores a setting value set for each player according to the strength of each player in the competitive game for each of a plurality of players. a match execution unit for starting a match between a specific player's game content and an enemy game content in accordance with a request from a specific player among a plurality of players; a participation request notifying unit that notifies other players among the plurality of players of a request to participate in the battle according to a request from a specific player specified on a screen that is displayed according to the request; a participation accepting unit that accepts participation in the battle by other players within a range in which the total of the set values set for the player does not exceed a predetermined upper limit, wherein the predetermined upper limit is equal to the first set value; It is set so that the participation in the battle of the players for which the second set value smaller than the first set value is set can be accepted while the maximum number of participation in the battle by the set players is accepted.
Further, a control program according to the present invention is a control program for a computer that includes a storage unit and executes a competitive game, and is set for each of a plurality of players according to the strength of each player in the competitive game. The determined set values are stored in a storage unit, a match between the specific player's game medium and an enemy game medium is started in accordance with a request from a specific player among the plurality of players, and after the result of the battle is determined. In accordance with a request from a specific player specified on the screen displayed according to the result of the match, other players out of the plurality of players are notified of the request to participate in the match, and each player participating in the match The computer accepts another player's participation in the battle within a range in which the sum of the set values set for the player does not exceed a predetermined upper limit, and the predetermined upper limit is the first set value. It is set so that the participation in the battle of the players for which the second set value smaller than the first set value is set can be accepted while the maximum number of participation in the battle by the set players is accepted.

With the game control method, computer, and control program according to the present invention, it is possible to prevent the processing load on the computer from becoming too high .

It is a figure which shows an example of schematic structure of a game system. It is a figure which shows an example of schematic structure of a portable terminal. (a) and (b) are schematic diagrams for explaining a game provided by the game system. (a) to (d) are diagrams showing examples of screens displayed on the mobile terminal. (a) to (c) are diagrams showing examples of screens displayed on the portable terminal. It is a figure which shows an example of a 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. FIG. 4 is a diagram showing an example of an operation sequence related to game processing; FIG. 10 is a diagram showing an example of an operation sequence related to list screen display processing; It is a figure which shows an example of the operation|movement sequence regarding participation processing. FIG. 10 is a diagram showing an example of an operation flow of battle processing; FIG. 10 is a diagram illustrating an example of an operation flow of participation request processing; FIG. 10 is a diagram illustrating an example of an operational flow of a second participation request process; It is a figure which shows an example of the operation|movement flow of a participation acceptance process. It is a figure which shows an example of the operation|movement flow of a group classification process.

Various embodiments of the present invention will now 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 invention described in the claims and equivalents thereof.

1. Overview of this Embodiment In the game system of this embodiment, a player uses a portable terminal to play a game provided by a server. The games provided by the server include quests that progress according to game scenarios, normal battles in which players fight each other, and battle events that are executed as events.

A quest is generally called a search, a mission, or the like, and has a plurality of floors (stages) in each of a plurality of dungeons, and the processing of each floor is sequentially executed. Processing on each floor includes a battle between a character possessed by the player and an enemy character, granting special benefits such as specific items to the player, and the like. A normal battle is a battle between 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 (a so-called non-player character), and is an example of a battle game.

A character is an example of a game medium. Game media are electronic data used in games, and include, for example, cards, items, characters, avatars, and the like. Game media are electronic data that can be acquired, possessed, used, managed, exchanged, combined, enhanced, sold, discarded, and/or gifted by players in the game as the game progresses. The mode of use of the game media is not limited to those specified in this specification.

A player character or an enemy character used in a battle has battle parameters. Battle parameters include, for example, attack power, defense power, physical strength (or HP (hit points)), attributes (eg, fire, water, lightning, etc.), rarity (eg, normal, rare, S (super) rare, SS (double super) rare, SSS (triple super) rare, legend, etc.), activation rate of skills (special effects), attack speed (number of attacks per turn, number of turns before attacking, etc.), number of defenses per match and/or jobs (e.g., occupations, types of soldiers, etc.).

The server classifies a plurality of players into a plurality of groups in advance in order to execute the battle event. Then, in response to a participation request from a player participating in the battle event, the server first notifies each player belonging to the group to which the player belongs to the battle participation request. Further, each time the notification time elapses, the server sequentially selects a group to which a participation request has not yet been notified, and notifies each player belonging to the selected group of a competition participation request. In this way, the server prevents a large number of players from rushing into the battle event, and ensures the number of participants even if each player notified of the participation request does not notice the participation request. To properly notify each player of a request to participate in

Further, the server sets, for each player, 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 competition from each player within a range in which the total participation value set for each player participating in the competition does not exceed a predetermined upper limit. In this way, the server prevents only strong players from participating in a battle event common to a plurality of players and easily defeats the enemy characters, and conversely, only weak players participate and cannot defeat the enemy characters. To solve the problem that there is a possibility that the game balance is lost due to the occurrence of , and to appropriately maintain the game balance in a competitive game in which a plurality of players participate .

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

A game system 1 includes at least one mobile terminal 2 and a server 3 . The mobile terminal 2 and the server 3 are interconnected via a communication network such as a base station 4, a mobile communication network 5, a gateway 6, and the Internet 7, for example. A program (for example, a browsing program) executed by the mobile terminal 2 and a program (for example, a game program) executed by the server 3 are communicated using a communication protocol such as Hypertext Transfer Protocol (HTTP). communicate.

Note that 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 any device to which the present invention can be applied. A PC, a notebook PC, or the like may be used.

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

The mobile terminal 2 includes a terminal communication section 21 , a terminal storage section 22 , an operation section 23 , a display section 24 and a terminal processing section 25 . The mobile terminal 2 requests the server 3 to proceed with the game according to the player's operation of the operation unit 23 (such as buttons). The mobile terminal 2 also receives display data relating to the progress of the game from the server 3 and displays the data.

The terminal communication unit 21 includes a communication interface circuit including an antenna whose sensitive band is a predetermined frequency band, and connects the mobile terminal 2 to a wireless communication network. The terminal communication unit 21 establishes a radio signal line using a CDMA (Code Division Multiple Access) method or the like with the base station 4 via a channel allocated by the base station 4, and communicates with the base station 4. conduct. Then, the terminal communication section 21 transmits the data supplied from the terminal processing section 25 to the server 3 or the like. Also, the terminal communication unit 21 supplies data received from the server 3 or the like to the terminal processing unit 25 . Note that the terminal communication unit 21 may perform wireless communication with a Wi-Fi (Wireless Fidelity) access point (not shown) according to 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 an operating system program, a driver program, an application program, data, etc. used for processing in the terminal processing unit 25 . For example, the terminal storage unit 22 stores, as driver programs, 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. The terminal storage unit 22 also stores, as application programs, a program for acquiring and displaying display data relating to the progress of the game. The computer program can be stored in 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) using a known setup program or the like. 22 may be installed. The terminal storage unit 22 also stores, as data, a player ID that is identification information of the user of the portable terminal 2, display data relating to the progress of the game, video data, image data, and the like. Furthermore, the terminal storage unit 22 may temporarily store temporary data related to predetermined processing.

The operation unit 23 may be any device as long as it can operate the mobile terminal 2, such as a touch panel and key buttons. The player can use the operation unit 23 to input letters, numbers, symbols, and the like. When operated by the player, the operation unit 23 generates a signal corresponding to the operation. The generated signal is supplied to the terminal processing unit 25 as an instruction from the player.

The display unit 24 may also be any device as long as it can display video, images, and the like, such as a liquid crystal display and 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 more processors and their peripheral circuits. The terminal processing unit 25 is, for example, a CPU (Central Processing Unit), and controls overall operations of the mobile terminal 2 . The terminal processing unit 25 controls the terminal communication unit 21, the display unit, and the like so that various processes of the mobile terminal 2 are executed in appropriate procedures based on the programs stored in the terminal storage unit 22, the operation of the operation unit 23, and the like. 24 and the like. The terminal processing unit 25 executes processing based on programs (operating system program, driver program, application program, etc.) stored in the terminal storage unit 22 . Also, the terminal processing unit 25 can execute a plurality of programs (application programs, etc.) in parallel.

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

The first feature is that a request to participate in each competition event is notified for each group in which each player participating in the game is classified.

In the example shown in FIG. 3( a ), each player participating in the game is classified into a plurality of groups from group 1 to group N according to the timing at which each player accesses the game system 1 . When a participation request is notified at time T from the mobile terminal 2 of player A who is fighting against an enemy character in the battle event, the server 3 first receives the mobile terminal 2 of each player belonging to group K to which player A belongs. The terminal 2 is notified of a request to participate in the competition. Next, at time T+1 when the notification time has elapsed from time T, the server 3 determines if the battle event is still continuing (the enemy character has not been defeated) and the number of participants in the battle event has not reached the capacity. , to the portable terminals 2 of the players belonging to the groups (K-1) and (K+1) adjacent to the group K, of a request to participate in the competition. After that, every time the notification time elapses, the server 3 adjoins the group to which the participation request was last notified until the battle event ends (the enemy character is defeated) or the number of participants in the battle event reaches the capacity. A request to participate in the competition is sent to the mobile terminal 2 of each player belonging to the group.

Since a request to participate in a battle event is notified for each group, it is possible to prevent the processing load on the server 3 from becoming too high due to a large number of players rushing into the battle with the enemy character. Furthermore, even if each player notified of the participation request does not notice the participation request, the number of players participating in the battle event is small because the participation request is notified to players in other groups after the notification time has passed. Instead, the number of players participating in the battle event is ensured. Therefore, the server 3 can appropriately notify each player of a request to participate in the battle event.

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

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, depending on the strength of each player in the battle event. is set. In the example shown in FIG. 3B, a larger participation value is set for a weaker player, and a smaller participation value is set for a stronger player. The server 3 accepts each player's participation in the battle within a range in which the total participation value set for each player participating in the battle event does not exceed the upper limit value set for the battle event. That is, when player B with a participation value of 10 points and player C with a participation value of 5 points have already participated in a battle event with an enemy character with an upper limit of 18 points, the participation value is 1 point. A certain strong player D can participate in the battle event, but a weak player E whose participation value is 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 being unable to defeat the enemy character. Conversely, by setting a larger participation value for a stronger player and a smaller participation value for a weaker player, it is possible to prevent enemy characters from easily being defeated by only strong players participating in a battle event. be done. Therefore, the server 3 can appropriately maintain the game balance.

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

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

The home screen 400 displays a quest button 401, a battle button 402, an event button 403, and the like.

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 quest also searches for an enemy character in the battle event, and when an enemy character is found in the quest, a battle preparation screen, which will be described later, is automatically displayed, and the player can execute the battle event. can be done. When the battle button 402 is pressed, a screen (not shown) for executing the 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. As shown in FIG.

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

The battle execution button 411 is a button for executing a battle event against an enemy character discovered by the player among the battle events in which the player can participate. The image of the enemy character discovered by the player, the name, the level, the remaining time of the battle event, the name of the discovered player, and the like are displayed on the battle execution button 411 . The image of the enemy character includes a gauge that displays the maximum HP and remaining HP of the enemy character in a band-shaped graph. A 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 from another player, among the battle events in which the player can participate. is. Information similar to that of the battle execution button 411 is displayed on the battle execution button 412 for the enemy character. The battle event executed by the battle execution button 412 is the most recommended battle event among the battle events for which participation requests have been notified to the players. The most recommended battle event is the battle event in which the HP of the enemy character is the highest or the lowest, the battle event in which the remaining time is the longest or the shortest, or the battle event in which the reward for defeating the enemy character is the highest or the lowest.

The battle execution button 411 is not displayed when the player has not found an enemy character. If the player has not found an enemy character, the battle execution button 411 may function as a button for executing the second recommended battle event among the battle events for which the participation request has been notified to the player. good.

When the search button 413 is pressed, a search for an enemy character is executed, and if an enemy character is found, a battle preparation screen, which will be described later, is displayed. On the other hand, if the enemy character has not been found, the event screen is displayed again, and the event screen displays that the enemy character has not been found. When the search button 413 is pressed, a screen (not shown) for executing a quest may be displayed, and the enemy character may be searched for by the player 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 score button 416 is pressed, a screen (not shown) showing the rank of each player calculated based on the game points awarded in the battle event (for example, a list of player names from first place to a predetermined rank) is displayed. Is displayed. When the home button 417 is pressed, the home screen 400 is displayed again.

FIGS. 4C and 4D are diagrams showing examples of battle preparation screens displayed on the display unit 24. FIG.

The battle preparation screen 420 shown in FIG. 4C is displayed when the battle execution buttons 411 and 412 are pressed on the event screen 410, when the search button 413 is pressed and an enemy character is found, or when an enemy character is found in a quest. is found, etc., is displayed. A battle preparation screen 440 shown in FIG. 4D is displayed when the battle preparation screen 420 is scrolled. The battle preparation screen 420 displays the name 421 of the player who discovered the enemy character, the name 422 of the enemy character, the level 423, the image 424, the HP 425, the remaining time 426 of the battle event, and the like. Also displayed on the battle preparation screen 420 are 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 performance button 434, and the like. 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. FIG.

As HP 425, the maximum HP and remaining HP of the enemy character are displayed in a band-shaped graph (gauge) and numerical values. When the attack button 427 is pressed, a battle event with an enemy character is executed, and after a battle effect image showing changes in HP between the player's character and the enemy character is displayed by animation or the like, a screen showing the result of the battle appears. Is displayed. When the item button 428 is pressed, a screen (not shown) displaying a list of items possessed by the player, which can activate a special effect such as an effect of increasing attack power or defense power in a battle with an enemy character. ) is displayed. The player can select a specific item from the displayed screen to activate a special effect.

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. Note that, in the present embodiment, a player who has found an enemy character is a player who can request a participation request. Also, a player participating in the battle event, a player attacking an enemy character, or a player randomly selected from among these players may be the players who can request participation. Note that the number of times each player can request a participation request may be limited to a predetermined number (eg, 3) or less. A participation request button 429 is displayed so that it can be pressed only by a player who can request a participation request. Participating players 442 are updated when new players participate in the competition event.

When the recovery button 430 is pressed, a screen (not shown) displaying a list of recovery items capable of recovering the player's character's HP among the items owned by the player is displayed. The player can recover HP by selecting recovery items 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 fight against the enemy character from the displayed screen. The list button 432, reward button 433, and score button 434 have the same functions as the list button 414, reward button 415, and score button 416 on the event screen 410, respectively.

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

The battle result screens 500 and 510 shown in FIGS. 5(a) and 5(b) 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. FIG. 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.

The battle result screen 500 displays the player name 501 who discovered the enemy character, the enemy character name 502, the level 503, the image 504, the HP 505, the player character image 506, the HP 507, the result 508, the return button 509, and the like. .

As the HP 505 of the enemy character and the HP 507 of the player's character, the maximum HP and remaining HP are displayed in strip-shaped graphs (gauges) and numerical values in the same way as the HP 425 displayed on the battle preparation screen 440 . On the battle result screen 500, the enemy character's HP 505 has not yet reached 0, but the player's character's HP 507 has reached 0, and the result 508 indicates that the player has been defeated. When the return button 509 is pressed, the battle preparation screen 440 is displayed again, and the player can battle the enemy character again.

The battle result screen 510 displays the player name 501 who discovered the enemy character, the enemy character name 502, the level 503, the image 504, the HP 515, the player's character image 506, the HP 517, the result 518, the return button 509, and the like. .

On the battle result screen 510, the HP 517 of the player's character is not 0, but the HP 515 of the enemy character is 0. As a result 518, the fact that the player has won and the reward given to the player are displayed. ing. When the return button 509 is pressed, the event screen 410 is displayed again.

A 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 . The list screen 520 displays information 521 and a selection button 522 relating to each battle event in which the player can participate, as well as a rearrange button 523 and a return button 524 . A 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 the player is notified of a participation request from another player.

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, name, level, HP, remaining time of the battle event, and the like. When the selection button 522 is pressed, battle preparation screens 420 and 440 for executing a battle event against the enemy character corresponding to the pressed selection button 522 are displayed. The rearrangement button 523 is a button for changing the order of arranging the information 521 and selection buttons 522 relating to each battle. The sort button 523 includes buttons for sorting the remaining HP (physical strength) of the enemy character in each battle, the remaining time in 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 relating to each battle event are arranged in the order corresponding to the pressed button and displayed again on the list screen 520 . When the return 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, information 521 and selection buttons 522 relating to each battle event are displayed, including the remaining physical strength of the enemy character in each battle, the remaining time of each battle event, and the rewards obtained in each battle event. are displayed in order based on at least one of

It should be noted that when the player discovers the enemy character, it is considered that the player has not yet participated in the battle event against 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 related to the battle event is pressed, the player participates in the battle event against the discovered enemy character. shall be deemed to have

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 implemented by a program executed by a processor included in the terminal processing unit 25 . Alternatively, the browsing execution unit 251 may be implemented in the mobile terminal 2 as firmware.

The viewing execution unit 251 acquires and displays display data relating to the progress of the game. In other words, the viewing execution unit 251 transmits a request for acquiring display data relating to the progress of the game to the server 3 via the terminal communication unit 21 in accordance with an instruction from the player. In addition, the viewing execution unit 251 receives 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 viewing execution unit 251 analyzes the received display data to specify control data and content data, lays out the specified content data based on the specified control data, and creates drawing data. The viewing execution unit 251 then outputs the created drawing data to the display unit 24 . In addition, 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 the server 3 . 7A to 7C and 8A to 8C are diagrams showing examples of data structures of various tables stored in the server storage unit 32. FIG.

The server 3 includes a server communication section 31 , a server storage section 32 and a server processing section 33 . The server 3 advances the game in response to requests from the mobile terminal 2 . The server 3 also creates display data relating to the progress of the game and transmits the created display data to the mobile terminal 2 .

The server communication unit 31 is an example of an output unit, has 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 portable terminal 2 or the like to the server processing unit 33 . The server communication unit 31 also transmits data supplied from the server processing unit 33 to the mobile terminal 2 and the like.

The server storage unit 32 includes, for example, at least one of a magnetic tape device, a magnetic disk device, or an optical disk device. The server storage unit 32 stores an operating system program, a driver program, an application program, data, etc. used for processing in the server processing unit 33 . For example, the server storage unit 32 stores, as an application program, a game program for advancing a game and creating 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 CD-ROM, DVD-ROM, etc. using a known setup program or the like.

7(a), the battle information table shown in FIG. 7(b), the battle table shown in FIG. 7(c), and the group data shown in FIG. 8(a). A table, a character table shown in FIG. 8(b), an item table shown in FIG. 8(c), image data of each player, various image data relating to progress of the game, and the like are stored. Furthermore, the server storage unit 32 may temporarily store temporary data related to predetermined processing.

FIG. 7(a) shows a player table for managing players. In the player table, for each player, the player's identification number (player ID), password, name, image data file name, possessed character information, use ID, possessed item information, player level, player ID of related players, etc. Information is associated and stored.

The owned character information stores, for each character owned by the player, an identification number (owned ID) for managing the owned character, an identification number (character ID) of the character, and the like in association with each other. The use ID is the identification number of the 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. The owned item information stores, for each item owned by the player, an identification number (possession ID) for managing the owned item, an identification number (item ID) of the item, etc., in association with each other. The item is, for example, a medicine capable of activating a special effect such as an effect of increasing attack power or defense power in a battle with an enemy character, a medicine for recovering battle points, or the like.

The player level is the level of the player in the quest or normal battle, and is determined according to the points given to the player in the quest or normal battle. Associated players are other players that are associated with the player. Associated players include, for example, other players belonging to the same group as the player, other players who are friends with the player, other players who helped the player in past battles with enemy characters, and past battles. and/or other players who belong to a group that has played against in the past, other players who have sent or received messages in the past, and the like.

FIG. 7(b) shows a battle information table for managing information on battle events for each player. In the match information table, information such as player ID, match points, participation value, result information, found match ID, join match ID, join request match ID, past results, etc. of each player is stored in association with each player.

A battle point is a point for executing a battle event against an enemy character, and is consumed each time a battle event is executed. Battle points are recovered after a certain amount of time has passed or by using a specific item. The participation value is a value used for determining whether or not a player can participate in a competition event, and is an example of a setting value set for a 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 is, 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. A game point is an accumulated value of points given to each player when a player damages an enemy character or wins over an enemy character in a battle event. The number of wins is the number of battle events in which the player has won against enemy characters. The number of times of participation is the number of battle events in which the player has participated. The discovered battle ID is the identification number of the battle event in which the player discovered the enemy character. The participating competition ID is the identification number of the competition event in which the player is participating. The participation request competition ID is the identification number of the competition event for which the player has received a participation request. In the past results, an identification number (event ID) for managing the event, the rank of the player in the event, and the like are stored in association with each event during a predetermined event period in which the battle event was held in the past. . Rankings are determined by the game points earned by the players in the event.

FIG. 7(c) shows a battle table for managing each battle event. In the battle table, for each battle event, an identification number (match ID) for managing the battle event, enemy character name, level, HP, total participation value, discovery time, end flag, discovering player ID, participating player ID , participation request player ID, reward points, participation request start time, and the like are stored.

The enemy character name is the name of the enemy character who fights in the battle event. The level is the level of the enemy character that fights in the battle event. As HP, the remaining HP and maximum HP of the enemy character are stored. The total participation value indicates the sum of the participation values of the players participating in the event. The discovery time is the time when the enemy character was discovered, that is, the time when the battle event started. The end flag indicates whether or not the battle event has ended, is set to OFF at the start of the battle event, and is turned ON after a certain period of time (for example, 30 minutes) has elapsed from the discovery time or when the player has defeated the enemy character. set.

The finding player ID is the player ID of the player who found the enemy character. The participating player ID is the player ID of a player participating in the battle event. The participation request player ID is the player ID of the player notified of the participation request for the battle event. Reward points are points given to the player when the player wins against the enemy character. The participation request start time is the time when the participation request is first notified from the player. If the participation request request has not yet been notified, a blank is stored in the participation request start time.

FIG. 8(a) shows a group table for managing each group into which each player is classified. In the group table, each group is stored in association with the player IDs of the players belonging to the group.

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

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

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 implemented by a program executed by a processor included in the server processing unit 33 . Alternatively, each of these units may be implemented in 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 processing. The progress control unit 331 exchanges necessary data with the mobile terminal 2 via the server communication unit 31 .

4(a) to 5(c) are received from the mobile terminal 2, the progress control unit 331 displays buttons for receiving instructions from the player, character information to be notified to the player, , or instructs each unit to create display data for displaying an image or the like in a layout corresponding to the screen, and transmits the data to the portable terminal 2 . 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 causes the next screen to be displayed. It executes or instructs each unit to create data, and transmits the data to the mobile terminal 2 .

In particular, when the player performs an operation to start the game using the mobile terminal 2 or an operation to transition to the home screen, and receives a corresponding home screen request from the mobile terminal 2, the progress control unit 331 returns to the home screen. Display data for displaying the screen 400 is created. The progress control unit 331 then 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 executes the main game. The execution unit 332 is instructed to execute a quest or a normal match. Then, the progress control section 331 transmits the display data for executing the quest or normal battle created by the main game execution section 332 to the portable 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 causes the battle execution unit 333 to display the event screen 410 . Instructs creation of display data for display. Then, the progress control section 331 transmits the display data created by the battle execution section 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 a corresponding search request is received from the mobile terminal 2, the progress control unit 331 instructs the battle execution unit 333 to execute search processing. instruct. Then, the progress control unit 331 transmits display data for displaying the event screen 410 or the battle preparation screens 420 and 440 created by the battle executing 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 a corresponding battle request is received from the mobile terminal 2, the progress control unit 331 instructs the battle execution unit 333 to execute the battle. instruct. Then, the progress control unit 331 carries display data for displaying a battle effect image created by the battle execution unit 333 according to the execution result of the battle, 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 competition preparation screen 420 displayed on the mobile terminal 2 and a 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 execution of request processing. Further, the progress control unit 331 instructs the battle execution unit 333 to create display data for 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 or the list button 432 of the battle preparation screen 420 displayed on the mobile terminal 2 is pressed and a corresponding list screen request is received from the mobile terminal 2, the progress control unit 331 The battle executing unit 333 is instructed to create display data for displaying the list screen 520 . Then, the progress control section 331 transmits the display data created by the battle execution section 333 to the mobile terminal 2 .

Further, when the competition execution buttons 411 and 412 on the event screen 410 displayed on the mobile terminal 2 or the selection button 522 on the list screen 520 are pressed and a corresponding participation response is received from the mobile terminal 2, the progress control unit 331 , instructs the participation acceptance unit 335 to execute the participation acceptance process. When participation is accepted by the participation reception unit 335, the progress control unit 331 instructs the battle execution unit 333 to create display data for the battle preparation screens 420 and 440 corresponding to the battle event for which participation has been accepted. 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 participation, the progress control unit 331 instructs the competition execution unit 333 to create display data for the event screen 410, and sends the display data created by the competition execution unit 333 to the portable terminal. 2.

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

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

When the participating match ID is stored in association with the identified player ID, that is, when the player has already participated in the match event, the match executing unit 333 reads each piece of information corresponding to the participating match ID from the match table. , to create display data for the battle preparation screen 420 representing each piece of information that has been read. Then, the battle executing section 333 passes the created display data to the progress control section 331 .

On the other hand, if the participation match ID is not stored in association with the specified player ID, that is, if the player has not yet participated in the match event, the match execution unit 333 creates display data for the event screen 410.例文帳に追加In this case, the battle execution unit 333 extracts, from the battle information table, a battle event in which the player has found an enemy character and a battle event in which the player is notified of a participation request and in which the player can participate.

The battle execution unit 333 extracts, from the battle information table, the battle event corresponding to the discovered battle ID stored in association with the identified player ID as the battle event for which the participation request has been notified to the player. The battle execution unit 333 also extracts, from the battle information table, the battle event corresponding to the participation request battle ID stored in association with the identified player ID as the battle event in which the player is notified of the participation request. In addition, the battle execution unit 333 determines that the end flag is set to OFF in the battle table, the number of participating player IDs does not reach the upper limit of the number of players, and the value obtained by adding the player's participation value to the total participation value is less than a predetermined upper limit value as a competition event in which the player can participate.

The battle execution unit 333 determines the most recommended battle event among the extracted battle events based on each piece of information stored in the battle table. The battle execution unit 333 reads information about the battle event in which the player found the enemy character and information about each determined battle event from the battle table, and displays an event screen 410 showing battle execution buttons 411 and 412 corresponding to each battle event. create display data for Then, the battle executing section 333 passes the created display data to the progress control section 331 .

Further, when the progress control unit 331 instructs the battle execution unit 333 to execute a search process, for example, the player selects an enemy character using a pseudo-random number generated using the current clock counter value of the server 3 as a seed. A lottery is executed to select whether or not it has been discovered. When winning the lottery, the battle executing section 333 further determines the enemy character and its level using pseudo-random numbers generated using the current clock counter value of the server 3 as a seed. Note that the battle executing section 333 may determine the enemy character to be an enemy character whose level is one level higher than the enemy character discovered immediately before by the player.

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

Further, when the progress control unit 331 instructs the battle execution unit 333 to execute a battle, the battle execution unit 333 identifies the player ID and the battle ID included in the battle request, and extracts the use ID associated with the identified player ID from the player table. is extracted, and the match point associated with the identified player ID is extracted from the match information table. Furthermore, the battle executing 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 point. If the consumption value is greater than the battle points, the battle execution unit 333 does not execute the battle event, and creates display data for a battle preparation screen indicating that the battle points are insufficient.

On the other hand, if 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 the player is a participating player of the battle event based on whether the 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. If the player is not a participating player in the battle event, the battle execution unit 333 determines whether the discovered battle ID associated with the specified player ID in the battle information table is the same as the battle ID included in the battle request. It is determined whether or not the player is the player who discovered the battle event. If the player is not the player who discovered the battle event, the battle execution unit 333 does not execute the battle event and creates display data for a battle preparation screen indicating that the player has not participated in the battle event.

On the other hand, if the player is the player who discovered the match event, the match execution unit 333 stores the specified match ID as the participation match ID in the match information table in association with the specified player ID, and further stores the specified match ID in the match table. , the specified player ID is stored as a participating player ID in association with the specified competition ID. Thereby, the battle execution unit 333 allows the player to participate in the battle event.

If the player is a player participating in the battle event, the battle execution unit 333 executes the battle event. The battle executing section 333 determines the amount of damage to be given to the enemy character based on the attack power of the player's character and the defense power of the enemy character, and subtracts the determined amount of damage from the HP of the enemy character on the battle table. On the other hand, the battle executing section 333 determines the amount of damage to be given to the player's character based on the offensive power of the enemy character and the defensive power of the player's character, and subtracts the determined amount of damage 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 the player wins, the match execution unit 333 sets the end flag corresponding to the match event to ON in the match table, and sets the found match ID, the participating match ID, and the participation match ID of each player who participated in the match event in the match information table. Delete the match ID of the match event from the requested match ID. Similarly, when a certain period of time has passed since the time of discovery, the battle execution unit 333 sets the end flag corresponding to the battle event to ON in the battle table, and sets the end flag of each player participating in the battle event in the battle information table to ON. The match ID of the match event is deleted from the discovered match ID, the join match ID, and the join request match ID.

Further, the battle execution unit 333 reads 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. Furthermore, the battle executing unit 333 determines items to be given to each player by lottery, and adds them to the possessed item information of each player in the player table. In addition, the battle execution unit 333 creates display data for displaying a battle effect image and display data for displaying the battle result screens 500 and 510 according to the result of the battle event. In this manner, the battle execution section 333 starts and executes a battle between the character of the specific player and the enemy character in accordance with a request from the specific player.

Further, when the progress control unit 331 instructs the battle execution unit 333 to create display data for the list screen 520 , the battle execution unit 333 identifies the player IDs included in the list screen request and the order specified by the sort button 523 . In the same way as when creating the display data of the event screen 410, the battle execution unit 333 notifies the battle event in which the identified player has found the enemy character, the player's participation request, and the player's extracts all competition events that can participate in. The battle execution unit 333 reads the extracted information about each battle event from the battle table, creates display data for a list screen 520 in which the information about each battle event is arranged in the specified order, and displays the created display data. It is passed to the progress control unit 331 .

When the progress control unit 331 instructs the participation request notification unit 334 to execute the participation request process, the participation request notification unit 334 identifies the player ID and the competition ID included in the participation request. Next, the participation request notifying unit 334 allows a player to make a request based on whether or not the identified player ID or the participating player ID associated with the specified match ID is the same as the specified player ID in the match table. It is determined whether or not it is a player. If the player is not a requestable player, the participation request notification unit 334 does not notify other players of the competition event participation request.

On the other hand, if the player is a requestable player, the participation request notification unit 334 identifies a group that includes the identified player ID in the group table, and each player belonging to the identified group other than the requesting player extract the player ID of Next, the participation request notification unit 334 reads out the total participation value associated with the identified match ID from the match table, and reads the participation value associated with each extracted player ID from the match information table. The participation request notification unit 334 determines whether or not the value obtained by adding the player's participation value to the total participation value is equal to or less than a predetermined upper limit value, and only when the value is equal to or less than the upper limit value, requests the player to participate in the battle event. Notify 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 identified battle ID, and stores the identified battle ID as the participation request battle in the battle information table. The ID is stored in association with the player ID. As a result, when the player displays the event screen 410 or the list screen 520 on the mobile terminal 2 next time, the battle event corresponding to the specified battle ID is displayed on each screen so that the player can select the battle event. You will be notified of your participation request. Further, the participation request notification unit 334 may directly notify the player of the competition event participation request by sending an e-mail or the like to the mobile terminal 2 of the player 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 request to participate in the battle event, according to 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 match table in association with the specified match ID. Next, the participation request notification section 334 recreates the display data of the battle preparation screens 420 and 440 and passes the created display data to the progress control section 331 .

After that, the participation request notification unit 334 periodically determines whether or not the battle event is being executed by checking whether the end flag associated with the identified battle ID is OFF in the battle table. When the competition event is in progress, the participation request notification unit 334 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 last participation request notification. Other groups that have not been selected are selected in sequence, and player IDs included in the selected group are extracted. Next, the participation request notification unit 334 reads out the total participation value associated with the identified match ID from the match table, and reads the participation value associated with each extracted player ID from the match information table. The participation request notification unit 334 determines whether or not the total participation value plus the player's participation value exceeds a predetermined upper limit value, and only when the value does not exceed the upper limit value, the player is invited to participate in the battle event. Notify request. In this way, the participation request notification unit 334 sequentially selects a group other than the group including the requesting player each time the notification time elapses, and requests the players included in the selected group to participate in the battle event. Notice.

Note that the participation request notification unit 334 selects each group adjacent to the group to which the participation request was notified immediately before as the next group to be notified of the participation request. As will be described later, each group is classified so that the most recent times at which the players belonging to it access the competition event are evenly distributed, so that the players notified of the participation request are all the players who have recently accessed, or It is suppressed that there are only players who have not accessed.

Also, the notification time, which defines the intervals for notifying participation requests, can be a predetermined fixed time (for example, 1 minute). The notification time includes the number of players participating in the battle event in response to the participation request, the number of players executing the battle event, the number of characters of the requesting player winning the battle event against the enemy character, 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 participating in the battle event in response to the participation request increases, and increases the notification time as the number of players participating 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, preventing a rush of players to a single battle event. On the other hand, when the number of players who participate in the battle event is still small, more players can be quickly made to participate, and it is possible to prevent the long time required to defeat the enemy character.

Also, 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 the rush of players who wish to participate during lunch breaks and commuting times when the number of players who execute the battle event is large, and to allow more players to participate in the late night when the number of players is small. This makes it possible to equalize the number of participants in each competition event.

Also, 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 in the battle event more frequently so as to collect participants in the battle event and defeat the enemy character in a shorter time, so that the battle event can be activated.

Also, 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 quests or normal battles more frequently so as to collect participants in the battle event and defeat the enemy characters in a shorter time, thereby activating the quests or normal battles. becomes.

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

Further, the participation request notification unit 334 sets the group to which the participation request is first notified when the progress control unit 331 instructs execution of the participation request process to be a group other than the group including the requesting player. may For example, the group to which the participation request is first notified is that at least one of a related player related to the requesting player, a player participating in the competition, and a related player related to the player participating in the competition. It may be a group to be included.

When the progress control unit 331 instructs the participation reception unit 335 to execute the participation reception process, the participation reception unit 335 identifies the player ID and the competition ID included in the participation response. The participation reception unit 335 reads each piece of information associated with the identified match ID from the match table.

The participation reception unit 335 determines whether or not the finding player ID or the participation requesting player ID associated with the identified battle ID in the battle table is the same as the player ID included in the participation response. It is determined whether or not the player is the player who discovered the player or the player notified of the participation request. Further, the participation reception unit 335 determines whether or not the battle event is being executed based on whether or not the end flag is set to OFF in the battle table. Furthermore, 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 out the total participation value associated with the specified match ID from the match table, and reads the participation value associated with the specified player ID from the match information table.

The participation reception unit 335 determines whether the player is the player who discovered the battle event or the player who was notified of the participation request, the battle event is in progress, 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 player's participation value to the value does not exceed the upper limit value, the player's participation in the competition event is accepted.

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

In this way, the participation accepting unit 335 accepts each player's participation in the battle within a range in which the total participation value set for each player participating in the battle event does not exceed the upper limit. This 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 the upper limit of the number of players is reached, and strong players cannot participate in the battle event and, as a result, cannot defeat the enemy character. 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 this case, it is possible to prevent enemy characters from easily being defeated when only strong players participate in a specific battle event, and it is possible to appropriately maintain the 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 increases depends on the average time until the player wins the enemy character in the battle event. may be changed automatically by In that case, for example, if the average time it takes for a player to win against an enemy character is equal to or longer than a predetermined time, the participation value is set so that the strength of each player in the battle event is high so that more strong players can participate in the battle event. is set to a smaller value. Conversely, if the average time required for a player to defeat an enemy character is less than the 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 the value

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

For example, among the characters possessed by each player, the player's strength is set to a higher value as the sum of parameters of a predetermined number of characters in descending order of parameters such as attack power, defense power, and HP is higher. Also, for example, the greater the number of items possessed by each player that can activate special effects or recover battle points, the higher the player's strength is set. Also, for example, the greater the number of times each player participates in or wins in the battle event, the higher the player's strength is set. Also, for example, the higher the score of each player in the past battle event, the higher the player's strength is set. By doing so, it is possible to distribute the players who are highly likely to be able to inflict great damage on the enemy character in a well-balanced manner.

Further, when the participation value is set to a value that decreases as the strength of each player in the battle event increases, the upper limit of the total participation value cannot be divided by the participation value set for the weak player, and the remainder is the strong player's participation value. It is set to a value equal to or greater than the participation value set for the player. For example, if the upper limit of the total participation value is set to 18, the participation value of the weak player is set to a value that is not divisible by 18, such as 10, and the participation value of the strong player is set to 18 by dividing 10, such as 1. Set to a value less than or equal to the remainder of the division (8). As a result, not only weak players participate in the competition event, but also strong players can participate without fail. Conversely, if the lower the strength of each player in the battle event, the lower the participation value, the upper limit of the total participation value should be set to a value that is not divisible by the participation value set for the stronger player. By doing so, even players who are weak in the battle event can certainly participate.

Note that the upper limit of the total participation value may be set according to at least one of a predetermined battle situation, parameters of the enemy character, and parameters of the character of the requesting player. The predetermined battle situation includes at least one situation of a battle with a predetermined enemy character, a battle in which a predetermined player participates, and a battle involving a combination of predetermined enemy characters and players. For example, the upper limit is set in at least one of a battle with a predetermined enemy character, a battle in which a predetermined player participates, and a battle involving a combination of predetermined enemy characters and players, and the upper limit in other battles. set to a value higher than Alternatively, the upper limit value is the upper limit value in at least one of a battle with a predetermined enemy character, a battle in which a predetermined player participates, and a battle involving a combination of a predetermined enemy character and player, and in other battles. may be set to a lower value than As a result, it is possible to improve the gameplay in the battle event.

Also, for example, the upper limit is set to a lower value as the enemy character's attack power, defense power, HP, and other parameters are higher. As a result, only stronger players participate in a battle event in which a player fights against a strong enemy character, so that the possibility of winning against the enemy character can be increased. Also, for example, the upper limit value is set to a higher value as the parameters such as 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, weak players participate in the battle event, and if the requesting player is weak, strong players participate in the battle event. It becomes possible to

Also, the upper limit of the total participation value may be changed according to the passage of time after 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, it is possible to add a player who participates in the battle event when the enemy character is not defeated within a certain period of time, and the possibility of winning the enemy character can be increased.

The classification unit 336 classifies each player into a plurality of groups based on the order in which each player accessed the battle event. The classification unit 336 allocates each player to each group according to the order in which the actions are performed when each player performs a specific action in the battle event. For example, the classification unit 336 allocates the player of the portable terminal 2 that first transmitted the event screen request to group 1 , and then allocates the player of the portable terminal 2 that transmitted the event screen request to group 2 . Thereafter, the classification unit 336 allocates the player of the portable terminal 2 that has transmitted the event screen request to the group following the group to which the player was allocated immediately before. The classification unit 336 assigns each player to each group by adding the player ID of each player as the belonging player ID of each group in the group table.

Further, if the player of the mobile terminal 2 that has sent the event screen request already belongs to a specific group, that is, if the player's mobile terminal 2 has sent an event screen request for the second or subsequent time, the classification unit 336 Removes the player from the group he belongs to and assigns him to the group following the group to which he was previously assigned. As a result, each group is classified so that the latest times at which the players belonging to the group accessed the battle event are evenly distributed.

Note that the classification unit 336 may classify the players in the order in which the access time of each player to the competition event is closest to the current time. In this case, Group 1 includes a predetermined number of players whose access time is closest to the current time, Group 2 includes a predetermined number of players whose access time is next closest to the current time, and Group N includes a predetermined number of players whose access time is next closest to the current time. , a predetermined number of players whose access time is furthest from the current time. In addition, the participation request notification unit 334 notifies requests for participation in the battle event in order from the players included in group 1, that is, in order from the players whose access time is closest to the current time. As a result, the participation request can be sent preferentially to players who are likely to participate in the battle event, so that the number of players participating in the battle event can be secured early.

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

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

Also, 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 strength of the players included in each group is evenly distributed. As a result, the strength of the players participating in the battle event is prevented from becoming extremely unbalanced, and the game balance is prevented from being lost.

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

Alternatively, the classification unit 336 may classify each player into each group in descending order of participation rate in the battle event of the players included in each group. In this case, the participation request notification unit 334 notifies the participation request to the battle event in order from the players included in group 1, that is, in order from the player with 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 who will participate in the battle event at an early stage. Alternatively, the participation request notification unit 334 may send requests to participate in the battle event in order from the players included in group N, that is, in order from the players with the lowest participation rate in the battle event. As a result, participation requests are preferentially notified to players who are less likely to participate in the battle event, and the battle event can be activated.

Also, in this embodiment, a player who has already participated in a specific battle event is restricted from participating in another battle event. Therefore, when the portable terminal 2 of a player participating in the battle event transmits an 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 some 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 allocated as the player with the latest access time.

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

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 browsing execution unit 251 of the mobile terminal 2 sends an event screen request to the terminal. It is transmitted to the server 3 via the communication section 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 display data for the event screen 410 (step S102). Next, the battle executing section 333 transmits the created display data to the portable terminal 2 (step S103). When 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 being 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 section 21 (step S105). When the progress control unit 331 of the server 3 receives a search request from the mobile terminal 2, the battle execution unit 333 executes a lottery to determine whether or not the player has found an enemy character, and the found enemy character and its level. (step S106). Next, the battle execution unit 333 creates display data for the battle preparation screens 420 and 440 or the event screen 410 depending on whether the player has found an enemy character (step S107). Next, the battle executing unit 333 transmits the created display data to the mobile terminal 2 (step S108). When 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 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 being displayed on the display unit 24 of the mobile terminal 2, the viewing execution unit 251 of the mobile terminal 2 starts the battle. A 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 battle processing (step S111). Details of the battle process will be described later. Next, the battle execution section 333 creates display data of the battle effect image 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 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 the battle effect image and the battle on the display unit 24 . The result screen 500 or 510 is displayed (step S114).

After that, when the game preparation screens 420 and 440 are displayed again on the display unit 24 of the mobile terminal 2 and the player presses the participation request button 429 using the operation unit 23, the browsing execution unit 251 of the mobile terminal 2 A participation request is sent 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 from the mobile terminal 2, the participation request notification unit 334 executes participation request processing (step S116). The details of the participation request process will be described later. Next, the participation request notifier 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 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 the battle preparation screens 420 and 440 on the display unit 24 . is displayed (step S119). With this, the operation sequence relating to the game processing is completed.

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

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 viewing execution unit 251 of the mobile terminal 2 sends a list screen request to the terminal. It is transmitted to the server 3 via the communication section 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 display data for 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 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). With this, the operation sequence related to the list screen display ends.

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

First, while the event screen 410 or the list screen 520 is displayed on the display unit 24 of the mobile terminal 2 , when the player presses the battle execution buttons 411 and 412 or the selection button 522 using the operation unit 23 , The browsing execution unit 251 transmits a 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 participation reception processing (step S302). The details of the participation acceptance process will be described later. Next, the battle executing section 333 creates display data for the event screen 410 or the battle preparation screens 420 and 440 according to the result of the participation acceptance process (step S303). Next, the battle execution unit 333 transmits the created display data to the mobile terminal 2 (step S304). When 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 the event screen 410 or the battle preparation display on the display unit 24. Screens 420 and 440 are displayed (step S405). With this, the operation sequence relating to the joining process ends.

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

The battle executing unit 333 first extracts each piece of 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 point (step S402). If the consumption value is greater than the battle points (step S402-No), the battle execution unit 333 does not execute the battle event (step S403), and ends the series of steps. In this case, in step S112 of FIG. 9, the battle execution unit 333 displays the battle preparation screen indicating that the battle point is insufficient, instead of the display data of the battle effect image and the display data of the battle result screen 500 or 510. Create display data.

On the other hand, if 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). If the player is a participating player in the battle event (step S404-Yes), the battle execution unit 333 shifts the process to step S407. On the other hand, if the player is not a participating player of the battle event (step S404-No), the battle execution unit 333 determines whether the player is the discovering player of the battle event (step S405). If the player is not the player who discovered the battle event (step S405-No), the battle execution unit 333 does not execute the battle event (step S403), and ends the series of steps. In this case, in step S112 of FIG. 9, the battle execution unit 333 creates display data for a battle preparation screen indicating that the player has not participated in the battle event.

On the other hand, if the player is the player who discovered the battle event (step S405-Yes), the battle execution unit 333 allows the player to participate in the battle event (step S406). Next, the battle execution unit 333 executes a battle event (step S407). If the player loses in the battle event (step S408-No), the battle execution unit 333 ends the series of steps. In this case, in step S112 of FIG. 9, the battle executing section 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. FIG.

On the other hand, if the player wins the battle event (step S408-Yes), the battle execution unit 333 sets the end flag corresponding to the battle event to ON on 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 the series of steps. In this case, in step S112 of FIG. 9, the battle executing section 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.

FIG. 13 shows an operation flow of participation request processing by the participation request notifier 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 terminates the series of steps without notifying other players of the competition event participation request.

On the other hand, if the player is a requestable player, the participation request notification unit 334 identifies 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 a value obtained by adding the participation value of the extracted player to the total participation value of the battle event for which the participation request is notified exceeds a predetermined upper limit value (step S504). . If the added value is equal to or less than the upper limit (step S504-Yes), the participation request notification unit 334 notifies the player of a participation request for the battle event (step S505). On the other hand, if the added value exceeds the upper limit value (step S504-No), the participation request notification unit 334 does not notify the player of the request to participate in the battle event.

Next, the participation request notification unit 334 determines whether or not all players belonging to the specified group other than the requesting player 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 have been extracted (step S506-Yes), the participation request notification unit 334 stores the current time as the participation request start time of the identified match in the match table (step S507), and performs a series of steps. finish.

FIG. 14 shows the operation flow of the second participation request processing by the participation request notifier 334. As shown in FIG. The second participation request process shown in FIG. 14 is periodically executed after 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). If the target battle event is not being executed (step S601-No), the participation request notifier 334 terminates the series of steps. On the other hand, if the target battle event is being executed (step S601-Yes), the participation request notification unit 334 determines whether or not the notification time has passed since the previous participation request was notified (step S602). . If 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 and S602. On the other hand, if the notification time has passed (step S602-Yes), the participation request notification unit 334 selects a group for which a participation request has not yet been notified (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). If the added value is equal to or less than the upper limit (step S605-Yes), the participation request notification unit 334 notifies the player of a participation request for the battle event (step S606). On the other hand, if the added value exceeds the upper limit (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 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 have been extracted (step S607-Yes), the participation request notification unit 334 ends the series of steps.

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

The participation reception unit 335 first determines whether the player is the player who discovered the battle event or the player who was notified of the participation request (step S701). If the player is the player who discovered the battle event or the player who was notified of the participation request (step S701-Yes), the participation accepting unit 335 determines whether the battle event is in progress (step S702). If the battle event is in progress (step S702-Yes), the participation reception unit 335 determines whether the number of participating players participating in the battle event is less than the upper limit of the number of players (step S703). If the number of participating players is less than the upper limit of the number of players (step S703-Yes), the participation receiving unit 335 adds the participation value of the extracted player to the total participation value of the target battle event. It is determined whether or not the value exceeds the value (step S704). If the added value is equal to or less than the upper limit (step S704-Yes), the participation accepting unit 335 accepts the player's participation in the battle event (step S705), and ends the series of steps.

On the other hand, if the player is not the player who discovered the battle event or the player who was 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 exceeds the upper limit of 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 request to participate in the battle event and performs a series of steps. exit.

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

The classification unit 336 first determines whether or not a player who has performed a specific action in the battle event is participating in the battle event (step S801). If the player is participating in the battle event (step S801-Yes), the classification unit 336 ends the series of steps without performing any particular processing. On the other hand, if the player has not participated in the battle event (step S801-No), the classification unit 336 determines whether 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 assigns the player to the group next to the group to which the player was assigned immediately before (step S804), ending the series of steps.

As described above, the server 3 classifies a plurality of players into a plurality of groups, sequentially selects a group each time the notification time elapses, and requests the players included in the selected group to participate in the battle event. to notify you. This prevents a large number of players from rushing into the battle event, and even if each player notified of the participation request does not notice the participation request, the number of participants is ensured. 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 participation value set for each player participating in the battle event does not exceed the upper limit value. As a result, in the battle event, it is suppressed that only strong players participate and the enemy characters are easily defeated, and conversely, only weak players participate and the enemy characters are prevented from being defeated. can be maintained.

In addition, not only limited players such as players belonging to the same group as the requesting player and friends of the requesting player but also all players are notified of the request to participate in the battle. , it is possible to expand communication between players.

In addition, the present invention is not limited to this 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 take part of 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 displayed by native applications installed on the mobile terminal 2. Native display displayed by

It should be understood by those skilled in the art that various changes, substitutions and modifications can be made thereto without departing from the spirit and scope of the present 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 competition execution unit 334 participation request notification unit 335 participation reception unit 336 classification unit

Claims (6)

A game control method in a computer having a storage unit and executing a competitive game,
storing in the storage unit, for each of a plurality of players, setting values that are set based on items associated with each player;
starting a match between the game content of the specific player and the enemy game content in accordance with a request from a specific player among the plurality of players;
Notifying other players of the plurality of players of a request to participate in the match according to a request from the specific player;
Accepting the other player's participation in the competition within a range in which the sum of the set values set for each player participating in the competition does not exceed a predetermined upper limit;
A game control method including: The predetermined upper limit value is set to a value that is not evenly divisible by a first set value and the remainder of dividing the predetermined upper limit value by the first set value is equal to or greater than a second set value. Item 1. A game control method according to item 1. 3. The predetermined upper limit value according to claim 1 or 2 , wherein the predetermined upper limit value is set according to at least one of a predetermined competition situation, a parameter of the enemy game content, and a parameter of the game content of the specific player. game control method. 4. The game control method according to any one of claims 1 to 3 , wherein said predetermined upper limit value is changed according to the elapse of time after said match is started. A computer that executes a battle game,
a storage unit that stores, for each of a plurality of players, setting values that are set based on items associated with each player;
a battle execution unit for starting a battle between the game content of the specific player and the enemy game content in accordance with a request from a specific player among the plurality of players;
a participation request notification unit that notifies other players of the plurality of players of a request to participate in the competition in accordance with a request from the specific player;
a participation reception unit that accepts participation in the competition by the other players within a range in which the total of the set values set for each player participating in the competition does not exceed a predetermined upper limit;
A computer comprising: A control program for a computer that includes a storage unit and executes a competitive game,
storing in the storage unit, for each of a plurality of players, setting values that are set based on items associated with each player;
starting a match between the game content of the specific player and the enemy game content in accordance with a request from a specific player among the plurality of players;
Notifying other players of the plurality of players of a request to participate in the match according to a request from the specific player;
Accepting the other player's participation in the competition within a range in which the sum of the set values set for each player participating in the competition does not exceed a predetermined upper limit;
A control program for causing the computer to execute

Images