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

Description

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

In recent years, servers that provide games to mobile terminals via communication networks have become widespread. Such a server provides, for example, a game in which a character owned by a player fights against an enemy character, a game in which a so-called quest is cleared according to a game scenario, and the like.

In such games, players are awarded points for performing various events, including battles or quests. This point is consumed each time a battle or quest is executed, and if this point falls below the required value for executing the battle or quest, the battle or quest cannot be executed. These points will be recovered after a certain period of time has passed, but by using a specific recovery item, it is possible to recover points without waiting for the certain amount of time to pass. However, the operation for using a specific recovery item is troublesome for the player, and the player's desire to continue playing the game may be lost.

For example, in Patent Literature 1, when the consumption parameters consumed by a battle with an enemy character are completely consumed, a collective input button for collectively inputting recovery and attack is displayed, and the player can collectively input. A game system is disclosed that recovers consumption parameters and attacks enemies when a button is selected.

JP 2013-230229 A

In the game system described in Patent Literature 1, the player can recover and attack by performing only one operation, so the trouble of operation can be saved. However, since the game (competition) is temporarily interrupted when the consumption parameters are completely consumed, the player's motivation to continue the game may be lost.

SUMMARY OF THE INVENTION The present invention has been made to solve such conventional problems, and it is an object of the present invention to provide a game control method, a computer, and a control program that enable a player to maintain a desire to continue playing the game. do.

A game control method according to the present invention is a game control method in a computer that executes a game, and includes owned points owned by a player for executing events in the game and recovery for recovering the owned points. Points or recovery items are stored, an event is executed on the condition that the possessed points are equal to or greater than a prescribed value, a prescribed value is consumed from the possessed points, and when the possessed points become less than the prescribed value, recovery points or This includes automatically recovering possession points using recovery items.

Further, in the game control method according to the present invention, the player's setting as to whether or not to automatically recover the owned points is accepted, and only when the setting is made to automatically recover the owned points, the owned points are automatically restored. recovery is preferred.

Further, in the game control method according to the present invention, the number and/or types of automatically usable recovery items are accepted by the player, and the number and/or types of automatically usable recovery items are received in order to automatically recover the possessed points. recovery items are preferably used.

Further, in the game control method according to the present invention, the setting of the automatically usable recovery point value by the player is accepted, and only the automatically usable recovery point value is used in order to automatically recover the possessed points. is preferred.

Moreover, in the game control method according to the present invention, it is preferable to give a privilege to the player according to the number of times the owned points are automatically recovered.

Further, in the game control method according to the present invention, it is preferable to change the recovery rate or the recovery amount of the owned points according to the number of times the owned points are automatically recovered.

Further, in the game control method according to the present invention, it is preferable that the predetermined value to be consumed is changed according to the number of times the possessed points are automatically recovered.

Further, in the game control method according to the present invention, it is preferable that the recovery rate or recovery amount in the case of automatically recovering the owned points be set higher than in the case of recovering the owned points according to the instruction of the player.

In addition, in the game control method according to the present invention, when the other players related to the player are stored for each player and the owned points are automatically recovered, the owned points of the other players related to the player are automatically recovered. recovery is preferred.

Further, in the game control method according to the present invention, the other player related to the player means another player who belongs to the same group as the player, another player who has a friend relationship with the player, or a player who has played a game or a quest in the past. is preferably another player who rescued the player in .

Further, in the game control method according to the present invention, the event includes a first event and a second event different from the first event, and when the owned points for the first event are automatically recovered, , the possession points for the second event are also preferably automatically restored.

Further, in the game control method according to the present invention, it is preferable to set the number of times the owned points can be automatically recovered according to the attributes of the game media used in the event owned by the player.

Moreover, in the game control method according to the present invention, it is preferable to set the number of times the possessed points can be automatically recovered according to the difficulty level of the event.

Moreover, in the game control method according to the present invention, the event is preferably a competition or a quest.

Further, a computer according to the present invention is a computer that executes a game, and includes possessed points owned by a player for executing events in the game, and recovery points or recovery items for recovering possessed points. an event execution unit that executes an event and consumes a predetermined value from the owned points on the condition that the owned points are equal to or greater than a predetermined value; and an automatic recovery unit for automatically recovering possessed points using recovery points or recovery items in a case.

Further, a control program according to the present invention is a control program for a computer that executes a game, and includes owned points owned by a player for executing events in the game and recovery points for recovering the owned points. Points or recovery items are stored, an event is executed on the condition that the owned points are equal to or greater than a predetermined value, a predetermined value is consumed from the owned points, and when the owned points become less than the predetermined value, recovery points or To cause a computer to automatically recover possession points using recovery items.

A game control method, a computer, and a control program according to the present invention automatically reduce points by using recovery points or recovery items owned by a player when points for executing a specific event become less than a predetermined value. It is possible to maintain the player's desire to continue playing the game.

1 is a diagram showing an example of a schematic configuration of a game system 1; FIG. 2 is a diagram showing an example of a schematic configuration of a mobile terminal 2; FIG. 3 is a diagram showing an example of a schematic configuration of a server 3; FIG. (a) is a diagram showing an example of the data structure of a player management table, and (b) is a diagram showing an example of the data structure of a card management table. (a) to (d) are diagrams showing an example of a display screen of the mobile terminal 2. FIG. (a) to (d) are diagrams showing an example of a display screen of the mobile terminal 2. FIG. (a) to (c) are diagrams showing an example of a display screen of the mobile terminal 2. FIG. 3 is a diagram showing an example of an operation sequence of the game system 1; FIG. 4 is a diagram showing an example of an operation flow of game progress processing by the server 3; FIG. 7 is a diagram showing an example of an operation flow of automatic recovery setting processing by the server 3; FIG. 4 is a diagram illustrating an example of an operation flow of event execution processing by the server 3; FIG.

Various embodiments of the present invention will now be described with reference to the drawings. However, it should be noted that the technical scope of the present invention is not limited to those embodiments, but extends to the invention described in the claims and equivalents thereof.

(1) Outline of this embodiment In the game system of this embodiment, a player uses a portable terminal to play a game provided by a server. As an event in the game provided by the server, the server executes a battle (competition) with an enemy character using game media owned by the player. Enemy characters in battle are game media owned by other players or non-player characters. Game media are electronic data used in games, and include, for example, cards, items, characters, avatars, and the like. Game media are electronic data that can be acquired, possessed, used, managed, exchanged, combined, enhanced, sold, discarded, and/or gifted by players in the game as the game progresses. The mode of use of the game media is not limited to those specified in this specification. In this embodiment, a card registered in the game system in advance will be described as an example of the game content.

