JP6907369B1 - Information processing programs, information processing systems and information processing methods - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve the interest of a game. An information processing program has a utility information determination unit that determines utility information indicating the utility acting on a game medium in a predetermined game, a notification unit that notifies the utility information, and any one of a plurality of game media. A selection screen display unit that displays a selection screen that can be selected by the player, a game medium holding unit that holds the game medium selected by the player on the selection screen as the possessed game medium, and at least a possessed game medium associated with the player. The computer functions as a predetermined game execution unit that executes a predetermined game based on the possessed game medium associated with the second player and the utility information. [Selection diagram] FIG. 10

Description

The present invention relates to an information processing program, an information processing system and an information processing method.

Conventionally, as shown in Patent Document 1, for example, a game genre called a so-called simulation game is known. Further, for example, as shown in Non-Patent Document 1, a new game genre called an auto butler is known. In games classified into these game genres, a match is played using the game medium (so-called "frame") possessed by each player.

Japanese Patent No. 6235669

What is the game genre "Auto Butler" that represents 2019? (http://www.e-xtreme.co.jp/topics/4626/)

In the game shown in Patent Document 1 or Non-Patent Document 1 described above, winning or losing is greatly influenced by whether or not a player has many pieces in which advantageous parameters are set. Therefore, there is a problem that the strategic nature of the player has a small influence on the outcome and the interest of the game is impaired.

An object of the present invention is to provide an information processing program, an information processing system, and an information processing method capable of improving the interest of a game.

In order to solve the above problems, the information processing program includes a utility information determination unit that determines utility information indicating the utility acting on the game medium in a predetermined game, a notification unit that notifies the utility information, and a plurality of game media. A selection screen display unit that displays a selection screen on which the player can select any of the above, a game medium holding unit that holds the game medium selected by the player as the possessed game medium on the selection screen, and an in-game owned by the player. A currency management unit that manages currency and consumes in-game currency based on the retention of possessed game media, and at least possessed game media associated with a player, possessed game media associated with a second player, and , A predetermined game execution unit that executes a predetermined game based on the utility information, determination and notification of the utility information, display of a selection screen, holding of a possessed game medium, and a unit game including the predetermined game. The unit game management unit that repeatedly executes until the preset end condition is satisfied, and the computer functions, and the currency management department carries over the in-game currency held at the end of the unit game to the next unit game. game medium holding part, the holding game medium held in the previous unit game, holding carried forward to the next unit game, the unit gaming said next, the game content selected by the player in the selection screen, holding game medium as a possible newly registered, utility information determining unit, from the plurality was utility information, to determine the effect information in the unit running game, notification unit, until the display of at least a selection screen is terminated The utility information can be notified, and the predetermined game execution unit executes the predetermined game based on the utility information determined for the unit game being executed.

Further, the selection screen display unit may be able to display the selection screen at least after the utility information is determined.

Further, any of a plurality of classification information is associated with the game medium, and the utility classification information is defined as the corresponding classification information which is the classification information for exerting the utility, and the predetermined game execution unit is in charge of the predetermined game. In the game medium possessed by the player and the second player, the utility may be applied to the game medium possessing the corresponding classification information defined in the utility information.

Further, Jo Tokoro game executing section in a predetermined game based on the player and the second player in possession game contents, and updates the parameters corresponding to at least one of the player and the second player, the unit game management unit , the parameters are updated at a predetermined game may exit condition is satisfied, terminate the unit game, if the parameters are updated in a predetermined game does not satisfy the termination condition may perform a unit game again.

Further, the possessed game medium may be initialized based on the start of the first unit game or the end of the last unit game.

Further, the game medium holding unit can release the holding of the possessed game medium based on the operation of the player, and the currency management unit may acquire the in- game currency based on the release of the holding of the possessed game medium. ..

Further, the in-game currency may be set to an initial value based on the start of the first unit game or the end of the last unit game.

In order to solve the above problems, the information processing system includes a utility information determination unit that determines utility information indicating the utility acting on the game medium in a predetermined game, a notification unit that notifies the utility information, and a plurality of game media. A selection screen display unit that displays a selection screen on which the player can select any of the above, a game medium holding unit that holds the game medium selected by the player on the selection screen as possessed game medium, and an in-game currency owned by the player. A currency management unit that manages and consumes in-game currency based on the holding of the possessed game medium, and at least the possessed game medium associated with the player, the possessed game medium associated with the second player, and A predetermined game execution unit that executes a predetermined game based on the utility information, determination and notification of the utility information, display of a selection screen, holding of a possessed game medium, and a unit game including the predetermined game are preliminarily set. It is equipped with a unit game management unit that repeatedly executes until the set end condition is satisfied, the currency management unit carries over the in-game currency held at the end of the unit game to the next unit game, and the game medium holding unit , The possessed game medium held in the previous unit game is carried over to the next unit game and held, and in the next unit game , the game medium selected by the player on the selection screen can be newly registered as the possessed game medium. The utility information determination unit determines the utility information in the unit game being executed from the plurality of utility information provided, and the notification unit can notify the utility information at least by the time the display of the selection screen is completed. The predetermined game execution unit executes the predetermined game based on the utility information determined for the unit game being executed.

In order to solve the above problems, the information processing method is an information processing method executed by a computer, and includes a step of determining utility information indicating the utility acting on the game medium in a predetermined game, and a step of notifying the utility information. , A step of displaying a selection screen on which the player can select one of a plurality of game media, a step of holding the game medium selected by the player on the selection screen as a possession game medium, and an in-game possession of the player. The steps to manage the currency and consume the in-game currency based on the retention of the possessed game medium, and at least the possessed game medium associated with the player, the possessed game medium associated with the second player, and the utility. Based on the information, the step of executing the predetermined game, the determination and notification of the utility information, the display of the selection screen, the holding of the possessed game medium, and the preset end of the unit game including the predetermined game. The in-game currency held at the end of the unit game, including the step of repeatedly executing until the conditions are met, is carried over to the next unit game, and in the step of holding the possessed game medium, it is held in the previous unit game. The possessed game medium is carried over to the next unit game and held, and in the next unit game, the game medium selected by the player on the selection screen can be newly registered as the possessed game medium, and the utility information is determined. In the step, the utility information in the unit game being executed is determined from the plurality of utility information provided, and the step of notifying the utility information can be executed at least until the display of the selection screen is completed, and the predetermined game. In the step of executing, a predetermined game is executed based on the utility information determined for the unit game being executed.

According to the present invention, the interest of the game can be improved.

FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system. FIG. 2A is a diagram illustrating a hardware configuration of a player terminal. FIG. 2B is a diagram illustrating a hardware configuration of the server. FIG. 3 is a diagram illustrating a phase of the battle game. FIG. 4A is a diagram illustrating an example of a stage selection screen. FIG. 4B is a diagram illustrating the relationship between the stage and the opponent deck. FIG. 4C is a diagram illustrating an example of the opponent deck table. FIG. 4D is a diagram illustrating another example of the opponent deck table. FIG. 5A is a diagram illustrating an example of a deck organization screen. FIG. 5B is a diagram illustrating an example of basic character information. FIG. 6A is a first diagram illustrating a music lottery screen. FIG. 6B is a second diagram illustrating a music lottery screen. FIG. 6C is a third diagram illustrating a music lottery screen. FIG. 6D is a fourth diagram illustrating a music lottery screen. FIG. 7 is a diagram illustrating an example of a musical composition effect. FIG. 8A is a diagram illustrating a character purchase screen. FIG. 8B is a diagram illustrating a character purchase operation. FIG. 8C is a diagram illustrating evolution. FIG. 8D is a diagram illustrating a release operation. FIG. 9A is a diagram illustrating a participating character selection screen. FIG. 9B is a diagram illustrating a participating character selection operation. FIG. 9C is a first diagram illustrating a frame purchase operation. FIG. 9D is a second diagram illustrating a confirmation operation. FIG. 10A is a diagram showing an example of an appeal image. FIG. 10B is a first diagram showing an example of an appeal value update screen. FIG. 10C is a second diagram showing an example of the appeal value update screen. FIG. 10D is a diagram showing an example of the start screen of the individual battle. FIG. 11A is a first diagram showing an example of the first individual battle. FIG. 11B is a second diagram showing an example of the first individual battle. FIG. 11C is a first diagram showing an example of the second individual battle. FIG. 11D is a second diagram showing an example of the second individual battle. FIG. 12A is a diagram illustrating a case where the number of participating characters is different. FIG. 12B is a diagram illustrating a case where the battle game continues. FIG. 12C is a diagram illustrating an end screen. FIG. 13 is a diagram illustrating a memory configuration and a function as a computer in a player terminal. FIG. 14 is a diagram illustrating a memory configuration and a function as a computer in a server. FIG. 15 is a sequence diagram of a player terminal and a server. FIG. 16 is a first flowchart illustrating an example of server-side game management processing in the server. FIG. 17 is a second flowchart illustrating an example of server-side game management processing in the server. FIG. 18 is a flowchart illustrating an example of terminal-side game management processing in the player terminal. FIG. 19 is a flowchart illustrating an example of music determination phase processing in a player terminal. FIG. 20 is a flowchart illustrating an example of character purchase phase processing in the player terminal. FIG. 21 is a flowchart illustrating an example of character selection phase processing in the player terminal. FIG. 22 is a flowchart illustrating an example of appeal phase processing in the player terminal. FIG. 23 is a flowchart illustrating an example of end phase processing in the player terminal.

One aspect of the embodiment of the present invention will be described in detail below with reference to the accompanying drawings. The dimensions, materials, other specific numerical values, etc. shown in such an embodiment are merely examples for facilitating understanding, and do not limit the present invention unless otherwise specified. In the present specification and drawings, elements having substantially the same function and configuration are designated by the same reference numerals to omit duplicate description, and elements not directly related to the present invention are not shown. do.

(Overall configuration of information processing system S)
FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system S. The information processing system S is a so-called client-server system including a player terminal 1 and a server 100. The player terminal 1 and the server 100 are communicated and connected via a communication network 200 having a communication base station 200a.

The player terminal 1 can establish communication with the server 100 via the communication network 200. The player terminal 1 includes a wide range of electronic devices capable of wirelessly or wired communication connection with the server 100. Examples of the player terminal 1 include smartphones, mobile phones, tablet devices, personal computers, game machines, and the like. In the present embodiment, a case where a smartphone is used as the player terminal 1 will be described.

The server 100 is communicated with a plurality of player terminals 1. The server 100 accumulates various types of information (player information) for each player who plays the game. Further, the server 100 updates the accumulated information based on the operation input from the player terminal 1.

The communication base station 200a is connected to the communication network 200 and wirelessly transmits and receives information to and from the player terminal 1. The communication network 200 is composed of a mobile phone network, an Internet network, a LAN (Local Area Network), a dedicated line, and the like, and realizes a wireless or wired communication connection between the player terminal 1 and the server 100.

In the information processing system S of the present embodiment, the player terminal 1 and the server 100 function as the game device G. The player terminal 1 and the server 100 are assigned roles to control the progress of the game, respectively, and the game can be progressed by the cooperation between the player terminal 1 and the server 100.

(Hardware configuration of player terminal 1 and server 100)
FIG. 2A is a diagram illustrating a hardware configuration of the player terminal 1. Further, FIG. 2B is a diagram illustrating a hardware configuration of the server 100. As shown in FIG. 2A, the player terminal 1 includes a CPU (Central Processing Unit) 10, a memory 12, a bus 14, an input / output interface 16, a storage unit 18, a communication unit 20, an input unit 22, and an output unit 24. Will be done.

Further, as shown in FIG. 2B, the server 100 includes a CPU 110, a memory 112, a bus 114, an input / output interface 116, a storage unit 118, a communication unit 120, an input unit 122, and an output unit 124.

The configurations and functions of the CPU 110, the memory 112, the bus 114, the input / output interface 116, the storage unit 118, the communication unit 120, the input unit 122, and the output unit 124 of the server 100 are the CPU 10 and the memory 12 of the player terminal 1, respectively. It is substantially the same as the bus 14, the input / output interface 16, the storage unit 18, the communication unit 20, the input unit 22, and the output unit 24. Therefore, in the following, the hardware configuration of the player terminal 1 will be described, and the description of the server 100 will be omitted.

The CPU 10 operates a program stored in the memory 12 and controls the progress of the game. The memory 12 is composed of a ROM (Read Only Memory) or a RAM (Random Access Memory), and stores a program and various data required for controlling the progress of the game. The memory 12 is connected to the CPU 10 via the bus 14.

An input / output interface 16 is connected to the bus 14. A storage unit 18, a communication unit 20, an input unit 22, and an output unit 24 are connected to the input / output interface 16.

The storage unit 18 is composed of a semiconductor memory such as a DRAM (Dynamic Random Access Memory), and stores various programs and data. In the player terminal 1, the programs and data stored in the storage unit 18 are loaded into the memory 12 (RAM) by the CPU 10.

The communication unit 20 is wirelessly connected to the communication base station 200a and transmits / receives information such as various data and programs to / from the server 100 via the communication network 200. In the player terminal 1, a program or the like received from the server 100 is stored in the memory 12 or the storage unit 18.

The input unit 22 is composed of, for example, a touch panel, buttons, a keyboard, a mouse, a cross key, an analog controller, and the like on which player operations are input (accepts operations). Further, the input unit 22 may be a dedicated controller provided in the player terminal 1 or connected (externally) to the player terminal 1. Further, the input unit 22 may be composed of an acceleration sensor that detects the inclination or movement of the player terminal 1 or a microphone that detects the voice of the player. That is, the input unit 22 broadly includes a device capable of inputting the player's intention in an identifiable manner.

The output unit 24 includes a display device and a speaker. The output unit 24 may be a device connected (externally) to the player terminal 1. In the present embodiment, the player terminal 1 includes a touch panel 26 that functions as an input unit 22 and an output unit 24.

(Game content)
Next, the content of the game provided by the information processing system S (game device G) of the present embodiment will be described with an example. Before starting the game, the player downloads a dedicated application from the server 100 to the player terminal 1 in advance, and registers the player ID in the server 100. When the application is started, the player terminal 1 receives various information stored in the server 100 and displays the game screen on the touch panel 26.

In this embodiment, a battle game in which a plurality of players play against each other is provided. In the following, among the participants participating in the battle game, the operating subject of the predetermined player terminal 1 is simply referred to as a player, the opponent seen from the player is referred to as an opponent player (second player), and the player and the opponent player are referred to as the opponent player. All participants including are called participating players.

Although the battle game in which two participating players compete against each other will be described here, the number of participating players may be three or more. Further, here, a case where a player plays against a computer one by one in one player terminal 1 will be described. Therefore, the opponent player in the following description is controlled by a computer. However, the battle game according to the embodiment may be executed, for example, by a communication battle using a plurality of player terminals 1. Further, a battle game may be executed by a plurality of players using one player terminal 1. In this case, the player terminal 1 does not have to have a communication function.

FIG. 3 is a diagram illustrating a phase of the battle game. As shown in FIG. 3, the battle game is divided into seven phases: stage selection phase F1, deck formation phase F2, music determination phase F3, character purchase phase F4, character selection phase F5, appeal phase F6, and end phase F7. ing. Of these, a battle game (unit game) is composed of four phases: a music determination phase F3, a character purchase phase F4, a character selection phase F5, and an appeal phase F6.

As will be described in detail later, in the appeal phase F6, individual battles by characters are performed. The individual battle is a central position in the battle game, and in the character purchase phase F4 and the character selection phase F5 described above, the player determines 1 to 5 characters (hereinafter referred to as participating characters) to participate in the individual battle. do. Similarly, the opponent player also determines 1 to 5 participating characters.

In the individual battle, one participating character determined by the player and one participating character determined by the opponent player compete against each other. Therefore, for example, when both the player and the opponent player decide five participating characters, five individual battles are performed in one battle game.

In the individual battle, the appeal value is calculated for each of the participating characters of the player and the participating characters of the opponent player. Then, in the individual battle, the appeal values of the two participating characters in the battle are compared, and the participating character with the larger appeal value wins. When the participating character wins in the individual battle, the calculated appeal value is directly given to the participating players as a score. That is, it can be said that the appeal value calculated in the individual battle is the score given when the participating character wins. The victory or defeat of the battle game is determined by the total score, which is the cumulative total of the points given.

Here, the end condition is set in advance in the battle game (battle game), and when the end condition is satisfied, the process shifts to the end phase F7 and the battle game ends. The end conditions are roughly classified into three conditions: a victory condition for the player to win, a defeat condition for the player to lose, and a draw condition. In the embodiment, it is set as a victory condition that the total score of the players becomes a predetermined value (here, 100 points) or more before the opponent player. Further, it is set as a defeat condition that the total score of the opponent players becomes a predetermined value or more before the player.

In the battle game, if the above victory conditions and defeat conditions are not satisfied, that is, if the total score of both the player and the battle player is less than 100 points at the end of the battle game, the battle game is repeatedly executed. NS. However, the maximum number of times the battle game is executed is set to 20, and if the total score of both the player and the battle player is less than 100 points at the end of the 20th battle game, it will be a draw. The battle game ends. As described above, in the embodiment, it is set as a draw condition that the total score of all the participating players is less than 100 points and the 20 battle games are completed. Hereinafter, the battle game of this embodiment will be described for each phase.

FIG. 4A is a diagram illustrating an example of the stage selection screen 26A. FIG. 4B is a diagram illustrating the relationship between the stage and the opponent deck. FIG. 4C is a diagram illustrating an example of the opponent deck table. FIG. 4D is a diagram illustrating another example of the opponent deck table. The battle game has four stages from the first stage to the fourth stage. Each stage has a different difficulty level, but the basic game rules such as the above end conditions are the same.

As shown in FIG. 4A, the stage selection screen 26A is displayed at the start of the battle game. On the stage selection screen 26A, the first stage selection tab 30a, the second stage selection tab 30b, the third stage selection tab 30c, and the fourth stage selection tab 30d are displayed. The player can select the stage of the battle game to be played by tapping any of the four tabs and inputting the stage selection operation.

Here, in the battle game, the player and the battle player use their respective decks. The deck defines a character that can be a participating character in an individual battle (hereinafter referred to as a deck formation character) and various parameters of the deck formation character. The player can configure a deck to be used by himself (hereinafter referred to as his own deck) by selecting a deck formation character in the deck formation phase F2, which will be described in detail later.

On the other hand, the deck of the opponent player (hereinafter referred to as the opponent deck) is preset for each stage. As shown in FIG. 4B, there are four opponent decks, the first deck to the fourth deck, the first deck is used in the first stage, the second deck is used in the second stage, and the third deck is used. The third deck is used on the stage, and the fourth deck is used on the fourth stage.

For example, the first deck is composed of 20 deck-organized characters as shown in FIG. 4C, and the fourth deck is composed of 50 deck-organized characters as shown in FIG. 4D. In addition, here, some deck formation characters are organized in a plurality of different opponent decks. At this time, as shown in FIGS. 4C and 4D, some parameters may differ depending on the opponent deck to be organized, depending on the character. In this way, the difficulty level of each stage is set to be different by making the composition of the deck formation character and the parameters set for each deck formation character different for each opponent deck.

Here, the number of deck-organized characters, the type of deck-organized characters to be organized, and the parameters of deck-organized characters are different for each opponent deck. However, any one or two of the number of deck-organized characters, the type of deck-organized characters to be organized, and the parameters of deck-organized characters may differ for each opponent deck. Further, only one stage may be provided, and further, a common opponent deck may be used in a plurality of stages.

The server 100 has an opponent deck table to which various information referred to in individual battles such as attributes, team attributes, feats, base costs, and base appeal values are associated with each deck formation character (character number and name). It is remembered. The opponent deck table is provided for each stage, and in the battle game, various processes are performed using the opponent deck table corresponding to the stage selected by the player.

Here, the attribute is the classification information of the character, and one of the attributes is always associated with each character. Here, three attributes, a cool attribute, a passion attribute, and a cute attribute, are provided, and each character is classified into one of these three attributes. In the above individual battle, the parameters may change advantageously depending on the attributes of the participating characters.

The team attribute is division information provided separately from the above attribute, and one of the team attributes is always associated with each character. Here, a plurality of types of team attributes are provided, and by selecting a plurality of characters associated with the same team attributes as participating characters, the parameters change advantageously in the above-mentioned individual battle. Here, team attributes are associated with all characters, and some characters are associated with a plurality of team attributes. However, depending on the character, the team attribute may not be associated, or only one team attribute may be associated with the character. When determining a character in each phase such as deck formation, the player considers not only the parameters of the character alone but also the combination of characters that exerts the utility based on the team attributes, which improves the interest.

The feat is to change the parameters advantageously in a battle game including an individual battle. As an example, "support" shown in FIG. 4C is a special skill that increases the appeal value of a participating character that appears next to the participating character by a predetermined value when participating in an individual battle. In addition, "Victory" is a special skill in which, when the participating character wins an individual battle, the appeal value of the participating character is maintained at a predetermined value higher until the end of the battle game. In addition to this, there is also a special skill that changes the cost, which will be described later, instead of the appeal value that affects the outcome in individual battles. In any case, since the player can advance the battle game in an advantageous manner by activating the feat, the feat can be said to be an important factor to be considered when deciding the participating character.

However, activation conditions are set for each feat, and when the activation conditions are satisfied, the feat is activated and the parameters are updated. Therefore, the player needs to determine the participating character in consideration of not only the special skill but also the activation condition.

The base cost is the amount of in-game currency (called coins here) required to purchase each character. The player can purchase a character in the character purchase phase F4, and the basic number of coins required at this time is set for each character as a base cost. The number of coins actually required when purchasing a character may change due to the activation of the above-mentioned feat.

As described above, the base appeal value is a basic parameter for calculating the appeal value in individual battles. In individual battles, the appeal value is calculated based on the base appeal value, taking into consideration the above attributes, activation of special skills, music effects, etc., which will be described later. Can be calculated.

FIG. 5A is a diagram illustrating an example of the deck formation screen 26B. FIG. 5B is a diagram illustrating an example of basic character information. When any of the first stage to the fourth stage is selected in the stage selection phase F1, the deck formation phase F2 is entered. The deck formation phase F2 is a phase in which the player organizes his / her own deck. When the deck formation phase F2 is entered, the deck formation screen 26B shown in FIG. 5A is displayed. On the deck formation screen 26B, the knitable character display unit 32a, the deck formation character display unit 32b, and the formation completion tab 32c are displayed.

The organizeable character display unit 32a displays the organizeable character, which is a character that can be organized in the own deck. For example, 100 organizeable characters are provided, and 100 organizeable characters are displayed on the organizeable character display unit 32a. The organizeable character display unit 32a functions as an operation unit that receives an input operation of the player. For example, when a slide operation in the left-right direction is input, the organizeable character displayed on the organizeable character display unit 32a is switched.

Although detailed description is omitted, the number and types of characters that can be organized may be different or the same for each stage. In addition, the number and types of characters that can be organized may be changed by satisfying predetermined conditions such as the play time and clearing a predetermined stage. Here, for ease of understanding, it is assumed that the characters that can be organized are the same regardless of the stage and play time.

The deck formation character selected by the player is displayed on the deck formation character display unit 32b. Here, regardless of the stage, 20 characters can be organized in their own deck as deck organization characters. However, the number of deck-organized characters that can be organized in your deck may differ from stage to stage. In addition, the number of deck formation characters may be changed when predetermined conditions such as play time and clearing a predetermined stage are satisfied.

The player organizes the selected organizationable character as a deck organization character by sliding it to the deck organization character display unit 32b while pressing and holding the organizationable character displayed on the organizationable character display unit 32a. can do. It should be noted that the same deck formation character cannot be incorporated into the own deck. Therefore, the own deck is composed of 20 different types of deck formation characters.

In addition, as shown in FIG. 5B, character numbers, names, attributes, feats, base costs, and base appeal values are preset for the characters that can be organized in the own deck. For example, by tapping the character displayed on the organizeable character display unit 32a or the deck organization character display unit 32b, the basic character information shown in FIG. 5B can be confirmed. Then, when the formation completion tab 32c is tapped and the deck confirmation operation is input, the deck formation phase F2 shifts to the music determination phase F3, and the battle game is started.

FIG. 6A is a first diagram illustrating the music lottery screen 26C. FIG. 6B is a second diagram illustrating the music lottery screen 26C. FIG. 6C is a third diagram illustrating the music lottery screen 26C. FIG. 6D is a fourth diagram illustrating the music lottery screen 26C. At the start of the battle game, the music to be output in the individual battle is determined. The music lottery screen 26C notifies the player of the determined music.

On the music lottery screen 26C, for example, as shown in FIG. 6A, a plurality of tabs on which music names are written are displayed. After that, as shown in FIG. 6B, each tab is scrolled in the direction indicated by the arrow in the figure. Then, the scroll speed gradually decreases, and as shown in FIG. 6C, the tab corresponding to the determined music is stopped and displayed in the center of the music lottery screen 26C. As a result, on the music lottery screen 26C, the music output in the individual battle is notified to the player. After that, as shown in FIG. 6D, the music effect brought about by the determined music is displayed on the music lottery screen 26C.

FIG. 7 is a diagram illustrating an example of a musical composition effect. The music effect is a utility that acts on the participating characters of both the player and the opponent player, and is information (utility information) that changes the parameters of the participating characters. Although detailed description is omitted, the utility information is managed in association with the battle game ID and the like given for each battle game. The battle game ID is an ID given to each battle game in one battle game, and is information that can identify the number of battle games in the battle game. Therefore, for example, the battle game ID may be information indicating the number of battle games.

Music is an important parameter that influences the outcome of competitive games and individual battles, and the determination of music can be said to be the determination of utility information. Here, 50 kinds of music are provided, but the music effect is defined for all the music. The number of songs and the effect of the songs may be different or common for each stage.

For example, as shown in FIG. 7, when the song with the song number 001 is determined, the appeal value of all the characters participating in the cool attribute who participate in the individual battle is added by "2". Further, for example, when the song with the song number 005 is determined, the feats of all the participating characters having the cute attribute are activated in the individual battle. Therefore, in this case, the feat will not be activated for the participating characters with attributes other than the cute attribute.

In this way, each character is associated with one of a plurality of attributes (classification information), and the music effect (utility information) has a corresponding attribute (correspondence) which is an attribute (classification information) that exerts the utility. Classification information) is defined. Then, in the individual battle, the utility acts on the participating characters of the player and the competing player with the corresponding attribute (correspondence classification information) defined in the music effect (utility information). In addition, in some music effects, all attributes become corresponding attributes, and the feats of all participating characters are activated.

