JPWO2013094160A1 - GAME CONTROL DEVICE, PROGRAM, GAME SYSTEM - Google Patents

Abstract

  There are provided a game control device, a game control method, a program, a recording medium, and a game system that can provide a sense that a game is progressing in cooperation between users. In this game control method, the following processing is performed. A character on the game and character data that is character data are associated with each other and stored in the storage device. For each user, the character data is changed according to the user's operation. Information on the character of the first user among the plurality of users is provided to a second user different from the first user. Here, when the information of the first user's character is provided to the second user, the first user character data and the first user's character data are simultaneously displayed in accordance with the operation of the second user. The character data of the user's character is changed.

Description

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

  In recent years, a so-called social game (Social) executed by a game application created on the basis of an operating environment such as an API (Application Programming Interface) that operates 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 interacting with users than conventional online games. In social games, for example, in addition to cooperative play with other users (friends), information exchange by communicating with friends such as greetings and contacts with friends, gifts of items on the game with friends or items An exchange has been made. For example, in Non-Patent Document 1, in a digital card game (Dragon Collection (registered trademark)), when a user battles with another game character using his game character, a fellow game character is supplementarily supported. It is stated that you can borrow.

App STYLE Vol.2 (East Press, Inc.), pages 26-27

  In the game described in Non-Patent Document 1, when a user performs a battle by borrowing a game character from another user, there is no instruction in the battle from the other user, and the users cooperate with each other. You can't taste the feeling of doing a battle. That is, even if a user performs a battle by borrowing a game character from another user, it is not possible to obtain a sense of cooperation between the users in that battle.

  The present invention has been made in view of the above-described viewpoints, and provides a game control device, a game control method, a program, a recording medium, and a game system that can provide a sense that a user is advancing a game in cooperation with each other. Objective.

A first aspect of the present invention is a game control device that controls the progress of a game by each user in accordance with each operation of a plurality of users.
This game control device
Storage means for storing a character on the game and character data as character data in association with each other;
For each user, control means for changing the character data according to the user's operation;
Providing means for providing information identifying a character of a first user among the plurality of users to a second user different from the first user;
With
When the information for specifying the first user's character is provided to the second user, the control means is configured to send the character data of the second user's character according to the operation of the second user. At the same time, the character data of the first user's character is changed.

In this game control device, “character data” is data related to a character and can be changed in accordance with the progress of the game. The character data may take various types of data depending on the nature of the game. For example, in the case of a battle game, the character data may be a value (HP) indicating the physical strength of the enemy character.
In this game control device, the “information for identifying a character” may be any information as long as it is information that can distinguish different characters on the game, or information that can identify a character on the game. For example, the information specifying the character may be an image showing the appearance of the character, text showing the name of the character, or an identification code for specifying the character.
In this game control device, the “character” is, for example, a virtual person, creature, or monster on the game, and includes those displayed on a card.

In this game control device, a game is advanced for each user with respect to a plurality of users while the character data is changed according to the user's operation. Further, in this game control device, when the information specifying the character of the first user is provided to the second user, the character data of the character of the second user is changed according to the operation of the second user. In addition, the character data of the first user character is also changed. Thereby, since the operation of the second user can directly affect the progress of the game of the first user, the first user and the second user proceed with the game in cooperation with each other. You can get the feeling of doing it.
The user character may be an enemy character in the case of a competitive game, but may be set as appropriate depending on the nature of the game. For example, in the case of a game in which each of a plurality of users competes for growing a plant or the like, the user's character may be a plant character to be a user's growing target.
In this game control device, the control means does not display the second user character on the display screen presented to the first user, and does not display the second user character on the display screen presented to the second user. May be displayed.

  In the game control apparatus, character data of each of the first user character and the second user character may be displayed on a display screen presented to the second user. Thereby, since the 2nd user can visually recognize the change result of the character data of his character and the change result of the character data of the 1st user's character based on his operation, it cooperates mutually. You can feel the sense that the game is progressing.

In the game control device, each user's character is associated with an attribute,
When the first user character and the second user character have the same attribute, the control means obtains the character data of the first user character according to the operation of the second user. It may be changed.
In this game control device, the “character attribute” refers to, for example, a character's form and / or color, pattern, character itself and ability (numerical level), and a specific sound (scream) set for the character. Etc.) may include any characteristic that can visually and / or audibly distinguish character differences. In the case of a competitive game, the user's character attribute may be an enemy character attribute.
According to this game control device, even if the second user has a plurality of characters with different attributes set on the game, the second user is responsive to the progress of the game of the first user among his / her characters. It is possible to proceed with the game while recognizing characters that can be affected.

  In the above-described game control device, when the information specifying a plurality of user characters is provided to the second user, the control means can select either one based on a selection operation by the second user. The character data of the selected character may be changed together with the character data of the character of the second user in accordance with the operation of the second user. That is, the second user can select which character to select. Thereby, for example, the second user can select a character having the same attribute as that of his / her character, so that it is easy to advance the game in cooperation with other users.

  The game control apparatus includes a second storage unit that stores associations between the plurality of users, and the providing unit specifies a user associated with the first user as the second user. May be. The association between the users may be performed by associating the users with each other as a friend in advance. By this game control device, the users who advance the game in cooperation are limited to the users associated in advance, so that the relationship between the users can be further strengthened. Thereby, activation of the community between friends can be aimed at, for example.

  The game control apparatus includes a second storage unit that stores associations between the plurality of users, and the providing unit includes the first user among the plurality of users associated with the first user. Inquiries about whether or not to provide information specifying the user's character may be made, and the user who first responded that the information is desired to be provided may be specified as the second user. Thereby, the user's desire to quickly advance the game in cooperation with other users can be satisfied.

A second aspect of the present invention is a game control apparatus that controls the progress of a game by each user in accordance with each operation of a plurality of users.
This game control device
Storage means for storing the enemy character of the user on the game and character data that is data of the enemy character in association with each other;
For each user, control means for changing the character data according to the user's operation;
Providing means for providing information for identifying an enemy character of the first user among the plurality of users to a second user different from the first user;
With
When the information for specifying the enemy character of the first user is provided to the second user, the control means, in response to the operation of the second user, the character of the enemy character of the second user Simultaneously with the data, the character data of the enemy character of the first user is changed.

A third aspect of the present invention is a game control method for controlling the progress of a game by each user in accordance with each operation of a plurality of users.
This game control method
Storing a character on the game and character data that is character data in a storage device in association with each other;
For each user, changing the character data according to the user's operation;
Providing information for identifying a character of the first user among the plurality of users to a second user different from the first user;
Including
In the step of changing, when information specifying the first user's character is provided to the second user, the character data of the second user's character according to the operation of the second user. At the same time, the character data of the first user character is changed.
When information specifying the first user's character is provided to the second user, the second user's character is not displayed on the display screen presented to the first user. A step of displaying the first user's character on the display screen presented to the user.

According to a fourth aspect of the present invention, in order to control the progress of a game by each user in accordance with each operation of a plurality of users,
A function for storing a character on the game and character data that is character data in a storage device in association with each other;
For each user, a function for changing character data in accordance with a user operation,
A function of providing information for identifying a character of a first user among the plurality of users to a second user different from the first user;
It is a program for realizing.
In this program, when the information for specifying the character of the first user is provided to the second user, the function to be changed is the second user's operation according to the operation of the second user. The character data of the first user character is changed simultaneously with the character data of the character.
In addition, when the information which specifies the 1st user's character is provided with respect to the 2nd user with the said program, a 2nd user's character is displayed on the display screen shown to a 1st user. Instead, a function of displaying the first user's character on the display screen presented to the second user may be realized.

  The computer may be a network server, a large computer, or the like, for example. 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 fifth aspect of the present invention is a computer-readable recording medium in which the program is recorded.

