WO2013161731A1

WO2013161731A1 - Game control device, game control method, program, recording medium, and game system

Info

Publication number: WO2013161731A1
Application number: PCT/JP2013/061723
Authority: WO
Inventors: 晃太若狭
Original assignee: 株式会社コナミデジタルエンタテインメント
Priority date: 2012-04-25
Filing date: 2013-04-22
Publication date: 2013-10-31
Also published as: JP2013226223A; JP5436612B2

Abstract

This game control device is provided with: a match execution means that executes a user match in a game; a reception means that receives an assistance request in a first match from a first user; a determination means that determines whether or not to carry out the assistance request in the first match in accordance with the difference in game progress of the first user with respect to users other than the first user; and a request means that, in accordance with the determination results of the determination means, identifies a second user as the assistance request destination among the users other than the first user and makes the assistance request of the second user.

Description

GAME CONTROL DEVICE, GAME CONTROL METHOD, PROGRAM, RECORDING MEDIUM, GAME SYSTEM

The present invention relates to a technique for controlling the progress of a game by each user according to each operation of a plurality of users.

In recent years, a so-called social game (Social) executed by a game application created based on an operating environment such as an API (Application Programming Interface) operating on a web browser in a social networking service (SNS) by a specific service provider. Game) is popular. It can be said that the social game is a kind of online game that is played while communicating among an unspecified number of users. If a user can connect to the Internet and has a communication terminal equipped with a web browser, the user can enjoy a social game regardless of time and place.

One of the features of the above-described social game is that it has a richer communication function for interaction between users than the conventional online game. In social games, for example, in addition to the execution of a game in cooperation between related users (companies), information exchange by communicating with the companion such as greetings and communication with the companion, items on the game with the companion Gifts or items have been exchanged. As an example of such a social game, a digital card game (Dragon Collection (registered trademark)) described in Non-Patent Document 1 below is known.

In a conventional social game, when each user advances the game while performing a battle with a character on the game, for example, there is a difference in the progress of the game due to a difference in the ability on the game for each user. Arise. At this time, for example, for a user with low game ability, the game cannot be advanced quickly by winning the battle (that is, the progress of the game is low). In some cases, it was not felt interesting.

The present invention has been made in view of the above-described viewpoints, and a game control device, a game control method, a program, a recording medium, and a game that can assist the progress of the game when the progress of the user's game is low The purpose is to provide a system.

The first aspect of the present invention is:
A battle execution means for performing a battle on the game by the user;
Receiving means for receiving a support request in the first battle from the first user;
A determination unit that determines whether to make a support request in the first battle according to a difference in the degree of progress of the game with the first user for a user other than the first user;
According to the determination result of the determination means, a request means for identifying a second user as a support request destination among users other than the first user, and requesting the support request to the second user;
Is provided.

In this game control device, a support request is made to, for example, a second user whose game progress is higher than that of the first user who is executing the game. Since the second user who has a high degree of progress of the game is considered to have a high ability on the game (for example, the ability of the battle, etc.), a support request is made to the second user. Support is highly effective. As a result, even a user with a low degree of progress of the game can feel the fun of the game according to the game scenario. Moreover, since the user with a high degree of game progress assists the user with the low degree of game progress, the game can be activated as a whole.
The “game progress” can be arbitrarily set depending on the nature of the game. For example, the number of stages cleared in the game, the number of items acquired in the game, or a specific number given in the game It may be determined according to a parameter such as a level that increases every time the mission is achieved, such as the number of times the mission has been completed, or the number of times a specific menu is selected on the game screen.

In the game control device, the determination unit determines that a support request is made to a user other than the first user who has a difference in game progress with the first user that is equal to or greater than a predetermined value. May be. As a result, the number of second users who request support can be appropriately limited. In addition, since the degree of progress of the second user can be set sufficiently higher than that of the first user, it can be expected to receive support from a user who has a sufficiently higher ability on the game than the first user. Effectiveness can be further increased.

In the game control device, based on information of a predetermined operation input by the second user in response to the support request made by the request unit, the first user's competitive capability in the first battle Or support means for executing a first support for adjusting the battle capability of the opponent of the first battle to be advantageous to the first user.
The “predetermined operation input” is a communication terminal having an acceleration sensor in addition to an input operation of pressing a predetermined operation button on a user's communication terminal, an input of a touch operation on a display screen to a communication terminal having a touch panel function. It may be an operation input by shaking or an operation input by gesture (gesture input). In gesture input, by performing a predetermined gesture on a communication terminal having an imaging function, the communication terminal recognizes an image of the gesture and recognizes an operation input previously associated with the gesture.
The first support performed by the second user is not directly fighting the opponent of the first battle, but the battle capability of the first user in the first battle, or of the first battle It is to adjust the battle capability of the opponent so that the first user is advantageous. In other words, the first support indirectly supports the first battle by the first user. That is, since the first user is assisted to win the first battle by his / her own operation, for example, the first user can have a sense of accomplishment that he / she has won the battle.

When performing the first support, the support means adjusts the first user to be more advantageous as the difference in the game progress between the first user and the second user increases. Also good. Thereby, as the progress degree of the game of the second user is higher than that of the first user, the progress of the game of the first user is facilitated by the support from the second user. As a result, the progress rate of the first user's game is adjusted depending on the second user who provides support, and the range of game characteristics can be widened.

In the game control device, the support request may execute a battle with the opponent of the first battle by the second user. Thus, the support performed by the second user may be a direct battle with the opponent of the first battle. Even with such a support method, the second user can assist the progress of the game of the first user.

In the above game control device, the requesting unit is configured to adjust the first support so that the first user is advantageous in the first battle according to the determination result of the determining unit, or the second support unit. Any of the second support for executing the battle with the opponent of the first battle by the user may be presented so as to be selectable by the second user. Here, the first support is a direct support in which the second user directly battles with the opponent of the first battle. As described above, the second support is an indirect support for the first battle by the first user. The second user can select either the first support or the second support as the support method for the first user. Therefore, it can be set as the game setting which enables a 2nd user to select flexibly according to the progress of own game.

In the game control device, the battle execution means may consume parameters on the game of the user as the user executes the battle on the game. In this case, when the second user selects the first support method or the second support method, the second support (executes a battle with the opponent of the first battle). Since the selection is made in consideration of the consumption of its own parameters, deep game characteristics can be realized. For example, when it is set to be able to obtain a privilege by winning in a match or according to the number of wins in a match, a configuration in which the second user comparatively considers the amount of parameter consumption and the privilege to be obtained It can be.

The game control apparatus may further include an association unit that associates users, and the request unit may select the second user from among users associated with the first user.
By selecting the second user who makes the support request from the users (companies) associated with the first user of the support request source, for the first user, the real feeling that the support is received by the companion Can be obtained, so the relationship with friends can be enhanced. Therefore, the social nature of the game can be improved.

The second aspect of the present invention is:
Performing a game battle by a user;
Receiving a support request in the first battle from the first user;
Determining whether to make a support request in the first battle according to the difference in the degree of progress of the game with the first user for users other than the first user;
According to a determination result of the determining step, identifying a second user as a support request destination among users other than the first user, and performing the support request to a second user;
A game control method comprising:

A third aspect of the present invention relates to a computer.
A function for performing a game battle by a user,
A function of accepting a support request from the first user in the first battle;
A function for determining whether or not to make a support request in the first battle according to a difference in the degree of progress of the game with the first user for users other than the first user; and
A function of specifying a second user of a support request destination among users other than the first user according to a determination result of the function to be determined, and performing the support request to a second user;
It is a program for realizing.

The computer may be, for example, a network server or a large computer. Further, this program may be stored in a computer-readable information storage medium such as a DVD-ROM or a CD-ROM. That is, a fourth aspect of the present invention is a computer-readable recording medium in which the program is recorded.

