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

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, in a social networking service (SNS) by a specific service provider, a so-called social game executed by a game application has become widespread. 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. As an example of such a social game, a digital card game (Dragon Collection (registered trademark)) described in Non-Patent Document 1 below is known.

Application STYLE Vol.5 (East Press, issued on November 1, 2011), pages 7-8

  By the way, in the conventional game, a point is given to the user who executed the game, and an item is given in exchange for the point held by the user. In other words, the user performs an act of acquiring an item as an acquisition price. When the user does not have a point corresponding to the item acquisition consideration, the user cannot obtain the item, and thus the user is given a motivation to increase the point to be held by executing the game.

  However, if the opportunity to obtain the item is limited, if the user loses the opportunity to obtain the item, the user is not motivated to run the game.

  The present invention has been made in view of the above-described viewpoint. For example, even when a user who has been given an opportunity to obtain an item does not have enough points, the user can be motivated to execute the game. It is an object to provide a game control device, a game control method, a program, a game system, and an online system.

A first aspect of the present invention is a game control device.
This game control device
A selection means (52) for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A determination means (53) for determining whether or not the user can acquire the object by comparing the acquisition price of the selected object with a point held by the user on the game;
Granting means (54) for granting the object to the user in exchange for a point corresponding to the acquisition consideration when it is determined that the user can obtain the object;
Registration means (55) for registering the object as an object to be obtained by the user when the user determines that the object cannot be obtained;
Each means is provided.

The game control device according to the present invention may be a stand-alone game machine used by a user alone, or wirelessly or wiredly with the communication terminal in order to display a game on the user's communication terminal. It may be an information processing apparatus such as a server that can establish communication.
In the present invention, the “object” includes, for example, characters and items on the game. The character is, for example, a virtual person or creature on the game, a monster, or the like, and includes characters displayed on a card.
In the present invention, the “point” is a price for obtaining an object on the game. For example, the points may be given to the user when the user executes the game. Alternatively, the point may be a virtual currency that the user can use on the game.
According to this game control apparatus, even when the user who has been given an opportunity to obtain the object does not have enough points, the user can register the object as the acquisition desired object. The user can be motivated to run the game to obtain

In the game control device, the grant means (54) exchanges the points corresponding to the acquisition consideration when the user determines that the acquisition desired object is available after the acquisition desired object is registered. The acquisition desired object may be given to the user.
According to this game control device, even when a user who has been given an opportunity to obtain an object does not have enough points, the user can obtain the desired object after becoming a state having sufficient points. Therefore, the user can be motivated to execute the game in order to increase points.

The game control apparatus may further include a release unit (56) for canceling registration of the desired acquisition object after a predetermined period has elapsed since the acquisition desired object has been registered.
According to this game control device, the registration of the desired object to be acquired is canceled after the lapse of a predetermined period, so that the user can be motivated to execute the game before the registration is canceled.

In the game control device, the predetermined period may be a time of a length corresponding to the acquisition price of the acquisition-desired object.
The higher the acquisition price of the desired acquisition object, the longer the game execution time required for the user to acquire the desired acquisition object. For this reason, the length of the registration period is set to an appropriate value by changing the length of the period during which the acquisition object can be registered according to the acquisition price of the acquisition object (hereinafter referred to as the registration period). be able to. For example, it can be avoided that the user gives up the acquisition of the object to be acquired because the registration period is too short for the acquisition price.

The game control apparatus may further include an extension means (58) for extending the predetermined period when the difference between the acquisition price of the acquisition-desired object and the user's possession points decreases.
According to this game control device, by increasing the points that the user executes and holds the game, the difference between the acquisition price of the object desired to be acquired and the points held by the user is reduced, and the registration period is extended. The user can be motivated to run the game to avoid being deregistered and losing the opportunity to obtain items.

The game control apparatus may further include an acquisition price changing means (59) for changing an acquisition price of the acquisition-desired object according to a time from when the acquisition-desired object is registered.
According to this game control device, the acquisition price of the desired acquisition object varies depending on the time from the time of registration, and therefore the motive for executing the game for the purpose of acquiring the acquisition desired object at a time when the acquisition price is lower Can be given to the user. For example, in the case where the acquisition consideration is increased according to the time from the time of registration, the user can be given a motivation to execute the game in order to acquire the acquisition desired object at an earlier time.
Also, when the registration is canceled and the points are paid back to the user, the points corresponding to the acquisition price reduced according to the time from the time of registration can be paid back in consideration of interest.

In the game control device, the game control device further includes point giving means (60) for giving points to the user in accordance with the execution of the game, and when the desired object to be obtained is registered, the point giving means (60) You may change the point given to a user according to execution.
According to this game control device, when an acquisition-desired object is registered, the game execution time required by the user to acquire the acquisition-desired object by changing the points given to the user according to the execution of the game Can be varied. For example, by increasing the number of points given to the user when the desired acquisition object is not registered, the game execution time required for the user to acquire the desired acquisition object is shortened. For this reason, even if the user does not have enough points, the user can be motivated to actively register the desired acquisition object and execute the game.
On the other hand, in consideration of interest, the number of points given to the user when the desired object is registered is less than when the desired object is not registered. Execution time can be extended.

The said game control apparatus WHEREIN: You may provide the 1st restriction | limiting means (61) which restrict | limits the opportunity for the said user to acquire another object, when the said acquisition-desired object is registered.
According to this game control device, when an acquisition-desired object is registered, it is possible to prevent the user from registering an object unplanned by not giving the user an opportunity to acquire another object.

The game control apparatus further includes second restriction means (62) for restricting use of points for obtaining other objects by the user until it is determined that the user can obtain the desired object. Also good.
According to this game control device, another object cannot be obtained using points until it is determined that the user can obtain the desired object. Therefore, in order to allow the user to obtain other objects other than the desired acquisition object, the user can be motivated to execute the game so that points corresponding to the acquisition price of the registered desired acquisition object can be obtained quickly.

The game control apparatus may further include an accepting unit (57) for accepting cancellation of registration of the desired acquisition object from the user.
According to this game control device, for example, when the user does not desire after registration, the user cancels the registration of the acquisition desired object, thereby restricting the user when the acquisition desired object is registered (for example, Other objects cannot be obtained, point usage restrictions, etc.) can be released.

A second aspect of the present invention is a game control device.
This game control device
A selection means (52) for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A determination means (53) for determining whether or not the user can acquire the object by comparing the acquisition price of the selected object with a point held by the user on the game;
Granting means (54) for granting the object to the user in exchange for a point corresponding to the acquisition consideration when it is determined that the user can obtain the object;
Registration means (55) for registering the object as an object to be obtained by the user when the user determines that the object cannot be obtained;
Release means (56) for canceling registration of the desired acquisition object after a predetermined period of time since the acquisition desired object has been registered;
First restriction means (60) for restricting an opportunity for the user to obtain another object when the object to be obtained is registered;
A game control device. Each means is provided.

A third aspect of the present invention is a game control method.
The game control method includes a step of accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
Comparing the acquisition price of the selected object with the points the user has on the game to determine whether the user can acquire the object;
When it is determined that the user can obtain the object, the object is given to the user in exchange for a point corresponding to the acquisition consideration;
Registering the object as an object to be obtained by the user when the user determines that the object cannot be obtained;
including.

A fourth aspect of the present invention relates to a computer.
A function for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A function of comparing the acquisition price of the selected object with the points that the user holds in the game and determining whether or not the user can acquire the object;
A function of giving the object to the user in exchange for a point corresponding to the acquisition consideration when the user is determined to be able to obtain the object;
A function of registering the object as an object desired to be obtained by the user when the user determines that the object cannot be obtained;
It is a program for realizing.

  The computer may be a network server, a large computer, or the like, for example. The program may be stored in a computer-readable information storage medium such as an optical disk (DVD-ROM, CD-ROM, etc.), a flexible disk, or a semiconductor memory.

A fifth aspect of the present invention is a game system including a plurality of user communication terminals (10) and a server (20) accessed from the communication terminals (10).
This game system
A selection means (52) for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A determination means (53) for determining whether or not the user can acquire the object by comparing the acquisition price of the selected object with a point held by the user on the game;
Granting means (54) for granting the object to the user in exchange for a point corresponding to the acquisition consideration when it is determined that the user can obtain the object;
Registration means (55) for registering the object as an object to be obtained by the user when the user determines that the object cannot be obtained;
Either one of the communication terminal (10) and the server (20) includes these means.

  In the above, in order to facilitate the understanding of the present invention, the reference numerals shown in the drawings are appropriately described in parentheses, but this restricts the game control device and the like according to the present invention to the illustrated embodiment. It is not a thing.

  According to the game control device, the game control method, the program, and the game system of the present invention, even when the user who is given the opportunity to obtain the item does not have enough points, the user is motivated to execute the game. be able to.

The figure which shows the basic composition of the game system of embodiment. The figure which shows the example of the external appearance of a communication terminal. The block diagram which shows the structure of a communication terminal. The block diagram which shows the structure of a game server. The block diagram which shows the structure of a database server. The figure which shows the structural example of a user database. The figure which shows the structural example of a monster card database. The figure which shows the structural example of a registration table. The figure which illustrates a series of web pages displayed on a user's communication terminal. The figure which illustrates a series of web pages displayed on a user's communication terminal. The figure which illustrates a series of web pages displayed on a user's communication terminal. The figure which illustrates a series of web pages displayed on a user's communication terminal. The figure which illustrates the web page displayed on a user's communication terminal. The figure which illustrates a series of web pages displayed on a user's communication terminal. The figure which illustrates a series of web pages displayed on a user's communication terminal. The functional block diagram for demonstrating the function to play main roles with the game control apparatus of embodiment. The flowchart which shows an example of the main processes of the game control apparatus of embodiment. The flowchart which shows an example of the main processes of the game control apparatus of embodiment. The flowchart which shows an example of the main processes of the game control apparatus of embodiment. The functional block diagram for demonstrating the function which plays a main role with the game control apparatus of the modification 1. FIG. The flowchart which shows an example of the main processes of the game control apparatus of the modification 1. The functional block diagram for demonstrating the function which plays a main role with the game control apparatus of the modification 2. FIG. The flowchart which shows an example of the main processes of the game control apparatus of the modification 2. The functional block diagram for demonstrating the function which plays a main role with the game control apparatus of the modification 3. FIG. The flowchart which shows an example of the main processes of the game control apparatus of the modification 3. The flowchart which shows an example of the main processes of the game control apparatus of the modification 3. The functional block diagram for demonstrating the function which plays a main role with the game control apparatus of the modification 4. FIG. The flowchart which shows an example of the main processes of the game control apparatus of the modification 4. The functional block diagram for demonstrating the function which plays a main role with the game control apparatus of the modification 5. FIG. The flowchart which shows an example of the main processes of the game control apparatus of the modification 5. The figure which shows the sharing example between a communication terminal, a game server, and a database server about each function of a game control apparatus.

  Hereinafter, an embodiment of the game system of the present invention will be described.