According to a sixth aspect of the present invention, there is provided a communication terminal operated by a user, a game control device connected to the communication terminal via a network, and controlling the progress of a game by each user according to each user's operation; , A game system provided with
This game system
Storage means for storing a character on the game and character data that is character data in association with each other;
For each user, control means for changing the character data according to the user's operation, and
Providing means for providing information identifying a character of a first user among the plurality of users to a second user different from the first user;
Each means is provided in either one of the communication terminal or the server,
When the information for specifying the first user's character is provided to the second user, the control means is configured to send the character data of the second user's character according to the operation of the second user. At the same time, the character data of the first user's character is changed.
The control means may not display the second user character on the display screen presented to the first user, but may display the first user character on the display screen presented to the second user. .

The figure which shows the basic composition of the game system of embodiment. The figure which shows the example of the external appearance of the communication terminal of embodiment. The figure which shows the 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 functional block diagram for demonstrating the function to play main roles with the game control apparatus of embodiment. The figure which shows an example of the display screen of the communication terminal which displays a top page. The figure which illustrates the content of the data of a monster character. 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 the contents of battle data. The figure which illustrates the contents of battle data. The figure which illustrates a series of web pages displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The flowchart which shows an example of the main processes of the game server of embodiment. The figure which illustrates a series of web pages displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal.

  The present invention relates to the patent application of Japanese Patent Application No. 2011-277722 filed with the Japan Patent Office on December 19, 2011, the entire contents of which are incorporated herein by reference.

(1) First Embodiment Hereinafter, a first embodiment will be described.

(1-1) Configuration of Game System FIG. 1 shows a system configuration example of the game system of 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 operates the communication terminal 10 on the web page to execute a game.

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.
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.