In this game, players are given battle points for performing battles. Battle points are consumed each time a battle is executed, and when the battle points are below the required value for executing a battle, the battle cannot be executed. Battle points are recovered by a predetermined amount each time a certain period of time elapses, and are also recovered by using specific recovery items. In the game system of this embodiment, it is also possible for the player to automatically recover the battle points using recovery items owned by the player when the battle points fall below the required value for executing a battle. As a result, even if the Battle Points are below the required value for conducting a battle, the player can continue the battle without having to use a specific recovery item to recover Battle Points. It is possible to maintain the desire to continue playing the game.

(2) Configuration of Game System 1 FIG. 1 is a diagram showing an example of a schematic configuration of the game system 1. As shown in FIG.

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

(2.1) Configuration of Mobile Terminal 2 FIG. 2 is a diagram showing an example of a schematic configuration of the mobile terminal 2 .

The mobile terminal 2 connects to the server 3 via the base station 4 , the mobile communication network 5 , the gateway 6 and the Internet 7 and communicates with the server 3 . The mobile terminal 2 executes a game provided by the server 3 according to the player's operation of the operation unit (buttons, etc.). For this purpose, the mobile terminal 2 includes a terminal communication section 21 , a terminal storage section 22 , an operation section 23 , a display section 24 and a terminal processing section 25 .

In this embodiment, a multifunctional mobile phone (so-called "smartphone") is assumed as the mobile terminal 2, but the present invention is not limited to this. The mobile terminal 2 may be a mobile phone (so-called "feature phone"), a mobile information terminal (Personal Digital Assistant, PDA), a mobile game machine, a mobile music player, a tablet PC, etc., as long as the present invention can be applied. good.

The terminal communication unit 21 includes a communication interface circuit including an antenna whose sensitive band is a predetermined frequency band, and connects the mobile terminal 2 to a wireless communication network. The terminal communication unit 21 establishes a radio signal line based on the CDMA (Code Division Multiple Access) method or the like with the base station 4 via a channel allocated by the base station 4 to perform communication. The terminal communication unit 21 transmits the data supplied from the terminal processing unit 25 to the server 3 or the like. Also, the terminal communication unit 21 supplies data received from the server 3 or the like to the terminal processing unit 25 .

The terminal storage unit 22 includes, for example, a semiconductor memory. The terminal storage unit 22 stores an operating system program, a driver program, an application program, data, etc. used for processing in the terminal processing unit 25 . For example, the terminal storage unit 22 stores, as driver programs, an input device driver program that controls the operation unit 23, an output device driver program that controls the display unit 24, and the like. The terminal storage unit 22 also stores, as application programs, a program for acquiring and displaying display data relating to a game provided by the server 3, and the like. The computer program can be stored in a computer-readable portable recording medium such as a CD-ROM (compact disk read only memory) or a DVD-ROM (digital versatile disk read only memory) using a known setup program or the like. 22 may be installed. The terminal storage unit 22 also stores, as data, display data, video data, image data, etc. related to the game received from the server 3 . Furthermore, the terminal storage unit 22 may temporarily store temporary data related to predetermined processing.

The operation unit 23 may be any device as long as it can operate the mobile terminal 2, such as a touch panel input device, a keypad, or the like. The player can use the operation unit 23 to input characters, numbers, and the like. When operated by the player, the operation unit 23 generates a signal corresponding to the operation. The generated signal is supplied to the terminal processing section 25 as an instruction from the player.

The display unit 24 may be any device that can display video, images, and the like, such as a touch panel display device, a liquid crystal display, an organic EL (Electro-Luminescence) display, and the like. The display unit 24 displays a video corresponding to the video data supplied from the terminal processing unit 25, an image corresponding to the image data, and the like.

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

(2.1.1) Configuration of Terminal Processing Unit 25 The terminal processing unit 25 includes at least a browsing execution unit 251 . The browsing execution unit 251 is a functional module implemented by a program executed by a processor included in the terminal processing unit 25 . Alternatively, the browsing execution unit 251 may be implemented in the mobile terminal 2 as firmware.

The viewing execution unit 251 executes a game provided by the server 3 in accordance with an instruction from the player using the operation unit 23 . The browsing execution unit 251 receives a game start instruction from the player using the operation unit 23, further receives a player ID and password from the player using the operation unit 23, and issues a game start request including the received player ID and password. It transmits to the server 3 via the terminal communication unit 21 . Note that the player ID and password may be stored in the terminal storage unit 22 in advance, and the viewing execution unit 251 may acquire the player ID and password by reading them from the terminal storage unit 22 . When the server 3 succeeds in the authentication process using the player ID and password, the server 3 transmits home screen display data for displaying a home screen, which will be described later, to the portable terminal 2 .

Upon receiving the home screen display data from the server 3 via the terminal communication unit 21, the browsing execution unit 251 creates drawing data based on the received display data. That is, the viewing execution unit 251 analyzes the received display data to specify control data and content data, lays out the specified content data according to the specified control data, and creates drawing data. The viewing execution unit 251 then outputs the created drawing data to the display unit 24 .

In addition, in response to an instruction from the player using the operation unit 23, the browsing execution unit 251 sends a game progress request including the request type according to the instruction and the player ID of the player via the terminal communication unit 21. Send to server 3. The request type specifies one of the following: a request to acquire display data for various screens such as home screen display data, an automatic recovery setting request for setting automatic recovery of battle points, a battle execution request, etc. be done. The viewing execution unit 251 receives corresponding display data from the server 3 via the terminal communication unit 21 as a response to the game progress request, creates drawing data corresponding to the received display data, and outputs the drawing data to the display unit 24 . .

(2.2) Configuration of Server 3 FIG. 3 is a diagram showing an example of a schematic configuration of the server 3. As shown in FIG.

The server 3 is an example of a computer that executes games. In response to a request from the mobile terminal 2, the server 3 provides games for executing battles, and consumes and recovers battle points. Also, the server 3 creates display data in response to a request from the mobile terminal 2 and transmits the display data to the mobile terminal 2 . For this purpose, the server 3 includes a server communication section 31 , a server storage section 32 and a server processing section 33 .

The server communication unit 31 includes a wired communication interface circuit such as Ethernet (registered trademark) for connecting the server 3 to the Internet 7 and communicates with the Internet 7 . Then, the server communication section 31 supplies the data received from the portable terminal 2 or the like to the server processing section 33 . The server communication unit 31 also transmits data supplied from the server processing unit 33 to the mobile terminal 2 and the like.

The server storage unit 32 includes, for example, at least one of a semiconductor memory, a magnetic tape device, a magnetic disk device, or an optical disk device. The server storage unit 32 stores an operating system program, a driver program, an application program, data, etc. used for processing in the server processing unit 33 . For example, the server storage unit 32 stores, as an application program, a game program for executing a battle, consuming and recovering battle points, and creating display data related to the result. The computer program may be installed in the terminal storage unit 22 from a computer-readable portable recording medium such as CD-ROM, DVD-ROM, etc. using a known setup program or the like. The server storage unit 32 also stores, as data, a player management table (FIG. 4(a)) for managing players, a card management table (FIG. 4(b)) for managing cards, and the like. Furthermore, the server storage unit 32 may temporarily store temporary data related to predetermined processing.

