JP2014128463A - Game control device, game control method, program, game system, and online system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To ease dissatisfaction when a user accessing a server cannot receive any service unexpectedly.SOLUTION: A game control device includes: acquisition means for acquiring access time for execution of a game by a user; limiting means for restricting execution of a game by the user at a predetermined common limited time; determination means for determining whether the common limited time includes the user's access time; and privilege granting means for granting a privilege to the user when the common limited time includes the user's access time.

Description

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

2. Description of the Related Art In recent years, online systems that provide services executed by applications created based on an operating environment such as an API (Application Programming Interface) that runs on a web browser, such as electronic commerce such as Internet auctions and Internet shopping, online games, etc. It is popular.
In addition, a so-called social game executed by a game application is popular in a social networking service (SNS) by a specific service provider. 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 a conventional online system, maintenance of a server is performed regularly or irregularly. For example, in a social game, server maintenance is performed when introducing a new event or changing the game specifications. If some or all of the functions that use the game server are disabled during the maintenance period, users who access the server during the maintenance period will not be able to receive services (eg, game execution) and will be dissatisfied. There is a risk of feeling. For this reason, the user is notified in advance of the period during which access to the server is disabled and the service content that cannot be provided. The user who knows the prior notice accesses the server while avoiding the maintenance period in order to receive the service.

However, if the time required for the maintenance is longer than expected, the maintenance end time may be postponed. In this case, a user who accesses the user thinking that the maintenance has been completed cannot receive the service and may feel dissatisfied.
In addition, when maintenance is required due to a sudden server failure, advance notification is not possible or the period of advance notification is short, so users who access the server without knowing the advance notification can provide services. There is a risk of dissatisfaction.

  The present invention has been made in view of the above-described viewpoints, and it is possible to alleviate dissatisfaction when a user who accesses the server cannot receive the service unexpectedly, a game control device, a game control method, a program, The object is to provide a game system and an online system.

A first aspect of the present invention is a game control device.
This game control device
Acquisition means (53) for acquiring an access time for game execution by the user;
Limiting means (54) for limiting the execution of the game by the user for a predetermined common time limit,
Determination means (55) for determining whether or not a user access time is included in the common time limit;
When a user's access time is included in the common time limit, each means of privilege granting means (56) for granting a privilege to the user is provided.

In the present invention, “restricting the execution of the game” includes disabling some of the functions of the game and disabling all the functions of the game.
In the present invention, the “common time limit” includes a period during which some of the functions of the game are disabled and a period during which all the functions of the game are disabled.

  According to this game control device, when the access time of the user is included in the predetermined common time limit for the restriction means (54) to restrict the execution of the game by the user, the benefit grant means (56) gives the user a benefit. By giving, dissatisfaction of the user who is restricted from executing the game can be alleviated.

In the above game device, the privilege granting means (56) grants more privileges to a user whose access time is included in the common time limit than a user whose access time is not included in the common time limit. Also good.
According to this game apparatus, by giving more benefits to a user whose access time is included in the common time limit than a user whose access time is not included in the common time limit, all the users are uniform. Since the user who restricted the execution of the game feels preferentially than the case where the privilege is granted to the user, the dissatisfaction of the user who is restricted to execute the game can be further alleviated.

In the above game device, the privilege granting means (56) may give the user a privilege based on an individual time limit in which the user is restricted from executing the game by the restriction means (54).
In the present invention, the “individual time limit” is a period during which a user has actually disabled a part or all of the functions of the game, or because a part or all of the functions of the game have been disabled. This period is assumed to have suffered a disadvantage and is calculated for each user. For example, at least the time from the access time within the common time limit of the user to the end time of the common time limit.
Alternatively, for example, when the points consumed in the game are set to increase according to time up to an upper limit value determined for each user, the time when the points reach the upper limit value within the common time limit The time from the (arrival time) to the end time of the common time limit may be set as the individual time limit.
It is considered that the dissatisfaction of the user who is restricted in the execution of the game increases according to the individual time limit in which the execution of the game is restricted by the restriction means (54). According to this game device, since a privilege according to the degree of dissatisfaction for each user is given, the content of the privilege given to the user can be set appropriately.

The game apparatus further includes a notice presentation unit (57) for presenting information related to the common time limit to a user in a notice period that is a period before the start time of the common time limit, and the privilege granting means (56) May give the privilege to the user when the access time of the user is included in the notice period.
According to this game apparatus, in order to give a user who has accessed the advance notice period to the user who has accessed the advance notice period and who knows the common restricted time, in order to grant the same benefit to the user who has accessed the common restricted time, Access to the common time limit is suppressed. As a result, it is possible to reduce the load on the server by the user who accesses the common time limit.

The game device may further include postponing means (58) for postponing the end time of the common time limit.
According to this game apparatus, the common time limit is extended by the postponing means (58) for postponing the end time of the common time limit, so that the common time limit is extended. A privilege is also given to the user who accessed during the later end time by privilege grant means (56). For this reason, the dissatisfaction that the user who accesses considering that the initial common time limit has ended can be alleviated.

The game apparatus further comprises an extended notice presenting means (59) for presenting information related to an end time after the postponement by the postponement means to the user during an extended notice period that is a period before the end time before the postponement, and The granting means (56) may grant a privilege to the user when the access time of the user is included in the extended notice period.
According to this game device, the user's dissatisfaction due to the extension of the common time limit can be alleviated by giving a privilege to the user who has accessed the extended notice period.

In the above game device, when the end time of the common time limit is not presented to the user, the privilege giving means (56) grants a privilege according to the number of times the user has accessed within the common time limit. Also good.
The dissatisfaction of users who frequently access within the common time limit is considered to increase with the number of accesses. According to this game device, a privilege according to the degree of dissatisfaction is given to the user by granting the privilege according to the number of accesses within the common time limit, and the user's dissatisfaction can be alleviated.

According to a second aspect of the present invention, there is provided a game control device that controls execution of a game in which parameters on the game related to the user vary with the passage of time.
This game control device
Acquisition means (53) for acquiring an access time for game execution by the user;
Limiting means (54) for limiting the execution of the game by the user for a predetermined common time limit,
Determination means (55) for determining whether or not a user access time is included in the common time limit;
When a user's access time is included in the common time limit, each means of privilege granting means (56) for granting a privilege to the user is provided.

  In a game in which the game parameters related to the user fluctuate with the passage of time, the user schedules the time to access the game so that the value of the parameter is advantageous for the progress of his game. There is a case. In this case, the dissatisfaction of the user who is unexpectedly restricted from executing the game is considered to be higher than in the case of a game whose parameters do not vary with time. According to this game device, a user's dissatisfaction can be relieved by giving a privilege to the user who accessed the common time limit.

In the above game device, the parameter fluctuates until a predetermined value is reached with the passage of time, and the privilege granting means (56) is configured such that the parameter of the user at the access time of the user within the common time limit is the parameter. When the predetermined value is reached, more benefits may be given than when the predetermined value is not reached.
In a game where the parameter changes until it reaches a predetermined value over time, a user whose parameter reaches the predetermined value feels dissatisfied, but a user whose parameter does not reach the predetermined value is considered to be less satisfied . According to this game device, a privilege according to the degree of dissatisfaction is given to the user by giving more benefits to the user whose parameter has reached the predetermined value, thereby relieving the user's dissatisfaction. it can.

A third aspect of the present invention is a game control method.
This game control method
Obtaining an access time for execution of the game by the user;
Limiting the execution of the game by the user for a predetermined common time limit;
Determining whether a user access time is included in the common time limit;
A step of granting a privilege to the user when the access time of the user is included in the common time limit;
including.

A fourth aspect of the present invention relates to a computer.
A function for obtaining an access time for the game execution by the user;
A function to limit the execution of the game by the user at a predetermined common time limit;
A function of determining whether a user access time is included in the common time limit;
A function of giving a privilege to the user when the access time of the user is included in the common time limit,
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
Obtaining means (53) for obtaining an access time to the server for execution of a game by a user;
Limiting means (54) for limiting the execution of the game by the user for a predetermined common time limit,
Determination means (55) for determining whether or not a user access time is included in the common time limit;
When a user access time is included in the common time limit, a privilege granting means (56) for granting a privilege to the user,
Either one of the communication terminal (10) and the server (20) includes these means.