(1) Configuration of Game System FIG. 1 shows a system configuration example of a game system according to the embodiment. As shown in FIG. 1, the game system includes communication terminals 10a, 10b, 10c,... That can be connected to a communication network NW (network) such as the Internet, a game server 20 connected to the communication network NW, The database server 30 is configured. Each of the communication terminals 10a, 10b, 10c,... Is a terminal operated by an individual user, for example, a mobile terminal, a smartphone, a PDA (Personal Digital Assistant), a personal computer, a television having a bidirectional communication function. A communication terminal such as a John receiver (including a so-called multi-function smart TV). In the following description, when referring to the communication terminals 10a, 10b, 10c,.
In this game system, the game server 20 is configured to be able to communicate with the communication terminal 10 that is a client, and provides a gaming service to the communication terminal 10. The game server 20 is mounted with an application operable on a web browser as a game application. The database server 30 stores various information to be described later in executing the game, and is connected to the game server 20 in a wired or wireless manner for reading and writing the information. Note that the game server 20 and the database server 30 may be connected via a communication network NW.
The communication terminal 10 includes a web browser capable of displaying a web page provided by the game server 20, and the user executes a game by performing an operation on the web page on the communication terminal 10.

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

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

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

  The web browser performs communication with the game server 20 in accordance with HTTP (HyperText Transfer Protocol). The web browser interprets the HTML data acquired from the game server 20 and displays the web page on the display unit 16 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 sends an HTTP request according to the selection result to the game for updating the web page. Send to server 20.

  The image processing unit 14 displays a web page on the display unit 16 based on display image data given 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 (shown in FIG. 2A), the instruction input unit 15 includes 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 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 to select one hyperlink or menu that is active (for example, highlighted) when a plurality of hyperlinks or menus are displayed on a web page, for example. 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 a plurality of instruction inputs in which “0” to “9”, “*”, and “#” (numeric keys) are written. Includes buttons.

  When the communication terminal 10 is a touch panel input type communication terminal (shown in FIG. 2B), the instruction input unit 15 accepts touch panel type input mainly 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 shown 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 mobile terminal, the menu on the web page displayed on the communication terminal 10 is selected by pressing the direction instruction button and selected by pressing the enter button. This is done by confirming the menu. For example, when the communication terminal 10 is a touch panel input method, the menu is selected by instructing (touching) the position of the menu on the display screen 16a on which the web page is displayed with a finger or a pen. .

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

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

For example, the CPU 21 performs communication according to HTTP with the web browser of the game server 20 via the communication interface unit 25. For example, the CPU 21 performs predetermined data processing or the like based on an HTTP request received from the communication terminal 10 via the communication interface unit 25 (for example, including a user hyperlink or menu selection result on a web page). The arithmetic processing is performed, and an HTTP response including the processing result is returned to the web browser of the game server 20. The HTTP response includes HTML data for updating the web page. When the game server 20 performs an authentication process for the user of the communication terminal 10, the CPU 21 performs the authentication process.
The database access unit 24 is an interface when the CPU 21 reads / writes data from / to the database server 30.

(4) Configuration of Database Server The database server 30 (storage device) can be realized by a general-purpose storage such as a large-capacity hard disk device or a device in the form of RAID (Redundant Arrays 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 (user DB) 31 and a game database (game DB) 32.

The type of game of the present embodiment is not particularly limited, but in the following, as an example of the game of the embodiment, a digital card game using a monster card (hereinafter simply referred to as “card” as appropriate) (hereinafter referred to as appropriate). Simply called “game” or “game of this embodiment”). This game is configured so that a user can create a team (card deck) by obtaining a digital card (monster card) on which a monster is drawn and battle with a computer or a team of other users. . A card deck is generally composed of a plurality of cards.
This game includes the following processes, for example.
・ Quest processing:
This is a process of obtaining a monster card by searching for an area set in the game in order to create a team of at least one monster card. In this game, a certain amount of physical strength points (described later) are consumed by executing the quest process.
・ Battle processing:
This is a process of performing a battle between a team of users and a team of computers or other users. Here, the computer team is a team composed of a plurality of monster cards arbitrarily extracted by the CPU 21, for example. In the battle process, based on the user's input, an event (hereinafter referred to as COM battle) between the user team and the computer team, or a battle between the user team and another user's team. One of the events to be performed (hereinafter referred to as a battle between users) occurs.
Purchase process A process for giving a user an opportunity to obtain a card and giving the card that the user wants to obtain in exchange for a point (purchase point to be described later) that the user holds on the game. If the purchase points owned by the user are less than the points necessary for purchasing the card (hereinafter referred to as acquisition consideration), the card is registered for a predetermined period, and insufficient points for the acquisition consideration for the purchase points of the registered user Manage (negative values). When the user runs the game and obtains purchase points and the shortage point reaches 0, a registered card (registered card) is given to the user. In addition, although the case where the user is given an opportunity to obtain a card will be described below, the user may be given an opportunity to obtain an item instead of the card.

  Although not described in detail here, the game of the present embodiment includes, for example, a monster card that the user holds in the game, a monster card included in the user's team, and other monster cards (that is, the user's team). A knitting process for executing replacement with a monster card which is not included in the above may be included.

  FIG. 6 shows an example of the user database 31 applied in the game of the present embodiment. In this example, the user database 31 has, for each user ID (user identification information), a user name / display image, progress level, physical strength point, purchase point, fellow user ID, possession card, and item identification code. Contains information. Information included in the user database 31 can be updated sequentially by the game server 20.

In the following description, data for each user ID included in the user database 31 is collectively referred to as user data. The data of each item constituting the user data is as follows.
User name / display image A user name and a display image that are displayed to identify the user of the communication terminal 10 when the game is executed. The user name is text of a predetermined length or less that is designated in advance by the user, and the display image is, for example, an avatar image that is selected in advance by the user. The user name is a name that identifies the user on the network environment (or game community) provided by the game server 20.
Progress level data indicating the progress 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). For example, the quest process is continuously executed, and the progress level is sequentially increased.
-Physical strength point Physical strength point is a parameter which shows the cost consumed when a user performs a quest process, and a physical strength point decreases when a user performs a quest process. The upper limit value of the physical fitness point may be determined for each user, and the upper limit value of the physical fitness point may be set to increase as the progress level increases. You may set a physical strength point so that it may increase (recover) to an upper limit with progress of time.
Purchase points Points that the user has acquired from the system or other users in the quest process or the battle process. In this game, cards and items on the game are given to the user in exchange for the purchase point of the user. Note that purchase points may be given to the user by the system in exchange for a fixed amount of charge.
・ Friend's user ID
For example, it is a list of user IDs of other users (companies) associated with the user, triggered by an application for becoming a friend.
-Owned card, item identification code This is an identification code for a monster card or item (such as a recovery item that recovers health points) that the user holds in the game. The contents of data such as a monster card corresponding to the identification code will be described later.

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 the game of the present embodiment as an example, the information related to the progress of the game includes, for example, information about the battle result (for example, win / loss).
In addition, the game database 32 stores a monster card database and a registration table in relation to the various processes described above.

The monster card database is a database in which information of all monster cards prepared in the game of the present embodiment is described.
FIG. 7 is a diagram illustrating an example of a data configuration of a monster card database. The monster card database illustrated in FIG. 7 includes, for each monster card identification code (in the example shown, MC001, MC002,...), The image data (image) of the target monster card, the name of the target monster (monster Name), parameters of the target monster card (in the example of the figure, attack power, defense power and rareness indicating the ability of the monster), and data on each item of the acquisition price of the monster card. For example, it may be set to indicate that as the parameters such as attack power and defense power are larger, the ability of the monster corresponding to the monster card is higher in the battle processing.
The rare degree is a value indicating the degree of the rare value of the monster card. For example, the higher the value (that is, the higher the rare value), the lower the probability of appearing in the game may be set. For example, when the rare degree is expressed in five stages of 1 to 5, the rare degree of a monster card corresponding to a monster with outstanding abilities or a popular monster may be set high (for example, 4 or 5).

  FIG. 8 is a diagram illustrating an example of a data configuration of a registration table used for purchase processing. In the registration table illustrated in FIG. 8, the user ID of the user who registered the card, the identification code of the registration card, the registration time, and the registration expiration date are associated with each registration code. The registration table gives the user an opportunity to obtain a card in the purchase process, and when the user registers the card, the user ID of the registered user, the identification code of the registered card, the registration time (registration time), The registration expiration date (registration expiration date) is recorded. For example, the registration expiration date may be a time after a predetermined time has elapsed from the registration time.

(5) Game of this embodiment Hereinafter, the game of this embodiment is demonstrated, referring FIGS. 9-15.
In the following description, menus, marks and the like displayed on the web page displayed on the communication terminal 10 are arranged at desired positions on the web page, and are menus visually recognized on the communication terminal 10. The position on the display screen of the mark and the like can be changed by scrolling the web page by the user's direction instruction button or touch panel operation.

The top page P1 of FIG. 9 includes a monster image display area 101, a user data display area 102, and a menu display area 103. Although the top page P1 is configured for each user to be processed, the top page P1 in FIG. 11 is a case where the user to be processed is a user “A” (hereinafter referred to as “user: A”). It is an example.
The monster image display area 101 is an area in which an image of a card designated in advance by the user among a plurality of cards corresponding to the identification code recorded in the user database of the user to be processed is displayed. The user data display area 102 is an area in which data (see FIG. 6) of items such as progress levels and physical fitness points recorded in the user database of the user to be processed is displayed. The menu display area 103 includes a menu m1 (“quest”) and a menu m2 (“match”) respectively corresponding to event processing (quest processing, battle processing) provided in the game of the present embodiment. The menu display area 103 may include a menu corresponding to the knitting process described above.
When the menu m1 or menu m2 is selected on the top page P1, the execution of the game is started.

