Program and game management device

Abstract

To provide a game that is highly interesting for players. [Solution] The program causes a computer to function as: game progress point consuming means for consuming game progress points necessary for game progress as the game progresses; first recovery means for recovering game progress points over time up to a first upper limit; second recovery means for recovering game progress points on condition that a first type of game element or a second type of game element is consumed; and providing means for providing a collection including a plurality of the second type of game elements. The second recovery means allows recovery of game progress points that exceed the first upper limit on condition that the first type of game element is consumed, and does not allow recovery of game progress points that exceed the first upper limit on condition that the second type of game element is consumed.

Description

[Technical field]

[0001] The present invention relates to a program and a game management device. [Background technology]

[0002] In recent years, games have become known that are configured so that a user can play each of a plurality of parts. When a game is configured so that a player can play each of the multiple parts, depending on the nature of the game or the settings of the game, the player may frequently play a particular part while seldom playing another part. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2013-146590 A Summary of the Invention [Problem to be solved by the invention]

[0004] In a game such as the one described above, making each part interesting for the player will increase the entertainment value of the game.

[0005] SUMMARY OF THE PRESENT EMBODIMENT An object of the present invention is to provide a program and a game management device that can provide a game that is highly entertaining to players. [Means for solving the problem]

[0006] One aspect of the present invention is a program that causes a computer to function as game progress point consumption means that consumes game progress points necessary for game progress as the game progresses, first recovery means that recovers game progress points over time up to a first upper limit value, second recovery means that recovers game progress points on condition that a first type of game element or a second type of game element is consumed, and providing means that provides a collection including a plurality of the second type of game elements, wherein the second recovery means allows recovery of game progress points that exceed the first upper limit value on condition that the first type of game element is consumed, and does not allow recovery of game progress points that exceed the first upper limit value on condition that the second type of game element is consumed.

[0007] One aspect of the present invention is a game management device comprising: a game progress point consumption means for consuming game progress points required for game progress as the game progresses; a first recovery means for recovering the game progress points over time up to a first upper limit value; a second recovery means for recovering the game progress points on condition that a first type of game element or a second type of game element is consumed; and a providing means for providing a collection including a plurality of the second type of game elements, wherein the second recovery means allows recovery of game progress points in excess of the first upper limit value on condition that the first type of game element is consumed, and does not allow recovery of game progress points in excess of the first upper limit value on condition that the second type of game element is consumed. Effect of the Invention

[0008] According to the present invention, a highly entertaining game can be provided. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 shows an example of a card in which a character is embodied. [Diagram 2] FIG. 2 is a diagram showing an example of a stone. [Diagram 3] FIG. 3 is a diagram for explaining the flow of one story. [Figure 4] FIG. 4 is a diagram showing an example of the overall configuration of a game system according to this embodiment. [Diagram 5] FIG. 5 is a diagram showing an example of the device configuration of a notebook computer, which is an example of the player terminal 1. As shown in FIG. [Figure 6] FIG. 6 is a block diagram showing an example of the functional configuration of the player terminal 1. As shown in FIG. [Figure 7] FIG. 7 is a diagram showing an example of the player information database D1. [Figure 8] FIG. 8 is a diagram showing an example of the game element information database D2. [Figure 9] FIG. 9 is a diagram showing an example of the owned card / stone information database D3. [Figure 10] FIG. 10 is a diagram showing an example of the deck database D4. [Figure 11] The figures from FIG. 11 onwards are diagrams for explaining the deck formation. [Figure 12] FIG. 12 is a diagram showing an example of the area selection screen. [Figure 13] FIG. 13 is an example of a support character selection screen. [Figure 14] FIG. 14 is a diagram showing an example of the stone selection screen. [Figure 15] FIG. 15 is an example of the behavior part home screen 61. [Figure 16] FIG. 16 is a diagram showing an example of transformation performance 1. [Figure 17] FIG. 17 is a diagram showing an example of transformation performance 2. [Figure 18] FIG. 18 is a diagram showing an example of a battle screen. [Figure 19] FIG. 19 is a diagram showing an example of a battle screen. [Figure 20] FIG. 20 is a diagram showing an example of a battle start screen. [Figure 21] FIG. 21 is a diagram showing an example of ending episode 1. [Figure 22] FIG. 22 is a diagram showing an example of ending episode 2. [Diagram 23] Figure 23 is an example of a results screen. [Figure 24] FIG. 24 is a block diagram showing an example of the functional configuration of the game server 2. [Diagram 25] FIG. 25 is an operational flowchart of the action part execution process executed by the action part execution control unit 104. [Figure 26] FIG. 26 is an operational flowchart of the transformation part execution process executed by the transformation part execution control section 105. [Figure 27] FIG. 27 is an operational flowchart of the battle part execution process executed by the battle part execution control unit 106. [Figure 28] FIG. 28 is an operational flowchart of the ending part execution process executed by the ending part execution control unit 106. [Figure 29] FIG. 29 is an operational flowchart of the result part execution process executed by the result part execution control unit 108. [Diagram 30] FIG. 30 is an example of a top home screen 60 for a game. [Diagram 31] FIG. 31 is a diagram showing an example of the store screen. [Diagram 32] FIG. 32 is a diagram showing an example of the provided card information database D10. [Diagram 33] FIG. 33 is a diagram showing an example of the player's owned currency information database D11. [Diagram 34] FIG. 34 is a flowchart showing the operation of the card provision process. [Diagram 35] FIG. 35 is a diagram for explaining the transition of the store purchase screen. [Diagram 36] FIG. 36 is a diagram for explaining the transition of the store screen displayed on the player terminal 1 when purchasing a card. [Figure 37] FIG. 37 is a flowchart showing the process of updating the number of times stored and provided. [Figure 38] FIG. 38 is a diagram showing an example of the provided information database D20 for steps 1 to 4. In FIG. [Figure 39]FIG. 39 is an example of a step-up offer screen. [Diagram 40] FIG. 40 is a block diagram of a player terminal 1 in the second embodiment. [Diagram 41] FIG. 41 is a block diagram of the game server 2 in the second embodiment. [Diagram 42] FIG. 42 is a diagram showing an example of the character level change screen 200. [Diagram 43] FIG. 43 is a diagram showing an example of the player's character information database D12. [Diagram 44] FIG. 44 is a flowchart showing the operation of the level change process. [Diagram 45] FIG. 45 is an example of a character level change screen displayed on the player terminal 1 after the level has been changed. [Figure 46] FIG. 46 is a diagram for explaining recovery of game progress points by consuming items. [Figure 47] FIG. 47 is a diagram showing an example of the game progress point recovery screen 210. As shown in FIG. [Figure 48] FIG. 48 is a flowchart showing the operation of the game progress point recovery process. [Figure 49] FIG. 49 shows an example of a notification screen after recovery when the current available game points are 75 points and three free recovery items have been consumed. [Figure 50] FIG. 50 shows an example of a notification screen after recovery when the current available game points are 75 points and 13 free recovery items have been consumed. [Figure 51] FIG. 51 is an example of a notification screen after recovery when the current available game progress points are 75 points and three paid currency units are consumed. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] <First embodiment> <Game Overview> In order to facilitate understanding of the game system in this embodiment, an overview of the game applied to this embodiment will be described.

[0011] First, the game elements that appear in this game will be described.

[0012] The game elements that appear in this game are classified into a first type of game element and a second type of game element.

[0013] The first type of game element is a character (person, etc.), which is represented by being embodied in an image, a virtual or real object, etc. An object is, for example, a virtual or real card.

[0014] There are three types of characters: first, second, and third. The first character is the main character who takes the lead role in the game. The second character is a sub-character who forms a group with the main character. The third character is a character that can be added using the friend function described below. The player selects the desired first, second, and third characters to form a group (deck).

[0015] The first character, second character, and third character each have multiple statuses. The types of statuses include the character's attributes, their attribute values, the character's support effect value, the character's intimacy with the player (referred to as intimacy), the character's skills (abilities), and other parameters.

[0016] The character's level increases as the game progresses. The character's attributes are characteristics that represent the character, such as colors such as red, blue, yellow, and green, and personalities such as bright and cool. In this embodiment, the character's attributes are colors, and the character is associated with two of the four colors red, blue, yellow, and green. That is, the character has two attributes. Hereinafter, the two attributes that the character has are referred to as the first attribute and the second attribute. The character's attribute value is a parameter that indicates the degree of the attribute. The character has attribute values ​​of four attributes (red, blue, yellow, and green). Each attribute value changes by performing an action described later. The character's support effect value is an ability value that the character exerts when it is a second character, and is an ability value that supports the action selected by the player, as described later, and the higher the ability value, the more advantageous the progress of the game. The character's intimacy is the intimacy between the player and the character, and increases by selecting a special action described later. As intimacy increases, the character's affectionate expressions towards the player in the game change, and the amount of information provided to the player increases, resulting in a good relationship between the player and the character. In addition, the player can progress in battles to an advantage, as described below. A character's skills are activated when certain conditions are met, and are effects that give the player an advantage in the game.

[0017] Figure 1 shows an example of a card in which a character has been transformed. In Figure 1, card X1 is an example of a card for a character with the attributes of "red" and "blue" and a level of 50, and card X2 is an example of a card for a character with the attributes of "yellow" and "green" and a level of 50.

[0018] The second type of game element is an item that is collected by the player and has an effect on the battle, etc. In this embodiment, this item is called a stone. The second type of game element (stone) has multiple status information. The types of status are attributes that are characteristics representative of the character, and parameters such as the attribute value, rank, and skill.