A sixth aspect of the present invention is an online system that includes a plurality of user communication terminals (10) and a server (20) accessed from the communication terminals (10), and provides a predetermined service to the user. .
This online system
An acquisition means (53) for acquiring an access time to the server for the user to receive the service;
Limiting means (54) for limiting the provision of the service to the user at a predetermined common time limit,
Determination means (55) for determining whether or not a user access time is included in the common time limit;
When a user access time is included in the common time limit, a privilege granting means (56) for granting a privilege to the user,
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, the game system, and the online system of the present invention, it is possible to alleviate dissatisfaction when the user who accesses the server cannot receive the service unexpectedly.

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 recovery item database. The figure which shows a common time limit table. The figure which shows an access time 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 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 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 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 figure which shows the common time limit table of the modification 1. The figure which illustrates a series of web pages displayed on a user's communication terminal. The flowchart which shows an example of the main processes of the game control apparatus of the modification 1. 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 figure which shows the access time table of the modification 2. The figure which shows the common time limit table of the modification 2. 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 figure which shows the common time limit table of the modification 3. The figure which shows the access time table of the modification 3. The flowchart which shows an example of the main processes of the game control apparatus of the modification 3. The figure which shows the common time limit table of the modification 4. 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 provided from the CPU 11 as an analysis result of HTML data. The display unit 16 is, for example, an LCD (Liquid Cristal Display) monitor including thin film transistors arranged in a pixel unit in a matrix, and drives the thin film transistors based on the display image data to display the image of the web page on the display screen 16a. To display.

  When the communication terminal 10 is a button input type communication terminal (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 that the user selects one hyperlink or menu that is actively displayed (for example, highlighted) when, for example, a plurality of hyperlinks or menus are displayed on a web page. To be provided. When the communication terminal 10 is configured by a small portable terminal, these buttons are provided on the front surface of the communication terminal 10 so that the user can easily operate (click) with the thumb while holding the communication terminal 10 with one hand. It is preferable to arrange | position. In the example shown in FIG. 2A, the button group 15b is arranged below the button group 15a, and 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 portable terminal, the menu selection operation on the web page displayed on the communication terminal 10 is selected by pressing the direction instruction button and selecting by pressing the enter button. This is done by confirming the selected menu. Further, for example, when the communication terminal 10 is a touch panel input method, the selection operation is performed by instructing (touch operation) a menu position on the display screen 16a on which the web page is displayed with a finger or a pen.

(3) Configuration of Game Server The configuration of the game server 20 will be described with reference to FIG.
The game server 20 manages a game website including a plurality of hierarchical web pages, for example, and provides a game web service to the communication terminal 10. As shown in FIG. 4, the game server 20 includes a CPU 21, ROM 22, RAM 23, database (DB) access unit 24, instruction input unit 25, and communication interface unit 26. A bus 27 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 26.

  For example, the CPU 21 changes, updates, deletes, etc., stored contents of the database server 30 (storage device) based on instructions input by the administrator through the instruction input unit 25 or the like (maintenance).

For example, the CPU 21 performs communication according to HTTP with the web browser of the game server 20 via the communication interface unit 26. 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 26 (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 such as a RAID (Redundant Array of Inexpensive Disks). Each database in the database server 30 is configured to be able to read and write data from the CPU 21 via the database access unit 24 of the game server 20.
FIG. 5 shows an example of the configuration of the database server 30. As shown in FIG. 5, the database server 30 includes a user database (user DB) 31, a game database (game DB) 32, and a maintenance database (maintenance DB) 33.

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.

  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, a progress level, physical strength points, victory points, fellow user IDs, possession cards, and item identification codes. 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 specified in advance by the user, and the display image is an avatar image that is selected in advance by the user, for example. 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 variable which shows the cost consumed 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.
Victory points Points acquired by winning a battle against a computer or another user's team in the battle process. In this game, every time the total number of victory points of a user reaches a predetermined value set in advance, a privilege on the game is given to the user.
・ 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).
Further, the game database 32 stores a monster card database and a recovery item database 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) and parameters of the target monster card (in the example of the figure, the data of each item of the attack power, defense power, and rarity indicating the ability of the monster). 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 recovery item database in which recovery item information is described as an example of items on the game. The recovery item database illustrated in FIG. 8 is a database in which information on all recovery items prepared in the game of this embodiment is described. The recovery item database illustrated in FIG. 8 stores data (a health recovery value) of values to be added to the user's physical strength points when used for each recovery item identification code (RE001, RE002,... Including. Although not shown, there may be a recovery item in which the used user's physical strength points recover at a predetermined rate (physical energy recovery rate) with respect to the upper limit value of the user, and the recovery item database includes physical recovery data. But you can.

FIG. 9 is an example of a common time limit table included in the maintenance database 33. As shown in FIG. 9, in the common time limit table, a start time, an end time, and the like are recorded for each common time limit ID. The reason for limiting the execution of the game (for example, maintenance), the purpose (for example, preparation for a new event), and the like may be recorded.
FIG. 10 is an example of an access time table included in the maintenance database 33. As shown in FIG. 10, the time (access time) when the user accessed the game is recorded and stored for each user ID in the access time table. The access time may be recorded in the access time table only when the user accesses during the common time limit, or the access time may be recorded regardless of whether the time is the common time limit.
Note that the common time limit table and the access time table may be stored in the RAM 23 of the game server 20.

(5) Game of this Embodiment Hereinafter, the game of this embodiment is demonstrated, referring FIGS. 11-14.
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.

11 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 user whose processing target is the first user “A” (hereinafter referred to as “user: A”). It is an example in some cases.
The monster image display area 101 is an area in which an image corresponding to a card designated in advance by the user among a plurality of cards included in the game information 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 level and physical fitness points included in the game information 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 the menu m2 is selected and operated 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 menu m1 is selected and operated on the top page P1 in FIG. 11, 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 (area 4 in the example of the figure), a menu m10 written as “quest execution” for executing search processing, and The value of physical strength points required for one search, experience values obtained by one search, victory points, and the like are included.
Each time the menu m10 is selected and operated by the user A, the achievement rate value 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 and operated, the user: A's physical strength points are consumed by a predetermined amount (8 in the example of FIG. 11). A plurality of search target areas may be provided. In the quest process, each time the menu m10 is selected, the user obtains objects such as cards or items, experience points, victory points, etc. prepared on the game with a predetermined or random probability. It is configured to be able to.

  When the selection operation of the menu m10 is repeatedly performed on the web page P2, the physical strength point decreases as described above. However, when the physical strength point is less than the physical strength point (for example, 8) required for one search, Thus, the search cannot be executed. 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.

(Competition processing)
Next, an example of a battle process will be described. When the menu m2 is selected and operated on the top page P1 in FIG. 12, the battle process is started, and the web page is updated as shown in P3. The web page P3 includes an image of the opponent (E) and a menu m20 written as “start battle” for instructing execution of the battle. When the user: A performs a selection operation of the menu m20 (“start of battle”) on the web page P3, a battle is performed between the user: A team and the opponent: D 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 parameters such as attack power and defense power, but the attack power and defense power are varied according to the special skill and attribute associated with the card set for the team. The winning / losing may be determined by comparing the above, or the winning / losing may be determined by performing a lottery process after varying the probability of winning according to the magnitude of the parameter value. For example, if there is a card with a special skill in the team of the user: A or the opponent: E, the attack power or defense power of a card with a predetermined attribute in the team including the card is increased according to the special skill, or After reducing the attack or defense of cards of a given attribute in the opponent's team, compare the attack strength of the attacking team's cards with the sum of the defense strength of the defending team's cards May be.

  When the battle is over, a web page (web page exemplified in P4) for notifying the result of the battle is displayed on the communication terminal 10 of the user: A. The web page P4 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: D, a predetermined amount of victory points (100 in the example of FIG. 12) is given to the user: A as a privilege.

[Processing during and after the common time limit]
When introducing a new event or changing game specifications, the user database 31 and the game database 32 are maintained. During the maintenance period, some or all of the functions of the game using the user database 31 and the game database 32 may not be executable for some users or all users. When the user accesses the game during a period in which the execution of such a game is limited to some users or all users (common time limit), the top page P1 is not displayed on the user's communication terminal 10. Then, a web page P5 as shown in FIG. 13 is displayed. The web page P5 is, for example, currently (user access time), the game is not executable (“game is not possible”), the scheduled time when the game can be executed (“scheduled end: X month X day 15:00 )). Also, an apology for restricting the execution of the game ("I'm sorry to trouble you"), the reason for restricting the execution of the game ("Because it is under maintenance"), the purpose ("Preparation for starting a new event") You may include text to indicate.
In this embodiment, when user A who accesses the game within the common time limit accesses the game again after the common time limit ends, an item is given as a privilege to user A as described later. (Present)