[Quest processing]
First, an example of a quest process will be described. When the user: A selects the menu m1 on the top page P1 in FIG. 9, the quest process is started, and the web page is updated as shown in P2. The web page P2 includes an achievement rate gauge indicating the degree of progress of an area to be searched, a menu m10 written as “quest execution” for executing search processing for the area to be searched, and 1 The value of physical strength points required for one search, the experience value obtained by one search, and the like are included.
User: Every time A selects menu m10, the achievement rate increases in accordance with a predetermined condition or with a random increase amount. When the achievement rate reaches 100%, the area search is completed and the process can proceed to the next area. Each time the menu m10 is selected, the user: A's health points are consumed by a predetermined amount (8 in the example of FIG. 9). A plurality of search target areas may be provided.
When the menu m10 is repeatedly selected on the web page P2, the health point decreases as described above. However, when the health point is less than the health point required for one search (for example, 8), further search is performed. Cannot execute. In that case, in order for the user to be able to execute the search again, it is necessary to wait until the physical fitness point recovers (increases) over time.
In the quest process, every time the menu m10 is selected, the user can obtain objects such as cards or items, purchase points, experience points, etc. prepared on the game with a predetermined or random probability. It is configured as follows. When the user obtains the card when the menu m10 is selected, for example, as shown in P3, the web page including the information on the obtained card is updated. Alternatively, when the user obtains a purchase point when the menu m10 is selected, for example, as shown in P4, the user: A user after adding the purchase point newly acquired by the user A and the newly acquired purchase point : Updated to a web page containing information on purchase points held by A.
In the quest process, each time the menu m10 is selected, an opportunity to shift to another event on the game is given with a predetermined or random probability. For example, each time the menu m10 is selected, it may be updated to a web page for shifting to a battle process described later with a predetermined or random probability, or a web page for shifting to a purchase process described later (For example, P7 in FIG. 11) may be updated. In the following description, a case will be described in which the process proceeds to purchase processing as another event.

(Competition processing)
Next, an example of a battle process will be described. When the menu m2 is selected on the top page P1 in FIG. 10, the battle process is started, and the web page is updated as shown in P5. The web page P5 includes an image of the opponent: E, and a menu m20 labeled “start battle” for instructing execution of the battle. When the user: A selects the menu m20 (“start of battle”) on the web page P5, a battle is performed between the user: A team and the opponent: E team.
Note that, as in this embodiment, the CPU 21 may determine a predetermined condition or a random opponent, or display a list of predetermined conditions or a plurality of randomly selected opponents, and the user May be able to select an opponent from among them. The opponent may be a computer (COM battle) or another user (inter-user battle). The other user may be a friend associated with the user A, or may be a user not associated with the user.

  The battle process is performed based on, for example, card information of the attacking team and card information of the defending team. For example, by comparing the total attack power of the attacking team's cards with the total defense power of the defending team's cards and determining that the side with the larger number wins and the side with the smaller side loses, the battle process It can be performed. The battle process is not limited to the comparison of the sum of the parameters such as attack power and defense power, but the attack power and defense power of the cards set in the team are changed according to a predetermined calculation formula and compared to win or lose. It may be determined, or the winning / losing may be determined by performing a lottery process after changing the probability of winning according to the numerical value of the parameter.

  When the battle is over, a web page (web page exemplified in P6) notifying the result of the battle is displayed on the communication terminal 10 of the user: A. The web page P6 shows an example of a web page displayed on the display unit 16 of the communication terminal 10 when the user: A wins the battle. In this game, when the user: A wins the opponent: E, a predetermined amount of purchase points (1000 in the example of FIG. 10) is given to the user: A as a privilege.