A fifth aspect of the present invention is a game system including a communication terminal and a server configured to be accessible from the communication terminal and controlling execution of the game by the communication terminal,
A battle execution means for performing a battle on the game by the user;
Accepting means for accepting a support request in the first battle from the first user;
A determination unit that determines whether or not to make a support request in the first battle according to a difference in the degree of progress of the game with the first user for a user other than the first user, and
Request means for identifying the second user as the support request destination among the users other than the first user according to the determination result of the determination means, and making the support request to the second user,
Each of the means is provided in either the communication terminal or the server,
Is a game system.

The figure which shows the basic composition of the game system of embodiment. The figure which shows an example of the external appearance of the communication terminal of embodiment. The figure which shows the other example of the external appearance of the communication terminal of embodiment. The block diagram which shows the structure of the communication terminal of embodiment. The block diagram which shows the structure of the game server of embodiment. The block diagram which shows the structure of the database server of embodiment. The figure which shows the structural example of the user database contained in a database server. The figure which illustrates the contents of monster character data. The figure which illustrates the example of a data structure of battle management data. The figure which illustrates the example of a data structure of a support request list. The figure which shows the example of a display of the top page of a game. The figure which shows the example of a display of the top page of the battle in a game. The figure which illustrates a series of web pages displayed in a user's communication terminal. The figure which illustrates a series of web pages displayed in a user's communication terminal. The figure which illustrates a series of web pages displayed in a user's communication terminal. The functional block diagram for demonstrating the function to play main roles with the game control apparatus of embodiment. The sequence chart which shows the main processes (when another user participates in a battle) between the communication terminal and game server of embodiment. The sequence chart which shows the main processes (when another user supports) between the communication terminal and game server of embodiment. The functional block diagram for demonstrating the function which plays a main role with the game control apparatus which concerns on a modification. The figure which shows the example of 1 structure of each function in each of a communication terminal and a communication server. The figure which shows the other structural example of each function in each of a communication terminal and a communication server.

The present invention relates to a patent application of Japanese Patent Application No. 2012-099549 filed with the Japan Patent Office on April 25, 2012, the contents of which are incorporated herein by reference.

Hereinafter, embodiments of the present invention will be described.

(1) Configuration of Game System FIG. 1 shows a system configuration example of a game system according to the embodiment. As shown in FIG. 1, the game system includes

communication terminals

10a, 10b, 10c,... That can be connected to a communication network NW (network) such as the Internet, a game server 20 connected to the communication network NW, The database server 30 is configured. Each of the

communication terminals

10a, 10b, 10c,... Is a terminal operated by an individual user, for example, a mobile terminal, a smartphone, a PDA (Personal Digital Assistant), a personal computer, a television having a bidirectional communication function. A communication terminal such as a John receiver (including a so-called multi-function smart TV). In the following description, when referring to the

communication terminals

10a, 10b, 10c,.
In this game system, the game server 20 is configured to be able to communicate with the communication terminal 10 that is a client, and provides a gaming service to the communication terminal 10. The game server 20 is mounted with an application operable on a web browser as a game application. The database server 30 stores various information to be described later in executing the game, and is connected to the game server 20 by, for example, a wire for reading and writing the information.
The communication terminal 10 includes a web browser capable of displaying a web page provided by the game server 20, and the user executes a game by operating the web page on the communication terminal 10.

Although not shown in FIG. 1, an authentication server for authenticating the user of each communication terminal 10 may be provided separately from the game server 20. Further, when a plurality of game servers 20 are provided in order to accept access from many communication terminals 10, a load balancer for adjusting a load between the plurality of game servers 20 may be provided. The game server 20 may be configured as a single server device, but may be configured as a plurality of server devices having distributed functions.

(2) Configuration of Communication Terminal The communication terminal 10 will be described with reference to FIGS. 2A, 2B, and 3.
2A and 2B are diagrams each illustrating an example of the appearance of the communication terminal 10. FIG. 2A illustrates a button input type communication terminal such as a foldable mobile terminal (mobile phone). FIG. 2B illustrates a communication terminal of a touch panel input method such as a smartphone. FIG. 3 is a block diagram showing an internal configuration of the communication terminal 10.
As shown in FIG. 3, the communication terminal 10 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an image processing unit 14, an instruction input unit 15, a display unit 16, A communication interface unit 17 as a signal transmission / reception unit is provided, and a bus 18 for transmitting a control signal or a data signal between the units is provided.

The CPU 11 loads the web browser in the ROM 12 into the RAM 13 and executes it. And CPU11 is based on the appropriate designation | designated of URL (Uniform Resource Locator) input to a user by the instruction | indication input part 15 grade | etc., Data for displaying a web page from the game server 20 via the communication interface part 17, That is, data of an object such as an HTML (HyperText Markup Language) document and an image associated with the document (hereinafter collectively referred to as “HTML data” as appropriate) is acquired via the communication interface unit 17. Interpret HTML data. The communication terminal 10 may be mounted with various plug-ins for extending the browser function of the web browser.
In acquiring the HTML data, the CPU 11 sends an access request message including a user ID (user identification information) registered in advance or a user ID input via the instruction input unit 15 via the communication interface unit 17. The game server 20 is notified.

The web browser displays the web page provided from the game server 20 on the display unit 16 based on the acquired HTML data via the image processing unit 14. When the user selects a hyperlink or menu on the web page by operating the instruction input unit 15, the web browser transmits new HTML data for displaying the web page according to the selection. (That is, update of the web page) is requested to the game server 20.

The image processing unit 14 displays a web page on the display unit 16 based on the display image data given from the CPU 11 as the analysis result of the HTML data. The display unit 16 is, for example, an LCD (Liquid-Cristal-Display) monitor including thin film transistors arranged in units of pixels in a matrix, and displays an image of a web page by driving the thin film transistors based on display image data. To display.

When the communication terminal 10 is a button input type communication terminal (FIG. 2A), the instruction input unit 15 includes a button group 15a including a plurality of instruction input buttons such as a direction instruction button and a decision button for accepting a user operation input. And a button group 15b including a plurality of instruction input buttons such as a numeric keypad, and includes an interface circuit for recognizing a pressing (operation) input of each button and outputting it to the CPU 11. For example, the direction instruction button is provided to instruct the CPU 11 to scroll and display the web page displayed on the display unit 16. The determination button instructs the CPU 11 that the user selects one hyperlink or menu that is actively displayed (for example, highlighted) when, for example, a plurality of hyperlinks or menus are displayed on a web page. To be provided. When the communication terminal 10 is configured by a small portable terminal, these buttons are provided on the front surface of the communication terminal 10 so that the user can easily operate (click) with the thumb while holding the communication terminal 10 with one hand. It is preferable to arrange | position. In the example shown in FIG. 2A, the button group 15b is arranged below the button group 15a and includes a plurality of instruction input buttons on which “0” to “9”, “*”, and “#” (ten keys) are written. .

When the communication terminal 10 is a touch panel input type communication terminal (FIG. 2B), the instruction input unit 15 mainly accepts touch panel type input by touching the display screen 16a with a fingertip or a pen. The touch panel input method may be a known method such as a capacitance method. As illustrated in FIG. 2B, the button group 15a may be provided even when the communication terminal 10 is a touch panel input method.

For example, when the communication terminal 10 is a portable terminal, the menu selection operation on the web page displayed on the communication terminal 10 is selected by pressing the direction instruction button and selecting by pressing the enter button. This is done by confirming the selected menu. Further, for example, when the communication terminal 10 is a touch panel input method, the selection operation is performed by instructing (touch operation) a menu position on the display screen 16a on which the web page is displayed with a finger or a pen.