User: When A receives a present such as an item on the game from the system or another user, as shown in FIG. 14, the top page P6 of the user: A indicates that the item has been transferred (present). A menu m3 ("A gift has arrived") is displayed. When a user who accesses the game within the common time limit accesses the game after the common time limit ends, when the user: A performs a selection operation of the menu m3, a web page as shown in P7 of FIG. 14 is displayed. Is done. The web page P7 displays information related to an item (hereinafter referred to as a privilege item) given as a privilege from the system to a user who has accessed within the common time limit. The privilege item may be the same for all users who have accessed the game within the common time limit, or the privilege item may be changed according to the access time of the user as will be described later.
In addition, a privilege item may be provided irrespective of the operation of the user: A, or the user: A selects and operates the menu m30 (“receive”) displayed on the web page P7. You may give to a user.
In addition, a text or the like indicating an apology ("I apologize for the inconvenience") that the game could not be executed may be displayed.
Moreover, when the user: A has received a plurality of presents, a list of a plurality of presents transferred to the user: A may be displayed, and information related to the privilege item may be displayed in one of them.
Even if a user who has not accessed the game within the common time limit receives a present from the system or another user and then accesses the game, the top page on which the menu m3 is displayed is displayed. . In this case, when the user performs the selection operation of the menu m3, the web page may be updated so as to display a list of presents transferred to the user (not shown).

(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. 15 for the case where the game mentioned above is applied as an example. FIG. 15 is a functional block diagram for explaining functions that play a major role in the game control apparatus of the present embodiment.
In the functional block diagram of FIG. 15, the acquisition means 53, the restriction means 54, the determination means 55, and the privilege grant means 56 correspond to the main configuration of the present invention. The other means (that is, the registration means 51 and the execution means 52) are not necessarily indispensable components, but are components for making the present invention more preferable.

The registration unit 51 has a function of recognizing a user request based on an appropriate operation input to the communication terminal 10 on a web page provided to the communication terminal 10, for example, and performing a registration process (user registration).
The function of the registration means 51 is implement | achieved as follows, for example. The CPU 21 of the game server 20 receives a registration request message from the communication terminal 10 via the communication interface unit 26. The registration request message is automatically generated by a predetermined operation on the communication terminal 10 on the web page provided from the game server 20 (for example, a predetermined menu selection operation or a text input such as a user ID or password specified by the user). Web pages may be configured to be generated automatically. The registration request message may include information for identifying the communication terminal 10 as the transmission source (for example, individual identification information of a terminal such as a UID (Unique Identifier), an IP address, a mail address, etc.), or If the user has already used another game by the same service provider, the user ID may be included.
When the CPU 21 receives the registration request message and the registration request message does not include the user ID, the CPU 21 issues a new user ID and performs registration processing of the user ID, and then the registration processing is completed. Is sent to the communication terminal 10. When the CPU 21 receives the registration request message and the registration request message includes a user ID, the CPU 21 performs registration processing of the user ID, and then transmits a registration completion message indicating that the registration processing is completed to the communication terminal. 10 to send.
When the registration is completed, the CPU 21 generates user data corresponding to the user ID and stores it in the user database 31. When registration is completed, the user can execute the game of the present embodiment.

The execution means 52 receives an HTTP request in response to a user's selection operation on the web page for the communication terminal 10, and receives HTML data (that is, an HTTP response) for sequentially updating the web page displayed on the communication terminal 10. By transmitting, it has the function to execute the game of this embodiment by web service.
The execution means 52 causes the communication terminal 10 to display a plurality of menus to which a plurality of processes executed in the game are assigned. Specifically, the CPU 21 generates HTML data for displaying a web page including a plurality of menus, and transmits the HTML data to the communication terminal 10. 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 52 executes the quest process is realized as follows, for example.
When the menu m1 is selected and operated on the top page (web page illustrated as P1 in FIG. 10), the CPU 21 of the game server 20 displays a quest processing web page (web page illustrated as P2 in FIG. 10). HTML data to be generated is transmitted to the user's communication terminal 10. Next, when receiving an HTTP request including the selection operation result of the menu m10 (“quest execution”), the CPU 21 performs the following series of processes. That is, the CPU 21 accesses the game information 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 operation for the menu m10, the CPU 21 determines to give the user a card selected from the plurality of cards with a predetermined or random probability. Here, when the CPU 21 determines to give a card, the CPU 21 may generate HTML data for displaying a web page notifying that the card has been obtained and send it to the user's 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.

Further, the execution means 52 has a function of executing a game at an event in the battle process (in this embodiment, a function of executing a battle). 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 P3 or P6, the team of the user to be processed (here, user: A) and the opponent A process of determining a battle result with a team of (computer or other user) 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 P4) for notifying the user: A of the battle result, and the communication terminal of the user: A 10 to send.

The acquisition unit 53 has a function of acquiring an access time for executing a game by a user, for example. The function of the acquisition means 53 is implement | achieved as follows, for example.
When the user accesses the game server 20, the CPU 21 of the game server 20 refers to the real time clock in the CPU 21 to acquire the current time, and uses the current time as the access time for each user ID in the access time table of the maintenance database 33. To record. The acquisition of the access time may be limited to the common time limit, or may be performed every time the user accesses the game server 20 regardless of whether the time is the common time limit. Instead of referring to the real-time clock, the access time may be acquired using a network time protocol acquired via the communication network NW or a standard radio wave (standard frequency time signal radio wave).

The limiting unit 54 has a function of limiting the execution of the game by the user during a predetermined common time limit. The function of the limiting means 54 is implement | achieved as follows, for example.
When the user accesses the game server 20, the CPU 21 of the game server 20 acquires the current time and refers to the common time limit table in the maintenance database 33. If the current time is a time between the start time and end time (within the common time limit) in any common time limit ID, the CPU 21 generates HTML data of the web page P5 as shown in FIG. To the communication terminal. That is, the top page is not displayed, and the user's game execution is restricted. On the other hand, if the current time is not within the common time limit for any common time limit ID, the CPU 21 accesses the user database 31 and the game database 32 to execute a normal game.

The determination unit 55 has a function of determining whether or not the user access time is included in the common time limit. The function of the determination means 55 is implement | achieved as follows, for example.
The CPU 21 refers to the access time table of the maintenance database 33 and obtains access time information corresponding to the user ID. Next, the CPU 21 refers to the common time limit table of the maintenance database 33, and determines whether the acquired access time is between the start time and the end time (within the common time limit) in any common time limit ID. Determine whether or not. For example, referring to the common time limit table in FIG. 9, the user corresponding to the user ID: 000001 in the access time table of FIG. 10 starts the start time (X year X month X day 14:00) of the common time limit ID: 001. Access time (X year X month X day 15:00) and access time (X year X month X day 14:05) between the user and the user ID: 000001 It is determined that it is included in the common time limit (maintenance period) of the time limit ID: 001. On the other hand, since the access time of the user corresponding to the user ID: 000002 is not between the start time and the end time of any common time limit ID, the access time of the user corresponding to the user ID: 000002 is the common time limit. Not determined to be included.

The privilege granting unit 56 has a function of granting a privilege to the user when it is determined that the user access time is included in the common time limit. The function of the privilege provision means 56 is implement | achieved as follows, for example.
As described above, when it is determined that the user access time is included in the common time limit, the CPU 21 grants a privilege item to the user. Granting of privilege items can be performed, for example, by writing the identification code of the privilege item in the user database corresponding to the user ID of the user.

Here, the privilege item may be uniformly given to users whose access time is included in the common time limit. Also, privilege items may be uniformly given to users whose access times are not included in the common time limit. In this case, the privilege items for the users whose access times are included in the common time limit may be more than the privilege items for the users whose access times are not included in the common time limit. For example, the same object may be given to all users, and the privilege item may be given to users whose access times are included in the common time limit.
Alternatively, a privilege item that is more useful than a privilege item that is granted to a user whose access time is not included in the common time limit may be granted to a user whose access time is included in the common time limit.