FIG. 4A is a diagram showing an example of the data structure of a player management table that manages players. The player management table includes, for each player, the player's player ID, password, name, image data file name, group ID of the group to which the player belongs, card ID of the card used by the player in battle, the player's Stores the battle points possessed by, automatic recovery settings for whether or not to automatically recover battle points, information on recovery items and recovery points for recovering battle points, and the number of automatic recovery times performed. . A group to which a player belongs is, for example, a team formed by a plurality of players in an event such as a so-called RAID battle, in which information is shared using the message transmission and reception function in the game, and a specific cooperative relationship has been established. A group of players. Battle points are an example of owned points owned by a player. Valid or invalid is stored as the automatic recovery setting. As information about the recovery item, the item name, the number of possessions, the number of automatically usable items, the number of uses, etc. of the recovery item are stored in association with each type of recovery item. As information on recovery points, owned values, automatically usable values, used values, and the like are stored. The recovery points are, for example, in-game currency, and the player can acquire recovery items by consuming the recovery points.

FIG. 4B is a diagram showing an example of the data structure of a card management table for managing cards. The card management table stores the card ID, name, file name of image data, number of points consumed, attack power, vitality, etc. of the card of each character. The number of consumption points is the number of points required to execute one battle using the card, and indicates a predetermined number of points consumed from battle points each time a battle is executed.

The server processing unit 33 includes one or more processors and their peripheral circuits. The server processing unit 33 controls overall operations of the server 3, and is, for example, a CPU. The server processing unit 33 controls operations of the server communication unit 31 and the like so that various processes of the server 3 are executed according to appropriate procedures according to programs and the like stored in the server storage unit 32 . The server processing unit 33 executes processing based on programs (operating system program, driver program, application program, etc.) stored in the server storage unit 32 . Also, the server processing unit 33 can execute a plurality of programs (application programs, etc.) in parallel.

(2.2.1) Functions of Server Processing Unit 33

FIGS. 5(a) to (d), FIGS. 6(a) to (d), and FIGS. 7(a) to (c) show examples of display screens of the mobile terminal 2 based on display data created by the server 3. FIG. 4 is a diagram showing;

FIG. 5(a) shows a home screen 500 displayed when the game is started. On the home screen 500, a notice 501 regarding the game, a "game selection" button 502, a "battle point automatic recovery setting" button 503, and the like are displayed. When the "game selection" button 502 is tapped, a game selection screen for selecting a game to be executed is displayed, and when the "battle point automatic recovery setting" button 503 is tapped, battle point automatic recovery setting is performed. The battle point automatic recovery setting screen for is displayed.

FIG. 5B shows an automatic battle point recovery setting screen 510 . On the battle point automatic recovery setting screen 510, an image 511 of a character card set to be used in battle by the player, an attack power 512, a vitality 513, a consumption point number 514, and a number of points currently owned by the player are displayed. Battle points 515 and the like are displayed. In the present embodiment, an example in which a battle is performed using one card will be described for ease of explanation, but the battle may be performed using a deck made up of a plurality of cards. In that case, the battle point automatic recovery setting screen 510 displays information about all the cards that make up the deck, and the total number of points consumed by all the cards is required to perform one battle. is displayed as the number of points.

The battle point automatic recovery setting screen 510 further includes an input field 516 for specifying whether or not to automatically recover battle points, and an input field for specifying the number of recoverable items that can be automatically used when automatically recovering. 517, an input field 518 and the like for specifying a value that can be used automatically for the recovery point is displayed. In the input field 517 for the number of recovery items that can be automatically used, the currently set number of automatically available recovery items is set as an initial value, and numbers up to the current owned number are displayed in a selectable manner for each type of recovery item. be. In the input field 518 of the automatically usable value of the recovery point, the currently set automatic usable value is set as the initial value, and the numbers up to the current possessed value are displayed in a selectable manner. The player can use the input field 517 to set the type and number of recovery items that can be automatically used. Note that the setting of the types of automatically usable recovery items may be omitted in the input field 517, and the number of automatically usable recovery items may be commonly set for all types of recovery items. Further, the setting of the number of automatically usable recovery items may be omitted in the input field 517, and all of the automatically usable recovery items owned by the player may be made automatically available. Further, when the display of the input fields 517 and/or 518 is omitted and the battle points are automatically recovered, all recovery items and/or all recovery points owned by the player may be automatically usable.

The automatic battle point recovery setting screen 510 further displays a "set" button 519, a "return" button 520, a "select opponent" button 521, and the like. When the "Set" button 519 is tapped, the items specified in the input fields 516 to 518 are set in the server 3, and the battle point automatic recovery setting screen is displayed again. When the "return" button 520 is tapped, the home screen is displayed again. When the "select opponent" button 521 is tapped, an opponent selection screen (not shown) for selecting an opponent is displayed. The opponent selection screen displays a list of opponents with which the player can compete, and the player can select an opponent from the opponent selection screen. Also, a battle may be executed from this opponent selection screen. Also, the number of points required for executing a single battle may be determined according to the opponent rather than the card of the character set to be used in the battle.

As for the automatically usable recovery items, the recovery items themselves may be selectable instead of the types and number of automatically available recovery items. In that case, for example, an automatic recovery box may be used in which recovery items that can be used automatically are registered in advance.

An automatic recovery box setting screen 530 is shown in FIG. 5(c). The automatic recovery box setting screen 530 includes a list of recovery items owned by the player, a check box 531 for selecting each recovery item, a "select all" button 532 for selecting all recovery items, A "clear all" button 533 for canceling the selection of all recovery items is displayed. Also, on the automatic recovery box setting screen 530, a registration button 534 for registering the selected item in the automatic recovery box and a "return" button 535 are displayed. The player can select an automatically usable recovery item by checking the check box of the recovery item to be automatically enabled and tapping the registration button 534 . The server storage unit 32 stores, for each recovery item owned by the player, whether or not the recovery item can be automatically used. Whether automatic use is possible or not is updated. This makes it easier for the player to grasp all of the recovery items currently owned, and can appropriately determine which of the recovery items owned by the player should be automatically enabled.

FIG. 5(d) shows a home screen 540 that is displayed when the automatic recovery setting is enabled. On the home screen 540, a "battle point automatic recovery setting" button 541 indicates that automatic recovery is set and the number of recovery items to be automatically used is displayed for each type of recovery item.