The music lottery screen 26C is reproduced and displayed on the touch panel 26 for a predetermined reproduction time. Then, when the playback time elapses, the music determination phase F3 shifts to the character purchase phase F4.

FIG. 8A is a diagram illustrating the character purchase screen 26D. FIG. 8B is a diagram illustrating a character purchase operation. FIG. 8C is a diagram illustrating evolution. FIG. 8D is a diagram illustrating a release operation. The character purchase phase F4 is a phase in which the player purchases a character from the deck-organized characters and registers (possessed) the purchased character as a possessed character. Also, in the character purchase phase F4, the registration of the possessed character can be canceled. The player can register up to five possessed characters, and can select a participating character to participate in an individual battle from the possessed characters registered in the character purchase phase F4.

When the character purchase phase F4 is entered, the character purchase screen 26D (selection screen) shown in FIG. 8A is displayed on the touch panel 26. The music effect display unit 34a is displayed on the character purchase screen 26D. The music effect display unit 34a notifies the player of the music output in the individual battle and the music effect. Therefore, the player can register the possessed character or cancel the registration of the possessed character in consideration of the music effect.

In addition, the possessable character display unit 34b is displayed on the character purchase screen 26D. The possessable character display unit 34b displays five characters (hereinafter, referred to as possessable characters) that the player can register as possessable characters. At the start of the battle game, five possessable characters are determined by lottery from among the deck-organized characters that make up the own deck organized by the player in the deck-organization phase F2. The possessable character display unit 34b displays five possessable characters determined at the start of the battle game.