(3) Configuration of Game Server The configuration of the game server 20 will be described with reference to FIG.
The game server 20 manages a game website including a plurality of hierarchical web pages, for example, and provides a game web service to the communication terminal 10. As shown in FIG. 4, the game server 20 includes a CPU 21, a ROM 22, a RAM 23, a database (DB) access unit 24, and a communication interface unit 25, for transmitting control signals or data signals between the units. A bus 26 is provided. In addition, the game server 20 can take the same structure as a general-purpose web server regarding hardware.

The ROM 22 stores an application program that provides a service for displaying an object such as an HTML document or an image (displaying a web page) to the web browser of the communication terminal 10 that is a client. The ROM 22 stores various data referred to by the CPU 21 in addition to the application program.
The CPU 21 loads the game program in the ROM 22 to the RAM 23 and executes it, and performs various processes via the communication interface unit 25.

For example, the CPU 21 transmits HTML data to the communication terminal 10 via the communication interface unit 25. In addition, when the game server 20 performs the authentication process of the user of the communication terminal 10, the CPU 21 performs the authentication process.
CPU21 performs the process according to the hyperlink or menu selected by the user on the web page displayed on the communication terminal 10 via a communication interface part. The processing includes, for example, transmission of new HTML data, arithmetic processing in the game server 20 or data processing.
The database access unit 24 is an interface when the CPU 21 reads / writes data from / to the database server 30.

(4) Configuration of Database Server The database server 30 (storage device) can be realized by a general-purpose storage such as a large-capacity hard disk device or a device such as a RAID (Redundant Array of Inexpensive Disks). Each database in the database server 30 is configured to be able to read and write data from the CPU 21 via the database access unit 24 of the game server 20.
FIG. 5 shows an example of the configuration of the database server 30. As shown in FIG. 5, the database server 30 includes a user database 31 and a game database 32.

The type of game realized by the game system according to the present embodiment is not particularly limited, but in the following, as an example of the game according to the present embodiment, the user performs a game on the game in accordance with the user's operation on the communication terminal 10. The battle-type digital card game (hereinafter referred to as “game of the present embodiment” as appropriate) that battles with a monster character, which is a monster on the game, is used. As will be described later, in the game of the present embodiment, when the user loses the battle with the monster character, a support request can be made, and the other user who accepts the support request supports the battle of the support requesting user. It is configured to be able to.

FIG. 6 shows an example of a user database 31 applied in the game of the present embodiment. In this example, for each user ID (user identification information), the user database 31 has information on each item of user name, skill level, attack point, friendship point, monster defeat number, fellow user ID, and possessed card data. including. Information included in the user database 31 can be updated sequentially by the game server 20.

In the following description, the user ID included in the user database 31 or data for each user name (to be described later) specifying the user is generically referred to as user data. The data of each item constituting the user data is as follows.
-User name It is a user name displayed in order to identify a user on the communication terminal 10 at the time of execution of a game. The user name is text having a predetermined length or less designated in advance by the user. The user name is a name that identifies the user on the network environment (or game community) provided by the game server 20.
Skill level This is data indicating the skill level of the user on the game. For example, it is a level value in a range from Lv1 (level 1) to Lv100 (level 100).
-Attack point In the game of this embodiment, it is a point required when performing a battle with the monster character using a warrior card. When the attack points are less than a predetermined value, the battle cannot be executed. The attack point is a value that decreases by performing one battle with the monster character and recovers (increases) each time a predetermined time elapses.
-Friendship point In the game of this embodiment, it is a point which a user acquires by transmitting a support message to a friend. Also, friendship points can be obtained when support is provided by supporting other users in response to support requests from other users.
-Monster Defeat Count The number of monster characters that the user has defeated by battle in the game of the present embodiment. The number of defeated monster characters is an example of the progress of the game.
・ Friend's user ID
This is data of another user ID associated with the target user ID. The fellow user ID is related to the second modification described later.
-Data of possession card The possession card data is data of the warrior card possessed by the user, and includes parameters such as an image and attack power for each warrior card as shown in FIG. When a warrior card battles with a monster character, damage according to the value of the attack power can be given to the monster character.

Returning to FIG. 5, the game database 32 stores information on the progress of the game executed by the game server 20, monster character data (monster character data), battle management data, and a support request list based on access from the game server 20. Remember. Information relating to the progress of the game may include various information depending on the nature of the game. Taking the case of the game of the present embodiment as an example, the information related to the progress of the game may include detailed results of battles with the monster characters of each user.

An example of monster character data is shown in FIG. The monster character data includes data of a monster character that is the opponent of the battle. The monster character data is data that is loaded from the game database 32 to, for example, the RAM 23 and stored together with the execution of the battle process. In FIG. 7, for each of the monster characters MC1, MC2, MC3,... That appear in the battle, an image displayed on the web page is associated with a value of HP (Hit Point) indicating the physical strength of the monster character. . For example, in the example shown in FIG. 7, the HP of each monster character is in the range of 1500 to 2000, but the HP value may be set randomly when performing a battle from this range.

Battle management data is data for managing the state of the battle for each user. FIG. 8 shows a data configuration example of battle management data. In the battle management data shown in FIG. 8, an appearing monster character (appearing monster), its HP, and the battle end time are written for each user (user name or user ID). Note that the battle end time is not necessarily indispensable data, but when the time until the monster character is defeated is limited, the battle end time is written. In addition, when a monster character appears as a battle opponent for each user, it is written in the battle management data as an appearing monster until the monster character is defeated (that is, the battle with the monster character is won). Become. Moreover, HP in battle management data has shown the newest value of the corresponding monster character. For example, when HP is reduced in one or more battles, the reduced HP is written to the battle management data.
The data in the battle management data is read when the user performs a battle, and is overwritten (updated) when the battle ends.

As described above, in the game of the present embodiment, for example, when a user loses in a battle with a monster character, a support request for the battle can be made to another user. Note that the condition for requesting support for the battle is not limited to the condition that the user has lost the battle with the monster character. It may be possible to request support unconditionally at the start of the battle, or to request support only when a predetermined condition in the battle is satisfied. The “predetermined condition in the battle” may be, for example, a predetermined condition for a parameter (or an ability level) such as a warrior card used by the user in battle and an attack power of a battle opponent's monster character. For example, it may be a condition that a difference in attack power between a warrior card and a monster character has a certain value.
The support request list is a list in which support requests made by users are sequentially written. Of the support requests in the support request list, those that have been supported are deleted from the list. FIG. 9 is a diagram illustrating a data configuration example of the support request list. In the support request list illustrated in FIG. 9, for each user (user name or user ID), the battle opponent (monster character) of the battle when the support request is made, and the battle end time are written. Note that the battle end time is not necessarily indispensable data, but when the time until the monster character is defeated is limited, the battle end time is written. In this case, if the HP of the monster character is not zero before the battle end time (that is, if the monster character cannot be defeated), it is determined that the monster character cannot be defeated.

(5) Game of this Embodiment Hereinafter, the battle process with the monster character of the game of this embodiment will be described with reference to FIGS. FIG. 10 is a diagram illustrating an example of a top page displayed on the communication terminal 10 in the game of the present embodiment. FIGS. 11 to 14 are diagrams showing examples of web pages displayed on the communication terminal 10 when the battle process is executed.
In the following description, menus, marks and the like displayed on the web page displayed on the communication terminal 10 are arranged at desired positions on the web page, and are menus visually recognized on the communication terminal 10. The position on the display screen of the mark and the like can be changed by scrolling the web page by the user's direction instruction button or touch panel operation.

