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

Description

Article 30, paragraph 2 of the Patent Act applies. Website address: http://jp.apps.gree.net/ja/96 https://itunes.apple.com/jp/app/diaorisuta/id465588102?mt=8 https://play.google.com/store/apps/details?id=jp.gree.android.pf.greeapp96 Posted on: September 19, 2014

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

In recent years, servers that provide games to mobile devices via communication networks have become widespread. Games provided by such servers include those in which multiple players can participate (so-called "social games"). In such social games, for example, events are held in which players participating in the social game battle each other using characters, items, etc. owned by each player, and points are awarded to each player depending on the results of the battle.

When holding such an event, the server determines the match pairings for each player participating in the social game. However, since not all players are always participating in a social game, when all players are paired together, there are many cases where a match cannot be made because both players are not present.

In response to this, for example, by pairing only players who have requested to participate in advance, it is possible to improve the rate at which each pairing results in a match.

Patent document 1 discloses a network game system that matches players who have requested a competitive game by operating a terminal device with each other, and allows the two matched players to play a competitive game.

JP 2007-229329 A

In the network game system of Patent Document 1, a battle begins as soon as matching is established. Of the two players who have been matched, the player who entered later is likely to notice that the battle has started because the battle begins immediately after entry, but the player who entered earlier may not notice that the battle has started because the battle may begin a long time after entry.

The present invention was made to solve these problems, and aims to provide a game control method, computer, and control program that can prevent unfairness between players.

A game control method according to the present invention is a game control method in a computer having a memory unit and an output unit, which plays a game in which players battle each other using game media owned by the players, and includes: storing a first time and a second time after the first time in the memory unit in advance; accepting requests to participate in the battle from a plurality of players; determining battle pairings for the battle between players whose participation requests have been accepted by the first time and a closing time for acceptance; outputting display data to the output unit, after the first time, for displaying a game screen that notifies players related to the determined battle pairings of the time remaining until the second time; and executing the battle related to the battle pairings from the second time.
The computer may be any type of computer capable of executing the above procedures, such as a mobile terminal, a fixed terminal, or a server.

In addition, in the game control method according to the present invention, it is preferable that the game screen includes information about the opponent player.

In addition, it is preferable that the game control method according to the present invention further includes outputting, to the output unit, display data for displaying a second game screen, prior to the first time, that notifies the player who has accepted the participation request of the remaining time until the first time.

In addition, in the game control method according to the present invention, it is preferable that the battle pairings are determined based on first points awarded to each player in past battles and second points awarded to each player in another game different from the game.

In addition, in the game control method according to the present invention, it is preferable that the battle pairings are determined based on the number of consecutive wins each player has had in past battles.

In addition, it is preferable that the game control method according to the present invention further includes outputting to the output unit display data for displaying a third game screen that displays a first button for executing another game different from the game, and, if the player satisfies the conditions for participating in the battle, further displays a second button for accepting a participation request.

In addition, in the game control method according to the present invention, it is preferable to further output display data to the output unit for displaying a fourth game screen that displays the first button when the player does not meet the conditions for participating in the battle, and displays the second button without displaying the first button when the player meets the conditions for participating in the battle.

Furthermore, in the game control method according to the present invention, if the second button is not specified while it is displayed on the fourth game screen, it is preferable to display the first button without displaying the second button on the fourth game screen that is subsequently output, regardless of whether or not the player meets the conditions for participating in a battle.

In addition, it is preferable that the game control method according to the present invention further includes granting a bonus to a player when a message sent from the player to the opponent is accepted between the first time and the second time.

The computer according to the present invention is a computer for playing a game in which players battle each other using items, and includes a storage unit that prestores a first time and a second time after the first time, a participation request acceptance unit that accepts requests to participate in the battle from multiple players, a combination determination unit that determines a battle combination for a battle between players whose participation requests have been accepted by the first time and the end of acceptance time, an output unit that outputs display data for displaying a game screen that notifies players related to the determined battle combination of the time remaining from the first time until the second time, and a battle execution unit that executes the battle related to the battle combination from the second time.

The control program of the present invention is a control program for a computer having a memory unit and an output unit, for playing a game in which players battle each other using items, which causes the computer to previously store a first time and a second time after the first time in the memory unit, accept requests to participate in the battle from a plurality of players, determine battle pairings for a battle between players whose requests to participate have been accepted by the first time or before the end of acceptance time, output display data to the output unit for displaying a game screen that notifies players related to the determined battle pairings of the time remaining until the second time after the first time, and execute a battle related to the battle pairings from the second time.
Furthermore, a game control method according to the present invention is a game control method in a computer having a memory unit and an output unit, which plays a game in which a first battle is played by a player using game media owned by the player, and a second battle is played between a plurality of players using game media owned by the players, the method including: pre-storing in the memory unit a first time and a second time after the first time; accepting requests to participate in the second battle from a plurality of players; determining a battle combination for the second battle by players whose participation requests have been accepted by the first time or before a closing time of acceptance; when the first battle is executed in response to a request from a player after the first time, outputting to the output unit display data for displaying a game screen that notifies a player associated with the determined battle combination of the execution result of the first battle and the time remaining until the second time; and executing the second battle associated with the battle combination in accordance with an operation from the player associated with the battle combination after the second time.
In the game control method according to the present invention, it is preferable that the game screen includes information on the opponent player.
In addition, it is preferable that the game control method according to the present invention further includes outputting to an output unit, before the first time, display data for displaying a second game screen notifying the player who has accepted the participation request of the remaining time until the first time.
In addition, in the game control method according to the present invention, it is preferable that in determining the battle pairings, the battle pairings are determined based on the first points awarded to each player in the past second battle and the second points awarded to each player in the first battle.
In the game control method according to the present invention, it is preferable that the battle pairings are determined based on the number of consecutive wins that each player has had in the past second battles.
Furthermore, in the game control method of the present invention, it is preferable that the method further includes outputting display data to the output section for displaying a third game screen which displays a first button for executing the first battle and, if the player satisfies the conditions for participating in the second battle, further displays a second button for accepting a participation request.
Furthermore, in the game control method of the present invention, it is preferable that the method further includes outputting display data to the output unit for displaying a fourth game screen that displays the first button when the player does not satisfy the conditions for participating in the second battle, and that displays the second button without displaying the first button when the player satisfies the conditions for participating in the second battle.
Furthermore, in the game control method of the present invention, if the second button is not specified while it is displayed on the fourth game screen, it is preferable that the first button is displayed without displaying the second button on the fourth game screen that is subsequently output, regardless of whether or not the player meets the conditions for participating in the second battle.
In addition, it is preferable that the game control method according to the present invention further includes granting a bonus to the player when a message is received from the player to the opponent between the first time and the second time.
Further, a computer according to the present invention is a computer for playing a game in which a first battle is played by a player using game media owned by the player, and a second battle is played between multiple players using items, and the computer is equipped with: a memory unit that pre-stores a first time and a second time after the first time; a participation request receiving unit that receives requests to participate in the second battle from multiple players; a combination determination unit that determines a battle combination for the second battle by players whose participation requests have been received by the first time and by the end of reception time; an output unit that, when the first battle is executed in response to a request from a player after the first time, outputs display data for displaying a game screen that notifies a player associated with the determined battle combination of the execution result of the first battle and the time remaining until the second time; and a battle execution unit that executes the second battle associated with the battle combination in accordance with an operation from the player associated with the battle combination after the second time.
Furthermore, a control program according to the present invention is a control program for a computer having a storage unit and an output unit, for playing a game in which a first battle is played by players using game media owned by the players, and a second battle is played between players using items, the control program causing the computer to previously store a first time and a second time after the first time in the storage unit, accept requests to participate in the second battle from a plurality of players, determine a battle pairing for the second battle by the first time or before the acceptance closing time for players whose requests to participate are accepted, and when the first battle is executed in response to a request from a player after the first time, output display data to the output unit for displaying a game screen that notifies a plurality of players associated with the determined battle pairing of the execution result of the first battle and the time remaining until the second time, and after the second time, execute the second battle associated with the battle pairing in accordance with an operation from the player associated with the battle pairing.
Furthermore, a game control method according to the present invention is a game control method in a computer that has a storage unit and an output unit and plays a game in which a plurality of battles are executed, the method comprising: storing in the storage unit in advance a first time at which a process of determining a battle pairing for the first battle by a player who has accepted a participation request for a first battle of the plurality of battles is completed and a second time at which the first battle can be started after the first time; accepting requests to participate in the first battle of the plurality of battles from the plurality of players, determining a battle pairing for the first battle by a player whose participation request has been accepted by a reception closing time by the first time; outputting to the output unit display data for displaying a game screen that notifies a player associated with the determined battle pairing of the remaining time until the second time after the first time; executing the first battle associated with the battle pairing after the second time; accepting requests to participate in a second battle of the plurality of battles from a player other than the player whose participation request has been accepted immediately after the reception closing time, and determining a battle pairing for the second battle by a player whose participation request has been accepted.
In the game control method according to the present invention, it is preferable that the game screen includes information on the opponent player.
In addition, it is preferable that the game control method according to the present invention further includes outputting to an output unit, before the first time, display data for displaying a second game screen that notifies the player who has accepted the participation request of the remaining time until the first time.
In addition, in the game control method according to the present invention, in determining the battle pairings, it is preferable to determine the battle pairings based on first points awarded to each player in a past battle among the multiple battles, and second points awarded to each player in another game different from the game.
In the game control method according to the present invention, it is preferable that in determining the battle pairings, the battle pairings are determined based on the number of consecutive wins each player has had in past battles among a plurality of battles.
In addition, it is preferable that the game control method of the present invention further includes outputting to the output unit display data for displaying a third game screen which displays a first button for executing another game different from the game, and, when the player satisfies the conditions for participating in multiple battles, further displays a second button for accepting a participation request.
Furthermore, it is preferable that the game control method of the present invention further includes outputting display data to the output section for displaying a fourth game screen which displays the first button when the player does not satisfy the conditions for participating in multiple battles, and which displays the second button without displaying the first button when the player satisfies the conditions for participating in multiple battles.
Furthermore, in the game control method according to the present invention, if the second button is not specified while being displayed in the fourth game screen, it is preferable to display the first button without displaying the second button in the fourth game screen that is subsequently output, regardless of whether or not the player satisfies the conditions for participating in multiple battles.
In addition, it is preferable that the game control method according to the present invention further includes granting a bonus to the player when a message is received from the player to the opponent between the first time and the second time.
Further, a computer according to the present invention is a computer for playing a game in which a plurality of battles are executed, the computer comprising: a storage unit that prestores a first time at which a process for determining a battle pairing for the first battle by a player who has accepted a participation request for a first battle of the plurality of battles is completed and a second time at which the first battle can be started after the first time; a participation request accepting unit that accepts requests to participate in the first battle of the plurality of battles from the plurality of players; a combination determination unit that determines, by the first time, a battle pairing for the first battle by a player whose participation request has been accepted by the acceptance end time; an output unit that outputs display data for displaying a game screen that notifies a player associated with the determined battle pairing of the remaining time until the second time after the first time; and a battle executing unit that executes the first battle associated with the battle pairing after the second time, wherein the participation request accepting unit accepts requests to participate in a second battle of the plurality of battles from a player other than the player who accepted the participation request immediately after the acceptance end time, and the combination determination unit determines a battle pairing for the second battle by a player whose participation request has been accepted for the second battle.
Further, a control program according to the present invention is a control program for a computer having a storage unit and an output unit, for playing a game in which a plurality of battles are executed, the control program causing the computer to execute the following: storing in the storage unit in advance a first time at which a process of determining a battle pairing for the first battle by a player who has accepted a participation request for a first battle of the plurality of battles is completed, and a second time after the first time at which the first battle can be started; accepting requests to participate in the first battle of the plurality of battles from a plurality of players, determining a battle pairing for the first battle by a player whose participation request has been accepted by the acceptance end time, by the first time; outputting to the output unit display data for displaying a game screen that notifies a player associated with the determined battle pairing of the remaining time until the second time after the first time; executing the first battle associated with the battle pairing after the second time; accepting requests to participate in a second battle of the plurality of battles from a player other than the player whose participation request has been accepted, immediately after the acceptance end time, and determining a battle pairing for the second battle by a player whose participation request has been accepted.