Moreover, you may change privilege items according to a user's access time. For example, when the privilege item is a recovery item, the CPU 21 gives a recovery item having a higher physical strength recovery value to a user who has recorded an access time close to the start time of the common time limit including the access time. A recovery item with a smaller physical strength recovery value may be given to a user whose access time close to the end time is recorded.
Or CPU21 may calculate the time (individual time limit) which the user considers that execution of the game was restrict | limited for every user, and may provide the said user with the privilege based on the calculated individual time limit. For example, the time between the access time and the end time can be set as the individual time limit. For example, a recovery item having a physical strength recovery value proportional to the length of the individual time limit may be given to the user. For example, the CPU 21 may refer to the recovery item database of FIG. 8 and give a recovery item having a physical strength recovery value closest to a value obtained by multiplying the calculated individual time limit by a predetermined coefficient to the user. For example, when the physical fitness point is set to recover over time, the recovery rate (point / time) of the physical fitness recovery value closest to the value multiplied by the individual time limit is set as a predetermined coefficient. You may give to the said user.
Alternatively, a table in which the individual time limit and the privilege item are associated may be provided in advance, and the privilege item corresponding to the calculated individual time limit may be determined with reference to the table.
For example, if the health point is set to recover 1 point every 3 minutes, the recovery rate is 1/3 (points / minute), so the nearest physical strength to the value obtained by multiplying the individual time limit by 1/3 A recovery item having a recovery value may be given to the user. For example, if the individual restriction time is 40 minutes, the value obtained by multiplying the individual restriction time by 1/3 is 13.333..., And therefore, a recovery item having a physical strength recovery value of 13 may be given to the user. In addition, the fraction may be rounded off, rounded up, or rounded down.

  In addition, a privilege may be provided according to the number of access times within the common time limit, that is, the number of accesses, or a privilege may be provided according to any one access time. For example, a privilege according to the first or last access time within the common time limit may be given to the user. For example, a privilege may be given to the user based on the individual time limit calculated using the first or last access time within the common time limit.

(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. 16 is a flowchart when the quest process is performed in the game of the present embodiment. FIG. 17 is a flowchart when performing the battle process in the game of the present embodiment. FIG. 18 is a flowchart of an access process for recording an access time in the game of the present embodiment. FIG. 19 is a flowchart of a privilege grant process for granting privilege items. FIG. 20 is a flowchart of a privilege item reception process in a user who is given a privilege item.
Note that HTML data for displaying the web pages P1 to P9 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. On the flowchart, the timing at which each of the web pages P1 to P9 is displayed is indicated by reference numerals P1 to P9.
In the flowcharts of FIGS. 16 to 20, a case where the user A executes a game will be described as an example.

[Quest processing]
First, in the flowchart of FIG. 16, when recognizing that the menu m1 (“quest”) is selected on the top page P1, the CPU 21 of the game server 20 displays the web page illustrated in P2 of FIG. HTML 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 S100: YES), whether or not to grant a monster card selected from a plurality of monster cards to the user A. , Determined with a predetermined or random probability. When it is determined that the monster card is to be given to the user: A (step S102: YES), the CPU 21 performs a process of giving the monster card to the user: A (step S104). 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 writes the selected identification code in the user database of the user ID corresponding to the user: A. In addition, when it determines with not giving a monster card | curd to a user in step S102 (step S102: NO), CPU21 transfers to the process of step S106.
The CPU 21 accesses the game information database, updates the achievement rate, physical fitness points, experience points, victory points, etc. of the user: A, generates HTML data that displays the updated values, and generates the communication terminal 10 of the user: A. (Step S106).
Note that the CPU 21 may end the quest process 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).
Further, the CPU 21 may determine whether to give a predetermined item other than the card to the user: A with a predetermined or random probability in the process of step S102.

(Competition processing)
Next, an example of a flowchart for performing the battle process will be described with reference to FIG.
When recognizing 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 P3, and the communication terminal 10 of the user: A Send to.
When the CPU 21 recognizes that the menu m20 (“start of battle”) has been selected on the web page P3 (step S200: YES), the CPU 21 and the opponent of the processing target user (here, the user: A) A process of determining a battle result with the team of (computer or other user) is performed (step S202).
And when user: A wins a battle | competition (step S204: YES), CPU21 performs the process which adds a victory point with respect to user: A (step S206). Here, when the user: A wins in the COM battle, the CPU 21 accesses the game information database and increases the value of the victory point corresponding to the user ID of the user: A by a predetermined value (for example, 100). In addition, when the user: A wins in the battle between users, the CPU 21 accesses the game information database and simultaneously increases the value of the victory point corresponding to the user ID of the user: A by a predetermined value (for example, 500). The value of the victory point corresponding to the user ID of the opponent is decreased by a predetermined value (for example, 500).

  On the other hand, when the user: A loses the battle (step S204: NO), the CPU 21 performs a process of subtracting victory points from the user: A (step S208). Here, when the user: A is defeated in the COM battle, the CPU 21 accesses the game information database and decreases the value of the victory point corresponding to the user ID of the user: A by a predetermined value (for example, 100). When the user A loses in the battle between the users, the CPU 21 accesses the game information database and simultaneously decreases the value of the victory point corresponding to the user ID of the user A by a predetermined value (for example, 500). The value of the victory point corresponding to the user ID of the opponent is increased by a predetermined value (for example, 500).

  In addition, CPU21 may complete | finish a battle | competition process, when predetermined time passes in the state in which the menu m20 ("start of battle | competition") is not selection-operated on the web page P3 or P6 (step S200: NO).

[Access processing]
Next, an example of a flowchart for performing access processing will be described with reference to FIG.
When the user A accesses the game server 20 through the communication network NW, the CPU 21 performs an access process. That is, the CPU 21 acquires the current time, and writes the current time as the access time of the user: A in the access time table shown in FIG. 10 (step S302). Next, the CPU 21 accesses the maintenance database 33 and refers to the common time limit table shown in FIG. 9 (step S304). Next, the CPU 21 determines whether or not the current time is within any common time limit (step S306). For example, for each common time limit ID, the current time is compared with the start time and the end time. If there is a current time between the start time and the end time, the current time is within the common time limit of the common time limit ID. Is determined.
If it is determined that the current time is within the common time limit (step S306: YES), the CPU 21 limits the execution of the game by the user (step S308). That is, the CPU 21 generates HTML data of the web page P5 shown in FIG. 13 based on the end time recorded in the access time table, transmits it to the communication terminal 10 of the user, and ends the access process.
If it is determined that the current time is not within the common time limit (step S306: NO), the CPU 21 ends the access process.

[Bonus grant processing]
Next, with reference to FIG. 19, an example of a flowchart when performing the privilege grant process will be described.
First, the CPU 21 accesses the maintenance database 33 and refers to the access time table (step S400). Next, the CPU 21 determines whether or not the access time of the user: A recorded in the access time table is included in any common time limit (step S402). When the access time is not included in the common time limit (step S402: NO), the CPU 21 ends the privilege granting process and starts executing a normal game.
When the access time is included in the common time limit (step S402: YES), the CPU 21 determines whether or not a privilege item has already been given (step S404). If the privilege item has already been granted (step S404: YES), the privilege grant process is terminated. When the privilege item has not been given yet (step S404: NO), the privilege item is determined based on the access time included in the common time limit, and given to the user: A (step S406). Thereafter, the CPU 21 starts execution of the normal game, transmits the HTML data of the top page including the menu m3 to the user's communication terminal 10 as shown in P6 of FIG. 14, and ends the privilege granting process.

[Reward item receipt processing]
Next, an example of a reception process for receiving a privilege item will be described with reference to FIG.
First, the CPU 21 determines whether or not an operation for selecting the menu m3 has been performed (step S500). When selection operation other than menu m3 is performed (step S500: NO), CPU21 complete | finishes a process.
When the selection operation of the menu m3 is performed (step S500: YES), the CPU 21 transmits the HTML data of the web page P7 in FIG. 14 to the communication terminal 10 of the user. Thereafter, the CPU 21 determines whether or not a selection operation of the menu m30 has been performed (step S502). When the selection operation of the menu m30 is performed (step 502: YES), the CPU 21 writes the privilege item identification code in the user database of the user ID corresponding to the user: A (step S504), and ends the process. When a selection operation other than the menu m30 is performed (step S502: NO), the CPU 21 ends the process.

  In addition, even when a privilege item is not provided, when the user: A has received an item (present) other than the privilege item from another user or the like, the top including the same menu as the menu m3 in the communication terminal 10 of the user: A A page is displayed. In this case, after the selection operation of the menu m3, a web page (not shown) including a menu for writing the identification code of each item in the user database of the user ID corresponding to the user: A together with the list of items transferred. Is displayed.

  As described above, in this game device, when a user's access time is included in the common time limit, in order to give a privilege to the user, the user who has restricted the execution of the game by accessing the common time limit Dissatisfaction can be eased. Furthermore, when granting more benefits to a user whose access time is included in the common time limit than when a user whose access time is not included in the common time limit, the privilege is uniformly given to all users Rather, since the user who is restricted from running the game feels preferential, the dissatisfaction of the user who is further restricted from running the game can be alleviated.

  In addition, since the dissatisfaction of the user who is restricted from executing the game is considered to increase according to the individual time limit for which the game is restricted, the user is dissatisfied when the privilege is given to the user based on the individual time limit. The privilege according to the degree can be given to the user, and the user's dissatisfaction can be further alleviated.