The top page of the game of this embodiment illustrated in FIG. 10 is configured with a web page corresponding to each user ID. The example of FIG. 10 includes a user data display area, a warrior image display area, and a menu display area.
The user data display area is an area in which data of each item of skill level, friendship points, attack points, and monster defeat counts (see FIG. 6) included in the user data of the target user ID.
The warrior image display area is an area in which an image of a warrior card specified in advance by the user among a plurality of warrior cards included in the user data of the target user ID is displayed.
The menu display area is an area where a plurality of menus (not shown except for the menu m1) including a menu m1 for starting execution of the battle process in the game of the present embodiment are displayed.

When the menu m1 is selected and operated on the top page of the game in FIG. 10, the web page is updated as shown at P0 in FIG. The web page P0 is a battle top page. The web page P0 includes a monster display area 101 that displays a list of monster characters that are appearing as monster characters that can be battled, and a message display area 102 that displays a text message addressed to the user regarding the battle. The monster display area 101 includes menus m11 and m12 labeled “battle” for each monster character. Each menu is provided for each corresponding monster character. The text message included in the message display area 102 includes, for example, information indicating the degree of progress of a user's (in this case, user KNM) battle, or other information when a support request for a battle is made to another user. Information on the result of support by the user is included.

For example, when the menu m11 is selected and operated on the web page P0 in FIG. 11, the web page is updated as shown in P1 in FIG. The user switches to a battle screen for executing a play for defeating a monster character using a warrior card on hand. Web page P1 is a web page for a battle with monster character MC1 corresponding to menu m11. Each time a battle is performed, the user's attack points are consumed by a certain value or a value corresponding to the warrior card to be used.
The web page P1 is described as an image of a warrior card used by a user in a battle, an image of a battle opponent's monster character MC1, an HP gauge indicating the HP (Hit Point) of the monster character MC1, and “attack” Menu m20. HP is a value indicating the physical strength of the monster character. If the HP of the monster character can be reduced to zero before the warrior card used by the user is defeated, this means that the user has won the battle, and the HP of the monster character is zero when the warrior card used by the user is defeated. If not, it means that the user has lost the battle.

When the menu m20 is selected and operated on the web page P1, the web page is updated as shown in P2. The web page P2 shows a case in which the monster character MC1 is attacked by the warrior card used by the user for the battle, and as a result, the HP of the monster character is reduced as compared to the web page P1. Each time the menu m20 is selected and operated, an attack is applied to the warrior card from the monster character of the battle opponent.
As shown on the web page P3, when the HP of the monster character MC1 reaches zero, the user wins the battle and the monster character MC1 is defeated. On the other hand, as shown in the web page P4, if the warrior card is defeated before the HP of the monster character MC1 reaches zero, the user is defeated in the battle. If the battle is defeated, the monster character MC1 does not disappear and is displayed on the user's top page P0 regarding the battle in a state where the HP remaining after the battle is maintained.

In addition, as shown on the web page P4, when defeated in the battle, the menu m21 labeled “Challenge alone” for performing another battle with the monster character MC1 again, A menu m22 for requesting support is displayed.
FIGS. 13 and 14 both show the transition of the web page for the user KNM when the user KNM makes a support request (that is, when the menu m22 is selected and operated), and the user ABC who has accepted the support request. And the transition of the web page. FIG. 13 and FIG. 14 differ in the user ABC support method in response to a support request from the user KNM.

In FIG. 13, as a support method of the user ABC in response to a support request from the user KNM, a support method (second support described later) for performing a battle (that is, participating in a battle) with the monster character of the battle partner of the user KNM is selected. Is the case.

Referring to FIG. 13, when the menu m22 is selected and operated on the web page P4 (same as the web page P4 in FIG. 12), the web page is updated as shown in P5, and the user KNM has received the support request. Will be notified. When a support request by the user KNM is accepted, a message for confirming whether or not the support request is received is displayed for a user who satisfies a predetermined condition. Here, an example of a web page for the user ABC that satisfies the predetermined condition is shown in P6. On the web page P6, in order to prompt the selection of the support method, a menu m31 written as “to participate in the war” and a menu m32 written as “to support” are displayed. When the menu m31 (“participate”) is selected and operated on the web page P6, the web page is updated as shown in P7, and the user ABC uses the warrior card and the monster character that is the battle opponent of the user KNM. Transit to the screen to battle with MC1. For example, the web page P7 has the same format as the web pages P1 and P2 in FIG. 12, but the HP value of the monster character MC1 is the HP at the time when the user KNM is defeated (that is, the HP of the monster character MC1 of the web page P4). ) Value. As shown on the web page P8, when the user ABC defeats the monster character MC1 who is the battle partner of the user KNM in this battle, a message indicating that the user ABC has defeated the monster character MC1 is notified to the user KNM. The A display example of the web page including the message is shown in the web page P9. Note that the method of notifying the user KNM is not limited to the textual visual information exemplified in the web page P9, and may be audio information such as voice.

FIG. 14 shows a case where a support method of supporting a battle by the user KNM (first support described later) is selected as a support method of the user ABC in response to a support request from the user KNM. When supporting a battle, the user ABC that accepts the support request does not battle with the battle partner of the user KNM, but the attack power of the warrior card used by the user KNM who is the support request source is improved. Yes.

Referring to FIG. 14, when the menu m22 is selected and operated on the web page P4 (same as the web page P4 in FIG. 12), the web page is updated as shown in P5, and the user KNM has received the support request. Will be notified. When a support request by the user KNM is accepted, a message for confirming whether or not the support request is received is displayed for a user who satisfies a predetermined condition. Here, an example of a web page for the user ABC that satisfies the predetermined condition is shown in P6. On the web page P6, in order to prompt the selection of the support method, a menu m31 written as “to participate in the war” and a menu m32 written as “to support” are displayed. When the menu m32 (“support”) is selected and operated on the web page P6, the web page is updated as shown in P10, and the screen is changed to a screen for confirming that the user ABC has cheered the battle by the user KNM. . When support by the support of the battle is performed by the user ABC, for example, the attack power of the warrior card used by the user KNM in the battle increases. That is, when the user KNM then battles again with the monster character MC1, the battle is performed in a state where the attack power of the warrior card used by the user KNM is increased by the support of the user ABC. At this time, the user KNM is notified of a message indicating that the attack power of the warrior card has increased. A display example of a web page including the message is shown in the web page P11. Note that the method of notifying the user KNM is not limited to the textual visual information exemplified in the web page P11, and may be audio information such as voice.

(6) Overview of Each Process in Game Control Device Next, each process in the game control device will be described in order to realize the above-described game of the present embodiment.
In the present embodiment, the game server 20 and the database server 30 constitute a game control device. Hereinafter, functions implemented by the game control device of the present embodiment will be described with reference to FIG. 15, taking as an example the case where the above-described competitive digital card game is applied. FIG. 15 is a functional block diagram for explaining functions that play a major role in the game control apparatus of the present embodiment. In the functional block diagram of FIG. 15, the registration unit 51, the first support unit 56, and the second support unit 57 are not necessarily essential components.

For example, the registration unit 51 has a function of recognizing a user registration request based on an appropriate operation input to the communication terminal 10 on a web page provided to the communication terminal 10 and performing a registration process. This registration process is executed when the user performs user registration for the game of the present embodiment.
The function of the registration means 51 is implement | achieved as follows, for example. The CPU 21 of the game server 20 receives a registration request message from the communication terminal 10 via the communication interface unit 25. The registration request message is automatically generated by a predetermined operation on the communication terminal 10 on the web page provided from the game server 20 (for example, a predetermined menu selection operation or a text input such as a user ID or password specified by the user). Web pages may be configured to be generated automatically. The registration request message may include information for identifying the communication terminal 10 of the transmission source (for example, individual identification information of a terminal such as a UID (Unique Identifier), a mail address, or the like) If another game by the same service provider is used, the user ID may be included.