In the possessable character display unit 34b, the cost, which is the number of coins required for purchase, is displayed for each possessable character. This cost may be the base cost itself set for each character, or may be changed from the base cost due to a music effect, activation of a special skill, or the like as described above.

In addition, a reload button 34c is displayed on the possessable character display unit 34b. The reload button 34c functions as an operation unit that accepts the reload operation. By tapping the reload button 34c and inputting the reload operation, the player can consume a predetermined number (for example, 1) of coins to redetermine the characters that can be possessed.

The character purchase screen 26D is provided with a coin holding number display unit 34d that displays the player's current holding coin number. A predetermined number (for example, 10) of coins are distributed to the player for each battle game, and the coins held by the player can be carried over to the next battle game. However, the coins are initialized based on the start of the first match game or the end of the last match game. That is, the coins used for purchasing characters, etc. increase or decrease in units of battle games, and are not inherited between battle games. Further, here, it is assumed that the coin is set as an in-game currency dedicated to the battle game, but an in-game currency that can be used other than the battle game may be used.

Further, the possessed character display unit 34e is displayed on the character purchase screen 26D. The currently registered possessed character is displayed on the possessed character display unit 34e. As described above, the player can register 1 to 5 possessed characters. In the example shown in FIG. 8A, three possessed characters are registered.