FIG. 6(a) shows a game selection screen 600. FIG. The game selection screen 600 displays a "battle" button 601, a "quest" button 602, a "card" button 603, a "my page" button 604, a "shop" button 605, and the like. When the "Battle" button 601 is tapped, a battle is selected as the game to be executed, and a battle start screen for starting the battle is displayed. When the "quest" button 602 is tapped, a quest is selected as the game to be executed, and a quest start screen (not shown) for starting the quest is displayed. When the "card" button 603 is tapped, a card setting screen (not shown) for making settings related to the card owned by the player is displayed. When the "My Page" button 604 is tapped, a My Page screen (not shown) for performing various settings and the like is displayed. When the "Shop" button 605 is tapped, a shop screen (not shown) is displayed for obtaining items and the like using in-game currency.

A battle start screen 610 is shown in FIG. 6(b). The battle start screen 610 includes a "character selection" button 611 for selecting a character card to be used in battle, an image 612 of the selected card, attack power 613, vitality 614, number of points consumed 615, and information about the player's current status. The battle points 616 or the like owned by the player are displayed. Also, on the battle start screen 610, there is a "select opponent" button 617 similar to the "select opponent" button 521 in FIG. A similar "auto-recovery settings" button 618 is displayed. Furthermore, on the battle start screen 610, a “battle execution” button 619 and a “return” button 620 are displayed. When the "character selection" button 621 is tapped, a character selection screen (not shown) is displayed. The character selection screen displays a list of character cards that can be used in battle, and the player can select a character card to be used in battle from the character selection screen. When the "execute battle" button 619 is tapped, a battle execution screen showing the results of the battle is displayed. When the "return" button 620 is tapped, the game selection screen 600 is displayed again.

FIGS. 6C and 6D show a battle execution screen 630 and a battle result screen 640, respectively. The battle execution screen 630 is a screen displayed immediately after the "execute battle" button 619 is tapped, and the battle result screen 640 is a screen displayed when the battle ends. On the battle execution screen 630 and the battle result screen 640, the card 631 of the player executing the game and its vitality 632 are displayed, and the opponent's card 633 and its vitality 634 are displayed. In the battle, the amount of damage to be given to the opponent's cards is determined based on the attack power of the player's cards, and the determined amount of damage is subtracted from the vitality of the opponent's cards. On the other hand, the amount of damage to be given to the player's card is determined based on the attack power of the opponent's card, and the determined amount of damage is subtracted from the vitality of the player's card. If the vitality of the opponent's card becomes 0 first, the player wins, and if the vitality of the player's card becomes 0 first, the player loses. On the battle result screen 640, a battle effect image showing the change in vitality of the player's card and the opponent's card is displayed by animation or the like, and the result content (win/lose) 641 is displayed. Also, a “return” button 636 is displayed on the battle execution screen 630 and the battle result screen 640 . When the "return" button 636 is tapped, the battle start screen is displayed again.

FIG. 7(a) shows a battle start screen 700 displayed after the battle is executed. On the battle start screen 700, the value of the battle points 626 is the value (10) displayed on the battle start screen 610 of FIG. (0).

When the automatic recovery setting is enabled, when the "execute battle" button 629 is tapped on the battle start screen 700 of FIG. is restored to , and the battle is executed again.

FIG. 7(b) shows a battle start screen 710 displayed after execution of the battle in this case. On the battle start screen 710, the value of battle points 626 is recovered from the value (0) displayed on the battle start screen 700 of FIG. (10) is changed to the subtracted value (40). Furthermore, the battle start screen 710 displays 711 that automatic recovery has been performed. The display of the battle start screen 710 may be omitted, and the battle execution screen may be displayed after the battle start screen 700 .

On the other hand, when the automatic recovery setting is disabled, when the "execute battle" button 629 is tapped on the battle start screen 700 of FIG. A screen appears.

FIG. 7(c) shows a battle result screen 720 indicating that the battle points are insufficient. The battle result screen 720 includes a message 721 that the battle points are insufficient, a time 722 until the battle points are recovered, a "recovery item acquisition" button 723 for acquiring recovery items using the recovery points, A “use recovery item” button 724, an “auto recovery setting” button 725, and a “return” button 726 for using recovery items owned by the player are displayed. When the "acquire recovery item" button 723 is tapped, a shop screen for acquiring recovery items using recovery points is displayed. When the "use recovery items" button 724 is tapped, a screen for using recovery items owned by the player is displayed. can be specified. When the "automatic recovery setting" button 725 is tapped, an automatic recovery setting screen for battle points is displayed. When the "return" button 726 is tapped, the battle start screen is displayed again. On the battle result screen 720, the player selects whether to wait until the time 722 elapses, use the recovery items owned by the player, acquire recovery items using recovery points, or set automatic recovery. can do.

(2.2.2) Configuration of Server Processing Unit 33 In order to realize the above functions, the server processing unit 33 includes a control unit 331, a game start unit 332, and a game controller 332, as shown in FIG. A progression unit 333 , a display data creation unit 334 , an automatic recovery setting unit 335 , an event execution unit 336 , an automatic recovery unit 337 , and a privilege provision unit 338 are provided. Each of these units is a functional module implemented by a program executed by a processor included in the server processing unit 33 . Alternatively, each of these units may be implemented in the server 3 as firmware.

Processing by the control unit 331 will be described below. The control unit 331 controls the progress of the game, and appropriately instructs the game starting unit 332, the game progressing unit 333, and the like to execute processing.

Upon receiving a game start request from the mobile terminal 2 via the server communication unit 31, the control unit 331 transmits the player ID and password included in the received game start request to a player authentication unit (not shown), and performs authentication processing. Instruct execution.

When the authentication by the player authentication unit is successful, the control unit 331 passes the player ID to the game start unit 332 and instructs execution of game start processing. Also, the control unit 331 transmits the home screen display data received from the game start unit 332 to the mobile terminal 2 via the server communication unit 31 .

On the other hand, when the control unit 331 receives a game progress request from the mobile terminal 2 via the server communication unit 31, the control unit 331 passes the received game progress request to the game progress unit 333 and instructs execution of game progress processing. Also, the control unit 331 transmits various display data received from the game progression unit 333 to the mobile terminal 2 via the server communication unit 31 .

The game starter 332 creates home screen display data for displaying buttons for receiving various instructions (game start, automatic recovery setting, display data creation, etc.). The game start unit 332 then passes the created home screen display data to the control unit 331 .

Processing by the game progression unit 333 will be described below. The game progress section 333 progresses the game in response to the game progress request, and creates various display data for displaying information according to the progress results. Then, the game progress section 333 passes the created display data to the control section 331 .

The game progress unit 333 identifies the request of the mobile terminal 2 from the request type included in the game progress request received from the control unit 331 .

When the identified request is a request to acquire home screen display data, the game progress unit 333 passes the player ID included in the game progress request to the game start unit 332 and instructs the game start unit 332 to generate home screen display data. In this case, the game starting unit 332 identifies the player corresponding to the player ID received from the game progressing unit 333 . Also, the game starting unit 332 passes the created home screen display data to the game progressing unit 333 .