When the CPU 21 receives the registration request message and the registration request message does not include the user ID, the CPU 21 issues a new user ID and performs registration processing of the user ID, and then the registration processing is completed. Is sent to the communication terminal 10. When the CPU 21 receives the registration request message and the registration request message includes a user ID, the CPU 21 performs registration processing of the user ID, and then transmits a registration completion message indicating that the registration processing is completed to the communication terminal. 10 to send.
When the registration is completed, the CPU 21 generates user data corresponding to the user ID and stores it in the user database 31. When the registration is completed, the user can execute the game of the present embodiment.

The battle execution means 52 (match execution means) has a function of executing a battle (match) on the game by the user.
The function of the battle execution means 52 may execute a battle on the game by sequentially updating a web page displayed on the communication terminal 10 in response to a request from the communication terminal 10, for example. In this case, in order to realize the function of the battle execution means 52, the CPU 21 of the game server 20 receives an HTTP request from the communication terminal 10, performs a predetermined process on the game according to the HTTP request, and executes the game. An HTTP response including the resulting HTML data is returned to the communication terminal 10.

For example, when an HTTP request is transmitted from the communication terminal 10 to the game server 20 due to the selection operation of the menu m1 on the top page of the game shown in FIG. 10, the CPU 21 of the game server 20 responds to the HTTP request. Then, an HTTP response including HTML data for displaying the top page of the battle shown in FIG. 11 is transmitted to the communication terminal 10. At this time, in creating the HTML data, the CPU 21 reads out the monster character that is the battle opponent of the user who is executing the game and its HP from the battle management data and stores them in the RAM 23, and the HTML data based on the read data. Is generated.

In the battle process with the monster character, the CPU 21 of the game server 20 acquires a selection result of a predetermined number of warrior cards used in the battle among warrior cards held by the user in accordance with an appropriate operation by the user. In the following, for ease of understanding, the number of warrior cards participating in the battle is one. For each user, the CPU 21 causes one of the monster characters in the monster character data stored in the game database 32 to appear for battle at the timing of defeating the monster character or at random timing. Specifically, CPU21 reads the data of the monster character used as a battle opponent of a user, and newly writes it into battle management data. At this time, the initial HP value of the monster character data is randomly determined. For example, in the monster character data, the HP of the monster character MC1 is set as a range of 1500 to 2000, but as an initial value of HP used when performing an actual battle process, the HP is randomly selected from the range of 1500 to 2000. One value is determined.

CPU21 reads the data of the monster character which is appearing from battle management data, reads the data of the warrior card used by a battle from user data, makes it memorize | store in RAM23, and performs the following battle processes.
Specifically, for example, when one of the menus m11 and m12 ("Battle") is selected and a battle with a monster character is started, when the user attacks the monster character using a warrior card (For example, when the menu m20 (“attack”) is selected and operated on the web page P1 in FIG. 12), the CPU 21 reduces the monster character's HP according to the attack power value of the warrior card used. Process. Hereinafter, the operation on the menu m20 (“attack”) is referred to as “attack operation”.
For example, if the attack power of a warrior card is Pa and the coefficient determined at random is k, the calculation performed on the HP of the monster character by one attack operation is performed, for example, according to the following equation (1): You may be made to be. The updated HP value is sequentially overwritten in the RAM 23 during the execution of the battle.

HP = HP−Pa × k (1)

In addition, an attack is applied to the warrior card from the battle opponent's monster character with a constant or random attack power according to the attack operation. The attack power of the monster character may be a value that is approximately proportional to HP, or may be a constant or random value. The attack power applied from a monster character or the integrated value of the attack power (the integrated value of the attack power associated with multiple attack operations) exceeds the defense power of the warrior card. Become. When the user uses only one warrior card in battle, the user loses when the warrior card is defeated. When a plurality of warrior cards participate in the battle, the warrior cards to be attacked by the monster character may be determined in a certain order or randomly.

The update of the monster character's HP by the attack operation is not limited to the above-described formula (1). For example, Pa in the above formula (1) may be a numerical value determined randomly according to the attack operation from a predetermined range, not the attack power of the warrior card.
Moreover, the determination method of a battle win / loss can be set suitably. For example, if the HP of a monster character cannot be reduced to zero by a predetermined number of attack operations or by a predetermined time, it is determined that the monster character cannot be defeated.

When the updated monster character's HP value is not zero, the CPU 21 writes the updated monster character's HP (value on the RAM 23) into the battle management data. When the updated HP value of the monster character becomes zero, the CPU 21 determines that the monster character has been defeated, and erases the monster character data for the target user from the battle management data. The number of monster defeats in the user data as the game progress is increased by one.
When one battle is performed by the user, the CPU 21 accesses the user data of the user and performs a process of reducing the value of the attack point by a predetermined amount or an amount corresponding to the warrior card used in the battle.

The accepting unit 53 has a function of accepting a support request in a battle (first battle) from a user (first user) as a support request source.
The function of the accepting unit 53 can be realized as follows. For example, when the CPU 21 of the game server 20 recognizes that the user who is executing the game has performed an operation of selecting the menu m22 (“request for support”), the CPU 21 stores necessary data in the support request list in the game database 32. Accept support requests by writing. As shown in FIG. 9, data written in the support request list includes, for example, a user ID, a battle partner (a monster character when the user is defeated in the battle), a battle end time, and the like.

The determination unit 54 determines whether the first user battles (first match) according to the difference in the degree of progress of the game with the first user against a user other than the support requesting user (first user). ) Has a function for determining whether or not to make a support request.
The function of the determination means 54 is realizable as follows, for example. When the HTTP request for the game top page or the battle top page is transmitted from the communication terminal 10 of the user, the CPU 21 of the game server 20 has a smaller number of monster defeats than the user (that is, the progress is low). ) Search the support request list to see if there is a support request from the user. More preferably, the CPU 21 searches the support request list for whether or not there is a support request from a user whose number of monster defeats is a predetermined number or more than the user who transmitted the HTTP request. The comparison of the number of defeated monsters is performed by reading out and comparing the number of defeated monsters in the user data between the user who transmitted the HTTP request and the user described in the support request list.

The request unit 55 identifies the second user of the support request destination among users other than the support request source user (first user) according to the determination result of the determination unit 54, and A function for requesting support is provided.
The function of the request means 55 is realizable as follows. As described above, the CPU 21 of the game server 20 compares the number of monster destruction of user data between the user who transmitted the HTTP request and the user described in the support request list. Then, the CPU 21 transmits, to the communication terminal 10 of the user who has transmitted the HTTP request, the support request of the user whose monster destruction number is smaller than the user who has transmitted the HTTP request among the users described in the support request list. That is, every time an HTTP request for a game top page or battle top page is transmitted from a user, whether or not the user is requested to be a support request destination is determined based on the number of defeated monsters. A user is identified. In this case, the CPU 21 performs the above-described process for a user who transmits an HTTP request for the top page of the game or the top page of the battle until there is a reply to accept the support request from any user who has already transmitted the support request.
Note that the timing for specifying the second user is not limited to the example described above. As another example, the CPU 21 recognizes the user's selection operation of the menu m22 (“request for support”), refers to the user data at the timing when the support request is received, and is 1 or from the difference in the number of monster destruction at that time. A plurality of second users may be specified in advance. Then, when access is made by any one of the identified second users (that is, when an HTTP request for the top page of the game or the top page of the battle is transmitted), to the accessing user A request for assistance may be sent.

For example, as shown in the web page P6 of FIG. 13, the request unit 55 preferably responds to the support request from the user (first user) of the support request source with the first support (first to be described later). The second user has a function of presenting either the second support (first support by the support means 56) or the second support (second support by the second support means 57 described later) in a selectable manner. Also good. The first support is a support method in which another user who accepts the support request indirectly supports (supports) without directly participating in the battle of the support requesting user. The second support is a support method in which another user who has accepted the support request performs (participates in) a battle with a battle partner of the support requesting user.
In order to realize the function of the request means 55, the CPU 21 includes a message for notifying the HTTP request transmission source user that there is a support request from a friend and a support method selection menu. HTML data for displaying the page or the top page of the battle is transmitted (for example, see the web page P6 in FIG. 13).