(1-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 showing an example of the appearance of the communication terminal 10, and FIG. 2A exemplifies a button input type communication terminal such as a foldable mobile terminal (mobile phone), for example. FIG. 2B illustrates a touch panel input type communication terminal 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 wireless communication interface unit 17 serving 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. The CPU 11 then displays data for displaying a web page from the game server 20 via the wireless communication interface unit 17 based on appropriate designation of a URL (Uniform Resource Locator) input to the user by the instruction input unit 15 or the like. 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 wireless communication interface unit 17. The HTML data is interpreted. 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 wireless communication interface unit 17. To the game server 20.

  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 display image data provided from the CPU 11 as an analysis result of HTML data. The display unit 16 is, for example, an LCD (Liquid Cristal Display) monitor including thin film transistors arranged in a pixel unit in a matrix, and drives the thin film transistors based on the display image data to display the image of the web page on the display screen 16a. 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 “#” (tenkeys) 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.

(1-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. 3, the game server 20 includes a CPU 21, a ROM 22, a RAM 23, a database (DB) access unit 24, and a wireless communication interface unit 25, for transmitting control signals or data signals between the units. 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 wireless communication interface unit 25.

For example, the CPU 21 transmits HTML data to the communication terminal 10 via the wireless 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.

(1-4) Configuration of Database Server The database server 30 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 server 20 of the present embodiment is not particularly limited, but in the following, as an example of a game realized by the game server 20 for convenience of description of the embodiment, a user communication terminal In response to an operation on the game 10, a battle type digital card game in which a user battles with a monster character that is a monster on the game using a warrior card virtually held in the game is taken up.
This digital card game is a game in which a user collects a warrior card to create his or her own team (army), for example, a battle with another user's team (army) or a monster character. . This digital card game includes a mission execution process to search for warrior cards to create your own team, a lottery process that allows you to obtain warrior cards by lottery, or two or more warrior cards. Strengthening processing to improve the ability of warrior cards is provided.

  FIG. 6 shows an example of a user database 31 applied in the above-described competitive digital card game. In this example, the user database 31 has a display name / display image, skill level, physical strength points, attack points, strengthening points, friendship points, number of warriors, possessed coins, and fellow user IDs for each user ID (user identification information). , Information about each item of possessed card image data and possessed card parameters. Information included in the user database 31 can be updated sequentially by the game server 20.

In the following description, user IDs included in the user database 31 or data for each display name (to be described later) that identifies a user are collectively referred to as user data. The data of each item constituting the user data is as follows.
Display name / display image A display name and a display image that are displayed to identify the user of the communication terminal 10 when the game is executed. The display name is a text of a predetermined length or less designated in advance by the user, and the display image is an avatar image selected in advance by the user, for example. The display 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).
-Physical point This is a point necessary for performing the mission on the game by the user in the above-mentioned competitive digital card game. The health point is a value that decreases by performing the mission and recovers (increases) every time a predetermined time elapses.
-Attack point It is a point which is needed when performing a battle on a game by a user in the above-mentioned battle type digital card game. The attack point is a value that is reduced by a battle with another user or a monster character and is recovered (increased) every time a predetermined time elapses.
-Strengthening points These points are necessary for strengthening warrior cards by the user in the above-mentioned competitive digital card game. The strengthening point is a value that is reduced by strengthening the warrior card and is recovered (increased) every time a battle with another user is won or a predetermined time elapses.
-Friendship point In the said battle | competition type digital card game, it is a point which a user acquires by transmitting a support message to a friend.
-Number of warriors This is the number of warrior cards held by the user. The number of warriors increases and decreases with the execution of mission execution processing and reinforcement processing. The maximum number of warriors (for example, 60) is defined in advance.
-Owned coin This is the possessed amount of virtual currency (coin) on the game that is required when the user corresponding to the user ID uses the pay function on the game. The possessed coins are consumed (reduced) when the user uses a paid function on the game, and the user pays actual money to the service provider or the like by a predetermined method, and increases according to the amount paid.
・ Friend's user ID
This is data of another user ID previously associated with the target user ID.
-Image data of possession card In the case of the above-mentioned battle type digital card game, the image data of possession card is data including the image about the warrior card possessed by the user.
-Owned card parameter The held card parameter is data indicating the ability value of the warrior card. For example, as shown in FIG. 6, each capability value of “attack power” and “defense power” and “necessary points” may be included as parameter items. “Necessary points” are points required when using a warrior card in battle. In this game, the total required points of warrior cards used in battles may be limited to be equal to or less than attack points.

  Returning to FIG. 5, the game database 32 stores and updates information related to the progress of the game executed by the game server 20 based on the access from the game server 20. Information relating to the progress of the game may include various information depending on the nature of the game. Taking the case of a battle-type digital card game as an example, the information related to the progress of the game includes the results of battles between different users, the processing results of excavation execution processing described later, and the like.

(1-5) Overview of Each Process in Game Control Device In the present embodiment, the game control device is configured by the game server 20 and the database server 30. In the following, functions implemented by the game control device of the present embodiment will be described with reference to FIG. 7, taking as an example the case where the above-described competitive digital card game is applied. FIG. 7 is a functional block diagram for explaining functions that play a main role in the game control apparatus of the present embodiment.
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 of the mark on the display screen can be changed by scrolling the web page by the user's direction instruction button.

The registration unit 51 recognizes a user request based on an appropriate operation input to the communication terminal 10 on a web page provided to the communication terminal 10, for example, and performs a registration process. The registration means 51 in this case is executed as follows, for example. The CPU 21 of the game server 20 receives a registration request message from the communication terminal 10 via the wireless communication interface unit 25. The registration request message is automatically generated by a predetermined operation (for example, a predetermined menu selection operation, text input, etc.) on the communication terminal 10 on the web page provided from the game server 20. May be configured. The registration request message may include information (for example, IP address, e-mail address, etc.) for specifying the communication terminal 10 as the transmission source, or the user has already played another game by the same service provider. If used, the user ID may be included.
When the CPU 21 receives the registration request message and the registration request message does not include a user ID, the CPU 21 issues a new user ID and performs registration processing for 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.

The registration unit 51 may also register the user ID in association with another user ID triggered by an application based on the user ID. That is, the registration unit 51 registers another user ID (that is, another user) as a “friend” with an application based on the user ID as a trigger.
The registration means 51 in this case is executed as follows, for example. The CPU 21 of the game server 20 applies an application message (application) specifying a user ID (or a corresponding display name) that the user wants to become a friend from the communication terminal 10 of the user corresponding to a certain user ID via the wireless 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 “mate” part (see FIG. 6) of the user data of the corresponding two user IDs in the user database 31.

The game progress means 52 advances the game by transmitting HTML data for sequentially updating web pages displayed on the communication terminal 10 in response to a user operation on the communication terminal 10. In an example of a battle-type digital card game (hereinafter simply abbreviated as “game” as appropriate), the following processing can be performed to advance the game.
・ Mission execution processing:
This is a process to get a warrior card by completing a mission to build your own team. In this game, a certain amount of action points are required to complete the mission.
・ Strengthening process:
It is a process that increases the ability of a specific warrior by integrating two or more warrior cards. In this game, a certain amount of strengthening points is required for the user to execute the strengthening process.
・ Battle execution process:
This is a process of performing a battle with another user's team.
・ Lottery processing:
This is a process in which a user performs a lottery for obtaining a warrior card.
・ Excavation execution processing:
This is a process of executing a play to capture the land by excavating the land in accordance with the user's operation and defeating the monster character of the land (described later).

  The display means 521 has a function of causing the communication terminal 10 to display a plurality of menus to which the plurality of processes executed in the game are assigned. Specifically, the CPU 21 generates HTML data for displaying a web page including a plurality of menus, and transmits the HTML data to the communication terminal 10. In the game, points on the game are consumed with the execution of the mission execution process, the reinforcement process, the battle execution process, and the lottery process.

An example of the top page of the game displayed on the communication terminal 10 by the display means 521 is shown in FIG. This top page is composed of web pages corresponding to individual user IDs. The top page illustrated in FIG. 8 includes a user data display area, a warrior image display area, and a menu display area.
In the user data display area, the skill level, physical strength point, attack point, strengthening point, friendship point, number of warriors, and data of each item included in the user data of the target user ID (see FIG. 6) are displayed. Area. It should be noted that in the items displayed in the user data display area, the point or number written in the X / Y format is that X is the point or number held by the user, and Y is the maximum value of the point or number. It shows that there is. For example, if the number of warriors is written as “40/60”, it indicates that the number of warrior cards held by the user is 40 and the maximum number of warrior cards that can be held is 60.
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 a basic menu corresponding to the multiple functions (mission execution process, reinforcement process, battle execution process, lottery process, excavation execution process) provided in the competitive digital card game. This is an area in which the menus m1 to m5 on which the texts “battle”, “lottery”, and “excavation” are written are displayed. That is, a plurality of menus to which a plurality of processes executed in the game are assigned are respectively arranged at predetermined positions on the web page displayed on the communication terminal 10.

For example, when the top page shown in FIG. 8 is displayed on the communication terminal 10 of the user, the game progress means 52 is realized as follows. The CPU 21 of the game server 20 accesses the user database 31 via the database access unit 24, and reads the data of each item included in the user data display area and the image data of the warrior card to be displayed in the warrior image display area. Next, the CPU 21 generates HTML data so that the top page shown in FIG. 8 is configured, and transmits it to the communication terminal 10. The generated HTML data is different for each user (that is, for each user ID). The communication terminal 10 interprets the received HTML data and displays the top page image on the display unit 16 (display screen 16a).
The game progress means 52 performs a mission execution process, a reinforcement process, a battle execution process, a lottery process, and an excavation execution process, respectively, according to the user's selection operation for any of the menus m1 to m5 displayed on the communication terminal 10. Run. Preferably, when each process is executed, each process is executed hierarchically so that a new web page including a plurality of subdivided menus is displayed.

[Drilling execution processing]
As described above, the game progression means 52 has a function of executing excavation execution processing for each user and advancing the game using a character whose character data can be changed according to the user's operation. The function of the excavation execution process in the game progress means 52 and the method for realizing it will be described in detail below.

  During the excavation execution process, the monster character data on the game is referred to by the CPU 21. FIG. 9 exemplifies the contents of the monster character data, and is data that is loaded and stored in, for example, the RAM 23 together with the execution of the excavation execution process. This data may be stored in the game database 32. In FIG. 9, as an example, for each of the three types of monster characters MC1 to MC3 having different attributes, the level (Lv), the attack value, the defense value, and the monster character HP value ( A value indicating physical strength; character data) is shown. As the level of the monster character increases, the attack power value, the defense power value, and the HP value of the monster character may be set to increase. Although three types of monster characters having different attributes are shown in FIG. 9, in the present embodiment, at least one type of monster character may be provided. In FIG. 9, the image of the monster character is an example of the attribute of the monster character.

The flow of the game by the excavation execution process is as follows.
The excavation execution processing includes processing of each game in excavation mode and battle mode. In the excavation mode, a plurality of sections of land are dug in order (excavated) in response to a user operation, and a monster character appears when each section is dug. When a monster character appears, it shifts to a battle mode in which a battle is performed between the warrior card held by the user and the monster character that appears, in accordance with the user's operation on the communication terminal 10. When the HP (value indicating physical strength) of the monster character becomes zero due to the attack of the warrior card, the monster character is defeated and the land of the section where the monster character appears is captured, and the section of the land to be excavated by the user Move to the next section. On the other hand, if the warrior card loses physical strength due to the attack of the monster character, the capture of the land in the section where the monster character appears has failed, and the monster character will not disappear from the section. In that case, after the physical strength of the warrior card is recovered, the user performs a battle with the same monster character again.

The flow of the excavation mode in the excavation execution process will be described with reference to FIG. FIG. 10 shows an example in which the user who performs the operation is “KNM” (hereinafter referred to as user: KNM). Steps S1 to S3 in FIG. 10 sequentially show examples of web pages displayed on the user communication terminal 10 in the excavation mode.
First, when the menu m5 is selected and operated by the user on the top page of FIG. 8, HTML data is generated and transmitted to the communication terminal 10 so that the top page of the excavation execution process is displayed on the communication terminal 10 of the user. (FIG. 10, step S1). Step S1 in FIG. 10 is a top page in the excavation execution process. In the battle mode to be described later, for example, a display area 100 for enabling display of a maximum of three monster characters as battle opponents, For example, a display area 200 for displaying a maximum of three monster characters as battle opponents of the user is included.

When the CPU 21 recognizes that the “start” menu m7 on the top page has been selected, the web page displayed on the user's communication terminal 10 displays the land of a predetermined number (10 in FIG. 10) of sections. The display image 300 representing, the display image 350 representing the excavation rate of the land of the target section, and the menu m8 of “digging” are transferred (FIG. 10, step S2). In the display image 300, it can be visually recognized that the land of the section to be excavated by the user is the section 301. Here, each time the CPU 21 recognizes that the “digging” menu m8 has been selected, the value of the “digging rate” (%) displayed in the display image 350 increases by a random increase amount. Displayed. When the “excavation rate” (%) displayed in the display image 350 reaches 100%, the excavation of the land in the section is completed (FIG. 10, step S3).
It should be noted that every time the “digging” menu m8 is selected, the user's physical strength points are consumed by a certain amount, and the digging cannot be continued when the physical strength points become zero. In that case, it is necessary to wait until the health points are recovered.

  FIG. 11 shows an example of a web page displayed on the communication terminal 10 when the excavation rate reaches 100% and shifts to the battle mode. As shown in step S4 of FIG. 11, an image of an appearing monster character and its level (Lv8 in FIG. 11) are displayed, and in order to select one user to fight against the appearing monster character. Menu m10 and a menu m11 for making a battle support request to a fellow user.

The providing means 523 provides information on the monster character of the first user (that is, the monster character that is the battle opponent of the first user; enemy character) to the communication terminal 10 of the second user different from the first user. It has the function to provide. In other words, the providing means 523 allows the second user to simultaneously attack the monster character that is the battle opponent of the first user who is the other user, in addition to the monster character that is the battle opponent. The function which provides the 2nd user's communication terminal 10 with the information which specifies the monster character of a 1st user is provided. In the following description, the user: KNM corresponds to the “first user”, and the user: ABC corresponds to the “second user”.
In the following, in response to an operation on the communication terminal 10 of the first user, the support request message for making a support request to the game server 20 is transmitted from the communication terminal 10 of the first user. The case where the function of the providing unit 523 is realized will be described, but is not limited thereto. The support request message may be automatically transmitted from the game server 20 to the communication terminal 10 of the fellow user while shifting to the battle mode.

Referring to FIG. 11, the function of the providing unit 523 is specifically realized as follows.
When the CPU 21 of the game server 20 recognizes that the menu m11 has been selected in the web page shown in step S4 of FIG. 11, the user: KNM user data is identified with reference to the user: KNM user data, and the identification is made. HTML data for displaying a friend in a selectable format is transmitted to the communication terminal 10 of the user: KNM. Thereby, the web page shown in step S5 of FIG. 11 is displayed on the communication terminal 10 of the user: KNM. In this web page, a case where user: ABC is selected as the support request destination user on the web page list in step S5 will be described as an example.

  User: When receiving a support request message designating user: ABC as a support request destination user from communication terminal 10 of KNM, CPU 21 displays menus m20, m21 for selecting whether or not to accept the support request. HTML data for displaying the web page to be included is transmitted to the communication terminal 10 of the user: ABC. In the transmission of the HTML data, the avatar image of the user: KNM who is the support request source and the information specifying the monster character of the battle partner of the user: KNM are provided to the user: ABC. In step S5 of FIG. 11, the information for specifying the provided monster character shows an example including the image and level of the monster character, but is not limited thereto. The text for specifying a monster character may be sufficient.

  When the CPU 21 of the game server 20 recognizes that the menu m20 is selected on the web page shown in step S5 of FIG. 11, it becomes a battle partner in the battle mode for the communication terminal 10 of the user: KNM and the user: ABC. HTML data for displaying a monster character is transmitted. As a result, as shown in step S <b> 6 of FIG. 11, for example, the monster character MC <b> 1 is arranged in the sub area 101 of the display area 100 on the web page displayed on the communication terminal 10 of the user: KNM. User: On the web page displayed on the ABC communication terminal 10, the monster character MC <b> 1 is arranged in the sub area 201 of the display area 200.

The above is an example of a method for realizing the providing unit 523. In addition, CPU21 produces | generates battle data for every user in RAM23 at the time of step S6. The battle data is for managing data of a monster character that is a user's battle opponent. Examples of battle data generated at the time of step S6 in FIG. 11 are illustrated in FIGS. 12A and 12B. FIG. 12A is an example of battle data corresponding to user: KNM, and FIG. 12B is an example of battle data corresponding to user: ABC. As shown to FIG. 12A and FIG. 12B, battle data are level (Lv) about the monster character used as the battle partner of one's own battle, and the monster character used as the battle partner of the other user who accepted the support request for every user. , Attack power, and HP (value indicating physical strength; character data). The attack power of the monster character and the initial HP value may be determined randomly with reference to the data of the monster character shown in FIG. As will be described later, when an attack is applied to the monster character according to the attack instruction during the battle, the CPU 21 accesses the battle data each time and changes the HP value of the monster character subjected to the attack. CPU21 deletes the monster character from which HP became zero during battle from battle data.
The RAM 23 that stores the HP (character data) of the monster character in the battle may be an example of the storage unit 522. Further, the CPU 21 accessing the RAM 23 for storing and updating the HP of the monster character in the battle may be an example for realizing the storage unit 522.

  In step S6 of FIG. 11, gauges 101g and 201g indicating the HP of the monster character are displayed in the sub areas 101 and 201 where the monster character is arranged, respectively. This gauge is a scale that decreases in accordance with the degree of attack on the monster character of the warrior card by the user's operation, and is linked to the value of the monster character's HP in the battle data.

The control means 524 has a function of changing the HP (character data) of a monster character that is a user's battle partner for each user in accordance with the user's operation. In this embodiment, more specifically, the control means 524 reduces the HP of a monster character by a warrior card held by the user attacking the monster character based on an attack instruction based on the user's operation. It has a function to make it.
Further, the control means 524 provides information for identifying the monster character of the first user (support requesting user; KNM) to the second user (user who accepted the support request; ABC). A function of changing the HP value of the first user's monster character at the same time as the HP value (character data) of the second user's monster character according to the operation of the second user. Note that the control unit 524 may display the first user character on the display screen presented to the second user without displaying the second user character on the display screen presented to the first user. .

In the following description, a monster character that is a battle partner of the user: KNM is an enemy character of the user: KNM, and a monster character that is a battle partner of the user: ABC is an enemy character of the user: ABC.
Referring to FIG. 13, the function of the control means 524 is specifically realized as follows. FIG. 13 is a diagram illustrating a series of web pages displayed on the communication terminal 10 of the user: ABC who has accepted the support request from the user: KNM. In step S7 of FIG. 13, as a result of accepting the support request from the user: KNM, the monster character that is the battle partner of the user: KNM is arranged and displayed in the sub-area 201 of the display area 200, and then the own battle is performed. An example in which a monster character as an opponent appears and is arranged in the sub area 101 of the display area 100 is shown. At the time point when step S7 in FIG. 13 is displayed, information specifying the monster character of the user: KNM (first user) is already provided to the communication terminal 10 of the user: ABC (second user). It is assumed that

  In this case, the attack on the monster character of the battle opponent (monster of the sub area 101) by the warrior card possessed by the user ABC is against the monster character of the battle opponent of the user: KNM (the monster character of the sub area 201). Is also configured to be effective (that is, to reduce physical strength). For example, on the web page shown in step S7 of FIG. 13, when the menu m23 on which the text “attack a monster” is selected, an attack instruction message is transmitted from the communication terminal 10 to the game server 20. When receiving the attack instruction message, the CPU 21 of the game server 20 generates HTML data for displaying a state in which a plurality of warrior cards (C1) possessed by the user: ABC simultaneously attack two monster characters, and the user : Transmit to the ABC communication terminal 10. As a result, the web page shown in step S8 of FIG. 13 is displayed on the communication terminal 10 of the user: ABC. In this web page, the same gauge G as the gauges 101g and 102g is displayed on each of the two monster characters.

  A battle between a plurality of warrior cards on hand and a monster character may be set as follows. For example, the number (for example, 5 to 10) of warrior cards that can participate in a battle with a monster character from among warrior cards held by the user is defined in advance. The user consumes a certain amount of attack points and performs one attack on the monster character with one or more warrior cards. The monster character's HP value decreases according to the sum of the attack power values of one or more warrior cards participating in the attack. If the attack point becomes zero, the monster character cannot be attacked. On the other hand, an attack is applied from the monster character to the warrior card at random timing with the attack power shown in the battle data. As a result, if the HP value of the monster character becomes zero within a certain period of time, it is determined that the user's warrior card has won and succeeded in the capture of the land in the block, otherwise the user Is judged to have failed to capture the land in the parcel.

  More specifically, when the CPU 21 recognizes that the menu m23 has been selected, the CPU 21 selects, for example, a warrior card that performs an attack from a predetermined number of warrior cards participating in the battle, at a certain standard or randomly. The total of the attack power of the warrior card may be read from the user data and subtracted from the HP value of the monster character in the battle data in the RAM 23. The CPU 21 writes the HP value of the monster character after subtraction into battle data, determines the scale amount of the gauge G according to the value after subtraction, and generates HTML data. At this time, CPU21 performs the process which subtracts from the value of HP of all the monster characters currently displayed on a user's web page. That is, regardless of the number of monster characters displayed on the communication terminal 10 of the user, the CPU 21 can attack all monster characters by one attack (that is, consumption of one attack point) by the user. The battle data is updated so as to lower the HP. For example, the web page shown in step S9 of FIG. 13 indicates that the HPs of both monster characters have decreased due to a single attack of the warrior card. Note that the amount of change in HP of the two monster characters may be different. For example, even if the attack power is the same, there may be a case where the amount of HP change to be reduced varies depending on the level of the monster character.

  Various methods can be adopted as a method of changing the amount of change in HP of two monster characters. For example, the amount of change in the HP of the monster character of the second user (user who accepted the support request; ABC) to be processed is set to that of the HP of the monster character of the first user (user who requested the support; KNM). You may take the method of making it larger. In this case, in the attack by the 2nd user, the attack to the monster character of the battle opponent is mainly performed, and the attack to the monster character of the 1st user's battle partner is performed in a secondary manner.

  In FIG. 13, a monster character can be selected by selecting either the sub-area 101 or the sub-area 201 so that the user can specify the monster character that is the main attack target. In this case, the amount of change in HP of the main attack target monster character specified by the user may be larger than that of the monster character not specified. That is, in the example of FIG. 13, when the selection operation for the menu m23 (“attack a monster”) is recognized in a state where the sub area 101 is selected, the CPU 21 determines the HP of the monster character of the battle opponent of the user: ABC. The amount of change may be larger than that of the monster character of the battle partner of the user: KNM. Conversely, when the selection operation for the menu m23 (“attack a monster”) is recognized in a state where the sub-area 201 is selected, the CPU 21 determines the amount of change in the HP of the monster character of the battle partner of the user: KNM. : It may be larger than that of the monster character of the ABC battle opponent.

13 is an example in which only one monster character is displayed in each of the display area 100 and the display area 200. However, when a plurality of monster characters are displayed in each area, each sub area is displayed. In other words, the monster character that is the main attack target may be designated (selected) by the user for each monster character. In that case, processing may be performed as follows.
When any monster character displayed in the display area 100 is designated, the CPU 21 is identical to the designated monster character among the monster characters displayed in any sub-area of the display area 200. It is determined whether or not there is a monster character with the attribute of. When there is a monster character with the same attribute, the CPU 21 changes the HP of the monster character designated as the monster character, and when there is no monster character with the same attribute, the CPU 21 Only HP is changed. Note that the CPU 21 changes only the HP of the designated monster character even when another monster character having the same attribute as the monster character designated in the display area 100 exists in the display area 100.
On the other hand, when any one of the monster characters displayed in the display area 200 is designated, the CPU 21 designates the designated monster character among the monster characters displayed in any sub-area of the display area 100. It is determined whether or not there is a monster character having the same attribute. When there is a monster character with the same attribute, the CPU 21 changes the HP of the monster character designated as the monster character, and when there is no monster character with the same attribute, the CPU 21 Only HP is changed. Note that the CPU 21 changes only the HP of the designated monster character even when another monster character having the same attribute as the monster character designated in the display area 200 exists in the display area 200.
In order to realize the above-described processing, the battle data shown in FIGS. 12A and 12B is associated with each battle opponent, and is configured so as to describe a sub-area where the battle opponent is displayed. The CPU 21 refers to the battle data and identifies the battle opponent corresponding to the sub-region designated by the user. For example, when the CPU 21 specifies any one of the “other users and their battle opponent” in the battle data as the designated monster character, the CPU 21 has the same monster character as the designated monster character. It is determined whether or not an attribute monster character exists. When there is a monster character having the same attribute, the HPs of both the monster character and the designated monster character are lowered according to the user's attack instruction.

You may make it change the variation | change_quantity of HP according to the familiarity between fellow users. Intimacy may be a numerical value of the level of relationship between fellow users, for example, frequency of sending or receiving messages between users, items that can be used on the game It may be set on the basis of the number of times a present is sent or received. For example, the familiarity may be set higher as the frequency and the number of times are higher. Data describing the intimacy between users (intimacy data) is stored in the user database 31, for example. In calculating the amount of change in HP, the CPU 21 refers to the familiarity data and adjusts the amount of change in HP according to the familiarity between users. For example, when the HP change amount when the familiarity is lower than a predetermined value is set as the reference value, and the closeness is equal to or higher than the predetermined value, the HP change amount is set to the reference value × k (k is 1). Large coefficient).
In the example of FIG. 13, the higher the closeness between the user: ABC and the user: KNM, the more the user: ABC's selection operation of the menu m23 (“attack monster”) by the user: ABC, the support requesting user: KNM ’s battle It is preferable to increase the amount of change in HP of the opponent monster character. Since a battle can be advanced advantageously, so that the closeness between friends is high, the exchange between users can be promoted.

  CPU21 generates the attack with respect to a warrior card from a monster character at random timing. For example, CPU21 accesses the battle data of RAM23 and reads the value of the monster character's attack power. The CPU 21 randomly gives an attack by a monster character to, for example, one of the warrior cards participating in the battle, and when the attack power of the monster character is greater than the defense power of the warrior card to which the attack is given, Judge that the warrior card was killed by the attack. It is preferable to display such that the number of warrior cards of the user decreases on the updated web page as the monster character is defeated by the attack.