If the specified request is a request to acquire each screen display data other than the home screen, the game progression unit 333 passes the player ID included in the game progression request to the display data generation unit 334, and generates each screen display data. to direct.

If the specified request is a battle point automatic recovery setting request, the game progress unit 333 passes the player ID included in the game progress request and each setting included in the automatic recovery setting request to the automatic recovery setting unit 335. , directs the setting of the automatic recovery of Battle Points.

When the identified request is a battle execution request, the game progression section 333 passes the player ID included in the game progression request to the event execution section 336 and instructs the event execution section 336 to execute the battle.

The game progression unit 333 passes display data received from the game start unit 332 , the display data creation unit 334 , the automatic recovery setting unit 335 , or the event execution unit 336 to the control unit 331 .

Processing by the display data creation unit 334 will be described below. The display data creation unit 334 creates display data for displaying each screen, and passes it to the game progression unit 333 .

The display data creation unit 334 generates a game selection screen, a battle point automatic recovery setting screen, an opponent selection screen, a battle start screen, a quest start screen, a card setting screen, a My Page screen, a shop screen, and a character selection screen from the game progress unit 333. Receive instructions to create display data such as The display data creation unit 334 refers to the player management table stored in the server storage unit 32, identifies the player corresponding to the player ID received from the game progression unit 333, and displays each screen corresponding to the identified player. Create display data.

When creating the display data for the battle point automatic recovery setting screen, the display data creating unit 334 refers to the player management table and collects the card ID of the card used in the battle, the battle points, the item name of the recovery item, the number of possessions, and the automatic recovery setting screen. Extract the number of available, own value of recovery point and auto-available value, etc. Furthermore, the display data creation unit 334 refers to the card management table stored in the server storage unit 32, and calculates the name of the card corresponding to the card ID extracted from the player management table, the file name of the image data, the number of points consumed, Extract attack power and vitality. Next, the display data creation unit 334 creates the battle point automatic recovery setting screen display data for displaying the extracted information, the "setting" button, the "return" button, the "opponent selection" button, etc. in a predetermined layout. It is created and passed to the game progression section 333 . When creating the display data for the battle start screen, the display data creating unit 334 similarly extracts the information of the cards used in the battle from the card management table and creates the display data for the battle start screen.

Processing by the automatic recovery setting unit 335 will be described below. When the game progression unit 333 instructs the automatic recovery setting unit 335 to set the automatic recovery of battle points, the automatic recovery setting unit 335 receives various settings from the player and sets the automatic recovery of the battle points.

When instructed to set automatic recovery of battle points, the automatic recovery setting unit 335 refers to the player management table stored in the server storage unit 32 and selects the player corresponding to the player ID received from the game progress unit 333. Identify. The automatic recovery setting unit 335 sets the automatic recovery setting of battle points, the number of automatically usable recovery items, and the number of automatic recovery points in the player management table according to each setting included in the automatic recovery setting request received from the game progression unit 333 . Set possible values. In addition, the automatic recovery setting unit 335 creates battle point automatic recovery setting screen display data in the same manner as the display data creation unit 334 and passes it to the game progress unit 333 so that the player can confirm the set contents.

Processing by the event execution unit 336 will be described below. The event execution unit 336 executes a battle when instructed to execute a battle by the game progression unit 333 .

When the execution of a battle is instructed, the event execution unit 336 refers to the player management table stored in the server storage unit 32 to determine the player corresponding to the player ID received from the game progression unit 333 and the player's current status. Identify battle points for Further, the event execution unit 336 extracts the card ID of the card used in the battle by the identified player, and extracts the attack power, vitality, points consumed, etc. corresponding to the extracted card ID from the card management table.

The event executing section 336 executes a battle on the condition that the current battle points are equal to or greater than the number of consumption points of the cards used in the battle. The event execution unit 336 determines the amount of damage to be given to the opponent's card based on the attack power of the player's card used in the battle, and subtracts the determined amount of damage from the vitality of the opponent's card. On the other hand, the event executing section 336 determines the amount of damage to be given to the player's card based on the attack power of the opponent's card, and subtracts the determined amount of damage from the vitality of the player's card. Then, the event execution unit 336 determines that the player has won when the vitality of the opponent's card becomes 0 first, and determines that the player has been defeated when the vitality of the player's card becomes 0 first. judge.

Further, when executing a battle, the event execution unit 336 subtracts the number of consumption points from the battle points in the player management table, thereby causing the number of consumption points to be consumed from the battle points. The event execution unit 336 also creates battle execution screen display data and battle result screen display data for displaying battle effect images and result contents, and passes them to the game progression unit 333 .

Processing by the automatic recovery unit 337 will be described below. The automatic recovery unit 337 automatically recovers battle points using recovery items when the event execution unit 336 determines that the battle points are less than the number of consumption points.

In the automatic recovery unit 337, the automatic recovery setting for battle points is valid in the player management table, and the number of automatically usable recovery items possessed is equal to or greater than the necessary number (for example, 1) for recovering the deficient battle points. and the number of used recovery items is equal to or less than the number that can be used automatically, recover battle points. The automatic recovery unit 337 recovers battle points by adding a value corresponding to the recovery amount or recovery rate determined for each recovery item to the battle points in the player management table. Note that the automatic recovery unit 337 may restore the battle points by updating the battle points in the player management table to the upper limit determined for each player. The automatic recovery unit 337 decrements (subtracts 1) the owned number of recovered items in the player management table and increments (adds 1) the used number. Furthermore, the automatic recovery unit 337 increments the number of automatic recoveries in the player management table. Note that, when a plurality of types of recovery items are set as recovery items that can be automatically used, the automatic recovery unit 337 performs recovery according to a predetermined priority order (in descending order or in descending order of recovery amount or recovery rate). Use items. This priority may be designated by the player.

On the other hand, the automatic recovery unit 337 does not automatically recover battle points even if the battle points are less than the number of points consumed, if the automatic recovery setting for battle points is disabled in the player management table. Also, if the number of recovery items used exceeds the number that can be automatically used, recovery items are not used and battle points are not automatically recovered. In these cases, the automatic recovery unit 337 creates battle result screen display data for displaying that the battle points are insufficient, and passes the data to the game progression unit 333 .

In addition, the automatic recovery unit 337 determines whether the owned number of recovery items is less than the required number, the owned value of the recovery points is less than the required value for acquiring the recovery items, or the used value of the recovery points is automatically restored. Do not use recovery points and do not automatically recover battle points if the available value is exceeded. On the other hand, the automatic recovery unit 337 exchanges the recovery points for recovery items when the possessed value of the recovery points is equal to or more than the required value and the used value of the recovery points is equal to or less than the automatically usable value. The automatic recovery unit 337 increases the owned number of recovery items in the player management table and subtracts the required value from the recovery points, thereby exchanging the recovery points for recovery items. Then, the automatic recovery unit 337 recovers battle points using the recovery item. Note that the automatic recovery unit 337 may directly recover battle points using the recovery points without exchanging the recovery points for recovery items.