The first support means 56 (support means) receives a predetermined operation input by a user other than the first user (second user) in response to a support request from the support requesting user (first user). Based on information, it has the function to perform the 1st support which adjusts the 1st user's battle capability in a battle, or the battle capability of the battle opponent of a battle so that a 1st user may become advantageous. Here, a 2nd user means the user who accepted the support request among the users of a support request destination. The second user is not limited to one user, and a plurality of second users may exist.
The function of the 1st assistance means 56 is realizable as follows. When the CPU 21 of the game server 20 recognizes a selection operation (predetermined operation input) of the menu m32 (“support”) from any user (second user of the support request destination), the support request source user ( In the battle to be supported by the first user), the attack power of the warrior card used by the first user is increased, or the attack power of the monster character of the battle opponent is reduced. The increase in the attack power of the warrior card or the decrease in the attack power of the monster character may be an increase or decrease in a predetermined ratio, or an increase or decrease in a predetermined amount.

The second support means 57 responds to a support request from a support requesting user (first user) by a user other than the first user (second user) as a battle opponent monster of the first user. It has a function of executing a second support for performing a battle with the character.
The function of the second support means 57 can be realized as follows. When the CPU 21 of the game server 20 recognizes a selection operation (predetermined operation input) of the menu m31 (“participate in battle”) from any user (second user of the support request destination), the user and the support target The battle process is executed with the monster character in the battle. Specifically, the CPU 21 generates HTML data so that the second user can perform an attack operation on the monster character in the battle to be supported, and transmits the HTML data to the communication terminal 10 of the second user. (For example, see web page P7 in FIG. 13). At this time, the HP of the monster character to be a battle opponent starts a battle based on the HP value written in the support request list.

(7) Flow of main processing of game control device of this embodiment Next, an example of the flow of main processing performed by the game control device of this embodiment will be described with reference to the sequence charts of FIGS. explain. FIGS. 16 and 17 show the game battle process of the present embodiment performed by the game control apparatus of the present embodiment. FIG. 16 shows a case where another user who has accepted the support request participates in the battle. 17 is a case where another user who accepts the support request supports. In FIGS. 16 and 17, the timing at which each web page described in FIGS. 13 and 14 is displayed is indicated by reference numerals.
In FIGS. 16 and 17, the user KNM is an example of the first user, and the user ABC is an example of the second user.

(7-1) In the case where the user who has accepted the support request participates in the support, first, when the user KNM (first user) who is executing the game loses the battle against the monster character MC1, for example, the web shown in FIG. Page P4 is displayed. Here, when the menu m22 (“request for support”) is selected and an HTTP request including a support request is received (step S100), the CPU 21 of the game server 20 stores necessary data in the support request list in the game database 32. Is written (step S110). As shown in FIG. 9, the data to be written includes, for example, a user ID, a battle partner (a monster character when the user is defeated in the battle), a battle end time, and the like. After writing in the support request list, the CPU 21 transmits HTML data for notifying that the support request has been received to the communication terminal 10 of the user KNM (step S120). Thereby, for example, the web page P5 of FIG. 13 is displayed on the communication terminal 10 of the user KNM. After the user KNM support request is written in the support request list, the CPU 21 recognizes the user who transmits the HTML data for displaying the game top page or the battle top page. Also, it is determined whether or not the number of monsters to be defeated is large, and if so, a support request from the user KNM is transmitted to the user (step S140). That is, a support request is made for a user who has more monster defeats than the user who requested the support (that is, the game progress is high). Here, it is assumed that a user KNM support request is transmitted to the communication terminal 10 of the user ABC. For example, the web page P6 of FIG. 13 is displayed on the communication terminal 10 of the user ABC that has received the support request.

When the menu m31 ("participate") is selected on the web page P6 and it is recognized that the support request has been accepted (step S150), the CPU 21 is the monster character MC1 in which the user ABC and the user KNM have been defeated in the battle. HTML data for the battle screen between and is generated and transmitted (step S160). As a result, for example, the web page P7 of FIG. 13 is displayed on the communication terminal 10 of the user ABC. At this time, the HP of the monster character MC1 in the battle of the user ABC is displayed by reading the data of the user KNM of the battle management data. Then, based on one or a plurality of attack operations of the user ABC, the CPU 21 performs a battle process (step S170). Here, when the user ABC defeats the monster character MC1, for example, the web page P8 of FIG. 13 is displayed on the communication terminal 10 of the user ABC in response to the transmission of the HTML data from the CPU 21.
After the battle between the user ABC and the monster character MC1, the CPU 21 updates the support request list, battle management data, and user data (step S180). For example, when the user ABC defeats the monster character MC1, the corresponding data (the monster character MC1 as the opponent of the user KNM) is deleted from the support request list, and the monster that the user KNM appears in the battle management data is deleted. Delete the monster character MC1 from the column. Moreover, CPU21 accesses the user data of user KNM and user ABC, and increases the number of monster defeats by 1, respectively.
Thereafter, for example, in response to reception of an HTTP request for a game or battle top page from the communication terminal 10 of the user KNM, HTML data for notifying the support result by the user ABC is transmitted to the communication terminal 10 of the user KNM. (Step S190). Thereby, for example, the web page P9 of FIG. 13 is displayed on the communication terminal 10 of the user KNM.

(7-2) In the case where the user who has accepted the support request supports the user by cheering Steps S100 to S140 are the same as in the case of (7-1), and thus redundant description is omitted.
When the menu m32 (“support”) is selected on the web page P6 and it is recognized that the support request has been accepted (step S200), the CPU 21 notifies that a predetermined privilege has been obtained through support. HTML data is generated and transmitted (step S210). Thereafter, when the HTML data is transmitted when the user KNM battles again with the monster character MC1 to be supported, the communication terminal 10 of the user KNM is supported by the support as illustrated in the web page P11 of FIG. A message is displayed to notify you that your attack power has increased. Thereafter, each time it is recognized that an attack operation has been performed in the battle process, the CPU 21 adjusts the attack power of the warrior card used by the user KNM to increase, for example, a certain amount or a certain ratio (step S240). In accordance with the attack operation, the CPU 21 updates the HP by determining the amount of decrease in the HP of the monster character MC1 based on the adjusted attack power (step S250). When updating the HP of the monster character MC1, the CPU 21 generates HTML data including the updated HP (step S260) and transmits it to the communication terminal 10 of the user KNM (step S270). In FIG. 17, steps S230 to S270 show a series of processes corresponding to one attack operation. However, when a plurality of attack operations are performed, the processes of steps S230 to S270 are repeated. Is called.

As described above, when the user ABC who has accepted the support request selects support by the support, the support method is not that the user ABC directly battles with the battle partner of the user KNM of the support request source, For example, the user KNM may adjust the battle ability of the user KNM as the support requester so that the user KNM is advantageous. In other words, the second support indirectly supports a battle with the monster character MC1 by the user KNM. That is, since the user KNM is assisted to win the battle with the monster character MC1 by, for example, the user's own operation, the user KNM can obtain a sense of achievement that the user has won the battle by winning the battle.

As described above, in the game control device of the present embodiment, the support request destination of the support request source user (first user) is determined according to the difference in the progress of the game. For example, a support request is made to a user (second user) who has more monster defeats than the first user (that is, the degree of progress of the game is high). Since the second user who has a high degree of progress of the game is considered to have a high ability on the game (for example, the ability of a warrior card used in battle), a support request is made to the second user, The support for the first user is highly effective. As a result, even a user with a low degree of progress of the game can feel the fun of the game according to the game scenario. Moreover, since the user with a high degree of game progress assists the user with the low degree of game progress, the game can be activated as a whole.