When the process corresponding to the selection operation of the menu m23 ends, the CPU 21 generates new HTML data so that the gauge indicating the monster character's HP is updated by the attack based on the operation by the user: ABC, and the user: KNM. , And user: send to the communication terminal 10 of ABC. As a result, the web page shown in step S10 of FIG. 14 is displayed on the communication terminal 10 of the user: KNM and the user: ABC. Comparing step S10 in FIG. 14 with step S7 in FIG. 13, it can be seen that the HP of the monster character that is the battle opponent of both user: KNM and user: ABC has decreased due to the attack by user: ABC (gauge 101g , 201g).
As shown in FIG. 14, in the present embodiment, the user: KNM's battle opponent monster character is displayed on the lower screen on the display screen presented to the user: KNM who requested the support, but the user: ABC battle. The opponent's monster character is not displayed. On the other hand, on the display screen presented to the user: ABC who has accepted the support request, the monster character of the battle partner of the user: KNM is displayed in the upper row, and the monster character of the battle partner of the user: ABC is displayed in the lower row. That is, in this embodiment, only a common monster character (enemy character) based on the support request is displayed on each user's display screen, and other monster characters (that is, their own battle opponent monster characters) are individually Only displayed on the user's display screen. In short, in this embodiment, although cooperation battle is performed between users, a display screen differs between users and a virtual space is not shared between users.

  FIG. 15A is a diagram illustrating an example of a web page displayed on the communication terminal 10 after the battle when the warrior card possessed by the user wins the monster character and succeeds in capturing the land in the target section 301. is there. FIG. 15B is a diagram illustrating an example of a web page displayed on the communication terminal 10 after the battle when the warrior card possessed by the user is defeated by the monster character and fails to capture the land in the target section 301. is there. In the example illustrated in FIG. 15A, a flag image indicating that the land has been successfully captured in the section 301 is displayed in the section 301. On the other hand, in the example shown in FIG. 15B, an image of a monster character that could not be defeated is displayed in the section 301. In FIG. 15B, it may be set so that the battle with the monster character is executed again by selecting the section 301.

