JP7796793B2 - Program and game device - Google Patents

Description

The present invention relates to a program and a game device.

In recent years, games have become known that are configured so that users can play each of multiple parts. When a game consists of multiple parts and is configured so that a player can play each of them, depending on the nature of the game or the game settings, a player may play certain parts frequently while playing other parts infrequently.

JP 2013-146590 A

In games like the one above, making each part interesting for the player will increase the game's enjoyment.

The object of the present invention is therefore to provide a program and a game device that can provide a highly entertaining game for players.

One aspect of the present invention is a program that causes a computer to function as: group organizing means for organizing groups including at least one of a first type of game element of a player and a second type of game element of another player; presentation means for presenting the first type of game elements and the second type of game elements; action part execution means for executing an action part that changes the attribute values of the first type of game elements of the group depending on the result of an action selected by the player from at least one or more actions; and battle part execution means for executing a battle part in which the player's first type of game elements compete against each other; and the first type of game elements of the other players include the player's level information and level information within a predetermined range, and the player's last login information and last login information within the predetermined range.

One aspect of the present invention is a gaming device comprising: a group organizing means for organizing a group including at least one of a first type of game elements of a player and a second type of game elements of another player; a presentation means for presenting the first type of game elements and the second type of game elements; an action part executing means for executing an action part that changes the attribute values of the group's first type of game elements in accordance with the result of an action selected by the player from at least one or more actions; and a battle part executing means for executing a battle part in which the player's first type of game elements compete against each other; wherein the other player's first type of game elements include the player's level information and level information within a predetermined range, and also the player's last login information and last login information within the predetermined range.

The present invention makes it possible to provide a highly entertaining game.

FIG. 1 shows an example of a card in which a character is embodied. FIG. 2 is a diagram showing an example of a stone. FIG. 3 is a diagram for explaining the flow of one story. FIG. 4 is a diagram showing an example of the overall configuration of a game system according to this embodiment. 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. FIG. 6 is a block diagram showing an example of the functional configuration of the player terminal 1. FIG. 7 is a diagram showing an example of the player information database D1. FIG. 8 is a diagram showing an example of the game element information database D2. FIG. 9 is a diagram showing an example of the owned card/stone information database D3. FIG. 10 is a diagram showing an example of the deck database D4. The figures from FIG. 11 onwards are diagrams for explaining deck organization. FIG. 12 is a diagram showing an example of the area selection screen. FIG. 13 shows an example of a support character selection screen. FIG. 14 is a diagram showing an example of the stone selection screen. FIG. 15 is an example of the behavior part home screen 61 . FIG. 16 is a diagram showing an example of transformation performance 1. FIG. 17 is a diagram showing an example of transformation effect 2. FIG. 18 is a diagram showing an example of a battle screen. FIG. 19 is a diagram showing an example of a battle screen. FIG. 20 shows an example of a battle start screen. FIG. 21 is a diagram showing an example of ending episode 1. FIG. 22 is a diagram showing an example of ending episode 2. FIG. 23 is an example of the result screen. FIG. 24 is a block diagram showing an example of the functional configuration of the game server 2. FIG. 25 is a flowchart showing the operation of the action part execution process executed by the action part execution control unit 104. FIG. 26 is an operational flowchart of the transformation part execution process executed by the transformation part execution control unit 105. FIG. 27 is a flowchart showing the operation of the battle part execution process executed by the battle part execution control unit 106. FIG. 28 is a flowchart showing the operation of the ending part execution process executed by the ending part execution control unit 106. FIG. 29 is an operational flowchart of the result part execution process executed by the result part execution control unit 108. FIG. 30 shows an example of the top home screen 60 of the game. FIG. 31 is a diagram showing an example of the store screen. FIG. 32 is a diagram showing an example of the provided card information database D10. FIG. 33 is a diagram showing an example of the player's currency information database D11. FIG. 34 is a flowchart showing the operation of the card provision process. FIG. 35 is a diagram for explaining the transition of the store purchase screen. FIG. 36 is a diagram for explaining the transition of the store screen displayed on the player terminal 1 when purchasing a card. FIG. 37 is a flowchart showing the process of updating the number of times of storage and provision. FIG. 38 is a diagram showing an example of the provided information database D20 for steps 1 to 4. FIG. 39 is an example of a step-up provision screen. FIG. 40 is a block diagram of the player terminal 1 in the second embodiment. FIG. 41 is a block diagram of the game server 2 in the second embodiment. FIG. 42 is a diagram showing an example of the character level change screen 200. FIG. 43 is a diagram showing an example of the player's character information database D12. FIG. 44 is a flowchart showing the operation of the level change process. FIG. 45 shows an example of a character level change screen displayed on the player terminal 1 after the level change. FIG. 46 is a diagram for explaining recovery of game progress points by consuming items. FIG. 47 is a diagram showing an example of the game progress point recovery screen 210. FIG. 48 is a flowchart showing the operation of the game progress point recovery process. FIG. 49 shows an example of a notification screen after recovery when three free recovery items are consumed when the current game progress points are 75 points. FIG. 50 shows an example of a notification screen after recovery when the current game progress points are 75 points and 13 free recovery items have been consumed. FIG. 51 shows an example of a notification screen after recovery when the current game progress points are 75 points and three paid currency units are consumed. FIG. 52 is a diagram for explaining switching between the first mode and the second mode at each turn. FIG. 53 is a diagram for explaining prohibited conditions for deck organization. FIG. 54 shows an example of a support character selection screen. FIG. 55 is an example of a search screen. FIG. 56 is an example of a stone selection screen. FIG. 57 is an example of a search screen.

First Embodiment
<Game Overview>
To facilitate understanding of the game system in this embodiment, an outline of the game to which this embodiment is applied will be described.

First, let me explain the game elements that appear in this game.

There are two types of game elements that appear in this game: a first type of game element and a second type of game element.

The first type of game element is a character (person, etc.), which is represented by an image, virtual or physical object, etc. An object, for example, is a virtual or physical card.

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 their desired first, second, and third characters to form a group (deck).

The first, second, and third characters each have multiple statuses. Types of status include parameters such as the character's attributes, their attribute values, the character's support effect value, the character's intimacy with the player (referred to as intimacy), and the character's skills (abilities).

A character's level increases as the game progresses. A character's attributes are characteristics that represent the character, such as colors (e.g., red, blue, yellow, green) or personalities (e.g., bright, cool). In this embodiment, a character's attributes are colors, and each character is associated with two of the four colors (red, blue, yellow, and green). In other words, each character has two attributes. Hereinafter, the two attributes possessed by a character are referred to as the first attribute and the second attribute. A character's attribute value is a parameter that indicates the degree of the attribute. A character has attribute values for four attributes (red, blue, yellow, and green). Each attribute value changes by performing actions described below. A character's support effect value is an ability value demonstrated when the character is a second character, and, as described below, is an ability value that supports the action selected by the player. The higher the ability value, the more advantageous the character's progress in the game. A character's intimacy level is the degree of intimacy between the player and the character, and increases by selecting special actions described below. As intimacy increases, the character's expressions of affection towards the player in the game change and the amount of information provided to the player increases, improving the relationship between the player and the character. This also gives the player an advantage in battles, as described below. Character skills are activated by meeting certain conditions, and have effects that give the player an advantage in the game.

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 character card with the attributes "red" and "blue" and a level of 50, and card X2 is an example of a character card with the attributes "yellow" and "green" and a level of 50.

The second type of game element is an item that the player collects and that affects battles, etc. In this embodiment, these items are called stones. The second type of game element (stones) has multiple pieces of status information. The types of status are attributes, which are characteristics that represent the character, and parameters such as their attribute values, rank, and skills.

A stone's attribute is one of the attributes that represent the 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 attribute values for four attributes (red, blue, yellow, and green). A stone's rank indicates the stone's strength. A stone's skills are skills that provide advantages to actions, as described below.

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

Next, we will explain the flow of the game in this embodiment. The game is made up of at least one story. Figure 3 is a diagram explaining the flow of one story.