In the above embodiment, the stamina point may be decreased in the quest process, and the decreased stamina point may be set to increase (recover) to the upper limit value as time elapses. A parameter that varies arbitrarily may be set accordingly. For example, another parameter that is consumed in the game and increases (recovers) to the upper limit value as time passes may be set. For example, the consumption cost is set for the card, the usable cost is set for the user, the usable cost is reduced when the user uses the card in the battle process, and the reduced usable cost is set to the upper limit over time. It may be set so as to increase (recover) until an item for recovering the available cost is granted as a privilege.
In the above embodiment, the user who accesses the game within the common time limit gives the privilege item when the user accesses the game again after the common time limit ends, but the present invention is not limited to this. . For example, a privilege item may be given to the user who has accessed the game within the common time limit at the earliest access within the common time limit, or at the end of the common time limit regardless of the user's access. May be given. Further, access after the common time limit has elapsed and present receipt processing need not be used as the conditions for granting.

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

(8-1) Modification 1
FIG. 21 shows a functional block diagram of the game control apparatus according to this modification. As shown in FIG. 21, the present modification is different from the functional block diagram of FIG. 15 in that a notice presentation unit 57 is added.
The notice presentation unit 57 has a function of presenting information on the common time limit to the user in a notice period before the start time of the common time limit.

  An example of the common time limit table for realizing this modification will be described with reference to FIG. As shown in FIG. 22, in the common time limit table, for each common time limit ID, a notice time, a maintenance start time, an end time, etc. for which a maintenance notice is made in advance are recorded.

  An example of a web page for realizing this modification will be described with reference to FIG. When the user: A accesses the game between the notice time and the start time of any common time limit ID, the top page P8 displayed on the communication terminal 10 of the user: A is maintenance as shown in FIG. Includes a menu m4 ("maintenance schedule") that indicates that is scheduled. When the user: A selects and operates the menu m4, a web page shown in P9 of FIG. 23 is displayed on the communication terminal 10 of the user: A. The web page P9 has a scheduled start time and a scheduled end time ("X month X day 14: 00-15: 00") of a common time limit that is between the advance notice time and the start time, and the game cannot be executed. Including text indicating that the game cannot be played. Further, it may include text indicating a reason for restricting the execution of the game (“maintenance”) and a purpose for restricting the execution of the game (“preparation for starting a new event”).

[Access processing]
Next, with reference to FIG. 24, an example of a flowchart for performing access processing in the present modification will be described.
When the user A accesses the game server 20 through the communication network NW, the CPU 21 starts an access process. That is, the CPU 21 acquires the current time, and writes the current time as the access time of the user: A in the access time table shown in FIG. 10 (step S602). Next, the CPU 21 accesses the maintenance database 33 and refers to the common time limit table shown in FIG. 22 (step S604). Next, the CPU 21 determines whether or not the current time is within any notice period (step S606). For example, for each common time limit ID, the current time is compared with the notice time and the start time. If the current time is between the notice time and the start time, the current time is within the notice period of the common time limit ID. judge. When it is determined that the current time is within any of the notice periods (step S606: YES), the CPU 21 performs notice presentation processing (step S608), ends the access process, and starts executing the normal game. .
That is, the CPU 21 transmits the HTML data of the top page P8 including the menu m4 (“maintenance schedule”) indicating that maintenance is scheduled as shown in FIG. 23 to the communication terminal 10 of the user: A. When the user A selects and operates the menu m4, as shown in FIG. 23, the CPU 21 sets the scheduled start time and scheduled end time ("X month X Day 14:00 to 15:00 "), HTML data of the web page P9 including text indicating that the game is not executable (" game is not possible ") is transmitted to the communication terminal 10 of the user: A.
When it is determined that the current time is not within the notice period (step S606: NO), the CPU 21 determines whether or not the current time is within any common time limit (step S610). Thereafter, processing similar to the flowchart shown in FIG. 18 is performed.
That is, when it is determined that the current time is within the common time limit (step S610: YES), the CPU 21 restricts execution of the game by the user (step S612). That is, the CPU 21 transmits the HTML data of the web page P5 shown in FIG.
If it is determined that the current time is not within the common time limit (step S610: NO), the CPU 21 ends the access process.

FIG. 25 is a flowchart of the privilege grant process in the present modification.
First, the CPU 21 accesses the maintenance database 33 and refers to the access time table (step S700). Next, the CPU 21 determines whether or not the access time of the user A recorded in the access time table is included in any notice period or common time limit (step S702). When the access time is not included in either the notice period or the common time limit (step S702: NO), the CPU 21 ends the privilege granting process and starts executing the normal game.
When the access time is included in the notice period or the common time limit (step S702: YES), the CPU 21 determines whether or not a privilege item has already been given (step S704). When the privilege item has already been granted (step S704: YES), the privilege grant process is terminated. When the privilege item has not been given yet (step S704: NO), the privilege item is determined based on the access time included in the notice period or the common time limit, and given to the user: A (step S706). Thereafter, the CPU 21 starts execution of the normal game, transmits the HTML data of the top page including the menu m3 to the user's communication terminal 10 as shown in P6 of FIG. 14, and ends the privilege granting process.

  Here, in step S706, there may be various grant modes for determining the privilege item based on the access time included in the notice period or the common time limit. A privilege may be given according to the number of access times within the notice period or the common time limit, or a privilege may be given according to any one access time. For example, a privilege according to the first or last access time within the common time limit may be given to the user. For example, the privilege may be given to the user based on the individual time limit calculated using the first or last access time of the user who has accessed the common time limit.

Moreover, you may give the privilege which is different with the case where access time is in a notice period, and the case where access time is in common time limit.
If (a) the access time is recorded in the notice period but the access time is not recorded in the common restriction time, (b) the access time is recorded in the notice period and the common restriction time is If another access time is recorded, (c) the access time is recorded in the common time limit, but no access time is recorded in the notice period, (d) the notice period and the common time limit In any case where the access time is not recorded in any of the four cases, the privilege may be given in a different manner.

  For example, in the case of (a) and (b), the privilege according to the common time limit is granted, in the case of (c), the privilege according to the individual time limit is granted, and in the case of (d), the privilege is not given. May be. By setting the privilege grant in this way, (a) the privilege when not accessing the common time limit after accessing the notice period, (b) accessing the common time limit after accessing the notice period Since it becomes the same as the privilege in the case, the necessity for the user to access the common time limit is reduced, and the frequency of the user accessing the common time limit can be reduced. If there is an access during maintenance, a load is applied to the game server 20, but by making such a setting, the load on the game server 20 can be reduced.

  In addition, in the case of (a), a privilege according to the common time limit is given, in the case of (b) and (c), a privilege according to the individual time limit is given, and in the case of (d), a privilege is not given. May be. By setting the privilege grant in this way, (a) the privilege when not accessing the common time limit after accessing the notice period, (b) accessing the common time limit after accessing the notice period In this case, the frequency of access to the common time limit can be further reduced. If there is an access during maintenance, a load is applied to the game server 20, but the load on the game server 20 can be further reduced by such a setting.

(8-2) Modification 2
FIG. 26 shows a functional block diagram of the game control apparatus according to this modification. As shown in FIG. 26, the present modification is different from the functional block diagram of FIG. 15 in that a postponing means 58 is added.
The postponing means 58 has a function of postponing the end time of the common time limit. The function of the postponement means 58 is implement | achieved when CPU21 rewrites the content of the common time limit table according to the instruction | indication of the administrator input from the instruction | indication input part 25, for example. Also in this modification, a privilege based on the access time and the end time after postponement can be granted by performing the access process shown in FIG. 18 and the privilege grant process shown in FIG.

In this modification, the privilege may be changed depending on whether there is access during the common time limit before the postponement, and whether the user has access after the postponed end time until the postponed end time. it can. An example of a form for realizing this will be described with reference to FIGS.
FIG. 27 is an example of an access time table in this modification. As shown in FIG. 27, the access time table records, for each user ID, the time when the user accesses the game (access time) in association with the common time limit ID, and the time when the user accesses the game. The end time of the common time limit is stored as “scheduled end time”. That is, the access time between “start time” and “end time” in the common time limit ID: 001 row of FIG. 28 described later is recorded in the row of the common time limit ID: 001 of each user. As will be described later, when the row of the common time limit ID: 001a is added to the common time limit table shown in FIG. 28, when the user subsequently accesses the game, the common time limit ID: 001a is added to the access time table. Will be added. The access time at that time is recorded in the row of the added common time limit ID: 001a, and the “end time” corresponding to the common time limit ID: 001a in FIG. 28B is the common time limit of the access time table. It is recorded at “scheduled end time” in the line of ID: 001a.

  In the present modification, the administrator can change the contents of the common time limit table by inputting an instruction from the instruction input unit 25. FIGS. 28A and 28B are examples of a common time limit table. FIG. 28A is a common time limit table before the contents are added. In FIG. 28A, the “start time” field of the common time limit ID: 001 is “X year X month X day 14:00”. The “End time” field is “X year X month X day 15:00”. On the other hand, FIG. 28B shows a common time limit table because the end time of the common time limit ID: 001 is postponed to 16:00 on the same day at 14:50 (change time) on year X month X day. It is a common time limit table after changing the contents of. In FIG. 28 (b), a common time limit ID: 001a row is added, and the extended end time “X year X month X” is displayed in the “end time” column of the common time limit ID: 001a row. “16:00” is recorded, and the start time “X year X month X day 15:00” of the extended common restriction period is recorded in the “start time” column. Similarly, when the end time is further postponed, rows of common time limit IDs: 001b, 001c,... Are added sequentially.