In FIG. 13 and FIG. 14, the attributes of the user who accepted the support request: ABC battle opponent monster character and the support request source user: KNM battle opponent monster character are the same (in this case, both monster characters MC1). However, even if the attributes of the two monster characters are different, the user: ABC battle opponent monster character by the selection operation of the user: ABC menu m23 (“attack monster”). And user: Both HPs of KNM's battle opponent monster characters may be changed (decreased). In that case, the amount of change in the HP of the monster character of the user: KNM may be smaller than the case where the attributes match, or may be a value corresponding to the attribute of each monster character.
Alternatively, when the attributes of the monster characters are different, the selection operation of the user: ABC menu m23 ("attack monster") reduces only the HP of the monster character of the user: ABC battle opponent, and the user : You may make it not change HP of the monster character of KNM.

(1-6) Main Process Flow of Game Control Device of This Embodiment Next, an example of the main process flow performed by the game control device of this embodiment will be described with reference to the flowchart of FIG. . FIG. 16 is a flowchart illustrating an example of a battle mode process in the excavation execution process. In FIG. 16, as in FIGS. 11 to 14, an example in which the support request source user is user: KNM (first user) and the support request destination user is user: ABC (second user). Will be described. In the flowchart of FIG. 16, the screen display in steps S4 to S10 corresponds to the display example of the web page in steps S4 to S10 in FIGS.

  First, when shifting to the battle mode in the excavation execution process, the communication terminal 10 of the user: KNM displays an image of the monster character that appears in the battle mode and a web page displaying the level, and selects the menu m11. In response to the operation, a web page including a list for selecting a user as a support request destination is displayed (steps S4 and S5). When one of the users is selected from the list, a support request message specifying the support request destination user (user: ABC) is transmitted from the communication terminal 10 to the game server 20 (step S100). When the game server 20 receives the support request message, the game server 20 generates HTML data including information for identifying the monster character of the user: KNM, and transmits it to the communication terminal 10 of the user: ABC who is the support request destination (step S102). ).

  Upon receiving the HTML data in step S102, the user: ABC communication terminal 10 has a web page including a menu as to whether or not to accept the support request along with information specifying the user who requested the support and the monster character. It is displayed (step S5). Thereby, the information which specifies a monster character is provided with respect to user: ABC. Here, when a selection operation for accepting the support request is performed by the user: ABC, an acceptance message is transmitted from the communication terminal 10 to the game server 20 (step S104). In response to the acceptance message from the user: ABC, the game server 20 sends new HTML data to the support requesting user: KNM communication terminal 10 and the user who accepted the support request: ABC communication terminal 10. Is transmitted (steps S106, S108). As a result, a web page including a monster character as a battle partner is displayed in a predetermined display area on the communication terminal 10 of the user: KNM, and a user is displayed in the predetermined display basin on the communication terminal 10 of the user: ABC. : A web page including a monster character to be a battle partner of KNM is displayed (step S6).

  Thereafter, for example, assuming that a monster character that is a battle opponent for the user: ABC appears, HTML data including information specifying the monster character is transmitted (step S110). In this case, on the web page (step S7) displayed on the communication terminal 10 of the user: ABC based on the HTML data transmitted in step S110, the monster character that is his / her battle opponent is displayed in a predetermined display area. In another display area, a monster character that is a battle partner of the user: KNM is displayed. Here, when an operation of an attack instruction to the monster character by the user: ABC (selection operation of the menu m23) is performed, an attack instruction message is transmitted to the game server 20 from the communication terminal 10 of the user: ABC (step S112). ). In response to the attack instruction message, the game server 20 updates the battle data so as to reduce the HP of the monster characters of both the user: KNM and the user: ABC (step S114), and reflects the new HP value. The generated HTML data is generated and transmitted to the communication terminal 10 of the user: ABC (step S116). Thereby, the gauge which shows HP of a monster character changes on the web page displayed on the communication terminal 10 of user: ABC (step S9). Note that the game server 20 updates the user data based on the attack instruction by the user: ABC so that the attack point of the user: ABC decreases by a certain amount.

  When the process corresponding to the operation of the attack instruction by the user: ABC is completed, the game server 20 generates new HTML data and transmits it to the communication terminal 10 of the user: ABC and the user: KNM (steps S118 and S120). ). In the web page displayed by this HTML data, it can be visually recognized that the HP of the monster character that is the battle partner of both the user: ABC and the user: KNM has decreased (step S10).