[Purchase processing]
Next, an example of purchase processing will be described. In the quest process, whenever the user: A selects the menu m10, the web page is updated with a predetermined or random probability, for example, as shown at P7 in FIG. . The web page P7 includes a menu m11 described as “stop” for shifting to the purchase process in addition to the menu m10 described as “execution of quest” for executing a normal search process.
When the user selects the menu m11 on the web page P7, the purchase process is started, and the web page is updated, for example, as shown at P8 in FIG. The web page P8 includes information on cards that are given to the user: A an opportunity to obtain, and menus m12, m13 labeled “obtain” for the user: A to select each card. Here, the CPU 21 may select a card that is given an opportunity to be acquired by the user A, from a card sold by another user, or the CPU 21 may select an arbitrary card from the monster card database.
In the web page P8, when the user: A selects the menu m12, for example, the acquisition price (required points) of the selected card: def: 10000 is deducted from the user's purchase points: 12438, and at the same time, the selected card: def is : Given to A.
On the other hand, when the user: A selects the menu m13, the acquisition price (necessary points) of the selected card: abc: 20000 exceeds the purchase point: 12438 of the user: A, so the selected card: abc is the user: For example, as shown in P9 of FIG. 12, the web page is updated without being assigned to A. The web page P9 includes information on the card: abc selected by the user: A, text indicating that the purchase point of the user A is insufficient for the purchase price (“the point is insufficient”), and the card selected by the user: A The menu m14 labeled “Register” for registering the user, the text indicating the purchase point of the user A (“purchase point: 12438”), the user: the card selected by the user of the purchase point of A: abc It includes text (“Purchase Points: -7562”) indicating the shortage points for the consideration. Note that the downward arrow (↓) indicates that when the user A selects the menu m14, the point displayed on the web page of the user A is an insufficient point.
In the web page P9, when the user: A selects the menu m14, the web page is updated, for example, as shown in P10 of FIG. The web page P10 includes information regarding the registration card: abc of the user: A, text indicating registration (“registered”), and text indicating the point displayed on the web page of the user: A (“purchase” Point: -7562 "), and text indicating the time from the current time to the registration expiration date (" remaining time: 24:00 "). Here, the points displayed on the top page of the user: A after registration are shortage points (hereinafter referred to as “shortage points”) for the acquisition price of the registration card: abc of the purchase points of the user: A.

In a state where the user: A has registered the card: abc, the top page of the user: A is written as “card registration in progress” indicating that the card has been registered, for example, as shown at P11 in FIG. Contains menu m3. In addition, the top page P11 includes text indicating a shortage point (“purchase point: -7562”) instead of the purchase point of the user: A.
In the top page P11, when the user: A selects the menu m3, for example, as shown at P12 in FIG. The web page P12 includes information on the registration card: abc of the user: A, text indicating a shortage point (“purchase point: −7562”), text indicating the time from the current time to the registration expiration date (“remaining time: 04: 00 ”), a menu m31 described as“ registration cancellation ”for canceling registration, text indicating a shortage point (“ purchase points: −7562 ”), user after registration cancellation: text indicating purchase points of A (“ (Purchase point: 12438 "), text indicating that purchase points corresponding to the purchase price will be refunded by canceling registration (for example," Point difference will be refunded "), return to top page A menu m32 labeled “RETURN”.

[Quest processing when there is a registered card]
In the top page P11, when the user: A selects the menu m1 and purchase points are given to the user: A in the quest process, the web page is updated as shown in P13 or P14 of FIG. Here, after the purchase point is given to the user: A, when the purchase point of the user: A is insufficient for the acquisition price of the registration card of the user: A, it is updated to the web page P13, and the purchase point of the user: A is changed. User: When the purchase price for the registration card of A is exceeded, the web page P14 is updated.
The web page P13 is a “registration cancellation” for canceling registration together with an achievement rate gauge, a menu m10, a value of physical strength points required for one search, an experience value obtained by one search, and an obtained purchase point. And the text indicating the updated shortage point (“point: −6562”). In the web page P13, when the user: A selects the menu m33, for example, as shown in P12 of FIG. 13, the web page is updated to a web page for confirming / cancelling registration.
The web page P14 is a “registration card” for receiving a registration card together with an achievement rate gauge, a menu m10, a value of physical strength points required for one search, an experience value obtained by one search, and obtained purchase points. A menu m34 labeled “Receiving”, and user: A text (“Point: 438”) indicating a point obtained by subtracting the purchase price of the registration card from the purchase point of A. When the user: A selects the menu m34 on the web page P14, the user: A obtains a registration card, and is ready for use in a game such as a battle process.

[Battle process when there is a registered card]
On the top page P11, when the user: A selects the menu m2 and after the battle process, purchase points are given to the user: A, as shown in P15 or P16 of FIG. Updated. Here, after the purchase point is given to the user: A, when the purchase point of the user: A is insufficient for the acquisition price of the registration card, it is updated to the web page P15, and the purchase point of the user: A gets the registration card. When the price is exceeded, the web page P16 is updated.
The web page P15 is updated with the text indicating that the battle has been won (“I won the battle!”) And the purchase points given to the user: A (“1000 purchase points acquired!”), And the updated missing points (“Point: −6562”) and a menu m35 described as “registration cancellation” for canceling registration. In the web page P15, when the user: A selects the menu m35, for example, as shown in P12 of FIG. 13, the web page is updated to a web page for confirming and canceling registration.
The web page P16 shows the purchase of the user: A together with the text indicating that the battle has been won (“I won the battle!”) And the purchase points given to the user: A (“1000 purchase points have been acquired!”). It includes a text (“point: 438”) indicating a point obtained by subtracting the acquisition price of the registration card from the point, and a menu m36 labeled “Receive registration card” for receiving the registration card. When the user: A selects the menu m36 on the web page P16, the user: A obtains a registration card and is ready for use in a game such as a battle process.

(6) Overview of Functions in Game Control Device In the present embodiment, the game control device is configured by the game server 20 and the database server 30. Below, the function implement | achieved with the game control apparatus of this embodiment is demonstrated with reference to FIG. 16, taking the case where the game mentioned above is applied as an example. FIG. 16 is a functional block diagram for explaining functions that play a main role in the game control apparatus of the present embodiment.
In the functional block diagram of FIG. 16, the selection means 52, determination means 53, provision means 54, and registration means 55 correspond to the main configuration of the present invention. The other means (that is, the executing means 51, the releasing means 56, and the accepting means 57) are not necessarily indispensable components, but are components for making the present invention more preferable.

The execution unit 51 receives an HTTP request in response to a user's selection on the web page for the communication terminal 10 and transmits HTML data (that is, an HTTP response) for sequentially updating the web page displayed on the communication terminal 10. By doing so, a function of executing the game of the present embodiment by a web service is provided.
The execution means 51 displays on the communication terminal 10 a plurality of menus each assigned a plurality of processes executed in the game. 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. Then, when the menu on the web page is selected in the communication terminal 10, the CPU 21 receives information about the selected menu from the communication terminal 10, and is assigned to the selected menu based on the received information. Execute the process.

The function that the execution means 51 executes the quest process is realized as follows, for example.
When the menu m1 is selected on the top page (web page illustrated as P1 in FIG. 9), the CPU 21 of the game server 20 illustrates web pages for quest processing (P3, P4 in FIG. 9, and P7 in FIG. 11). HTML data for displaying the web page) is generated and transmitted to the communication terminal 10 of the user. Next, when receiving an HTTP request including the selection result of the menu m10 (“quest execution”), the CPU 21 performs the following series of processes. That is, the CPU 21 accesses the user database and updates (decreases) the value of the physical strength point of the target user ID. Next, the CPU 21 increases the achievement rate value of the user by a predetermined amount. Furthermore, CPU21 produces | generates the HTML data containing the value of the increased achievement rate, for example, and transmits to a user's communication terminal 10. FIG. At this time, if the CPU 21 determines that the value of the achievement rate has reached 100%, the CPU 21 generates HTML data so as to shift the search target to the next area.
In the quest process, the strength points required for one search may be different for each area to be searched. That is, the amount of physical strength points that are reduced (consumed) in one search may be different for each area to be searched. For example, as the user's progress level increases, the amount of physical strength points consumed may be increased.

In the quest process, when the CPU 21 recognizes the selection for the menu m10, it gives the user a card selected from a plurality of cards, gives a predetermined purchase point to the user, and other events on the game. Giving an opportunity to transition is determined with a predetermined or random probability.
When the CPU 21 determines to give the card, the CPU 21 generates HTML data for displaying the web page P3 notifying that the card has been obtained, and transmits the HTML data to the user communication terminal 10. When the CPU 21 determines to give the user a card selected from a plurality of cards, the CPU 21 selects a card to be given to the user from a plurality of cards provided in advance for the quest. To do. Next, the CPU 21 writes the identification code of the selected card in the user database of the target user ID. Moreover, CPU21 may write identification codes, such as predetermined items other than a card, in the user database of the target user ID in the quest process.
When the CPU 21 determines to give the purchase point, the CPU 21 generates HTML data for displaying the web page P4 notifying that the purchase point has been obtained, and transmits it to the communication terminal 10 of the user. When the CPU 21 determines to give the purchase point to the user, the CPU 21 accesses the user database, and gives a value obtained by adding the newly added purchase point to the purchase point before granting the target user ID. Write in the “Purchase Point” field as a later purchase point.
When the CPU 21 determines to give an opportunity to shift to another event on the game, the CPU 21 generates HTML data of a web page including a menu to shift to another event and transmits it to the user's communication terminal 10. . For example, when the CPU 21 determines to give an opportunity to shift to the purchase process, the CPU 21 generates HTML data of the web page including the menu m11 to shift to the purchase process as shown in P7 of FIG. Transmit to the terminal 10.

Moreover, the execution means 51 has a function of executing a battle process. This function is realized as follows, for example. When the CPU 21 of the game server 20 recognizes that the menu m20 (“match start”) has been selected on the web page P5, the team of the user to be processed and the team of the opponent (other users or computers) Processing to determine the match result is performed.
As a determination method of the battle result, any method can be adopted as long as the parameter value of the card included in each team affects the winning or losing. For example, the total of the parameter values of a plurality of cards included in each of the two teams to be played is compared, and the team with the larger sum has a higher probability (for example, a predetermined probability within a range of 60 to 90%). You may set to win. The win rate may be higher as the difference between the parameter values is larger. At this time, as shown in FIG. 7, if there are a plurality of items indicating parameter values (two in the example of FIG. 7, attack power and defense power), the parameter values of each card are represented. By performing predetermined weighting on the value of each item as a value (for example, in the example of FIG. 7, “attack power” is 0.4, “defense power” is 0.2, etc.) A comprehensive parameter value may be set.
Next, when the CPU 21 determines the result of the battle, the CPU 21 generates HTML data for displaying a web page (for example, the web page P6) for notifying the user: A of the battle result, and the communication terminal of the user: A 10 to send.

The selection means 52 has a function of accepting selection of a card that the user desires to obtain based on user input information when the user is given an opportunity to obtain the card. A card is an example of an object. The function of the selection means 52 is implement | achieved as follows, for example.
When the CPU 21 recognizes that the menu m11 to be transferred to the purchase process is selected by the HTTP request received from the communication terminal 10, the CPU 21 reads out information on a plurality of cards that can be selected by the user from the monster card database, and displays P8 in FIG. The HTML data of the illustrated web page for purchase processing is generated and transmitted to the communication terminal 10 of the user. Thereafter, the CPU 21 recognizes the card selected by the user based on the HTTP request received from the communication terminal 10.

The determination means 53 has a function of determining whether or not the user can acquire the card by comparing the acquisition price of the selected card with the points (purchase points) that the user holds on the game. The function of the determination means 53 is implement | achieved as follows, for example.
When the CPU 21 recognizes the card selected by the user based on the selection result included in the HTTP request, the CPU 21 accesses the user database, reads the value of the “purchase point” (user purchase point) corresponding to the user ID, The monster card database is accessed, and the value of “acquisition price” of the card that the user desires to obtain is read. Next, the CPU 21 compares the purchase point of the user with the acquisition price of the card that the user desires to obtain. If the purchase point is equal to or greater than the acquisition price, the CPU 21 determines that the user can obtain the card. On the other hand, if the purchase point is less than the purchase price, the user determines that the card cannot be obtained.

The giving unit 54 has a function of giving a card to the user in exchange for a point corresponding to the acquisition price when it is determined that the user can obtain the card. The function of the provision means 54 is implement | achieved as follows, for example.
When it is determined that the user can obtain the card, the CPU 21 obtains a value obtained by subtracting the card purchase price from the purchase point of the user, and writes the obtained value in the “purchase point” field corresponding to the user ID of the user database. At the same time, the card identification code is written in the “owned card, item identification code” field of the user ID of the user database.

The registration means 55 has a function of registering a card as a user's desired acquisition card when it is determined that the user cannot obtain the card. The function of the registration means 55 is implement | achieved as follows, for example.
When determining that the user cannot obtain the card, the CPU 21 registers the user ID of the user and the card identification code together with the registration time and the registration expiration date in the registration table illustrated in FIG. Note that the registration time may be the time determined as unavailable. The registration expiration date can be a time after a predetermined time (registration period) from the registration time. This registration period may be of a length corresponding to the purchase price of the registration card. The higher the acquisition price for the registration card, the longer the game execution time required for the user to obtain the registration card. For this reason, the length of the registration period can be set to an appropriate value by changing the length of the registration period of the registration card according to the acquisition price of the registration card. For example, it can be avoided that the user gives up obtaining the registration card because the registration period is too short for the acquisition price.
For example, when a card with a high acquisition price is registered, a longer registration period may be used. For example, a registration period of 6 minutes per 100 points of acquisition price may be set.
In addition, when the user performs an operation for registration (selection of the menu m14) on the web page illustrated in P9 of FIG. 12, the user ID of the user and the card identification code, along with the registration time and the registration expiration date, You may register into the registration table illustrated in FIG. In this case, the time when the menu m14 is selected may be set as the registration time.
At the same time, the CPU 21 obtains a value obtained by subtracting the card purchase price from the user's purchase points, and writes the obtained value in the “purchase points” column corresponding to the user ID in the user database. At this time, since the purchase point is less than the acquisition price, a negative value (shortage point) is written in the “purchase point” column.

The canceling unit 56 has a function of canceling registration of a desired card after the expiration date of registration. The function of the cancellation | release means 56 is implement | achieved as follows, for example.
When the user accesses the game, the CPU 21 refers to the registration table. When the corresponding user ID is recorded in the registration table, the CPU 21 compares the current time with the registration expiration date of the corresponding registration code. If the current time is after the registration expiration date, the CPU 21 accesses the monster card database and reads the value of “acquisition price” of the registration card. Next, the CPU 21 accesses the user database and writes a value obtained by adding “acquisition price” to the shortage point written in the “purchase points” column in the “purchase points” column corresponding to the user ID, Refund purchase points. Thereafter, the CPU 21 cancels the registration state by deleting the information of the registration code from the registration table.
Note that the CPU 21 also determines that the user can obtain the registration card, and deletes the information of the registration code corresponding to the given registration card from the registration table even when the user has given the registration card.
Further, the cancellation of the registration of the desired acquisition card is not limited to when the user accesses the game. For example, the registration may be canceled in the order in which the current time has reached the registration expiration date.

The accepting unit 57 has a function of accepting cancellation of registration of a desired card. The function of the reception means 57 is implement | achieved as follows, for example.
When the user accesses the game, the CPU 21 refers to the registration table. When the corresponding user ID is recorded in the registration table, the CPU 21 compares the current time with the registration expiration date of the corresponding registration code. If the current time is before the registration expiration date, the CPU 21 generates HTML data of the top page including the menu m3 exemplified in P11 of FIG. 13 and transmits it to the communication terminal 10 of the user. When the user selects the menu m3, the CPU 2 generates HTML data of the web page including the menu m31 (“registration cancellation”) for canceling the registration exemplified in P12 of FIG. Send to When recognizing that the menu m31 has been selected by receiving an HTTP request from the communication terminal 10, the CPU 21 accesses the monster card database and reads the value of the “acquisition price” of the registered card. Next, the CPU 21 accesses the user database, and writes a value obtained by adding “acquisition price” to “insufficient points” written in the “purchased points” field in the “purchased points” field corresponding to the user ID. Then, refund the purchase points. Thereafter, the CPU 21 cancels the registration state by deleting the information of the registration code from the registration table.

  Instead of canceling the registration state by deleting the registration code information, the registration state may be managed by a flag. For example, if the registration is maintained, the flag is set to “1”, and if the registration is canceled or the registration expiration date has passed, the flag is set to “0”. Can leave.

(7) Flow of main processing of game control device of this embodiment Next, an example of the flow of main processing performed by the game control device of this embodiment will be described with reference to the flowcharts of FIGS. To do. FIG. 17 is a flowchart for performing quest processing in the game of the present embodiment. FIG. 18 is a flowchart when performing the battle process in the game of the present embodiment. FIG. 19 is a flowchart for performing purchase processing in the game of the present embodiment.
In addition, HTML data for displaying each web page of P1 to P16 is transmitted from the game server 20 to the communication terminal 10 as appropriate in accordance with the execution of each process in the flowcharts of FIGS. In some cases, the HTML data transmission process is not described in the flowchart. The timing at which each of the web pages P1 to P16 is displayed on the flowchart is indicated by the reference numerals P1 to P16.
In the flowcharts of FIGS. 17 to 19, the case where the user A executes the game will be described as an example.

[Quest processing]
First, in the flowchart of FIG. 17, when the CPU 21 recognizes that the menu m10 (“execute quest”) of the web page P2 is selected (step S100: YES), the CPU 21 accesses the user database and accesses the user: A. The achievement rate, physical strength points, experience values, etc. are updated (step S102). Next, the CPU 21 determines whether or not to grant a monster card selected from a plurality of monster cards to the user: A, whether to give a purchase point to the user: A, or an opportunity to shift to purchase processing. Is determined with a predetermined or random probability (step S104). In step S104, when it is determined that a monster card is to be given to the user: A (step S104: card grant), the CPU 21 performs a process of giving the monster card to the user: A (step S106). In this case, the CPU 21 accesses the monster card database and selects an identification code of the monster card to be given from a plurality of monster cards provided in advance for the quest. Next, the CPU 21 accesses the user database and writes the identification code selected in the “owned card, item identification code” column of the user ID of user A. Thereafter, the CPU 21 ends the quest process.

When it is determined in step S104 that purchase points are to be given to the user: A (step S104: point grant), the CPU 21 performs a process of giving purchase points to the user: A (step S108). In this case, the CPU 21 accesses the user database, and adds the newly added purchase point to the purchase point before granting the target user ID as the purchase point after grant in the “Purchase Point” column. Write. Next, the CPU 21 determines whether or not the user: A has a registration card (step S110). Specifically, if the user ID of user A is registered in the registration table and the current time is within the registration period, it is determined that user A has a registration card. On the other hand, when the user ID of user A is not registered in the registration table, it is determined that user A does not have a registration card. Also, if the user ID of user A is registered in the registration table but the current time is not within the registration period, it is determined that user A does not have a registration card. When it is determined that the user: A does not have a registration card (step S110: NO), the CPU 21 ends the quest process.
When it is determined that the user: A has a registration card (step S110: YES), the CPU 21 determines whether or not the purchase point of the user: A is equal to or more than the acquisition price for the registration card (step S112). Specifically, the CPU 21 accesses the user database, reads the value of the “purchase point” column corresponding to the user ID of the user: A, accesses the monster card database, and corresponds to the identification code of the registered card. Read the value in the “Acquisition Consideration” column, and compare the purchase points with the consideration available.
When it is determined that the purchase point is equal to or higher than the acquisition price (step S112: YES), the CPU 21 determines whether or not the user A has performed a registration card receiving operation (step S114). Specifically, the CPU 21 determines whether or not the menu m34 is selected on the web page P14. When the user A does not perform the registration card receiving operation (step S114: NO), the CPU 21 ends the quest process.
When the user: A performs a registration card receiving operation (step S114: YES), the CPU 21 gives the registration card to the user: A (step S116). Specifically, the CPU 21 accesses the user database, writes the value obtained by subtracting the card purchase price from the purchase point of the user: A in the “purchase point” field corresponding to the user ID of the user: A, and simultaneously The identification code of the registration card is written in the “owned card, item identification code” field of the user ID of user A. Thereafter, the CPU 21 deletes the registration code information from the registration table, and ends the quest process.
When it is determined that the purchase point is less than the acquisition price (step S112: NO), the CPU 21 determines whether or not the user A has performed a registration cancellation operation (step S118). Specifically, the CPU 21 determines whether or not the menu m33 is selected on the web page P13. When the user: A does not perform the registration cancellation operation (step S118: NO), the CPU 21 ends the quest process.
When the user A performs a registration cancel operation (step S118: YES), the CPU 21 performs a registration cancellation process (step S120), and ends the quest process. Specifically, it is determined whether or not the menu m31 is selected on the web page P12. When the CPU 21 recognizes that the menu m31 has been selected, the CPU 21 accesses the user database, and adds the acquisition price of the registration card to the shortage point written in the “purchase points” column corresponding to the user ID of the user: A. The value obtained is written in the “Purchase Point” field corresponding to the user ID. Thereafter, the CPU 21 cancels the registration by deleting the registration code information from the registration table, and ends the registration cancellation process. On the other hand, when a menu other than the menu m31 is selected, or when a predetermined time has passed without the menu m31 being selected, the quest process is terminated without performing the deregistration process.

In step S104, when it is determined to give the user: A an opportunity to shift to the purchase process (step S104: grant purchase opportunity), the CPU 21 determines whether the menu m11 is selected on the web page P7 (step S104). S122). When a menu other than the menu m11 is selected, or when a predetermined time has elapsed without the menu m11 being selected (step S122: NO), the CPU 21 ends the quest process.
When the menu m11 is selected (step S122: YES), the CPU 21 performs a purchase process described later (step S124), and ends the quest process.
In addition, CPU21 starts a quest process again from step S100, when menu m10 is selected in web page P3, P4, P7. Further, when a predetermined time has elapsed without the menu m10 being selected, or when a menu other than the menu m10 is selected (step S100: NO), the quest process may be terminated.
Further, in the process of step S104, the CPU 21 may determine whether or not a predetermined item other than the card is given to the user: A with a predetermined or random probability. Alternatively, the CPU 21 may end the quest process without determining any of card grant, point grant, and purchase opportunity grant in the process of step S104.

(Competition processing)
Next, an example of a flowchart when performing a battle process will be described with reference to FIG.
When the CPU 21 recognizes that the menu m20 (“start of battle”) has been selected on the web page P5 (step S200: YES), the CPU 21 and the team of the user to be processed (here, the user: A) and the opponent ( A process of determining a battle result with a team of a computer or another user) is performed (step S202).

  When the user: A loses the battle (step S202: NO), the CPU 21 performs a process of subtracting purchase points from the user: A (step S204), and ends the battle process. Here, when the user: A is defeated in the COM battle, the CPU 21 accesses the user database and decreases the value of the purchase point corresponding to the user ID of the user: A by a predetermined value (for example, 1000). The CPU 21 accesses the user database when the user A is defeated in the user-to-user battle, and simultaneously decreases the value of the purchase point corresponding to the user ID of the user A by a predetermined value (for example, 1000). The value of the purchase point corresponding to the user ID of the opponent is increased by a predetermined value (for example, 1000).

When the user: A wins the battle (step S202: YES), the CPU 21 performs a process of adding purchase points to the user: A (step S206). Here, when the user: A wins in the COM battle, the CPU 21 accesses the user database and increases the value of the purchase point corresponding to the user ID of the user: A by a predetermined value (for example, 1000). The CPU 21 accesses the user database when the user A wins the user-to-user battle, and increases the value of the purchase point corresponding to the user ID of the user A by a predetermined value (for example, 1000). The value of the purchase point corresponding to the opponent user ID is decreased by a predetermined value (for example, 1000).
Next, the CPU 21 determines whether or not the user: A has a registration card (step S208). Specifically, if the user ID of user A is registered in the registration table and the current time is within the registration period, it is determined that user A has a registration card. On the other hand, when the user ID of user A is not registered in the registration table, it is determined that user A does not have a registration card. Also, if the user ID of user A is registered in the registration table but the current time is not within the registration period, it is determined that user A does not have a registration card. If it is determined that the user: A does not have a registration card (step S208: NO), the CPU 21 ends the battle process.
When it is determined that the user: A has a registration card (step S208: YES), the CPU 21 determines whether or not the purchase point of the user: A is equal to or higher than the acquisition price for the registration card (step S210). Specifically, the CPU 21 accesses the user database, reads the value of the “purchase point” column corresponding to the user ID of the user: A, accesses the monster card database, and corresponds to the identification code of the registered card. Read the value in the “Acquisition Consideration” column, and compare the purchase points with the consideration available.
When it is determined that the purchase point is equal to or higher than the acquisition price (step S210: YES), the CPU 21 determines whether or not the user A has performed a registration card receiving operation (step S212). Specifically, the CPU 21 determines whether or not the menu m36 has been selected on the web page P16. When the user A does not perform the registration card receiving operation (step S212: NO), the CPU 21 ends the battle process.
When the user: A performs a registration card receiving operation (step S212: YES), the CPU 21 gives the user: A a registration card to the user: A (step S214). Specifically, the CPU 21 accesses the user database, writes a value obtained by subtracting the acquisition price of the registration card from the purchase point of the user: A in the “purchase point” column corresponding to the user ID of the user: A, At the same time, the identification code of the registration card is written in the “owned card, item identification code” column of the user ID of user A. Thereafter, the CPU 21 deletes the registration code information from the registration table, and ends the battle process.
When it is determined that the purchase point is less than the acquisition price (step S210: NO), the CPU 21 determines whether or not the user A has performed a registration cancellation operation (step S216). Specifically, the CPU 21 determines whether or not the menu m35 has been selected on the web page P15. When the user A does not perform the registration cancellation operation (step S216: NO), the CPU 21 ends the battle process.
When the user A performs a registration cancellation operation (step S216: YES), the CPU 21 performs a registration cancellation process (step S218), and ends the battle process. Specifically, it is determined whether or not the menu m31 is selected on the web page P12. When the CPU 21 recognizes that the menu m31 has been selected, the CPU 21 accesses the user database, and adds the acquisition price of the registration card to the shortage point written in the “purchase points” column corresponding to the user ID of the user: A. The value obtained is written in the “Purchase Point” field corresponding to the user ID. Thereafter, the CPU 21 cancels the registration by deleting the registration code information from the registration table, and ends the registration cancellation process. On the other hand, when a menu other than the menu m31 is selected or when a predetermined time has elapsed without the menu m31 being selected, the battle process is terminated without performing the deregistration process.
Note that the CPU 21 may end the battle process when a predetermined time has passed without the menu m20 (“start of battle”) being selected on the web page P5, or when a menu other than the menu m20 is selected (step S200). : NO).