Thus, the automatic recovery unit 337 uses only the number and/or types of recovery items that can be automatically used to automatically recover battle points. Also, the automatic recovery unit 337 uses only recovery points with values that can be automatically used to automatically recover battle points. As a result, even if the computer automatically recovers battle points, the player can feel that he or she is controlling the progress of the battle within a certain range.

The automatic recovery unit 337 may change the battle point recovery rate or recovery amount according to the number of battle point automatic recovery times. In this case, the automatic recovery unit 337 increases the battle point recovery rate or recovery amount as the number of battle point automatic recovery increases. Further, the automatic recovery unit 337 may change the number of consumption points to be consumed when a battle is executed, according to the number of times the battle points are automatically recovered. In this case, the automatic recovery unit 337 reduces the number of consumption points as the number of times of automatic recovery of battle points increases. Further, the automatic recovery unit 337 may set the recovery rate or recovery amount when the owned points are automatically recovered to be higher than when the owned points are recovered according to the instruction of the player. As a result, the automatic recovery of owned points becomes attractive to the player, and the usage rate of the automatic recovery function can be improved.

Also, other players related to the player are stored in the player management table, and the automatic recovery unit 337 links the battle points of the mutually related players to automatically recover the battle points of the specific player. Battle points of other players associated with the player may also be automatically restored when the player is defeated. For example, when automatically recovering the battle points of a specific player, the automatic recovery unit 337 automatically recovers the battle points of other players who belong to the same group as that player. In that case, the battle points of other players may be automatically recovered, for example, only when the automatic recovery of the battle points of a specific player is performed more than a predetermined number of times, or only when the player wins a prize by random number generation processing or the like. Also, the battle point recovery rate or recovery amount of other players may be less than the battle point recovery rate or recovery amount of a specific player. In addition, other players related to the player are not limited to other players belonging to the same belonging group as the player, other players who are friends with the player, or past battles with enemy characters or It may be another player or the like who rescued the player in the quest. As a result, it is possible to increase the willingness to build a cooperative relationship in the game.

Also, the automatic recovery unit 337 may set the number of times of automatic recovery (or its upper limit) according to the difficulty of the battle (the level of the opponent). In that case, the automatic recovery unit 337 sets the number of times of automatic recovery (or its upper limit) higher as the difficulty of the battle is higher. As a result, it is possible to set the number of automatic recovery times that is the same as the number of times the owned points become 0 before defeating the opponent. becomes possible.

In addition, when attributes such as level or rarity are set for the cards used in battle, the automatic recovery unit 337 sets the number of times of automatic recovery of battle points (or its upper limit) according to the attributes of the cards used in battle. May be set. In that case, the automatic recovery unit 337 sets the number of automatic recovery times (or its upper limit) higher as the level or rarity of the cards used in the battle is higher. As a result, the higher the level, the higher the player's level, the greater the number of times of automatic recovery, which makes it possible to motivate the player to improve his level. In addition, the automatic recovery unit 337 may determine the number of times of automatic recovery (or its upper limit) according to the number of logins of the player, the number of battle executions, the number of friends, and the like. In this case, the automatic recovery unit 337 sets the number of times of automatic recovery (or its upper limit) to be higher as the number of logins of the player, the number of battle executions, the number of friends, etc., increases. This makes it possible to increase the player's motivation to play the game, to participate in the battle, and to build a cooperative relationship in the game.

Processing by the privilege granting unit 338 will be described below. The privilege granting unit 338 grants a privilege to the player according to the number of times of automatic recovery of owned points.

When the automatic recovery unit 337 automatically recovers the owned points, the privilege granting unit 338 determines whether or not the number of automatic recoveries in the player management table is equal to or greater than a predetermined number. give perks. Note that the privilege granting unit 338 grants the player, for example, a card of a specific character, a recovery item, or the like as a privilege. The privilege granting unit 338 grants the player a higher privilege, for example, a higher level or higher rarity card or recovery item as the number of automatic recovery increases. As a result, the automatic recovery of owned points becomes attractive to the player, and the usage rate of the automatic recovery function can be improved.

(3) Operation of game system 1 FIG. 8 shows an example of an operation sequence of the game system 1 . Note that the operation sequence described below is based on programs stored in advance in the terminal storage unit 22 and the server storage unit 32, mainly by the terminal processing unit 25 and the server processing unit 33. Executed in cooperation with each element.

The player uses the operation unit 23 of the mobile terminal 2 to give an instruction to start the game. The viewing execution unit 251 receives a player ID and password from the player using the operation unit 23, and transmits a game start request including the received player ID and password to the server 3 via the terminal communication unit 21 (step S101).

Upon receiving a game start request from the mobile terminal 2 via the server communication unit 31, the control unit 331 of the server 3 transmits the player ID and password included in the received game start request to the player authentication unit, and executes authentication processing. (step S102).

When the authentication by the player authentication unit is successful, the control unit 331 passes the player ID to the game start unit 332 and instructs execution of game start processing. When the controller 331 instructs the game starter 332 to execute the game start process, the game starter 332 creates home screen display data and passes the created home screen display data to the controller 331 (step S103).

Next, the control unit 331 transmits the home screen display data received from the game start unit 332 to the mobile terminal 2 via the server communication unit 31 (step S104).

Upon receiving the home screen display data from the server 3 via the terminal communication unit 21, the browsing execution unit 251 creates drawing data based on the received home screen display data. The viewing execution unit 251 outputs the created drawing data to the display unit 24 to display the home screen (step S105).

Next, in response to an instruction from the player using the operation unit 23, the browsing execution unit 251 sends a game progress request including the request type corresponding to the instruction and the player ID of the player via the terminal communication unit 21. to the server 3 (step S106).

When the "Set" button 519 on the battle point automatic recovery setting screen 510 of FIG. 5B is tapped, the request type becomes a battle point automatic recovery setting request. This auto-recovery setting request includes the settings specified in the input fields 516-518. Also, when the "execute battle" button 619 on the battle start screen 610 of FIG. 6(b) is tapped, the request type is a battle execution request. 5(a) to (d), FIGS. 6(a) to (d), and FIGS. 7(a) to (c), when other buttons are tapped, the request type is an acquisition request for the display data of each corresponding screen.

Upon receiving a game progress request from the mobile terminal 2 via the server communication unit 31, the control unit 331 passes the received game progress request to the game progress unit 333 and instructs execution of game progress processing. The game progression section 333 executes the game progression process when instructed to execute the game progression process by the control section 331 (step S107). In the game progress processing, each part of the server processing unit 33 creates display data corresponding to the received game progress request, and the game progress unit 333 passes the created display data to the control unit 331 . Details of the game progress processing will be described later.