As described above, the battle game is repeated up to 20 times. The possessed character display unit 34e displays the possessed characters registered in the previous battle game, that is, the possessed characters purchased by the player. However, the possessed character is initialized based on the start of the first battle game or the end of the last battle game. That is, the possessed characters are registered in units of battle games, and are not inherited between battle games. Therefore, at the start of the first battle game in the battle game, no possessed character is displayed on the possessed character display unit 34e of the character purchase screen 26D.

Then, as shown in FIG. 8B, for example, by inputting a character purchase operation that slides to the possessable character display unit 34e while pressing and holding the possessable character displayed on the possessable character display unit 34b, the player Can purchase a character that can be possessed and register it as a character that can be possessed. When the possessable character is purchased, that is, the possessed character is registered in this way, the cost (the number of coins) set for the purchased possessable character is subtracted from the number of possessed coins.

Further, the possessed character display unit 34e is provided with a release button 34f. The player can cancel the registration of the possessed character by inputting the release operation of sliding to the release button 34f while pressing and holding the possessed character displayed on the possessed character display unit 34e. When the registration of the possessed character is canceled, the cost consumed at the time of purchase is added to the number of possessed coins. In other words, by canceling the registration of the possessed character, the paid cost will be refunded. In this way, the possessed character can be registered (held) and deregistered based on the operation of the player, coins (in-game currency) are consumed based on the registration of the possessed character, and the possessed character is deregistered. Coins will be earned based on. The cost refunded by canceling the registration of the possessed character may be different from the paid cost, but it is desirable that it is less than or equal to the paid cost.

Here, in the lottery to determine the five possessable characters, the same possessable characters are not determined. That is, five different possessable characters are always displayed on the possessable character display unit 34b. On the other hand, in the lottery to determine the five possessable characters, the characters registered as possessed characters can also be determined. For example, in the example shown in FIG. 8B, the possessable character displayed second from the right in the possessable character display unit 34b is the same as the possessable character displayed second from the left in the possessable character display unit 34e. be.

However, the same possessable character may be determined in the lottery for determining the possessable character. For example, a total of 40 deck-organized characters, two for each of the 20 types of deck-organized characters, may be set as the lottery target in advance, and may be controlled so as not to be the lottery target based on the registration as possessed characters. Further, for example, a total of 40 characters to be drawn may be shared by all participating players. In this case, based on the fact that the possessable characters of one participating player are determined, the possessable characters are controlled so as not to be subject to the lottery. Further, when the next lottery is performed without the player registering as a possessed character, the remaining possessable characters are controlled to be subject to the lottery again.

The player can purchase the same possessable character as the possessed character. When the same possessable character as the possessed character is purchased, the possessed character evolves as shown in FIG. 8C. In the following, the possessed character after evolution will be referred to as an evolved character. The evolution character changes its appearance from before evolution, and changes so that various parameters become advantageous. Here, for all characters, the appeal value is added by "2" due to evolution. However, the parameters that change with evolution are not limited to the appeal value and can be set as appropriate. In addition, the parameters that change with evolution may differ for each character.

In addition, in the state where the evolved character is not possessed, a lottery is performed to determine 5 possessable characters from the 20 organizeable characters regardless of the number and types of possessed characters registered. On the other hand, for example, in the state where one evolved character is possessed, a lottery to determine five possessable characters from 19 organizeable characters excluding the character that is the source of the evolved character is held. Will be done. Therefore, the player can only evolve the possessed character in one stage. However, the stage of evolution is not limited to one stage, and two or more stages may be possible. In this case, an upper limit is set at the evolution stage, and characters whose evolution stage has reached the upper limit may be excluded from the lottery target.

In addition, the evolved character will be carried over to the next battle game in the same way as the normal possessed character. However, the evolution character can also be unregistered, and in this case, the cost required to purchase the evolved character, that is, the cost required for the second purchase will be refunded. If the registration of the evolved character is canceled, 5 of the 20 organizeable characters will be determined again in the next lottery.

Further, the possessed character display unit 34e is provided with a purchase end button 34g. When the purchase end button 34g is tapped and the purchase end operation is input, the character purchase phase F4 shifts to the character selection phase F5.

FIG. 9A is a diagram illustrating a participating character selection screen 26E. FIG. 9B is a diagram illustrating a participating character selection operation. FIG. 9C is a first diagram illustrating a frame purchase operation. FIG. 9D is a second diagram illustrating a confirmation operation. The character selection phase F5 is a phase in which the characters to participate in the individual battle and the order of participation (hereinafter referred to as the turn) are selected from the possessed characters registered in the character purchase phase F4. Although detailed description is omitted, it is possible to shift to the character purchase phase F4 based on the operation of the player in the character selection phase F5.

As described above, in one battle game, a maximum of five individual battles are executed. In each individual battle, the participating characters of the player and the participating characters of the opponent player compete one by one. At the start of the individual battle, the participating characters and their turns are also determined for the opponent player, but in the character selection phase F5, the characters and the appearance of the opponent player cannot be known.

In the individual battle, the player's participation character and the opponent player's participation character win the victory with the higher appeal value. Therefore, even if the participating characters determined by the player are the same, the result of victory or defeat differs depending on the turn. Therefore, the turn of the participating characters is a major factor that determines the outcome of individual battles.

When the character selection phase F5 is entered, the participating character selection screen 26E shown in FIG. 9A is displayed on the touch panel 26. Similarly to the character purchase screen 26D, the music effect display unit 34a and the number of coins held display unit 34d are also displayed on the participating character selection screen 26E.

In addition, the second possessed character display unit 36a is displayed on the participating character selection screen 26E. The possessed character registered in the character purchase phase F4 is displayed on the second possessed character display unit 36a.

Further, the participating character selection screen 26E is provided with the participating character arrangement area 36b. In the participating character placement area 36b, in order from the right, the first participating character placement area 38a, the second participation character placement area 38b, the third participation character placement area 38c, the fourth participation character placement area 38d, and the fifth participation character placement area 38e is provided.

The player presses and holds the possessed character displayed on the second possessed character display unit 36a, and inputs the participating character selection operation that slides into the participating character arrangement area 36b to select the participating character from the possessed characters. Can be decided. At this time, the turn of the participating characters can be determined depending on which of the first participating character arrangement area 38a to the fifth participation character arrangement area 38e the participation character selection operation is input.

Specifically, the first participating character placement area 38a to the fifth participating character placement area 38e correspond to the 1st to 5th individual battles, respectively. By moving the character from the first participating character arrangement area 38a to the fifth participating character arrangement area 38e and arranging the character, the player can determine the participating character and its turn at the same time.