In the above embodiment, it is determined whether or not a support request is made according to the difference in the number of monsters to be defeated, and the difference in the number of monsters to be defeated can be set as appropriate. In addition, as described in the description of the above embodiment, the determination unit 54 determines the number of monster defeats (game progress) with the first user among the users other than the support requesting user (first user). It may be determined that a support request is made to a user whose difference is equal to or greater than a predetermined value.
In this configuration, it is possible to appropriately limit the number of support request destination users (second users). In addition, since the degree of progress of the second user can be set sufficiently higher than that of the first user, it can be expected to receive support from a user who has a sufficiently higher ability on the game than the first user. Effectiveness can be further increased.

In the above embodiment, it is not essential to provide the first support means 56. After the support request destination user (second user) is specified, the support method may be set as appropriate. The first support realized by the support means 56 is preferable in the following points.
The first support performed by the second user is not a direct battle with the battle partner of the support requesting user (first user), but the attack of the warrior card used by the first user in the battle It is to adjust the strength (first user's fighting ability) or the attack power of the first user's battle opponent so that the first user has an advantage. In other words, the first support indirectly supports the first battle by the first user. That is, since the first user is assisted to win the first battle by his / her own operation, for example, the first user can have a sense of accomplishment that he / she has won the battle.

In the above embodiment, it is not essential to provide the second support means 57. After the support request destination user (second user) is specified, the support method may be set as appropriate. The second user can assist the progress of the game of the first user also by the second support of performing the battle directly with the battle partner of the user (first user). In the second support, since the second user who has a high degree of game progress can receive direct support, the effectiveness of the support becomes higher.

In the above embodiment, the requesting unit 55 preferably responds to the support request from the support request source user (first user) as shown in the web page P6 of FIG. An example has been shown in which both the menu m32) and the second support (menu m31) method are presented, and the second user can select either support, but either one is not presented. May be presented. When both the first support method and the second support method are presented so that the second user can select one of the support methods, the second user can proceed with his / her game. It is possible to set a game setting that enables flexible selection according to the situation.

In the said embodiment, although the battle execution means 52 was comprised so that the said user's attack point (parameter on a game) might be consumed with execution of the battle by a user, it is not restricted to this. When the user is configured to consume attack points when performing a battle, the user who receives the support request (second user) is either the first support or the second support. In selecting the method, since it will be selected in consideration of the consumption of the attack points of its own by the second support (perform a battle with the battle opponent of the user of the support request source), deep game characteristics realizable.
For example, when the game setting is such that a privilege can be obtained by defeating a monster character or according to the number of monsters destroyed, the second user can compare the consumption of his / her attack points with the obtained privilege. It can be set as the structure to do. More specifically, in the case of performing the first support (indirect support), it is not necessary to reduce the attack points because the battle is not performed by itself, but only a relatively small amount of privilege is given, You cannot increase the number of monster kills. On the other hand, in the case of the second support (direct support), the number of monsters can be increased to gain comparatively large benefits by conducting battles, but the attack points decrease. This makes it impossible to execute another new battle immediately. Therefore, for the second user, the support method is selected in consideration of the circumstances of such loss.

(8) Modification Hereinafter, a modification of the above-described embodiment will be described.

(8-1) Modification 1
In the above-described embodiment, the first support means 56 calculates the number of monster defeats (game progress) between the support requesting user (first user) and the support requesting user (second user). Adjustment may be made such that the greater the difference, the more advantageous the first user. Thereby, as the progress degree of the game of the second user is higher than that of the first user, the progress of the game of the first user is facilitated by the support from the second user. As a result, the progress rate of the first user's game is adjusted depending on the second user who provides support, and the range of game characteristics can be widened.
In order to realize the first support means 56 of the present modification, the CPU 21 of the game server 20 receives the response of acceptance of the support request from the second user, and the first user and the second user The difference in the number of defeated monsters can be determined by referring to the user data. For example, the ROM 22 stores data indicating the relationship between the difference in the number of defeated monsters and the rate of increase of the attack power of the warrior card used by the user in the battle. CPU21 will determine the increase rate of the attack power of the warrior card which a 1st user uses with a battle with reference to the data in ROM22, if the difference of the monster defeat number is calculated | required.

(8-2) Modification 2
FIG. 18 is a functional block diagram for explaining functions that play a major role in the game control device of the present modification. The functional block diagram of FIG. 18 differs from that of FIG. 15 in that an association means 58 is added. The association means 58 has a function of relating users. For example, the associating unit 58 has a function of associating the user ID with another user ID when triggered by an application based on the user ID.

The function of the correlation means 58 is implement | achieved as follows, for example. The CPU 21 of the game server 20 sends an application message (application) specifying a user ID (or a corresponding user name) to be a friend from the communication terminal 10 of the user corresponding to a certain user ID via the communication interface unit 25. Accept. Transmission of this application message is preset as a function of a web page provided to the user's communication terminal 10. When receiving the application message, the CPU 21 approves an application based on another user ID to the communication terminal 10 corresponding to the user ID at the timing when the access is based on the user ID included in the application message. HTML data for displaying a web page for requesting the reply is transmitted. If it is replied that the application is approved, the CPU 21 registers both as friends. Specifically, the CPU 21 writes the data in the location (see FIG. 6) of “friend user ID” of the user data of the corresponding two user IDs in the user database 31.
In addition, the conditions which relate users are not limited to the format requiring application and approval as described above, and users who execute stages on the same game may be registered as friends. Alternatively, users who transmit a predetermined number of greeting messages may be automatically registered as friends, and if there is a mode on the game in which a battle is performed between users, the user who has performed the battle a predetermined number of times or more You may automatically register each other as a friend.
Further, instead of directly associating users with each other, the users in the group may be associated with each other by associating each user with the same group (guild or the like). For example, when the user A can apply for the specific user B in the user associated with the predetermined group and obtain the approval of the specific user B, the predetermined group and Associate user A. In this way, by applying and approving specific users within a given group, whether or not they are directly applying and approving belonging to a given group The users may be related to each other.
In this embodiment, although the example which implement | achieves by registering data in the user database 31 by registering the friendship relationship between users was shown, it is not restricted to this example. The data regarding the friendship may be written in an external storage device on the network accessible from the game server 20.

In the present modification, the requesting unit 55 may select the support requesting user (second user) from among users who are related to the support requesting source user (first user). . By selecting in this way, the first user can feel that he / she is receiving support from his / her friend, so that the relationship with the friend can be enhanced. Therefore, the social nature of the game can be improved.
The function of the request means 55 in this modification can be realized as follows.
When the HTTP request for the game top page or the battle top page is transmitted from the user, the CPU 21 of the game server 20 has more monster defeats than the user who transmitted the HTTP request among the users described in the support request list. A support request from a small number of fellow users is transmitted to the communication terminal 10 of the user who transmitted the HTTP request. In other words, each time an HTTP request for the game top page or battle top page is sent from a user, whether or not the user is requested for support is determined based on the number of monsters defeated and whether or not they are friends. By doing so, the second user is specified. Also in this case, the CPU 21 performs the above-described process for the user who transmits the HTTP request for the game top page or the battle top page until there is a reply for accepting the support request from any user who has already transmitted the support request. .