[Purchase processing]
Next, an example of a flowchart for performing purchase processing will be described with reference to FIG.
When recognizing that the menu m11 ("stop") is selected on the web page P7, the CPU 21 determines a plurality of cards (exhibition cards) that can be selected by the user A (step S300), and the web illustrated in P8. HTML data for displaying a page is generated and transmitted to the user's communication terminal 10. Next, the CPU 21 determines whether or not the user: A has selected any exhibition card on the web page P8 (step S302). Specifically, the CPU 21 determines whether menus m12 and m13 (“Acquire”) corresponding to the exhibition card have been selected. When the user A does not select any exhibition card (step S302: NO), the CPU 21 ends the purchase process.
When the user: A selects any exhibition card (step S302: YES), the CPU 21 determines whether or not the purchase point of the user: A is equal to or higher than the acquisition price of the selected card (selected card). (Step S304). Specifically, the CPU 21 accesses the user database, reads the value of the “purchase point” column corresponding to the user ID of the user: A, accesses the monster card database, and adds the identification code of the selected card. Read the value in the corresponding “Acquisition Consideration” column, and compare the purchase points with the consideration received.
When it is determined that the purchase point is equal to or higher than the acquisition price (step S304: YES), the CPU 21 gives the selection card to the user: A (step S306). Specifically, the CPU 21 accesses the user database and writes the value obtained by subtracting the purchase price of the selected card from the purchase point of the user: A in the “purchase point” field corresponding to the user ID of the user: A, At the same time, the identification code of the selected card is written in the “owned card, item identification code” column of the user ID of user A. Thereafter, the CPU 21 ends the purchase process.
When it is determined that the purchase point is less than the acquisition price (step S304: NO), the CPU 21 determines whether or not the user A has performed a registration operation (step S308). Specifically, the CPU 21 determines whether or not the menu m14 is selected on the web page P9. When the user A does not perform the registration operation (step S308: NO), the CPU 21 ends the purchase process.
When the user A performs a registration operation (step S308: YES), the CPU 21 performs a registration process (step S310) and ends the purchase process. Specifically, the CPU 21 registers the user ID of the user: A and the identification code of the selected card in the registration table illustrated in FIG. 8, and uses the current time as the registration time, after a predetermined time (registration period) from the current time. Is registered in the registration table as the registration expiration date. In the registration process, the CPU 21 may determine the registration period according to the acquisition price of the selected card.
For example, when a selection card having a high acquisition price is registered, a longer registration period may be used.
Note that step S308 may be omitted, and registration processing may be performed regardless of the selection of the user: A when it is determined in step S304 that the purchase point is less than the acquisition price.