In the following, the participating characters placed in the first participating character placement area 38a are referred to as the first participating characters, the participating characters placed in the second participating character placement area 38b are referred to as the second participating characters, and the third participating character placement The participating characters placed in the area 38c are called the 3rd participating characters, the participating characters placed in the 4th participating character placement area 38d are called the 4th participating characters, and the participating characters placed in the 5th participating character placement area 38e. Is called the 5th participating character. The 1st to 5th participating characters will participate in the 1st to 5th individual battles, respectively.

For example, as shown in FIG. 9B, after pressing and holding a predetermined possessed character displayed on the second possessed character display unit 36a to start inputting a participating character selection operation, a touch panel is displayed on the first participating character arrangement area 38a. It is assumed that the contact with 26 is released and the input of the participating character selection operation is completed. In this case, the character long-pressed at the time of inputting the participating character selection operation is moved from the second possessed character display unit 36a to the first participating character arrangement area 38a and arranged, and is determined as the first participating character. In this way, on the participation character selection screen 26E, the participation character and the turn can be determined by arranging the possessed characters from the first participation character arrangement area 38a to the fifth participation character arrangement area 38e.

Here, at the start of the battle game, a blackout curtain (indicated by cross-hatching in the figure) is superimposed and displayed on the 4th participating character arrangement area 38d and the 5th participating character arrangement area 38e, and these two areas cannot be selected. It has become. In other words, at the start of the battle game, the 4th participating character placement area 38d and the 5th participating character placement area 38e are not released. As described above, in the initial state of the battle game, the two participation slots are not released, and the player can only participate in three participating characters in the individual battle.

However, the player can release one participation slot by paying a predetermined cost (here, 10 coins). In other words, the player can purchase a quota by paying a predetermined cost. For example, in the state shown in FIG. 9B, it is assumed that the player taps the fourth participating character arrangement area 38d and inputs the frame purchase operation. In this case, if it is not possible to purchase the participation slot, an unillustrated slot purchase impossible screen is displayed to notify that the number of coins held is insufficient. On the other hand, if the participation slot can be purchased, as shown in FIG. 9C, the blackout curtain is hidden and the fourth participation character arrangement area 38d is released. As a result, as shown in FIG. 9D, the participating characters can be arranged in the fourth participating character arrangement area 38d.

Once the 4th participating character placement area 38d and the 5th participating character placement area 38e are released, they remain released until the battle game ends. Therefore, strategicity is required as to when to purchase the quota. Then, when the confirmation tab 36c provided on the participation character selection screen 26E is tapped and the confirmation operation is input, the participation character and the turn are confirmed, and the character selection phase F5 shifts to the appeal phase F6.

FIG. 10A is a diagram showing an example of the appeal image 26F. FIG. 10B is a first diagram showing an example of an appeal value update screen. FIG. 10C is a second diagram showing an example of the appeal value update screen. FIG. 10D is a diagram showing an example of the start screen of the individual battle. When the mode shifts to the appeal phase F6, the appeal image 26F is reproduced and displayed, and the music determined in the music determination phase F3 is reproduced.

In the appeal image 26F, as shown in FIG. 10A, the player total score display unit 40a and the opponent player total score display unit 40b are displayed. The player total score display unit 40a visually displays the player's total score, and the opponent player total score display unit 40b visually displays the opponent player's total score.

In the appeal image 26F, the player total score display unit 40a and the player's participating characters are displayed on the left side of the screen, and the opponent player total score display unit 40b and the opponent player's participating characters are displayed on the screen right side. NS. Immediately after the start of the display of the appeal image 26F, the appeal value update screen is displayed as shown in FIGS. 10B and 10C. On the appeal value update screen, the update value of the appeal value of the participating character is notified.

As described above, the appeal value of the participating character is updated based on various information such as the music effect, the activation of the special skill, the combination of the participating characters, or the attribute. In the appeal image 26F, first, as shown in FIG. 10B, the updated value of the appeal value for the participating character of the player is notified, and then, as shown in FIG. 10C, the updated value of the appeal value for the participating character of the opponent player is notified. Will be done.

If the appeal value of the participating character is not changed, the above appeal value update screen will not be displayed. Then, when the appeal value update screen is displayed, as shown in FIG. 10D, the start screen of the individual battle is displayed, and the individual battle is started.

FIG. 11A is a first diagram showing an example of the first individual battle. FIG. 11B is a second diagram showing an example of the first individual battle. FIG. 11C is a first diagram showing an example of the second individual battle. FIG. 11D is a second diagram showing an example of the second individual battle. FIG. 12A is a diagram illustrating a case where the number of participating characters is different. FIG. 12B is a diagram illustrating a case where the battle game continues. FIG. 12C is a diagram illustrating an end screen.

As shown in FIG. 11A, in the first individual battle, the first participating characters of the player and the opponent player are displayed, and the appeal value of each is displayed. Then, as shown in FIG. 11B, after the victory of the participating character having a high appeal value is notified, the appeal value of the winning participating character is added to the total score.

In the example shown in FIG. 11B, since the participating character of the player has won in the first individual match, the meter showing the total score of the player is increasing in the player total score display unit 40a. When the first individual battle is completed, the second individual battle is subsequently started. As shown in FIG. 11C, in the second individual battle, the second participating characters of the player and the opponent player are displayed, and the appeal value of each is displayed. Then, as shown in FIG. 11D, after the victory of the participating character having a high appeal value is notified, the appeal value of the winning participating character is added to the total score. In the example shown in FIG. 11D, since the opponent player has won, the meter indicating the total score of the opponent player is increasing in the opponent player total score display unit 40b.

Here, as described above, the number of participating characters may differ between the player and the opponent player. If the number of participating characters is different, the individual battle will be executed in the same number as the relatively large number of participating characters. For example, as shown in FIG. 10A, when the player has four participating characters and the opponent player has five participating characters, five individual battles are executed.

At this time, in the first to fourth individual battles, as shown in FIGS. 11A to 11D, the appeal values of the player's participating characters and the opponent player's participating characters are compared, and the appeal values are relatively high. The participating character wins. On the other hand, in the fifth individual battle, as shown in FIG. 12A, only one participating character is displayed, and this one participating character automatically wins. Even in this case, the appeal value of the participating character is given as a score.

As described above, when the total score of both the player and the opponent player is less than 100 points at the end of all the individual battles, the appeal phase F6 shifts to the music determination phase F3. When the music determination phase F3 is entered, as shown in FIG. 12B, the music lottery screen 26C is displayed, and thereafter, the battle game is repeated in the same manner as described above.

On the other hand, if the total score of either the player or the opponent player becomes 100 points or more at the end of any of the individual battles, or if the battle game is executed 20 times, the appeal phase F6 is started. The end phase F7 is entered. When the end phase F7 is entered, as shown in FIG. 12C, the end screen is displayed and the battle game ends. If the player wins the battle game, the score is displayed on the end screen.

As described above, according to the battle game according to the embodiment, the music (utility information) indicating the music effect (utility) acting on the participating characters in the individual battle is determined and notified. Then, the individual battle is executed based on at least the participating characters of the player, the participating characters of the opponent player, and the music effect. In this way, by providing a music effect that acts in common on the participating characters of both the player and the opponent player, the range of strategy when determining the participating characters and possessed characters is expanded, and the interest of the game is improved. do.

In particular, in the embodiment, after the music is determined and notified, it is possible to purchase a possessable character or determine a participating character. As a result, a long-term strategy is required, such as purchasing characters that can be possessed by giving priority to the current battle game, or purchasing characters that can be possessed in anticipation of the next battle game, and the interest of the game. Is improved.

(Control processing in player terminal 1 and server 100)
Next, the control processing in the player terminal 1 and the server 100 for executing the above battle game will be described. FIG. 13 is a diagram illustrating the configuration of the memory 12 and the function as a computer in the player terminal 1.

In the program storage area 12a, the battle game program 50, the stage selection processing program 52, the deck organization processing program 54, the battle game management program 56, the music determination processing program 58, the character purchase processing program 60, the character selection processing program 62, and the appeal processing The program 64 and the termination processing program 66 are stored. Each of the above programs is an example, and a large number of other programs are provided in the program storage area 12a.

The data storage area 12b is provided with an information storage unit 70 that stores various information for a battle game.

The CPU 10 operates each program stored in the program storage area 12a to update the data in each storage unit in the data storage area 12b. Then, the CPU 10 causes the player terminal 1 (computer) to function as the terminal side control unit 1A by operating each program stored in the program storage area 12a. The terminal side control unit 1A includes a battle game execution unit 50a, a stage selection processing unit 52a, a deck organization processing unit 54a, a battle game management unit 56a (unit game management unit), a music determination processing unit 58a, a character purchase processing unit 60a, and a character. The selection processing unit 62a, the appeal processing unit 64a, and the end processing unit 66a are included.

