Program and game device

Abstract

To provide highly engaging games. [Means for solving the problem] The program causes the computer to function as a deck management means for managing a deck used by a player in a competitive game, which includes a first type of character and a second type of character. A first type of character is a character that cannot directly attack an enemy character. A second type of character is a character that can directly attack an enemy character.

Description

Technical Field

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

Background Art

[0002] There is a so-called battle game in which characters operated by each of a plurality of users fight against each other. In this battle game, with regard to matching for a specific person, a technique for matching in consideration of the status of the target user has been proposed (for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Matching in a battle game is an important issue in providing a highly interesting game to players. Therefore, an object of the present invention is to provide a highly interesting program and a game device.

Means for Solving the Problems

[0005] One aspect of the present invention is a program for managing a battle game, which causes a computer to function as deck management means for managing a deck used by a player in a battle game, and matching means for matching the player with a battle player according to the number of times the player has executed a battle in the battle game using the deck.

[0006] One aspect of the present invention is a program for executing a competitive game, wherein the computer functions as a deck registration means for registering a deck composed of multiple characters that a player uses to play the competitive game, a competitive game request means for requesting the competitive game, and a competitive game execution means for executing the competitive game between the player and a matched competitive player in response to the request for the competitive game, wherein the matched competitive player is a competitive player corresponding to the number of times the player has played competitive games.

[0007] One aspect of the present invention is a game management device for managing a competitive game, comprising: a deck management means for managing a deck used by a player in a competitive game; and a matching means for matching a player with an opponent in a competitive game using the deck, based on the number of matches the player has played.

[0008] One aspect of the present invention is a game device for executing a competitive game, comprising: a deck registration means for registering a deck to be used by a player in a competitive game, which is composed of a plurality of characters; a competitive game request means for requesting the competitive game; and a competitive game execution means for executing the competitive game between the player and a matched competitive player in response to the request for the competitive game, wherein the matched competitive player is a competitive player corresponding to the number of times the player has played competitive games.

[0009] One aspect of the present invention comprises a game device on which a player runs a competitive game, and a game management device for managing the competitive game, wherein the game device is composed of a plurality of characters and includes a deck registration means for registering a deck to be used by the player in the competitive game. The game management device comprises a game request means for requesting the aforementioned game, a game execution means for executing the game between the player and a matched opponent in response to the game request, and the game management device further comprises a deck management means for managing the deck registered by the player, and a matching means for matching the player with an opponent according to the number of times the player has played a game in a game using the deck. [Effects of the Invention]

[0010] According to the present invention, it is possible to provide a highly entertaining game. [Brief explanation of the drawing]

[0011] [Figure 1] Figure 1 is a diagram showing an example of a game card 1 (game medium) in this embodiment, and shows an example of the front side (first side) and back side (second side) of the game card 1. [Figure 2] Figure 2 is a diagram illustrating an example of a battle screen. [Figure 3] Figure 3 shows an example of the overall configuration of the game system in this embodiment. [Figure 4] Figure 4 shows an example of a smartphone device configuration, which is an example of terminal 2. [Figure 5] Figure 5 is a block diagram showing an example of the functional configuration of terminal 2. [Figure 6] Figure 6 shows an example of each database in terminal 2. [Figure 7] Figure 7 is a block diagram showing an example of the functional configuration of game server 3. [Figure 8] Figure 8 shows an example of each database on game server 3. [Figure 9] Figure 9 is a sequence diagram between terminal 2 and game server 3. [Figure 10] Figure 10 shows an example of a home screen. [Figure 11]Figure 11 is a flowchart of the game card scanning process (Step 103). [Figure 12] Figure 12 is a diagram for explaining the reading operation of the pattern 11 of the game card 1. [Figure 13] Figure 13 is a flowchart of the deck registration process (Step 105). [Figure 14] Figure 14 is a diagram for explaining the deck registration screen. [Figure 15] Figure 15 is a flowchart for performing the first game execution process (Step 107). [Figure 16] Figure 16 is a diagram for explaining the first game. [Figure 17] Figure 17 is a flowchart of the deck management process (Step 106). [Figure 18] Figure 18 is a flowchart of the matching process (Step 110). [Figure 19] Figure 19 is a flowchart of the second game execution process (Step 111). [Figure 20] Figure 20 is a diagram showing an example of the battle screen. [Figure 21] Figure 21 is a flowchart of the attack turn process (Step 706) performed during the second game execution process (Step 111). [Figure 22] Figure 22 is a diagram showing an example of the battle screen when the character is in the first state. [Figure 23] Figure 23 is a diagram showing an example of the battle screen when the character transitions from the first state to the second state. [Figure 24] Figure 24 is an example of the second game result screen. [Figure 25] Figure 25 is an example of the battle player selection screen.

Mode for Carrying Out the Invention

[0012] Embodiments of the present invention will now be described. First, to facilitate understanding of these embodiments, the characters appearing in the game, the game medium used in the game, and an overview of the game will be explained.

[0013] <Overview of the Embodiment> The game in this embodiment uses a game medium to which characters are associated, and a game application that runs on the player's terminal. By acquiring the game medium, the player can register (acquire) the character associated with that game medium into the game application. The registered (acquired) character can then be used in the game application.

[0014] The game application in this embodiment features multiple characters. Each character is associated with a game medium. Characters can be people, virtual creatures, items, etc. Each character has character information. Character information is distinguished into first character information and second character information depending on whether or not it is displayed (printed) on the game medium. The first character information of the characters in this embodiment is mainly immutable information that does not change according to the progress of the game on the game application, for example, the character's profile information. Profile information includes information such as the character's name, birthplace, attributes, background, and initial ability values. All or part of the first character information is displayed (printed) on the game medium. The second character information of the characters in this embodiment is mainly variable information that changes according to the progress of the game on the game application, for example, the character's status information. Status information represents the character's abilities (various abilities (speed, attack power, defense power, etc.), hit points, magic points, experience points, level, acquired skills, etc.). Furthermore, the second character information is information that is not displayed (printed) on the game medium.

[0015] Furthermore, in this embodiment, characters can be divided into two types based on their roles in the competitive game, as described later. A first-type character is a character that does not directly attack enemy characters in the competitive game, but can activate skills that cause enemy characters to transition from a first state to a second state in order to gain an advantage in the game. Here, the first state is the character's normal state, and the second state is an abnormal state other than the normal state. For example, a second state could be the discovery of a character's weakness, or an undefendable state such as the character being asleep. A second-type character is a character that is assigned the role of attacking enemy characters, or the role of defending against attacks from enemy characters.

[0016] Some players aim not only to play games in game applications, but also to collect playable materials. Therefore, in this embodiment, the playable materials provided to players are not virtual, but tangible objects that players can actually perceive, and characters are associated with (embodied) these playable materials. The playable material is, for example, a game card, which is an item with physical volume (a real item). However, it is not limited to game cards; for example, it may be a figurine or other object that has the appearance of a character. The following description will focus on the case where the playable material is a game card.

[0017] Figure 1 is a diagram showing an example of a game card 1 (game medium) in this embodiment, and shows an example of the front side (first side) and back side (second side) of the game card 1.

[0018] The front (first side) of Game Card 1 (the game medium) displays a picture 11. The picture 11 of Game Card 1 includes a first character image 12, which is an image including the head and torso of the character associated with Game Card 1; a first background image 13, which is the background image of the first character image; and the first character information (profile information) 14 of that character. The first character information on the front (first side) of Game Card 1 in Figure 1 includes the character's name, character attributes, and character hit points. Note that the hit points listed on Game Card 1 are initial values, and as will be described later, the character's hit points will exceed the initial value as the character is used in the game. Note that the initial values ​​of other characters' abilities (various abilities (speed, attack power, defense power, etc.), magic points, experience points, level, learned skills, etc.) may also be included as first character information.

[0019] The back side (second side) of Game Card 1 (the game medium) displays the first character information 14 of the character associated with Game Card 1, and the second character image 15, which is an image of the character's head. The first character information on the back side (second side) of Game Card 1 in Figure 1 includes the character's background, birthplace, etc.

[0020] Furthermore, the first character information 14 displayed on the front or back of game card 1 does not need to display all of the character's first character information; it is sufficient if only a portion of the first character information is displayed.

[0021] Furthermore, as mentioned above, it should be noted that while all or part of the first character information (profile information) is displayed on the front or back of Game Card 1, the second character information (status information) is not displayed. This is because, due to design limitations of game cards and other play media, and the size of the play media, the amount of character information that can be displayed is limited. On the other hand, when a player acquires Game Card 1, they will want to know what kind of character the character on Game Card 1 is. Therefore, only the first character information, which does not change through the game after acquiring Game Card 1, is included.

[0022] Next, the game of this embodiment will be described. The game application of this embodiment allows the user to play both a first game and a second game.

[0023] The first game is a game played by the player alone using a character registered in the game application. Here, "played alone" means that it does not include games where the player competes against other players. Games played alone by the player include, but are not limited to, maze games or block-breaking games using characters registered in the game application. Furthermore, the results of playing the first game increase the status information of the character used, and the status information of the character used is updated. The updated status information of the character will also affect the second game using that character.

[0024] The second game is a competitive game in which players use characters registered in the game application to compete against other players (hereinafter sometimes referred to as "opponents").

[0025] While a single character may be used in the competitive game, this embodiment uses a team (hereinafter sometimes referred to as a deck) composed of multiple characters. Players can freely assemble a deck by selecting characters to make up the deck (hereinafter sometimes referred to as deck-component characters) from the characters registered in the game application. The deck used in the competitive game in this embodiment consists of one character of type 1 and three characters of type 2, selected from the characters owned by the player. The assembled deck can be registered in the game application and also registered on the game server that operates the game. At this time, players can also register multiple decks.

[0026] The opposing players in the second game can be real players, or they can be so-called non-player characters controlled by the computer. If the opposing players are non-player characters, there are two ways to design the decks they use.

[0027] The first method involves non-player characters using decks provided by the game's operators. In this case, the operators can freely set the decks, which has the advantage of allowing them to adjust the strength of the non-player characters. For example, to make a non-player character weaker, they can make the deck consist of characters with low status information, and to make a non-player character stronger, they can make the deck consist of characters with high status information. Non-player characters that use decks provided by the game operators in this way are referred to as Type 1 non-player characters.

[0028] The second method involves using decks actually registered by real players. As mentioned above, players can register decks to use in the game. Since the status information of each character differs depending on the player, even decks composed of the same characters will have different overall strengths. Therefore, a wide variety of decks exist, and the strength of the non-player characters using them also varies, resulting in the advantage of a more varied competitive game. Non-player characters that use decks registered by real players in this way will be referred to as the second type of non-player character.

[0029] Next, let's discuss player-versus-player matching. Matching can be done regardless of the opponent's level (strength). However, beginner players with few matches experience often don't understand how to play well, and their decks tend to consist mainly of characters with low stats, making them less likely to win matches. If beginner players with little experience in competitive games are repeatedly matched with high-level players, the beginner players will suffer repeated losses, lose interest in competitive games, and eventually lose interest in games altogether.

[0030] Therefore, in this embodiment, players are matched with opponents based on the number of matches the player has played. Here, the number of matches played is, for example, the cumulative number of matches played. Matching a player with an opponent based on the number of matches played by a player is such that if the number of matches played is low, the player is matched with an opponent with a low skill level, and if the number of matches played is high, the player is matched with an opponent randomly. Here, the skill level can be determined by referring to the skill level of the opponent, but it is not always the case that an opponent with a skill level appropriate for the number of matches played by the player is participating in the game at the time of matching, and there is a possibility that proper matching may not be possible.

[0031] Therefore, in this embodiment, in order to achieve proper matching, matching is performed using the following method with a first type of non-player character and a second type of non-player character.

[0032] (1) If the cumulative number of matches played by a player is less than or equal to a predetermined number, the player is matched with a non-player character of type 1. At this time, the deck level of the deck used by the player is referenced, and the non-player character of type 1 is made to use a deck with a lower deck level than the player's deck level. Here, the deck level is affected by the levels of the deck-making characters that make up the deck, so in this embodiment, the sum of the levels of the deck-making characters is used as the deck level. By performing such matching, if the cumulative number of matches played by a player is less than or equal to a predetermined number, the player will be matched with a non-player character using a deck with a lower deck level than the deck used by the player, thereby increasing the probability of victory for beginner players with a low cumulative number of matches played and preventing them from losing interest in the game.

[0033] (2) If a player's cumulative number of matches exceeds a predetermined number, the player will be matched with a randomly selected second-type non-player character. Players who have exceeded the predetermined number of cumulative matches will have become accustomed to the game and will likely desire a variety of matches. Therefore, players who have exceeded the predetermined number of cumulative matches will be matched with second-type non-player characters who use various decks registered by other real players, thereby enabling them to participate in a variety of matches.

[0034] Furthermore, the player's cumulative number of matches played can also be used as the player's cumulative number of wins. Using the player's win count allows for a more accurate assessment of the player's skill level in competitive games.

[0035] Additionally, while it is permissible to notify other players that a deck registered by a Type 2 non-player character has been used, notification is generally not required.

[0036] Next, I will explain the competitive game (Game 2). On the player's device, the match screen for the matched opponent is displayed. Figure 2 shows an example of the match screen for a competitive game.

[0037] The battle screen displays the character images of the four characters that make up Player A's deck: PAC1, PAC2, PAC3, and PAC4, and the character images of the four characters that make up Player B's deck: PBC1, PBC2, PBC3, and PBC4. Characters PAC1 and PBC1 are Type 1 characters. Characters PAC2, PAC3, and PAC4, and characters PBC2, PBC3, and PBC4 are Type 2 characters.

[0038] Characters PAC1 and PBC1, which are Type 1 characters, can activate skills that transition enemy characters from their first state to their second state. Here, the first state is the character's normal state, and the second state is any other state, such as an abnormal state. For example, the second state could be the discovery of a character's weakness or the character being in an undefendable state like sleep. In the following explanation, the character that activates the skill that transitions enemy characters from their first state to their second state will be referred to as a Type 1 character, but it is not limited to this, and may also be a Type 2 character.

[0039] The second type of characters, PAC2, PAC3, PAC4, and PBC2, PBC3, PBC4, are characters that can attack enemy characters or defend against attacks from enemy characters.

[0040] In this versus game, players and their opponents' combat-ready characters take turns attacking in order of their speed. Each turn includes an action order calculation phase, a skill activation phase, and an attack phase.

[0041] The action order calculation phase determines which of the player's and opponent's combat-capable second-type characters will perform the attack (sometimes referred to as the attacking character). For example, if player A's character PAC2 has a speed of 50, player A's character PAC3 has a speed of 90, and player A's character PAC4 has a speed of 40, and opponent player B's character PBC2 has a speed of 45, player B's character PBC3 has a speed of 82, and player B's character PBC4 has a speed of 60, then player A's character PAC3, which has the highest speed, will be the attacking character.

[0042] The skill activation phase is the phase in which a character of type 1 can activate a skill. In this embodiment, the skill that a character of type 1 can activate is a weakness detection skill that discovers the weakness attribute of an opponent's enemy character. The number of times this weakness detection skill can be activated (at least once) is determined according to the level of the character of type 1. The weakness detection skill can be activated by the player at any skill activation phase, and when activated, it discovers the weakness attribute of one enemy character at random (excluding characters whose attributes have already been revealed). At this time, the weakness attribute is displayed near the character whose weakness attribute was discovered. In other words, it indicates that the character has transitioned from the first state to the second state.

[0043] The attack phase is the phase in which the characters determined as attacking characters in the action order calculation phase attack enemy characters. Here, the method for selecting the target character to attack differs depending on the state of the enemy character.

[0044] In the normal state (first state), where the weaknesses of all enemy characters are unknown, a target character is randomly selected from the enemy characters. This random selection of a target character is referred to as the first target selection method. On the other hand, in the skill activation phase, if the attributes of the enemy characters are known and the weaknesses of at least one enemy character are known (second state), the attack character whose weakness is known is selected preferentially as the attack character. This method of preferentially selecting an enemy character whose weakness is known (second state) as the attack character is referred to as the second target selection method. In the second target selection method, the attribute of the attack character may not be the weakness attribute of an enemy character whose weakness is known. In this case, regardless of the attribute of the attack character, the enemy character whose weakness is known may be selected preferentially as the attack character, or, as in the first target selection method, a target character may be randomly selected from the enemy characters. Characters selected as targets for attack will be displayed in a way that allows them to be visually distinguished from other characters.

[0045] Damage dealt to an enemy character is calculated based on the attacking character's status information (e.g., attack power) and the target character's status information (e.g., defense power). In this case, for example, if the attacking character's attribute is advantageous against the target character's attribute (i.e., the target character is attacked by an attacking character with a weak attribute), the damage dealt is calculated as 1.5 times the normal damage. This allows for attacks that deal significant damage to enemy characters in the second target selection mode, enabling players to gain an advantage in the game.

[0046] Figure 2 is a diagram illustrating an example of a battle screen. In the battle screen of Figure 2, before the activation of the Weakness Discovery skill, the weak attribute of all enemy characters PBC2, PBC3, and PBC4 is unknown. That is, all of the opposing player's characters are in the first state. Therefore, the target character for attack character PAC3 is selected according to the first target selection method, and character PAC3 attacks the randomly selected enemy character PBC2. On the other hand, if the Weakness Discovery skill is activated during the skill activation phase and the weak attribute of enemy character PBC3 is revealed to be "Water", then at least one enemy character is in the second state. At this time, the target character for attack character PAC3 is selected according to the second target selection method. At this time, if the attribute of character PAC3 is "Water", then enemy character PBC3, whose weak attribute "Water" has been revealed, is preferentially selected as the target character, and character PAC3 attacks the selected enemy character PBC3. Furthermore, if the attacking character PAC3 does not have the "Water" attribute, you may select enemy character PBC3, whose weakness attribute is "Water," as the target character, or you may randomly select another enemy character.

[0047] When an attack is made against an enemy character in this manner, the damage dealt to the enemy character is calculated, and that calculated damage is subtracted from the remaining hit points of the attacked enemy character. If the enemy character's remaining hit points reach 0, it is determined that the enemy character is incapacitated, and the character image of that enemy character is removed from the battle screen.

[0048] This attack turn is performed for all combat-ready characters, and this constitutes one cycle, which is then repeated. The game ends when all of one player's characters become incapacitated, and the player whose characters are all incapacitated loses.

[0049] Once a winner is determined, the status information of the characters in each player's deck is increased, and the winning player's win count is increased by 1. At this time, evaluation information (titles, etc.) may be awarded to players according to their win count. The above is an overview of the second game.

[0050] <Configuration of the embodiment> The game system in this embodiment will now be described.

[0051] Figure 3 shows an example of the overall configuration of the game system in this embodiment. As shown in Figure 3, the game system is composed of a game card 1, a terminal 2 provided for each player, and a game server 3. The terminal 2 and the game server 3 can connect to a communication line N and communicate with each other.

[0052] Communication line N refers to a communication path capable of data communication. In other words, communication line N includes not only dedicated lines (dedicated cables) for direct connection and LANs using Ethernet (registered trademark), but also communication networks such as telephone networks, cable networks, and the Internet, and the communication method can be wired or wireless.

[0053] Terminal 2 is a computer capable of running game applications, and can connect to a communication line N via a wireless communication base station or the like, and communicate data with the game server 3. Examples of Terminal 2 include smartphones, mobile phones, portable game consoles, home consoles, arcade game consoles, personal computers, tablet computers, and controllers for home consoles. Basically, there are multiple Terminal 2s, each operated by a different player.

[0054] Figure 4 shows an example of the device configuration of a smartphone, which is an example of terminal 2. As shown in Figure 4, terminal 2 comprises a display 21, a touch operation panel 22 integrated with the display 21, a built-in speaker 23, and a camera 24. Terminal 2 also includes a control board, a built-in battery, a power button, volume control buttons, etc., which are not shown. The control board is equipped with various microprocessors such as a CPU, GPU, and DSP, an ASIC, various IC memories such as VRAM, RAM, and ROM, and a wireless communication module for wireless communication with a mobile phone base station. The control board is also equipped with so-called I / F circuits (interface circuits), such as the driver circuit for the touch operation panel 22. Each of these elements mounted on the control board is electrically connected via a bus circuit, etc., enabling data reading and writing and signal transmission and reception.

[0055] Figure 5 is a block diagram showing an example of the functional configuration of terminal 2. As shown in Figure 5, terminal 2 includes an operation input unit 31, a reading unit 32, a display unit 33, an audio output unit 34, a communication unit 35, a storage unit 36, and a processing unit 37.

[0056] The operation input unit 31 is for the player to input various game-related operations and outputs an operation input signal to the processing unit 37 according to the operation input. The functions of the operation input unit 31 can be realized not only by elements that the player directly operates with their fingers, such as a touch operation pad, home button, button switch, joystick, and trackball, but also by elements that detect movement and posture, such as an accelerometer, angular velocity sensor, tilt sensor, and geomagnetic sensor. In the example of the smartphone in Figure 4, the operation input unit 31 corresponds to the touch operation panel 22.

[0057] The reading unit 32 is a photographic device consisting of an image sensor and the like. In the example of the smartphone in Figure 4, the reading unit 32 corresponds to the camera 24.

[0058] The display unit 33 displays various game screens based on image signals input from the image generation unit 41. The functions of the display unit 33 can be realized by display devices such as flat panel displays like liquid crystal displays, cathode ray tubes (CRTs), projectors, and head-mounted displays. In the example of the smartphone in Figure 4, the display unit 33 corresponds to the display 21.

[0059] The sound output unit 34 is for outputting sound effects and the like related to the game based on the sound signal input from the sound generation unit 42. In the example of the smartphone in Figure 4, the sound output unit 34 corresponds to the speaker 23.

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

[0061] The memory unit 36 ​​pre-stores system programs, game programs, and data used during program execution, which are necessary for operating the terminal 2 and realizing its various functions. It also temporarily stores these programs each time processing is performed. The memory unit 36 ​​can be implemented using, for example, a solid-state drive with IC memory such as RAM, ROM, or flash memory, a magnetic disk such as a hard disk, or an optical disk such as a CD-ROM or DVD. The system program is a program that realizes the basic computer functions of the terminal 2. The game program is a program that causes the processing unit 37 to function as the game calculation unit 40, which will be described later. This game program is distributed from the game server 3 or another application distribution server. The memory unit 36 ​​also stores a database necessary for running the game.

[0062] In this embodiment, the storage unit 36 ​​stores a player database 1 (DB1), a character information database 2 (DB2), a character image database 3 (DB3), a owned character database 4 (DB4), and a player deck database 5 (DB5). Figure 6 shows an example of each database in the terminal 2.

[0063] Player DB1 is a database of player information. Each record in Player DB1 includes a player ID field, a player name (nickname) field, a field for the cumulative number of matches played in the player's second game, a field for the number of wins in the player's second game, and a field for the player's title.

[0064] Character Information DB2 is a database of information about characters. Each record in Character Information DB2 includes a field for card number, a field for character ID (identification information), a field for image feature data, a field for first character information, and a field for second character information. Each field stores its respective data. The card number is an identification number assigned to each type of game card 1. The character ID is an identification number assigned to each character. The image feature data is data on the feature quantities of the image 11 displayed (printed) on the surface of game card 1. The first character information and second character information are the information described above.

[0065] Character Image DB3 is a database of character images. Each record in Character Image DB3 includes a Character ID field, a field for the character image for listing, a field for the character image for the first game, and a field for the character image for the second game. The character image for listing is used for deck building, etc. The character image for the first game is used in the first game. The character image for the second game is used in the second game.

[0066] The Character Database 4 is a database of characters owned by the player. Each record in the Character Database 4 includes a field for card number, a field for character ID, a field for ownership flag, a field for status information, and a field for level. The ownership flag ("1") is set for characters registered to the game application from game card 1, as described later. This means that the player owns the character associated with game card 1. The status information is the character's current status and is updated when the first and second games are played. The level is the character's level and is updated when the first and second games are played.

[0067] The Player Deck DB5 is a database containing information about decks created by players. It includes a field for the deck number (name) and a field for the character IDs of the characters that make up that deck. These databases can be downloaded sequentially from game server 3 as characters used in the game are added or changed.

[0068] The processing unit 37 comprehensively controls the operation of the terminal 2 based on programs and data stored in the memory unit 36, various input signals from the operation input unit 31 and the reading unit 32, etc. The functions of the processing unit 37 can be realized by electronic components such as a microprocessor such as a CPU or GPU, an ASIC, or an IC memory. The main functional units of this processing unit 37 include a game calculation unit 40, an image generation unit 41, a sound generation unit 42, and a communication control unit 43.

[0069] The game calculation unit 40 performs various game processes to realize the game of this embodiment and outputs the processing results to the image generation unit 41, the sound generation unit 42, or the communication control unit 43. The game calculation unit 40 includes a game management unit 50, an operation detection unit 51, a game card reading control unit 52, a character recognition unit 53, a presentation control unit 54, a deck registration unit 55, a first game execution control unit 56, and a second game execution control unit 57.

[0070] The Game Management Unit 50 is responsible for updating each database and managing and executing the entire game.

[0071] The operation detection unit 51 detects signals input from the operation input unit 31 and detects player operations. The player operations to be detected include, for example, taps (selections), slides, swipes, pinches, and drops.

[0072] The game card reading control unit 52 controls the reading unit 32 (camera 24) to read the image on the surface of the game card 1. To control the reading process, the game card reading control unit 52 displays guidelines and operation information for reading the game card 1 on the display unit 33. The game card reading control unit 52 then outputs the image data of the image on the surface of the read game card 1 to the character recognition unit 53.

[0073] The character recognition unit 53 uses the image feature data of each game card 1 in the character information DB2 to recognize the character associated with the image on the surface of the read game card 1 using known image recognition technology. If the character recognition unit 53 can recognize a character, it sets the ownership flag ("1") in the ownership flag field of the owned character DB4. As a result, the character associated with game card 1 is registered in the game application, and the player acquires (owns) the character associated with game card 1. In other words, the character with the ownership flag ("1") set in the ownership flag field of the owned character DB4 becomes the character owned by the player.

[0074] The display control unit 54 displays images or home screens (menu screens), etc., necessary for running the game on the display unit 33.

[0075] The deck registration unit 55 assembles and registers a deck to be used in the second game from the characters the player owns. The deck registration unit 55 displays an input field for the name of the deck to be registered and a list of the player's characters. The deck registration unit 55 registers the character ID of one first-type character selected from the list, the character IDs of three second-type characters, and the entered deck name in the player deck DB5. The deck registration unit 55 also sends player deck configuration information, including the player's player ID, the name of the newly assembled deck, and the character IDs of the characters that make up that deck, to the game server 3. Players can also register multiple decks.

[0076] The first game execution control unit 56 executes the first game using the acquired character. The first game is a game in which the player controls the character selected by the player. The first game is executed when the menu button on the home screen is selected. The status information of the character used in the game increases upon execution. The first game execution control unit 56 increases the status information of the character used in the first game and updates the status information in the owned character DB4. The first game execution control unit 56 also sends the updated status information to the game server 3.

[0077] The second game execution control unit 57 executes the second game, which is a competitive game using a deck. The second game execution control unit 57 comprises a competitive game request unit 571, a character presentation control unit 572, a character state presentation unit 573, an attack target character selection unit 574, and an attack control unit 575.

[0078] The battle game request unit 571 sends battle game request information to the game server 3 to request matching of players for a battle game. The battle game request information includes the player's player ID and the name of the deck to be used in the battle game. If a player has registered multiple decks, the battle game request unit 571 displays the registered decks on the battle request screen and includes the name of the deck selected by the player as the deck to be used in the battle game in the battle game request information.

[0079] Furthermore, the battle game request unit 571 receives battle player deck configuration information from the game server 3. The battle player deck configuration information includes the battle player's player ID, battle player name (including title), and battle player deck configuration character information for the characters that make up the deck used in the battle. The battle player name (including title) is the player name (including title) set by the operator in the case of a first-type non-player character, and in the case of a second-type non-player character, it is the name (including title) of another player who registered the deck used by the second-type non-player character. The battle player deck configuration character information includes the character ID of the characters that make up the deck used in the battle, and status information of the characters that make up the deck.

[0080] The character display control unit 572 reads the character IDs of the characters in the deck used for the match from the player deck DB5 and reads the second game image for that character ID from the character image DB3. The character display control unit 572 also reads the second game image for the character IDs of the characters in the opponent's deck from the character image DB3 based on the match play deck configuration information. Then, the character display control unit 572 displays the match screen.

[0081] The character state control unit 573 controls the character's state, transitioning the character from the first state to the second state through actions such as skill activation. The character state control unit 573 also displays whether the character's current state is the first state or the second state. In this embodiment, the character state control unit 573 controls the character to maintain the second state until the end of the game once the character has transitioned from the first state to the second state, but this is not limited to this. For example, the character may transition from the second state to the first state over time, or from the second state to the first state through the activation of other skills.

[0082] Regarding the relationship between the duration of a character's first state and the duration of their second state, considering the enjoyment of the battle, it is preferable for the duration of a character's second state to be shorter than the duration of their first state. In particular, it is preferable that at least one character's second state duration is shorter than the duration of all characters' first state. The character state control unit 573 controls the character so that at least one character's second state duration is shorter than the duration of all characters' first state. However, it is not limited to this, and it is also possible to control the character so that the duration of a character's second state is longer than the duration of their first state.

[0083] The attack target character selection unit 574, during an attack turn, selects either a first attack target selection mode or a second attack target selection mode depending on the character's state, and selects an attack target character from the opposing player's characters according to the selected mode. Specifically, if the attack target character selection unit 574 is in a normal state (first state) where the weaknesses of all of the opposing player's enemy characters are unknown, it randomly selects an attack target character from the enemy characters according to the first attack target selection mode. If the attack target character selection unit 574 is in a state where the weaknesses of at least one enemy character are known (second state), it preferentially selects an attack character whose weakness is known as the attack character according to the second attack target selection mode. Furthermore, in the second attack target selection mode, if the attack character's attribute is not the weakness attribute of an enemy character whose weakness is known, it preferentially selects an enemy character whose weakness is known as the attack character, regardless of the attack character's attribute. Furthermore, the target character selection unit 574 may randomly select a target character from enemy characters, similar to the first target selection mode. In this embodiment, the target character selection unit 574 selects either the first or second target selection mode depending on the character's state, but the number of times the second target selection mode is selected may be limited.

[0084] The attack control unit 575 controls the attack turn, which includes the action order calculation phase, the skill activation phase, and the attack phase, and controls the battle, including damage calculation. The attack control unit 575 also presents the character that has been targeted for attack in a manner that allows it to be identified from other characters.

[0085] Next, I will explain game server 3. Figure 7 is a block diagram showing an example of the functional configuration of the game server 3. The game server 3 comprises a storage unit 60, a communication unit 61, and a processing unit 62.

[0086] The memory unit 60 is implemented by, for example, IC memory such as RAM, ROM, or flash memory, magnetic disks such as hard disks, or optical disks such as CD-ROMs or DVDs, and stores system programs and functional programs. The system program is a program that implements the basic functions of the computer. The functional program is a program that causes the processing unit 62 to perform the function of managing games.

[0087] In this embodiment, the storage unit 61 stores a player management database 10 (DB10), a game operation deck management database 11 (DB11), a player deck management database 12 (DB12), a character information database 13 (DB13), and a player-owned character database 14 (DB14) for each player. Figure 8 shows an example of each database of the game server 3.

[0088] Player Management DB10 is a database for managing players. Each record in Player Management DB10 includes a player ID field, a player name (nickname) field, a field for the cumulative number of matches played in the player's second game, a field for the number of wins in the player's second game, and a field for the player's title.

[0089] The Game Operation Deck Management DB11 is a database for managing game operation decks. Each record in the Game Operation Deck Management DB11 includes a field for the player's name set by the game operator, a field for the deck's name, a field for the character IDs of the characters that make up the deck, and a field for the deck's level. The Game Operation Deck Management DB11 has multiple levels of decks registered to correspond to the player's deck level.

[0090] The Player Deck Management DB12 is a database that manages players' decks. Each record in the Player Deck Management DB12 includes a field for the player ID, a field for the name of the deck, a field for the character IDs of the characters that make up the deck, and a field for the deck level.

[0091] Character Information DB13 is a database of information about characters. Each record in Character Information DB13 includes a card number field, a character ID (identification information) field, an image feature data field, a first character information field, and a second character information field. Each field stores its respective data. The card number is an identification number assigned to each type of game card 1. The character ID is an identification number assigned to each character. The image feature data is data on the feature quantities of the image 11 displayed (printed) on the surface of game card 1. The first character information and second character information are the information described above.

[0092] The Player Character Database (DB14) for each player (Player ID) is a database that manages the characters owned by each player. A Player Character Database (DB14) is prepared for each Player ID. Each record in the Player Character Database (DB14) includes a Player ID field, a Character ID field, an Ownership Flag field, a Status Information field, and a Level field. The Ownership Flag ("1") is set for characters registered to the game application from Game Card 1. This means that the player owns the character associated with Game Card 1. The Status Information is the character's current status and is updated when the first and second games are played. The Level is the character's level and is updated when the first and second games are played.

[0093] The communication unit 61 is responsible for performing communication with terminal 2. The communication unit 61 connects to the communication line N to achieve communication. The functions of the communication unit 61 can be realized by, for example, a wireless communication device, a modem, a TA (terminal adapter), a jack or control circuit for a wired communication cable, etc.

[0094] The processing unit 62 comprehensively controls the operation of the game server 3 based on the programs and data stored in the memory unit 60. The functions of the processing unit 62 can be realized by electronic components such as a microprocessor such as a CPU or GPU, an ASIC, or an IC memory. The main functional units of this processing unit 62 include a player information management unit 70, a player deck management unit 71, a matching unit 72, and an evaluation information update unit 73.

[0095] The Player Information Management Unit 70 manages the Player Management DB 10, the Game Operation Deck Management DB 11, the Character Information DB 13, and the Player-Owned Character DB 14 for each player, and updates each database. The Player Deck Management Unit 71 manages the Player Deck Management DB 12 and updates the database.

[0096] The matching unit 72 responds to the battle game request information from terminal 2 and matches the player with an opponent. The matching unit 72 refers to the player management DB 10 and, if the player's cumulative number of battles played is less than or equal to a predetermined number, matches the player with a non-player character of type 1. At this time, it refers to the deck level of the deck used by the player and selects a deck with a lower deck level than the player's deck level from the game operation deck management DB 11. If the deck level is lower than the player's deck level, it may also randomly select a deck from the game operation deck management DB 11. Then, the matching unit 72 sends battle play deck configuration information, including the player name (including title), deck level, and status information of the characters in the deck, to terminal 2.

[0097] Furthermore, the matching unit 72 refers to the player management DB 10, and if the cumulative number of matches a player has played exceeds a predetermined number, it randomly selects a deck from the player deck management DB 12 and sets the selected deck as the deck to be used by the second type of non-player character. The matching unit 72 then transmits the match play deck configuration information, including the player name (including title), deck level, and status information of the characters that make up the deck, to the terminal 2.

[0098] The evaluation information update unit 73 refers to the player management DB 10 and updates the player's title field in the player management DB 10 according to the number of wins in the second game. In this embodiment, players are given titles according to the number of wins. Titles according to the number of wins are, for example, Warrior for 0 to 10 wins, Knight for 11 to 30 wins, ..., King, etc. Note that titles are just one example of evaluation information, and other titles that evaluate the player may be used.

[0099] <Prototype of the embodiment> The operation of this embodiment will now be described. Figure 9 is a sequence diagram between terminal 2 and game server 3.

[0100] First, when the player launches the game application, the game management unit 50 of terminal 2 performs a player registration request process (Step 100). The game management unit 50 sends a player registration request to the game server 3, which includes the player's desired player name (nickname).

[0101] The player information management unit 70 of game server 3 receives a player registration request and performs player registration processing (Step 101). The player information management unit 70 determines whether the player name (nickname) is a duplicate of an already registered player name (nickname), and if there is no duplicate, assigns a player ID. The player information management unit 70 newly registers the player ID and player name (nickname) in the player management DB 10. Then, the player information management unit 70 sends the approval of the player name (nickname) and the assigned player ID to terminal 2. The game management unit 50 of terminal 2 registers the received player ID in the player DB1. With the above steps completed, the player can now run the game.

[0102] After the player registers and launches the game application, the display control unit 54 of terminal 2 performs home screen processing (Step 102). The display control unit 54 displays the home screen on the display unit 33. The home screen includes menu buttons. Figure 10 shows an example of the home screen. The home screen in Figure 10 displays character images of characters owned (acquired) by the player, along with menu buttons (menu icons) 80 for "New Information," "Game Card Scan," "Deck Registration," "Execute First Game," "Execute Second Game," and "End Game." The player can execute each game by selecting one of the various menu buttons 80.

[0103] On the home screen described above, when the player selects the "Scan Game Card" button, terminal 2 performs the game card scanning process (Step 103). Figure 11 is a flowchart of the game card scanning process (Step 103).

[0104] When the operation detection unit 51 detects a touch of the "game card scan" button, the game card reading control unit 52 controls the reading unit 32 (camera 24) to enable photography and displays guidelines on the display unit 33 to guide the reading of the image 11 of the game card 1 (Step 200). Figure 12 is a diagram illustrating the reading operation of the image 11 of the game card 1. In the example in Figure 12, guidelines 85 with the same shape as the game card 1 and a scan start button 86 that instructs the start of scanning are displayed. The player operates the terminal 2 so that the outer edge of the game card 1, which is photographed by the reading unit 32 and displayed on the display unit 33, aligns with the guidelines 85. With the outer edge of the game card 1 aligned with the guidelines 85, the player touches the scan start button 86.

[0105] When the operation detection unit 51 detects a touch of the scan start button 86, the game card reading control unit 52 starts scanning the game card 1 (Step 201). The image 11 of the scanned game card 1 is output from the game card reading control unit 52 to the character recognition control unit 53.

[0106] The character recognition control unit 53 compares the image of the picture 11 on the scanned game card 1 with the feature data of each picture in the character information DB2 to identify the character corresponding to the picture 11 on the scanned game card 1 (Step 202).

[0107] If the character recognition control unit 53 can identify a character corresponding to the image 11 of the scanned game card 1 (Step 203), it sets the ownership flag in the ownership flag field of the owned character DB4 corresponding to the identified character (assigns "1") (Step 204). The character recognition control unit 53 displays on the display unit 33 that a character has been newly acquired (Step 205). The character recognition control unit 53 sends the character ID and player ID of the identified (owned flag set) character to the game server 3 (Step 206). Then, it returns to Step 102 (home screen). If the character can be identified but is already owned (ownership flag is already set), it displays that it is already owned and returns to Step 102 (home screen) in the same way. On the other hand, if the character recognition control unit 52 cannot identify the character corresponding to the image 11 of the scanned game card 1 (Step 203), it displays an error on the display unit 33 (Step 207) and returns to Step 102 (home screen). Through the above steps, the player can register the character associated with their game card 1 to the game application.

[0108] When the player information management unit 70 of the game server 3 receives the character ID and player ID from terminal 2, it performs a player information update process (Step 104). The player information management unit 70 sets the ownership flag (assigns "1") in the ownership flag field of the character ID in the player ownership character DB 14 corresponding to the received player ID. As a result, the player of the player ID can register the acquired character with the game server 3.

[0109] Next, the player can register a deck using the characters they have acquired. The deck registration process (Step 105) on terminal 2 will be explained. Figure 13 is a flowchart of the deck registration process (Step 105).

[0110] On the home screen, when the player selects the "Deck Registration" button and the operation detection unit 51 detects the touch of the "Deck Registration" button, the deck registration unit 55 reads information about the characters owned by the player from the owned character DB4 and character image DB3 (Step 300) and generates a list layout image (Step 301). Then, the deck registration unit 55 displays the deck registration screen on the display unit 33 (Step 302).

[0111] Figure 14 is a diagram illustrating the deck registration screen. The list layout image 90 is an image generated by placing list images of owned characters on a list layout map where the placement positions of characters are predetermined, and placing unowned images for characters that are not owned. Owned characters are those whose owned flag is set in the owned field of the owned character DB4. The deck registration screen comprises a list layout image display area 91 and a deck formation area 92 for forming a deck. As shown in Figure 14, in the initial display of this example, the list layout image 90 displayed in the list layout image display area 91 of the deck registration screen is an image corresponding to the range from the top of the list layout image 90 to the bottom of the list layout image display area 91. By flicking or swiping the screen of the list layout image display area 91, the player can scroll the list layout image 90 in the direction of the flick or swipe and view the list layout images 90 of characters that are not currently displayed. Additionally, the deck building area 92 displays a deck name input field 93, one character slot for type 1 94, three character slots for type 2 95, and a deck confirmation button 96.

[0112] The player enters the deck name in the deck name input field 93 (Step 303). The player selects one character of type 1 from the list layout image 90 displayed in the list layout image display area 91 (Step 304). The player can select a character of type 1 by dragging the image of the desired character from the list layout image 90 to the character of type 1 frame 94. The player selects three characters of type 2 from the list layout image 90 displayed in the list layout image display area 91 (Step 305). The player can select characters of type 2 by dragging the images of the desired characters from the list layout image 90 to the character of type 2 frame 95.

[0113] When the player presses the Deck Confirmation button 96 (Step 306), the Deck Registration Unit 55 updates the Player Deck DB5 using player deck configuration information that includes the player ID, the deck name entered in the Deck Name Input Field 93, and the character IDs of the characters placed in the first type character slot 94 and the second type character slot 95 (Step 307). The deck registration unit 55 sends the player deck configuration information to the game server 3 (Step 308). Based on the above, players can register their decks.

[0114] Furthermore, it is possible to reorganize a deck once it has been registered. In this case, the deck registration unit 55 displays a list of registered decks on the display unit 33, and displays the selected deck on the deck registration screen shown in Figure 14.

[0115] Next, we will discuss the first game, which affects the level of your deck. On the home screen described above, when the player selects the "Execute First Game" button, terminal 2 performs the first game execution process (Step 107). Figure 15 is a flowchart of the first game execution process (Step 107).

[0116] On the home screen, when the player selects the "Execute First Game" button and the operation detection unit 51 detects the touch of the "Execute First Game" button, the first game execution control unit 56 reads information about the characters owned by the player from the owned character DB4 and character image DB3 and displays a list of characters (Step 400).

[0117] Figure 16 is a diagram illustrating the first game. The first game execution control unit 56 displays a list of owned characters, an image 90, on the display unit 33. The player selects a character to play the first game from the list of owned characters, an image 90 (Step 401). The first game execution control unit 56 reads the game image of the selected character from the character image DB3 and executes the first game (Step 402). In the example in Figure 16, the player manipulates the game image of the selected character with their finger while playing the game. This game changes the status information (ability values ​​(speed, attack power, defense power, hit points, level, etc.)) of the character who played the first game. At this time, the first game execution control unit 56 starts the first game from the initial ability values ​​(e.g., initial level) included in the first character information, and after the game, controls the ability values ​​to increase so that they do not fall below those initial ability values. The first game execution control unit 56 calculates the result of the first game (Step 403) and displays the result of the first game (Step 404). The first game execution control unit 56 then transmits the first game result information to the game server 3. The first game result information includes the player ID, the character ID of the character that played the first game, and the character's status information (ability values ​​(speed, attack power, defense power, hit points, level, etc.)).

[0118] Upon receiving the first game result information, game server 3 performs player information update processing (Step 108). The player information management unit 70 of game server 3 updates the status information (ability values ​​(speed, attack power, defense power, hit points, level, etc.)) of the player's owned character DB 14 corresponding to the received player ID.

[0119] Next, we will explain the deck management process (Step 106) of game server 3. Figure 17 is a flowchart of the deck management process (Step 106).

[0120] When the game server 3 receives player deck configuration information (player ID, deck name, character IDs of the characters in the deck) (Step 500), the player deck management unit 71 registers the deck name and character IDs of the characters in the deck in the player ID record of the player deck management DB 12 (Step 501). The player deck management unit 71 retrieves the level of each character in the deck from the player owned character DB 14 using their character ID as the key, and calculates the deck level of that deck (Step 502). In this embodiment, for example, the deck level is the sum of the levels of the characters in the deck. Then, the player deck management unit 71 updates the deck level in the player ID record of the player deck management DB 12 (Step 503).

[0121] Next, when the status information of the player's character is updated due to the execution of the first game or the second game, etc. (Step 504), the player deck management unit 71 determines whether there has been a change in the level of the characters in the player's owned character DB 14 deck (Step 505). If there has been a change in the level of the characters in the deck (Step 505), the player deck management unit 71 obtains the level of each character in the deck, calculates the deck level (Step 502), and updates the deck level of the player ID record in the player deck management DB 12 (Step 503).

[0122] Through the above actions, players can register their decks with game server 3, and furthermore, even if the levels of the characters in a player's registered deck change due to the execution of the first and second games, the level of the registered deck can be updated to the latest level.

[0123] Next, we will explain how to play the second game (a versus game). On the home screen described above, when the player selects the "Execute Second Game" button, the battle game request unit 571 of terminal 2 performs the second game execution request process (Step 109). The battle game request unit 571 of terminal 2 sends battle game request information, including the player ID, to the game server 3. If the player has registered multiple decks, the deck selected by the player is included in the battle game request information as the deck the player will use for the battle game.

[0124] Game server 3, upon receiving the matchmaking request information, performs the matching process (Step 110). Figure 18 is a flowchart of the matching process (Step 110).

[0125] When the matchmaking unit 72 of the game server 3 receives a match request information (Step 600), it retrieves the cumulative number of matches played for the player ID included in the match request information from the player management DB 10 (Step 601).

[0126] The matching unit 72 determines whether the cumulative number of matches played by a player ID is less than or equal to a predetermined number n (Step 602). If the cumulative number of matches played is less than or equal to the predetermined number n, it obtains the registered deck level of the player ID from the player deck management DB 12 (Step 603). The matching unit 72 selects an operator deck that is equal to or equal to the registered deck level of the player ID (Step 604). Using the database in Figure 8 as an example, the cumulative number of matches played by player ID "1001" is 5. If the predetermined number n is 10, then the cumulative number of matches played by player ID "1001" is less than or equal to the predetermined number n. The registered deck level of the player ID is "8". Therefore, the matching unit 72 selects an operator deck that is equal to or equal to the registered deck level of the player ID "8". For example, it selects an operator deck for player name "xyz (warrior)" with deck level "5".

[0127] On the other hand, the matching unit 72 determines whether the cumulative number of matches played by a player ID is less than or equal to a predetermined number n (Step 602). If the cumulative number of matches played exceeds the predetermined number n, it randomly selects a registered deck from another player from the player deck management DB 12 (Step 606). Using the database in Figure 8 as an example, the cumulative number of matches played by player ID "1002" is 35. If the predetermined number n is 10, then the cumulative number of matches played by player ID "1002" exceeds the predetermined number n. Therefore, the matching unit 72 randomly selects a registered deck from another player from the player deck management DB 12. For example, it selects the deck of player ID "1003".

[0128] The matching unit 72 sends the match play deck configuration information, including the player ID of the selected deck, the player name (including title), the deck level, and the status information of the characters in the deck, to the terminal 2 (Step 605).

[0129] Terminal 2, having received the battle play deck configuration information, performs the second game execution process (Step 111). Figure 19 is a flowchart of the second game execution process (Step 111).

[0130] The character display control unit 572 receives the battle play deck configuration information (Step 700). The character display control unit 572 obtains the player's play deck configuration information from the player deck DB5 (Step 701). The play deck configuration information includes the player's name (including title), deck level, and status information of the characters in the deck. Then, using the character ID of each character in the deck as a key, the character display control unit 572 reads the second game image for each character in the deck from the character image DB3 and displays the battle screen (Step 702).

[0131] Figure 20 shows an example of a battle screen. The battle screen displays the player names (including titles) of the player and the opposing player, the deck levels of the player and the opposing player, the skill buttons of the player and the opposing player, the characters PAC1-PAC4 in the player's deck, and the characters PBC1-PBC4 in the opposing player's deck. Here, the player name (including title) of the opposing player is the player name and title of the player who registered the deck used by the opposing player.

[0132] In this embodiment of the battle game, characters from the deck-based characters PAC2-PAC4 and PBC2-PBC4 attack the enemy character in order of their speed. Processing the attack of one deck-based character constitutes one attack turn, and the attack turns of all combat-ready deck-based characters constitute one cycle.

[0133] The attack control unit 575 calculates P=XYZ each turn, with X being the number of characters that can attack, Y being the number of characters that have finished attacking, and Z being the number of characters that are unable to fight (Step 703). The number of characters that can attack at the start of one cycle is counted and set as X (Step 704). At the start of one cycle, Y=0 and Z=0 (Step 705). Then, the attack control unit 575 processes the attack turn (Step 706).

[0134] The attack turn processing (Step 706) will be explained using Figures 21, 22, and 23. Figure 21 is a flowchart of the attack turn processing (Step 706) that takes place in the second game execution process (Step 111). Figure 22 shows an example of the battle screen when the character is in the first state, and Figure 23 shows an example of the battle screen when the character has transitioned from the first state to the second state.

[0135] The attack control unit 575 determines that the character with the highest speed value among the characters capable of combat will be the attacking character (Step 800).

[0136] The character state control unit 573 determines whether a skill has been activated (Step 801). If a player has activated a skill, the character state control unit 573 transitions one of the opposing player's characters from the first state to the second state (Step 802). The character state control unit 573 displays the character that has transitioned to the second state in a way that makes it visually identifiable that it is in the second state (Step 803).

[0137] When a character is in its first state, as shown in Figure 22, a "?" indicating an unknown weakness is displayed above each deck-building character PAC2~PAC4 and deck-building character PBC2~PBC4. On the other hand, when a player touches the skill button 101 and activates a skill, as shown in Figure 23, the character state control unit 573 transitions the opposing player's deck-building character PBC3 from the first state to the second state (weakness revealed), and displays the weakness attribute "Water" of deck-building character PBC3 so that it can be identified.

[0138] Next, the opponent character selection unit 574 determines the attack target selection method (Step 805). If there are no characters in the second state among the opposing player's characters, the opponent character selection unit 574 selects the first attack target selection method (Step 806) and randomly selects an attack target character (Step 807).

[0139] Meanwhile, the character selection unit 574 selects a second attack target selection method if there is a character in the second state among the opposing player's characters (Step 809). The character selection unit 574 determines whether there is a character in the second state that should be attacked preferentially (Step 810). If there is a character that should be attacked preferentially, the character selection unit 574 selects that character as the target character (Step 811). If there is no character that should be attacked preferentially, it randomly selects an attack target character (Step 807).

[0140] The attack control unit 575 displays that the attacking character has selected a target character to attack (Step 808). The attack control unit 575 calculates the damage to the target character (Step 812) and displays the damage to the target character (Step 813).

[0141] The attack control unit 575 determines whether the target character is incapacitated after taking damage (Step 814), and if the target character is incapacitated (Step 815), it removes the target character from the battle screen (Step 816).

[0142] As explained using Figure 22, if the opposing player's deck characters PBC2~PBC4 are in their first state (weakness unknown), the player's character PAC3 (attacking character) attacks PBC2, which is randomly selected from the opposing player's deck characters PBC2~PBC4. Then, the damage dealt to deck character PBC2, "10," is displayed, and "10" is subtracted from deck character PBC2's HP (hit points), displaying the HP (hit points) after the damage, "5."

[0143] On the other hand, as shown in Figure 23, when a skill is activated and the weakness attribute of deck character PBC3 is revealed to be "Water", the player's deck character PAC3 (attack character) has the attribute "Water", so deck character PAC3 (attack character) will prioritize selecting deck character PBC3 as its target character and attack. As a result, the damage dealt to deck character PBC3 will be 1.5 times, or "15", unlike the first state. Consequently, deck character PBC3's HP (Hit Points) will become "0", deck character PBC3 will disappear from the battle screen, and will be displayed as incapacitated. Thus, the second attack target selection method is an attack method that gives the player an advantage in the battle game.

[0144] The attack control unit 575 increases Y by 1 when the attack turn of one of the deck's characters is completed (Step 707). The attack control unit 575 then checks if there are any incapacitated characters (Step 708), and if there are, it increases Z by 1 (Step 709).

[0145] The attack control unit 575 determines whether both sides have playable characters in their decks (Step 710). If both sides have playable characters in their decks, the attack control unit 575 determines if P=0. If P=0, it returns to Step 703 and resets the cycle. If P=0, it returns to Step 706 and performs the attack turn processing (Step 706).

[0146] Meanwhile, if neither side has any playable characters in their deck, i.e., if a winner and loser have been determined, the attack control unit 575 calculates the battle results, including the status information of the players' deck characters (Step 712), and displays the battle results (Step 713). Figure 24 is an example of the second game results screen. The attack control unit 575 then sends the second game results information to the game server 3 (Step 714). The second game results information includes the player's player ID, the outcome of the second game, and the status information of the players' deck characters.

[0147] Upon receiving the results of the second game, the game server 3 performs a player information update process (Step 112). The player information management unit 70 of the game server 3 updates the status information (ability values ​​(speed, attack power, defense power, hit points, level, etc.)) of the player's owned character DB 14 corresponding to the received player ID, based on the status information of the characters in the deck. The evaluation information update unit 73 increases (+1) the number of wins in the player's player management DB 10 based on the outcome of the second game and updates it. The evaluation information update unit 73 also updates the title in the player management DB 10 to a title corresponding to the updated number of wins. This concludes the explanation of the operation of this embodiment.

[0148] In this embodiment, in the matchmaking for a competitive game, players are matched with opponents based on the number of matches the player has played. Specifically, in this embodiment, if the cumulative number of matches a player has played is less than or equal to a predetermined number, the player is matched with a first-type non-player character, and if the cumulative number of matches a player has played exceeds the predetermined number, the player is matched with a second-type non-player character randomly selected. The first-type non-player character is a non-player character that uses a deck provided by the game operator, and the second-type non-player character is a non-player character that uses a deck registered by another player.

[0149] Therefore, if a player's cumulative number of matches played is below a predetermined number, the player will be matched with a non-player character using a deck with a lower deck level than the player's own deck. This increases the probability of victory for beginner players with few cumulative matches played and prevents them from losing interest in the game. Furthermore, players who have exceeded a predetermined number of cumulative matches will be matched with a second type of non-player character using various decks registered by real players, allowing for a variety of matches.

[0150] Furthermore, in competitive games, by using a second type of non-player character that utilizes various decks registered by real players, it becomes possible to run non-real-time competitive games that do not require the control of other players who registered their decks.

[0151] Furthermore, in this embodiment, the method of selecting an attack target in a competitive game varies depending on the state of the opponent's character. By using this configuration, it is possible to select an attack method that will give the player an advantage in the competitive game depending on the character's state, and it is possible to prevent mistakes in selecting an attack target due to the player's lack of understanding of the game. In addition, it is possible to give the player the enjoyment of transitioning the character's state and activating skills that will give them an advantage in the game. As a result, players will not lose interest in the game, allowing us to provide games that are more engaging for users.

[0152] <Example 1 of the Concept> In the embodiment described above, when matching a player with a first type of non-player character, multiple first type of non-player characters may be presented to the player.

[0153] For example, if there are multiple game administrator decks at or below the player's deck level, the matchmaking unit 72 of the game server 3 sends information on the configurations of these multiple opposing player decks to terminal 2. The second game execution control unit 57 of terminal 2 presents multiple first-type non-player characters to terminal 2, allowing the player to select one. The second game execution control unit 57 then executes the second game between the player and the first-type non-player character selected by the player.

[0154] Figure 25 shows an example of a player selection screen. The player selection screen in Figure 25 presents two Type 1 non-player characters with different deck levels. A player can select the Type 1 non-player character they wish to play against and then proceed to play against that character.

[0155] <Modified example 2 of this embodiment> In the embodiment described above, the system is configured to increase the win count (+1) only for the player who wins the second game. However, if a Type 2 non-player character using a deck registered by another player wins a match, the win count of the other player who registered the deck used by the Type 2 non-player character may also be increased (+1).

[0156] In this case, if the outcome of the second game is a victory for a non-player character of type 2, the evaluation information update unit 73 of the game server 3 increases the number of wins in the player management DB 10 of other players who registered the deck used by the non-player character of type 2 by +1. The evaluation information update unit 73 updates the title in the player management DB 10 to a title corresponding to the updated number of wins.

[0157] By configuring the game in this way, players can increase their win count and earn titles (evaluation information) corresponding to their win count without actually playing a second game. This encourages players to play the first and second games to raise the levels of the characters in their registered decks, thus providing a more engaging game experience for users.

[0158] <Modification 3 of this embodiment> In the embodiment described above, the attacking characters were determined in order of the speed values ​​of the player's and the opposing player's combat-ready characters, with the highest speed being used first. However, the attack turn may be configured to alternate between the player's turn and the opposing player's turn. For example, the attack turn processing may be performed only for the player's characters, and then only for the opposing player's characters, so that the attack turn alternates between the player's turn and the opposing player's turn.

[0159] <Modification 4 of this embodiment> In the embodiment described above, the player's deck level and the opponent's deck level are displayed on the battle screen. However, the deck level corresponds to each player's level. Therefore, instead of displaying the player's deck level and the opponent's deck level, the player's player level and the opponent's player level may be used.

[0160] Some or all of the above embodiments may also be described as follows, but are not limited to the following.

[0161] [Note 1] It is a program that manages competitive games, Computers, A deck management system for managing the decks that players use in competitive games. In a competitive game using the aforementioned deck, a matching means for matching the aforementioned player with opposing players according to the number of matches the aforementioned player has played, A program that makes it function as such.

[0162] [Note 2] The matching means is If the number of matches played by the aforementioned player is less than or equal to a predetermined number, the aforementioned player is matched with a first-type opponent player. If the number of matches played by the aforementioned player exceeds the predetermined number, the player is matched with a second type of opponent. The program described in Appendix 1.

[0163] [Note 3] The aforementioned first type of player is a non-player character, and uses a deck set by the game operator. The second type of player mentioned above is a non-player character, and uses a deck registered by another player other than the aforementioned player. The program described in Appendix 2.

[0164] [Note 4] The matching means matches the player with the first type of opponent so that the number of wins the player has achieved exceeds the number of losses, until the number of matches the player has achieved the predetermined number. The program described in Appendix 2 or Appendix 3.

[0165] [Note 5] The matching means randomly selects a deck to be used by the second type of player from the decks registered by the other players. The program described in any of the appendices 2 through 4.

[0166] [Note 6] The strength of the first type of player or the second type of player depends on the strength of the deck used by the first type of player or the second type of player. The program described in any of the appendices 2 through 5.

[0167] [Note 7] The deck used by the aforementioned first type of player is a deck of lower strength than the deck used by the player being matched. The program described in Appendix 6.

[0168] [Note 8] The strength of the aforementioned deck depends on the level of the characters that make up the deck. The program described in Appendix 6 or Appendix 7.

[0169] [Note 9] The matching means is The player is presented with multiple decks that can be used by the aforementioned first type of player, Matching a first-type opponent player using the deck selected by the aforementioned player with the aforementioned player, The program described in any of the appendices 2 through 8.

[0170] [Note 10] When the matching means matches the player with the second type of opposing player, it does not notify the other player who registered the deck used by the second type of opposing player that the match has been made. The program described in any of the appendices 2 through 9.

[0171] [Note 11] When the matching means matches the player with the second type of opposing player, it displays the name of the other player who registered the deck used by the second type of opposing player as the name of the second type of opposing player. The program described in any of the appendices 2 through 10.

[0172] [Note 12] The number of matches played is the cumulative number of times the player has played the match game. The program described in any of the appendices 1 through 11.

[0173] [Note 13] The aforementioned computer, A win counting means for counting the number of wins in the aforementioned player's competitive games, Evaluation information setting means for setting evaluation information for the player according to the number of wins the player has achieved, To make it function as The program described in any of the appendices 1 through 12.

[0174] [Note 14] The victory count means counts the victory of the other player who registered the deck used by the second type of player when that player wins. The program described in any of the appendices 1 through 13.

[0175] [Note 15] A program that runs a competitive game, Computers, A deck registration method for registering decks composed of multiple characters that players use in competitive games. The means for requesting the aforementioned competitive game, A competitive game execution means that executes a competitive game between the aforementioned player and a competitive player matched in response to a request for the competitive game. To make it function as, The matched opponents are those whose number of matches have been played by the aforementioned player. program.

[0176] [Note 16] The aforementioned competitive game execution means is If the number of matches played by the aforementioned player is less than or equal to a predetermined number, the match game is executed between the aforementioned player and a first-type match player who has been matched in response to the request for the match game. If the number of matches played by the aforementioned player exceeds the predetermined number, a match game is played between the aforementioned player and a second type of matched player who has responded to the request for the match game. The program described in Appendix 15.

[0177] [Note 17] The aforementioned first type of player is a non-player character, and uses a predetermined deck. The second type of player mentioned above is a non-player character, and uses a deck registered by another player other than the aforementioned player. The program described in Appendix 16.

[0178] [Note 18] The strength of the first type of player or the second type of player depends on the strength of the deck used by the first type of player or the second type of player. The program described in Appendix 17.

[0179] [Note 19] The predetermined deck used by the first type of player is a deck of lower strength than the deck used by the player being matched. The program described in Appendix 18.

[0180] [Note 20] The strength of the aforementioned deck depends on the level of the characters that make up the deck. The program described in Appendix 18 or Appendix 19.

[0181] [Note 21] When the aforementioned competitive game execution means matches the aforementioned player with the aforementioned second type of competitive player, it displays the name of the aforementioned other player who registered the deck used by the aforementioned second type of competitive player as the name of the aforementioned second type of competitive player. The program described in any of the appendices 17 to 20.

[0182] [Note 22] The aforementioned battle game execution means presents a plurality of decks that can be used by the first type of battle player, and executes a battle game between the first type of battle player using the deck selected by the player and the other player. The program described in any of the appendices 17 to 21.

[0183] [Note 23] A game management device for managing competitive games, A deck management system for managing the decks that players use in competitive games, In a competitive game using the aforementioned deck, a matching means is provided to match the aforementioned player with opposing players based on the number of matches the aforementioned player has played. A game management device equipped with the following features.

[0184] [Note 24] A game device for running competitive games, A deck registration method for registering decks composed of multiple characters that players use in competitive games, The means for requesting the aforementioned competitive game, A competitive game execution means that executes a competitive game between the aforementioned player and a competitive player matched in response to a request for the competitive game, Equipped with, The matched opponents are those whose number of matches have been played by the aforementioned player. Game device.

[0185] [Note 25] The system comprises a game device on which players execute a competitive game, and a game management device that manages the competitive game, The aforementioned game device, A deck registration means for registering a deck composed of multiple characters that the player will use in a competitive game, The means for requesting the aforementioned competitive game, A competitive game execution means that executes a competitive game between the aforementioned player and a competitive player matched in response to a request for the competitive game, Equipped with, The aforementioned game management device is A deck management means for managing the decks registered by the aforementioned player, In a competitive game using the aforementioned deck, a matching means is provided to match the aforementioned player with opposing players based on the number of matches the aforementioned player has played. Equipped with, Game system.

[0186] Although the present invention has been described above with reference to preferred embodiments, 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. [Explanation of Symbols]

[0187] 1 Game Card 2 terminals 3 Game Servers 11 designs 12. First character image 13. First background image 14. Character Information (First Character) 21 displays 22 Touch control panel 23 speakers 24 cameras 31 Operation Input Section 32 Reading section 33 Display section 34. Sound output section 35 Communications Department 36 Memory section 37 Processing Unit 40 Game Processing Unit 41 Image generation unit 42 Sound generation section 43 Communication Control Unit 50 Game Management Department 51 Operation detection unit 52 Game Card Reading Control Unit 53 Character Recognition Unit 54 Display Control Unit 55 Deck Registration Section 56 First Game Execution Control Unit 57 Second Game Execution Control Unit 60 Storage section 61 Communications Department 62 Processing Unit 70 Player Information Management Department 71 Player Deck Management Department 72 Matching Section 73 Evaluation Information Update Department 571 Competitive Game Requirements Section 572 Character Presentation Control Unit 573 Character Status Display Section 574 Target Character Selection Department 575 Attack Control Unit

Claims

1. Computers, A deck used by a player in a competitive game, which includes both a first-type character and a second-type character, functions as a deck management means for managing such decks. The first type of character is a character that is incapable of directly attacking enemy characters. The second type of character mentioned above is a character capable of directly attacking enemy characters. program.

2. The first type of character is a character that grants an indirect effect to an enemy character that is advantageous to an allied character. The program according to claim 1.

3. The first type of character has a skill that causes the enemy character to transition from a first state to a second state in the aforementioned battle game. The program according to claim 2.

4. The first state is the enemy character's normal state, The second state described above is an abnormal state other than the normal state. The program according to claim 3.

5. When an enemy character transitions to a second state due to a character of the first type, the target selection for attacks by the second type of character will prioritize the enemy character in the second state. The program according to claim 4.

6. The second type of character described above has the role of attacking enemy characters or defending against attacks from enemy characters in the aforementioned battle game. The program according to claim 1 or claim 2.

7. Computers, In a competitive game using the aforementioned deck, if the cumulative number of matches played by the player is less than or equal to a predetermined number, the player is matched with a first-type opponent; and if the cumulative number of matches played by the player exceeds the predetermined number, the player is further matched with a second-type opponent. The program according to claim 6.

8. A deck used by a player in a competitive game, comprising a deck management means for managing a deck containing a first type of character and a second type of character, The first type of character is a character that is incapable of directly attacking enemy characters. The second type of character mentioned above is a character capable of directly attacking enemy characters. Game device.

Images