Program, game device, and game management device

Abstract

To provide a game with high amusement.MEANS FOR SOLVING THE PROBLEM: A program operates a computer as matching means of matching a player with a first type matching player or a second type matching player. The first type matching player is a non-player character and uses a deck that is set by a game management side. The second type matching player is a non-player character and uses a deck that is registered by another player than the player.SELECTED DRAWING: Figure 5

Description

[Technical field]

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

[0002] There are so-called battle games in which characters operated by multiple users compete against each other. In this battle game, a technique has been proposed for matching specific users by taking into account the status of the target users (for example, Patent Document 1). [Prior art documents] [Patent documents]

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

[0004] Matching in competitive games is an important issue in providing highly entertaining games to players. SUMMARY OF THE PRESENT EMBODIMENTS Accordingly, an object of the present invention is to provide a highly entertaining program, a game device, and a game management device. [Means for solving the problem]

[0005] One aspect of the present invention is a program for managing a competitive game, which causes a computer to function as deck management means for managing the decks used by players in competitive games, and matching means for matching the player with an opposing player in a competitive game using the deck according to the number of matches the player has played.

[0006] One aspect of the present invention is a program for executing a competitive game, which causes a computer to function as deck registration means for registering a deck composed of a plurality of characters that a player will use in a competitive game, competitive game request means for requesting the competitive game, and competitive game execution means for executing a competitive game between the player and a competitive player matched in response to the request for the competitive game, the matched competitive player being a competitive player according to the number of times the player has executed matches.

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

[0008] One aspect of the present invention is a game device that plays a competitive game, the game device comprising: deck registration means for registering a deck composed of a plurality of characters that a player will use in the competitive game; competitive game request means for requesting the competitive game; and competitive game playing means for playing a competitive game between the player and a competitive player matched in response to the request for the competitive game, the competitive player being a competitive player according to the number of times the player has played matches.

[0009] One aspect of the present invention is a game device that includes a player who plays a competitive game, and a game management device that manages the competitive game, the game device including a plurality of characters, deck registration means for registering a deck that the player uses in the competitive game, and The game system comprises a competitive game request means for requesting the competitive game, and a competitive game execution means for executing a competitive game between the player and an opposing player matched in response to the request for the competitive game, wherein the game management device comprises deck management means for managing a deck registered by the player, and matching means for matching the player with an opposing player according to the number of times the player has executed matches in a competitive game using the deck. Effect of the Invention

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

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

[0012] An embodiment of the present invention will be described below. First, in order to facilitate understanding of the embodiment, an outline of the characters appearing in the game, the play medium used in the game, and the game will be described.

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

[0014] In the game of the game application in this embodiment, a plurality of characters appear. Each character is associated with a game medium. The characters are people, virtual creatures, items, etc. The characters have character information. The character information is classified into first character information and second character information depending on whether it is displayed (printed) on the game medium. The first character information of the character in this embodiment is mainly invariant information that does not change according to the progress of the game on the game application, for example, the profile information of the character. The profile information is information such as the character's name, birthplace, attributes, career, and initial ability value. All or a part of the first character information is information that is displayed (printed) on the game medium. The second character information of the character in this embodiment is mainly variable information that changes according to the progress of the game on the game application, for example, the status information of the character. The status information is information that represents the character's abilities (various abilities (speed, attack power, defense power, etc.), hit points, magic points, experience points, level, acquired skills (skills), etc.). The second character information is information that is not displayed (printed) on the game medium.

[0015] In addition, in this embodiment, characters can be divided into a first type and a second type according to the role in the battle game described later. The first type of character is a character that does not directly attack an enemy character in the battle game, but can activate a skill that transitions the enemy character from a first state to a second state in order to develop the battle game advantageously. Here, the first state is the normal state of the character, and the second state is, for example, an abnormal state other than the normal state. For example, the second state may be a state in which the character's weakness is identified, a defenseless state in which the character is asleep, etc. The second type of character is a character that is given the role of attacking the enemy character or the role of defending against attacks from the enemy character.

[0016] Some players do not only aim to play a game of a game application, but also aim to collect game media. In this embodiment, the game media provided to the player is not virtual, but is a tangible object with a substance that the player can actually recognize, and is provided to the player by associating (embodiing) a character with the game media. The game media is, for example, a game card, which is an object (real object) having a physical volume. Note that the game media is not limited to game cards, and may be a shaped object such as a figure having the appearance of a character. In the following description, a case in which the game media is a game card will be described.

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

[0018] A picture 11 is displayed on the front (first side) of the game card 1 (game medium). The picture 11 of the game card 1 includes a first character image 12, which is an image including the head and torso of a character associated with the game card 1, a first background image 13, which is an image of the background of the first character image, and first character information (profile information) 14 of the character. The first character information on the front (first side) of the game card 1 in FIG. 1 includes the name of the character, the attributes of the character, and the hit points of the character. The hit points listed on the game card 1 are initial values, and as will be described later, the hit points of the character will exceed the initial values ​​by using the character in a game. The first character information may also include initial values ​​of the abilities of other characters (various abilities (speed, attack power, defense power, etc.), magic points, experience points, level, acquired skills, etc.).

[0019] On the back side (second side) of the game card 1 (game medium), first character information 14 of a character associated with the game card 1 and a second character image 15 which is an image of the character's head are displayed. The first character information on the back side (second side) of the game card 1 in FIG. 1 describes the character's career, place of birth, etc.

[0020] Incidentally, the first character information 14 displayed on the front or back of the game card 1 does not need to display all of the first character information of the character, and only a portion of the first character information may be displayed.

[0021] Also, as described above, it should be noted that, among the character information, all or part of the first character information (profile information) is displayed on the front or back of the game card 1, but the second character information (status information) is not displayed. This is because the character information that can be displayed on a game medium such as a game card is limited due to design issues and the size of the game medium. On the other hand, when a player obtains the game card 1, he or she will want to know what kind of character the character on the game card 1 is. Therefore, only the first character information that does not change due to games, etc. after obtaining the game card 1 is described.

[0022] Next, the game of this embodiment will be described. The game application of this embodiment is capable of playing a first game and a second game.

[0023] The first game is a game played by a player alone using a character registered in a game application. Here, playing by a player alone does not mean a game in which the player competes against other players. Examples of games played by a player alone include, but are not limited to, maze games and block-breaking games using characters registered in a 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 also affects the second game using that character.

[0024] The second game is a battle game in which a player plays against another player (hereinafter, sometimes referred to as a battle player) using a character registered in the game application.

[0025] Although a single character may be used in a battle game, in this embodiment, a team consisting of multiple characters (hereinafter, sometimes referred to as a deck) is used. A player can select characters (hereinafter, sometimes referred to as deck constituent characters) that will compose a deck from the characters registered in the game application, and can freely organize a deck. The deck used in the battle game of this embodiment is composed of one first type character and three second type characters from the characters owned by the player. The organized deck can be registered in the game application, and can also be registered in the game server that operates the game. At this time, a player can also register multiple decks.