As described above, in this game control device, the user can register the card even when the user who is given the opportunity to obtain the card does not have enough points. The user can be motivated to run the game to obtain.
In addition, even if a user who has been given an opportunity to obtain a card does not have enough purchase points, the user can obtain a registered card after having entered a state having sufficient purchase points. Is motivated to run the game to increase purchase points.
Further, when the registration of the card is canceled after the lapse of a predetermined period, it is possible to give the user a motivation for executing the game before the registration is canceled. The present invention is not limited to this, and the registration expiration date may not be provided.
In addition, when providing a shortcut menu that transitions to a web page for confirming or canceling registration on the web page for executing games such as quest processing and battle processing, or the user's top page, the user cancels registration at any time, Other cards can be made available. Note that the present invention is not limited to this, and the registration may not be canceled by the user.

  In the above-described embodiment, a plurality of types of attributes are set on the card, and after the user selects the menu m11 on the web page P5, the purchase page is updated to a web page for selecting the attribute of the card that the user desires to obtain. You may do it. Further, after the user selects the menu m11 on the web page P5, the number of cards that can be selected by the user in the purchase process, the text indicating the number of cards with a high rarity (rare degree), and the like are included. It may be updated to a web page.

In the above embodiment, when the registration is canceled without the user's operation, such as when the registration is expired after the expiration date of registration, the user may be notified that the registration has been canceled. .
In the above embodiment, the registration table is stored in the game database 32. However, the registration table may be stored in the RAM 23 of the game server 20 or an external storage device.

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

(8-1) Modification 1
FIG. 20 shows a functional block diagram of the game control apparatus according to this modification. As shown in FIG. 20, the present modification is different from the functional block diagram of FIG. 16 in that an extension means 58 is added.
The extension means 58 has a function of extending a predetermined period (registration period) from the registration time to the registration expiration date when the difference between the acquisition price of the desired acquisition card and the user's holding points decreases. The function of the extension means 58 is implement | achieved as follows, for example.
When the user has a registration card, when giving a purchase point to the user according to the execution of the game, such as a quest process or a battle process, the CPU 21 accesses the user database, and purchases before giving the target user ID A value obtained by adding the newly added purchase points to the points is written in the “purchase points” column as the purchase points after the grant.
Next, the CPU 21 accesses the monster card database, reads the value in the “acquisition price” column corresponding to the identification code of the registered card, and compares the purchase point with the acquisition price. And when it determines with a purchase point being less than acquisition consideration, CPU21 extends a registration period.

Specifically, when giving purchase points to the user, the CPU 21 determines the length of the extension period of the registration period, calculates the registration expiration date after the extension, and writes it in the registration table. At this time, the registered expiration date that has already been written may be deleted, and the extended registration expiration date may be written. Alternatively, the registration before the extension may be canceled and the registration expiration date after the extension may be written as a new registration in the registration table.
Further, the CPU 21 may extend the registration period for a predetermined time, for example, 3 minutes each time a purchase point is newly given to the user. Or CPU21 may determine the length of the extended time of a registration period according to the purchase point newly provided to the user. For example, the extension time may be 3 minutes for 100 purchase points newly given to the user.

FIG. 21 is an example of a flowchart when performing purchase point grant processing in the present modification. When the purchase point is given to the user, the CPU 21 determines whether or not the purchase point after the grant of the user: A is equal to or more than the acquisition price of the registration card (step S400).
When it is determined that the purchase point is equal to or higher than the acquisition price (step S400: YES), the CPU 21 determines whether or not the user A has performed a registration card receiving operation (step S402). When the user: A does not perform the registration card receiving operation (step S402: NO), the CPU 21 ends the grant process.
When the user: A performs a registration card receiving operation (step S402: YES), the CPU 21 gives the registration card to the user: A (step S404). Specifically, the CPU 21 accesses the user database, and writes the value obtained by subtracting the registered card acquisition price from the purchase point of the user: A in the “purchase point” column corresponding to the user ID of the user: A. At the same time, the identification code of the registered card is written in the “owned card, item identification code” field of the user ID of user A. Thereafter, the CPU 21 ends the grant process.
When it is determined that the purchase point is less than the acquisition consideration (step S400: NO), the CPU 21 performs a registration period extension process (step S406). For example, the CPU 21 determines the length of the extension time of the registration period according to the given purchase points, calculates the registration expiration date after the extension, and writes it in the registration table. Next, the CPU 21 determines whether or not the user A has performed a registration cancellation operation (step S408). When the user: A does not perform the registration cancellation operation (step S408: NO), the CPU 21 ends the grant process.
When the user A performs a registration cancellation operation (step S408: YES), the CPU 21 performs a registration cancellation process (step S410), and ends the grant process.

  In this modification, since the registration period is extended by the user executing the game and increasing the purchase points as much as possible, the user can avoid the loss of the opportunity to acquire the item by canceling the registration. Motivation to run the game can be given.

(8-2) Modification 2
FIG. 22 shows a functional block diagram of the game control apparatus according to this modification. As shown in FIG. 22, the present modification is different from the functional block diagram of FIG. 16 in that an acquisition price changing unit 59 is added.

The acquisition price changing means 59 has a function of changing the acquisition price of the registration card according to the time from the registration time. The function of the acquisition price changing means 59 is realized as follows, for example.
When the user has a registration card, after giving purchase points to the user according to the execution of the game, such as a quest process or a battle process, before comparing the purchase price of the user and the acquisition price of the registration card, the CPU 21 The acquisition price to be compared with the purchase point is a value (extra acquisition price) that is increased according to the time from the registration time to the current time. For example, a value obtained by adding a value (interest) obtained by multiplying a time from the registration time to the current time by a predetermined rate (interest rate) to the acquisition price of the registration card may be used as the premium acquisition consideration.
Alternatively, a value obtained by adding 1 point per minute from the registration time to the current time to the acquisition price of the registration card may be used as the additional acquisition price.

FIG. 23 is an example of a flowchart when performing purchase point grant processing in the present modification. When purchase points are given to the user, the CPU 21 calculates a premium acquisition consideration (step S500). Next, the CPU 21 determines whether or not the purchase point after the grant of the user: A is equal to or more than the premium acquisition price of the registration card (step S502).
When it is determined that the purchase point is equal to or greater than the premium acquisition price (step S502: YES), the CPU 21 determines whether or not the user: A has performed a card receiving operation registered (step S504). When the user: A does not receive the registered card (step S504: NO), the CPU 21 ends the grant process.
When the receiving operation of the card registered by the user: A is performed (step S504: YES), the CPU 21 gives the card registered by the user: A to the user: A (step S506). Specifically, the CPU 21 accesses the user database, and obtains a value obtained by subtracting the registered card additional acquisition price from the purchase point of the user: A in the “purchase point” column corresponding to the user ID of the user: A. At the same time, the identification code of the registered card is written in the “owned card, item identification code” column of the user ID of user A. Thereafter, the CPU 21 ends the grant process.
When it is determined that the purchase point is less than the premium acquisition consideration (step S502: YES), the CPU 21 determines whether or not the user A has performed a registration cancellation operation (step S508). When the user: A does not perform the registration cancellation operation (step S508: NO), the CPU 21 ends the grant process.
When the user A performs a registration cancellation operation (step S508: YES), the CPU 21 performs a registration cancellation process (step S510) and ends the grant process.

In this modification, since the acquisition price of the registration card is changed according to the time from the registration time, the user may be motivated to execute the game for the purpose of acquiring the registration card at a time when the acquisition price is lower. it can. For example, in the case where the premium acquisition price is increased according to the time from the registration time to the current time in consideration of the interest, the user is given a motivation to execute the game in order to obtain the desired acquisition card earlier. be able to.
In the above-described modification, the example of increasing the registration card acquisition price according to the time from the registration time to the current time has been described, but the registration card acquisition price according to the time from the registration time to the current time has been described. It may be decreased.
For example, if cancellation of registration is accepted, the value obtained by reducing the acquisition price of the registration card (discount acquisition price) will be refunded as a purchase point based on the time of reception of registration cancellation (acceptance time) in consideration of interest May be. For example, the acquisition price (discounted acquisition price) obtained by subtracting the value (interest) obtained by multiplying the "acquisition price" of the registered card read from the monster card database by a predetermined percentage (interest rate) from the registration time to the reception time You may refund the user.