[0019] A stone's attribute is one of the attributes that represent a character's characteristics. In other words, it has one of four colors: red, blue, yellow, and green. A stone's attribute value is a parameter that indicates the degree of the attribute. Stones have four attribute values ​​(red, blue, yellow, and green). A stone's rank is a rank that indicates the strength of the stone. A stone's skills are skills that give advantages to actions, which will be described later.

[0020] Fig. 2 is a diagram showing an example of a stone. In Fig. 2, stone Y1 is a diagram showing an example of a stone with an attribute of "red" and a rank of "SS", and stone Y2 is a diagram showing an example of a stone with an attribute of "blue" and a rank of "SS". The character image of the stone is preferably an image of a transformed form of a character with similar status information.

[0021] Next, the flow of the game in this embodiment will be described. The game is made up of at least one story. Figure 3 is a diagram for explaining the flow of one story.

[0022] The story includes a deck formation part 10, an episode 11, an action part 12, a transformation part 13, a battle part 14, an ending part 15, and a result part 16.

[0023] Deck organization part 10 is the part where you organize a deck from the cards and stones you own. When organizing a deck, you select the main first character's card, the sub second character's card, and the third character's card using the friend function described below from the cards you own as character slots. You can select one card for the first character, two cards for the second character, and one card for the third character. However, you must select one card for the first character. You can also include up to four stones from the stones you own in your deck. You can also add one stone as a spare stone.

[0024] Episode 11 is a part where the character's episode is displayed and is not the target of the player's operation. Episode 11 is inserted between parts at appropriate times.

[0025] The action part 12 is the main part of the game, and is the target of operation by the player. The action part 12 includes a plurality of turns 20. The number of turns 20 in one action part 12 is predetermined. For example, one action part 12 is composed of six turns. The player can select one action for each turn 20. The types of actions are area investigation 21, request acceptance 22, and rest 23.

[0026] District Investigation 21 is the action of selecting one spot from those scattered in the district selected at the start of the story (game) and investigating the selected spot. Spots have one of several attributes. When the investigation of the spot is completed, the parameters of the characters in the deck will increase and investigation points will be awarded depending on the results of the District Investigation 21 investigation. The results of the District Investigation 21 investigation can be either success or failure, and if the investigation is successful, the parameters of the characters in the deck will increase and investigation points will be awarded. In particular, the rate of increase in the attribute value of the character's attribute that is the same as the spot's attribute will be high. The investigation points awarded are the points required to complete the action part and are accumulated.

[0027] The district investigation 21 is carried out by consuming motivation points, which are parameters that increase the success rate of the district investigation 21 and the request acceptance 22. The motivation points, which are parameters that increase the success rate, are assigned a maximum value at the start of the action part 12.

[0028] In the Request Orders 22, a player selects a specific request (mission) from the game management side, and by completing the request (mission), the parameters of the characters in the deck increase and research points are awarded and accumulated. In particular, many research points are awarded for completing the action part. The mission results of the Request Orders 22 can be success or failure, and if the mission result is successful, the parameters of the characters in the deck increase and research points are awarded. The Request Orders 22 are completed by consuming action points, which are parameters that increase the success rate.

[0029] Rest 23 is an action that recovers energy points, a parameter that increases the success rate. By choosing the Rest 23 action, the success rate of the district investigation increases.

[0030] Each turn 20, one of the above-mentioned area investigation 21, request acceptance 22, and rest 23 can be selected, and when the selected action is completed and the accumulated investigation points exceed a predetermined value, action part 12 can be completed.

[0031] When the accumulated research points exceed a predetermined value and action part 12 is completed, the game proceeds to transformation part 13. Transformation part 13 is a part that depicts the transformation of the first character, who is the main character. The first character transforms from the first character's normal appearance during action part 12 into a combat appearance. In addition, the transformation performance of the first character differs depending on the character's attribute values, etc., that have changed in action part 12.

[0032] The battle part 14 is a part where the first character transformed in the first type of game element battles against a non-player character prepared by the game operator. In the battle game, the outcome of the battle is determined by parameters such as the attribute values ​​of the stones in the deck and the intimacy of the characters.

[0033] The ending part 15 is a performance part that precedes the result part of the game. The performance performed in the ending part 15 differs depending on the attribute values ​​of the character that have changed in the action part 12.

[0034] When Ending Part 15 ends, a result screen is displayed showing the character parameters that have changed as a result of completing Action Part 12 and Battle Part 14, details of the stones that have been awarded, etc.

[0035] As described above, one of the features of the game of this embodiment is that a first type of game elements are used to discover various second type of game elements, and the discovered second type of game elements have a significant impact on the battle using the first type of game.

[0036] Another feature is that the presentation of the subsequent transformation part 13 and ending episode 15 will differ depending on the result of the action part 12 using the first type of game element.

[0037] Next, the configuration of this embodiment will be described.

[0038] <Overall composition> Fig. 4 is a diagram showing an example of the overall configuration of a game system in this embodiment. As shown in Fig. 4, the game system includes a player terminal 1 provided for each of game players A and B, and a game server 2. The player terminal 1 and the game server 2 can be connected to a communication line N and can communicate with each other.

[0039] The communication line N means a communication path that allows data communication. In other words, the communication line N includes a dedicated line (dedicated cable) for direct connection, a LAN such as Ethernet (registered trademark), a telephone communication network, a cable network, the Internet, and other communication networks, regardless of whether the communication method is wired or wireless.

[0040] The player terminal 1 is a computer capable of executing a game program, and is connected to a communication line N via a wireless communication base station or the like, and can perform data communication with the game server 2. The player terminal 1 is, for example, a personal computer, a smartphone, a mobile phone, a portable game device, a stationary home game device, an arcade game device, a tablet computer, a controller for a stationary home game device, etc. Basically, there are multiple player terminals 1, and each is operated by a player.

[0041] The game server 2 is a server system including one or more server devices, storage devices, etc. The game server 2 provides various services for operating the game of this embodiment, and can manage data required for operating the game, and distribute game programs and data required for executing the game on the player terminals 1, etc.

[0042] Fig. 5 is a diagram showing an example of the device configuration of a notebook computer, which is an example of the player terminal 1. As shown in Fig. 5, the player terminal 1 includes a display 11 and a keyboard 12, which is an operating means. The player terminal 1 also includes a control board, a built-in battery, a power button, a volume control button, a speaker, etc., which are not shown.

[0043] The control board is equipped with various microprocessors such as a CPU, GPU, and DSP, various IC memories such as an ASIC, a VRAM, a RAM, and a ROM, and a wireless communication module for wireless communication with a mobile phone base station. The control board is also equipped with a so-called I / F circuit (interface circuit), such as a driver circuit for the touch operation panel 12. These elements mounted on the control board are electrically connected to each other via a bus circuit or the like, and are connected to enable reading and writing of data and sending and receiving of signals.

[0044] Next, the configuration of each device will be described.

[0045] <Configuration of Player Terminal 1> FIG. 6 is a block diagram showing an example of the functional configuration of the player terminal 1. As shown in FIG.

[0046] As shown in FIG. 6, the terminal 1 includes a display unit 51, an operation input unit 52, a sound output unit 53, a communication unit 54, a storage unit 55, and a processing unit 56.

[0047] The display unit 51 displays various game screens based on the input image signals. The function of the display unit 51 can be realized by a display device such as a flat panel display such as a liquid crystal display, a cathode ray tube (CRT), a projector, or a head-mounted display. In the example of the personal computer in FIG. 5, the display unit 51 corresponds to the display 3.

[0048] The operation input unit 52 allows the player to input various operations related to the game, and outputs an operation input signal corresponding to the operation input to the processing unit 56. The function of the operation input unit 52 can be realized by, for example, elements that are directly operated by the player's fingers, such as a keyboard, a mouse, a touch operation pad, a home button, a button switch, a joystick, or a trackball, as well as elements that detect movement or posture, such as an acceleration sensor, an angular velocity sensor, a tilt sensor, or a geomagnetic sensor. In the example of the personal computer in FIG. 5, the operation input unit 52 corresponds to the keyboard 4.

[0049] The sound output unit 53 is for outputting sound effects and the like relating to the game based on the input sound signal.

[0050] The communication unit 54 realizes communication by connecting to the communication line N. The function of the communication unit 54 can be realized by, for example, a wireless communication device, a modem, a TA (terminal adapter), a jack for a wired communication cable, a control circuit, and the like.

[0051] The storage unit 55 stores in advance or temporarily stores each time processing is performed programs for operating the player terminal 1 and implementing various functions of the player terminal 1, and data used during execution of these programs. The storage unit 55 can be realized by, for example, a RAM, a ROM, a solid state drive using IC memory such as a flash memory, a magnetic disk such as a hard disk, an optical disk such as a CD-ROM or a DVD, etc.

[0052] The storage unit 55 stores a system program and a game program. The system program is a program for realizing the basic functions of the player terminal 1 as a computer. The game program is a program for causing the processing unit 56 to perform the functions described below. This program is distributed from the game server 2 or another application distribution server, etc., when the player completes account registration. Furthermore, the storage unit 55 stores databases necessary for executing the game. In this embodiment, the storage unit 55 stores a player information database D1, a card information database D2, a possessed card / stone information database D3, and a deck database D4.

[0053] The player information database D1 is a database in which various information about players is stored. Fig. 7 is a diagram showing an example of the player information database D1. The player information database D1 includes a field for a player ID, a field for a player name, a field for a level, a field for a possessed card ID, a field for a possessed stone ID, a field for a setting deck, a field for story information, and a field for a last update date and time, and each piece of information is stored in association with each other.