In the game control method, computer, and control program according to the present invention, matchups are determined only for players who have received a request to participate in a battle, making it possible to improve the rate at which battles are established. In addition, because matchup determination and each battle are executed at a predetermined time, it is possible to prevent unfairness between players. Furthermore, after the time at which matchup determination is completed, each player is notified of the time remaining until the start of the battle, making it possible to prevent a decrease in the participation rate in battles and improve the rate at which battles are established.

FIG. 1 is a diagram illustrating an example of a schematic configuration of a game system. FIG. 2 is a diagram illustrating an example of a schematic configuration of a mobile terminal. FIG. 2 is a schematic diagram for explaining a game provided by the game system. 11A to 11C are diagrams showing examples of screens displayed on a mobile terminal. 13A and 13B are diagrams showing an example of a screen displayed on a mobile terminal. 11A to 11D are diagrams showing examples of screens displayed on a mobile terminal. 11A to 11C are diagrams showing examples of screens displayed on a mobile terminal. FIG. 2 illustrates an example of a schematic configuration of a server. 4A to 4C are diagrams illustrating an example of the data structure of each table. FIG. 11 is a diagram showing an example of an operation sequence of the game system. FIG. 11 is a diagram illustrating an example of an operational flow of a home screen display data creation process. FIG. 11 is a diagram illustrating an example of an operational flow of a battle process. FIG. 11 illustrates an example of an operation flow of entry processing. FIG. 11 is a diagram illustrating an example of an operation flow of a matching process.

Various embodiments of the present invention will be described below with reference to the drawings. However, please note that the technical scope of the present invention is not limited to these embodiments, but extends to the inventions described in the claims and their equivalents.

1. Overview of the Present Embodiment In the game system of the present embodiment, a player uses a mobile terminal to play a game provided by a server. In the game system of the present embodiment, the server provides a web game.

In web games, the mobile device displays various game screens based on information (documents written in markup languages, programs written in scripting languages, etc.) received from the server via the browser. The server also updates game data and sends information to the mobile device based on information sent from the mobile device via the browser.

The games provided by the server include a main game and sub-games, which are games different from the main game. The main game is, for example, a single-player game in which the player takes on quests, missions, etc., and repeatedly battles various NPCs (Non Player Characters). Quests and missions are games in which multiple dungeons each have multiple floors (stages), and processing for each floor is executed sequentially. Processing for each floor includes battles, acquisition of game media, etc. The player can execute the main game by switching to the sub-game or simultaneously, even while the sub-game is being executed.

In this embodiment, a game in which players battle each other using characters owned by each player will be described as an example of a main game and a sub game. A normal battle is executed in the main game. By executing a normal battle, entry points required for applying (entering) to participate in the sub game are granted to the player, and when the entry points reach a predetermined value or more, the player becomes able to participate in the sub game. In the sub game, a battle between players is executed as an event. Hereinafter, a battle executed in the sub game may be referred to as an event battle. By executing an event battle, event points are granted to the player, and depending on the event points, benefits such as items usable in the main game are granted to the player.

The characters used in each battle are an example of game media. Game media is electronic data used in the game, and includes, for example, cards, items, characters, and avatars. Game media is also electronic data that can be acquired, possessed, used, managed, exchanged, synthesized, strengthened, sold, discarded, and/or gifted by the player in the game as the game progresses, but the manner in which the game media is used is not limited to those explicitly stated in this specification.

In this embodiment, cards registered in the game system in advance will be described as an example of game media. The player's character or enemy character cards used in battle have battle parameters. The battle parameters are, for example, attack power, defense power, stamina (or HP (hit points)), attributes (e.g., fire, water, lightning, etc.), rarity (e.g., normal, rare, S (super) rare, SS (double super) rare, SSS (triple super) rare, legend, etc.), skill (special effect) activation rate, attack speed (number of attacks in one turn, number of turns until attack, etc.), number of defenses in one match, and/or job (e.g., occupation, type of soldier, etc.).

The main game is not limited to battles between players, but may be a so-called raid battle in which multiple players cooperate to fight enemy characters (so-called non-player characters), or a quest that progresses according to a game scenario.

In the sub-game, the matchups for each player who has requested entry into the event battle before a predetermined period of time are determined, and the event battle is carried out after the period has elapsed. Also, in the sub-game, during that period, the time remaining until the start time of the event battle is notified to each player involved in the determined matchups.