Note that if the support request destination user is limited to the friend of the support request source user, the second user (support request destination user) may not be able to determine. In other words, after making a support request, there is no log-in or access from a friend, support cannot be received in a timely manner, and the effectiveness of support may be lost. Therefore, the processing may be performed as follows.
Whenever an HTTP request for a game top page or a battle top page is transmitted from the user for a predetermined period after being written in the support request list, the CPU 21 requests an HTTP request from among the users described in the support request list. The number of defeated monsters is smaller than that of the user who transmitted the request, and the support request from the fellow user is transmitted to the communication terminal 10 of the user who transmitted the HTTP request. If there is no reply for accepting the support request from the support request destination user during the predetermined period, the support request destination user is not limited to the support request source user. That is, the CPU 21 transmits a support request from a user described in the support request list having a smaller number of monster destruction than the user who transmitted the HTTP request to the communication terminal 10 of the user who transmitted the HTTP request. .
In addition, when the end time is set in the battle, if there is no response to the acceptance of the support request from the friend by a predetermined time before the end time, the support requesting user is the friend of the support requesting user. You may make it not limit to.

(8-2) Modification 3
In the above-described embodiment, the first support executed by the first support means 56 (the battle ability of the first user who requested the support in the battle, or the battle ability of the battle partner of the first user battle, It may be allowed to accept a request for assistance from a plurality of users (adjusting the first user to be advantageous). In that case, the first user may be adjusted to be more advantageous as the number of users who accept the support request increases.
In order to realize this modification, for example, the CPU 21 requests a support every time an HTTP request for a game top page or a battle top page is transmitted from the user for a predetermined period after being written in the support request list. Among the users described in the list, a support request from a user having a smaller number of monster destruction than the user who transmitted the HTTP request is transmitted to the communication terminal 10 of the user who transmitted the HTTP request. Then, the CPU 21 counts the number of users who accepted the support request during the predetermined period (that is, performed the selection operation of the menu m32 (“support”)). CPU21 determines the increase rate of the attack power of the warrior card which a 1st user uses for a battle according to the count value, for example.
In the present modification, for example, when support is provided by support from five users on the web page P11 in FIG. 14, a message such as “Updating attack power with support from five users!” Is displayed. Is preferred.

As mentioned above, although embodiment of this invention was described in detail, this invention is not limited to the said embodiment. In addition, it goes without saying that each embodiment may be variously improved and changed without departing from the gist of the present invention. For example, the technical matters described in the above embodiment and each modification may be applied in appropriate combination.

In the embodiment and the modification described above, the case where a battle using a card is performed has been described as an example, but the present invention is not limited thereto. Other objects such as a user's avatar image may be used instead of the card. Or you may perform a battle process, without using objects, such as a card | curd.

In the above-described embodiment, an example in which the game to be executed of the present invention is a battle game using cards has been described. However, the present invention is not limited to this, and can be applied to any game. For example, in a game where a stage in a game is advanced, such as a role playing game or a race game, the progress rate of the stage of the support requesting user is increased according to the progress of the stage of the support requesting user. (For example, advancing speed of a character, a race car, or the like is increased), and the present invention can be suitably applied. In addition, when the present invention is applied to a shooting game such as FPS (First Person Person Shooter), TPS (Third Person Person Shooter), etc., the more the number of enemy objects destroyed by the user of the support request destination (that is, the target of the support request destination). As the degree of progress of the user increases, the diameter of the sighting displayed in the shooting of the user may be expanded as assistance given to the user who requested the assistance.

In the above-described embodiment, the number of monster defeats is given as an example of the progress of the game of the present invention, but the progress of the game can be arbitrarily set according to the nature of the game. For example, the number of stages cleared in the game, the number of items acquired in the game, or the number of times a specific mission given in the game has been achieved. You may decide according to a parameter and the frequency | count of selection of the specific menu on a game screen.

In the above-described embodiment, the predetermined operation input by the user to the communication terminal is an input of a pressing operation of a predetermined operation button on the user's communication terminal or an input of a touch operation on the display screen to the communication terminal having a touch panel function. Although there is, the operation input is not limited to this. The operation input may be an operation input by shaking a communication terminal provided with an acceleration sensor, or an operation input by gesture (gesture input). In gesture input, by performing a predetermined gesture on a communication terminal having an imaging function, the communication terminal recognizes an image of the gesture and recognizes an operation input previously associated with the gesture. In the case of a communication terminal capable of executing a voice recognition program, the operation input may be performed by inputting voice.

In the above-described embodiment, the case where the present invention is applied to a social game has been described as an example, but the present invention is not limited thereto. For example, in a so-called online game system in which a server device placed on a network and a home online game machine are connected, it goes without saying that the progress of the game by each user can be controlled as in the above-described embodiment.

In the above-described embodiment, the battle execution unit 52, the reception unit 53, the determination unit 54, the request unit 55, the first support unit 56, and the second support unit 57 are executed by the game server 20 and the database server 30 on the network. Although it is configured to realize each function, it is not limited to this configuration. All these means may be realized by the communication terminal 10, or at least a part of the means may be realized by the communication terminal 10. Since the communication terminal 10 and the game server 20 have substantially the same hardware configuration, each function can be realized by the communication terminal 10 as described in the above embodiment. FIGS. 19A and 19B each show an example of sharing between the communication terminal 10, the game server 20, and the database server 30 for each function (each function shown in FIG. 15) of the game control device of the present embodiment.

Claims

A battle execution means for performing a battle on the game by the user;
Receiving means for receiving a support request in the first battle from the first user;
A determination unit that determines whether to make a support request in the first battle according to a difference in the degree of progress of the game with the first user for a user other than the first user;
According to the determination result of the determination means, a request means for identifying a second user as a support request destination among users other than the first user, and requesting the support request to the second user;
A game control device comprising:
The determination means determines that a support request is made to a user other than the first user who has a difference in game progress with the first user equal to or greater than a predetermined value.
The game control apparatus according to claim 1.
Based on information of a predetermined operation input by the second user in response to the support request made by the requesting means, the battle capability of the first user in the first battle, or the first Characterized in that it comprises support means for executing a first support for adjusting a battle capability of a battle opponent so that the first user is advantageous.
The game control apparatus according to claim 1 or 2.
The support means adjusts the first user to be more advantageous as the difference in game progress between the first user and the second user is larger.
The game control apparatus according to claim 3.
The support request is to execute a battle with the opponent of the first battle by the second user,
The game control apparatus according to claim 1.
The requesting means is a first support for adjusting the first user to be advantageous in the first battle according to a determination result of the determination means, or the first support by the second user. The second user presents one of the second supports for performing a battle with an opponent of the battle so that the second user can select,
The game control apparatus according to claim 1 or 2.
The battle execution means consumes parameters on the user's game as the user executes the battle on the game.
The game control apparatus according to claim 6.
An association means for relating users,
The requesting unit selects the second user from users associated with the first user.
The game control device according to any one of claims 1 to 7.
Performing a game battle by a user;
Receiving a support request in the first battle from the first user;
Determining whether to make a support request in the first battle according to the difference in the degree of progress of the game with the first user for users other than the first user;
According to a determination result of the determining step, identifying a second user as a support request destination among users other than the first user, and performing the support request to a second user;
A game control method comprising:
On the computer,
A function for performing a game battle by a user,
A function of accepting a support request from the first user in the first battle;
A function for determining whether or not to make a support request in the first battle according to a difference in the degree of progress of the game with the first user for users other than the first user; and
A function of specifying a second user of a support request destination among users other than the first user according to a determination result of the function to be determined, and performing the support request to a second user;
A program to realize
A computer-readable recording medium in which the program according to claim 10 is recorded.
A game system including a communication terminal and a server accessed from the communication terminal,
A battle execution means for performing a battle on the game by the user;
Accepting means for accepting a support request in the first battle from the first user;
A determination unit that determines whether or not to make a support request in the first battle according to a difference in the degree of progress of the game with the first user for a user other than the first user, and
Request means for identifying the second user as the support request destination among the users other than the first user according to the determination result of the determination means, and making the support request to the second user,
Each of the means is provided in either the communication terminal or the server,
Game system.