[Access processing]
Next, with reference to FIG. 29, an example of a flowchart for performing access processing in the present modification will be described.
When the user A accesses the game server 20 through the communication network NW, the CPU 21 performs an access process. That is, the CPU 21 acquires the current time and writes the current time as the access time of the user: A in the access time table shown in FIG. 10 (step S802). Next, the CPU 21 accesses the maintenance database 33 and refers to the common time limit table at the current time (user: time accessed by A) shown in FIG. 28 (step S804). Next, the CPU 21 determines whether or not the current time is within any common time limit (step S806). For example, for each common time limit ID, the current time is compared with the start time and the end time. If there is a current time between the start time and the end time, the current time is within the common time limit of the common time limit ID. Is determined. If the end time after extension is recorded in the common time limit table, if the current time is between the start time before extension and the end time after extension, the current time is the common time limit ID. It is determined that it is within the common time limit.
If it is determined that the current time is within the common time limit (step S806: YES), the CPU 21 limits the execution of the game by the user (step S808). That is, the CPU 21 writes the common time limit ID recorded in the common time limit table in the “common time limit ID” of the access time table, and sets the end time corresponding to the common time limit ID in the “scheduled end time” of the access time table. "Time" is written (step S810). Thereafter, the CPU 21 generates HTML data of the web page P5 shown in FIG. 13 based on the scheduled end time, transmits the HTML data to the communication terminal 10 of the user, and ends the access process.
If it is determined that the current time is not within the common time limit (step S806: NO), the CPU 21 ends the access process.

Here, when the common time limit table when the access time of the user ID: 000001 in FIG. 27 is “X year X month X day 14:30” is in the state of FIG. 28A, the user ID: 000001 “X year X month X day 15:00” is written in “scheduled end time”. Thereafter, even if the common time limit table is rewritten to the state of FIG. 28B and the “end time” is changed to “X year X month X day 16:00”, the user with the user ID: 000001 is subsequently changed. If the access is not made before 16:00 of X year X month X day, the “scheduled end time” of the user ID: 000001 remains “X year X month X day 15:00”.
On the other hand, when the common time limit table when the access time of the user ID: 000002 in FIG. 27 is “X year X month X day 15:05” is in the state of FIG. 28B, the access of the user ID: 000002 A row having “001a” as the “common time limit ID” is added to the time table, and “X year X month X day 16:00” is written in the “scheduled end time” of the row.

[Bonus grant processing]
Next, an example of privilege provision processing in this modification will be described.
In the present modification, when the end time after extension is not recorded in the common time limit table in step S402 of FIG. 19, the access time is recorded between the start time before extension and the end time before extension. If so, it is determined that the access time is within the common time limit. On the other hand, when the end time after extension is recorded in the common time limit table, if the access time is recorded between the start time before extension and the end time after extension, the access time is set at the common time limit. Judge that there is.
In this modification, in step S406 in FIG. 19, the CPU 21 determines a privilege item based on the access time within the common time limit recorded in the access time table and the scheduled end time, and the user: A Give. When the extended end time is recorded in the common time limit table, the privilege item may be determined based on the access time for each common time limit ID recorded in the access time table and the scheduled end time. . When a plurality of access times are included in the common time limit, the privilege item may be determined based on the earliest or latest access time and the scheduled end time.
For example, in the privilege grant process, the privilege item is determined based on the earliest access time among the access times determined to be included in the common time limit and the latest scheduled end time recorded in the access time table. For the user with the user ID: 000001, the individual time limit is calculated as 30 minutes, and for the user with the user ID: 000002, the individual time limit is calculated as 90 minutes, and a privilege corresponding to each time is given.

  Thus, by determining the privilege item based on the scheduled end time at the access time of the user, the user recognizes both the user who did not know the postponement of the end time and the user who knew the postponement of the end time. Based on the scheduled end time, the individual time limit considered that the user could not substantially execute the game is calculated, and a privilege is given. Therefore, the privilege according to a user's dissatisfaction can be provided.

(8-3) Modification 3
FIG. 30 shows a functional block diagram of the game control apparatus according to this modification. As shown in FIG. 30, this modification is different from the functional block diagram of FIG. 26 in that an extended notice presenting means 59 is added.
The extension notice presenting means 59 has a function of presenting information related to the end time after the extension to the user during the extension notice period that is a period before the end time before the extension.

  An example of the common time limit table for realizing this modification will be described with reference to FIGS. 31 (a) and 31 (b). As shown in FIGS. 31A and 31B, the common time limit table records the start time / extension notice time, end time, etc. for each common time limit ID. Here, the “start time” is a maintenance start time, and the “extension notice time” is a time at which an extension notice of the end time of the common time limit is made.

In the present modification, the administrator can change the contents of the common time limit table by inputting an instruction from the instruction input unit 25.
FIG. 31A is a common time limit table before the contents are added. In FIG. 31A, the start time of the common time limit is displayed in the “start time / extension notice time” column of the common time limit ID: 001. The end time “X year X month X day 15:00” of the common time limit is recorded in the column “X year X month X day 14:00” and “end time”.
On the other hand, FIG. 31B is a common time limit table after changing the contents of the common time limit table in order to postpone the end time of the common time limit ID: 001 to 16:00 on the same day. In FIG. 31 (b), a row of common time limit ID: 001a is added, and “X year X month X” is the extended end time in the “End time” column of the row of common time limit ID: 001a. Day 16:00 "is recorded, and extended notice time" X year X month X day 14:50 "is recorded in the" start time / extended notice time "column. Similarly, when the end time is further postponed, a row of common time limit IDs: 001b, 001c,... The postponed end time is recorded in the “end time” field.

FIG. 32 is an example of an access time table in this modification. The access time table in FIG. 32 differs from FIG. 27 in that, when the common time limit table is accessed after being changed as shown in FIG. 31B, the “start time / The access time after the “extension notice time” and before the end time before the extension is recorded in the row of the common time ID: 001a after the change of the access time table. For example, as shown in FIG. 32, in the row of the common time limit ID: 001a of the access time table of the user ID: 000002, the “start time / extension notice time” of the common time ID: 001a is “X year X month”. “X year X month X day 14:55” is recorded as an example of the access time between “X day 14:50” and the end time before extension “X year X month X day 15:00” .
Further, when the user corresponding to the user ID: 000001 accessed before the extended notice time (X month X day 14:50) refers to the common restricted time table of FIG. 31, the extended notice of the common restricted time ID: 001 is obtained. Since the access is made only at the access time (X year X month X day 14:30) before the time (X year X month X day 14:50), the access time table of the user ID: 000001 has a common time limit. Only “X year X month X day 15:00” which is the “scheduled end time” corresponding to ID: 001 is recorded. On the other hand, the user corresponding to the user ID: 000002 has an access time (X year X month X day 14:55) after the extended notice time (X year X month X day 14:50) of the common time limit ID: 001. In the access time table of user ID: 000002 is also recorded “X year X month X day 16:00” that is the “scheduled end time” corresponding to the common time limit ID: 001a. .