[0054] The player ID field is a field in which identification information for identifying a player is recorded. The player name field is a field in which, for example, a nickname is recorded. The level field is a field in which the player's level obtained by accumulating experience points is recorded. The owned card ID field is a field in which card identification information (card ID) of cards held by the player is recorded. The owned stone ID field is a field in which card identification information (card ID) of stones held by the player is recorded. The set deck field is a field in which the deck ID of the currently set deck is recorded. The story information field is a field in which story progress information is recorded. The last update date and time field is a field in which the last update date and time of the game element information database D2 is recorded.

[0055] The game element information database D2 is a database that stores information on game elements that appear or are used in a game. Fig. 8 is a diagram showing an example of the game element information database D2. The card information database D2 includes a card ID field, a character name field, a character information field, a basic character image field, a transformed character image field, a transformation performance field, an ending episode field, and a last update date and time field.

[0056] The card ID field is a field in which identification information (game card ID) that identifies the card is written. The character information field is a field in which character information (e.g., initial status information, etc.) of the character that has been transformed into the character is written. The basic character image field is a field in which an image of the character's normal appearance in the action part is written. The transformed character image field is a field in which an image of the character's appearance after transformation in the battle part, etc. is written. The transformation performance field is a field in which transformation performance 1 to transformation performance 3 are written. The ending episode field is a field in which ending episode 1 to ending episode 3 are written. The last update date and time field is a field in which the last update date and time of the game element information database D2 is written.

[0057] The owned card / stone information database D3 is a database of cards and stones owned by a player. FIG. 9 is a diagram showing an example of the owned card / stone information database D3. The owned card / stone information database D3 includes a field for the ID of the owned card or stone, and a field for its status information. The status information field describes the status information of the card or stone, such as its attributes, attribute values, rank, level, etc.

[0058] The deck database D4 is a database in which the contents of the deck organized by the player are recorded. Fig. 10 is a diagram showing an example of the deck database D4. The deck database D4 includes a deck ID field, a card ID field for the first character, a card ID field for the second character, a card ID field for the third character, a card ID field for the fourth character, and a stone ID field for the stone.

[0059] The Deck ID field is a field in which a deck ID that identifies a deck is recorded. The First Character Card ID field, the Second Character Card ID field, the Third Character Card ID field, and the Fourth Character Card ID field are fields in which the card ID of the first main character, the card IDs of the second and third sub characters, and the card ID of the fourth character rented from a friend are recorded. The Stone ID field is a field in which the stones and sub stone IDs to be included in the deck are recorded.

[0060] These databases can be downloaded by the game server 2 successively when characters used in the game are added or changed.

[0061] The processing unit 56 comprehensively controls the operation of the terminal 1 based on the programs and data stored in the memory unit 55, various input signals from the operation input unit 52, and the like. The functions of the processing unit 56 can be realized by electronic components such as a microprocessor such as a CPU or a GPU, an ASIC, and an IC memory. The processing unit 56 includes, as main functional units, a player information management unit 101, a game execution control unit 102, a deck organization unit 103, an action part execution control unit 104, a transformation part execution control unit 105, a battle part execution control unit 106, an ending episode execution control unit 107, a result part execution control unit 108, and a store presentation control unit 109.

[0062] The player information management unit 101 manages the information of the players using the player information database D1. When the information is updated, the player information management unit 101 updates the player information database D1 and records the update date.

[0063] The game execution control unit 102 controls and manages the progress of the entire game. For example, the game execution control unit 102 displays a menu screen such as a home screen, and executes a process selected by a player. Fig. 30 shows an example of a top home screen 60 of the game. The top home screen 60 includes story buttons for transitioning to various stories (action parts) of the game, and a store button for transitioning to a store.

[0064] The deck compilation unit 103 is a unit that compiles a deck from the owned cards and stones. Figures 11 and onward are diagrams for explaining deck compilation.

[0065] Deck organization unit 103 displays a deck organization screen. Fig. 11 shows a screen for selecting a first character to be the main character. Each character belongs to one of the teams based on attributes, etc., and by selecting a team, the card X of the character belonging to that team is displayed.

[0066] When the player selects a first character to be the main character, the deck organization unit 103 displays a district selection screen to select the district that the deck will be responsible for. Figure 12 is a diagram showing an example of the district selection screen. Two attributes, a first attribute and a second attribute, are associated with each district, and selecting the same attribute as the main character's attribute is advantageous for increasing various parameters.

[0067] When the region selection is completed, the deck organization unit 103 displays a support character selection screen for selecting a card of a second character that will be a sub character and a card of a third character using the friend function. Figure 13 is an example of a support character selection screen. The friend function is a function that allows the selection of a character owned by a player other than the player.

[0068] Finally, the deck organization unit 103 displays a stone selection screen for selecting stones. FIG. 14 is a diagram showing an example of the stone selection screen. The player selects the desired stone from the stones he owns. Once the stone is selected, the deck organization unit 103 writes the contents of the newly organized deck into the deck database D4, and the deck organization is completed.

[0069] The action part execution control unit 104 controls and executes the action parts in the story. The action part 12 includes a plurality of turns 20. The number of turns 20 in one action part 12 is predetermined, for example, six turns. The player can select one action for each turn 20. The types of actions are area investigation 21, request acceptance 22, and rest 23.

[0070] When the story button on the top home screen 60 is selected, the action part execution control unit 104 starts the action part and displays an action part home screen 61 for selecting an action. Fig. 15 is an example of the action part home screen 61. The action part home screen 61 in Fig. 15 displays selection buttons for selecting an area investigation 21, a request acceptance 22, and a rest 23, and the player can select any of the actions. In addition, the action part home screen 61 displays a first character.

[0071] When the district investigation 21 is selected, the action part execution control unit 104 presents spots scattered in the district selected at the start of the story (game) and develops an investigation story of one spot selected by the player. The spot has any attribute. By consuming the motivation points and completing the investigation of the spot, the action part execution control unit 104 increases the parameters of the characters in the deck and grants the investigation points. The action part execution control unit 104 accumulates the granted investigation points and displays them on the action part home screen 61 as the investigation points 24. Note that the purpose of the district investigation 21 is to increase the parameters such as the attribute values ​​of the characters that organize the deck, especially the first character, so the grant rate of the investigation points is set to be lower than that of the request acceptance 22. In addition, the action part home screen 61 displays the motivation points, which are the parameter 25 of the success rate, and the action part execution control unit 104 develops the investigation story by consuming the motivation points, which are the parameter of the success rate. In order to increase the motivation points, which are the parameter of the success rate, it is necessary to execute the rest 23.

[0072] When the request order 22 is selected, the action part execution control unit 104 presents the prepared mission to the player. By accomplishing the mission, the action part execution control unit 104 increases the parameters of the characters in the deck and grants research points. The action part execution control unit 104 accumulates the granted research points and displays them on the action part home screen 61 as accumulated points 24. Note that, since the purpose of the request order 22 is to accumulate research points for completing the action part, the increase rate of the parameters such as the attribute values ​​of the characters that organize the deck, especially the first character, is set low, and the grant rate of the research points is set high. In addition, the action part home screen 61 displays the action power points, which are the parameter 25 of the success rate, and the action part execution control unit 104 executes the mission by consuming the action power points, which are the parameter of the success rate.

[0073] When break 23 is selected, the action part execution control unit 104 executes a break performance in which the first character appears, such as a conversation story with the first character. Break 23 increases motivation points, which are a parameter 25 for the success rate of area investigation 21 and request acceptance 22, and also serves to increase intimacy with the first character. The motivation points to be restored are determined by lottery, i.e., a random function. The motivation points to be restored may be 0.

[0074] The player selects one of the above-mentioned area investigation 21, request acceptance 22, and rest 23 in one turn 20 and completes the selected action. The action part execution control unit 104 records the turn or story that the player has completed in the story information in the player information database D1. When the accumulated investigation points exceed a predetermined value, the action part execution control unit 104 completes the action part 12 and notifies the transformation part execution control unit 105 of the completion of the action part 12.

[0075] The transformation part execution control unit 105 executes the transformation part 13 after the action part 12 is completed. The transformation part 13 is a part that performs the transformation of the first character, who is the main character. The first character transforms from the first character's normal appearance during the action part 12 to an appearance for battle. The transformation performance of the first character differs depending on the attribute values ​​of the character that have changed by the action part 12.

[0076] The transformation part execution control unit 105 judges the first character of the deck, identifies the card ID of the first character, and identifies transformation performance 1 to transformation performance 3 associated with the card ID from the card information database D2. Transformation performance 1 is a transformation performance selected when the attribute value of the first attribute of the first character is larger than the attribute value of the second attribute. Transformation performance 2 is a transformation performance selected when the attribute value of the first attribute of the first character is smaller than the attribute value of the second attribute. Transformation performance 3 is a transformation performance selected when the attribute value of the first attribute of the first character is the same as the attribute value of the second attribute. FIG. 16 is a diagram showing an example of transformation performance 1, and FIG. 17 is a diagram showing an example of transformation performance 2. In the examples of FIG. 16 and FIG. 17, the background is different depending on the magnitude of the attribute value of the first attribute and the attribute value of the second attribute of the first character. The lines of the first character may also be changed. What is common to transformation performances 1 to 3 is that the appearance of the first character after transformation is a deformed appearance of the first character, unlike the normal appearance of the first character displayed in action part 12. For example, the appearance of the character after transformation is smaller than the normal appearance of the first character.

[0077] After completing the transformation part 13, the battle part execution control unit 106 executes a battle part 14 between the character organizing the deck and a non-player character. The outcome of the battle is determined by the magnitude of the fighting power calculated from the parameters of the stones in the deck and the intimacy of the first character. The first character appearing on the battle screen is the first character transformed in the transformation part 13, and the background may be different depending on the magnitude of the attribute value of the first attribute and the attribute value of the second attribute of the first character. Figs. 18 and 19 are diagrams showing an example of the battle screen.