Specifically, the CPU 10 operates the battle game program 50 and causes the computer to function as the battle game execution unit 50a. Similarly, the CPU 10 includes a stage selection processing program 52, a deck organization processing program 54, a battle game management program 56, a music determination processing program 58, a character purchase processing program 60, a character selection processing program 62, an appeal processing program 64, and an end processing program. 66 is operated, and stage selection processing unit 52a, deck organization processing unit 54a, battle game management unit 56a (competition game management unit), music determination processing unit 58a (notification unit), character purchase processing unit 60a (selection screen display unit), respectively. , Game medium holding unit), character selection processing unit 62a, appeal processing unit 64a (predetermined game execution unit), and end processing unit 66a.

FIG. 14 is a diagram illustrating the configuration of the memory 112 and the function as a computer in the server 100. The information management program 150, the battle game management program 152, the music determination program 154, the possessable character determination program 156, and the participation character determination program 158 are stored in the program storage area 112a. Each of the above programs is an example, and a large number of other programs are provided in the program storage area 112a.

The data storage area 112b is provided with an information storage unit 170 that stores various information for a battle game.

The CPU 110 operates each program stored in the program storage area 112a to update the data in each storage unit in the data storage area 112b. Then, the CPU 110 operates each program stored in the program storage area 112a to cause the server 100 (computer) to function as the server-side control unit 100A. The server-side control unit 100A includes an information management unit 150a (currency management unit), a battle game management unit 152a, a music determination unit 154a (utility information determination unit), a possessable character determination unit 156a, and a participation character determination unit 158a.

Specifically, the CPU 110 operates the information management program 150 to make the computer function as the information management unit 150a. Similarly, the CPU 110 operates the battle game management program 152, the music determination program 154, the possessable character determination program 156, and the participation character determination program 158, respectively, and the battle game management unit 152a, the music determination unit 154a, and the possessable character determination unit, respectively. 156a, function as a participating character determination unit 158a. A part of the processing executed by the terminal side control unit 1A and the server side control unit 100A will be described below.

FIG. 15 is a sequence diagram of the player terminal 1 and the server 100. When the application start operation is input to the player terminal 1, the battle game execution unit 50a of the player terminal 1 executes the save information request process (P1). In the storage information request processing, the request information stored in the server 100 and requesting the storage information necessary for executing the battle game is transmitted to the server 100. Upon receiving the request information, the information management unit 150a of the server 100 executes the request information acquisition process (S1). In the request information acquisition process, the stored information stored in the server 100 is read out and set to be receivable by the player terminal 1.

The player terminal 1 collates the received stored information with the information stored in the player terminal 1, and performs a collation process of storing the received stored information in the information storage unit 70 (P2). Then, the stage selection processing unit 52a displays the stage selection screen 26A on the touch panel 26 (P3). When the stage selection operation is input in the player terminal 1, the stage selection processing unit 52a stores the stage information indicating the stage selected by the player in the information storage unit 70 (P4).

Next, the deck knitting processing unit 54a displays the deck knitting screen 26B on the touch panel 26 (P5). Then, when the deck confirmation operation is input, the deck formation processing unit 54a generates own deck information indicating the 20 deck formation characters selected by the player and stores it in the information storage unit 70 (P6). Further, here, the deck knitting processing unit 54a transmits the start information to the server 100. The start information transmitted here includes stage information and own deck information stored in the information storage unit 70.

When the information management unit 150a of the server 100 receives the start information, the information management unit 150a stores the stage information and the own deck information in the information storage unit 170 (S2). Further, here, based on the own deck information, the own deck table to which various parameters are associated with each deck organization character is generated and stored in the information storage unit 170.

Then, in the player terminal 1, the battle game management unit 56a executes the terminal-side game management process (P10), and in the server 100, the battle game management unit 152a executes the server-side game management process (S10). The terminal-side game management process (P10) and the server-side game management process (S10) will be described in detail below. The terminal-side game management process (P10) and the server-side game management process (S10) proceed based on the information transmitted and received between the player terminal 1 and the server 100. In the following, in order to facilitate understanding, the server-side game management process (S10) and the terminal-side game management process (P10) will be described in an appropriate order.

FIG. 16 is a first flowchart illustrating an example of server-side game management processing in the server 100. FIG. 17 is a second flowchart illustrating an example of server-side game management processing in the server 100. The server 100 confirms the reception of information from the player terminal 1, and performs processing based on the received information. At the start of the battle game, start information is transmitted from the player terminal 1 to the server 100. Upon receiving the start information, the server 100 executes the processing required at the start of the battle game.

When the start information is received from the player terminal 1 (YES in S10-1), the music determination unit 154a of the server 100 determines the music to be output during the individual battle by lottery, and performs a music determination process for storing the determined music information. Execute (S10-2).

According to the lottery executed in this music determination process, one music is randomly determined from all 50 music with the same lottery probability. Further, here, one of the songs is determined regardless of the lottery history of the songs in the battle game. Therefore, when the battle game is executed a plurality of times in one battle game, the same song can be determined a plurality of times. However, in the battle game, the lottery may be executed except for the songs already determined during the battle game by referring to the lottery history so that the same song is not determined multiple times.

Next, the information management unit 150a acquires the possessed character information (information indicating the possessed character possessed by the player) stored in the information storage unit 170 (S10-3). Further, the information management unit 150a executes the coin holding update process and updates the holding coin number information indicating the holding coin number of the player (S10-4). Here, with the start of the battle game, the number of coins held by the player is added by "10".

Next, the information management unit 150a updates the information of the opponent player and acquires the updated information (S10-5). Next, the possessable character determination unit 156a executes the possessable character determination process, and determines the possessable characters that the player can purchase and possess in the character purchase phase F4 by lottery (S10-6). Here, based on the possessed character information acquired in S10-3, it is confirmed whether or not the evolved character is possessed, and if the evolved character is not possessed, 5 out of 20 deck-organized characters can be possessed. Is determined with the same lottery probability. On the other hand, if an evolved character is possessed, a lottery table is generated by the deck organization characters excluding the evolved character (strictly speaking, the character that is the source of the evolved character), and 5 bodies are possessed using the generated lottery table. Possible characters are decided. The information (possible character information) related to the five possessable characters determined here is stored in the information storage unit 170.

Next, the information management unit 150a sets the start time determination information (S10-7), and ends the server-side game management process. The start determination information includes the music information determined in S10-2, the possessed character information acquired in S10-3, the number of possessed coins updated in S10-4, and the information related to the opponent player acquired in S10-5. , The possessable character information determined in S10-6 is included. The processing of the player terminal 1 when the start time determination information set in S10-7 is received will be described below.

FIG. 18 is a flowchart illustrating an example of terminal-side game management processing in the player terminal 1. In the player terminal 1, the terminal-side game management process shown in FIG. 18 is repeatedly executed at frame update intervals. For example, the number of frames per second in the player terminal 1 is set to "30". In this case, the terminal-side game management process is executed 30 times per second.

The battle game management unit 56a accesses the server 100, confirms the presence or absence of the received information, and if there is the received information, acquires the received information (P10-1). When the start time determination information set in S10-7 in the server-side game management process is received (YES in P10-2), the battle game management unit 56a stores the start time determination information in the information storage unit 70 (P10). -3). Next, the battle game management unit 56a turns on the music determination phase flag (P10-4).

Here, in the player terminal 1, the phase flag manages the phase of the battle game, that is, the progress stage. Here, as the phase flags, the music determination phase flag indicating the music determination phase F3, the character purchase phase flag indicating the character purchase phase F4, the character selection phase flag indicating the character selection phase F5, the appeal phase flag indicating the appeal phase F6, and the end. An end phase flag indicating phase F7 is provided. When one of the phase flags is switched to the on state, all the other phase flags are turned off. In P10-4, when the music determination phase flag is turned on, the music determination phase is started.

Next, the music determination processing unit 58a executes the music lottery screen display processing, and reproduces the music lottery screen 26C corresponding to the music information stored in P10-3 on the touch panel 26 (P10-5). As a result, the music lottery screen 26C is displayed in the music determination phase F3.

Further, when the start time determination information is not received (NO on P10-2), the battle game management unit 56a confirms the phase flag. At this time, if the music determination phase flag is on (YES on P10-6), the music determination processing unit 58a executes the music determination phase processing (P20), and if the character purchase phase flag is on (P10-7). YES), if the character purchase processing unit 60a executes the character purchase phase processing (P30) and the character selection phase flag is on (YES on P10-8), the character selection processing unit 62a performs the character selection phase processing (P40). ) Is executed, and if the appeal phase flag is on (YES on P10-9), the appeal processing unit 64a executes the appeal phase processing (P50), and if the end phase flag is on (YES on P10-10). ), The end processing unit 66a executes the end phase processing (P60).

FIG. 19 is a flowchart illustrating an example of music determination phase processing in the player terminal 1. The music determination processing unit 58a determines whether it is the playback end timing of the music lottery screen 26C (P20-1). If the playback end timing of the music lottery screen 26C is reached (YES on P20-1), the music determination processing unit 58a turns on the character purchase phase flag (turns off the music determination phase flag) (P20-2). Then, the character purchase processing unit 60a displays the character purchase screen 26D on the touch panel 26 (P20-3). As a result, with the end of playback of the music lottery screen 26C, the music determination phase F3 shifts to the character purchase phase F4.