As described above, in the battle mode process in the excavation execution process, a certain amount of attack points required to attack only the own monster character are consumed, and not only the own monster character but also other users' It is configured to attack even monster characters. Thereby, each user can obtain a feeling that the game is progressing in cooperation with each other.
In the battle mode process described above, the attack point is consumed by attacking another user's monster character, and the user's own monster character cannot be attacked. Since the attack points are consumed by attacking, it is not possible to attack another user's monster character. Therefore, the user can help other users' battles more positively by attacking the monster characters of other users together with their own monster characters. Therefore, it becomes easy to advance a game in cooperation between users, and it is possible to activate a community between users in the game.

(2) Second Embodiment Hereinafter, a second embodiment will be described. About the structure of the game server 20 and database server 30 of 2nd Embodiment, it can be set as the hardware structure similar to 1st Embodiment.

  In 1st Embodiment, although the case where the monster character used as a battle opponent of a user is one type (refer FIGS. 11-14), ie, the case where a monster character is matched with the single attribute, it demonstrated as an example. Not limited to this. The monster character that is the user's battle opponent may be associated with any of a plurality of attributes. Note that the attributes of a monster character include, for example, a monster character's form and / or color, pattern, the character itself and a numerical value of the ability (level, etc.), and a specific sound (scream, etc.) set for the monster character. Any characteristic that can visually and / or audibly distinguish between monster characters can be included. Hereinafter, in the present embodiment, as illustrated in FIG. 9, at least one of a plurality of monster characters (monster characters MC <b> 1 to 3 in FIG. 9) having different attributes (appearance images in the example of FIG. 9) is a user. The case of becoming a battle opponent will be described.

  In the first embodiment, the HP of all monster characters displayed on the user's web page is reduced by an attack instruction operation (selection operation of the menu m23 in FIG. 13) by the user, but in this embodiment, The user can select and operate a monster character whose HP is reduced by an operation of an attack instruction among the monster characters displayed on the user's web page.

  In this embodiment, the control means 524 has the same attribute as the monster character of the battle partner of the support request source user (first user) and the monster character of the battle partner of the user (second user) who accepted the support request. Is different from the first embodiment in that it has a function of changing the HP (character data) of the monster character of the first user in accordance with the operation of the second user.

  Referring to FIG. 17, the function of the control means 524 of the present embodiment is specifically realized as follows. FIG. 17 is a diagram exemplifying a series of web pages displayed on the communication terminal 10 of a user: ABC who has accepted support requests from a plurality of users, for example. In step S20 of FIG. 17, three monster characters that are their battle opponents are arranged in the sub-areas 101 to 103 of the display area 100, respectively, and two monsters that are battle opponents of the other two users. An example in which characters are arranged and displayed in the sub-areas 201 and 202 of the display area 200 is shown. At the time point when step S20 of FIG. 17 is displayed, information (monster characters MC1, MC3) for specifying the monster character of another user is already provided to the communication terminal 10 of the user: ABC.

  In this case, for example, as shown in step S20 of FIG. 17, a menu m25 in which a text “attack the most monsters” may be provided. This menu m25 is used to give an attack instruction to a monster character having the same attribute as that of any of the monster characters of the user: ABC battle opponent among the monster characters displayed on the web page. It is a menu. When the menu m25 is selected, an attack instruction message is transmitted from the communication terminal 10 to the game server 20. When receiving the attack instruction message, the CPU 21 of the game server 20 has the same attribute as that of one of the monster characters of the user: ABC battle opponent among the monster characters provided to the user: ABC, and is the most. A monster character having the same attribute (three monster characters MC1 in the example of step S21 in FIG. 17) is specified, and a plurality of warrior cards (C2) possessed by the user: ABC are simultaneously specified. HTML data for displaying the attacking state is generated and transmitted to the communication terminal 10 of the user: ABC. As a result, the web page shown in step S21 of FIG. 17 is displayed on the communication terminal 10 of user: ABC. In this web page, a gauge G indicating HP is displayed on each of the three monster characters MC1.

  On the web page shown in step S20 of FIG. 17, the user: ABC does not display the menu m25, and selects a monster character to be attacked by selecting one of the sub-regions. May be. According to this configuration, the user can select a monster character to be attacked while considering which monster character can support other users by attacking.

  The battle between the plurality of warrior cards and the monster character may be the same method as the method described in the first embodiment. When recognizing that the menu m25 has been selected, the CPU 21 performs a process of reducing all the HP values of the three monster characters MC1 by consuming one attack point according to the attack power of the warrior card. The CPU 21 writes the HP value of the reduced monster character in the battle data in the RAM 23, determines the scale amount of the gauge G according to the value after the decrease, generates HTML data, and communicates with the user: ABC. Transmit to the terminal 10. As a result, as shown in step S22 of FIG. 17, a web page indicating that the HP of all three monster characters has decreased is displayed on the communication terminal 10 of user: ABC.