[0078] When the battle part 14 is completed (for example, when the battle is won), the battle part execution control unit 106 writes information to the effect that the battle part 14 is completed in the story information of the player information database D1.

[0079] The battle part execution control unit 106 also has a skip function for the battle part 14. The skip function is a function that allows the player to skip the battle part 14 again when re-executing a story in which all parts have been completed. This skip function is used because, since the action part 12 allows the player to select a different action for each turn and is a part that places emphasis on character development, even if one story is completed, it is meaningful to execute the action part 12 of that story multiple times, whereas the battle part places emphasis on the battle, and once a victory has been achieved, it is less meaningful to execute the action part multiple times.

[0080] When starting the battle part, the battle part execution control unit 106 checks the story information in the player information database D1, and if the battle part 14 has been completed, displays a message on the battle start screen of the battle part 14 indicating that it can be skipped, and displays a battle skip button. FIG. 20 is a diagram showing an example of the battle start screen. When the battle skip button is selected, the battle part execution control unit 106 skips the battle part 14 without executing it, and notifies the ending part execution control unit 107 of the completion of the battle part 14. Note that the condition for skipping may be not only winning one battle, but also winning multiple battles.

[0081] Regarding the difference between the time of the action part 103 and the time of the battle part 14, the time of the action part 103 is longer because the battle part 104 is a simple battle as described above.

[0082] The ending part execution control unit 107 presents an ending episode in the ending part 15 after the end of the battle part 14. The ending episode differs depending on the magnitude relationship between the attribute value of the first attribute and the attribute value of the second attribute of the first character.

[0083] The ending part execution control unit 107 determines the first character of the deck, identifies the card ID of the first character, and identifies ending episodes 1 to 3 associated with the card ID from the card information database D2. The ending episode 1 is an ending episode selected when the attribute value of the first attribute of the first character is greater than the attribute value of the second attribute. The ending episode 2 is an ending episode selected when the attribute value of the first attribute of the first character is smaller than the attribute value of the second attribute. The ending episode 3 is an ending episode selected when the attribute value of the first attribute of the first character is the same as the attribute value of the second attribute. FIG. 21 is a diagram showing an example of the ending episode 1, and FIG. 22 is a diagram showing an example of the ending episode 2. In the examples of FIG. 21 and FIG. 22, the lines, characters, background, etc. differ depending on the magnitude of the attribute value of the first attribute and the attribute value of the second attribute of the first character.

[0084] The result part execution control unit 108 determines the rank of the stone to be given and displays the result screen. The rank of the stone to be given is determined by converting each attribute value of the first character into an evaluation point and adding up the evaluation points. The result part execution control unit 108 then determines the rank of the stone based on the total value of the evaluation points. The result part execution control unit 108 also determines the attribute of the stone to be given. The result part execution control unit 108 determines the attribute based on the magnitude relationship between the attribute value of the first attribute of the first character and the attribute value of the second attribute of the first character. If the attribute value of the first attribute is greater than the attribute value of the second attribute, the result part execution control unit 108 determines the attribute of the stone to be the first attribute. On the other hand, if the attribute value of the first attribute is less than the attribute value of the second attribute, the result part execution control unit 108 determines the attribute of the stone to be the second attribute. When the attribute value of the first attribute and the attribute value of the second attribute are the same value, either the first attribute or the second attribute is selected by lottery.

[0085] The result part execution control unit 108 displays a result screen of the story including information such as the rank and attributes of the stones to be given. Fig. 23 is an example of the result screen. In Fig. 23, the attribute value of the first character and information on the stones to be given are presented.

[0086] When the store button on the top home screen 60 is selected, the store display control unit 109 requests a store screen from the game server 2, and displays the store screen so that the purchase button for the card to be traded can be selected based on the received store screen information. Fig. 31 is a diagram showing an example of the store screen. The store screen in Fig. 31 includes an owned currency list 90, card purchase buttons 91, 92, and 93, and a rarity determination gauge 94.

[0087] The owned currency list 90 displays a list of currencies owned by the player. Currency is the price of cards, and in this embodiment includes card tickets, free currency, and paid currency. Card tickets and free currency are given free of charge by the game operator. There are multiple types of card tickets, including normal card tickets that allow one card to be acquired, and consecutive card tickets that allow ten cards to be acquired in succession. Free currency can be used in units of one, and can be used to acquire cards, other items, etc. Paid currency can be acquired in exchange for money, and like free currency, can be used in units of one, and can be used to acquire cards, other items, etc.

[0088] The card purchase button 91 is a button that allows a card to be obtained at a price lower than the normal card price, limited to once a day. However, the currency that can be used is limited to paid currency. In this embodiment, 100 units of currency are required to obtain one card, but by selecting the once-a-day limited card button 91, it is possible to obtain one card for 50 units of currency. Once the once-a-day limited card button 91 is selected and an exchange for a card is performed, it cannot be used until the next day. Note that one day is just an example, and other predetermined periods such as three days or one week may be used.

[0089] The card purchase button 92 can consume currency to acquire one card. The currency that can be used is any of card tickets, free currency, and paid currency.

[0090] The card purchase button 93 allows the user to consume currency to acquire 10 cards. Any of the following currencies can be used: card tickets, free currency, and paid currency. The advantage of purchasing 10 cards in succession is that it increases the probability of acquiring a rare card, as described below. When purchasing a card using any of the card purchase buttons 91, 92, and 93, the rarity of the card is determined by a drawing by the game device 1 or the game server 2, and a card of that rarity is awarded. The probability of winning a card with a higher rarity is lower.

[0091] The rarity determination gauge 94 is a gauge that indicates the number of cards provided to the player (the number of times the player has acquired cards), and increases by one every time a card is acquired. In this embodiment, the system is such that if a player acquires 100 cards, one card with high rarity is always given to the player.

[0092] In this embodiment, the priority order of currency to be consumed when purchasing a card is determined in advance. In this embodiment, the currency is consumed in the following order: card ticket, free currency, and paid currency.

[0093] <Game Server 2 Configuration> 24 is a block diagram showing an example of a functional configuration of the game server 2. The game server 2 includes a processing unit 70, a communication unit 71, and a storage unit 72.

[0094] The processing unit 70 comprehensively controls the operation of the game server 2 based on programs and data stored in the memory unit 72, received information, etc. The functions of the processing unit 70 can be realized by electronic components such as a microprocessor such as a CPU or GPU, an ASIC, an IC memory, etc. The processing unit 70 has the functions of a player information management unit 80, a game execution management unit 81, and a store management unit 82.

[0095] The player information management unit 80 manages information about players. The player information management unit 80 has a player information database D1, a possessed card / stone information database D3, and a deck database D4 for each player ID.

[0096] The player information management unit 80 compares the player ID, update information for each database, and last update date and time sent when the player terminal 1 logs in to the game with the contents of each database for the player ID stored on the game server 2 side, and if there is a match, it sends a message to that effect, but if there is a mismatch, it sends the contents of each database for the player ID stored on the game server 2 side, thereby synchronizing the contents of each database between the player terminal 1 and the game server 2.

[0097] The game execution management unit 81 manages the game. It mainly has a game element information database D2, and when the game elements are updated, it transmits the update information to the player terminal 1. Then, when logging in to the player terminal 1, etc., it synchronizes the contents of the game element database D2 between the player terminal 1 and the game server 2.

[0098] The store management unit 82 manages the stores that provide cards by using the provided card information database D10 and the player-owned currency information database D11. Fig. 32 is a diagram showing an example of the provided card information database D10, and Fig. 33 is a diagram showing an example of the player-owned currency information database D11. The provided card information database D10 includes a card ID field, a rarity information field, and a winning probability field. The card ID field is a field in which a card ID that identifies a card is recorded. The rarity information field is a field in which rarity information of the card is recorded, with the larger the numerical value, the higher the rarity. The winning probability field is a field in which the winning probability of the card is recorded, with the larger the numerical value, the higher the winning probability.

[0099] The player's owned currency information database D11 includes a field for a player ID, a field for free currency, a field for tickets, a field for paid currency, a field for purchase history information, and a field for the number of times that currency has been provided accumulated. The player ID field is a field in which the player's player ID is recorded. The free currency field is a field in which the number of pieces of free currency that the player owns is recorded. The ticket field is a field in which the number of pieces of free currency that the player owns is recorded. The paid currency field is a field in which the number of pieces of paid currency that the player owns is recorded. The purchase history information field is a field in which the player's card and currency purchase history is recorded. The accumulated number of times that currency has been provided accumulated field is a field in which the number of times cards have been provided to the player is recorded.

[0100] Upon receiving a request from the player terminal 1, the store management unit 82 refers to the provided card information database D10 and the player's owned currency information database D11, determines the card to be provided in exchange for the consumption of the currency, and transmits the card ID information.

[0101] The communication unit 71 connects to a communication line N to realize communication.

[0102] A system program and a game program are stored in the storage unit 72. The system program is a program for implementing the basic functions of the game server 2 as a computer. The game program is a program for causing the processing unit 70 to function as a player information management unit 80, a game execution management unit 81, and a store management unit 82.

[0103] Furthermore, the recording unit 72 stores information on players for each player ID in a player information database D1, a possessed card / stone information database D3, a deck database D4, a provided card information database D10, and a player possessed currency information database D11.

[0104] <Operation of Player Terminal 1> The operation of the player terminal 1 will now be described.

[0105] <Behavior Part 12 Actions> First, a description will be given of the operation of the action part execution control unit 104. Fig. 25 is an operational flowchart of the action part execution process executed by the action part execution control unit 104.