(8-3) Modification 3
FIG. 24 shows a functional block diagram of the game control apparatus according to this modification. As shown in FIG. 24, the present modification is different from the functional block diagram of FIG. 16 in that a point giving means 60 is added.

The point giving means 60 has a function of giving points to the user in accordance with the execution of the game and changing the points to be given to the user in accordance with the execution of the game when the desired acquisition card is registered. The function of the point provision means 60 is implement | achieved as follows, for example.
When the user has a registration card, when the purchase point is given to the user according to the execution of the game, such as a quest process or a battle process, the CPU 21 purchases a purchase point (a premium purchase point) with a value different from that when there is no registration card. ) To the user. For example, when there is a registration card, the user may be given an extra purchase point (for example, 10%) more than the purchase point when there is no registration card.

FIG. 25 is a flowchart when the quest process is performed in the game of the present modification. Note that some of the steps similar to those in the flowchart of FIG. 17 are omitted.
First, in the flowchart of FIG. 25, when recognizing that the menu m1 (“quest”) is selected on the top page P1, the CPU 21 of the game server 20 displays HTML for displaying the web page illustrated in P2 of FIG. Data is generated and transmitted to the communication terminal 10 of the user: A. When the CPU 21 recognizes that the menu m10 ("Quest execution") has been selected (step S600: YES), the CPU 21 accesses the user database and updates the achievement rate, physical fitness points, experience points, etc. of the user: A. (Step S602). Next, the CPU 21 determines whether or not to grant a monster card selected from a plurality of monster cards to the user: A, whether to give a purchase point to the user: A, or an opportunity to shift to purchase processing. Is determined with a predetermined or random probability (step S604). In step S604, when it is determined that a monster card is to be given to the user: A (step S604: card grant), the CPU 21 performs a process of giving the monster card to the user: A (step S606), and ends the quest process. To do.

If it is determined in step S604 that purchase points are to be given to the user A (step S104: point grant), the CPU 21 determines whether or not the user: A has a registration card (step S608). When it is determined that the user: A does not have a registration card (step S608: NO), the CPU 21 performs a process of giving a normal purchase point to the user: A (step S610). End the quest process.
On the other hand, when it is determined that the user: A has a registration card (step S608: YES), the CPU 21 performs processing to give the user: A more premium purchase points than the normal purchase points (step S612). In this case, the CPU 21 calculates a premium purchase point to be given to the user: A, accesses the user database, and adds the premium purchase point to be given to the purchase point before grant corresponding to the user ID of the user: A. Write the value in the “Purchase Points” field.
Next, the CPU 21 determines whether or not the purchase point of the user: A is equal to or more than the acquisition price of the registration card of the user: A (Step S614).
When it is determined that the purchase point is equal to or higher than the acquisition price (step S614: YES), the CPU 21 determines whether or not the user A has performed a registration card receiving operation (step S616). When the user: A does not perform the registration card receiving operation (step S616: NO), the CPU 21 ends the quest process.
When the user: A performs a registration card receiving operation (step S616: YES), the CPU 21 gives the user: A the registration card to the user: A (step S618), and ends the quest process.
When it is determined that the purchase point is less than the acquisition consideration (step S614: NO), the CPU 21 determines whether or not the user A has performed a registration cancellation operation (step S620). When the user: A does not perform the registration cancellation operation (step S620: NO), the CPU 21 ends the quest process.
When the user A performs a registration cancel operation (step S620: YES), the CPU 21 performs a registration cancellation process (step S622), and ends the quest process.

In step S604, when it is determined to give the user: A an opportunity to shift to the purchase process (step S604: purchase opportunity grant), the CPU 21 determines whether the menu m11 is selected on the web page P7 (step S604). S624). When a menu other than the menu m11 is selected, or when a predetermined time has elapsed without the menu m11 being selected (step S624: NO), the CPU 21 ends the quest process.
When the menu m11 is selected (step S624: YES), the CPU 21 performs a purchase process (step S626) and ends the quest process.
When the menu m10 is selected on the web pages P3, P4, and P7, the CPU 21 starts the quest process again from step S600. Further, when a predetermined time has passed without menu m10 being selected, or when a menu other than menu m10 is selected (step S600: NO), the quest process may be terminated.

FIG. 26 is a flowchart for performing a battle process in the game of the present modification. Note that a part of the same steps as those in the flowchart of FIG. 18 will be omitted.
When the CPU 21 recognizes that the menu m2 (“match”) has been selected on the top page P1, the CPU 21 generates HTML data for displaying the web page exemplified in P5, and sends it to the communication terminal 10 of the user: A. Send.
When the CPU 21 recognizes that the menu m20 (“match start”) has been selected on the web page P4 (step S700: YES), the CPU 21 and the team of the user to be processed (here, the user: A) and the opponent ( A process of determining a battle result with a team of a computer or another user) is performed (step S702).

When user A loses the battle (step S702: NO), the CPU 21 performs a process of subtracting purchase points from the user A (step S704), and ends the battle process.
When the user: A wins the battle (step S702: YES), the CPU 21 determines whether the user: A has a registration card (step S706). When it is determined that the user: A does not have a registration card (step S706: NO), the CPU 21 performs a process of adding normal purchase points to the user: A (step S708), and ends the battle process.
When it is determined that the user: A has a registration card (step S706: YES), the CPU 21 performs a process of giving the user: A more premium purchase points than normal purchase points (step S710). In this case, the CPU 21 calculates a premium purchase point to be given to the user: A, accesses the user database, and adds a value obtained by adding the premium purchase point to the purchase point before grant corresponding to the user ID of the user: A. Then, write in the “Purchase Point” column as the purchase point after the grant.

Next, the CPU 21 determines whether or not the purchase point of the user: A is equal to or higher than the acquisition price of the registration card of the user: A (step S712). When it is determined that the purchase point is equal to or higher than the acquisition price (step S712: YES), the CPU 21 determines whether or not the user A has performed a registration card receiving operation (step S714). When the user A does not perform the registration card receiving operation (step S714: NO), the CPU 21 ends the battle process.
When the user: A performs a registration card receiving operation (step S714: YES), the CPU 21 grants the registration card to the user: A by the user: A (step S716), and ends the battle process.
When it is determined that the purchase point is less than the acquisition price (step S712: NO), the CPU 21 determines whether or not the user A has performed a registration cancellation operation (step S718). When the user A does not perform the registration cancellation operation (step S718: NO), the CPU 21 ends the battle process.
When the user A performs a registration cancellation operation (step S718: YES), the CPU 21 performs a registration cancellation process (step S720), and ends the battle process.
Note that the CPU 21 may end the battle process when a predetermined time has passed without the menu m20 (“start of battle”) being selected on the web page P5, or when a menu other than the menu m20 is selected (step S700). : NO).

In this modification, the execution time of the game required for the user to obtain the acquisition desired card is changed by changing the points given to the user depending on whether the acquisition desired card is registered or not. Can be varied.
For example, by increasing the points given to the user when the desired acquisition card is not registered, the game execution time required for the user to acquire the desired acquisition card is shortened. For this reason, even if the user does not have enough points, the user can be motivated to actively register the desired card and execute the game.
On the other hand, in consideration of interest, the number of points given to the user when the desired card is registered is less than when the desired card is not registered. Execution time can be extended.

(8-4) Modification 4
FIG. 27 shows a functional block diagram of the game control apparatus according to this modification. As shown in FIG. 27, the present modification is different from the functional block diagram of FIG. 16 in that a first restricting means 61 is added.
The first restricting means 61 has a function of restricting a user's opportunity to obtain another card when an acquisition desired card is registered. The function of the 1st restriction | limiting means 61 is implement | achieved as follows, for example.
In the execution of a game such as a quest process or a battle process, when the user is given an opportunity to obtain a card with a predetermined probability, the CPU 21 determines whether or not the user has a registered card. If it is determined that there is a registered card, the probability of giving the user an opportunity to obtain the card is set to zero or a lower probability than when there is no registered card.

FIG. 28 is a flowchart when the quest process is performed in the game of the present modification. Note that some of the steps similar to those in the flowchart of FIG. 17 are omitted.
First, in the flowchart of FIG. 28, when recognizing that the menu m1 (“quest”) is selected on the top page P1, the CPU 21 of the game server 20 displays HTML for displaying the web page illustrated in P2 of FIG. Data is generated and transmitted to the communication terminal 10 of the user: A. When the CPU 21 recognizes that the menu m10 ("Quest execution") has been selected (step S800: YES), the CPU 21 accesses the user database and updates the achievement rate, physical fitness points, experience points, etc. of the user: A. (Step S802). Next, the CPU 21 determines whether the user: A has a registration card (step S804).
Next, the CPU 21 determines whether or not to grant a monster card selected from a plurality of monster cards to the user: A, whether to give a purchase point to the user: A, or an opportunity to shift to purchase processing. Is determined with a predetermined or random probability (step S806). If it is determined in step S804 that the user: A has a registration card, the CPU 21 sets the probability of giving the user an opportunity to shift to the purchase process, for example, zero. That is, when the user: A has a registration card, the CPU 21 does not give the user: A an opportunity to obtain the card in the purchase process.

  In step S806, when it is determined that a monster card is to be given to the user: A (step S806: card grant), the CPU 21 performs a process of giving the monster card to the user: A (step S808), and ends the quest process. To do.

In step S806, when it is determined to give the purchase point to the user: A (step S806: point grant), the CPU 21 performs a process of giving the purchase point to the user: A (step S810). Thereafter, when it is determined that the user: A does not have a registration card (step S812: NO), the CPU 21 ends the quest process.
On the other hand, when it is determined that the user: A has a registration card (step S812: YES), the CPU 21 determines whether the purchase point of the user: A is equal to or more than the acquisition price of the registration card of the user: A. (Step S814).
When it is determined that the purchase point is equal to or higher than the acquisition price (step S814: YES), the CPU 21 determines whether or not the user A has performed a registration card receiving operation (step S816). When the user: A does not perform the registration card receiving operation (step S816: NO), the CPU 21 ends the quest process.
When the user: A performs a registration card receiving operation (step S816: YES), the CPU 21 gives the registration card to the user: A (step S818), and ends the quest process.
When it is determined that the purchase point is less than the acquisition price (step S814: NO), the CPU 21 determines whether or not the user A has performed a registration cancel operation (step S820). When the user: A does not perform the registration cancellation operation (step S820: NO), the CPU 21 ends the quest process.
When the user A performs a registration cancel operation (step S820: YES), the CPU 21 performs a registration cancellation process (step S822), and ends the quest process.