Next, the control section 331 transmits each display data received from the game progression section 333 to the portable terminal 2 via the server communication section 31 (step S108).

Upon receiving display data and the like from the server 3 via the terminal communication unit 21, the browsing execution unit 251 creates drawing data based on the received display data. Also, the browsing execution unit 251 outputs the created drawing data to the display unit 24 and displays the corresponding screen (step S109). After that, the processing of steps S106 to S109 is repeated.

FIG. 9 is a diagram showing an example of an operation flow of game progress processing by the game progress section 333. As shown in FIG. The game progress process shown in FIG. 9 is executed in step S107 of FIG.

First, the game progression unit 333 identifies the request of the mobile terminal 2 from the request type included in the game progression request received from the control unit 331 (step S201).

If the identified request is a battle point automatic recovery setting request (step S202-Yes), the game progression unit 333 instructs the automatic recovery setting unit 335 to set the automatic recovery of battle points, and the automatic recovery setting unit 335 executes automatic recovery setting processing (step S203). In the automatic recovery setting process, the automatic recovery setting unit 335 creates battle point automatic recovery setting screen display data, and passes it to the game progression unit 333 . Details of the automatic recovery setting process will be described later.

Next, the game progression unit 333 passes the battle point automatic recovery setting screen display data to the control unit 331 (step S209), and ends the series of steps.

On the other hand, if the request identified in step S201 is a battle execution request (step S202-No, step S204-Yes), the game progression unit 333 instructs the event execution unit 336 to execute a battle, and the event execution unit 336 executes a battle execution process (step S205). In the battle execution process, the event execution unit 336 creates battle execution screen display data and battle result screen display data, and passes them to the game progression unit 333 . The details of the battle execution process will be described later.

Next, the game progression unit 333 passes the battle execution screen display data and the battle result screen display data received from the event execution unit 336 to the control unit 331 (step S209), and ends the series of steps.

On the other hand, if the request identified in step S201 is a request to acquire home screen display data (step S204-No, step S206-Yes), the game progression unit 333 instructs the game start unit 332 to create home screen display data. do. The game starting unit 332 creates home screen display data and passes it to the game progressing unit 333 (step S207).

Next, the game progression unit 333 passes the home screen display data received from the game start unit 332 to the control unit 331 (step S209), and ends the series of steps.

On the other hand, if the request identified in step S201 is none of the above, that is, if it is a request to acquire display data of each screen other than the home screen display data (step S206-No), the game progression unit 333 creates display data. The unit 334 is instructed to create display data for each screen. The display data creation unit 334 creates display data for the instructed screen and passes it to the game progression unit 333 (step S208).

Next, the game progression unit 333 passes the received screen display data to the control unit 331 (step S209), and ends the series of steps.

FIG. 10 is a diagram showing an example of an operation flow of automatic recovery setting processing by the automatic recovery setting unit 335. As shown in FIG. The automatic recovery setting process shown in FIG. 10 is executed in step S203 of FIG.

First, the automatic recovery setting unit 335 sets the automatic recovery setting in the player management table according to the setting as to whether or not automatic recovery is to be performed, which is included in the automatic recovery setting request (step S301).

Next, the automatic recovery setting unit 335 sets the number of automatically usable recovery items for each automatically usable type in the player management table according to the setting of the automatically usable types and number of recovery items included in the automatic recovery setting request. is set (step S302).

Next, the automatic recovery setting unit 335 sets the automatically usable value of the recovery point in the player management table according to the setting of the automatically usable recovery point value included in the automatic recovery setting request (step S303).

Next, the automatic recovery setting unit 335 creates battle point automatic recovery setting screen display data, passes it to the game progression unit 333 (step S304), and ends the series of steps.

FIG. 11 is a diagram showing an example of an operation flow of battle execution processing by the event executing section 336, the automatic recovery section 337, and the privilege granting section 338. As shown in FIG. The battle execution process shown in FIG. 11 is executed in step S205 of FIG.

First, the event execution unit 336 determines whether or not the current battle points of the player of the mobile terminal 2 are equal to or greater than the number of consumption points of the card used in the battle (step S401).

If the battle points are equal to or greater than the number of consumed points (step S401-Yes), the event execution unit 336 shifts the process to step S412. On the other hand, if the battle points are less than the number of consumed points (step S401-No), the automatic recovery unit 337 determines whether the automatic recovery setting for battle points is valid (step S402).

If the automatic recovery setting for battle points is disabled (step S402-No), the automatic recovery unit 337 does not automatically recover battle points, and stores the battle result screen display data for displaying that the battle points are insufficient. It is created and passed to the game progression unit 333 (step S403), and the series of steps ends.

On the other hand, if the automatic recovery setting for battle points is enabled (step S402-Yes), the automatic recovery unit 337 determines that the number of automatically usable recovery items possessed is the necessary number to recover the deficient battle points. It is determined whether or not the above is satisfied (step S404).

If the number of automatically usable recovery items possessed is greater than or equal to the required number (step S404-Yes), the automatic recovery unit 337 determines whether the number of used recovery items exceeds the automatically usable number. Determine (step S405).

If the number of used recovery items is equal to or less than the number of items that can be used automatically (step S405-No), the automatic recovery unit 337 shifts the process to step S409. On the other hand, if the number of used recovery items exceeds the number that can be used automatically (step S405-Yes), the automatic recovery unit 337 does not automatically recover the battle points and displays that the battle points are insufficient. Battle result screen display data for the game is created and passed to the game progression unit 333 (step S403), and the series of steps ends.

On the other hand, if the number of owned recovery items of the type that can be used automatically is less than the required number (step S404-No), the automatic recovery unit 337 determines that the owned value of the recovery points is the required recovery item. It is determined whether or not it is equal to or greater than the required value (step S406).

If the possessed value of the recovery points is less than the required value (step S406-No), the automatic recovery unit 337 does not automatically recover the battle points, and displays battle result screen display data for displaying that the battle points are insufficient. is created and passed to the game progression unit 333 (step S403), and the series of steps ends.

On the other hand, if the possessed value of the recovery points is greater than or equal to the required value (step S406-Yes), the automatic recovery unit 337 determines whether the used value of the recovery points exceeds the automatically usable value (step S407). ).

If the used value of the recovery points exceeds the value that can be used automatically (step S407-Yes), the automatic recovery unit 337 does not automatically recover the battle points, and performs a battle to indicate that the battle points are insufficient. Result screen display data is created and passed to the game progression unit 333 (step S403).

On the other hand, if the used value of the recovery points is equal to or less than the automatically usable value (step S407-No), the automatic recovery unit 337 exchanges the recovery points for recovery items (step S408), and shifts the process to step S409. .