FIG. 20 is a flowchart illustrating an example of character purchase phase processing in the player terminal 1. The character purchase phase process is executed when the character purchase phase flag is on (YES on P10-7). When the character purchase operation is input (YES on P30-1), the character purchase processing unit 60a determines whether or not the possessable character can be purchased (P30-2). Here, when the number of possessed coins is equal to or greater than the cost set for the possessable character to be purchased, it is determined that the possessable character can be purchased.

When it is impossible to purchase a possessable character (NO on P30-2), the character purchase processing unit 60a displays a non-purchasable screen notifying that the purchase is impossible on the touch panel 26 (P30-3). ). On the other hand, when it is possible to purchase a possessable character (YES on P30-2), the character purchase processing unit 60a updates the possessed character information stored in the information storage unit 70 and also updates the possessed coin number information. (P30-4). Here, the character purchase processing unit 60a registers the possessable character for which the character purchase operation has been performed as the possessed character, and subtracts the cost set for the possessed character from the possessed coins. Then, the character purchase processing unit 60a updates the character purchase screen 26D based on the information updated in P30-4 (P30-5).

Also, when the release operation is input (YES on P30-6), the character purchase processing unit 60a updates the possessed character information and the possessed coin number information (P30-4), and also updates the character purchase screen 26D. (P30-5). When the cancellation operation is input, the character purchase processing unit 60a cancels the registration of the possessed character for which the character purchase operation has been performed (deleted from the information storage unit 70), and transfers the cost required for purchasing the possessed character to the possessed coin. to add.

Further, when the reload operation is input (YES on P30-7), the character purchase processing unit 60a determines whether reloading (redetermination of the possessable character) is possible (P30-8). Here, it is determined that reloading is possible when the number of coins held is equal to or greater than the cost required for reloading.

When reloading is impossible (NO on P30-8), the character purchase processing unit 60a displays a reloadable screen notifying that reloading is impossible on the touch panel 26 (P30-9). On the other hand, when reloading is possible (YES on P30-8), the number of coins held in the information storage unit 70 is updated (P30-10), and the reload request information is transmitted to the server 100 (P30-). 11).

Returning to FIG. 16, when it is determined that the reload request information has been received by the server 100 (YES in S10-8), the possessable character determination unit 156a executes the possessable character redetermination process (S10-9). .. In this possessable character redetermination process, the same lottery as in the possessable character determination process of S10-6 is executed. Then, the information management unit 150a stores the possessable character determined in the possessable character redetermination process in the information storage unit 170, and sets the possessable character redetermination information indicating the stored possessable character (S10-). 10), the server-side game management process is terminated.

Returning to FIG. 20, when it is determined that the possessable character re-determination information has been received by the player terminal 1 (YES on P30-12), the character purchase processing unit 60a has the possessable character display unit 34b on the character purchase screen 26D. Is updated (P30-13).

When the purchase end operation is input (YES on P30-14), the character purchase processing unit 60a sends the purchase information including the possessed character information and the possessed coin number information stored in the information storage unit 70 to the server 100. Transmit (P30-15). Further, the character purchase processing unit 60a turns on the character selection phase flag (turns off the character purchase phase flag) (P30-16). Then, the character selection processing unit 62a displays the participation character selection screen 26E on the touch panel 26 (P30-17). As a result, the character purchase phase F4 shifts to the character selection phase F5.

As shown in FIG. 16, when it is determined that the purchase information has been received by the server 100 (YES in S10-11), the information management unit 150a updates the possessed character information of the information storage unit 170 (YES in S10-11). S10-12), the information on the number of coins held is updated (S10-13).

FIG. 21 is a flowchart illustrating an example of character selection phase processing in the player terminal 1. The character selection phase processing is executed when the character selection phase flag is on (YES on P10-8). When the participation character selection operation is input (YES on P40-1), the character selection processing unit 62a stores the participation character information indicating the participation character in the information storage unit 70 (P40-2), and the participation character selection screen. Update 26E (P40-3).

Further, when the frame purchase operation is input (YES on P40-4), the character selection processing unit 62a determines whether or not the participation frame can be purchased (P40-5). Here, when the number of coins held is equal to or greater than the cost required to purchase the participation slot, it is determined that the participation slot can be purchased.

When the participation frame cannot be purchased (NO on P40-5), the character selection processing unit 62a displays a frame purchase impossible screen notifying that the purchase is impossible on the touch panel 26 (P40-6). ). On the other hand, when it is possible to purchase the participation slot (YES on P40-5), the character selection processing unit 62a stores the participation slot information indicating the number of participation slots and the number of coins held information stored in the information storage unit 70. At the same time as updating (P40-7), the participating character selection screen 26E is updated (P40-8).

When the confirmation operation is input (YES on P40-9), the character selection processing unit 62a inputs the confirmation information including the participation frame information, the participation character information, and the number of coins held information stored in the information storage unit 70. It is transmitted to the server 100 (P40-10), and the appeal phase flag is turned on (the character selection phase flag is turned off) (P40-11).

As shown in FIG. 17, when it is determined that the server 100 has received the confirmed information (YES in S10-14), the information management unit 150a updates various information of the player (S10-15). Here, the participation frame information, the participation character information, and the number of coins held information included in the confirmation information are updated.

Then, the participation character determination unit 158a determines the participation character and the turn of the opponent player based on the opponent deck table (S10-16). In addition, the battle game management unit 152a determines all the information related to the individual battle based on the participating characters, turns, music information, etc. of both the player and the battle player (S10-17). Here, all the information related to the change of the appeal value such as the music effect and the activation of the special skill is decided, and for all the individual battles, the appeal value and the victory or defeat of the participating characters are decided in consideration of the music effect etc. The total score of the player and the opponent player is determined. Further, here, whether or not the above-mentioned end condition is satisfied is determined, and whether or not the battle game (battle game) can be continued, and when the battle game ends, information related to the score is determined. The information management unit 150a sets the result information based on the decision of S10-17 (S10-18).

FIG. 22 is a flowchart illustrating an example of appeal phase processing in the player terminal 1. The appeal phase processing is executed when the appeal phase flag is on (YES on P10-9). When the player terminal 1 receives the result information from the server 100 (YES in P50-1), the appeal processing unit 64a stores the result information in the information storage unit 70 (P50-2), and the appeal image is based on the result information. 26F is generated and reproduced (P50-3).

In this way, in the player terminal 1, the appeal image 26F is reproduced in the appeal phase F6, and the result of the individual battle is notified to the player. However, the results of individual battles and the like are all calculated by the server 100, and the player terminal 1 only performs a process of displaying the calculation results of the server 100.

Further, when the reproduction end timing of the appeal image 26F is reached (YES on P50-4), the appeal processing unit 64a turns on the end phase flag (turns off the appeal phase flag) (P50-5).

FIG. 23 is a flowchart illustrating an example of end phase processing in the player terminal 1. The end phase process is executed when the end phase flag is on (YES on P10-10). The end processing unit 66a determines whether or not the battle game has ended based on the result information stored in the information storage unit 70 (P60-1). If the battle game is over (YES on P60-1), the end processing unit 66a displays the end screen (P60-2), transmits the end information to the server 100 (P60-3), and ends the battle game. The terminal side termination process for causing the game is executed (P60-4). In this terminal-side termination process, information stored in the information storage unit 70, such as information on the number of coins held and information on the characters held, is initialized.

As shown in FIG. 17, when the server 100 receives the termination information (YES in S10-19), the information management unit 150a executes the server-side termination processing (S10-20). Here, the information stored in the information storage unit 170 is initialized, and the information related to the result of the battle game is stored in association with the player ID.

Returning to FIG. 23, if it is not the end of the battle game (NO on P60-1), the end processing unit 66a transmits the start information to the server 100 (P60-5). As a result, as shown in FIG. 16, the server 100 repeatedly executes the processes S10-2 to S10-7 triggered by the reception of the start information, and the next battle game is started.

Although one aspect of the embodiment has been described above with reference to the accompanying drawings, it goes without saying that the present invention is not limited to the above embodiment. It is clear that a person skilled in the art can come up with various modifications or modifications within the scope of the claims, and it is understood that these also naturally belong to the technical scope of the present invention. Will be done.

In the above embodiment, in the battle game (individual battle), the victory or defeat is determined by the magnitude of the appeal value of the character, but the content of the above game is only an example. Further, in the above embodiment, the player possesses the character as the game medium, but the game medium is not limited to this. In any case, a selection screen on which the player can select one of a plurality of game media is displayed, the game medium selected by the player on the selection screen is held as the possessed game medium, and a predetermined game medium using the possessed game medium is used. The game should be run.

Further, in the above embodiment, the utility (utility information) acting on the participating characters in the individual battle is defined for each song, but the song is not essential, and only the utility information may be determined. Then, the predetermined game may be executed at least based on the possessed game medium associated with the player, the possessed game medium associated with the opponent player, and the utility information, and the specific content of the predetermined game or The processing method can be appropriately designed.

Further, in the above embodiment, the character selection screen is displayed after the music (utility information) is notified. That is, the player can purchase the character in consideration of the music (utility information), but for example, the music (utility information) may be notified after the start of the individual battle.