[Access processing]
Next, with reference to FIG. 33, an example of a flowchart for performing access processing in the present modification will be described.
When the user A accesses the game server 20 through the communication network NW, the CPU 21 performs an access process. That is, the CPU 21 acquires the current time, and writes the current time as the access time of the user: A in the access time table shown in FIG. 10 (step S902). Next, the CPU 21 accesses the maintenance database 33 and refers to the common time limit table shown in FIG. 31 (step S904). Next, the CPU 21 determines whether or not the current time is within any extended notice period (step S905).
For example, if the common time limit table is not extended as shown in FIG. 31A, the current time is determined not to be within the extended notice period.
Further, if the common time limit table is in a state after the end time is extended as shown in FIG. 31B, the “start time / extension notice time” of the extended common time limit ID: 001a, If the current time is between the “end time” of the common time limit ID: 001 before the extension (extended notice period), it is determined that the current time is within the extended notice period. On the other hand, if there is no current time in the extended notice period, it is determined that the current time is not within the extended notice period.
When it is determined that the current time is not within the extension notice period (step 905: NO), the CPU 21 determines whether or not the current time is within any common time limit, that is, “start time / extension” in the common time limit ID. It is determined whether or not the current time is between “notification time” and “end time” (common time limit) (step S906). If it is determined that the current time is not within the common time limit (step S906: NO), the CPU 21 ends the access process.
When it is determined that the current time is within the extended notice period (step S905: YES), or when it is determined that the current time is within the common time limit (step S906: YES), the execution of the game by the user is restricted. (Step S908). That is, the CPU 21 writes the end time recorded in the common time limit table in the “scheduled end time” of the access time table (step S910). Thereafter, the CPU 21 generates HTML data of the web page P5 shown in FIG. 13 based on the scheduled end time, transmits the HTML data to the communication terminal 10 of the user, and ends the process. Thereafter, the CPU 21 generates HTML data of the web page P5 shown in FIG. 13 based on the scheduled end time, transmits the HTML data to the communication terminal 10 of the user, and ends the process.

[Bonus grant processing]
Next, an example of privilege provision processing in this modification will be described.
In the present modification, when the end time after extension is not recorded in the common time limit table in step S402 of FIG. 19, between the start time before extension / extension notice time and the end time before extension. If the access time is recorded, it is determined that the access time is within the common time limit. On the other hand, if the end time after extension is recorded in the common time limit table, if the access time is recorded between the start time before extension / extension notice time and the end time after extension, the common limit It is determined that there is an access time in time.
In this modification, in step S406 in FIG. 19, the CPU 21 determines a privilege item based on the access time within the common time limit recorded in the access time table and the scheduled end time, and the user: A Give. When the extended end time is recorded in the common time limit table, the privilege item may be determined based on the access time for each common time limit ID recorded in the access time table and the scheduled end time. . When a plurality of access times are included in the common time limit, the privilege item may be determined based on the earliest or latest access time and the scheduled end time.

  For example, in the privilege granting process, when the privilege item is determined and granted based on the earliest access time included in the common time limit and the latest scheduled end time recorded in the access time table, the user ID: 000001 The user is calculated with an individual time limit of 30 minutes, and the user with user ID: 000002 is calculated with an individual time limit of 90 minutes, and a corresponding privilege is given.

  Thus, by determining the privilege item based on the scheduled end time at the access time of the user, the user knows both the user who did not know the postponement of the end time and the user who knew the postponement of the end time. Based on the scheduled end time, the individual time limit that is considered to have caused the user to have substantially failed to execute the game is calculated and a privilege is granted, so that a privilege according to the user's dissatisfaction can be given.

Different privileges may be given depending on whether the access time is within the extension notice period and when it is between the end time before extension and the end time after extension (extension time).
If (a) the access time is recorded in the extended notice period but the access time is not recorded in the extended time, (b) the access time is recorded in the extended notice period and If another access time is recorded, (c) if the access time is recorded in the extension time but not in the extension notice period, (d) the extension notice period and the extension time In any case where the access time is not recorded in any of the four cases, the privilege may be given in a different manner.
For example, in the case of (a) and (b), a privilege according to the extension time is granted, in the case of (c), a privilege according to the individual time limit is granted, and in the case of (d), the privilege is not given May be. By setting the privilege grant in this way, (a) after accessing the extended notice period, the benefit when the extended time is not accessed, (b) accessing the extended time after accessing the extended notice period. Since it becomes the same as the privilege in the case, the necessity for the user to access the extension time is reduced, and the frequency of the user accessing the extension time can be reduced. If there is an access during maintenance, a load is applied to the game server 20, but by making such a setting, the load on the game server 20 can be reduced.
In addition, in the case of (a), a privilege according to the extension time is granted, in the case of (b) and (c), a privilege according to the individual time limit is granted, and in the case of (d), the privilege is not given May be. By setting the privilege grant in this way, (a) after accessing the extended notice period, the benefit when the extended time is not accessed, (b) accessing the extended time after accessing the extended notice period. In this case, the frequency of the user accessing the extended time can be further reduced. If there is an access during maintenance, a load is applied to the game server 20, but the load on the game server 20 can be further reduced by such a setting.

(8-4) Modification 4
An example of the common time limit table for realizing this modification will be described with reference to FIG. As shown in FIG. 34, in this modification, a plurality of common time limits are set to be continuous. That is, the common time limit for the common time limit ID: 001 is 14:00 to 15:00 on the year X month X day, and the common time limit for the common time limit ID 002 is 15:00 to 16 on the year X month X day. The common time limit of 00, common time limit ID: 003 is set to X year X month X day 16: 00-17: 00. Also in this modification, a privilege is provided for every common time limit ID by the access process shown in FIG. 18 and the privilege grant process shown in FIG. For example, if the access time of the user: A is X: X month X day 14:30 minutes, X year X month X day 15:20 minutes, X year X month X day 16:40 minutes, the common time limit ID: The individual time limit corresponding to 001 is calculated as 30 minutes, the individual time limit corresponding to the common time limit ID: 002 is calculated as 40 minutes, and the individual time limit corresponding to the common time limit ID: 003 is calculated as 20 minutes. Benefits are granted. In addition, a privilege may be provided based only on the first access time in each common time limit, or a privilege may be provided based only on the last access time.
In addition, during the privilege granting process, a privilege may be granted based on the total value of the individual time limits calculated for each common time limit ID. Further, a different privilege may be given for each common time limit ID. For example, the ratio of the privilege corresponding to the individual time limit calculated for each common time limit ID may be changed according to the reason or length of the time limit of the common time limit.
Note that, as in the first modification, a notice presentation unit 57 may be provided.

(8-5) Modification 5
When the end time of the common time limit is not presented to the user, among the access times recorded in the access time table, a privilege according to the number of access times within the common time limit, that is, the number of accesses by the user. It may be given.
Here, when the end time is not presented to the user, the end time is fixed, but when the end time is not presented to the user and when the end time is presented to the user, the end time of the common time limit The case where is not fixed is included. Here, the timing of presenting the end time to the user is when the user accesses during the common time limit, the notice period, and the extended notice period.
Although the end time of the common time limit is not presented to the user, the dissatisfaction of the user who accesses frequently is considered to increase with each access. For this reason, a privilege according to the degree of dissatisfaction is given to a user by giving a privilege according to the number of times accessed within a common time limit, and a user's dissatisfaction can be eased.
In addition, when the end time of the common time limit is not fixed, the privilege granting process is performed after the end time is determined.

(8-6) Modification 6
In a game in which a predetermined parameter that is consumed in the game and increases (recovers) to the upper limit over time is set, a recovery item of a parameter proportional to the length of the individual time limit is given to the user as a privilege item. May be. In this case, a privilege according to the parameter value at the access time may be given.
For example, in a game in which the upper limit value of the physical fitness point is determined for each user and the physical fitness point is set to increase (recover) to the upper limit value as time passes, the physical fitness recovery value proportional to the length of the individual time limit When the recovery item is given to the user, a privilege corresponding to the value of the physical strength point at the access time may be given.
Alternatively, the consumption cost is set for the card, the usable cost is set for the user, the usable cost is reduced when the user uses the card in the battle process, and the reduced usable cost is increased to the upper limit over time. It may be set so as to increase (recover) until an item for recovering the available cost is granted as a privilege.

  For example, if the game database 32 is under maintenance and the game cannot be executed, but the user database 31 is accessible, when the user A accesses the game server 20, the CPU 21 accesses the user database 31 and the user: The upper limit value of the A physical strength point and the user at the access time: A difference Δ between the physical strength points of A may be calculated, and a privilege obtained by subtracting the difference Δ may be given.

For example, a privilege corresponding to a value obtained by multiplying the individual restriction time by a recovery rate per unit time of a predetermined parameter (parameter recovery rate (points / hour)) may be given.
Specifically, for example, a recovery item for recovering a parameter corresponding to a value closest to a value obtained by subtracting the difference Δ from the value obtained by multiplying the individual time limit by the parameter recovery rate may be given to the user A. For example, if the parameter recovery rate is 1/3 (points / minute) and the individual time limit is 60 minutes, the value obtained by multiplying the individual time limit (60 minutes) by the parameter recovery rate (1/3) is 20. However, if the parameter of the user A in the access time is 90 and the upper limit value of the parameter is 100, the difference Δ from the value (20) obtained by multiplying the individual time limit (60 minutes) by the parameter recovery rate (1/3) Since the value obtained by subtracting = 10 (= 100−90) is 10, a recovery item whose parameter recovery value is 10 may be given to the user A. In addition, the fraction may be rounded off, rounded up, or rounded down.