[0026] The opponent in the second game may be not only an actual player, but also a so-called non-player character in which a computer plays the opponent. When the opponent is a non-player character, there are two ways to select the deck that the non-player character uses.

[0027] The first method is for non-player characters to use decks prepared by the game operators. In this case, the game operators can freely set the decks, so there is an advantage in that they can adjust the strength of the non-player characters. For example, if you want to make a non-player character weaker, you can make the deck used by the character consist of characters with low status information, and if you want to make a non-player character stronger, you can make the deck used by the character consist of characters with high status information. In this way, non-player characters that use decks prepared by the game operators are referred to as the first type of non-player characters.

[0028] The second method is to use a deck registered by a real player in reality. As mentioned above, a player can register a deck to be used in the game. Since the status information of each character in this deck differs depending on the player, the overall strength of the deck differs even if the deck is composed of the same characters. Therefore, there are a wide variety of decks, and the strength of the non-player characters who use them also varies widely, which has the advantage of adding variety to the battle game. In this way, non-player characters who use decks registered by real players are referred to as a second type of non-player character.

[0029] Next, the matching between the player and the opponent player will be described. Matching may be performed regardless of the level (strength) of the opponent player. However, a beginner player who has played few matches does not fully understand how to play a match, and often uses a deck that is mainly composed of characters with low status information, so there is a high possibility that he or she will not be able to win a match game. If a beginner player with little experience in match games is matched repeatedly with a high-level player in this way, the beginner player will continue to lose, lose interest in the match game, and eventually lose interest in the game itself.

[0030] Therefore, in this embodiment, a player is matched with a competing player according to the number of matches the player has performed. Here, the number of matches is, for example, the cumulative number of matches performed. When a player has performed a few matches, the player is matched with a competing player with a low competition level, and when the number of matches increases, the player is matched with a random competing player. Here, the competition level can be determined with reference to the competition player's level, but a competing player with a competition level appropriate for the number of matches the player has performed is not necessarily participating in the game at the time of matching, and there is a possibility that appropriate matching cannot be performed.

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

[0032] (1) When the cumulative number of battles performed by a player is equal to or less than a predetermined number, the player is matched with a first type of non-player character. At this time, the deck level of the deck used by the player is referenced, and the first type of non-player character is made to use a deck with a deck level lower than the deck level of the player. Here, the deck level is affected by the level of the deck constituent characters that compose the deck, so in this embodiment, the deck level is the total value of the levels of the deck constituent characters. By performing such matching, when the cumulative number of battles performed by a player is equal to or less than a predetermined number, the player is matched with a non-player character that uses a deck with a deck level lower than the deck level of the deck used by the player, and the winning probability of a beginner player who has a small cumulative number of battles can be increased, and loss of interest in the battle game can be prevented.

[0033] (2) When the player's cumulative battle execution count exceeds a predetermined number, the player is matched with a randomly selected second type of non-player character. A player who has accumulated battle execution counts exceeding the predetermined number will become accustomed to battle games and will want to play battles with a variety of matches. Therefore, a player who has accumulated battle execution counts exceeding the predetermined number is matched with a second type of non-player character using various decks registered by other real players, thereby allowing the player to play a variety of battles.

[0034] The player's cumulative number of battles may be determined by the player's cumulative number of wins. By using the player's number of wins as the cumulative number of battles, the player's skill level in battle games can be accurately determined.

[0035] In addition, other players who have used a deck registered by a non-player character of the second type may be notified that the deck has been used, but notification is generally not required.

[0036] Next, the competitive game (second game) will be described. A battle screen for the matched battle game is displayed on the player's terminal. Fig. 2 shows an example of the battle screen for the battle game.

[0037] The battle screen displays four character images of characters PAC1, PAC2, PAC3, and PAC4 that make up player A's deck, and four character images of characters PBC1, PBC2, PBC3, and PBC4 that make up player B's deck, who is the opponent of player A. Characters PAC1 and PBC1 are a first type of character. Characters PAC2, PAC3, and PAC4 and characters PBC2, PBC3, and PBC4 are a second type of character.

[0038] Character PAC1 and character PBC1, which are first type characters, can activate a skill that transitions an enemy character from a first state to a second state. Here, the first state is the character's normal state, and the second state is, for example, an abnormal state other than the normal state. For example, the second state may be a state in which the character's weakness is identified, a state in which the character is in a sleeping state and cannot be defended, etc. In the following description, the character that activates the skill that transitions an enemy character from the first state to the second state is a first type character, but is not limited to this and may be a second type character.

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

[0040] In the battle game, attack turns are taken in order of speed between the player and the opposing player's second type of battle-capable characters. One turn includes an action order calculation phase, a skill activation phase, and an attack phase.

[0041] The action order calculation phase is a phase for determining the second type of character (sometimes referred to as an attacking character) that will attack among the second type of characters of the player and the opposing player that can fight. For example, if the speed of the character PAC2 of the player A is 50, the speed of the character PAC3 of the player A is 90, and the speed of the character PAC4 of the player A is 40, and the speed of the character PBC2 of the opposing player B is 45, the speed of the character PBC3 of the player B is 82, and the speed of the character PBC4 of the player B is 60, then the character PAC3 of the player A, which has the highest speed, becomes the attacking character.

[0042] The skill activation phase is a phase in which the skills possessed by the first type of character can be activated. In this embodiment, the skill that the first type of character can activate is a weakness detection skill that detects the weak attribute of the opponent's enemy character. The number of times (minimum once) that this weakness detection skill can be activated is determined according to the level of the first type of character. The timing of activation of the weakness detection skill is that the player can activate it in any skill activation phase, and when it is activated, the weak attribute of one enemy character randomly (excluding characters whose attributes have already been determined) among the enemy characters is discovered. At this time, the weak attribute is presented in the vicinity of the character whose weak attribute has been discovered. In other words, it is presented that the character has transitioned from the first state to the second state.

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

[0044] In a normal state (first state) in which the weak points of all enemy characters are not known, an attack target character is randomly selected from the enemy characters. This mode of randomly selecting an attack target character is referred to as a first attack target selection mode. On the other hand, in a skill activation phase, in a state (second state) in which the attributes of enemy characters are known and the weak points of at least one enemy character are known, an attack character whose weak point is known is preferentially selected as an attack character. This mode of preferentially selecting an enemy character in a state (second state) in which a weak point is known as an attack character is referred to as a second attack target selection mode. Note that in the second attack target selection mode, the attribute of the attack character may not be the weak attribute of the enemy character whose weak point is known. In this case, regardless of the attribute of the attack character, an enemy character whose weak point is known may be preferentially selected as an attack character, or an attack target character may be randomly selected from the enemy characters as in the first attack target selection mode. The character selected as the attack target character is displayed in a manner that allows visual distinction from other characters.