Further, in the above embodiment, the character that is the game medium is associated with the attribute that is the classification information, and the utility information is defined as the corresponding classification information (corresponding attribute) that is the classification information that exerts the utility. In the predetermined game (individual battle), among the game media (characters) possessed by the player and the opponent player, the utility is applied to the game medium possessing the corresponding classification information defined in the utility information. However, the attributes are only an example, and parameters such as levels, feats, and skills set in the game medium may be provided as the classification information.

Further, in the above embodiment, in the predetermined game, the parameters (total score) corresponding to both the player and the opponent player are updated based on the game medium possessed by the player and the opponent player, and the updated parameters in the predetermined game are updated in advance. When the set end condition is satisfied, the battle game is ended, and when the parameter updated in the predetermined game does not satisfy the end condition, the battle game is re-executed. However, the competitive game does not necessarily have to be repeated, and the predetermined game may be executed only once.

Further, in the above embodiment, the parameters (total score) corresponding to both the player and the opponent player are updated, but only the parameters corresponding to either the player or the opponent player may be updated. For example, if the player's participating character wins in an individual battle, the player's parameters increase, and if the player's participating character loses, the player's parameters decrease. Then, when the parameter increases by a predetermined value or more, the player wins, and when the parameter decreases by a predetermined value or more, the player loses. In this way, in the predetermined game, the parameters corresponding to at least one of the player and the opponent player may be updated based on the possessed game medium of the player and the opponent player.

Further, in the above embodiment, the possessed character (possessed game medium) and the coin (in-game currency) possessed by the player are set to initial values based on the end of the last battle game. However, either or both of the possessed characters and coins may be initialized based on the start of the first competitive game. Further, in the embodiment, the in-game currency dedicated to the battle game is used, but the in-game currency shared with other games may be used.

Further, for example, when three or more players participate in a battle game, a battle game may be played by three or more players. Further, from all the players participating in the battle game, a predetermined number of players to be played in individual battles may be determined according to predetermined conditions such as a lottery. For example, when 10 players participate in a battle game, 5 pairs of 2 players who play against each other in an individual battle are determined from the 10 players. In this case, in the battle game, individual battles of five games are performed in parallel. In this way, the two players who compete in the individual battle are determined for each battle game, and the ranking of all the participating players may be determined by the total score of the participating players. At this time, it is desirable that the two players who face each other in the individual battle are determined immediately before the music determination phase F3 or the character purchase phase F4.

Further, in the above embodiment, the battle game in which the participating players compete is described, but the game content is not limited to this. For example, the present invention is also applicable to a game in which a plurality of participating players cooperate to accomplish a mission.

Further, the control process shown in the above embodiment is only an example. In the above embodiment, the control process for executing the game is executed by the player terminal 1 and the server 100. That is, the information processing system S, which is a client-server system including the player terminal 1 and the server 100, functions as the game device G. However, the control process for executing the game may be executed only by the player terminal 1, for example. In this case, only the player terminal 1 functions as the game device G.

The processing of the player terminal 1 and the processing of the server 100 shown in the above embodiment are merely examples. For example, a part or all of the processing in the player terminal 1 described in the above embodiment may be executed in the server 100. , A part or all of the processing in the server 100 may be executed in the player terminal 1. For example, in the above embodiment, the music is determined by the server 100, but the music may be determined by the player terminal 1.

Further, in the above embodiment, the information processing program for realizing the game may be stored in a computer-readable storage medium. Further, the above embodiment may be an information processing method that realizes each function and the steps shown in the flowchart.

The present invention can be used for information processing programs, game devices, and information processing methods.

26D Character purchase screen 56a Competitive game management unit 58a Music determination processing unit 60a Character purchase processing unit 64a Appeal processing unit 150a Information management unit 154a Music determination unit

Claims (9)

A utility information determination unit that determines utility information indicating the utility acting on the game medium in a predetermined game,
A notification unit that notifies the utility information and
A selection screen display unit that displays a selection screen on which the player can select one of the plurality of game media.
On the selection screen, a game medium holding unit that holds the game medium selected by the player as possessed game medium, and a game medium holding unit.
A currency management unit that manages the in-game currency held by the player and consumes the in-game currency based on the holding of the possessed game medium.
At least, a possession game medium associated with the player, a possession game medium associated with the second player, and a predetermined game execution unit that executes the predetermined game based on the utility information.
A unit game in which the unit game including the determination and notification of utility information, the display of the selection screen, the holding of the possessed game medium, and the predetermined game is repeatedly executed until a preset end condition is satisfied. With the management department
To make the computer work,
The currency management department
The in-game currency held at the end of the unit game is carried over to the next unit game,
The game medium holding unit is
The possessed game medium held in the previous unit game is carried over to the next unit game and held, and in the next unit game, the game medium selected by the player on the selection screen is used as the possessed game medium. New registration is possible,
The utility information determination unit
From the plurality of the utility information provided, the utility information in the unit game being executed is determined, and the utility information is determined.
The notification unit
The utility information can be notified at least by the time the display of the selection screen is completed.
The predetermined game execution unit
An information processing program that executes the predetermined game based on the utility information determined for the unit game being executed. The selection screen display unit
The selection screen can be displayed at least after the utility information is determined.
The information processing program according to claim 1. Each of the game media is associated with any of a plurality of classification information.
Corresponding classification information, which is classification information for exerting the utility, is defined in the utility information.
The predetermined game execution unit
In the predetermined game, among the game media possessed by the player and the second player, the utility is caused to act on the game medium possessing the corresponding classification information defined in the utility information.
The information processing program according to claim 1 or 2. The predetermined game execution unit
In the predetermined game, the parameters corresponding to at least one of the player and the second player are updated based on the possessed game medium of the player and the second player.
The unit game management department
When the parameter updated in the predetermined game satisfies the end condition, the unit game is terminated and the unit game is terminated.
If the parameter updated in the predetermined game does not satisfy the end condition, the unit game is executed again.
The information processing program according to any one of claims 1 to 3. The possessed game medium is initialized based on the start of the first unit game or the end of the last unit game.
The information processing program according to claim 4. The game medium holding unit is
It is possible to release the holding of the possessed game medium based on the operation of the player.
The currency management department
The information processing program according to claim 4 or 5, wherein the in-game currency is acquired based on the release of the holding of the possessed game medium. The in-game currency is set to an initial value based on the start of the first unit game or the end of the last unit game.
The information processing program according to any one of claims 1 to 6. A utility information determination unit that determines utility information indicating the utility acting on the game medium in a predetermined game,
A notification unit that notifies the utility information and
A selection screen display unit that displays a selection screen on which the player can select one of the plurality of game media.
A game medium holding unit that holds the game medium selected by the player on the selection screen as a possessed game medium, and a game medium holding unit.
A currency management unit that manages the in-game currency held by the player and consumes the in-game currency based on the holding of the possessed game medium.
At least, a possession game medium associated with the player, a possession game medium associated with the second player, and a predetermined game execution unit that executes the predetermined game based on the utility information.
A unit game in which the unit game including the determination and notification of utility information, the display of the selection screen, the holding of the possessed game medium, and the predetermined game is repeatedly executed until a preset end condition is satisfied. With the management department
With
The currency management department
The in-game currency held at the end of the unit game is carried over to the next unit game,
The game medium holding unit is
The possessed game medium held in the previous unit game is carried over to the next unit game and held, and in the next unit game, the game medium selected by the player on the selection screen is used as the possessed game medium. New registration is possible,
The utility information determination unit
From the plurality of the utility information provided, the utility information in the unit game being executed is determined, and the utility information is determined.
The notification unit
The utility information can be notified at least by the time the display of the selection screen is completed.
The predetermined game execution unit
An information processing system that executes the predetermined game based on the utility information determined for the unit game being executed. It is an information processing method executed by a computer.
A step of determining utility information indicating the utility acting on the game medium in a predetermined game, and
The step of notifying the utility information and
A step of displaying a selection screen in which the player can select one of the plurality of game media, and
A step of holding the game medium selected by the player on the selection screen as a possession game medium, and
A step of managing the in-game currency held by the player and consuming the in-game currency based on the holding of the possessed game medium.
At least, a step of executing the predetermined game based on the possessed game medium associated with the player, the possessed game medium associated with the second player, and the utility information.
A step of repeatedly executing the determination and notification of the utility information, the display of the selection screen, the holding of the possessed game medium, and the unit game including the predetermined game until a preset end condition is satisfied. ,
Including
The in-game currency held at the end of the unit game is carried over to the next unit game.
In the step of holding the possessed game medium, the possessed game medium held in the previous unit game is carried over to the next unit game and held, and in the next unit game, the player selects on the selection screen. The game medium can be newly registered as the possessed game medium, and the game medium can be newly registered.
In the step of determining the utility information, the utility information in the running unit game is determined from the plurality of the utility information provided.
The step of notifying the utility information can be executed at least until the display of the selection screen is completed.
An information processing method for executing the predetermined game based on the utility information determined for the unit game being executed in the step of executing the predetermined game.

Images