The story includes a deck organization 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.

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

Episode 11 is a part where the character's episode is displayed and is not controlled by the player. Episode 11 is inserted between parts as appropriate.

The action part 12 is the main part of the game and is controlled by the player. The action part 12 includes multiple turns 20. The number of turns 20 in one action part 12 is predetermined. For example, one action part 12 consists 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.

District Investigation 21 is the action of selecting one spot from those scattered throughout 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 player's experience points and the parameters such as attribute values and experience values of the characters in the deck will increase depending on the results of the District Investigation 21 investigation, and investigation points will be awarded. The results of the District Investigation 21 investigation can be either successful or unsuccessful, 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 attribute values of character attributes that match the attribute of the spot will be higher. The investigation points awarded are the points required to complete the action part and are accumulated.

The District Investigation 21 is conducted by consuming motivation points, a parameter that increases the success rate of the District Investigation 21 and Request Acceptance 22. Motivation points, a parameter that increases the success rate, are assigned a maximum value at the start of Action Part 12.

Request Orders 22 are completed by selecting a specific request (mission) from the game management side. By completing the request (mission), the player's experience points and parameters such as the attribute values and experience values 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 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. Request Orders 22 are completed by consuming action points, which are parameters that increase the success rate.

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

You can select one of the following actions each turn 20: Area Investigation 21, Request Acceptance 22, or Rest 23. Once you complete the selected action and your accumulated investigation points exceed a predetermined value, you can complete Action Part 12.

When the accumulated research points exceed a predetermined value and Action Part 12 is completed, the player moves on to Transformation Part 13. Transformation Part 13 is the 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 to a combat appearance. Furthermore, the transformation performance of the first character varies depending on the character's attribute values, etc., that have changed in Action Part 12.

Battle part 14 is a part in which the transformed first character of the first type of game element battles against a non-player character prepared by the game operator. In a 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. By playing battle part 14, the player's experience points and parameters such as the attribute values and experience points of the characters in the deck increase.

Ending Part 15 is a performance part that precedes the result part of the game. The performance in Ending Part 15 varies depending on the character's attribute values, etc., that have changed in Action Part 12.

When Ending Part 15 ends, a results screen will be displayed showing the character parameters that have changed as a result of completing Action Part 12 and Battle Part 14, as well as details of the stones awarded.

As described above, one of the features of the game of this embodiment is that various second-type game elements are discovered using first-type game elements, and the discovered second-type game elements have a significant impact on battles using the first type of game.

Another feature is that the subsequent transformation part 13 and ending episode 15 are presented differently depending on the outcome of the action part 12 using the first type of game element.

Next, we will explain the configuration of this embodiment.

<Overall structure>
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 is configured to include 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.

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

The player terminal 1 is a computer capable of executing a game program, and is capable of connecting to a communication line N via a wireless communication base station or the like to communicate data with the game server 2. Examples of player terminals 1 include personal computers, smartphones, mobile phones, portable game devices, stationary home game devices, arcade game devices, tablet computers, and controllers for stationary home game devices. There are generally multiple player terminals 1, each operated by a different player.

The game server 2 is a server system configured to include 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 necessary for operating the game and distribute game programs and data necessary for running the game on the player terminal 1.

Figure 5 shows an example of the device configuration of a laptop computer, which is an example of a player terminal 1. As shown in Figure 5, the player terminal 1 is equipped with a display 11 and a keyboard 12, which serves as an operating means. The player terminal 1 also includes a control board, built-in battery, power button, volume control button, speaker, etc., which are not shown.

The control board is equipped with various microprocessors such as a CPU, GPU, and DSP, ASICs, various IC memories such as VRAM, RAM, and ROM, and wireless communication modules for wireless communication with mobile phone base stations. The control board also has so-called I/F circuits (interface circuits), such as the driver circuit for the touch operation panel 12. Each of these elements mounted on the control board is electrically connected via bus circuits, etc., enabling the reading and writing of data and the sending and receiving of signals.

Next, we will explain the configuration of each device.

<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. 6, the terminal 1 includes a display unit 51, an operation input unit 52, a sound output unit 53, a communication unit 54, a memory unit 55, and a processing unit 56.

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

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

The sound output unit 53 outputs sound effects and other sounds related to the game based on the input sound signal.

The communication unit 54 connects to the communication line N to realize communication. The functions of the communication unit 54 can be realized, for example, by a wireless communication device, a modem, a TA (terminal adapter), a jack for a wired communication cable, a control circuit, etc.

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

The memory unit 55 stores a system program and a game program. The system program is a program for implementing the basic computer functions of the player terminal 1. The game program is a program for enabling 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., once the player has completed account registration. The memory unit 55 also stores databases necessary for running the game. In this embodiment, the memory unit 55 stores a player information database D1, a card information database D2, an owned card/stone information database D3, and a deck database D4.

The player information database D1 is a database that stores various information about players and following players, who are players the player follows. Figure 7 shows an example of the player information database D1. The player information database D1 includes a field for player ID, a field for player name, a field for level, a field for owned card IDs, a field for owned stone IDs, a field for setting decks, a field for story information, a field for last update date and time, and a field for last login date and time, and each piece of information is stored in association with the other information. The information about following players is updated when connected to the game server 2 and synchronized with the player information database D1 on the game server 2.

The player ID field is a field in which identification information that identifies the player is entered. The player name field is a field in which, for example, a nickname is entered. The level field is a field in which the player's level, which is obtained by accumulating experience points granted to the player, is entered. The owned card ID field is a field in which card identification information (card ID) of cards owned by the player is entered. The owned stone ID field is a field in which card identification information (card ID) of stones owned by the player is entered. The configured deck field is a field in which the deck ID of the currently configured deck is entered. The story information field is a field in which story progress information is entered. The last update date/time field is a field in which the last update date/time of the game element information database D1 is entered. The last login date/time field is the last date/time the player logged into the game.

The game element information database D2 is a database that stores information on game elements that appear or are used in the game. Figure 8 shows 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 effect field, an ending episode field, and a last update date and time field.

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

The owned card/stone information database D3 is a database of cards and stones owned by a player. Figure 9 shows 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 contains status information such as the card or stone's attributes, attribute value, rank, and level.

The deck database D4 is a database that records the contents of the decks organized by the player. Figure 10 shows an example of the deck database D4. The deck database D4 includes a deck ID field, a first character card ID field, a second character card ID field, a third character card ID field, a fourth character card ID field, and a stone ID field.

The Deck ID field is a field where the deck ID that identifies the deck is entered. The First Character Card ID field, Second Character Card ID field, Third Character Card ID field, and Fourth Character Card ID field are fields where 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 entered. The Stone ID field is a field where the stones and sub stone IDs to be included in the deck are entered.

Furthermore, these databases can be downloaded successively by the game server 2 as characters used in the game are added or changed.

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 GPU, an ASIC, or IC memory. The processing unit 56 includes, as its main functional units, a player information management unit 101, a game execution control unit 102, a deck compilation 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.

The player information management unit 101 manages player information using the player information database D1. When this information is updated, the player information management unit 101 updates the player information database D1 and records the update date. The player information management unit 101 may update the last login date and time in the player information database D1 when logging in, or may update the last login date and time when logging out after playing a game.

The game execution control unit 102 controls and manages the overall progress of the game. For example, the game execution control unit 102 displays menu screens such as a home screen and executes processes selected by the player. Figure 30 shows an example of a top home screen 60 for the game. The top home screen 60 includes story buttons that transition to various stories (action parts) of the game, and a store button that transitions to the store.

The deck organization unit 103 is the unit that organizes decks from owned cards and stones.

The deck organization unit 103 displays a deck organization screen. Here, we will explain the deck to be organized. The deck is composed of a first group including a first character (first type of game element) who will be the main character, a second group including a second character (first type of game element) and a third character (first type of game element) who will be sub characters, and a third group including stones.