In step S409, the automatic recovery unit 337 recovers battle points (step S409).

Next, the privilege granting unit 338 determines whether or not the number of times of automatic recovery is equal to or greater than a predetermined number of times (step S410).

If the number of times of automatic recovery is less than the predetermined number of times (step S410-No), the privilege granting unit 338 does not perform any particular process, and moves the process to step S412. On the other hand, when the number of times of automatic recovery is equal to or greater than the predetermined number of times (step S410-Yes), the privilege granting unit 338 grants a privilege to the player (step S411), and the process proceeds to step S412.

In step S412, the event executing section 336 executes a battle (step S412).

Next, the event execution unit 336 consumes the number of consumption points from the battle points (step S413).

Next, the event execution unit 336 creates battle execution screen display data and battle result screen display data for displaying battle effect images and result contents, and transfers them to the game progress unit 333 (step S414). exit.

As described above, the server 3 automatically recovers the battle points using recovery points or recovery items owned by the player when the battle points become less than the predetermined value. As a result, it is possible to prevent the progress of the game from being interrupted and to keep the player's desire to continue playing the game.

In addition, the present invention is not limited to this embodiment. For example, in the present embodiment, an example in which the event of the game provided by the server 3 is a battle has been described, but the event may be a quest that progresses according to the scenario of the game. A quest is generally called a search, a mission, or the like, and is provided by a plurality of stages that are cleared by fighting, acquiring items, and the like. By executing quests, the player can grow a character and acquire benefits such as specific items.

In this case, the server storage unit 32 stores the card ID of the card to be used, information on quest points, which are owned points for executing the quest, automatic recovery settings, recovery items, and so on. and the number of times of automatic recovery are stored respectively. Information about recovery points is managed in common between battles and quests. On the home screen, a "quest point automatic recovery setting" button is displayed in the same way as the "battle point automatic recovery setting" button. When the "quest point automatic recovery setting" button is tapped, a quest point automatic recovery setting screen for setting automatic recovery of quest points similar to the battle point automatic recovery setting screen is displayed. When the execution of a quest is instructed from the quest start screen, the event execution unit 336 executes the quest on the condition that the quest points are equal to or greater than a predetermined value, and consumes a predetermined value from the quest points. The automatic recovery unit 337 automatically recovers quest points using recovery points or recovery items for quest points when the quest points become less than a predetermined value. Note that the predetermined value to be consumed is the number of consumption points of the card of the character used for the quest, as in the case of the battle. In addition, when the character card is not used for the quest, the predetermined value to be consumed may be set according to the difficulty of the quest. Alternatively, the predetermined value to be consumed may be a fixed value.

Also, when the game event includes both battles and quests, the automatic recovery unit 337 links the battle points and the quest points, and automatically recovers one of the battle points and the quest points. In some cases, the other's owned points may be automatically recovered. In that case, for example, only when the automatic recovery of one's owned points is performed more than a predetermined number of times, or only when a winning is made by random number generation processing or the like, the other's owned points may be automatically recovered. Also, the recovery rate or recovery amount of owned points on the side that recovers in conjunction may be smaller than the recovery rate or recovery amount of owned points on the side that recovers first. As a result, the automatic recovery of owned points becomes attractive to the player, and the usage rate of the automatic recovery function can be improved.

Also, in the present embodiment, the automatic recovery setting can be performed from both the home screen and the battle start screen, but either one may be omitted.

Also, in the present embodiment, the server 3 executes the game, but the server 3 may be omitted and the mobile terminal 2 may control the game. In that case, the terminal storage unit 22 stores information about the player of the portable terminal 2 and the card management table among the player management table, and the terminal processing unit 25 stores the server 3 in addition to each unit shown in FIG. has the same function as each part of the server processing part 33 of . The terminal processing unit 25 transmits and receives each information within the terminal processing unit 25 instead of transmitting and receiving each information via the terminal communication unit 21 and the server communication unit 31 .

It should be understood by those skilled in the art that various changes, substitutions and modifications can be made thereto without departing from the spirit and scope of the present invention.

2 mobile terminal 3 server 32 server storage unit 335 automatic recovery setting unit 336 event execution unit 337 automatic recovery unit 338 privilege giving unit

Claims (11)

A computer control method for executing an event in which a first game content is displayed in accordance with a player's instruction,
The computer
storing, in association with the player, points that decrease with the execution of the event and a plurality of types of second game media for increasing the points;
The automatically usable number of each type of second game content associated with the player is set by the player operating a screen on which the automatically usable number of each type of second game content can be set. remember the number,
automatically increasing the points by using the second game content of each type by a number equal to or less than the set automatically usable number when the points become less than a predetermined value;
A control method comprising: Receiving a setting by the player as to whether or not to automatically increase the points,
2. The control method according to claim 1, further comprising automatically increasing the points when automatic increase of the points is set in the increase of the points. each time the points are automatically incremented, storing the number of increments;
3. The point increment according to claim 1 or 2, wherein the point increment is not performed when the stored number of times has reached a predetermined number of times set according to the information on the first game medium. control method. 4. The control method according to claim 3, wherein a privilege is given to the player according to the stored number of times. 5. The control method according to claim 3, wherein the point increase rate or amount is changed according to the stored number of times. 6. The control method according to any one of claims 3 to 5, wherein a point value that decreases as the event is executed is changed according to the stored number of times. 7. The rate of increase or the amount of increase when the points are automatically increased is set to be greater than the rate of increase or the amount of increase when the points are increased according to instructions from the player. The control method described in . storing, for each player, other players associated with the player and the points owned by said other players;
The control method according to any one of claims 1 to 7, wherein points of other players related to the player are also recovered according to recovery of the points of the player. Other players related to the player are other players who belong to the same group as the player, other players who are friends with the player, or other players who have rescued the player in past battles or quests. The control method according to claim 8. A computer that executes an event in which a first game content is displayed according to a player's instruction,
a storage unit that stores, in association with the player, points that decrease with the execution of the event and a plurality of types of second game media for increasing the points;
The automatically usable number of each type of second game content associated with the player is set by the player operating a screen on which the automatically usable number of each type of second game content can be set. remember the number,
a processing unit configured to automatically increase the points by using the second game content of each type by a number equal to or less than the set number of automatically usable when the points become less than a predetermined value;
A computer comprising: A control program for a computer that executes an event in which a first game content is displayed according to a player's instruction,
to said computer;
storing, in association with the player, points that decrease with the execution of the event and a plurality of types of second game media for increasing the points;
The automatically usable number of each type of second game content associated with the player is set by the player operating a screen on which the automatically usable number of each type of second game content can be set. remember the number,
automatically increasing the points by using the second game content of each type by a number equal to or less than the set automatically usable number when the points become less than a predetermined value;
A control program for executing

Images