When the processing corresponding to the selection operation of the menu m25 is completed, the CPU 21 generates new HTML data for the related user so that the gauge indicating the monster character's HP is updated by the attack based on the operation by the user: ABC. Then send. For example, when the monster character MC1 displayed in the sub area 201 of the display area 200 of FIG. 17 is based on a support request from the user: KNM, the gauge indicating the HP of the monster character MC1 is updated. In addition, new HTML data is generated and transmitted to the user: ABC and the user: KNM. As a result, the web page shown in step S23 of FIG. 18 is displayed on the communication terminal 10 of the user: KNM and the user: ABC. Comparing step S20 in FIG. 17 with step S23 in FIG. 18, it can be seen that the HP of the monster character MC1, which is a battle opponent of both the user: ABC and the user: KNM, is reduced by the attack by the user: ABC (user: (See gauge 101g displayed to KNM, user: 102g, 103g, 201g displayed to ABC).
As shown in FIG. 18, in the present embodiment, the user: KNM's battle opponent's monster character is displayed on the lower screen on the display screen presented to the user: KNM who requested the support, but the user: ABC's battle. The opponent's monster character is not displayed. On the other hand, on the display screen presented to the user: ABC who has accepted the support request, the monster character of the user: KNM's battle partner and the user: the monster character of the battle partner of the user who requested the support by a user other than KNM. The monster character of the battle partner of the user: ABC is displayed in the lower row. That is, in this embodiment, only a common monster character (enemy character) based on the support request is displayed on each user's display screen, and other monster characters (that is, their own battle opponent monster characters) are individually Only displayed on the user's display screen. In short, in this embodiment, although cooperation battle is performed between users, a display screen differs between users and a virtual space is not shared between users.

In the present embodiment, when a plurality of monster characters having different attributes appear on the game, the monster character of the supporting user and the monster character of the requesting support user are the same according to the attack instruction from the supporting user. Attack is added to the attribute monster character. Therefore, according to the present embodiment, when a plurality of monster characters having different attributes appear on the game, the user attacks the monster character having the highest attack effect including the monster characters of other users. Will be added.
Further, in the present embodiment, even when a plurality of monster characters having different attributes are set on the game, the user who has accepted the support request is the progress of the game of the support request source among his monster characters. The game can be advanced while recognizing the characters that can affect the game. That is, since it becomes a structure which makes a user judge about which monster character can support another user by attacking, the interest property of a game increases.

(3) Modified Examples Hereinafter, modified examples of the above-described embodiments will be described.

(3-1) Modification 1
When the information specifying the monster characters of the plurality of users is provided to the user (second user) who has received support requests from a plurality of users, the control means 524 receives the support request. A function of selecting any monster character based on the selection operation by may be provided. That is, when a plurality of support requests from other users are received, it is preferable that the user can select which monster character to select from among the monster characters provided by the support request. In that case, since the user who received the support request can select, for example, a monster character having the same attribute as the monster character that is his / her battle partner, it is easy to support other users.

  The function of the control means 524 described above can be realized as follows. When the CPU 21 of the game server 20 receives a plurality of support request messages addressed to a specific user within a certain period of time, for example, the user of the support request source specified by the plurality of support request messages and the battle partner of the user HTML data for displaying information specifying the monster character in a list format is generated and transmitted to the communication terminal 10 of the user of the support request destination. As a result, for example, the web page shown in FIG. 19 is displayed on the communication terminal 10 of the user of the support request destination. When any user or monster character is selected by the support requesting user on this web page, the CPU 21 selects the user to be supported based on the selection result (the user to whom the support request is accepted) ).