The first group is a group that contains only one first character, who will be the main character. The second group is a group that contains one to three second characters and up to one third character. It should be noted here that when organizing a deck, the first character in the first group and the second and third characters in the second group cannot be the same character. In other words, the main character and a sub-character cannot be the same character. This is because, although the story of this game unfolds around the first character, who is the main character, sub-characters also affect the presentation, and having the same characters in the same deck would deviate from the worldview of this game.

Also, even if the cards have different appearances but the same character, such as parallel cards, or if the characters are the same depending on the type of card but have different abilities or appearances, they are still the same character, so even if the cards are different, if the characters are the same, they cannot be included in the same deck.

Similarly, characters belonging to the second group are prohibited from being the same character. In other words, it is preferable that all second and third characters belonging to the second group are different characters. However, even if the second group contains the same character, as long as it is different from the first character in the first group, it may be acceptable, as this does not have a significant impact on the game's worldview.

In addition, stones (second type of game elements) belonging to the third group are associated with characters, but because stones (second type of game elements) are items, they may also be stones (second type of game elements) associated with characters belonging to the first and second groups. Furthermore, the third group may contain multiple identical stones (second type of game elements).

In other words, the prohibited conditions for deck composition are as follows:
(1) The characters belonging to the first group and the characters belonging to the second group are not the same.
(2) All characters in the second group are different.
Furthermore, the character corresponding to the stone belonging to the third group may be included in the characters belonging to the first group and the characters belonging to the second group.
FIG. 53 is a diagram for explaining the prohibited conditions for deck organization described above.
In the case of Figure 53(a), the first character A belongs to the first group, the second character A, second character B, second character C, and second character D belong to the second group, and stone A, stone B, stone C, and stone D belong to the third group. However, because the first character A is in the first group and the second character A is in the second group, the prohibited condition (1) is met, and the organized deck cannot be registered.
In the case of Figure 53(b), the first character A belongs to the first group, the two second characters B, C, and D belong to the second group, and Stone A, B, C, and D belong to the third group. However, because there are two identical second characters B in the second group, this satisfies the prohibited condition (2), and the organized deck cannot be registered.
On the other hand, in the case of Figure 53(c), the stones belonging to the third group are two stones A, stone C, and stone D. However, multiple identical stones are permitted within the third group. Furthermore, even if a character belonging to the first and second groups is the same as a character corresponding to a stone belonging to the third group, this does not meet the prohibited condition, so the organized deck can be registered.

When displaying the finally selected characters and stones on the formation screen, it is preferable to display the characters and stones for each of the first, second, and third groups, as shown in Figure 53. In this case, the characters and stones are displayed in different forms, for example, as shown in Figures 1 and 2, or as images of the characters and stones. It is also preferable to display the characters as larger images than the stones.

If, during the deck organization process, a deck is organized that falls under the above-mentioned prohibited conditions, the deck organization unit 103 will notify the user that the organized deck cannot be registered. Figures 11 to 14 are diagrams for explaining deck organization. Figure 11 is a screen for selecting a first character, who will be the main character. Each character belongs to one of the teams based on attributes, etc., and by selecting a team, the cards X of the characters belonging to that team will be displayed.

When the player selects a first character that will be the main character, the deck compilation unit 103 displays a district selection screen to select the district that the deck will be responsible for. Figure 12 shows an example of the district selection screen. Each district is associated with two attributes: a first attribute and a second attribute, and selecting the same attribute as the main character's attribute is advantageous for increasing various parameters.

Once the region selection is complete, the deck organization unit 103 displays a support character selection screen on which a card for a second sub-character and a card for a third character using the friend function can be selected. Figure 13 shows an example of a support character selection screen. The friend function allows the player to select characters owned by players other than the player.

Finally, the deck compilation unit 103 displays a stone selection screen for selecting stones. Figure 14 shows an example of the stone selection screen. The player selects the desired stone from the stones they own. Once a stone is selected, the deck compilation unit 103 determines whether the deck compilation satisfies the prohibited conditions for deck compilation described above, and notifies the player if a prohibited condition is met. On the other hand, if a prohibited condition is not met, the deck compilation unit 103 writes the contents of the newly compiled deck to the deck database D4 and ends the deck compilation.

The action part execution control unit 104 controls and executes action parts within a story. An action part 12 includes multiple 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.

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 the action part home screen 61, where an action can be selected. Figure 15 is an example of the action part home screen 61. The action part home screen 61 in Figure 15 displays selection buttons for area investigation 21, request acceptance 22, and rest 23, allowing the player to select any of the actions. The action part home screen 61 also displays the first character.

When District Investigation 21 is selected, the action part execution control unit 104 presents spots scattered throughout the selected district at the start of the story (game) and develops an investigation story for one of the spots selected by the player. Spots have one of several attributes. By consuming energy points to complete an investigation of a spot, the action part execution control unit 104 increases the player's experience points and parameters such as the attribute values and experience values of the characters in the deck, and awards investigation points. The action part execution control unit 104 accumulates the awarded investigation points and displays them as investigation points 24 on the action part home screen 61. Because the purpose of District Investigation 21 is to increase parameters such as the attribute values of the characters forming the deck, particularly the first character, the award rate for investigation points is set lower than for Request Acceptance 22. Energy points, which are the success rate parameter 25, are also displayed on the action part home screen 61, and the action part execution control unit 104 consumes energy points, which are the success rate parameter, to develop the investigation story. To increase your motivation points, which are a success rate parameter, you must perform Rest 23.

When a request order 22 is selected, the action part execution control unit 104 presents the prepared mission to the player. By completing the mission, the action part execution control unit 104 increases the player's experience points and parameters such as the attribute values and experience values of the characters in the deck, and awards research points. The action part execution control unit 104 accumulates the awarded research points and displays them as accumulated points 24 on the action part home screen 61. Note that because the purpose of request order 22 is to accumulate research points to complete an action part, the rate of increase for parameters such as the attribute values of the characters forming the deck, particularly the first character, is set low, and the rate of awarding research points is set high. In addition, the action part home screen 61 displays action points, which are the success rate parameter 25, and the action part execution control unit 104 consumes action points, which are the success rate parameter, to execute the mission.

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 the motivation points, which are the parameter 25 for the success rate of the area investigation 21 and request acceptance 22, and also serves to increase the intimacy with the first character. The motivation points to be restored are determined by lottery, i.e., by a random function. The motivation points to be restored may be 0.

The player selects one of the above actions in one turn 20: area investigation 21, request acceptance 22, or rest 23, 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 that the action part 12 has been completed.

The action part execution control unit 104 described above is a normal mode (first mode) in which the player selects an action themselves. Furthermore, the action part execution control unit 104 also has a second mode function (autoplay function) in which it automatically selects an action and executes the selected action without requiring the player to select an action. Specifically, when the player selects the second mode function (autoplay function), the action part execution control unit 104 automatically selects one of the following for each turn: district investigation 21, request acceptance 22, or rest 23, and executes the selected action.

The action part execution control unit 104 selects the action as follows: First, in turn 20, when the action points (success rate of the area investigation) exceed 70, it selects Area Investigation 21. The area (or points) selected in Area Investigation 21 is an area with the same attributes as the first character's attributes. Then, when the action points (success rate of the area investigation) fall below 70, the action part execution control unit 104 selects Rest 23 in the next turn. Once again, when the action points (success rate of the area investigation) exceed 70, it selects Area Investigation 21. Request Acceptance 22 is generally not selected. This is because the purpose of Request Acceptance 22 is to accumulate investigation points to complete the action part, and the auto-play function prevents the adverse effect of investigation points accumulating without the player playing.

Furthermore, when the second mode function (autoplay function) is selected, the parameter values, such as the attribute values of the characters in the deck obtained by completing the district survey 21, are set to values lower than those in the first mode. By setting the second mode function (autoplay function) in this way, the rank of the stones assigned by the result part execution control unit 108 is lower than that when the first mode is selected. This is because the amount of effort expended on gameplay differs between a player who actually plays the game and a player who uses the autoplay function without actually playing the game, which deviates from the original purpose of the game, which is to enjoy the game.
Therefore, in order to obtain a high-ranking stone, the player must select the first mode to be executed by himself.