[0045] Damage to an enemy character is calculated from the status information of the attacking character (e.g., attack power) and the status information of the attacked character (e.g., defense power). At this time, for example, if the attribute of the attacking character is advantageous to the attribute of the attacked character (if the attacked character is attacked by an attacking character with a weak attribute), the damage inflicted is calculated as 1.5 times the normal damage. As a result, in the case of an attack in the second attack target selection mode, it is possible to inflict large damage on the enemy character and perform an attack that allows the game to be advanced advantageously.

[0046] FIG. 2 is a diagram for explaining an example of a battle screen. In the battle screen of FIG. 2, the state before the activation of the weakness discovery skill is that the weak attribute of all the enemy characters PBC2, PBC3, and PBC4 is unknown. That is, all the characters of the battle players are in the first state. Therefore, the attack target character of the character PAC3, who is an attack character, is selected by the first attack target selection manner, and the character PAC3 attacks the randomly selected enemy character PBC2. On the other hand, in the skill activation phase, when the weakness discovery skill is activated and the weak attribute "water" of the enemy character PBC3 is revealed, at least one enemy character is in the second state. At this time, the attack target character of the attack character PAC3 is selected by the second attack target selection manner. At this time, if the attribute of the character PAC3, who is an attack character, is "water", the enemy character PBC3, whose weak attribute "water" is revealed, is preferentially selected as the attack target character, and the character PAC3 attacks the selected enemy character PBC3. Furthermore, if the attribute of the attacking character PAC3 is not "water," the enemy character PBC3, which has been found to have a weak attribute of "water," may be selected as the character to be attacked, or another enemy character may be selected at random.

[0047] When an attack is made against an enemy character in this way, the damage inflicted on the enemy character is calculated, and the calculated damage is subtracted from the remaining hit points of the enemy character that was the target of the attack. When the remaining hit points of the enemy character reach 0, the enemy character is determined to be unable to fight, and the character image of the enemy character is erased from the battle screen.

[0048] This attack turn is performed on all characters that are able to fight, and this cycle is repeated. When all of the characters of one player become unable to fight, the game ends and the player who lost all of his / her characters loses.

[0049] When the outcome is decided, the status information of the characters that make up each player's deck is increased, and the number of wins of the winning player is increased by 1. At this time, evaluation information (such as a title) may be given to the player according to the number of wins. That's the outline of the second game.

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

[0051] Fig. 3 is a diagram showing an example of the overall configuration of a game system in this embodiment. As shown in Fig. 3, the game system includes a game card 1, a terminal 2 prepared for each player, and a game server 3. The terminal 2 and the game server 3 can be connected to a communication line N and can communicate with each other.

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

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

[0054] FIG. 4 is a diagram showing an example of the device configuration of a smartphone, which is an example of the terminal 2. As shown in FIG. 4, the terminal 2 includes a display 21, a touch operation panel 22 integrally formed with the display 21, a built-in speaker 23, and a camera 24. The terminal 2 also includes a control board, a built-in battery, a power button, a volume control button, and the like, which are not shown. The control board includes various microprocessors such as a CPU, a GPU, and a DSP, various IC memories such as an ASIC, a VRAM, a RAM, and a ROM, and a wireless communication module for wireless communication with a mobile phone base station. The control board also includes a so-called I / F circuit (interface circuit), such as a driver circuit for the touch operation panel 22. Each of these elements mounted on the control board is electrically connected to each other via a bus circuit or the like, and is connected to enable reading and writing of data and transmission and reception of signals.

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

[0056] The operation input unit 31 allows the player to input various operations related to the game, and outputs an operation input signal corresponding to the operation input to the processing unit 37. The function of the operation input unit 31 can be realized by, for example, an element that is directly operated by the player's fingers, such as a touch operation pad, a home button, a button switch, a joystick, or a trackball, as well as an element that detects movement or posture, such as an acceleration sensor, an angular velocity sensor, a tilt sensor, or a geomagnetic sensor. In the example of the smartphone in FIG. 4, the operation input unit 31 corresponds to the touch operation panel 22.

[0057] The reading unit 32 is an imaging device including an image sensor, etc. The reading unit 32 corresponds to the camera 24 in the example of the smartphone in FIG.

[0058] The display unit 33 displays various game screens based on the image signals input from the image generation unit 41. The function of the display unit 33 can be realized by a display device such as a flat panel display such as a liquid crystal display, a cathode ray tube (CRT), a projector, or a head-mounted display. The display unit 33 corresponds to the display 21 in the example of the smartphone in FIG. 4.