(3-2) Modification 2
In FIG. 11, the user: KNM is configured to recognize the attribute of the monster character that is its battle opponent after selecting one of the users from the list for selecting the support request destination user (step S <b> 5). (Step S6). Steps S5 and S6 may be reversed. That is, the configuration may be such that the user selects the user of the support request destination after confirming the attribute of the monster character that is the battle opponent of the user first. In that case, since the user already knows the monster character of his / her battle opponent, it is preferable that the user of the support request destination can be selected accordingly.

  Further, in the second modification, the control means 524 provides information for identifying the monster characters of a plurality of users to the first user when a support request is made from the user (first user) who is the support request source. Then, based on the selection operation by the first user, one of the monster characters may be selected, and a user who uses the monster character as a battle partner may be determined as the support request destination user. For example, after the web page in step S6 of FIG. 11 is displayed, the web page shown in FIG. 20 is displayed on the communication terminal 10 of the user: KNM. This web page includes a list of information for identifying a plurality of users who are candidates for support requests and the monster characters of each user's battle opponent. Since the user who viewed this web page: KNM knows his / her battle opponent's monster character (monster character MC1 in step S6), the monster character having the same attribute as that monster character is selected from the list of FIG. Motivated to choose. By selecting a monster character with the same attribute, it will not be a burden on the user who supports it (that is, his attack points will not be consumed only by attacking other users' monster characters) This is because the received user is highly likely to accept the support request.

  The function of the control means 524 described above can be realized as follows. For example, when the menu m11 is selected on the web page in step S4 of FIG. 11, the CPU 21 of the game server 20 updates the display so that the web page shown in step S6 is displayed. On the web page in step S6, for example, it is preferable to display a menu m10 for selecting a single user to fight and a menu m11 for requesting a battle support for a fellow user ( Not shown). When recognizing that the menu m11 has been selected, the CPU 21 updates the display so that the web page in step S5 of FIG. 20 is displayed. At this time, it is preferable that the user in the list displayed in FIG. 20 is a user who belongs to the user: KNM. The CPU 21 refers to the battle data in the RAM 23 when creating the list of fellow users, and acquires information for identifying the monster character of the fellow user's battle opponent.

(3-3) Modification 3
In step S5 of FIG. 11, the user: KNM selects the support request destination user. However, the present invention is not limited to this. The providing unit 523 determines whether to accept the support request among a plurality of users (a plurality of users associated with the first user) of the first user (the user who requested the support) (that is, Inquiries about whether or not you wish to provide information that identifies the first user's monster character), requesting support for the user who first responded to accept (that is, to provide that information) You may specify as a previous user (2nd user). Thereby, it is possible to satisfy the desire of the user who has accepted the support request to help the fellow quickly.
In this case, when the CPU 21 of the game server 20 recognizes the selection operation of the menu m11 in the web page in step S4 in FIG. 11, the CPU 21 refers to the user data of the user: KNM without shifting to the web page in step S5. , User: A support request message is transmitted to all the communication terminals 10 of KNM. In each fellow communication terminal 10, as shown in step S5 of FIG. 11, a web page including menus m20 and m21 for selecting whether or not to accept the support request is displayed. Thereafter, the CPU 21 specifies the user who first performed the selection operation of the menu m20 in response to the support request message (that is, the user of the communication terminal 10 that first transmitted the acceptance message), and designates the user as the support request destination user. And

(3-4) Modification 4
In the second embodiment described above, as shown in FIGS. 17 and 18, when a plurality of monster characters having different attributes appear on the game, the user who has accepted the support request: in accordance with the operation of ABC Although the case where the HP of only the monster character MC1 having the same attribute is lowered with the support requesting user: KNM has been shown, the present invention is not limited thereto. You may enable it to set variously the monster character of HP reduction object. For example, you may reduce HP of all the monster characters regardless of an attribute according to operation of user: ABC. In that case, the user who accepted the support request: the ABC battle partner and the support request source user: the KNM battle partner have the same attribute of the HP change amount of the monster character (MC1 in FIG. You may make it larger than that of a monster character (MC2, MC3 of FIG. 17).

  In each of the above-described embodiments and modifications, the case where the support request source user and the support request destination user are friends (associated users) is described. Absent. The user can also support other users who are not friends. However, the community between friends can be activated by limiting the support request destination to friends.

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, in the above description, the case where there is one user who performs support (in the description of the above embodiment, user: ABC) is described, but the present invention is not limited thereto. A plurality of users who perform support may be configured. In that case, it is preferable to increase the maximum number of monster characters of other users (for example, three in FIG. 11) that can be displayed on the web page according to the number of users who provide support.
In the above-described embodiment, the case where the attributes of the monster character are visually different has been described. However, as described above, the attribute of the monster character may be aurally different. In that case, for example, when a monster character displayed on the communication terminal 10 is selected and operated, a cry of the monster character is output. Then, an attack may be applied to the monster character that outputs the same cry between the monster character of the user who performs the support and the monster character of the user who requests the support, according to an attack instruction from the user who performs the support.
Although embodiment mentioned above demonstrated as an example the case where a user's battle other party is a monster character in the battle mode of excavation execution processing, it is not restricted to this. For example, the user's battle partner may be a warrior card of another user other than the user's friends.
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 to this. 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 game server 20 and the database server 30 on the network are configured to realize the functions of the respective units illustrated in FIG. 7, but the configuration is not limited thereto. 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 can have substantially the same hardware configuration, each function can be realized by the communication terminal 10 as described in the above embodiment. In that case, in the above-described embodiment, at least one of the user database, monster character data, and battle data is stored in the storage device (RAM 13 or HDD (Hard Disk Drive) not shown) in the communication terminal 10 of each user. Large-capacity storage device) or another storage device on a network, for example.

Claims (11)

A game control device that controls the progress of a game by each user according to each operation of a plurality of users,
Storage means for storing a character on the game and character data as character data in association with each other;
For each user, control means for changing the character data according to the user's operation;
Providing means for providing information identifying a character of a first user among the plurality of users to a second user different from the first user;
With
When the information for specifying the first user's character is provided to the second user, the control means is configured to send the character data of the second user's character according to the operation of the second user. At the same time, the character data of the first user character is changed,
Game control device. In the display screen presented to the second user, the character data of each of the first user character and the second user character is displayed.
The game control apparatus according to claim 1. Each user's character is associated with an attribute,
When the first user character and the second user character have the same attribute, the control means obtains the character data of the first user character according to the operation of the second user. Characterized by changing,
The game control device according to claim 1 or 2. The control means selects one of the characters based on a selection operation by the second user when information specifying a plurality of user characters is provided to the second user.
In accordance with the operation of the second user, the character data of the selected character is changed together with the character data of the character of the second user.
The game control device according to claim 1. Second storage means for storing associations between the plurality of users;
The providing means specifies a user associated with the first user as the second user,
The game control apparatus as described in any one of Claims 1-4. Second storage means for storing associations between the plurality of users;
The providing means inquires about whether or not to provide information for specifying the character of the first user among a plurality of users associated with the first user, and provides the information. The user who first answered what he wants is specified as the second user,
The game control apparatus as described in any one of Claims 1-4. A game control device that controls the progress of a game by each user according to each operation of a plurality of users,
Storage means for storing the enemy character of the user on the game and character data that is data of the enemy character in association with each other;
For each user, control means for changing the character data according to the user's operation;
Providing means for providing information for identifying an enemy character of the first user among the plurality of users to a second user different from the first user;
With
When the information for specifying the enemy character of the first user is provided to the second user, the control means, in response to the operation of the second user, the character of the enemy character of the second user Simultaneously with the data, the character data of the enemy character of the first user is changed.
Game control device. A game control method for controlling the progress of a game by each user according to each operation of a plurality of users,
Storing a character on the game and character data that is character data in a storage device in association with each other;
For each user, changing the character data according to the user's operation;
Providing information for identifying a character of the first user among the plurality of users to a second user different from the first user;
Including
In the step of changing, when information specifying the first user's character is provided to the second user, the character data of the second user's character according to the operation of the second user. At the same time, the character data of the first user character is changed,
Game control method. In order to control the progress of the game by each user according to the operation of each of the plurality of users,
A function for storing a character on the game and character data that is character data in a storage device in association with each other;
For each user, a function for changing character data in accordance with a user operation,
A function of providing information for identifying a character of a first user among the plurality of users to a second user different from the first user;
Is a program for realizing
When the information for specifying the character of the first user is provided to the second user, the function to be changed is character data of the character of the second user according to the operation of the second user. At the same time, the character data of the first user character is changed,
program.   A computer-readable recording medium on which the program according to claim 8 is recorded. A game system comprising: a communication terminal operated by a user; and a game control device that is connected to the communication terminal via a network and controls the progress of a game by each user according to each user's operation. ,
Storage means for storing a character on the game and character data that is character data in association with each other;
For each user, control means for changing the character data according to the user's operation, and
Providing means for providing information identifying a character of a first user among the plurality of users to a second user different from the first user;
Each means is provided in either one of the communication terminal or the server,
When the information for specifying the first user's character is provided to the second user, the control means is configured to send the character data of the second user's character according to the operation of the second user. At the same time, the character data of the first user character is changed,
Game system.

Images