[0106] When the deck is organized and the player starts the game, the action part of a given story begins. As shown in Fig. 15, the action part execution control unit 104 presents each of the actions of area investigation 21, request acceptance 22, and rest 23 as selectable actions (Step 100). The player selects one of the presented actions.

[0107] When the area investigation 21 is selected (Step 101), the action part execution control unit 104 executes the area investigation 21 (Step 102). When the completion conditions for the area investigation 21 are met through the player's play (Step 103), the parameters of the first character in the deck are increased and investigation points are awarded to the player (Step 104). Note that in the case of the area investigation, it is preferable to increase the rate of increase of the first character's parameters and to award fewer investigation points, in order to balance with other actions.

[0108] When the request order 22 is selected (Step 105), the action part execution control unit 104 executes the request order 22 (Step 106). When the completion conditions for the request order 22 are met through the player's play (Step 107), the parameters of the first character in the deck are increased and research points are awarded to the player (Step 108). Note that in the case of the request order 22, it is preferable to reduce the rate of increase in the parameters of the first character and increase the amount of research points awarded, in order to achieve a balance with other actions.

[0109] When Break 23 is selected (Step 110), the action part execution control unit 104 executes Break 23 (Step 111). When the completion conditions for Break 23 are met through the player's play (Step 112), the parameters of the first character in the deck are increased, and the player is given action points (Step 113). In the case of Break 23, the rate of increase in intimacy level of the first character's parameters is increased.

[0110] As mentioned above, by varying the rate at which a character's parameters increase and the number of points awarded (research points, action points, etc.) for each action, it is important for the player to select each action in a balanced manner.

[0111] Next, the action part execution control unit 104 determines whether the action part 12 is completed (Step 109). The completion of the action part 12 is determined based on whether the player's accumulated investigation points exceed a predetermined value. When the player's accumulated investigation points exceed a predetermined value at the completion of a predetermined turn 20 (Step 114), the action part execution control unit 104 ends the action part 12, updates the story information, and transitions to the transformation part 13 (Step 115).

[0112] <Transformation Part 13 Actions> The operation of the transformation part execution control section 105 will be described below.

[0113] The transformation part execution control unit 105 determines the first character of the deck (Step 120). Then, the transformation part execution control unit 105 selects transformation performance 1 to transformation performance 3 associated with the first character (Step 121).

[0114] The transformation part execution control unit 105 determines whether the attribute value of the first attribute of the first character is greater than the attribute value of the second attribute of the first character (Step 122). If the attribute value of the first attribute is greater than the attribute value of the second attribute (Step 123), the transformation part execution control unit 105 selects transformation performance 1 (Step 124). If the attribute value of the first attribute is less than the attribute value of the second attribute (Step 125), the transformation part execution control unit 105 selects transformation performance 2 (Step 126). If the attribute value of the first attribute is the same as the attribute value of the second attribute (Step 130), the transformation part execution control unit 105 selects transformation performance 3 (Step 130).

[0115] The transformation part execution control unit 105 executes the selected transformation performance (Step 127). Next, the transformation part execution control unit 105 displays the first character's transformed appearance. The transformed appearance is a deformed version of the first character (Step 128). Then, the transformation part execution control unit 105 ends the transformation part 13, and transitions to the battle part 14 (Step 129).

[0116] <Match Part 14 Actions> The following describes the operation of the battle part execution control unit 106. FIG. 27 is a flowchart showing the operation of the battle part execution process executed by the battle part execution control unit 106.

[0117] The battle part execution control unit 106 judges whether to skip the battle part (Step 140). The battle part execution control unit 106 checks the story information in the player information database D1, and if the battle part 14 is completed (Step 141), it displays a message on the battle start screen of the battle part 14 that the battle part can be skipped, as shown in Fig. 20, and displays a battle skip button (Step 142). If the battle skip button is selected (Step 143), the battle part execution control unit 106 skips the battle part 14 and moves to the ending part 15 (Step 150).

[0118] On the other hand, if the battle skip button is not selected or if skipping is not possible, the battle part execution control unit 106 reads the parameters of the stones in the deck and the intimacy level of the first character (Step 144), and calculates the player's fighting power 1 (Step 145). The battle part execution control unit 106 calculates the fighting power 2 of the opposing player (non-player character) (Step 146). Then, the battle part execution control unit 106 determines the outcome of the battle (Step 147).

[0119] If the player's fighting power 1 is greater than the fighting power 2 of the opposing player (non-player character) (Step 148), the battle part execution control unit 106 determines that the player has won (Step 149). If the player's fighting power 1 is less than the fighting power 2 of the opposing player (non-player character) (Step 148), the battle part execution control unit 106 determines that the player has won (Step 151). Then, the battle part execution control unit 106 ends the battle part 14 and transitions to the ending part 15 (Step 150).

[0120] Regarding skipping the battle part, in the above explanation, the option to skip the battle is presented before the start of battle part 14, but this is not limited to this and the option may be presented at the start of the story.

[0121] <Ending Part 15 Actions> The following describes the operation of the ending part execution control unit 107. Fig. 28 is a flowchart showing the operation of the ending part execution process executed by the ending part execution control unit 106.

[0122] The ending part execution control unit 107 determines the first character of the deck (Step 160). Then, the ending part execution control unit 107 selects ending episode 1 to ending episode 3 associated with the first character (Step 161).

[0123] The ending part execution control unit 107 determines whether the attribute value of the first attribute of the first character is greater than the attribute value of the second attribute of the first character (Step 162). If the attribute value of the first attribute is greater than the attribute value of the second attribute (Step 163), the ending part execution control unit 107 selects ending episode 1 (Step 164). If the attribute value of the first attribute is less than the attribute value of the second attribute (Step 165), the ending part execution control unit 107 selects ending episode 2 (Step 167). If the attribute value of the first attribute is the same as the attribute value of the second attribute (Step 165), the ending part execution control unit 107 selects ending episode 3 (Step 168).

[0124] The ending part execution control unit 107 executes the selected ending episode (Step 168). Then, the ending part execution control unit 107 ends the ending part 15, and moves to the result part 16 (Step 169).

[0125] <Result Part 16 Operation> The following describes the operation of the result part execution control unit 108. FIG. 29 is a flowchart showing the operation of the result part execution process executed by the result part execution control unit 108.

[0126] The result part execution control unit 108 determines the rank of the stone to be awarded (Step 180). The result part execution control unit 108 converts each attribute value of the first character into an evaluation point (Step 181) and adds up the evaluation points (Step 182). Then, the result part execution control unit 108 determines the rank of the stone based on the total evaluation points (Step 183).

[0127] Next, the result part execution control unit 108 determines the attribute of the stone to be granted (Step 184). The result part execution control unit 108 determines whether the attribute value of the first attribute of the first character is greater than the attribute value of the second attribute of the first character (Step 184). If the attribute value of the first attribute is greater than the attribute value of the second attribute (Step 185), the result part execution control unit 108 determines the attribute of the stone to be the first attribute (Step 186). If the attribute value of the first attribute is less than the attribute value of the second attribute (Step 185), the result part execution control unit 108 determines the attribute of the stone to be the second attribute (Step 186).

[0128] The result part execution control unit 108 displays a story result screen including information such as the rank and attributes of the stones to be awarded (Step 187), and awards the stones to the player (Step 188).

[0129] <Card provision process> The card providing operation will now be described with reference to the flowchart of FIG.

[0130] When the store button is selected from the top home screen 60 in FIG. 30, the store presentation control unit 109 of the player terminal 1 transmits a request for store screen information (including the player ID) to the game server 2.

[0131] The store management unit 82 of the game server 2 receives a request from the player terminal 1, and refers to the player's owned currency information database D11 for the player ID, and acquires the tickets, free currency, paid currency, number of times accumulated and provided, and purchase history information owned by the player (Step 200). The store management unit 82 transmits store screen information including the acquired free currency, paid currency, number of times accumulated and provided, and purchase history information (Step 201).

[0132] When the store display control unit 109 of the player terminal 1 receives the store screen information (Step 203), it displays the store screen 61 as shown in Fig. 31 based on the free currency, paid currency, number of times accumulated and provided, and purchase history information included in the store screen information (Step 204). Fig. 35 is a diagram for explaining the transition of the store purchase screen. Fig. 35(a) is an example of the case where a one-day limited card has not been purchased.

[0133] When the player selects any one of the card purchase buttons 91, 92, or 93, the store display control unit 109 determines the currency required for provision (Step 206). Here, the order in which the currency is consumed is tickets, free currency, and paid currency. The store display control unit 109 determines the currency required to purchase the card of the selected card purchase button according to this order.

[0134] If the player has a ticket (Step 207), the store display control unit 109 notifies the player that the ticket will be consumed, and when the confirm button is selected, a purchase confirmation is transmitted to the game server 2. FIG. 35 is a diagram for explaining the transition of the store screen displayed on the player terminal 1 when purchasing a card. In the example of FIG. 35(a), the purchase card button 92 is selected. Then, after the purchase card button 92 is selected, the store display control unit 109 notifies the player that the ticket, which has the highest priority, will be consumed as the currency to be consumed (FIG. 35(b)).

[0135] The store management unit 82 of the game server 2 receives the purchase decision, consumes the ticket, and updates the ticket field in the player's owned currency information database D11 by the amount of the consumed ticket (Step 212).