[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. The sound output unit 34 corresponds to the speaker 23 in the example of the smartphone in FIG.

[0060] The communication unit 35 realizes communication by connecting to the communication line N. The function 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, and the like.

[0061] The storage unit 36 ​​stores in advance or temporarily stores each time processing is performed a system program for operating the terminal 2 and realizing various functions of the terminal 2, a game program, data used during execution of the program, and the like. The storage unit 36 ​​can be realized by, for example, a RAM, a ROM, a solid state drive using IC memory such as a flash memory, a magnetic disk such as a hard disk, an optical disk such as a CD-ROM or a DVD, and the like. The system program is a program for realizing the basic functions of the terminal 2 as a computer. The game program is a program for causing the processing unit 37 to function as a game calculation unit 40 described later. This game program is distributed from the game server 3 or another application distribution server, etc. The storage unit 36 ​​also stores a database required for executing a game.

[0062] In this embodiment, a player database 1 (DB1), a character information database 2 (DB2), a character image database 3 (DB3), a possessed character database 4 (DB4), and a player deck database 5 (DB5) are stored in the storage unit 36. Fig. 6 is a diagram showing an example of each database of the terminal 2.

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

[0064] The character information DB2 is a database of information related to characters. One record of the character information DB2 includes a card number field, a character ID (identification information) field, a picture characteristic data field, a first character information field, and a second character information field. Each field stores the respective data. The card number is an identification number given to each type of game card 1. The character ID is an identification number given to each character. The picture characteristic data is data on the characteristic amount of the picture 11 displayed (printed) on the surface of the game card 1. The first character information and the second character information are the information described above.

[0065] The character image DB3 is a database related to character images. One record of the character image DB3 includes a character ID field, a character image for list field, a character image for the first game field, and a character image for the second game field. The character image for list field is an image used for organizing a deck, etc. The character image for the first game is an image used in the first game. The character image for the second game is an image used in the second game.

[0066] The owned character DB4 is a database relating to characters owned by a player. One record in the owned character DB4 includes a card number field, a character ID field, an ownership flag field, a status information field, and a level field. As described below, an ownership flag ("1") is set for a character registered in 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 current status information of the character, and is updated as the first and second games are played. The level is the character's level, and is updated as the first and second games are played.

[0067] The player deck DB 5 is a database related to decks organized by players. The player deck DB 5 includes a field for the deck number (name) and a field for the character IDs of the deck constituent characters that make up the deck. These databases can be downloaded by the game server 3 successively when characters used in the game are added or changed.

[0068] The processing unit 37 comprehensively controls the operation of the terminal 2 based on the programs and data stored in the memory unit 36, the operation input unit 31, and various input signals from the reading unit 32. The functions of the processing unit 37 can be realized by electronic components such as a microprocessor such as a CPU or a GPU, an ASIC, and an IC memory. The processing unit 37 includes, as its main functional units, 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 executes various game processes for realizing 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 updates each database and manages and executes the entire game.

[0071] The operation detection unit 51 detects a signal input from the operation input unit 31 and detects an operation by a player. The detected player operations include, for example, tapping (selection), sliding, swiping, pinching, dropping, and the like.

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

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

[0074] The presentation control unit 54 presents on the display unit 33 images necessary for executing the game, a home screen (menu screen), and the like.

[0075] The deck registration unit 55 organizes and registers a deck to be used in the second game from the owned characters. The deck registration unit 55 displays an input field for the name of the deck to be registered and a list of the owned 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 input deck name in the player deck DB 5. In addition, the deck registration unit 55 transmits player deck configuration information including the player's player ID, the deck name of the newly organized deck, and the character IDs of the characters that compose the deck to the game server 3. It is also possible for a player to 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 character selected by the player is the control target. The first game is executed by selecting the menu button on the home screen. By executing the game, the status information of the characters used in the game is increased. The first game execution control unit 56 increases the status information of the characters used in the first game, and updates the status information in the owned character DB4. In addition, the first game execution control unit 56 transmits the updated status information to the game server 3.

[0077] The second game execution control unit 57 executes the second game, which is a battle game using a deck. The second game execution control unit 57 includes a battle 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 competitive game request unit 571 transmits competitive game request information requesting matching of competitive players for a competitive game to the game server 3. The competitive game request information includes the player's player ID and the deck name to be used in the competitive game. If a player has multiple decks registered, the competitive game request unit 571 displays the registered decks on the competition request screen, and includes the deck name of the deck selected by the player as the deck to be used by the player in the competitive game in the competitive 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 player ID of the battle player, the battle player name (including title), and battle player deck configuration character information of the characters that configure the deck used in the battle. The battle player name (including title) is the player name (including title) set by the management side in the case of a first type of non-player character, and is the name (including title) of another player who has registered the deck used by the second type of non-player character. The battle player deck configuration character information includes the character ID of the character that configures the deck used in the battle, and status information of the characters that configure the deck.

[0080] The character presentation control unit 572 reads out the character IDs of the deck constituent characters of the deck used in the battle from the player deck DB5, and reads out the second game images of the character IDs from the character image DB3. The character presentation control unit 572 also reads out the second game images of the character IDs of the deck constituent characters of the battle player from the character image DB3 based on the battle play deck composition information. Then, the character presentation control unit 572 displays the battle screen.

[0081] The character state control unit 573 is a unit that controls the state of the character, and transitions the character from the first state to the second state by activating a skill or the like. The character state control unit 573 also presents whether the current state of the character is the first state or the second state so that the character can be identified. In this embodiment, when the character transitions from the first state to the second state, the character state control unit 573 controls the character to maintain the second state until the end of the fighting game, but is not limited to this. For example, the character may transition from the second state to the first state over time, or the character may transition from the second state to the first state by activating another skill.

[0082] Regarding the relationship between the time of the character's first state and the time of the character's second state, in consideration of the interest of the battle, it is preferable that the time of the character's second state is shorter than the time of the character's first state. In particular, it is preferable that the time of at least one character's second state is shorter than the time of all characters' first states. The character state control unit 573 controls so that the time of at least one character's second state is shorter than the time of all characters' first states. However, this is not limited to this, and it is also possible to control so that the time of the character's second state is longer than the time of the character's first state.

[0083] The attack target character selection unit 574 selects the first attack target selection mode or the second attack target selection mode depending on the state of the character during the attack turn, and selects an attack target character to be an attack target from the characters of the opposing player depending on the selected mode. Specifically, in a normal state (first state) in which the weak points of all enemy characters of the opposing player are not known, the attack target character selection unit 574 randomly selects an attack target character from the enemy characters using the first attack target selection mode. In a state (second state) in which the weak points of at least one enemy character are known, the attack target character selection unit 574 preferentially selects an attack character whose weak point is known as an attack character using the second attack target selection mode. Then, in the second attack target selection mode, if the attribute of the attack character is not the weak attribute of the enemy character whose weak point is known, the enemy character whose weak point is known as an attack character is preferentially selected as an attack character regardless of the attribute of the attack character. The attack target character selection unit 574 may randomly select an attack target character from among enemy characters, similar to the first attack target selection mode. In this embodiment, the attack target character selection unit 574 selects the first attack target selection mode or the second attack target selection mode depending on the state of the character, but the number of times the second attack target selection mode is selected may be limited.

[0084] The attack control unit 575 controls the attack turn, which includes the above-mentioned action order calculation phase, skill activation phase, and attack phase, and controls the battle, such as damage calculation, etc. The attack control unit 575 also presents the character that is the target of the attack in a manner that allows it to be distinguished from other characters.

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

[0086] The storage unit 60 is realized by, for example, a RAM, a ROM, an IC memory such as a flash memory, a magnetic disk such as a hard disk, an optical disk such as a CD-ROM or a DVD, and stores a system program and a function program. The system program is a program for realizing the basic functions of a computer. The function program is a program for causing the processing unit 62 to perform the function of managing a game.

[0087] In this embodiment, 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) of each player are stored in the storage unit 61. Figure 8 is a diagram showing an example of each database of the game server 3.

[0088] The player management DB 10 is a database for managing players. One record of the player management DB 10 includes a field for a player ID, a field for a player name (nickname), a field for the player's cumulative number of matches played in the second game, a field for the player's number of wins in the second game, and a field for the player's title.

[0089] The game operation deck management DB11 is a database that manages game operation decks. One record in the game operation deck management DB11 includes a field for the player name set by the game operator, a field for the deck name, a field for the character IDs of the deck constituent characters that make up the deck, and a field for the deck level. Decks of multiple levels are registered in the game operation deck management DB11 so that they can be adapted to the deck levels of players.

[0090] The player deck management DB 12 is a database for managing the decks of players. Each record in the player deck management DB 12 includes a field for the player ID, a field for the deck name, a field for the character IDs of the deck constituent characters that make up the deck, and a field for the deck level.

[0091] The character information DB13 is a database of information related to characters. One record of the character information DB13 includes a card number field, a character ID (identification information) field, a picture characteristic data field, a first character information field, and a second character information field. Each field stores the respective data. The card number is an identification number given to each type of game card 1. The character ID is an identification number given to each character. The picture characteristic data is data on the characteristic amount of the picture 11 displayed (printed) on the surface of the game card 1. The first character information and the second character information are the information described above.

[0092] The player owned character DB14 of each player (player ID) is a database that manages characters owned by each player. The player owned character DB14 is prepared for each player ID. One record of the player owned character 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 a character registered in the game application from the game card 1. This means that the player owns the character associated with the game card 1. The status information is the current status information of the character, and is updated by the execution of the first game and the second game. The level is the character's level, and is updated by the execution of the first game and the second game.