Switching between the first mode and second mode functions can be done by turning the auto button 27 on or off on the action part home screen 61 shown in Figure 15. Also, switching between the first mode and second mode is possible during the action of each turn, as shown in Figure 52.

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 depicts 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 a combat appearance. The transformation of the first character also varies depending on the character's attribute values, etc., that have changed during the action part 12. Furthermore, if the second mode function (autoplay function) is selected in the action part 12, the transformation part 13 is executed automatically after the action part 12 is completed.

The transformation part execution control unit 105 determines the first character in the deck, identifies the card ID of the first character, and identifies transformation effects 1 to 3 associated with that card ID from the card information database D2. Transformation effect 1 is selected when the attribute value of the first attribute of the first character is greater than the attribute value of the second attribute. Transformation effect 2 is selected when the attribute value of the first attribute of the first character is less than the attribute value of the second attribute. Transformation effect 3 is selected when the attribute value of the first attribute and the attribute value of the second attribute of the first character are the same. Figure 16 is a diagram showing an example of transformation effect 1, and Figure 17 is a diagram showing an example of transformation effect 2. In the examples of Figures 16 and 17, the background differs 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 transformed appearance of the first character is a deformed version of the first character, different from the normal appearance of the first character displayed in action part 12. For example, the transformed character's appearance is smaller than the normal appearance of the first character.

Furthermore, a transformation performance 3 for the second mode (autoplay function) may be prepared, and when the transformation part 13 is executed in the second mode (autoplay function), the transformation part execution control unit 105 may execute the transformation performance 3 regardless of the attribute value executed by the first character.
In addition, when the transformation part execution control unit 105 is being executed in the second mode (autoplay function), it may be possible to select, before the execution of the effect, between an effect based on the attribute value of the first character (first mode effect) and transformation effect 3 for the second mode (autoplay function).

After completing the transformation part 13, the battle part execution control unit 106 executes the battle part 14 between the character organizing the deck and the non-player character. The outcome of the battle is determined by the magnitude of the combat power calculated from the parameters of the stones in the deck and the intimacy level of the first character. The first character that appears on the battle screen is the first character transformed in the transformation part 13, and the background may differ depending on the magnitude of the attribute values of the first attribute and the second attribute of the first character. Figures 18 and 19 show examples of the battle screen.

Furthermore, if the second mode function (autoplay function) is selected in the action part 12, the battle part 14 will be executed automatically after the transformation part 13 is completed. Furthermore, if the second mode function (autoplay function) is selected, the second mode function (autoplay function) cannot be canceled, i.e., transition to the first mode cannot be made. However, skipping, as described below, is possible.

When the battle part 14 is completed (for example, when the battle is won), the battle part execution control unit 106 records the completion of the battle part 14 in the story information in the player information database D1. Furthermore, when the battle part 14 is completed, the battle part execution control unit 106 increases the player's experience points and parameters such as the attribute values and experience points of the characters in the deck.

The battle part execution control unit 106 also has a skip function for the battle part 14. The skip function allows you to skip the battle part 14 again when replaying a story for which all parts have been completed. This skip function is used because, since the action part 12 allows you to select different actions each turn and is a part that places emphasis on character development, it is meaningful to perform the action part 12 of that story multiple times even after one story is completed, but the battle part places emphasis on the battle, and once you have won, there is little point in performing it multiple times.

When the battle part begins, 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 for the battle part 14 indicating that it can be skipped, and displays a battle skip button. Figure 20 shows 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 that the battle part 14 has been completed. Note that the skip condition may be not only victory in one battle, but also victory in multiple battles.

Note that there is a difference between the time of action part 103 and the time of battle part 14, but because battle part 104 is a simple battle as mentioned above, the time of action part 103 is longer.

The ending part execution control unit 107 presents an ending episode in ending part 15 after the end of battle part 14. If the second mode function (autoplay function) is selected in action part 12, the ending part execution control unit 107 automatically executes ending part 15 after the end of 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.

The ending part execution control unit 107 identifies the first character in the deck, specifies the card ID of the first character, and identifies ending episodes 1 to 3 associated with that card ID from the card information database D2. 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. Ending episode 2 is an ending episode selected when the attribute value of the first attribute of the first character is less than the attribute value of the second attribute. Ending episode 3 is an ending episode selected when the attribute value of the first attribute and the attribute value of the second attribute of the first character are the same. Figure 21 is a diagram showing an example of ending episode 1, and Figure 22 is a diagram showing an example of ending episode 2. In the examples of Figures 21 and 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.

The result part execution control unit 108 determines the rank of the stones to be awarded and displays the result screen. If the second mode function (autoplay function) is selected in the action part 12, the result part execution control unit 108 disables the second mode function (autoplay function) and transitions to the first mode before executing the result part 16.

The rank of the stone to be awarded is determined by converting each attribute value of the first character into evaluation points 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 awarded. The result part execution control unit 108 determines the attribute based on the relative magnitude of 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. If the attribute values of the first attribute and the second attribute are the same, either the first attribute or the second attribute is selected by lottery.

The result part execution control unit 108 displays a story result screen that includes information such as the rank and attributes of the stones to be awarded. Figure 23 is an example of a result screen. Figure 23 presents the attribute values of the first character and information about the stones to be awarded.

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

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 provided free of charge by the game operator. There are several types of card tickets, including normal card tickets that allow a player to acquire one card, and consecutive card tickets that allow a player to acquire ten cards 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.

The card purchase button 91 is a button that allows you to obtain a card at a price lower than the normal card price, limited to once per 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 per day limited card button 91, it is possible to obtain one card for 50 units of currency. Once the once per day limited card button 91 is selected and an exchange for a card is carried out, it cannot be used until the next day. Note that one day is an example, and other predetermined periods such as three days or one week may also be used.

The card purchase button 92 allows you to consume currency to obtain one card. Any of the following currencies can be used: card tickets, free currency, and paid currency.

The card purchase button 93 allows players to purchase 10 cards by consuming currency. Any of the following currencies can be used: card tickets, free currency, and paid currency. The benefit of purchasing 10 cards consecutively is that it increases the probability of obtaining cards with high rarity, 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 lottery held by the game device 1 or the game server 2, and a card of that rarity is awarded. The probability of winning a card of a higher rarity is lower.

The rarity confirmation gauge 94 is a gauge that indicates the number of cards provided to the player (number of times the player has acquired cards), and increases by one each time a card is acquired. In this embodiment, the system guarantees that one high-rarity card is granted by acquiring 100 cards.

In this embodiment, the priority of the currency consumed when purchasing a card is determined in advance. In this embodiment, the currency is consumed in the following order: card tickets, free currency, and paid currency.

<Configuration of Game Server 2>
24 is a block diagram showing an example of the 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.

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, or IC memory. 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.

The player information management unit 80 manages player information. For each player ID, the player information management unit 80 has a player information database D1, an owned card/stone information database D3, and a deck database D4.

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. If there is a match, it notifies the user of this fact; if there is a mismatch, it transmits the contents of each database for the player ID stored on the game server 2, thereby synchronizing the contents of each database between the player terminal 1 and the game server 2.

The game execution management unit 81 manages the game. It mainly holds the game element information database D2, and when game elements are updated, it sends the update information to the player terminal 1. It also synchronizes the contents of the game element database D2 between the player terminal 1 and the game server 2, for example, when logging in to the player terminal 1.

The store management unit 82 manages the stores that provide cards using a provided card information database D10 and a player-held 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-held 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 written. The rarity information field is a field in which rarity information of the card is written, with the larger the number, the higher the rarity. The winning probability field is a field in which the winning probability of the card is written, with the larger the number, the higher the probability of winning.

The player-owned currency information database D11 includes a player ID field, a free currency field, a ticket field, a paid currency field, a purchase history information field, and a field for the number of times cards have been provided. 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 free currency held by the player is recorded. The ticket field is a field in which the number of free currency held by the player is recorded. The paid currency field is a field in which the number of paid currency held by the player 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 cards have been provided is a field in which the accumulated number of times cards have been provided to the player is recorded.