[0136] On the other hand, if the player does not have a ticket (Step 209), the store display control unit 109 consumes the free currency with the second priority (Step 210) and determines whether the required currency is met (Step 211). If the required currency is not met (Step 211), the store display control unit 109 consumes the paid currency with the third priority (Step 220) and determines whether the required currency is met (Step 221). If the required currency is met, the store display control unit 109 notifies the player, and transmits a purchase decision to the game server 2 when the purchase decision button is selected. FIG. 36 is a diagram for explaining the transition of the store screen displayed on the player terminal 1 in card purchase. In the example of FIG. 36(a), the card purchase button 93 is selected. Then, after the card purchase button 93 is selected, the store display control unit 109 notifies the player that all the free currency with the high priority, which is the currency to be consumed, will be consumed and the shortage will be consumed from the paid currency (FIG. 36(b)).

[0137] The store management unit 82 of the game server 2 receives the purchase decision and updates the amount of free currency or paid currency consumed in the free or paid currency field of the player's owned currency information database D11 (Step 212).

[0138] Next, the store management unit 82 determines whether it is necessary to change the selection probability that determines the type of card to be provided (Step 213). If the player's accumulated number of times of providing is equal to or greater than a predetermined upper limit (Step 214), the store management unit 82 changes the selection probability of the card (Step 215). For example, the selection probability of the card listed in the provided card information database D10 is changed so that at least one card with the highest rarity is always selected. On the other hand, if the player's accumulated number of times of providing is not equal to or greater than a predetermined upper limit (Step 213), the store management unit 82 executes a card selection based on the selection probability in the provided card information database D10 (Step 216). Then, the store management unit 82 provides the selected card (Step 217).

[0139] Next, the store management unit 82 executes the update process of the accumulated provision count (Step 218). Fig. 37 is a flowchart of the update process of the accumulated provision count.

[0140] The store management unit 82 sets the accumulated provision count as N, the current provision count as n, and the upper limit as X (Step 230), and calculates the accumulated provision count N=(N+n) (Step 231). If (N+n) is equal to or greater than the upper limit X (Step 232), the store management unit 82 sets the accumulated provision count N to (NX) and updates the accumulated provision count of the player ID in the player-owned currency information database D11 to (NX) (Step 233). On the other hand, if (N+n) is less than the upper limit X (Step 232), the store management unit 82 sets the accumulated provision count N to (N+n) and updates the accumulated provision count of the player ID in the player-owned currency information database D11 to (N+n) (Step 234). This completes the process of updating the number of times stored and provided.

[0141] FIG. 35(c) and FIG. 36(c) are examples of store screens displayed on the player terminal 1 after the card is provided. FIG. 35(c) is an example of a store screen when a card is provided once by consuming a ticket, and the number of tickets in the owned currency list 90 is reduced by one to 0, and the number of times of provision (accumulated number of times of provision) in the rarity determination gauge 94 is increased by one, from 60 times to 61 times. On the other hand, FIG. 36(c) is an example of a store screen when a card is provided 10 times by consuming free currency and paid currency, and the free currency and paid currency in the owned currency list 90 are reduced by the amount consumed (free currency is reduced from 800 to 0, and paid currency is reduced from 1000 to 800). Furthermore, the number of times of provision (accumulated number of times of provision) in the rarity determination gauge 94 exceeds the upper limit of 100 times, so the gauge extends to the upper limit of 100 times (Max state). In addition, since the number of deliveries before the delivery (accumulated number of deliveries) was 95, the number of deliveries carried over, ie, 5 deliveries (=105-100), is displayed as the current number of deliveries (accumulated number of deliveries).

[0142] In this embodiment, a plurality of actions are prepared in the action part, and each action is configured to affect the status information of a first type of game element (character), and a different second type of game element (stone) can be obtained depending on the status information of the first type of game element (character). With such a configuration, the player can continue playing the game without getting bored, and a highly entertaining game can be provided.

[0143] Furthermore, since the form of the first type of game element (character) in the action part is different from the form of the first type of game element (character) in the battle part, the player will not get bored of the game, and a highly entertaining game can be provided.

[0144] Furthermore, the transformation effect that is executed when transitioning from the action part to the battle part is different depending on the result of the action in the action part, so the player does not get bored of the game and it is possible to provide a highly interesting game.Similarly, the ending episode of the ending part of the story is also different depending on the result of the action in the action part, so the player does not get bored of the game and it is possible to provide a highly interesting game.

[0145] This embodiment also has a skip function that allows a battle that has already been completed to be skipped, making it possible to repeatedly play the story without repeating the battle.

[0146] Furthermore, the store in this embodiment consumes the currency required for the card in the following order: tickets, free currency, and paid currency, so that the player can hold onto the valuable paid currency until the very end.

[0147] Furthermore, by giving the player the opportunity to acquire cards of high rarity depending on the number of times the cards are provided, the player's desire to purchase can be enhanced.

[0148] <Modification of Store Operation> The above-mentioned store has been described as a permanent operation. However, providing various cards and items for a limited time, or giving special advantages, is an important factor in maintaining the player's interest in the game and encouraging them to continue playing. Therefore, a modified method of providing items from the store will be described.

[0149] The modified example will now be outlined. The modified item provision method is carried out for a limited period of time. Here, items include cards and tickets and items that give an advantage in the progress of the game. The provision of items includes multiple steps (stages), and an achievement condition is set for each step. When the player achieves the achievement condition, the player can proceed to the next step. The items provided at each step, their rarity, and the probability of winning are disclosed to the user. The player checks the disclosed information for each step, provides the item, and obtains the item.

[0150] To execute the above-mentioned item providing method, the game server 2 has a provided information database for each step. Fig. 38 is a diagram showing an example of the provided information database D20 for steps 1 to 4. The provided information database D20 for each step includes a field for the step achievement condition, a field for item rarity information, a field for the provided item, and a field for the probability of winning the item. The step achievement condition, the type of item provided, and the probability of winning the item are different for each step.

[0151] When the store management unit 82 of the game server 2 receives a request to execute the step-up provision from the player terminal 1, the store management unit 82 reads information from the field for each step in the provision information database D20, and transmits the step-up provision information to the player terminal 1. When the store display control unit 109 of the player terminal 1 receives the step-up provision information, it displays a step-up provision screen. Fig. 39 shows an example of the step-up provision screen. The player can check the provision contents of each step by selecting the tab of the step.

[0152] By satisfying the conditions for each step, the player can receive the item for the next step. For example, the condition for step 1 is to obtain an item once using a ticket, and when that is achieved, the player can proceed to step 2.

[0153] The store management unit 82 of the game server 2 stores the purchase history in the player's purchase history information field of the player's owned currency information database D11 each time a step is provided, and when the step achievement condition is satisfied, makes it possible to provide the item for the next step. Note that when the last step is completed, it is also possible to return to the first step and repeat the provision of steps. Such a configuration can maintain the player's interest in the game and encourage him or her to continue playing the game.

[0154] <Modifications of the embodiment> In the above embodiment, the success rate parameter 25 is only one, the motivation points, but there may be a configuration in which there are multiple types of success rate parameters 25. In such a configuration, the action part execution control unit 104 may recover all types of success rate parameters that are recovered when rest 23 is selected, or may recover at least one type, and the recovery amount and the type of parameter to be recovered are determined by lottery (random function).

[0155] Furthermore, when the parameter of the success rate is less than a predetermined value, the action part execution control unit 104 may display a display on the action part home screen 61 to prompt the user to select rest 23. In this case, it is preferable to display the display in a manner in which the sub-characters are having a conversation.

[0156] The action part execution control unit 104 may display the first character with a facial expression according to the action power points, which are the success rate parameter 25, on the action part home screen 61. In this case, the first character with different facial expressions, such as a tired facial expression and a lively facial expression, is displayed on the action part home screen 61 before and after the execution of the rest time performance.

[0157] If rest 23 is selected when the action power points, which are the success rate parameter 25, are at the maximum value, one turn of the action part 12 will be wasted. Therefore, the action part execution control unit 104 may be configured to present a confirmation dialogue asking whether it is OK to execute rest 23 or whether it is not necessary to execute rest 23, and not to execute the rest performance. In other words, the action part execution control unit 104 may be configured to control so that rest 23 can be selected after the area investigation 21 or the request acceptance 22 is selected.

[0158] <Second embodiment> A second embodiment will now be described. The second embodiment relates to the processing of parameters such as points and character levels required for game progress. <Change character parameters> First, changing the parameters of a character will be described. In this embodiment, the character's level will be used as an example of the parameter of the character. The character's level increases with experience points given in the action part 12 and the battle part 14. However, some players may wish to increase the character's level quickly. Therefore, in the second embodiment, an example in which the character's level is increased by items will be described.

[0159] FIG. 40 is a block diagram of a player terminal 1 in the second embodiment, and FIG. 41 is a block diagram of a game server 2 in the second embodiment.

[0160] The player terminal 1 in the second embodiment further includes the functions of a parameter change designation unit 110 and an item acquisition unit 111 in addition to the functions of the player terminal 1 in the first embodiment.

[0161] The parameter change designation unit 110 designates the value of the level desired by the player. When a request to change the level is made, the parameter change designation unit 110 requests the game server 2 for character level change screen information including the type and number of items currently owned by the player, the current character level, the current character's experience points, the experience points required to reach the level to be changed, and the lacking experience points, and receives the character level change screen information from the game server 2. Then, based on the received character level change screen information, the character level change screen 200 is displayed.

[0162] 42 is a diagram showing an example of a character level change screen 200. The character level change screen 200 includes a list 201 of the types and quantities of level-up items currently possessed by the player, a list 202 of the character's current level, the character's experience points, the required experience points required to reach the level to be changed, and the lacking experience points that are the experience points lacking the required experience points, and a level designation 203 for designating the level to be changed (raised). Then, when a change level is specified by the player on the character level change screen 200, the parameter change specification unit 110 transmits the specified level to the game server 2.