[0093] The communication unit 61 is a unit for executing communication with the terminal 2. The communication unit 61 realizes communication by connecting to a communication line N. The function of the communication unit 61 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.

[0094] The processing unit 62 performs overall control of the operation of the game server 3 based on the programs and data stored in the storage 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, and an IC memory. The processing unit 62 includes a player information management unit 70, a player deck management unit 71, a matching unit 72, and an evaluation information update unit 73 as main functional units.

[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 of 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 matches the player with a competing player in response to the competitive game request information from the terminal 2. The matching unit 72 refers to the player management DB 10, and if the player's cumulative number of competitive matches is equal to or less than a predetermined number, matches the player with a first type of non-player character. At this time, the matching unit 72 refers to the deck level of the deck used by the player, and selects a deck with a deck level lower than the deck level of the player from the game operation deck management DB 11. If the deck level is lower than the deck level of the player, the deck may be selected randomly from the game operation deck management DB 11. Then, the matching unit 72 transmits competitive play deck configuration information including the player name (including the title), deck level, and status information of the deck configuration characters of the selected deck to the terminal 2.

[0097] Furthermore, the matching unit 72 refers to the player management DB 10, and when the player's cumulative battle execution count exceeds a predetermined count, randomly selects a deck from the player deck management DB 12, and sets the selected deck as the deck used by the second type of non-player character. Then, the matching unit 72 transmits battle play deck configuration information including the player name (including title) of the selected deck, the deck level, and status information of the deck configuration characters to the terminal 2.

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

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

[0100] First, when a game application is started by a player, the game management unit 50 of the terminal 2 performs a player registration request process (Step 100). The game management unit 50 transmits a player registration request including the player's desired player name (nickname) to the game server 3.

[0101] The player information management unit 70 of the game server 3 receives the player registration request and performs a player registration process (Step 101). The player information management unit 70 determines whether the player name (nickname) is the same as a previously registered player name (nickname), and if there is no duplication, assigns a player ID. The player information management unit 70 newly registers the player ID and the player name (nickname) in the player management DB 10. Then, the player information management unit 70 transmits the approval of the player name (nickname) and the assigned player ID to the terminal 2. The game management unit 50 of the terminal 2 registers the received player ID in the player DB1. This allows the player to play the game.

[0102] When the game application is started by the player after the player registration, the presentation control unit 54 of the terminal 2 performs home screen processing (Step 102). The presentation control unit 54 displays a home screen on the display unit 33. The home screen includes menu buttons. FIG. 10 is a diagram showing an example of a home screen. The home screen in FIG. 10 displays character images of characters owned (acquired) by the player, and also displays menu buttons (menu icons) 80 for "Latest news," "Scan game card," "Register deck," "Play first game," "Play second game," and "End game." The player can execute each play by selecting various menu buttons 80.

[0103] When the player selects the "game card scan" button on the above-mentioned home screen, terminal 2 performs a game card scan process (Step 103). Figure 11 is a flowchart of the game card scan process (Step 103).

[0104] When the operation detection unit 51 detects the touch of the "scan game card" button, the game card reading control unit 52 controls the reading unit 32 (camera 24) to be able to capture an image, and displays a guide line for reading the image 11 of the game card 1 on the display unit 33 (Step 200). FIG. 12 is a diagram for explaining the operation of reading the image 11 of the game card 1. In the example of FIG. 12, a guide line 85 having the same shape as the game card 1 and a scan start button 86 for instructing the start of scanning are displayed. The player operates the terminal 2 so that the outer edge of the game card 1 captured by the reading unit 32 and displayed on the display unit 33 is aligned with the guide line 85. When the outer edge of the game card 1 is aligned with the guide line 85, the player touches the scan start button 86.

[0105] When the operation detection unit 51 detects a touch on the scan start button 86, the game card reading control unit 52 starts scanning the game card 1 (Step 201). The scanned image 11 of the 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 design 11 of the scanned game card 1 with each design feature data in the character information DB2, and identifies the character corresponding to the design 11 of the scanned game card 1 (Step 202).

[0107] If the character corresponding to the picture 11 of the scanned game card 1 can be identified (Step 203), the character recognition control unit 53 sets a possession flag (adds "1") in the possession flag field of the possessed character DB4 corresponding to the identified character (Step 204). The character recognition control unit 53 displays on the display unit 33 that a new character has been acquired (Step 205). The character recognition control unit 53 transmits the character ID and player ID of the identified character (for which the possession flag has been set) to the game server 3 (Step 206). Then, the process returns to Step 102 (home screen). Note that if the character is identifiable but already possessed (the possession flag has already been set), a display is displayed indicating that the character is already possessed, and the process similarly returns to Step 102 (home screen). On the other hand, if the character corresponding to the picture 11 of the scanned game card 1 cannot be identified (Step 203), the character recognition control unit 52 displays an error on the display unit 33 (Step 207) and returns to Step 102 (home screen). By performing the above operations, the player can register the character associated with the game card 1 that he or she owns in the game application.

[0108] When the player information management unit 70 of the game server 3 receives the character ID and the player ID from the terminal 2, it performs a player information update process (Step 104). The player information management unit 70 sets a possession flag (adds “1”) in the possession flag field of the character ID in the player possessed character DB 14 corresponding to the received player ID. This allows the player of the player ID to register the acquired character in the game server 3.

[0109] Next, the player can register a deck using the acquired character. The deck registration process (Step 105) in terminal 2 will be described. Fig. 13 is a flowchart of the deck registration process (Step 105).

[0110] When the player selects the "Deck Registration" button on the home screen 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 the character image DB3 (Step 300) and generates a list arrangement image (Step 301). Then, the deck registration unit 55 displays the deck registration screen on the display unit 33 (Step 302).

[0111] FIG. 14 is a diagram for explaining the deck registration screen. The list arrangement image 90 is an image generated by arranging list images of owned characters on a list arrangement map in which the arrangement positions of the characters are predetermined, and arranging non-owned images for characters not owned. Owned characters are characters whose ownership flag is set in the ownership field of the owned character DB4. The deck registration screen includes a list arrangement image presentation area 91 and a deck organization area 92 for organizing a deck. As shown in FIG. 14, in the initial display of this example, the list arrangement image 90 displayed in the list arrangement image presentation area 91 of the deck registration screen is an image corresponding to the range from the top of the list arrangement image 90 to the bottom of the list arrangement image presentation area 91. By flicking or swiping the screen of the list arrangement image presentation area 91, the player can scroll the list arrangement image 90 in the direction of movement of the flick or swipe, and can view the list arrangement image 90 of characters that are not displayed. In addition, the deck organization area 92 displays a deck name input field 93, one first type character frame 94, three second type character frames 95, and a deck confirmation button 96.

[0112] The player inputs a deck name in the deck name input field 93 (Step 303). The player selects one first type character from the list arrangement image 90 displayed in the list arrangement image presentation area 91 (Step 304). The player can select a first type character by dragging an image of the character desired by the player from the list arrangement image 90 to the first type character frame 94. The player selects three second type characters from the list arrangement image 90 displayed in the list arrangement image presentation area 91 (Step 305). The player can select a second type character by dragging an image of the character desired by the player from the list arrangement image 90 to the second type character frame 95.

[0113] When the player presses the deck confirmation button 96 (Step 306), the deck registration unit 55 updates the player deck DB5 from the player deck configuration information including 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 frame 94 and the second type character frame 95 (Step 307). The deck registration unit 55 transmits the player deck configuration information to the game server 3 (Step 308). In this way, the player can register a deck.

[0114] It is also possible to reorganize a deck that has already 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 FIG.

[0115] Next, I'll explain the first game, which affects the level of your deck. When the player selects the "Play First Game" button on the home screen described above, terminal 2 performs a first game execution process (Step 107). Figure 15 is a flowchart showing the first game execution process (Step 107).

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

[0117] FIG. 16 is a diagram for explaining the first game. The first game execution control unit 56 displays a list layout image 90 of the characters possessed on the display unit 33. The player selects a character to execute the first game from the list layout image 90 (Step 401). The first game execution control unit 56 reads out the game image of the selected character from the character image DB3 and executes the first game (Step 402). The example of FIG. 16 shows an example in which the game is executed while operating the game image of the selected character with a finger. This game changes the status information (ability value (speed, attack power, defense power, hit points, level, etc.)) of the character who executed the first game. At this time, the first game execution control unit 56 starts the first game from the initial ability value (for example, initial level) included in the first character information, and controls the ability value to increase so as not to fall below the initial ability value after the game. The first game execution control unit 56 calculates the first game result (Step 403) and displays the first game result (Step 404). Then, the first game execution control unit 56 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 who executed the first game, and the status information of that character (ability values ​​(speed, attack power, defense power, hit points, level, etc.)).

[0118] The game server 3 that has received the first game result information performs a player information update process (Step 108). 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 character DB 14 corresponding to the received player ID.

[0119] Next, a description will be given of the deck management process (Step 106) of the game server 3. Fig. 17 is a flowchart of the deck management process (Step 106).

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

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

[0122] By performing the above operations, a player can register a deck to the game server 3, and furthermore, the level of the registered deck of a player registered to the game server 3 can be updated to the latest level even if the level of the deck constituent characters changes due to the execution of the first game and the second game.

[0123] Next, the execution of the second game (competitive game) will be described. When the player selects the "Play Second Game" button on the home screen described above, the fighting game request unit 571 of terminal 2 performs a second game play request process (Step 109). The fighting game request unit 571 of terminal 2 transmits fighting game request information including the player ID to the game server 3. If the player has multiple decks registered, the deck selected by the player is set as the deck to be used by the player in the fighting game, and the deck name is included in the fighting game request information.

[0124] The game server 3 that has received the competitive game request information performs matching processing (Step 110). Fig. 18 is a flowchart of the matching processing (Step 110).

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

[0126] The matching unit 72 determines whether the cumulative number of battles of the player ID is equal to or less than a predetermined number n (Step 602), and if the cumulative number of battles is equal to or less than the predetermined number n, 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's deck that is equal to or less than the registered deck level of the player ID (Step 604). Taking the database of FIG. 8 as an example, the cumulative number of battles of the player ID "1001" is 5 times. If the predetermined number n is 10 times, the cumulative number of battles of the player ID "1001" is equal to or less than the predetermined number n. And the registered deck level of the player ID is "8". Therefore, the matching unit 72 selects an operator's deck that is equal to or less than the registered deck level "8" of the player ID. For example, the operator's deck of the player name "xyz (fighter)" with a deck level of "5" is selected.

[0127] On the other hand, the matching unit 72 determines whether the cumulative number of battles of the player ID is equal to or less than a predetermined number n (Step 602), and if the cumulative number of battles exceeds the predetermined number n, randomly selects a registered deck of another player from the player deck management DB12 (Step 606). Taking the database of FIG. 8 as an example, the cumulative number of battles of the player ID "1002" is 35. If the predetermined number n is 10, the cumulative number of battles of the player ID "1002" exceeds the predetermined number n. Therefore, the matching unit 72 randomly selects a registered deck of another player from the player deck management DB12. For example, the deck of the player ID "1003" is selected.

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

[0129] The terminal 2 that has received the battle play deck configuration information performs a second game execution process (Step 111). Figure 19 is a flowchart of the second game execution process (Step 111).

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

[0131] 20 is a diagram showing an example of a battle screen. The battle screen displays the player and opponent player's player names (including titles) 100, the player and opponent player's deck levels 101, the player and opponent player's skill buttons 101, the player's deck constituent characters PAC1 to PAC4, and the opponent player's deck constituent characters PBC1 to PBC4. Here, the opponent player's player name (including title) 100 is the player name and title of the player who registered the deck used by the opponent player.

[0132] In the battle game of this embodiment, deck constituent characters PAC2 to PAC4 and deck constituent characters PBC2 to PBC4 attack enemy characters in order of speed. The attack processing of one deck constituent character is one attack turn, and the attack turns of all deck constituent characters that can fight are one cycle.

[0133] The attack control unit 575 calculates P=XYZ for each turn (Step 703), where X is the number of characters that can attack, Y is the number of characters that have already attacked, and Z is the number of characters that cannot fight. 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, Z=0 (Step 705). The attack control unit 575 then performs attack turn processing (Step 706).

[0134] The attack turn process (Step 706) will be described with reference to Figures 21, 22, and 23. Figure 21 is a flowchart of the attack turn process (Step 706) performed in the second game execution process (Step 111). Figure 22 is a diagram showing an example of a battle screen when a character is in a first state, and Figure 23 is a diagram showing an example of a battle screen when a character has transitioned from the first state to the second state.

[0135] The attack control unit 575 determines the character with the highest agility value among the characters capable of fighting as the attacking character (Step 800).

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

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

[0138] Next, the opponent character selection unit 574 determines the attack target selection mode (Step 805). If the opponent player's characters do not include a character in the second state, the opponent character selection unit 574 selects the first attack target selection mode (Step 806) and randomly selects an attack target character (Step 807).

[0139] On the other hand, if the opponent player's characters include a character in the second state, the opponent character selection unit 574 selects the second attack target selection mode (Step 809). The opponent character selection unit 574 determines whether or not there is a character that will be given priority in attack among the characters in the second state (Step 810). If there is a character that will be given priority in attack, the opponent character selection unit 574 selects that character as the target character (Step 811), and if there is no character that will be given priority in attack, the opponent character selection unit 574 randomly selects an attack target character (Step 807).

[0140] The attack control unit 575 displays that the attacking character will attack the selected target character (Step 808). The attack control unit 575 calculates 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 attacked character is unable to fight after the damage (Step 814), and if the attacked character is unable to fight (Step 815), it causes the attacked character to disappear from the battle screen (Step 816).

[0142] To explain using Figure 22, when the opposing player's deck characters PBC2 to PBC4 are in the first state (weakness unknown), the player's character PAC3 (attacking character) attacks the deck character PBC2 randomly selected from the opposing player's deck characters PBC2 to PBC4. Then, the damage inflicted on the deck character PBC2 is displayed as "10", and "10" is subtracted from the HP (hit points) of the deck character PBC2, displaying the HP (hit points) after the damage as "5".

[0143] On the other hand, as shown in FIG. 23, when the skill is activated and the weak attribute "water" of the deck character PBC3 is known, the attribute of the player's deck character PAC3 (attack character) is "water", so the deck character PAC3 (attack character) preferentially selects the deck character PBC3 as the attack target character and attacks it. As a result, the damage given to the deck character PBC3 is 1.5 times the damage given in the first state, which is "15". As a result, since the HP (hit points) of the deck character PBC3 is "15", the HP (hit points) of the deck character PBC3 becomes "0", the deck character PBC3 disappears from the battle screen, and is displayed as being unable to battle. In this way, the second attack target selection mode is an attack mode that advantageously advances the player's battle game.

[0144] When the attack turn of one of the deck constituent characters is completed, the attack control unit 575 increments Y by 1 (Step 707). The attack control unit 575 determines whether there is a character that is unable to fight (Step 708), and if there is a character that is unable to fight, increments Z by 1 (Step 709).

[0145] The attack control unit 575 determines whether or not both sides have deck constituent characters capable of combat (Step 710). If both sides have deck constituent characters capable of combat, the attack control unit 575 determines whether or not P=0, and if P=0, returns to Step 703 and resets one cycle of processing. If P=0 is not true, returns to Step 706 and performs attack turn processing (Step 706).

[0146] On the other hand, if neither player has a deck constituent character capable of fighting, i.e., if the outcome of the match has been decided, the attack control unit 575 calculates the battle result, such as the status information of the player's deck constituent characters (Step 712), and displays the battle result (Step 713). FIG. 24 is an example of a second game result screen. Then, the attack control unit 575 transmits the second game result information to the game server 3 (Step 714). The second game result information includes the player's player ID, the outcome of the second game, and the status information of the player's deck constituent characters.

[0147] The game server 3 that has received the second game result information 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 character DB 14 corresponding to the received player ID from the received status information of the deck constituent characters. The evaluation information update unit 73 updates the number of wins in the player management DB 10 of the player by incrementing (+1) based on the outcome of the second game. 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 matching of a battle game, a player is matched with a battle player according to the number of battles the player has performed. In particular, in this embodiment, when the player's cumulative battle number is equal to or less than a predetermined number, the player is matched with a first type of non-player character, and when the player's cumulative battle number exceeds the predetermined number, the player is matched with a randomly selected second type of non-player character. The first type of non-player character is a non-player character that uses a deck of the operator, and the second type of non-player character is a non-player character that uses a deck registered by another player.

[0149] Therefore, when the cumulative number of battles a player has performed is equal to or less than a predetermined number, the player is matched with a non-player character using a deck with a deck level lower than the deck level of the deck used by the player, and the winning probability of a beginner player who has performed a small number of battles can be increased, and interest in the battle game can be prevented from being lost. Also, a player who has performed a cumulative number of battles exceeds a predetermined number can be matched with a second type of non-player character using various decks registered by real players, thereby enabling a variety of battles to be performed.

[0150] In addition, in a competitive game, by using a second type of non-player character that uses various decks registered by real players, it is possible to play a non-real-time competitive game that does not require the operation of other players who have registered decks.

[0151] In addition, in the present embodiment, when selecting an attack target in a battle game, the method of selecting the attack target is changed depending on the state of the opponent's character. With this configuration, an attack mode that will give an advantage in the battle game can be selected depending on the state of the character, and it is possible to prevent mistakes in selecting an attack target due to a player's lack of understanding of the game. Also, it is possible to give the player the enjoyment of transitioning the state of the character and activating skills that will give an advantage in the game. As a result, the player does not lose interest in the game, making it possible to provide a game that is more entertaining for the user.

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

[0153] For example, if there are multiple game operator decks that are equal to or lower than the player's deck level, the matching unit 72 of the game server 3 transmits the multiple competing player deck configuration information to the terminal 2. The second game execution control unit 57 of the terminal 2 presents multiple first type non-player characters to the terminal 2 so that the player can select one. Then, the second game execution control unit 57 executes the second game between the player and the first type non-player character selected by the player.

[0154] Fig. 25 is an example of a battle player selection screen. Two first type non-player characters with different deck levels are presented on the battle player selection screen in Fig. 25. A player can select a first type non-player character with which to battle, and thereby execute a battle with the first type non-player character.

[0155] <Modification 2 of this embodiment> In the above-described embodiment, the number of wins is increased (+1) only for the player who won the second game. However, when a second type of non-player character using a deck registered by another player wins the battle game, the number of wins of the other player who registered the deck used by the second type of non-player character may be increased (+1).

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

[0157] By configuring the game in this manner, the player can increase the number of wins and obtain a title (evaluation information) according to the number of wins without actually playing the second game. This means that the player will play the first and second games in order to increase the level of the deck constituent characters of the registered deck, thereby providing a game that is more interesting for the user.

[0158] <Modification 3 of this embodiment> In the above-described embodiment, the attacking character is determined in descending order of the speed value of the combat-capable characters of the player and the opposing player. However, the attacking turn of the player and the attacking turn of the opposing player may be configured to alternate. For example, the attacking turn process may be performed only for the player's character, and then the attacking turn process may be performed only for the opposing player's character, so that the attacking turn of the player and the attacking turn of the opposing player may be configured to alternate.

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

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

[0161] [Appendix 1] A program for managing a competitive game, Computer, deck management means for managing decks used by players in a competitive game; a matching means for matching the player with a competing player in accordance with the number of matches the player has played in a competitive game using the deck; A program that functions as a

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

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

[0164] [Appendix 4] the matching means matches the player with a competing player of the first type such that the number of wins of the player exceeds the number of losses of the player until the number of matches played by the player reaches the predetermined number; 2. The program according to claim 1,

[0165] [Appendix 5] The matching means randomly selects a deck to be used by the second type of fighting player from the decks registered by the other players. 5. A program according to any one of claims 2 to 4.

[0166] [Appendix 6] The strength of the first type of opponent player or the second type of opponent player corresponds to the strength of a deck used by the first type of opponent player or the second type of opponent player. 6. A program according to any one of claims 2 to 5.

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

[0168] [Appendix 8] The strength of the deck corresponds to the level of the characters that make up the deck. 10. The program according to claim 6 or 7.

[0169] [Appendix 9] The matching means includes: presenting a plurality of decks that can be used by the first type of opponent player to the player; Matching the player with a first type of competitive player using the deck selected by the player; 9. A program according to any one of appendix 2 to appendix 8.

[0170] [Appendix 10] when the player and the second type of opponent player are matched, the matching means does not notify the other player who has registered the deck used by the second type of opponent player of the match-up; 10. The program according to any one of claims 2 to 9.

[0171] [Appendix 11] when the player and the second type of opponent player are matched, the matching means presents, as a name of the second type of opponent player, a name of the other player who has registered a deck used by the second type of opponent player; 11. The program according to any one of claims 2 to 10.

[0172] [Appendix 12] The number of times of playing a match is a cumulative number of times that the player has played a match game. 12. A program according to any one of claims 1 to 11.

[0173] [Appendix 13] The computer, a win counting means for counting the number of wins in the competitive game by the player; an evaluation information setting means for setting evaluation information for the player according to the number of wins of the player; To function as 13. A program according to any one of claims 1 to 12.

[0174] [Appendix 14] the win number counting means, when the second type of opponent player wins, counts the number of wins of the other player who has registered the deck used by the second type of opponent player; 14. A program according to any one of claims 1 to 13.

[0175] [Appendix 15] A program for executing a competitive game, Computer, A deck registration means for registering a deck, which is composed of a plurality of characters and which is to be used by a player in a battle game; a competitive game request means for requesting the competitive game; a match game execution means for executing a match game between the player and a match player matched in response to the request for the match game; Function as a The matched opponent players are opponent players according to the number of matches played by the player. program.

[0176] [Appendix 16] The competitive game execution means includes: if the number of matches played by the player is equal to or less than a predetermined number, a competitive game is played between the player and a first type of competitive player that has been matched in response to the request for the competitive game; When the number of matches of the player exceeds the predetermined number, a match game is executed between the player and a second type of match player that has been matched in response to the request for the match game. 16. The program according to claim 15.

[0177] [Appendix 17] The first type of opponent player is a non-player character and uses a predetermined deck; The second type of opponent player is a non-player character and uses a deck registered by a player other than the player. 17. The program according to claim 16.

[0178] [Appendix 18] The strength of the first type of opponent player or the second type of opponent player corresponds to the strength of a deck used by the first type of opponent player or the second type of opponent player. 18. The program according to claim 17.

[0179] [Appendix 19] The predetermined deck used by the first type of competitive player is a deck having a lower strength than a deck used by a matched player. 19. The program according to claim 18.

[0180] [Appendix 20] The strength of the deck corresponds to the level of the characters that make up the deck. 19. The program according to claim 18 or 19.

[0181] [Appendix 21] when the player and the second type of opponent player are matched, the competitive game executing means presents, as a name of the second type of opponent player, a name of the other player who has registered a deck used by the second type of opponent player; 21. The program according to any one of claims 17 to 20.

[0182] [Appendix 22] the competitive game execution means presents a plurality of decks that can be used by the first type of competitive player, and executes a competitive game between the player and the first type of competitive player using a deck selected by the player; 22. The program according to any one of claims 17 to 21.

[0183] [Appendix 23] A game management device for managing a competitive game, comprising: A deck management means for managing decks used by players in a competitive game; a matching means for matching the player with a competing player in accordance with the number of matches the player has played in a competitive game using the deck; A game management device comprising:

[0184] [Appendix 24] A game device for executing a competitive game, A deck registration means for registering a deck that is composed of a plurality of characters and that is to be used by a player in a battle game; a competitive game request means for requesting the competitive game; a match game execution means for executing a match game between the player and a match player matched in response to the match game request; Equipped with The matched opponent players are opponent players according to the number of matches played by the player. Gaming device.

[0185] [Appendix 25] The present invention comprises a game device for a player to execute a competitive game, and a game management device for managing the competitive game, The game device comprises: a deck registration means for registering a deck that is composed of a plurality of characters and that is to be used by the player in a battle game; a competitive game request means for requesting the competitive game; a match game execution means for executing a match game between the player and a match player matched in response to the match game request; Equipped with The game management device includes: a deck management means for managing the decks registered by the players; a matching means for matching the player with a competing player in accordance with the number of matches the player has played in a competitive game using the deck; 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-described embodiments, and can be modified and embodied in various ways within the scope of the technical concept thereof. [Explanation of symbols]

[0187] 1 Game Card 2. Terminal 3 Game Server 11 Design 12 First character image 13 First background image 14 First Character Information 21 Display 22 Touch panel 23 Speaker 24 Camera 31 Operation input section 32 Reading unit 33 Display section 34 Sound output section 35 Communications Department 36 Memory section 37 Processing section 40 Game Calculation Unit 41 Image Generation Unit 42 Sound generation section 43 Communication control section 50 Game Management Department 51 Operation detection unit 52 Game card reading control unit 53 Character Recognition Department 54 Presentation 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 section 70 Player Information Management Department 71 Player Deck Management Department 72 Matching Section 73 Evaluation Information Update Division 571 Match Game Request Unit 572 Character presentation control unit 573 Character Status Display 574 Attack Target Character Selection Department 575 Attack Control Unit

Claims

1. Computer, deck management means for managing decks used by players in a competitive game; a matching means for matching the player with a first type of competing player when the number of matches the player has played is equal to or less than a predetermined number in a competing game using the deck, and for matching the player with a second type of competing player when the number of matches the player has played exceeds the predetermined number; Function as a the first type of competitive player is a player who uses a deck of a limited deck level; The second type of competitive player is a player who uses a deck of an unlimited deck level. program.

2. The first type of competitive player is a player using a deck having a deck level lower than the deck level of the deck used by the player, The second type of competing player is a player using a deck including a deck having a deck level higher than the deck level of the deck used by the player. The program according to claim 1.

3. The second type of competitive player is a player selected by lottery. The program according to claim 2.

4. the matching means randomly selects a deck to be used by the second type of fighting player from the decks registered by the other players; The program according to claim 1 or 2.

5. The matching means includes: presenting a plurality of decks usable by the first type of opponent player to the player; Matching the player with a first type of competitive player using the deck selected by the player; The program according to claim 1.

6. A deck management means for managing the decks used by players in a competitive game; a matching means for matching the player with a first type of competing player when the number of matches played by the player in a competing game using the deck is equal to or less than a predetermined number, and for matching the player with a second type of competing player when the number of matches played by the player exceeds the predetermined number; Equipped with the first type of competitive player is a player who uses a deck of a limited deck level; The second type of competitive player is a player who uses a deck of an unlimited deck level. Gaming device.

7. A deck management means for managing decks used by players in a competitive game; a matching means for matching the player with a first type of competing player when the number of matches played by the player in a competing game using the deck is equal to or less than a predetermined number, and for matching the player with a second type of competing player when the number of matches played by the player exceeds the predetermined number; Equipped with the first type of competitive player is a player who uses a deck of a limited deck level; The second type of competitive player is a player who uses a deck of an unlimited deck level. Game management device.

Images