When the store management unit 82 receives a request from the player terminal 1, it references the provided card information database D10 and the player-held currency information database D11, determines the card to be provided in exchange for the currency consumed, and transmits the card ID information.

The communication unit 71 connects to the communication line N to realize communication.

The memory unit 72 stores a system program and a game program. The system program is a program that implements the basic functions of the game server 2 as a computer. The game program is a program that causes 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.

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

<Operation of player terminal 1>
The operation of the player terminal 1 will now be described.

<Actions in Action Part 12>
First, a description will be given of the operation of the action part execution control unit 104. Fig. 25 is a flowchart showing the operation of the action part execution process executed by the action part execution control unit 104.

Once the deck is organized and the player starts the game, the action part of a specific story begins. As shown in FIG. 15, the action part execution control unit 104 presents the following actions as selectable: Area Investigation 21, Request Acceptance 22, and Rest 23 (Step 100). The player selects one of the presented actions.

When District Investigation 21 is selected (Step 101), the action part execution control unit 104 executes District Investigation 21 (Step 102). When the player's play fulfills the conditions for completing District Investigation 21 (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 a district investigation, it is preferable to increase the rate of increase in the first character's parameters and award fewer investigation points, in order to balance with other actions.

When Request Order 22 is selected (Step 105), the action part execution control unit 104 executes Request Order 22 (Step 106). When the player's play fulfills the completion conditions for Request Order 22 (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 Request Order 22, it is preferable to decrease the rate of increase in the first character's parameters and increase the amount of research points awarded, in order to balance it with other actions.

When Rest 23 is selected (Step 110), the action part execution control unit 104 executes Rest 23 (Step 111). When the player's play satisfies the conditions for completing Rest 23 (Step 112), the parameters of the first character in the deck are increased and the player is awarded action points (Step 113). Note that in the case of Rest 23, the rate of increase in intimacy level for the first character's parameters is increased.

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 choose a balanced range of actions.

Next, the action part execution control unit 104 determines whether action part 12 has been completed (Step 109). Completion of action part 12 is determined by whether the player's accumulated investigation points have exceeded a predetermined value. If the player's accumulated investigation points have exceeded the predetermined value at the completion of a predetermined turn 20 (Step 114), the action part execution control unit 104 ends action part 12, updates the story information, and transitions to transformation part 13 (Step 115).

<Transformation part 13 movements>
The operation of the transformation part execution control unit 105 will be described below. FIG. 26 is a flowchart showing the operation of the transformation part execution process executed by the transformation part execution control unit 105.

The transformation part execution control unit 105 determines the first character on the deck (Step 120). Then, the transformation part execution control unit 105 selects transformation effects 1 to 3 associated with the first character (Step 121).

The transformation part execution control unit 105 determines 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 (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 effect 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 effect 2 (Step 126). If the attribute value of the first attribute and the attribute value of the second attribute are the same (Step 130), the transformation part execution control unit 105 selects transformation effect 3 (Step 130).

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 post-transformation appearance. The post-transformation 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).

<Actions in Battle Part 14>
The operation of the battle part execution control unit 106 will now be described.

The battle part execution control unit 106 determines 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 has been completed (Step 141), it displays a message on the battle start screen for the battle part 14 indicating that it 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).

On the other hand, if the battle skip button is not selected or skipping is not possible, the battle part execution control unit 106 reads the parameters of the stones in the deck and the intimacy level with 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). The battle part execution control unit 106 then determines the outcome of the battle (Step 147).