In a game in which game parameters related to the user fluctuate with the passage of time, the dissatisfaction of the user who is unexpectedly restricted from executing the game is considered to be higher. According to this game device, a user's dissatisfaction can be eased by giving a privilege to the user who accessed the common time limit.
Moreover, about the privilege given to the user who accessed the notice period in the modification 1, but did not access the common time limit, for example, the user at the upper limit value of the physical strength point of the user: A and the user at the start time of the common time limit The difference Δ with the value of the physical fitness point may be calculated, and the difference Δ may be subtracted from the privilege according to the common time limit. For example, a privilege corresponding to a value obtained by subtracting the difference Δ from a value obtained by multiplying the individual limit time by the physical strength recovery rate (point / time) may be given to the common limit time.

  Even when access to the user database 31 is restricted, if there is a database serving as a backup of the user database 31, the backup database may be accessed and the physical strength point of the user A may be referred to.

  Further, instead of granting a privilege according to the individual time limit, the privilege may be granted based only on the presence or absence of access of the common time limit. For example, a privilege corresponding to a value obtained by subtracting the difference Δ from a value obtained by multiplying the physical strength recovery rate (points / time) by the common time limit may be provided. Further, when calculating the difference Δ, the difference Δ from the upper limit value of the user: A physical strength point may be calculated based on the physical strength point of the user: A at the start time or end time of the common time limit.

  Note that a privilege corresponding to the common time limit may be given to a user who has not accessed the common time limit as well as a privilege for a user who has accessed the common time limit. Also in this case, for example, a privilege is given according to the user's physical fitness point at the start time or end time of the common time limit, or the ratio of the physical fitness point at the start time or end time to the upper limit value of the user's physical fitness point. May be.

Moreover, when the parameter reaches the upper limit value within the common time limit, a privilege may be given in consideration of the time (arrival time).
For example, when the parameter at the time of access is not the upper limit value, the privilege may be given by subtracting the time until the parameter reaches the upper limit value from the individual time limit. This is because the time obtained by subtracting the time until the parameter reaches the upper limit value from the individual time limit is considered as the time during which the user cannot actually enjoy the profit during the game.
Specifically, the following time δ may be subtracted from the individual time limit.
δ = (parameter upper limit value−parameter value at the time of access) ÷ parameter recovery rate That is, a privilege corresponding to the product of (individual time limit−δ) and a privilege ratio according to time may be given.
In addition, when the parameter reaches the upper limit value within the common time limit regardless of whether or not there is access during the common time limit, a privilege according to the time (arrival time) may be given.
For example, instead of setting the individual time limit as the time between the access time and the end time of the common time limit, a privilege may be given using the time from the arrival time to the end time of the common time limit as the individual time limit. . That is, a privilege corresponding to a value obtained by multiplying the time from the arrival time to the end time of the common time limit by a predetermined coefficient may be given. By giving a privilege according to the arrival time, it is possible to compensate for a lost parameter that could have been used if the user had accessed at the arrival time.
As for the arrival time, by recording the time when the physical strength point for each user has reached the upper limit value, or by recording the physical strength point of the user at the event start time for each user, and calculating the arrival time, The arrival time within the common time limit can be acquired.
Moreover, the privilege according to the parameter of the user who did not access common time limit may be less than the user who accessed common time limit, and may be increased. For example, the predetermined coefficient may be changed depending on whether there is access during the common time limit.

(8-7) Modification 7
In the above-described embodiment, the case where the present invention is applied to a social game has been described as an example, but the present invention is not limited to this. The present invention can be applied to any game that can set a time limit for limiting the user's action and / or a game in which game points consumed during the game are supplemented over time. It goes without saying that even in a so-called online game system in which a server device and an online game machine placed in are connected, the progress of the game by the user can be controlled as in the above-described embodiment.
Moreover, in order to display a game on a user's communication terminal, information processing apparatuses, such as a server which can establish communication with the said communication terminal by radio | wireless or a wire, may be sufficient, and communication by radio | wireless or a cable is mutually performed. It may be a communication terminal that can be established.
Further, for example, in the provision of a service by an online system in which a server device placed on a network and a communication terminal (computer) are connected, for example, an Internet shopping service, an Internet auction service, etc. Benefits, for example, points or items that can be used in the service, can be given according to the presence or absence of access to the server by the user or the access time by the user during a period in which the execution of is restricted.

  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.

  In each of the embodiments described above, the game server 20 and the database server 30 on the network are configured to implement the functions of the acquisition unit 53, the limitation unit 54, the determination unit 55, and the privilege grant unit 56. I can't. 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. 35A and 35B 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. Moreover, in each embodiment mentioned above, although it was set as the structure which the database server 30 (game database 32) memorize | stored various data (for example, a monster card database, event data, etc.), the one part in the communication terminal 10 is used. You may memorize | store in a memory | storage device. 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 ... Instruction input unit 26 ... Bus 27 ... Communication interface unit 30 ... Database server 31 ... User database 32 ... Game database 51 ... Registration means 52 ... Execution means 53 ... Acquisition means 54 ... Restriction means 55 ... Determination means 56. Benefit granting means

Claims (14)

Acquisition means for acquiring an access time for execution of a game by a user;
Limiting means for limiting the execution of the game by the user at a predetermined common time limit,
Determining means for determining whether or not a user access time is included in the common time limit;
When a user's access time is included in the common time limit, a privilege granting unit that grants a privilege to the user,
A game control device comprising:   The game control according to claim 1, wherein the privilege granting unit grants more privileges to a user whose access time is included in the common time limit than a user whose access time is not included in the common time limit. apparatus.   The game control device according to claim 1, wherein the privilege granting unit gives the user a privilege based on an individual time limit in which the user is restricted from executing the game by the limitation unit.   The game control device according to claim 3, wherein the individual time limit is at least a time from an access time within the common time limit of the user to an end time of the common time limit. Comprising a notice presenting means for presenting information related to the common time limit to the user in a notice period that is a period before the start time of the common time limit,
The game control device according to any one of claims 1 to 4, wherein the privilege granting unit grants the privilege to the user when the access time of the user is included in the notice period.   The game control device according to claim 1, further comprising a postponing unit that postpones an end time of the common time limit. An extended notice presenting means for presenting information related to the end time after the postponement by the postponement means to the user in an extended notice period that is a period before the end time before the postponement,
The game control device according to claim 6, wherein the privilege granting unit grants a privilege to the user when the access time of the user is included in the extended notice period.   The said privilege provision means provides the privilege according to the frequency | count that the said user accessed within the said common time limit, when the end time of the said common time limit is not shown to a user. The game control device according to one item. A game control device that controls execution of a game in which parameters on a game related to a user vary with the passage of time,
Obtaining means for obtaining an access time for execution of the game by the user;
Limiting means for limiting the execution of the game by the user for a predetermined common time limit,
Determining means for determining whether or not a user access time is included in the common time limit;
When a user's access time is included in the common time limit, a privilege granting unit that grants a privilege to the user,
A game control device comprising: The parameter varies over time until it reaches a predetermined value,
The privilege granting unit grants more privileges when the parameter of the user at the access time of the user within the common time limit has reached the predetermined value than when the parameter has not reached the predetermined value. The game control device according to claim 9. Obtaining an access time for execution of the game by the user;
Limiting the execution of the game by the user for a predetermined common time limit;
Determining whether a user access time is included in the common time limit;
A step of granting a privilege to the user when the access time of the user is included in the common time limit;
Including a game control method. On the computer,
A function for obtaining an access time for the game execution by the user;
A function to limit the execution of the game by the user at a predetermined common time limit;
A function of determining whether a user access time is included in the common time limit;
A function of giving a privilege to the user when the access time of the user is included in the common time limit,
Program to realize. A game system including a communication terminal of a plurality of users and a server accessed from the communication terminal,
Obtaining means for obtaining an access time to the server for execution of a game by a user;
Limiting means for limiting the execution of the game by the user at a predetermined common time limit,
Determining means for determining whether or not a user access time is included in the common time limit;
When a user's access time is included in the common time limit, a privilege granting unit that grants a privilege to the user,
A game system in which any one of the communication terminal and the server is provided. An online system that includes a plurality of user communication terminals and a server accessed from the communication terminal, and provides a predetermined service to the user,
Obtaining means for obtaining an access time to the server for the user to receive the service;
Limiting means for limiting the provision of the service to the user at a predetermined common time limit;
Determining means for determining whether or not a user access time is included in the common time limit;
When a user's access time is included in the common time limit, a privilege granting unit that grants a privilege to the user,
An on-line system in which either one of the communication terminal or the server is provided.

Images