[0163] The item acquisition unit 111 acquires surplus items, which will be described later.

[0164] The game server 2 in the second embodiment further includes the functions of a parameter management unit 83 and an item providing unit 84 in addition to the functions of the game server 2 in the first embodiment.

[0165] The parameter management unit 83 includes a player's owned character information database D12. Fig. 43 is a diagram showing an example of the player's owned character information database D12. The player's owned character information database D12 includes a field for a player ID, a field for the character's name, a field for the character's level, and a field for the character's experience value. When the parameter management unit 83 receives a request for character level change screen information, it refers to the player's owned currency information database D11 and the player's owned character information database D12, and transmits character level change screen information including the type and number of items currently owned by the player, the current character's level, the current character's experience value, the experience value required to reach the level to be changed, and the lacking experience value.

[0166] Furthermore, items that increase the character's level (referred to as experience point increase items) are given as rewards by performing the action part 12 and the battle part 14. In this embodiment, there are multiple types of experience point increase items depending on the experience point they increase, and in this embodiment, there are a 1000 increase item that increases the experience point by 1000, a 100 increase item that increases the experience point by 100, and a 10 increase item that increases the experience point by 10. However, the types are not limited to these and can be changed as needed.

[0167] In addition, when the parameter management unit 83 receives the designated level and the required experience points for changing to the designated level are insufficient, the parameter management unit 83 selects an experience point increasing item that will make up for the lack of experience points. Here, there are the following methods for selecting the experience point increasing item. - Choose the EXP increasing item with the most EXP increase from among the EXP increasing items you own. This method will minimize the number of EXP increasing items consumed. This is a method of selecting the EXP-increasing items to consume that will minimize the amount of surplus EXP from among the EXP-increasing items you possess. With this method, you generate combinations of EXP-increasing items you possess, calculate the surplus EXP for each combination, and select the combination that will minimize the amount of surplus EXP. - A method of setting ranks for the lack of experience points, and determining the order of experience point increase items to be consumed for each rank. For example, if the lack of experience points exceeds 1000, the experience point increase items are selected in the following order: 1000 increase item, 100 increase item, 100 increase item, 10 increase item. If the lack of experience points is between 100 and 1000, the experience point increase items are selected in the following order: 100 increase item, 1000 increase item, 10 increase item. If the lack of experience points is less than 100, the experience point increase items are selected in the following order: 10 increase item, 100 increase item, 100 increase item, 1000 increase item. This method has the advantage of reducing the processing load on the game server 2, since the types of experience point increase items to be consumed are predetermined. The above method is just an example and may be changed as needed.

[0168] When surplus experience points are generated by consuming an experience point increasing item selected by any of the methods, the parameter management unit 83 calculates the surplus experience points. Specifically, the parameter management unit 83 Excess EXP = (Owned EXP + EXP used to increase EXP) - Required EXP Calculate the amount of EXP you have and provide an EXP increase item that is equivalent to the amount of EXP you have left. For example, if you have 150 EXP, 1000 EXP to use for the EXP increase item, and 1000 EXP you need, then your EXP will be: Excess EXP 150 = (150 + 1000) - 100 = 150 Then, the parameter management unit 83 notifies the item providing unit 84 of the surplus experience points, and updates the player's owned currency information database D11 with respect to the consumed experience point increasing item.

[0169] The item providing unit 84 converts the notified surplus experience value into multiple types of experience value increasing items. For example, if the surplus experience value is 150, the item providing unit 84 converts the 150 surplus experience value into one experience value increasing item of 100 and five experience value increasing items of 10. The experience value increasing items are then provided to the player, and the player's owned currency information database D11 is updated for the provided experience value increasing items.

[0170] Next, a description will be given of the operation of the game server 2. Fig. 44 is a flowchart showing the operation of the level change process. First, when the parameter management unit 83 of the game server 2 receives a request for character level change screen information (Step 250), it refers to the player's owned currency information database D11 and the player's owned character information database D12 to obtain the type and number of items currently owned by the player, the current character's level, and the current character's experience points, and calculates the required experience points and lacking experience points to reach the new level (Step 251).The parameter management unit 83 then transmits character level change screen information including the type and number of items currently owned by the player, the current character's level, the current character's experience points, the required experience points and lacking experience points to reach the new level (Step 252).

[0171] Next, when a designated level is received from the player terminal 1 (Step 252), the parameter management unit 83 selects an experience point increasing item that will make up for the lack of experience points, using a predetermined selection method (Step 254).

[0172] If the lack of experience points can be made up by consuming the selected experience point increasing item, the parameter management unit 83 consumes the selected experience point increasing item and changes the character's level to the specified level (Step 256). The parameter management unit 83 also calculates the surplus experience points resulting from consuming the selected experience point increasing item and determines whether surplus experience points have been generated (Step 257). If surplus experience points have been generated, it notifies the item providing unit 84 of the surplus experience points. The parameter management unit 83 also updates the experience point increasing items in the player's owned currency information database D11 by the amount of the consumed experience point increasing item.

[0173] On the other hand, if the lack of experience points cannot be made up by consuming the experience point increasing item, the parameter management unit 83 notifies the player terminal 1 that the experience point increasing item is insufficient, and ends the process (Step 260).

[0174] The item providing unit 84 receives the surplus experience points, converts the surplus experience points into experience point increasing items (Step 258), provides the converted experience point increasing items, and updates the player's currency information database D11 for the provided experience point increasing items (Step 259).

[0175] 45 is an example of a character level change screen after the level change displayed on the player terminal 1. The character level change screen after the level change displays the level change 204, detailed information 205 of the surplus experience points, and details 206 of the experience point increasing item equivalent to the provided surplus experience points.

[0176] In the above example, the surplus experience points are exchanged for the same experience point increasing item, but the surplus experience points may be exchanged for other items of similar value.

[0177] In this embodiment, a level designation system is adopted in which the player designates the level to which he or she wishes to increase (change), so the player can change to the level he or she desires in one processing. In addition, any surplus experience points that accompany a change in level are converted into an item of the same value and provided to the player, so the player will not suffer any disadvantage.

[0178] <Game progress parameters> There are game progress parameters required to progress in the game. These game progress parameters are not parameters of characters, etc., but game progress points required to progress or execute the game. For example, in this game, a player executes action part 12, battle part 14, etc. while consuming game progress points. These game progress points are restored over time, but the amount of recovery per unit time is set, and depending on the player, the number of plays and the amount of recovery do not match, and the game play may not be executed. Therefore, game progress points may be restored by consuming items in addition to the recovery over time. Another example of the second embodiment is a method of processing parameters when such game progress points are restored by consuming items.

[0179] An outline of recovery of game progress points by consuming items in the second embodiment will be described below. Fig. 46 is a diagram for explaining recovery of game progress points by consuming items.

[0180] First, at the beginning of the game, the game progress points have a first upper limit of 100 (Figure 46(a)). These 100 points are consumed as the game progresses. For example, 10 points are consumed for each turn in action part 12 or each battle in the battle part (Figure 46(b)). Meanwhile, apart from consumption, the game progress points are restored over time (Figure 46(c)). However, the upper limit of the recovery is limited to the first upper limit, and the recovery will not exceed this.

[0181] Here, let us say that the player tries to recover the game progress points using an item. Items that can recover the game progress points are paid currency (including paid recovery items) and free recovery items. If the game progress points after consuming paid currency (including paid recovery items) and free recovery items (after recovery) are equal to or less than the first upper limit, both will be recovered normally (Figure 46(d)).

[0182] However, in the case of paid currency (including paid recovery items), if the game progress points available after spending (recovery) the paid currency (including paid recovery items) exceed the first upper limit, the points exceeding the first upper limit are rounded down and the game progress points available are set to the first upper limit (Figure 46 (e)).

[0183] On the other hand, in the case of a free recovery item, if the game progress points after the free recovery item is consumed (after recovery) exceed the first upper limit, the points exceeding the first upper limit are not rounded down, but are set to the current game progress points plus the recovery amount of the free recovery item (Figure 46(f)). Furthermore, in the case of a free recovery item, if the game progress points after the free recovery item is consumed (after recovery) exceed the second upper limit, the points exceeding the second upper limit are not rounded down, but are set to the current game progress points plus the recovery amount of the free recovery item (Figure 46(g)). However, subsequent recovery using a free recovery item is prohibited until the game progress points fall below the second upper limit.

[0184] The specific operation will be described below. The action part execution control unit 105 and the battle part execution control unit 106 of the player terminal 1 consume game progress points each time a turn is executed or a battle is executed. For example, in an action part turn, 10 game progress points are consumed per turn, and in a battle part, 20 game progress points are consumed per battle. On the other hand, as for recovery over time, 10 game progress points are recovered every hour. The action part execution control unit 105 and the battle part execution control unit 106 are assumed to be measuring the current game progress points.

[0185] When the player requests recovery of game progress points, the parameter change specification unit 110 of the player terminal 1 displays a game progress point recovery screen 210. FIG. 47 is a diagram showing an example of the game progress point recovery screen 210. The game progress point recovery screen 210 displays current game progress point information 211 and information 212 of the recovery items held. Information on the recovery items held can be acquired by referring to the player held currency information database D11. In this embodiment, it is assumed that one item, both the free recovery item and the paid currency (including paid recovery items), recovers 10 game progress points.

[0186] The player selects the item to be used (free recovery item or paid currency) from the recovery item information 212 on the game progress point recovery screen 210. Note that simultaneous use of free recovery items and paid currency is prohibited. Once the item to be used is determined, the parameter change designation unit 110 notifies the game server 2 of the type and number of items to be used.