In this way, by determining matchups only for players who have requested entry, the rate at which event battles are successful is improved. Also, by waiting a certain period of time after the matchups are determined and then executing the event battles, players are provided with time to prepare for the event battles. Also, by determining matchups and executing each event battle within a predetermined period, regardless of when each player requested entry, unfairness between players is prevented. Also, by notifying each player of the time remaining until the start of the event battle during a certain period from when the matchups are determined until the execution of the event battle, a decrease in the participation rate in event battles is suppressed, and the rate at which event battles are successful is improved.

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

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

Note that the mobile terminal 2 is assumed to be a multi-function mobile phone (a 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 is applicable, such as a mobile phone (a so-called "feature phone"), a personal digital assistant (PDA), a portable game console, a portable music player, a tablet terminal, a tablet PC, a notebook PC, etc.

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

The mobile device 2 includes a device communication unit 21, a device storage unit 22, an operation unit 23, a display unit 24, and a device processing unit 25. The mobile device 2 requests the server 3 to progress in the game in response to the operation of the operation unit 23 (touch panel, buttons, etc.) by the player. The mobile device 2 also receives and displays display data related to the progress of the game from the server 3.

The terminal communication unit 21 has a communication interface circuit including an antenna sensitive to a specific frequency band, and connects the mobile terminal 2 to a wireless communication network. The terminal communication unit 21 establishes a wireless signal line with the base station 4 by a CDMA (Code Division Multiple Access) method or the like via a channel assigned by the base station 4, and communicates with the base station 4. The terminal communication unit 21 then transmits data supplied from the terminal processing unit 25 to the server 3 or the like. The terminal communication unit 21 also supplies data received from the server 3 or the like to the terminal processing unit 25. The terminal communication unit 21 may also perform wireless communication with a Wi-Fi (Wireless Fidelity) access point (not shown) by a wireless communication method conforming to the IEEE 802.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 in the processing in the terminal processing unit 25. For example, the terminal storage unit 22 stores, as driver programs, an input device driver program for controlling the operation unit 23, an output device driver program for controlling the display unit 24, etc. The terminal storage unit 22 also stores, as application programs, programs for acquiring and displaying display data related to the progress of the game, etc. The computer program may be installed in the terminal storage unit 22 from a computer-readable portable recording medium such as a CD-ROM (compact disk read only memory) or a DVD-ROM (digital versatile disk read only memory) using a known setup program, etc. The computer program may also be installed in the terminal storage unit 22 from a specific server device, etc. via wireless communication. The terminal storage unit 22 also stores, as data, a player ID, which is identification information of the user of the portable terminal 2, display data related to the progress of the game, video data, image data, etc. Furthermore, the device storage unit 22 may temporarily store temporary data related to a specific process.

The operation unit 23 may be any device capable of operating the mobile terminal 2, such as a touch panel or 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 then supplied to the device processing unit 25 as an instruction from the player.

The display unit 24 may be any device capable of displaying video, images, etc., such as a liquid crystal display or an organic EL (Electro-Luminescence) display. The display unit 24 displays video corresponding to video data supplied from the device processing unit 25, images corresponding to image data, etc.

The device processing unit 25 includes one or more processors and their peripheral circuits. The device processing unit 25 is, for example, a CPU (Central Processing Unit), and controls the overall operation of the mobile device 2. The device processing unit 25 controls the operation of the device communication unit 21, the display unit 24, etc. so that various processes of the mobile device 2 are executed in an appropriate order based on the programs stored in the device storage unit 22, the operation of the operation unit 23, etc. The device processing unit 25 executes processes based on the programs (operating system programs, driver programs, application programs, etc.) stored in the device storage unit 22. The device processing unit 25 can also execute multiple programs (application programs, etc.) in parallel.

2.1.1. Functions of the Terminal Processing Unit 25 FIG. 3 is a schematic diagram for explaining the games provided by the game system 1. As shown in FIG.

As shown in FIG. 3, in the sub-game by the game system 1, event battles A to C are held at predetermined times. In the game system 1, for each event battle, an entry start time 301 at which acceptance of applications (entries) to participate in each event battle from each player begins, an entry end time 302 at which acceptance of entries ends, a matching completion time 303 at which the process of determining (matching) battle pairings for each entered player is completed, an event battle start time 304 at which the event battle related to each determined battle pairing begins, and an event battle end time 305 at which each event battle ends are determined in advance.

The period from the entry start time 301 to the entry end time 302 is set as an entry period 311 during which applications to participate in each event battle are accepted. On the other hand, the period from the entry end time 302 to the matching completion time 303 is set as a matching period 312 during which matching processing is carried out. On the other hand, the period from the matching completion time 303 to the event battle start time 304 is set as a notification period 313 during which each player involved in the determined battle combination is notified of the time remaining until the event battle start time. On the other hand, the period from the event battle start time 304 to the event battle end time 305 is set as an implementation period 314 during which the event battle is implemented.

When the entry period for event battle A ends, the entry period for the next event battle B begins, and players who are unable to enter in time for the entry period for event battle A can enter event battle B. Also, when the implementation period for event battle A ends, the implementation period for the next event battle B begins. In this way, some event battle is always being held in the sub-game.

In the sub-game, match-ups are determined only for players who have accepted a request to participate in an event battle, which makes it possible to improve the rate at which event battles are successful. In addition, since the event battle is held a certain period of time after the match-ups are determined, players are given time to prepare for the event battle. Furthermore, regardless of when each player enters during the entry period, match-ups are determined and each event battle is held within a predetermined period of time, which makes it possible to prevent unfairness between players.

In addition, during the notification period 313, that is, after the matching completion time, each player is notified of the time remaining until the event battle start time, so it is possible to prevent each player from forgetting that they have entered the battle, losing interest in the battle, or not realizing that the battle has started between the time they enter the battle and the time the battle starts. This makes it possible to prevent a decrease in the participation rate in event battles and to increase the rate at which event battles are successful.

Figures 4(a)-(c) and 5(a)-(b) are diagrams showing examples of home screens displayed on the display unit 24. Each of the home screens shown below is a screen that is displayed while playing the main game.

The home screen 400 shown in FIG. 4(a) is the normal home screen that is displayed when the player does not meet the conditions for participating in an event battle, such as when the game starts. Each screen described below is displayed based on the display data received from the server 3.

The home screen 400 displays event points 401, rankings 402, entry status 403, number of possible entries 404, entry point gauge 405, battle button 406, etc.

The event points 401 are the cumulative value of event points given to the player in all past event battles. The ranking 402 is the ranking of the player when all players are arranged in descending order of the event points 401. The status 403 indicates whether the player is not yet able to enter the event battle, is able to enter, or has already entered. The number of possible entries 404 indicates the remaining number of times the player can enter the event battle. The number of times the player can enter the event battle in a specified period is limited to a specified number (for example, 10 times per day). The entry point gauge 405 displays the current value of the entry points acquired by the player in the main game in a bar graph, and when the entry points in the entry point gauge 405 reach 100%, the player is able to enter the event battle. In addition, the current value/maximum value of the entry points are displayed in numbers below the entry point gauge 405. The battle button 406 is a button for executing a normal battle, and when the battle button 406 is pressed, a normal battle is executed.

On the home screen 400, the entry point in the entry point gauge 405 is not at 100%, and state 403 indicates that the player cannot yet enter the event battle.

The home screen 410 shown in FIG. 4(b) is an entry home screen that is displayed when the player meets the conditions for participating in an event battle.

On the home screen 410, the entry point in the entry point gauge 405 is at 100%, and the status 413 indicates that the player is able to enter the event battle. Also, in addition to the various information and buttons shown on the home screen 400, the home screen 410 displays an entry button 417. The entry button 417 is a button for accepting a request to participate in the event battle, and when the entry button 417 is pressed, the player is entered into the event battle.

The home screen 420 shown in FIG. 4(c) is the home screen displayed when the player has already entered the event battle.

On the home screen 420, the entry point in the entry point gauge 405 becomes 100%, and the status 423 indicates that the player has already entered the event battle. Furthermore, the entry button 417 shown on the home screen 410 is not displayed on the home screen 410. Furthermore, instead of the number of possible entries 404, the home screen 410 displays the remaining time 424 until an opponent is determined, i.e., until the matching completion time, and notifies the player who has accepted the entry.

By displaying the time remaining until matching is complete, players can be prevented from forgetting that they have entered an event battle, and it is possible to maintain players' interest in the event battle.

The home screen 500 shown in FIG. 5(a) is a home screen for event notification that is displayed when matching is complete.

In addition to the event points 401, rankings 402, and battle button 406 shown on the home screen 400, the home screen 500 also displays the status 508 regarding the event battle, and information 509 regarding the player and the opponent player.

Status 508 indicates whether the event battle has not yet started or has already started. If the event battle has not yet started, status 508 also displays the time remaining until the event battle starts, and if the event battle has already started, it also displays the time remaining until the event battle ends, and each is notified to the players associated with the determined battle combination. On the home screen 500, the event battle has not yet started, and status 508 indicates that the event battle has not yet started and the time remaining until the event battle starts. Information 509 includes each player's player name, image, number of wins and losses in the event, etc. Note that when the battle button 406 is pressed on the home screen 500, a normal battle is executed.

By displaying the time remaining until the start of the event battle, it is possible to prevent the event battle from starting without the player realizing it, and to maintain the player's interest in the event battle. In addition, by displaying information about the opponent player, the player can guess the character the opponent player will use before the event battle starts, and select a character with advantageous attributes against that character as the character to be used by the player himself. In addition, if the player guesses that he will not be able to defeat the opponent player's character, he can devise a strategy such as purchasing a character or item that will enable him to win.

The home screen 510 shown in FIG. 5(b) is the home screen displayed when an event battle is in progress and an event battle has started.

On the home screen 510, the event battle has already started, and status 508 indicates that the event battle has already started and the time remaining until the end of the event battle. Note that when the battle button 516 is pressed on the home screen 510, an event battle will be held instead of a normal battle.

Figure 6(a) shows an example of a battle screen displayed on the display unit 24.

The battle screen 600 shown in FIG. 6(a) is displayed when the battle button 406, 516 is pressed on the home screens 400-510 shown in FIGS. 4(a)-(c) and 5(a)-(b). The battle screen 600 is displayed in common for both normal battles and event battles.

The battle screen 600 displays information 601 about the player and the opponent player, a battle button 602, etc. In the case of a normal battle, the opponent player is automatically selected by the server 3. In the case of a normal battle, the opponent player may be selected by the player from multiple players automatically selected by the server 3. On the other hand, in the case of an event battle, the opponent player is the opponent player determined by the matching process. The information 601 includes each player's player name, an image of the card of the character to be used, HP, etc. The battle begins when the battle button 602 is pressed.

In a battle, the amount of damage to be inflicted on the opponent player's character is determined based on the attack power of the player's character in accordance with the player's operation, and the determined amount of damage is subtracted from the HP of the opponent player's character. Meanwhile, the amount of damage to be inflicted on the player's character is determined based on the attack power of the opponent player's character in accordance with the opponent player's operation, and the determined amount of damage is subtracted from the HP of the player's character. If the opponent player's character's HP reaches 0 first, the player wins, and if the player's character's HP reaches 0 first, the player loses. Note that the player can select a specific action from actions such as normal attack, special attack, defense, etc., and the amount of damage inflicted on the opponent player or the amount of damage received from the opponent player changes depending on the action selected.

Figures 6(b)-(d) and 7(a)-(c) are diagrams showing examples of battle result screens displayed on the display unit 24. When the battle button 602 is pressed on the battle screen 600 shown in Figure 6(a), each battle result screen is displayed after a battle effect image showing the change in HP of the player's character and the opponent player's character or NPC is displayed by animation or the like.

The battle result screen 610 shown in FIG. 6(b) is the normal battle result screen that is displayed when the player does not meet the conditions for participating in an event battle.

The battle result screen 610 displays information 611 about the player and the opponent player, the result 612, a next battle button 613, a status 614 about entry, a back button 615, and the like. The information 601 includes the player's name, an image of the card of the character used, HP, and the like. Victory or defeat is displayed as the result 612. The next battle button 613 is a button for replaying the normal battle, and when the next battle button 613 is pressed, the battle screen 600 is displayed again. The status 614 indicates whether the player is not yet able to enter the event battle, is able to enter, or has already entered. If the player is not yet able to enter the event battle, the status 614 further displays the remaining entry points required for entry, and if the player has already entered the event battle, the remaining time until the event start time is further displayed. If the back button 615 is pressed, the home screen is displayed again.

In the battle result screen 610 shown in FIG. 6(b), status 614 indicates that the player is not yet able to enter the event battle, and the remaining entry points required to enter the event battle.

The battle result screen 620 shown in FIG. 6(c) is a battle result screen for entry that is displayed when the player meets the conditions for participating in an event battle.

The entry status 624 indicates that the player is in a state where they can enter the event battle. Furthermore, on the battle result screen 620, the next battle button 613 is not displayed, but the entry button 623 is displayed. The entry button 623 is a button for accepting a request to participate in the event battle, and when the entry button 623 is pressed, the player is entered into the event battle.

By displaying the entry button 623 and indicating that entry is possible on the battle result screen for a regular battle, players can immediately recognize that they have met the entry conditions in a regular battle and enter the event battle, which can increase the participation rate in event battles.

The battle result screen 630 shown in FIG. 6(d) is a battle result screen after entry is rejected, which is displayed when the subsequent normal battle ends if the entry button 623 is not selected while the battle result screen 620 shown in FIG. 6(c) is displayed.

On the battle result screen 630, the entry status 634 indicates that the player is able to enter the event battle, but regardless of whether the player meets the conditions for participating in the event battle, the entry button 623 is not displayed, and the next battle button 613 is displayed. If the entry button 623 has been displayed in the past but not pressed, it is highly likely that the player has no intention of entering the event battle. Therefore, in that case, convenience for the player can be improved by not displaying the entry button 623 in the future.

The battle result screen 700 shown in FIG. 7(a) is the battle result screen displayed when a player has already entered an event battle.

On the battle result screen 700, the entry status 704 indicates that the player has already entered the event battle and the time remaining until matching is completed.

By displaying the time remaining until matching is complete on the battle result screen for regular battles, players can be prevented from becoming so engrossed in the regular battle that they forget that they have entered an event battle.

The battle result screen 710 shown in FIG. 7(b) is a battle result screen for event notification that is displayed when matching is completed.

In the battle result screen 710, a status 714 regarding the event battle is displayed instead of the status regarding the entry. The status 714 indicates whether the event battle has not yet started or has already started. If the event battle has not yet started, the status 714 also displays the time remaining until the event start time, and if the event battle has already started, the status 714 also displays the time remaining until the end time of the event battle. In the battle result screen 710, the event battle has not yet started, and the status 714 indicates that the event battle has not yet started and the time remaining until the start time of the event battle. Note that when the Next Battle button 713 is pressed on the battle result screen 710, a normal battle is executed.

By displaying the time remaining until the event battle starts on the battle result screen of the regular battle, it is possible to prevent the player from becoming so engrossed in the regular battle that they don't realize the event battle has started.

The battle result screen 720 shown in FIG. 7(c) is a battle result screen during an event battle that is displayed when an event battle has started.

In the battle result screen 720, the event battle has already started, and status 724 indicates that the event battle has already started and the time remaining until the end of the event battle. Note that when the next battle button 713 is pressed in the battle result screen 720, an event battle will be executed instead of a normal battle.

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

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

2.2 Configuration of Server 3 Fig. 8 is a diagram showing an example of a schematic configuration of the server 3. Figs. 9(a) to 9(c) are diagrams showing examples of data structures of various tables stored in the server storage unit 32.

The server 3 includes a server communication unit 31, a server storage unit 32, and a server processing unit 33. The server 3 progresses the game in response to requests from the mobile device 2. The server 3 also creates display data related to the progress of the game and transmits it to the mobile device 2.

The server communication unit 31 is an example of an output unit, and includes a communication interface circuit for connecting the server 3 to the Internet 7, and communicates with the Internet 7. The server communication unit 31 supplies data received from the mobile device 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 device 2 or 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 by the server processing unit 33. For example, the server storage unit 32 stores, as an application program, a game program that progresses a game and creates display data related to the results. The computer program may be installed in the terminal storage unit 22 from a computer-readable portable recording medium such as a CD-ROM or DVD-ROM using a known setup program, etc.

The server storage unit 32 also stores data such as the player table shown in FIG. 9(a), the event table shown in FIG. 9(b), the card table shown in FIG. 9(c), image data of each player, various image data related to the progress of the game, etc. Furthermore, the server storage unit 32 may also temporarily store temporary data related to a specified process.

Figure 9 (a) shows a player table that manages players. In the player table, information such as the player's identification number (player ID), password, name, image data file name, owned card information, identification numbers of owned cards used in battles (usage IDs), battle points, entry points, number of possible entries, entry information, event result information, and player IDs of related players are stored in association with each other.

In the owned card information, for each card owned by the player and used in the game, an identification number (owned ID) for managing the card of the owned character, an identification number (card ID) of the card, the current value and level of experience points, etc. are stored in association with each other. The use ID is the owned ID of the card used in the battle among the cards included in the owned card information. The battle points are the accumulated value of points given to each player in past normal battles. The battle points are given to each player according to the result of the normal battle (victory or defeat, and the levels of the player and the opponent player, etc.). The entry points are the accumulated value of points given in the normal battle when a specific condition is met, such as the points given being a predetermined value or more, or defeating a player of a predetermined level or more. Note that if the main game is a raid boss battle, the specific condition is, for example, defeating a boss character, and if the main game is a quest, the specific condition is, for example, obtaining a specific item.

For each event battle held, the entry information stores an identification number (event ID) for managing the event battle, the entry status, a rejection flag, the opponent player's identification number (opponent ID), and other information in association with the event battle. The entry status indicates whether or not the event battle has been entered. The rejection flag indicates whether or not the back button 615 has been selected without the entry button 623 being selected on the battle result screen 620 in the past, i.e., whether or not the player has rejected the event, and the initial value indicates that the player has not rejected the event.

Event result information stores and associates event points, number of wins and losses, number of consecutive wins, etc. Event points are the cumulative value of points awarded to each player in all past event battles. The number of wins and losses is the cumulative value of the number of times a player has won and lost in all past event battles. The number of consecutive wins is the highest number of times a player has won in all past event battles.

Related players are other players related to the player. Examples of related players include other players who belong to the same group as the player, other players who are friends with the player, other players who have helped the player in a past battle with an enemy character, other players who have played against the player in the past, and/or other players who belong to a group that the player has played against in the past.

Figure 9 (b) shows an event table that manages event battles. In the event table, for each event battle, the event ID of the event battle, the entry start time, the entry end time, the matching completion time, the event battle start time, the event battle end time, etc. are stored in association with each other. For each event battle, the entry end time is a time later than the entry start time, the matching completion time is a time later than the entry end time, the event battle start time is a time later than the matching completion time, and the event battle end time is a time later than the event battle start time.

Figure 9 (c) shows a card table that manages character cards. The card table stores the card ID, name, image data file name, rarity, HP, attack power, defense power, attributes, etc. of each card in association with each other.

2.2.1 Configuration of the server processing unit 33 The server processing unit 33 includes a progress control unit 331, a display data output unit 332, a normal battle executing unit 333, an event battle executing unit 334, a participation request receiving unit 335, and a combination determination unit 336. Each of these units is a functional module realized by a program executed by a processor included in the server processing unit 33. Alternatively, each of these 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 display data output unit 332, the normal battle execution unit 333, the event battle execution unit 334, and the participation request acceptance unit 335 to execute processing. The progress control unit 331 exchanges necessary data with the mobile device 2 via the server communication unit 31.

When a request for each screen described using Figures 4(a) to 7(c) is received from the portable device 2, the progress control unit 331 instructs each unit to create display data for displaying buttons for receiving instructions from the player, text information notifying the player, images, etc. in a layout appropriate to that screen, and transmits that data to the portable device 2. Then, when a button is pressed on the screen displayed on the portable device 2 and a request for the next screen corresponding to that button is received from the portable device 2, the progress control unit 331 similarly instructs each unit to create display data for the next screen, and transmits that data to the portable device 2.

In particular, when the player uses the portable device 2 to start a game or transition to a home screen, and a corresponding home screen request is received from the portable device 2, the progress control unit 331 instructs the display data output unit 332 to create a home screen. Then, the progress control unit 331 transmits the home screen display data for displaying the home screen, created by the display data output unit 332, to the portable device 2.

In addition, when the battle button 406 is pressed on the home screen 400 displayed on the mobile device 2 and a corresponding battle request is received from the mobile device 2, the progress control unit 331 instructs the normal battle executing unit 333 to execute a normal battle when an event battle is not being held or the player is not participating in an event battle. On the other hand, when an event battle is being held and the player is participating in the event battle, the progress control unit 331 instructs the event battle executing unit 334 to execute an event battle. Then, the progress control unit 331 transmits battle screen display data for displaying the battle screen 600, created by the normal battle executing unit 333 or the event battle executing unit 334, to the mobile device 2.

In addition, when the battle button 602 is pressed on the battle screen 600 displayed on the mobile device 2 and a corresponding battle start request is received from the mobile device 2, the progress control unit 331 instructs the normal battle executing unit 333 to start a normal battle when an event battle is not being held or the player is not participating in an event battle. On the other hand, when an event battle is being held and the player is participating in the event battle, the progress control unit 331 instructs the event battle executing unit 334 to start an event battle. Then, the progress control unit 331 transmits to the mobile device 2 display data for displaying a battle performance image and battle result screen display data for displaying the battle result, which were created by the normal battle executing unit 333 or the event battle executing unit 334.

In addition, when the entry button 417 on the home screen 410 or the entry button 623 on the battle result screen 620 displayed on the mobile device 2 is pressed and a corresponding entry request is received from the mobile device 2, the progress control unit 331 instructs the participation request acceptance unit 335 to accept the entry. Then, the progress control unit 331 instructs the display data output unit 332 to create a home screen, and transmits the home screen display data created by the display data output unit 332 to the mobile device 2.

When the progress control unit 331 instructs the display data output unit 332 to create a home screen, it extracts from the event table the event battles currently in the entry period, the event battles currently in the matching period, the event battles currently in the notification period, and the event battles currently in the implementation period. The display data output unit 332 also identifies the player ID included in the home screen request, and extracts from the player table the entry status for each extracted event battle associated with the player corresponding to the identified player ID.

When a player has entered an event battle that is currently being held, the display data output unit 332 reads the opponent ID, the player, and the opponent player's event result information, etc. from the player table, and creates display data for displaying the home screen 510 during the event battle shown in FIG. 5(b). In other words, the display data output unit 332 creates display data for displaying the home screen 510 during the event battle after the event battle start time and before the event battle end time of the event battle in which the player has entered.

On the other hand, when a player has entered an event battle that is currently in the notification period, the display data output unit 332 reads the opponent ID, the player's and the opponent player's event result information, etc. from the player table, and creates display data for displaying the event notification home screen 500 shown in FIG. 5(a). That is, the display data output unit 332 creates display data for displaying the notification home screen 500 after the matching completion time of the event battle in which the player has entered and before the start time of the event battle. The notification home screen 500 is displayed from the matching completion time that is common to each player, regardless of the timing when each player entered the event battle or the timing when the matching of each player was determined, thereby preventing unfairness between players.

On the other hand, if the player is currently entered in an event battle during the entry period or matching period, the display data output unit 332 reads the player's event result information, etc. from the player table and creates display data for displaying the home screen 420 when the player has already entered, as shown in FIG. 4(c). In other words, the display data output unit 332 creates display data for displaying the home screen 420 when the player has already entered after the entry end time of the event battle in which the player has entered and before the matching completion time.

On the other hand, if none of the above applies, the display data output unit 332 reads the player's entry point and the number of possible entries from the player table, and determines whether or not the player can enter the event battle during the current entry period. If the entry point is equal to or greater than a predetermined point and the number of possible entries is greater than a predetermined number (e.g., 0), the display data output unit 332 determines that entry is possible, and if the entry point is less than the predetermined point or the number of possible entries is equal to or less than the predetermined number, it determines that entry is not possible. If the player can enter the event battle during the current entry period, the display data output unit 332 reads the player's event result information, etc. from the player table, and creates display data for displaying the entry home screen 410 shown in FIG. 4(b).

On the other hand, if the player is not eligible to enter the event battle during the current entry period, the display data output unit 332 reads the player's event result information, etc. from the player table and creates display data for displaying the normal home screen 400 shown in FIG. 4(a).

The display data output unit 332 passes the created display data to the progress control unit 331. In addition, the home screen request when the back button 615 is pressed on the battle result screen 620 shown in FIG. 6(c) includes a message indicating that the entry has been rejected. If the home screen request includes a message indicating that the entry has been rejected, the display data output unit 332 updates the rejection flag associated with the player in the player table to rejected.

When the normal battle execution unit 333 is instructed by the progress control unit 331 to execute a normal battle, it determines an opponent for the normal battle. The normal battle execution unit 333 randomly determines an opponent for the normal battle using pseudo-random numbers generated using, for example, the current clock counter value of the server 3 as a seed. The normal battle execution unit 333 identifies the player ID included in the battle start request, extracts each piece of information related to the cards of the characters to be used in the battle between the identified player and the opponent player from the player table and card table, and creates display data for displaying the battle screen 600 shown in FIG. 6(a). The normal battle execution unit 333 passes the created battle screen 600 to the progress control unit 331.

In addition, the normal battle execution unit 333 starts a normal battle when the progress control unit 331 instructs the start of a normal battle. The normal battle execution unit 333 extracts each piece of information related to the cards of the characters used in the battle between the player and the opponent player from the player table and the card table. The normal battle execution unit 333 determines the amount of damage to be inflicted on the opponent player's character based on the attack power of the player's character used in the battle in accordance with the operation from the player, and subtracts the determined amount of damage from the HP of the opponent player's character. On the other hand, the normal battle execution unit 333 determines the amount of damage to be inflicted on the player's character based on the attack power of the opponent player's character in accordance with the operation from the opponent player, and subtracts the determined amount of damage from the HP of the player's character. Then, the normal battle execution unit 333 determines that the player has won if the vitality of the opponent player's character becomes 0 first, and determines that the player has lost if the vitality of the player's character becomes 0 first. The normal battle executing unit 333 grants battle points to the player by adding specific points to the battle points associated with the player according to the outcome of the battle. Furthermore, when a specific condition is met in the battle, the normal battle executing unit 333 grants entry points to the player by adding specific points to the entry points associated with the player.

The normal battle execution unit 333, like the display data output unit 332, extracts from the event table the event battles currently in the entry period, the event battles currently in the matching period, the event battles currently in the notification period, and the event battles currently in the implementation period. In addition, the normal battle execution unit 333 extracts the entry status for each extracted event battle associated with the player in the player table.

When a player has entered an event battle that is currently being held, the normal battle execution unit 333 creates display data for displaying the battle result screen 720 for the ongoing event battle shown in FIG. 7(c).

On the other hand, if the player has entered an event battle that is currently in the notification period, the normal battle execution unit 333 creates display data for displaying the battle result screen 710 for event notification shown in FIG. 7(b).

On the other hand, if the player is currently participating in an event battle during the entry period or matching period, the normal battle execution unit 333 creates display data for displaying the battle result screen 700 shown in FIG. 7(a) when the player has already entered.

On the other hand, if none of the above applies, the normal battle execution unit 333 reads the player's entry point and the number of possible entries from the player table, and determines whether or not the player is eligible to enter the event battle during the current entry period. If the entry point is equal to or greater than a predetermined point and the number of possible entries is greater than a predetermined number, the normal battle execution unit 333 determines that entry is eligible, and if the entry point is less than the predetermined point or the number of possible entries is equal to or less than the predetermined number, it determines that entry is not eligible.

If the player is eligible to enter the event battle during the current entry period, the normal battle execution unit 333 further determines whether the refusal flag indicates that the entry has been rejected. If the refusal flag indicates that the entry has been rejected, the normal battle execution unit 333 creates display data for displaying the battle result screen 630 after entry refusal shown in FIG. 6(d).

On the other hand, if the refusal flag indicates that the entry has not been rejected, the normal battle executing unit 333 creates display data for displaying the battle result screen 620 for entry shown in FIG. 6(c). Also, if the player is not eligible to enter an event battle during the current entry period, the normal battle executing unit 333 creates display data for displaying the normal battle result screen 610 shown in FIG. 6(b).

The normal battle execution unit 333 passes the created battle result screen to the progress control unit 331.

When the event battle execution unit 334 is instructed by the progress control unit 331 to execute an event battle, it identifies the player ID included in the battle execution request, reads the opponent ID associated with the identified player from the player table, and identifies the opponent player in the event battle. The event battle execution unit 334 extracts information related to the character cards used in the battle between the identified player and the opponent player from the player table and card table, and creates display data for displaying the battle screen 600 shown in FIG. 6(a). The event battle execution unit 334 passes the created battle screen 600 to the progress control unit 331.

When the event battle execution unit 334 is instructed by the progress control unit 331 to start an event battle, it executes the event battle in the same manner as the normal battle executed by the normal battle execution unit 333. The event battle execution unit 334 executes the event battle from the start time of the event battle to the end time of the event battle. Depending on the result of the event battle, the event battle execution unit 334 updates the number of wins and losses and the number of consecutive wins associated with the player in the player table, and grants event points to the player by adding specific points to the event points. The event battle execution unit 334 also creates display data for displaying a battle result screen 720 during the event battle shown in FIG. 7(c), and passes the created battle result screen 720 to the progress control unit 331.

When the participation request receiving unit 335 is instructed by the progress control unit 331 to accept an entry, it identifies the player ID included in the entry request and reads out the entry point and number of entries of the identified player from the player table. If the entry point is equal to or greater than a predetermined value and the number of possible entries is greater than a predetermined number, the participation request receiving unit 335 reads out the event table and identifies an event battle that is currently in the entry period. In the player table, the participation request receiving unit 335 updates the entry status associated with the identified player and event battle to "entering," subtracts a predetermined value from the entry point, and decrements (-1) the number of possible entries. In this way, the participation request receiving unit 335 accepts requests to participate in the event battle from each player.

When the reception end time for a specific event battle arrives, the combination determination unit 336 executes a matching process by the matching completion time to determine a battle combination in the event battle for each player whose entry request was accepted by the reception end time. The combination determination unit 336 reads the player table and extracts all players whose entry status is "entered", that is, all players who have entered the event battle. Next, the combination determination unit 336 reads the player table and extracts the battle points, event points, and number of consecutive wins in the event battle of each extracted player, and calculates the event level of each player based on the extracted battle points, event points, and number of consecutive wins. The event level is calculated so that the larger the battle points, the higher the event points, and the higher the number of consecutive wins. Next, the combination determination unit 336 arranges each player in order of the highest event level, and selects two players at a time from the highest event level to determine the battle combination. The pairing determination unit 336 writes the opponent ID of each player in association with each player in the player table according to the determined match pairings.

Battle points are cumulative values from when each player joined the game, and therefore represent the steady-state strength of each player. On the other hand, event points are cumulative values during the implementation period of all event battles, and therefore represent the strength of each player's attachment to event battles. Therefore, matchups are decided taking into consideration both the steady-state strength of each player and the strength of their attachment to event battles. Also, during the implementation period of all event battles, the difference in event points between each player is small in the early stages, and the difference in event points becomes larger toward the end. Therefore, in the early stages of an event, players with the same level of steady-state strength are paired together, and in the late stages of an event, players with the same level of attachment to event battles are paired together. Because the tendencies of opponents differ between the early and late stages of an event, it is possible to prevent players from getting bored of event battles and maintain players' motivation to continue playing event battles.

In addition, the number of consecutive wins in an event battle more clearly indicates the strength of a player's attachment to the event battle. Therefore, by calculating the event level based on the number of consecutive wins in an event battle, it becomes possible to pit players who are extremely attached to the event battle against each other at the end of the event battle.

The pairing determination unit 336 also determines matchups for all players who have entered during the entry period. Therefore, the level difference between players in each pairing is smaller than when players are paired in order of entry, making it possible to prevent battles between players with large levels.

In addition, the combination determination unit 336 may determine the match-up based on at least one of the battle points, event points, and winning streak, rather than based on all of the battle points, event points, and winning streak.

Figure 10 is a diagram showing an example of an operation sequence related to game processing of the game system 1. This operation sequence is executed mainly by the device processing unit 25 and the server processing unit 33 in cooperation with each element of the mobile device 2 and the server 3, based on a program previously stored in the device storage unit 22 and the server storage unit 32.

First, when a player uses the operation unit 23 of the portable device 2 to start a game or to transition to a home screen, the browsing execution unit 251 of the portable device 2 transmits a home screen request to the server 3 via the device communication unit 21 (step S101). When the progress control unit 331 of the server 3 receives the home screen request from the portable device 2, the display data output unit 332 executes a home screen display data creation process (step S102). The details of the home screen display data creation process will be described later. The progress control unit 331 transmits the home screen display data created by the display data output unit 332 in the home screen display data creation process to the portable device 2 (step S103). When the home screen display data is received from the server 3 via the device communication unit 21, the browsing execution unit 251 of the portable device 2 generates drawing data based on the received display data, and causes the display unit 24 to display the home screen (step S104).

Next, when the player presses the battle button using the operation unit 23 while the home screen is displayed on the display unit 24 of the mobile device 2, the viewing execution unit 251 of the mobile device 2 transmits a battle request to the server 3 via the device communication unit 21 (step S105). When the progress control unit 331 of the server 3 receives a battle request from the mobile device 2, if an event battle is not being held or the player is not participating in the event battle, the normal battle execution unit 333 determines an opponent for the normal battle and creates display data for displaying the battle screen 600. On the other hand, if an event battle is being held and the player is participating in the event battle, the event battle execution unit 334 identifies an opponent for the event battle from the player table and creates display data for displaying the battle screen 600 (step S106). The progress control unit 331 transmits the display data created by the normal battle execution unit 333 or the event battle execution unit 334 to the mobile device 2 (step S107). When display data for the battle screen 600 is received from the server 3 via the device communication unit 21, the viewing execution unit 251 of the mobile device 2 creates drawing data based on the received display data and displays the battle screen 600 on the display unit 24 (step S108).

Next, when the player presses the battle button 602 using the operation unit 23 while the battle screen 600 is displayed on the display unit 24 of the mobile device 2, the viewing execution unit 251 of the mobile device 2 transmits a battle start request to the server 3 via the device communication unit 21 (step S109). When the progress control unit 331 of the server 3 receives the battle start request from the mobile device 2, the normal battle execution unit 333 or the event battle execution unit 334 executes a battle process (step S110). Details of the battle process will be described later. The progress control unit 331 transmits the battle result screen display data created by the normal battle execution unit 333 or the event battle execution unit 334 in the battle process to the mobile device 2 (step S111). When the battle result screen display data is received from the server 3 via the device communication unit 21, the viewing execution unit 251 of the mobile device 2 creates drawing data based on the received display data and displays the battle result screen on the display unit 24 (step S112).

Next, when the player presses the entry button using the operation unit 23 while the home screen or the battle result screen is displayed on the display unit 24 of the portable device 2, the viewing execution unit 251 of the portable device 2 transmits an entry request to the server 3 via the device communication unit 21 (step S113). When the progress control unit 331 of the server 3 receives the entry request from the portable device 2, the participation request acceptance unit 335 executes an entry process (step S114). Details of the entry process will be described later. Next, the display data output unit 332 executes a home screen display data creation process (step S115). The display data output unit 332 transmits the home screen display data created by the display data output unit 332 in the home screen display data creation process to the portable device 2 (step S116). When the home screen display data is received from the server 3 via the device communication unit 21, the viewing execution unit 251 of the portable device 2 creates drawing data based on the received display data and displays the home screen on the display unit 24 (step S117). This is the end of the operation sequence related to the game process.

Figure 11 shows the operation flow of the home screen display data creation process by the display data output unit 332. The home screen display data creation process shown in Figure 11 is executed in steps S102 and S115 of Figure 10.

The display data output unit 332 first extracts from the event table the event battles currently in the entry period, the event battles currently in the matching period, the event battles currently in the notification period, and the event battles currently in the implementation period. The display data output unit 332 also identifies the player ID included in the home screen request, and extracts, from the player table, the entry status for each extracted event battle associated with the player corresponding to the identified player ID (step S201).

The display data output unit 332 determines whether or not the player has entered the currently ongoing event battle (step S202). If the player has entered the currently ongoing event battle (step S202-Yes), the display data output unit 332 creates display data for displaying the home screen 510 during the event battle (step S203), and ends the series of steps.

On the other hand, if the player has not entered an event battle currently being held (step S202: No), the display data output unit 332 determines whether the player has entered an event battle currently being held during the notification period (step S204). If the player has entered an event battle currently being held during the notification period (step S204: Yes), the display data output unit 332 creates display data for displaying the home screen 500 for event notification (step S205), and ends the series of steps.

On the other hand, if the player has not entered an event battle during the current notification period (step S204-No), the display data output unit 332 determines whether the player has entered an event battle during the current entry period or matching period (step S206). If the player has entered an event battle during the current entry period or matching period (step S206-Yes), the display data output unit 332 creates display data for displaying the home screen 420 when the player has entered (step S207), and ends the series of steps.

On the other hand, if the player has not entered an event battle during the current entry period or matching period (step S206-No), the display data output unit 332 determines whether the player is eligible to enter an event battle during the current entry period (step S208). If the player is eligible to enter an event battle during the current entry period (step S208-Yes), the display data output unit 332 creates display data for displaying the home screen 410 for entry (step S209), and ends the series of steps.

On the other hand, if the player is not currently participating in an event battle during the entry period or matching period (step S208-No), the display data output unit 332 creates display data for displaying the normal home screen 400 (step S210) and ends the series of steps.

Figure 12 shows the operational flow of battle processing by the normal battle execution unit 333. The battle processing shown in Figure 12 is executed in step S110 of Figure 10 when an event battle is not being held or when the player is not participating in an event battle.

The normal battle execution unit 333 first executes a normal battle (step S301).

Next, the normal battle execution unit 333 extracts from the event table the event battles currently in the entry period, the event battles currently in the matching period, the event battles currently in the notification period, and the events currently in the implementation period. The normal battle execution unit 333 also extracts the entry status for each extracted event battle associated with the player in the player table (step S302).

The normal battle executing unit 333 determines whether or not the player has entered an event battle currently being held (step S303). If the player has entered an event battle currently being held (step S303-Yes), the normal battle executing unit 333 creates display data for displaying a battle result screen 720 for the ongoing event battle (step S304), and ends the series of steps.

On the other hand, if the player has not entered an event battle currently being held (step S303-No), the normal battle executing unit 333 determines whether or not the player has entered an event battle currently being held during the notification period (step S305). If the player has entered an event battle currently being held during the notification period (step S305-Yes), the normal battle executing unit 333 creates display data for displaying the battle result screen 710 for event notification (step S306), and ends the series of steps.

On the other hand, if the player has not entered an event battle during the current notification period (step S305-No), the normal battle executing unit 333 determines whether the player has entered an event battle during the current entry period or matching period (step S307). If the player has entered an event battle during the current entry period or matching period (step S307-Yes), the normal battle executing unit 333 creates display data for displaying the battle result screen 700 when entry has been completed (step S308), and ends the series of steps.

On the other hand, if the player has not entered an event battle during the current entry period or matching period (step S307-No), the normal battle executing unit 333 determines whether the player is eligible to enter an event battle during the current entry period (step S309). If the player is eligible to enter an event battle during the current entry period (step S309-Yes), the normal battle executing unit 333 determines whether the refusal flag indicates that the entry has been rejected (step S310). If the refusal flag indicates that the entry has been rejected (step S310-Yes), the normal battle executing unit 333 creates display data for displaying the battle result screen 630 after the entry has been rejected (step S311), and ends the series of steps.

On the other hand, if the rejection flag indicates that the entry has not been rejected (step S310-Yes), the normal battle execution unit 333 creates display data for displaying the battle result screen 620 for entry (step S311), and ends the series of steps.

In addition, if the player is not eligible to enter the event battle during the current entry period (step S309-No), the normal battle execution unit 333 creates display data for displaying the normal battle result screen 610 (step S311), and ends the series of steps.

When an event battle is being held and the player is participating in the event battle, the battle process is executed by the event battle executing unit 334. In this case, since the player has entered the event battle currently being held, the event battle executing unit 334 executes the battle process in step S301, and then creates display data for displaying the battle result screen 720 for the event battle being held in step S304, and ends the series of steps.

Figure 13 shows the operation flow of the entry process by the participation request receiving unit 335. The entry process shown in Figure 13 is executed in step S114 of Figure 10.

The participation request receiving unit 335 first identifies the player ID included in the entry request, and reads the entry point and number of entries of the identified player from the player table (step S401).

Next, the participation request receiving unit 335 determines whether the entry point is equal to or greater than a predetermined value (step S402), and if the entry point is less than the predetermined value (step S402-No), no special processing is performed and the series of steps ends.

On the other hand, if the entry point is equal to or greater than the predetermined value (step S402-Yes), the participation request receiving unit 335 determines whether the number of possible entries is greater than a predetermined number (step S403). If the number of possible entries is equal to or less than the predetermined number (step S403-No), the participation request receiving unit 335 does not perform any particular process and ends the series of steps.

On the other hand, if the number of possible entries is greater than the predetermined number (step S403-Yes), the participation request receiving unit 335 updates the entry status in the player table to "entered," subtracts a predetermined value from the entry point, and decrements the number of possible entries (step S404), ending the series of steps.

Figure 14 shows the operational flow of the matching process by the combination determination unit 336. The matching process shown in Figure 14 is executed when the reception deadline for each event battle arrives.

The combination determination unit 336 first reads the player table and extracts all players who have entered the corresponding event battle (step S501).

Next, the combination determination unit 336 reads the player table and extracts the battle points, event points, and number of consecutive wins in event battles for each extracted player (step S502).

Next, the combination determination unit 336 calculates the event level of each player based on the extracted battle points, event points, and winning streak (step S503).

Next, the combination determination unit 336 ranks the players in order of highest event level (step S504).

Next, the pairing determination unit 336 determines the match pairings by selecting two players at a time starting from the highest event level (step S504), updates the player table, and ends the series of steps.

In conventional network game systems, a battle begins as soon as matching is established. Of two matched players, the player who entered later is likely to notice that the battle has started because the battle begins immediately after entry, but the player who entered earlier may not notice that the battle has started because the battle may begin a long time after entry. In this way, if the battle begins immediately after matching is established, unfairness may arise between players depending on the timing of entry. This issue is particularly noticeable in web games, where players are required to actively update the display information on their terminal devices.

As explained above, the server 3 determines battle pairings only for players who have accepted a request to participate in a battle, which makes it possible to improve the rate at which battles are successful. In addition, the server 3 executes each battle after a certain period of time has passed since the determination of the battle pairings, which makes it possible to ensure that players have time to prepare for the battle. Furthermore, even if all battle pairings cannot be determined by the time matching is completed, the event battle itself can be executed if the battle pairings are determined within a certain period of time, which prevents the occurrence of a situation in which the event battle cannot be executed. In addition, the server 3 determines the battle pairings and executes each battle within a predetermined period of time, which makes it possible to prevent unfairness between players.

Furthermore, after the completion time of the determination of the battle pairings, the server 3 notifies each player related to the determined battle pairings of the time remaining until the start of the battle. This prevents each player from forgetting that they have entered the battle, losing interest in the battle, or not realizing that the battle has started between the time they enter the battle and the time the battle starts. This makes it possible to prevent a decrease in the participation rate in battles and to increase the rate at which battles are established.

The present invention is not limited to this embodiment. For example, in this embodiment, the main game and sub game are battles using characters owned by each player, but the main game and sub game may be a fishing game or a car racing game using items owned by each player (fishing rod, car, etc.).

For example, if a fishing game is used as the main game and sub-game, in the main game, a player acquires battle points by catching any fish using a fishing rod that the player owns, and acquires entry points by catching a specific fish. In the sub-game, the outcome of an event battle is determined based on the number and size of fish that the player and the opponent player each catch during the event battle period, and players acquire event points according to the results.

In such fishing games, by being notified of the time remaining until the start of the event battle, the player can adopt a strategy of starting fishing shortly before the start of the event battle and reeling in the first fish immediately after the event battle begins. Also, by being notified of information about the opponent along with the time remaining until the start of the event battle, the player can devise a strategy such as purchasing items that will enable them to defeat the opponent depending on their level, just as in a battle using a character owned by the player.

In addition, in a fishing game, the event points that can be acquired during a specified period immediately after the start of an event battle, or during a specified period immediately before the end of an event battle, may be higher than the event points that can be acquired during other periods. Since players are notified of the time remaining until the start time of the event battle, the time remaining until the end time of the event battle, etc., each player can adjust the level of focus on the battle according to the time of day.

The server 3 may also change the event battle start time or end time of each player depending on the level difference between the two competing players. In this case, the server 3 sets the event battle start time of the lower-level player earlier than the event battle start time of the higher-level player the greater the level difference. Alternatively, the server 3 sets the event battle end time of the lower-level player later than the event battle end time of the higher-level player the greater the level difference. Furthermore, the server 3 may increase the event points awarded to the higher-level player who is at a disadvantage. This improves the gameplay of the event battle and makes it possible to increase the entertainment value of the game.

The server 3 may also accept messages such as greetings sent by players to their opponents during the notification period, and notify the opponents of the accepted messages. In this case, a bonus may be given to the player who sent the message and/or the player who received the message. This can stimulate communication between players.

The server 3 may also accept a request from the player during the notification period to have a related player participate in the event battle in order to help the player. This allows the player to improve the chances of winning when it is predicted that the player will not be able to defeat the player notified as an opponent, and also makes it possible to stimulate communication between players.

Alternatively, the server 3 may accept a request from a player during the notification period to cancel participation in the event battle, change the battle pairing, etc. In this case, the server 3 may further grant a specific benefit to the opponent player whose battle has been canceled or whose pairing has been changed.

The game executed on the mobile device 2 may be a hybrid game in which the server 3 and the mobile device 2 each handle part of the processing. In that case, for example, each screen related to the progress of the game is displayed as a web display on the mobile device 2 based on display data generated by the server 3, and other menu screens and the like are displayed as native displays by a native app installed on the mobile device 2.

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 Display data output unit 333 Normal battle execution unit 334 Event battle execution unit 335 Participation request acceptance unit 336 Pairing determination unit

Claims (12)

A game system for progressing a first game and a second game,
accepting a progress request from a first player;
when the request to progress is received before a period during which the second game can be progressed, the first game is progressed in response to the request to progress;
when the progress request is received during the progress period, if the first player has not made a request to participate in the second game, progress the first game in response to the progress request;
one or more processors that, when the progress request is accepted during the progress period, progress the second game if the first player has requested to participate in the second game;
A game system comprising: 2. The game system according to claim 1, wherein the second game that progresses when the progress request is accepted during the progress period from the first player who has made the request to participate in the second game is a game based on a match combination including the first player and a plurality of second players who have also made the request to participate. 3. The game system according to claim 2, wherein after determining the battle pairings for the second game, the one or more processors transmit display data for a first notification screen including a remaining time until the start of the progress period to the terminal of the first player who made the participation request. 4. The game system according to claim 3, wherein when the one or more processors progress the first game in response to a request of the first player who made the participation request after determining the match pairings for the second game and before the progress period starts, the one or more processors transmit display data for the first notification screen, including the result of the first game and the remaining time until the progress period starts, to a terminal of the first player who progressed the first game. The game system according to any one of claims 2 to 4, wherein the one or more processors transmit display data for a second notification screen including a remaining time until the battle pairing is determined to the terminal of the first player who made the participation request before determining the battle pairing for the second game. 6. The game system according to claim 5, wherein, when the one or more processors progress the first game in response to a request of the first player who made the participation request before the match-up for the second game is determined, the one or more processors transmit display data for the second notification screen, including the result of the first game and the remaining time until the match-up for the second game is determined, to a terminal of the first player who progressed the first game. The game system according to any one of claims 2 to 6, wherein when the one or more processors receive a message from the first player who made the participation request to an opponent during the period from when the battle pairing in the second game is determined to when the progress period starts, the one or more processors grant a benefit to the first player or the opponent. The game system according to any one of claims 2 to 7, wherein the one or more processors accept a request from the first player who has made the participation request to have another player who will rescue the first player participate in the game, during a period from when the battle pairings for the second game are determined to when the progress period begins. The game system according to any one of claims 2 to 8, wherein the one or more processors accept a request to cancel participation in the second game or to change the battle pairing from the first player who made the participation request, during the period from when the battle pairing in the second game is determined to when the progress period begins. The game system according to any one of claims 1 to 9, wherein, when the one or more processors progress the first game during the progress period in response to a request from the first player who made the participation request, the one or more processors transmit display data for a third notification screen including the result of the first game and the remaining time until the end of the progress period to the terminal of the first player who progressed the first game during the progress period. A method for controlling a game system that includes one or more processors and that progresses a first game and a second game, comprising:
one or more processors,
accepting a progress request from a first player;
when the request to progress is received before a period during which the second game can be progressed, the first game is progressed in response to the request to progress;
when the progress request is received during the progress period, if the first player has not made a request to participate in the second game, progress the first game in response to the progress request;
when the progress request is accepted during the progress period, if the first player has made the request to participate in the second game, progress the second game;
A control method comprising: A server device including one or more processors and configured to progress a first game and a second game,
accepting a progress request from a first player;
when the request to progress is received before a period during which the second game can be progressed, the first game is progressed in response to the request to progress;
when the progress request is received during the progress period, if the first player has not made a request to participate in the second game, progress the first game in response to the progress request;
a processing unit configured to, when the progress request is accepted during the progress period, progress the second game if the first player has requested to participate in the second game.

Images