In step S806, when it is determined to give the user: A an opportunity to shift to the purchase process (step S806: purchase opportunity grant), the CPU 21 determines whether the menu m11 is selected on the web page P7 ( Step S824). If it is determined in step S804 that the user: A has a registration card, the process does not proceed to the purchase process.
When a menu other than the menu m11 is selected, or when a predetermined time has elapsed without the menu m11 being selected (step S824: NO), the CPU 21 ends the quest process.
When the menu m11 is selected (step S824: YES), the CPU 21 performs a purchase process (step S826) and ends the quest process.
When the menu m10 is selected on the web pages P3, P4, and P7, the CPU 21 starts the quest process again from step S600. Further, when a predetermined time has passed without menu m10 being selected, or when a menu other than menu m10 is selected (step S600: NO), the quest process may be terminated.

  In the present modification, when an acquisition-desired card is registered, the user is not given an opportunity to acquire another card, so that the user can avoid unintentionally registering the card.

(8-5) Modification 5
FIG. 29 shows a functional block diagram of the game control apparatus according to this modification. As shown in FIG. 29, the present modification is different from the functional block diagram of FIG. 16 in that a second restriction unit 62 is added.
The second restriction means 62 has a function of restricting use of points for obtaining other cards by the user until it is determined that the user can obtain the desired card. The function of the 2nd restriction | limiting means 62 is implement | achieved as follows, for example.
When the user is given an opportunity to obtain a card, the CPU 21 determines whether the user has a registered card. And when there exists a registration card, CPU21 restrict | limits the use of the point for the acquisition of the card | curd by a user. For example, when the user has a registered card, the CPU 21 may restrict the use of points for obtaining the card by the user by restricting the selection of the card desired to be obtained by the user.

FIG. 30 is a flowchart when the purchase process is performed in the game of the present modification. Note that some of the steps similar to those in the flowchart of FIG. 19 are omitted.
When recognizing that menu m11 (“stop”) is selected on web page P7, CPU 21 determines a plurality of cards (exhibition cards) that can be selected by user A (step S900).
Next, the CPU 21 determines whether or not the user: A has a registration card (step S902). When it is determined that the user: A has a registration card (step S902: YES), the CPU 21 notifies the user: A that the exhibition card cannot be selected (step S904), and the purchase process is terminated. For example, instead of the menus m12 and m13 on the web page P8, the CPU 21 displays a web page (a web page that restricts selection of exhibition cards) including text indicating that an exhibition card cannot be selected (such as “cannot be obtained”). The user: A may be notified that the exhibition card cannot be selected by generating HTML data to be sent and transmitting it to the user's communication terminal 10. Although not shown, the web page notifying that the exhibition card cannot be selected may include a shortcut menu to the web page for performing the registration cancellation operation.

When the user: A does not have a registration card (step S902: NO), the CPU 21 determines whether the user: A has selected any exhibition card on the web page P8 (step S906). If the user: A does not select any exhibition card (step S906: NO), the CPU 21 ends the purchase process.
When the user: A selects any exhibition card (step S906: YES), the CPU 21 determines whether or not the purchase point of the user: A is equal to or more than the acquisition price of the selected card (step S908). When it is determined that the purchase point is equal to or higher than the purchase price (step S908: YES), the CPU 21 gives the selection card to the user A (step S910), and the CPU 21 ends the purchase process.
When it is determined that the purchase point is less than the acquisition price (step S908: NO), the CPU 21 determines whether the user A has performed a registration operation (step S912). When the user A does not perform the registration operation (step S912: NO), the CPU 21 ends the purchase process.
When the user A performs a registration operation (step S912: YES), the CPU 21 performs a registration process (step S914) and ends the purchase process.

  In this modification, since it is not possible to obtain other cards using the points until it is determined that the user can obtain the registered card, the game is performed so that the user can obtain another card. Motivate to increase purchase points by executing.

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

The game control device according to the present invention may be a stand-alone game machine used by a user alone, or wirelessly or wiredly with the communication terminal in order to display a game on the user's communication terminal. It may be an information processing apparatus such as a server that can establish communication.
In each of the above-described embodiments, the game server 20 and the database server 30 on the network are configured to realize the functions of the selection unit 52, the determination unit 53, the grant unit 54, the registration unit 55, and the release unit 56. It is not limited to the configuration. It is good also as a structure which implement | achieves at least one part of these means with the communication terminal 10. FIG. Since the communication terminal 10 and the game server 20 can have substantially the same hardware configuration, some functions can be realized by the communication terminal 10 as described in the above embodiments. For example, FIGS. 31A and 31B show examples of function sharing between the communication terminal 10, the game server 20, and the database server 30 for each function in the functional block diagram shown in FIG. 16. Moreover, in each embodiment mentioned above, it was set as the structure which the database server 30 (game database 32) memorize | stored various data (for example, a monster card database, the registration table for every user), However, The communication terminal is a part. You may memorize | store in the memory | storage device in 10. In that case, the storage device may be a mass storage device such as the RAM 13 in the communication terminal 10 or an HDD (Hard Disk Drive) (not shown).

10: Communication terminal 11 ... CPU
12 ... ROM
13 ... RAM
DESCRIPTION OF SYMBOLS 14 ... Image processing part 15 ... Instruction input part 16 ... Display part 17 ... Communication interface part 18 ... Bus 20 ... Game server 21 ... CPU
22 ... ROM
23 ... RAM
24 ... Database access unit 25 ... Communication interface unit 26 ... Bus 30 ... Database server 31 ... User database 32 ... Game database 51 ... Execution means 52 ... Selection means 53 ... Determination means 54 ... Granting means 55 ... Registration means 56 ... Release means 57 ... Accepting means 58 ... Extension means 59 ... Acquisition price fluctuation means 60 ... Point giving means 61 ... First restriction means 62 ... Second restriction means

Claims (13)

A selection means for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A determination unit that compares the acquisition price of the selected object with the points that the user holds in the game and determines whether or not the user can acquire the object;
Registration means for registering the object as the user's desired acquisition object when the user determines that the object cannot be obtained;
A granting unit for granting the user the desired acquisition object in exchange for a point corresponding to the acquisition price when the user determines that the desired acquisition object is available after the desired acquisition object is registered;
Providing means for providing the user with information for displaying an image indicating a shortage point, which is the difference between the point corresponding to the acquisition price and the point held by the user on the game,
A game control device comprising:   2. The game according to claim 1, further comprising: a canceling unit that cancels registration of the object to be obtained based on input information of the user input to the image based on the information provided by the providing unit. Control device. A selection means for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A determination unit that compares the acquisition price of the selected object with the points that the user holds in the game and determines whether or not the user can acquire the object;
A granting unit for granting the object to the user in exchange for a point corresponding to the acquisition price when the user determines that the object is available;
Registration means for registering the object as the user's desired acquisition object when the user determines that the object cannot be obtained;
A first restricting means for restricting an opportunity for the user to obtain another object when the object to be obtained is registered;
A game control device comprising: A selection means for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A determination unit that compares the acquisition price of the selected object with the points that the user holds in the game and determines whether or not the user can acquire the object;
A granting unit for granting the object to the user in exchange for a point corresponding to the acquisition price when the user determines that the object is available;
Registration means for registering the object as the user's desired acquisition object when the user determines that the object cannot be obtained;
Second restriction means for restricting the use of points for obtaining other objects by the user until it is determined that the user can obtain the object to be obtained;
A game control device comprising: A selection means for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A determination unit that compares the acquisition price of the selected object with the points that the user holds in the game and determines whether or not the user can acquire the object;
A granting unit for granting the object to the user in exchange for a point corresponding to the acquisition price when the user determines that the object is available;
Registration means for registering the object as the user's desired acquisition object when the user determines that the object cannot be obtained;
Release means for canceling registration of the desired acquisition object after a predetermined period of time since the acquisition desired object is registered;
A game control device comprising:   The game control apparatus according to claim 5, wherein the predetermined period is a length of time according to an acquisition price of the acquisition-desired object.   The game control apparatus according to claim 5, further comprising an extension unit that extends the predetermined period when a difference between an acquisition price of the acquisition-desired object and a point held by the user decreases. A selection means for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A determination unit that compares the acquisition price of the selected object with the points that the user holds in the game and determines whether or not the user can acquire the object;
A granting unit for granting the object to the user in exchange for a point corresponding to the acquisition price when the user determines that the object is available;
Registration means for registering the object as the user's desired acquisition object when the user determines that the object cannot be obtained;
Acquisition price changing means for changing the acquisition price of the acquisition-desired object according to the time from when the acquisition-desired object is registered;
A game control device comprising: A selection means for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A determination unit that compares the acquisition price of the selected object with the points that the user holds in the game and determines whether or not the user can acquire the object;
A granting unit for granting the object to the user in exchange for a point corresponding to the acquisition price when the user determines that the object is available;
Registration means for registering the object as the user's desired acquisition object when the user determines that the object cannot be obtained;
Point granting means for changing the points to be given to the user in accordance with the execution of the game when the object to be obtained is registered;
A game control device comprising: A selection means for accepting selection of an object that the user desires to obtain based on user input information when the user is given an opportunity to obtain the object;
A determination unit that compares the acquisition price of the selected object with the points that the user holds in the game and determines whether or not the user can acquire the object;
A granting unit for granting the object to the user in exchange for a point corresponding to the acquisition price when the user determines that the object is available;
Registration means for registering the object as the user's desired acquisition object when the user determines that the object cannot be obtained;
Release means for canceling registration of the desired acquisition object after a predetermined period of time since the acquisition desired object is registered;
A first restricting means for restricting an opportunity for the user to obtain another object when the object to be obtained is registered;
A game control device. When the user determines that the user can obtain the desired acquisition object after the desired acquisition object has been registered, the assigning means sends the desired acquisition object to the user in exchange for a point corresponding to the acquisition consideration. imparting to the game control device according to any one of claims 1-10. Program for causing a computer to function as each unit of a game controller according to any one of claims 1 to 11. A game system including a communication terminal of a plurality of users and a server accessed from the communication terminal,
The means of the game control device according to any one of claims 1 to 11 one of the communication terminal or the server includes a game system.

Images