[0187] When the type and number of items used for recovery are received, the parameter management unit 83 of the game server 2 performs a game progress point recovery process. Fig. 48 is an operational flowchart of the game progress point recovery process. The parameter management unit 83 consumes game progress points as the player progresses through the game (Step 280), and also recovers the game progress points over time (Step 281).

[0188] The parameter management unit 83 determines whether there is a request from the player terminal 1 to recover game executable points using items (Step 282). If there is a request from the player terminal 1 to recover game executable points using items (including the type and number of items to be used) (Step 283), the parameter management unit 83 determines the type of item to be used for the recovery (Step 284).

[0189] If the item to be used is a free recovery item (Step 285), the parameter management unit 83 determines whether the current game progress points exceed the second upper limit (Step 286). If the current game progress points exceed the second upper limit, the parameter management unit 83 notifies the player terminal 1 that the game progress points cannot be recovered by the item (Step 287). On the other hand, if the current game progress points do not exceed the second upper limit, the parameter management unit 83 recovers the game progress points according to the number of recovery items to be used (Step 288), and sets the game progress points to the recovered points (Step 289).

[0190] FIG. 49 is an example of a notification screen after recovery when three free recovery items are consumed when the current game progress possible points are 75 points. In the example of FIG. 49, it is notified that the game progress possible points have recovered to 105 points, and the game progress possible point information 211 indicates that the recovery has exceeded the first upper limit value. Also, FIG. 50 is an example of a notification screen after recovery when 13 free recovery items are consumed when the current game progress possible points are 75 points. In the example of FIG. 50, it is notified that the game progress possible points have recovered to 205 points, and the game progress possible point information 211 indicates that the recovery has exceeded the second upper limit value. Furthermore, it is notified that recovery using free recovery items is not possible until the game progress possible points become less than 200.

[0191] If the item used is paid currency (Step 285), the parameter management unit 83 recovers game progress possible points according to the amount of paid currency used (Step 290). The parameter management unit 83 then determines whether the recovered game progress possible points exceed a first upper limit (Step 291), and if the recovered game progress possible points exceed the first upper limit, rounds down the points that exceed the first upper limit and sets the game progress possible points to the first upper limit (Step 292). On the other hand, if the recovered game progress possible points do not exceed the first upper limit (Step 291), the game progress possible points are set to the recovered points (Step 289).

[0192] Figure 51 is an example of a notification screen after recovery when 3 paid currency units are consumed when the current game progress points available are 75. The example in Figure 51 notifies that the game progress points available have been restored to 100 points, and indicates that any points exceeding the first upper limit have been discarded.

[0193] As described above, in this embodiment, the recovery of game progress points is adjusted by setting two upper limits for free recovery items, and the recovery of game progress points exceeding the first upper limit is not permitted for paid items. This configuration has the effect of preventing the user from spending excessive money by restricting unlimited recovery with paid currency, and preventing the loss of the amount of recovery with free items, so that the player does not feel a loss. In addition, paid currency is an item that recovers game progress points, but is sold as a package containing multiple currencies in exchange for money. This paid currency includes recovery items, but like paid currency, it cannot recover game progress points beyond the first upper limit. In addition, free recovery items are not sold in packages in exchange for money, but are provided as rewards for performing actions such as Action Part 12 and Battle Part 14. Furthermore, free recovery items are prohibited from being obtained in exchange for paid currency or from being converted from paid currency.

[0194] Although the present invention has been described above with reference to preferred embodiments, the present invention is not necessarily limited to the above-described embodiments, and can be modified and embodied in various ways within the scope of the technical concept thereof.

[0195] A part or all of the above-described embodiments may be described as, but is not limited to, the following supplementary notes.

[0196] [Appendix 1] Computer, a game progress point consuming means for consuming game progress points necessary for game progress as the game progresses; a first recovery means for recovering the game progress possible points over time up to a first upper limit value; a second recovery means for recovering the game progress possible points on condition that the first type of game element or the second type of game element is consumed; providing means for providing a collection including a plurality of the second type of game elements; Functioning as a the second recovery means permits recovery of game progress points exceeding the first upper limit value on condition that the first type of game element is consumed, and does not permit recovery of game progress points exceeding the first upper limit value on condition that the second type of game element is consumed; program.

[0197] [Appendix 2] The providing means provides the assembly in exchange for money. 2. The program described in Appendix 1.

[0198] [Appendix 3] the providing means provides the first game element free of charge as the game progresses. 2. The program according to claim 1 or 2.

[0199] [Appendix 4] The providing means does not provide a collection of a plurality of the first game elements. 4. A program according to any one of claims 1 to 3.

[0200] [Appendix 5] Computer, an action part execution means for executing an action part in which a player selects one action from at least one or more actions and changes an attribute value of a third type of game element in accordance with a result of the selected action; a battle part execution means for executing a battle part in which the third type of game elements compete against each other; Functioning as a the providing means provides the first type of game element in accordance with the progress of the action part or the battle part. 5. The program according to claim 1, wherein the program functions as

[0201] [Appendix 6] the second recovery means, when the game progress possible points exceed the first upper limit value as a result of recovery through consumption of the second type of game element, sets the game progress possible points to the first upper limit value. 6. The program according to any one of claims 1 to 5.

[0202] [Appendix 7] the second recovery means, in the case of recovery by consumption of the first type of game element, sets the game progress possible points to a total value of the amount of recovery by consumption of the first type of game element and the game progress possible points before consumption of the first type of game element. 7. A program according to any one of claims 1 to 6.

[0203] [Appendix 8] the second recovery means, when the game progress possible points exceed a second upper limit value as a result of recovery through consumption of the first type of game elements, disables recovery through consumption of the first type of game elements until the game progress possible points fall below the second upper limit value; 8. A program according to any one of claims 1 to 7.

[0204] [Appendix 9] The first type of game element is not exchangeable for the second type of game element. 9. A program according to any one of claims 1 to 8.

[0205] [Appendix 10] a game progress point consuming means for consuming game progress points necessary for game progress as the game progresses; a first recovery means for recovering the game progress possible points over time up to a first upper limit value; a second recovery means for recovering the game progress possible points on condition that the first type of game element or the second type of game element is consumed; providing means for providing a collection including a plurality of the second type of game elements; Equipped with the second recovery means permits recovery of game progress points exceeding the first upper limit value on condition that the first type of game element is consumed, and does not permit recovery of game progress points exceeding the first upper limit value on condition that the second type of game element is consumed; Game management device. [Explanation of symbols]

[0206] 1 Player terminal 2 Game Server 10 Deck Organization Part 11 episodes 12 Action Part 13 Transformation Part 14 Battle Part 15 Ending Part 16 Result Part 80 Player Information Management Unit 81 Game Execution Management Department 82 Store Management Department 83 Parameter Management Section 101 Player Information Management Unit 102 Game execution control unit 103 Deck Organization Section 104 Action part execution control unit 105 Transformation part execution control unit 106 Battle part execution control unit 107 Ending episode execution control unit 108 Result part execution control section 109 Store presentation control unit 110 Parameter change specification section 111 Item Acquisition Department

Claims

1. Computer, a game progress point consuming means for consuming game progress points necessary for game progress as the game progresses; a first recovery means for recovering the game progress possible points over time up to a first upper limit value; a second recovery means for recovering the game progress possible points on condition that the first type of game element or the second type of game element is consumed; providing means for providing a collection including a plurality of the second type of game elements; Functioning as a The second recovery means is permitting recovery of game progress points exceeding the first upper limit value or a second upper limit value greater than the first upper limit value, on the condition that the first type of game element is consumed; when the game progress possible points exceed the second upper limit value due to the recovery through the consumption of the first type of game element, the recovery through the consumption of the first type of game element is disabled until the game progress possible points fall below the second upper limit value; when the game progress possible points exceed the first upper limit value as a result of recovery through consumption of the second type of game element, setting the game progress possible points to the first upper limit value; program.

2. The providing means provides the assembly in exchange for money. The program according to claim 1.

3. the providing means provides the first type of game element free of charge as the game progresses. The program according to claim 1 or 2.

4. the providing means does not provide a collection of a plurality of the first type of game elements; The program according to claim 3.

5. Computer, an action part execution means for executing an action part in which a player selects one action from at least one or more actions and changes an attribute value of a third type of game element in accordance with a result of the selected action; a battle part execution means for executing a battle part in which the third type of game elements compete against each other; Functioning as a the providing means provides the first type of game element in accordance with the progress of the action part or the battle part. The program according to claim 4,

6. the second recovery means, in the case of recovery by consumption of the first type of game element, sets the game progress possible points to a total value of the amount of recovery by consumption of the first type of game element and the game progress possible points before consumption of the first type of game element. The program according to claim 1.

7. The first type of game element is not exchangeable for the second type of game element. The program according to claim 4.

8. a game progress point consuming means for consuming game progress points necessary for game progress as the game progresses; a first recovery means for recovering the game progress possible points over time up to a first upper limit value; a second recovery means for recovering the game progress possible points on the condition that the first type of game element or the second type of game element is consumed; providing means for providing a collection including a plurality of the second type of game elements; Equipped with The second recovery means is permitting recovery of game progress points exceeding the first upper limit value or a second upper limit value greater than the first upper limit value, on the condition that the first type of game element is consumed; when the game progress possible points exceed the second upper limit value due to the recovery through the consumption of the first type of game element, the recovery through the consumption of the first type of game element is disabled until the game progress possible points fall below the second upper limit value; when the game progress possible points exceed the first upper limit value as a result of recovery through consumption of the second type of game element, the game progress possible points are set to the first upper limit value; Game management device.

Images