If the player's fighting power 1 is greater than the opposing player's (non-player character's) fighting power 2 (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 opposing player's (non-player character's) fighting power 2 (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).

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

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

The ending part execution control unit 107 determines the first character on the deck (Step 160). Then, the ending part execution control unit 107 selects ending episodes 1 to 3 associated with the first character (Step 161).

The ending part execution control unit 107 determines 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 (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 and the attribute value of the second attribute are the same (Step 165), the ending part execution control unit 107 selects ending episode 3 (Step 168).

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 transitions to the result part 16 (Step 169).

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

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 evaluation points (Step 181) and adds up the evaluation points (Step 182). The result part execution control unit 108 then determines the rank of the stone based on the total value of the evaluation points (Step 183).

Next, the result part execution control unit 108 determines the attribute of the stone to be assigned (Step 184). The result part execution control unit 108 determines 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 (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).

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). Then, the stones are awarded to the player (Step 188).

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

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

Upon receiving a request from the player terminal 1, the store management unit 82 of the game server 2 references the player-held currency information database D11 for the player ID and acquires the player's held tickets, free currency, paid currency, number of times accumulated and provided, and purchase history information (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).

When the store presentation 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 accumulated offers, 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) shows an example when no one-day-limited card has been purchased.

When the player selects 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 for which the card purchase button was selected according to this order.

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 sent to the game server 2. Figure 35 is a diagram illustrating the transition of the store screen displayed on the player terminal 1 when purchasing a card. In the example of Figure 35(a), the purchase card button 92 is selected. After the purchase card button 92 is selected, the store display control unit 109 notifies the player that the currency to be consumed will be the ticket with the highest priority (Figure 35(b)).

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 currency information database D11 with the consumed ticket amount (Step 212).

On the other hand, if the player does not have a ticket (Step 209), the store presentation control unit 109 consumes the second-priority free currency (Step 210) and determines whether the required currency is met (Step 211). If the required currency is not met (Step 211), the store presentation control unit 109 consumes the third-priority paid currency (Step 220) and determines whether the required currency is met (Step 221). If the required currency is met, the store presentation control unit 109 notifies the player, and when the purchase confirmation button is selected, sends a purchase confirmation to the game server 2. Figure 36 is a diagram explaining the transition of the store screen displayed on the player terminal 1 when purchasing a card. In the example of Figure 36(a), the card purchase button 93 is selected. After the purchase card button 93 is selected, the store presentation control unit 109 notifies the user that all of the free currency with the highest priority will be consumed, and that any shortfall will be made up by using paid currency (Figure 36 (b)).

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

Next, the store management unit 82 determines whether it is necessary to change the lottery probability that determines the type of card to be offered (Step 213). If the player's accumulated number of offers is equal to or greater than a predetermined upper limit (Step 214), the store management unit 82 changes the card lottery probability (Step 215). For example, the lottery probability for cards listed in the offered card information database D10 is changed so that at least one card with the highest rarity is always won. On the other hand, if the player's accumulated number of offers is not equal to or greater than the predetermined upper limit (Step 213), the store management unit 82 conducts a card lottery based on the winning probability in the offered card information database D10 (Step 216). Then, the store management unit 82 offers the winning card (Step 217).

Next, the store management unit 82 executes the process of updating the number of times the content has been stored (Step 218). Figure 37 is a flowchart of the process of updating the number of times the content has been stored.

The store management unit 82 calculates the accumulated provision count N=(N+n) (Step 231), where N is the accumulated provision count, n is the current provision count, and X is the upper limit (Step 230). 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 (N-X) and updates the accumulated provision count for the player ID in the player-held currency information database D11 to (N-X) (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 for the player ID in the player-held currency information database D11 to (N+n) (Step 234).
This completes the update process for the number of times stored and provided.

Figures 35(c) and 36(c) are examples of store screens displayed on the player terminal 1 after a card has been provided. Figure 35(c) is an example of a store screen when a card has been provided once by consuming a ticket, in which the number of owned tickets in the owned currency list 90 has decreased by one to 0, and the number of offers (accumulated offers) in the rarity determination gauge 94 has increased by one, from 60 to 61. On the other hand, Figure 36(c) is an example of a store screen when a card has been provided 10 times by consuming free currency and paid currency, in which the free currency and paid currency in the owned currency list 90 have decreased by the amount consumed (free currency has decreased from 800 to 0, and paid currency has decreased from 1,000 to 800). Furthermore, since the number of offers (accumulated offers) in the rarity determination gauge 94 exceeds the upper limit of 100, the gauge has reached the upper limit of 100 (Max state). Also, since the number of deliveries before delivery (accumulated number of deliveries) was 95, the carryover number of deliveries, 5 (= 105 - 100), is displayed as the current number of deliveries (accumulated number of deliveries).

In this embodiment, multiple actions are provided in the action part, and each action is configured to affect the status information of a first type of game element (character), and different second type of game elements (stones) can be obtained depending on the status information of the first type of game element (character). This configuration allows players to continue playing the game without getting bored, making it possible to provide a highly entertaining game.

In addition, because 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.

Furthermore, the transformation effect that occurs when transitioning from the action part to the battle part varies depending on the outcome of the actions in the action part, so the player will not get bored of the game and it is possible to provide a highly entertaining game. Similarly, the ending episode of the story's ending part will also vary depending on the outcome of the actions in the action part, so the player will not get bored of the game and it is possible to provide a highly entertaining game.

This embodiment also features a skip function that allows you to skip battles that have already been completed, allowing you to repeat the story without having to repeat the battles.

In addition, the store in this embodiment consumes the currency needed for the card in the order of tickets, free currency, and paid currency, allowing players to hold on to their valuable paid currency until the very end.

Furthermore, by giving players the opportunity to acquire high-rarity cards depending on the number of times cards are offered, it is possible to increase players' purchasing motivation.

<Modification of Store Operation>
The store described above operates on a permanent basis. However, providing various cards and items for a limited time, or offering special advantages, is an important factor in maintaining players' interest in the game and encouraging them to continue playing. Therefore, we will explain a variation of the store's method of providing items.

The modified example will be briefly described below.
In this modified method, items are provided for a limited time. Here, items include cards, tickets, and items that give an advantage in the game. The item provision includes multiple steps (stages), and each step has a set achievement condition. By achieving the achievement condition, the player can proceed to the next step. The items provided at each step, their rarity, and winning probability are disclosed to the user. The player checks the disclosed information for each step, provides the item, and obtains the item.

To execute the above item provision method, the game server 2 has a provision information database for each step. Figure 38 shows an example of the provision information database D20 for steps 1 to 4. The provision information database D20 for each step includes a field for the step's achievement conditions, a field for item rarity information, a field for the provided item, and a field for the probability of winning that item. The step's achievement conditions, the type of item provided, and the probability of winning that item differ for each step.

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, it reads information from the fields of 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 content of each step by selecting the tab for that step.

By fulfilling 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 once that is achieved, the player can proceed to Step 2.

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 conditions are met, makes it possible to provide the item for the next step. Note that when the last step is completed, the system may return to the first step and repeat the step provision cycle.
By adopting such a configuration, it is possible to maintain the player's interest in the game and encourage him or her to continue playing the game.

<Modification of the embodiment>
In the above embodiment, the success rate parameter 25 is only one, the energy 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 amount of recovery and the type of parameter to be recovered are determined by lottery (random function).

In addition, when the success rate parameter is lower than a predetermined value, the action part execution control unit 104 may display a message on the action part home screen 61 prompting the player to select Rest 23. In this case, it is preferable to display the message in a manner in which a sub-character is having a conversation.

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

If Rest 23 is selected when the action power points, which are the success rate parameter 25, are at their maximum value, one turn in the action part 12 will be wasted. Therefore, the action part execution control unit 104 may be configured to present a confirmation dialog asking whether it is okay to execute Rest 23 or whether there is no need to execute Rest 23, and not execute the rest performance. In other words, the action part execution control unit 104 may be configured to control the selection of Rest 23 after District Investigation 21 or Request Acceptance 22 has been selected.

In the above embodiment, a configuration was described in which the player's level is determined by the experience points granted to the player, but it may also be determined using the experience points granted to the player, the character's level, the stone's rank, etc.

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 progression.
<Changes to 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 a character's parameter.
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, the second embodiment will explain an example in which the character's level is increased by items.

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

In addition to the functions of the player terminal 1 of the first embodiment, the player terminal 1 in the second embodiment further includes the functions of a parameter change specification unit 110 and an item acquisition unit 111.

The parameter change specification unit 110 specifies the value of the level desired by the player. When a level change is requested, the parameter change specification unit 110 requests character level change screen information from the game server 2, 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 new level, and the experience points that are lacking, and receives the character level change screen information from the game server 2. The character level change screen 200 is then displayed based on the received character level change screen information.

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 new level, and the lacking experience points that are lacking compared to the required experience points, and a level specification 203 for specifying the level to be changed (raised).
When the player specifies a change level on the character level change screen 200 , the parameter change specification unit 110 transmits the specified level to the game server 2 .

The item acquisition unit 111 acquires surplus items, as described below.

In addition to the functions of the game server 2 in the first embodiment, the game server 2 in the second embodiment further includes the functions of a parameter management unit 83 and an item provision unit 84.

The parameter management unit 83 includes a player-owned character information database D12. Figure 43 shows an example of the player-owned character information database D12. The player-owned character information database D12 includes a field for the player ID, a field for the character's name, a field for the character's level, and a field for the character's experience points. When the parameter management unit 83 receives a request for character level change screen information, it references the player-owned currency information database D11 and the player-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 points, the experience points required to reach the new level, and the experience points that are lacking.

In addition, items that increase a character's level (referred to as experience point increase items) are awarded as rewards for completing the action part 12 and the battle part 14. In this embodiment, there are multiple types of experience point increase items depending on the amount of experience point they increase; in this embodiment, there are 1000 increase items that increase experience points by 1000, 100 increase items that increase experience points by 100, and 10 increase items that increase experience points by 10. However, the types are not limited to these and can be changed as needed.

Furthermore, when the parameter management unit 83 receives the designated level and the required experience points for changing to the designated level are insufficient, it selects an experience point increasing item that will make up for the lack of experience points. Here, there are the following methods for selecting an experience point increasing item.
- A method of selecting the experience point increasing items you own, starting with the item that increases the most experience points. This method minimizes the number of experience point increasing items you consume.
- A method of selecting the experience point increasing items to consume from among the experience point increasing items in possession so that the excess experience points are minimized. With this method, combinations of the experience point increasing items in possession are generated, the excess experience points for each combination are calculated, and the combination with the least excess experience points is selected.
- A method in which ranks are assigned to the lacking experience points, and the order of experience point increase items to be consumed is determined for each rank. For example, if the lacking experience points exceed 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 lacking experience points are 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 lacking experience points are 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. With this method, the types of experience point increase items to be consumed are predetermined, which has the advantage of reducing the processing load on the game server 2.
The above method is an example and may be changed as needed.

When excess experience points are generated by consuming an experience point increasing item selected by any of the methods, the parameter management unit 83 calculates the excess experience points.
Specifically, the parameter management unit 83
・Excess experience points = (owned experience points + experience points consumed from experience point increasing items) - required experience points are calculated, and an experience point increasing item equivalent to the excess experience points is provided. For example, if the owned experience points are 150, the experience points consumed from experience point increasing items are 1000, and the required experience points are 1000, the excess experience points are calculated as follows:
・Excess experience points 150 = (150 + 1000) - 1000
Then, the parameter management unit 83 notifies the item providing unit 84 of the surplus experience points, and updates the player's currency information database D11 with the consumed experience point increasing item.

The item providing unit 84 converts the notified surplus experience points into multiple types of experience point increasing items. For example, if the surplus experience points are 150, the item providing unit 84 converts the 150 surplus experience points into one 100 experience point increasing item and five 10 experience point increasing items. The experience point increasing items are then provided to the player, and the player-held currency information database D11 is updated with the provided experience point increasing items.

Next, we will explain the operation of the game server 2. Figure 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 references the player-owned currency information database D11 and the player-owned character information database D12 to obtain the type and number of items currently owned by the player, the current character level, and the current character's experience points, and calculates the experience points required and the 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 level, the current character's experience points, the experience points required and the lacking experience points to reach the new level (Step 252).

Next, upon receiving the designated level from the player terminal 1 (Step 252), the parameter management unit 83 selects an experience point increase item that will fill the missing experience points using a predetermined selection method (Step 254).

If the lack of experience points can be made up by consuming the selected experience point increase item, the parameter management unit 83 consumes the selected experience point increase 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 increase item and determines whether surplus experience points have been generated (Step 257). If surplus experience points have been generated, the parameter management unit 83 notifies the item provision unit 84 of the surplus experience points. The parameter management unit 83 also updates the experience point increase items in the player's currency information database D11 by the amount of the consumed experience point increase item.

On the other hand, if the lack of experience points cannot be met by consuming the experience point increasing items, the parameter management unit 83 notifies the player terminal 1 that there is a lack of experience point increasing items, and ends the processing (Step 260).

The item providing unit 84 receives the excess experience points, converts them into experience point-increasing items (Step 258), provides the converted experience point-increasing items, and updates the player's currency information database D11 with the provided experience point-increasing items (Step 259).

Figure 45 shows an example of a character level change screen displayed on the player terminal 1 after a level change. The character level change screen after a level change displays the level change 204, detailed information 205 about the surplus experience points, and details 206 about the experience point increase item that corresponds to the provided surplus experience points.

In the example above, the surplus experience points were exchanged for the same experience point-increasing item, but they may also be exchanged for other items of similar value.

This embodiment uses a level specification system in which the player specifies the level they wish to increase (change) to, allowing them to change to their desired level in a single process. Furthermore, any surplus experience points gained from changing levels are converted into items of the same value and provided to the player, so the player does not suffer any disadvantages.

<Game progress parameters>
There are game progress parameters required to progress through the game. These game progress parameters are not parameters of characters or the like, but game progress points required to progress or execute the game. For example, in this game, a player executes the action part 12, the battle part 14, etc. while consuming game progress points. These game progress points are restored over time, but the amount restored per unit time is set. Depending on the player, the number of plays may not match the amount restored, making it impossible to execute game play. Therefore, in some cases, game progress points may be restored by consuming items in addition to the restoration over time. Another example of the second embodiment is a method of processing parameters when such game progress points are restored by consuming items.

This section provides an overview of how game progress points are recovered by consuming items in the second embodiment. Figure 46 is a diagram illustrating how game progress points are recovered by consuming items.

First, at the start 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 each time a turn in action part 12 or a battle in the battle part is performed (Figure 46(b)). Meanwhile, apart from consumption, game progress points are recovered over time (Figure 46(c)). However, the upper limit of recovery is the first upper limit, and recovery beyond this limit will not occur.

Now, let's say the player attempts to recover game progress points using an item. Items that can recover game progress points include paid currency (including paid recovery items) and free recovery items. If the game progress points remaining after consuming paid currency (including paid recovery items) and free recovery items (after recovery) are below the first upper limit, both will be recovered normally (Figure 46 (d)).

However, in the case of paid currency (including paid recovery items), if the game progress points available after consuming (restoring) 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 are set to the first upper limit (Figure 46 (e)).

On the other hand, in the case of a free recovery item, if the game progress points after consuming (recovering) the free recovery item 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 consuming (recovering) the free recovery item 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, further recovery using free recovery items is prohibited until the game progress points fall below the second upper limit.

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 or a battle is executed. For example, 10 game progress points are consumed per turn in the action part, and 20 game progress points are consumed per battle in the battle part. On the other hand, 10 game progress points are recovered over time every hour. The action part execution control unit 105 and the battle part execution control unit 106 are assumed to be measuring the current number of game progress points.

When a player requests the recovery of game progress points, the parameter change specification unit 110 of the player terminal 1 displays a game progress point recovery screen 210. Figure 47 shows 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 on recovery items held. Information on held recovery items can be obtained by referencing the player-held currency information database D11. Note that in this embodiment, both free recovery items and paid currency (including paid recovery items) will recover 10 game progress points per item.

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

When the type and number of items to be used for recovery are received, the parameter management unit 83 of the game server 2 performs a game progress point recovery process. Figure 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 restores the game progress points over time (Step 281).

The parameter management unit 83 determines whether the player terminal 1 has requested the recovery of game executable points using items (Step 282). If the player terminal 1 has requested the recovery of 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).

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 using 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 game progress points according to the number of recovery items used (Step 288) and sets the game progress points to the recovered points (Step 289).

Figure 49 is an example of a notification screen after recovery when three free recovery items are consumed when the current number of game progress points is 75. In the example of Figure 49, a notification is displayed that the number of game progress points has recovered to 105, and the game progress point information 211 indicates that the recovery has exceeded the first upper limit. Figure 50 is an example of a notification screen after recovery when 13 free recovery items are consumed when the current number of game progress points is 75. In the example of Figure 50, a notification is displayed that the number of game progress points has recovered to 205, and the game progress point information 211 indicates that the recovery has exceeded the second upper limit. Furthermore, a notification is displayed that recovery using free recovery items is not possible until the number of game progress points falls below 200.

If the item used is paid currency (Step 285), the parameter management unit 83 restores game progress points according to the amount of paid currency used (Step 290). The parameter management unit 83 then determines whether the restored game progress points exceed the first upper limit (Step 291). If the restored game progress points exceed the first upper limit, the parameter management unit 83 discards the points that exceed the first upper limit and sets the game progress points to the first upper limit (Step 292). On the other hand, if the restored game progress points do not exceed the first upper limit (Step 291), the parameter management unit 83 sets the game progress points to the restored points (Step 289).

Figure 51 shows an example of a notification screen after recovery when the current number of points available for game progress is 75 and three paid currency units are consumed. The example in Figure 51 notifies the user that the number of points available for game progress has recovered to 100 points, and indicates that any points exceeding the first upper limit have been discarded.

As described above, this embodiment is configured to adjust the recovery of game progress points by setting two upper limits for free recovery items, and not allow the recovery of game progress points that exceed a first upper limit for paid items. This configuration has the effect of preventing users from spending excessive money by restricting unlimited recovery using paid currency, and preventing players from feeling a loss by preventing the loss of the amount of recovery using free items.
Paid currencies are items that restore game progress points, but are sold as a package containing multiple currencies in exchange for money. Paid currencies also include recovery items, but like paid currencies, they cannot restore game progress points beyond the first upper limit.
Free recovery items are not sold in packages in exchange for money, but are provided as rewards for completing the action part 12, the battle part 14, etc. Furthermore, free recovery items are prohibited from being acquired by exchanging them for paid currency or by converting them from paid currency.

Third Embodiment
A third embodiment will now be described.
In the third embodiment, the friend function of the above-described embodiment will be described in detail. As described above, the friend function is a function that allows a player other than the player to select (rent) a card of a third character, which is a main character owned by another player, as a sub-character.

Figure 54 is an example of a support character selection screen in this embodiment. The support character selection screen includes a search button 26. When the search button 26 is selected, the deck compilation unit 103 displays a search screen. Figure 55 is an example of the search screen.

When the search button 26 is selected on the support character selection screen, the deck compilation unit 103 searches the player information database D1 in the storage unit 55 for other players whose levels are within a predetermined range from the player's level and whose last login date and time (login information) of the player are within a predetermined range. The deck compilation unit 103 randomly extracts, from the search results, a predetermined ratio (a predetermined number) of other players that the player is following and other players that the player is not following. The deck compilation unit 103 displays the search screen with the extracted main character cards of the other players and information about the other players listed in the recommendation list 27 on the search screen in a selectable state.
In the following, we will explain using a configuration in which other players are searched for in the player information database D1 in the storage unit 55, but it is also possible to search for other players in the player information database D1 in the storage unit 72 of the game server 2, or to select either player information database D1 depending on the communication status.

The format of the third character cards displayed in the recommendation list 27 needs to include at least an image of the character's card, and may also include the other player's name, level, comments previously set by the other player, etc.

When an action part is performed with a deck containing a card of a third character, the deck compilation unit 103 grants a reward to other players who are holding the card of the third character. In other words, when another player performs an action part using one of the player's cards, the player who holds that card can obtain a reward. The reward content may vary depending on the follow status with respect to other players. For example, rewards may be granted in a way that makes them more advantageous to other players who are being followed, or other players who are mutually following each other, than to other players who are not being followed.

<Another Example of This Embodiment>
In the above, a configuration has been described in which cards of the main character can be rented, but a configuration in which cards of characters owned by other players can be rented instead of the main character may also be used.Furthermore, a configuration in which a player can set the cards of characters owned by the player as available for rental or not available for rental may also be used.

In the above, the deck compilation unit 103 was described as being configured to search the player information database D1 in the storage unit 55 for other players whose level is within a predetermined range from the player's level and whose last login date and time (login information) is within a predetermined range from the player's last login date and time (login information). However, it may also be configured to search for third character cards to rent using a user ID.

Alternatively, an update button may be provided on the search screen to update the display of the recommendation list 27. In this case, the deck compilation unit 103 will again randomly select other players from the results of an existing search, who are within a predetermined range of the player's level and whose last login date and time (login information) is within a predetermined range of the player's last login date and time (login information).

Furthermore, while the above description describes a configuration in which a card of a third character, which is a main character owned by a player other than the player, can be selected (rented) as a sub-character, it is also possible to select (rent) a second type of game element of another player. In such a configuration, the deck compilation unit displays a selection screen such as that shown in FIG. 56 and a search screen such as that shown in FIG. 57.

The present invention has been described above using preferred embodiments, but the present invention is not necessarily limited to the above embodiments and can be modified and implemented in various ways within the scope of its technical concept.

Some or all of the above embodiments may also be described as in the following notes, but are not limited to the following:

[Appendix 1]
Computer,
a group organizing means for organizing a group including at least one of the first type of game elements of the player and the first type of game elements of the other players and a second type of game element;
a presentation means for presenting the first type of game element and the second type of game element;
an action part execution means for executing an action part that changes an attribute value of a first type of game element of the group according to a result of an action selected by a player from at least one action;
a battle part execution means for executing a battle part in which the first type of game element of the player competes;
It functions as
The first type of game element of the other player includes level information of the player and level information within a predetermined range, and also includes last login information of the player and last login information within a predetermined range;
program.

[Appendix 2]
the presenting means presents selectable game elements of a first type of other players, the first type including the level information of the player and level information within a predetermined range, and the last login information of the player and last login information within a predetermined range;
10. The program according to claim 1.

[Appendix 3]
The presentation means
a predetermined number of first-type game elements of other players are randomly extracted from among the game elements of the first type which include the level information of the player and level information within a predetermined range, and which also include the last login information of the player and last login information within the predetermined range, and are presented for selection;
10. The program according to claim 1 or 2.

[Appendix 4]
the game presentation means extracts a first type of game element of another player whom the player is following and a first type of game element of another player whom the player is not following at a predetermined ratio, and presents the extracted first type of game element in a selectable manner;
4. The program according to any one of appendices 1 to 3.

[Appendix 5]
the group organizing means is capable of organizing a group including the updated first type of game element of the other player;
5. A program according to any one of claims 1 to 4.

[Appendix 6]
the battle part execution means executes the battle part using at least the attribute values of the second type of game elements.
6. A program according to any one of claims 1 to 5.

[Appendix 7]
The level information of the player changes depending on at least one of the execution of the action part and the execution of the battle part.
7. A program according to any one of claims 1 to 6.

[Appendix 8]
a bonus granting means for granting a bonus to another player on condition that the action part is executed;
8. The program according to claim 1, wherein the program functions as

[Appendix 9]
the reward granting means gives priority to a reward to be granted when a first type of game element of the other player being followed is selected over a reward to be granted when a first type of game element of the other player not being followed is selected.
9. A program according to any one of claims 1 to 8.

[Appendix 10]
a group organizing means for organizing a group including at least one of a first type of game element of the player and a first type of game element of another player and a second type of game element;
a presentation means for presenting the first type of game element and the second type of game element;
an action part execution means for executing an action part that changes an attribute value of a first type of game element of the group according to a result of an action selected by a player from at least one action;
a battle part execution means for executing a battle part in which the first type of game element of the player competes against each other;
Equipped with
The first type of game elements of the other players include level information of the player and level information within a predetermined range, and also include last login information of the player and last login information within a predetermined range;
Game device.

1 Player terminal 2 Game server 10 Deck organization part 11 Episode 12 Action part 13 Transformation part 14 Battle part 15 Ending part 16 Result part 80 Player information management unit 81 Game execution management unit 82 Store management unit 83 Parameter management unit 101 Player information management unit 102 Game execution control unit 103 Deck organization unit 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 unit 109 Store presentation control unit 110 Parameter change designation unit 111 Item acquisition unit

Claims (10)

Computer,
a deck organizing means for organizing a deck composed of a first group including a first type of game element of a player who will be a main character, a second group including the first type of game element of a sub-character, and a third group including a second type of game element of the player;
a presentation means for presenting a first type of game element possessed by the player, a first type of game element possessed by another player, and a second type of game element possessed by the player;
an action part execution means for executing an action part that changes an attribute value of a first type of game element of the main character according to a result of an action selected by a player from at least one action;
a battle part execution means for executing a battle part in which the first type of game element of the main character competes;
a second type of game element imparting means for imparting a new second type of game element having a rank determined based on the attribute value of the first type of game element of the main character after the action part has ended;
It functions as
the second group includes a first type of game element owned by the player and a first type of game element owned by another player and included as a main character in the deck of the other player;
the first type of game element that becomes the sub-character is a first type of game element of a character different from the main character of the player,
the presenting means presents a first type of game element that is included as a main character in a deck of another player who has level information within a predetermined range in addition to the level information of the player and who has final login information within a predetermined range in addition to the last login information of the player;
program. the presenting means presents selectably game elements of a first type included as main characters in decks of other players who have level information within a predetermined range that is the same as the level information of the player and who have last login information within a predetermined range that is the same as the last login information of the player;
The program according to claim 1. the presentation means randomly extracts a predetermined number of first-type game elements from first-type game elements included as main characters in decks of other players that include the player's level information and level information within a predetermined range, and that also include the player's last login information and last login information within the predetermined range, and presents the extracted first-type game elements selectably;
The program according to claim 1 or 2. the presentation means extracts a first type of game element of another player whom the player is following and a first type of game element of another player whom the player is not following at a predetermined ratio, and presents the extracted first type of game element in a selectable manner;
The program according to claim 3. the deck organizing means is capable of organizing a deck including the updated first type of game elements of the other player;
The program according to claim 4. the battle part execution means executes the battle part using at least the attribute values of the second type of game elements.
The program according to claim 5 . The level information of the player changes depending on at least one of the execution of the action part and the execution of the battle part.
The program according to claim 6. a reward granting means for granting a reward to another player on condition that the action part is executed;
The program according to claim 7, which causes the program to function as the reward granting means gives priority to a reward to be granted when a first type of game element of the other player being followed is selected over a reward to be granted when a first type of game element of the other player not being followed is selected.
The program according to claim 8. a group organizing means for organizing a deck consisting of a first group including a first type of game element of a player who will be a main character, a second group including the first type of game element of a sub-character , and a third group including a second type of game element of the player;
a presentation means for presenting a first type of game element possessed by the player, a first type of game element possessed by another player, and a second type of game element possessed by the player;
an action part execution means for executing an action part that changes an attribute value of a first type of game element of the main character according to a result of an action selected by a player from at least one action;
a battle part execution means for executing a battle part in which a first type of game element of the main character competes;
a second type of game element imparting means for imparting a new second type of game element having a rank determined based on the attribute value of the first type of game element of the main character after the action part has ended;
Equipped with
the second group includes a first type of game element owned by the player and a first type of game element owned by another player and included as a main character in the deck of the other player;
the first type of game element that becomes the sub-character is a first type of game element of a character different from the main character of the player,
the presenting means presents a first type of game element that is included as a main character in a deck of another player who has level information within a predetermined range in addition to the level information of the player and who has final login information within a predetermined range in addition to the last login information of the player;
Game device.