JP6775657B1 - Information processing system, information processing method and information processing program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve the real pleasure of a game. SOLUTION: Based on a lottery request operation input by a player, a lottery process of determining one of a plurality of types of game media provided in advance by lottery is executed, and the determined game medium is used as a possession game medium. , Stored in the storage unit in association with the player ID, and executes a predetermined game using the possessed game medium stored in the storage unit. During the pre-state, the execution of the lottery process exceeding the preset limit number of times is restricted, and during the present release state, the lottery process exceeding the limit number of times can be executed. [Selection diagram] Fig. 3

Description

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

Conventionally, as shown in Patent Document 1, for example, a digital card game that enables a battle between players by communication has been proposed. In such a digital card game, the player can acquire a card to be used in the battle game by executing a lottery called a so-called gacha for free or for a fee.

JP-A-2018-995

In digital card games, it is a real pleasure to play against each other by making full use of the cards possessed by the player among the various cards provided. However, the reality is that there are many players who possess all types of cards provided, such as players who have sufficient resources and players who have been playing games for a long period of time. In this case, the battle is based on the premise that all types of cards are possessed, and the original pleasure of the card game, such as making full use of the cards in a limited space, is impaired.

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

In order to solve the above problems, the information processing system is an information processing system including a player terminal and a server capable of communicating with the player terminal, and one or both of the player terminal and the server is input by the player. A player uses a lottery unit that executes a lottery process to determine one of a plurality of types of game media provided in advance by lottery based on a lottery request operation, and a game medium determined by the lottery unit as a possession game medium. A game medium storage unit that is associated with an ID and stored in a storage unit, a game execution unit that executes a predetermined game using the possessed game medium stored in the storage unit, and a period prior to a predetermined time , A management unit that limits the execution of the lottery process exceeding the preset limit number of times and enables the execution of the lottery process exceeding the limit number of times after a predetermined time.
Further, in the information processing system, the ceiling value set next may differ depending on the number of times the point value reaches the ceiling value and acquires the game medium.
Further, in the information system, when the number of times the point value reaches the ceiling value and the game medium is acquired is the first number of times, the number of times the point value reaches the ceiling value and the game medium is acquired is more than the first number of times. A larger number of points may be required to acquire the game medium than in the case of the second number of times.
In order to solve the above problems, the information processing system is an information processing system including a player terminal and a server capable of communicating with the player terminal, and one or both of the player terminal and the server is input by the player. A player uses a lottery unit that executes a lottery process to determine one of a plurality of types of game media provided in advance by lottery based on a lottery request operation, and a game medium determined by the lottery unit as a possession game medium. A game medium storage unit that is associated with an ID and stored in a storage unit, a game execution unit that executes a predetermined game using the possessed game medium stored in the storage unit, and a period prior to a predetermined time, In addition, the timing determination process for determining which period of the current period after the predetermined period is executed, and when it is determined that the period is at least during the previous period, the number of times the lottery process has been executed and the preset number of times. The management unit includes a management unit that executes a count determination process for comparing with the limit number of times, and the management unit is in the previous period and the number of times the lottery process has been executed is less than the limit number of times, and during this period. If it is, the lottery process can be executed, and if it is in the previous period and the number of times the lottery process has been executed is equal to or greater than the limit number, the execution of the lottery process is restricted.

Further, the information processing system is provided with a plurality of media classifications to which a plurality of types of game media belong, and at least a part of the game media to which the plurality of media classifications belong is different from each other, and the lottery request operation can select the media classification. In the lottery process, the lottery department determines one of a plurality of types of game media belonging to any one of the media classifications selected in the lottery request operation by lottery, and the management department specifies one during the previous period. The execution of the lottery process exceeding the limit number of times may be restricted for the medium classification of the above, and the lottery process exceeding the limit number of times may be executed for the medium classification other than the specific medium classification.

Further, the information processing system includes a first operation receiving unit in which either one or both of the player terminal and the server accepts the first operation for selecting and acquiring one of the game media when a predetermined condition is satisfied. , The game medium storage unit stores the game medium selected by the first operation in the storage unit as the possessed game medium, and the management unit cannot accept the first operation during the previous period and after a predetermined time. , The first operation may be accepted.

In order to solve the above problem, the information processing method is an information processing method executed by either one or both of the player terminal and the server capable of communicating with the player terminal, and is used for a lottery request operation input by the player. Based on this, a step of executing a lottery process of determining one of a plurality of types of game media provided in advance by lottery, and storing the determined game media as possessed game media in a storage unit in association with a player ID. The step of executing a predetermined game using the possessed game medium stored in the storage unit, and the execution of the lottery process exceeding the preset limit number of times during the previous period prior to the predetermined time are restricted. Steps to perform, a step to enable the lottery process to be executed more than the limit number of times after a predetermined time, a step to update a predetermined point value based on the execution of the lottery process, and a step to reach a preset ceiling value. If this is the case, the ceiling value includes a step of selecting one of the game media so that it can be acquired, and the ceiling value is a value at which the point value does not reach when the number of times the lottery process is executed is within the limit number of times. Moreover, it is a value that can be reached by executing the lottery process exceeding the limit number of times after a predetermined time.
In order to solve the above problem, the information processing method is an information processing method executed by either one or both of the player terminal and the server capable of communicating with the player terminal, and is used for a lottery request operation input by the player. Based on this, a step of executing a lottery process of determining one of a plurality of types of game media provided in advance by lottery and a game medium determined by the lottery process are stored in association with a player ID as possession game media. Either the step of storing in the unit, the step of executing a predetermined game using the possessed game medium stored in the storage unit, the period before the predetermined time, or the current period after the predetermined time. Executes the timing determination process for determining whether or not the period is, and executes the number of times determination process for comparing the number of times the lottery process has been executed with the preset limit number when it is determined that the period is at least during the previous period. If the number of times the lottery process has been executed is less than the limit number of times, and if the number of times the lottery process has been executed is less than the limit number, and if the lottery process is in the current period, the lottery process can be executed during the previous period. If the number of times the lottery process has been executed is equal to or greater than the limit number of times, the execution of the lottery process is restricted.

In order to solve the above problem, the information processing program executes a lottery process of determining one of a plurality of types of game media provided in advance by lottery based on a lottery request operation input by the player. Using the game medium determined by the lottery unit as the possessed game medium, the game medium storage unit that is associated with the player ID and stored in the storage unit and the possessed game medium stored in the storage unit are used to play a predetermined game. During the game execution unit to be executed and the period before the predetermined time, the execution of the lottery process exceeding the preset limit number is restricted, and after the predetermined time, the lottery process exceeding the limit number can be executed. The management unit, the point update unit that updates a predetermined point value based on the execution of the lottery process, and the point update unit that can be acquired by selecting one of the game media when the point value reaches the preset ceiling value. As a ceiling acquisition unit, the computer is made to function, and the ceiling value is a value at which the point value does not reach when the number of times the lottery process is executed is within the limit number of times, and exceeds the limit number of times after a predetermined time. It is a value that can be reached by executing the lottery process.
In order to solve the above problem, the information processing program executes a lottery process of determining one of a plurality of types of game media provided in advance by lottery based on a lottery request operation input by the player. Using the game medium determined by the lottery unit as the possessed game medium, the game medium storage unit that is associated with the player ID and stored in the storage unit and the possessed game medium stored in the storage unit are used to play a predetermined game. The game execution unit to be executed, the time determination process for determining which period is in the previous period before the predetermined time, or in the main period after the predetermined time is executed, and it is determined that the game is at least in the previous period. In that case, the computer is made to function as a management unit that executes a number determination process for comparing the number of times the lottery process has been executed with a preset limit number of times, and the management unit is in the last period. In addition, when the number of times the lottery process has been executed is less than the limit number of times, and when the lottery process has been executed, the lottery process can be executed, and the number of times the lottery process has been executed during the previous period is If the number of times exceeds the limit, the execution of the lottery process is restricted.

According to the present invention, the real pleasure 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. 3A is a diagram illustrating a game distribution period. FIG. 3B is a diagram illustrating the card classification provided for each delivery period. FIG. 3C is a diagram illustrating the relationship between the delivery period and the format. FIG. 4A is a diagram showing an example of a purchase type selection screen. FIG. 4B is a diagram illustrating an example of a card purchase screen in the pre-state. FIG. 4C is a diagram illustrating a limited number of times. FIG. 4D is a diagram illustrating the ceiling function. FIG. 5A is a diagram illustrating an example of a card purchase screen in the present release state. FIG. 5B is a diagram illustrating an example of a lottery result screen. FIG. 6A is a diagram illustrating an example of a card setting screen. FIG. 6B is a diagram illustrating an example of a format selection screen in the pre-state. FIG. 6C is a diagram illustrating an example of a deck selection screen. FIG. 7A is a diagram illustrating an example of a knitting method selection screen. FIG. 7B is a diagram illustrating an example of a deck organization screen in the initial state. FIG. 7C is a diagram illustrating an example of a deck knitting screen during knitting. FIG. 7D is a diagram illustrating an example of a copy source selection screen in the pre-state. FIG. 8A is a diagram illustrating an example of a format selection screen in the transition state. FIG. 8B is a diagram illustrating an example of a deck selection screen. FIG. 8C is a diagram illustrating an example of a knitting method selection screen. FIG. 8D is a diagram illustrating an example of a copy source selection screen in the transition state. FIG. 9A is a diagram illustrating an example of a format selection screen in this release state. FIG. 9B is a diagram illustrating an example of a copy source selection screen in this release state. FIG. 10A is a diagram illustrating an example of a card list screen. FIG. 10B is a diagram illustrating an example of a card generation screen in the pre-state. FIG. 10C is a diagram illustrating an example of a card detail screen in the pre-state. FIG. 11A is a diagram illustrating an example of a card list screen. FIG. 11B is a diagram illustrating an example of a card generation screen in this release state. FIG. 11C is a diagram illustrating an example of a card detail screen in the present release state. FIG. 12A is a diagram illustrating an example of a battle format selection screen in this release state. FIG. 12B is a diagram illustrating an example of a battle format selection screen in the pre-state. FIG. 12C is a diagram illustrating an example of a deck selection screen. FIG. 13 is a diagram illustrating an example of a card battle game. FIG. 14A is a diagram illustrating an example of functional information for the ninth period. FIG. 14B is a diagram illustrating an example of functional information for the 10th pre-stage. FIG. 14C is a diagram illustrating an example of functional information for the 10th period. FIG. 15 is a functional block diagram of the player terminal. FIG. 16 is a functional block diagram of the server. FIG. 17 is a first sequence diagram illustrating processing by the player terminal and the server. FIG. 18 is a flowchart illustrating an example of login processing in the server. FIG. 19 is a second sequence diagram illustrating processing by the player terminal and the server. FIG. 20 is a flowchart illustrating an example of the purchase information derivation process in the server. FIG. 21 is a flowchart illustrating an example of purchase screen display processing in the player terminal. FIG. 22 is a flowchart illustrating an example of the lottery execution process in the server. FIG. 23 is a flowchart illustrating an example of the lottery result reflecting process in the player terminal. FIG. 24 is a flowchart illustrating an example of acquisition execution processing in the server. FIG. 25 is a flowchart illustrating an example of acquisition result reflection processing in the player terminal. FIG. 26 is a third sequence diagram illustrating processing of the player terminal and the server. FIG. 27 is a flowchart illustrating an example of the format selection screen display process in the player terminal. FIG. 28 is a flowchart illustrating an example of deck formation processing in the player terminal. FIG. 29 is a flowchart illustrating an example of deck information storage processing in the player terminal. FIG. 30 is a flowchart illustrating an example of the card list generation screen display process in the player terminal. FIG. 31 is a flowchart illustrating an example of card generation / disassembly processing in the player terminal. FIG. 32 is a diagram illustrating an example of a card purchase screen according to a modified example. FIG. 33 is a functional block diagram of the player terminal according to the modified example. FIG. 34 is a functional block diagram of the server according to the modified example. FIG. 35 is a flowchart illustrating an example of the acquisition execution process according to the modified example.

One aspect of the embodiment of the present invention will be described in detail below with reference to the accompanying drawings. The numerical values and the like shown in such embodiments 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. To 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, a server 100, and 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 stores various information (player information) for each player who plays the game. Further, the server 100 updates the accumulated information and controls the progress of the game 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 each have a role of controlling the progress of the game, 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 display 26 as an output unit 24 and a touch panel as an input unit 22 superimposed on the display 26.

(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. The game of this embodiment is a so-called digital card game. The player can acquire and possess a plurality of types of cards provided by the operator by lottery or the like, and can play a card battle game in which the possessed cards are used to play against a computer or another player. The game content of this embodiment will be described in detail below.

FIG. 3A is a diagram illustrating a game distribution period. FIG. 3B is a diagram illustrating the card classification provided for each delivery period. FIG. 3C is a diagram illustrating the relationship between the delivery period and the format. In the present embodiment, different cards are provided according to the distribution period, and the game conditions of the card battle game, that is, the usable cards are different for each distribution period. Here, as an example, it is assumed that one delivery period is configured in four months and the delivery period is updated every four months, and each delivery period is shown in the n-1th period and the nth period as shown in FIG. 3A. The term will be described as the n + 1 term. Note that n in the nth period, which indicates the delivery period, is an arbitrary integer and increases by 1 every 4 months.

As shown in FIG. 3A, each distribution period is divided into a pre-release state (hereinafter referred to as a pre-release state) and a present release state as a distribution state. Here, as an example, it is assumed that the pre-state is provided for one month and the present release state is provided for three months. In each distribution period, the pre-state is first set, and the release state is set after the maintenance executed at the switching time one month after the start of the pre-state. That is, in each distribution period, the pre-state is set before the switching time, and the release state is set after the switching time.

As will be described in detail later, in each distribution period, the transition state is set from the start (switching time) of this release state to a predetermined period. This transition state is provided for the player to transfer the data in the pre-state, and the game conditions of the playable card battle game are the same as in this release state. Here, as an example, the transition state is set for one week. The transition state is set in parallel with this release state.

As described above, in the present embodiment, a card battle game using cards is provided. The cards used in the card battle game are provided by the operator, but each time the distribution period is updated, new cards are provided. Here, a plurality of card classifications to which each card belongs are provided. In other words, each card always belongs to at least one card classification, and the plurality of card classifications differ from each other in at least some of the cards to which they belong. In this embodiment, as an example, 120 types of cards belong to one card classification.

As shown in FIG. 3B, for example, in the 8th period, the 8th card classification is newly provided, in the 9th period, the 9th card classification is newly provided, and in the 10th period, the 10th card is newly provided. A new classification is provided. That is, in the nth period, a plurality of types of cards belonging to the nth card classification are newly provided. In addition, in each distribution period, cards provided during the previous distribution period are also provided. Therefore, in the nth period, cards belonging to the first to nth card classifications will be provided.

In the following, the nth card classification newly provided in the nth period is referred to as a new card classification, and the card classification started to be provided before the nth period is referred to as an old card classification. Further, a card belonging to the new card classification is simply called a new card, and a card belonging to the old card classification is called an old card.

In the present embodiment, the provision of a card means a situation in which the player can acquire a card, and the situation in which the player can use the card in a card battle game is called possession of the card. The player acquires the provided card by lottery or the like and possesses it, and in the card battle game, the possessed card can be used.

Further, in the present embodiment, the format of the card battle game is roughly classified into three types: rotation, unlimited, and pre-rotation. The format defines the card classification that can be used in the card battle game, that is, the card, and can be said to be a game condition in the card battle game. The player first selects a format before the start of the card battle game, and plays the card battle game using only the cards corresponding to the selected format.

Rotation is a format in which only cards belonging to the most recent five card classifications among the provided card classifications can be used. On the other hand, Unlimited has the same latest 5 types of card classification as the rotation of the same period, and in addition to the cards belonging to all the card classifications provided before that, all the cards in possession are available in a format that can be used. is there. In this way, the cards that can be used by the player in the card battle game differ between Rotation and Unlimited. During each delivery period, you can always choose between two formats: Rotation and Unlimited.

Here, as described above, since a new card classification is provided each time the distribution period is updated, the latest five types of card classifications that can be used in rotation are different for each distribution period. As shown in FIG. 3B, since the 8th card classification is newly provided in the 8th period, the latest 5 types of card classifications are the 4th to 8th card classifications. On the other hand, in the 9th period, the 9th card classification is newly provided, so the latest 5 types of card classifications become the 5th to 9th card classifications, and in the 10th period, the latest 5 types of cards. The classification will be the 6th to 10th card classification.

Then, in the present release state of each distribution period, as shown in FIG. 3C, the latest five types of card classifications can be used in rotation. On the other hand, in the pre-state of each distribution period, the same card classification as the previous distribution period can be used in the rotation. Specifically, in the 8th pre-state, the 3rd to 7th card classifications are available in the rotation, and in the 9th pre-state, the 4th to 8th card classifications are available in the rotation. , In the 10th pre-state, the 5th-9th card classifications are available in rotation.

That is, the rotation game conditions in the pre-state are the same as the rotation game conditions in the present release state of the immediately preceding distribution period. That is, in the pre-state, the rotation in the present release state of the immediately preceding distribution period can be continuously played.

Then, in the pre-state, a pre-rotation format is added separately from the rotation. Pre-rotation is the same game condition as rotation in this release state during the same distribution period. Therefore, in the 8th pre-state, the 4th to 8th card classifications are available in the pre-rotation, and in the 9th pre-state, the 5th to 9th card classifications are available in the pre-rotation. In the tenth pre-state, the sixth to ten card classifications are available in the pre-rotation.

As described above, in the pre-state, in addition to the rotation in the present release state of the immediately preceding distribution period, the rotation in the present release state of the new distribution period can be played as the pre-rotation. In this release state, you cannot play in the pre-rotation format. The differences between the pre-state and this release state will be described in detail below.

FIG. 4A is a diagram showing an example of a purchase type selection screen. FIG. 4B is a diagram illustrating an example of a card purchase screen in the pre-state. FIG. 4C is a diagram illustrating a limited number of times. FIG. 4D is a diagram illustrating the ceiling function. Further, FIG. 5A is a diagram illustrating an example of a card purchase screen in the present release state. FIG. 5B is a diagram illustrating an example of a lottery result screen. For example, when the application for this game is started, the communication between the player terminal 1 and the server 100 is started, the login state is set, and the game is started.

As shown in FIG. 4A, the menu bar 30 is displayed on the display 26 during the game. The menu bar 30 is provided with a plurality of operation units that can be operated (tapped) by the player. Here, as an example of the operation unit, the menu bar 30, the home screen selection unit 30a described as "home", the solo play selection unit 30b described as "solo play", and the battle selection unit 30c described as "battle". , A card screen selection unit 30d marked "card" and a purchase type selection unit 30e marked "shop" are provided.

When the home screen selection unit 30a is tapped, a predetermined home screen is displayed on the display 26. When the solo play selection unit 30b is tapped, various setting screens are displayed, and when the setting is made on the setting screen, a card battle game by computer battle is started. When the battle selection unit 30c is tapped, various setting screens are displayed, and when the setting is made on the setting screen, a card battle game by communication battle with another player is started. When the card screen selection unit 30d is tapped, deck organization, which will be described later, display of a list of cards, disassembly and generation of cards, and the like can be performed.

When the purchase type selection unit 30e is tapped, the purchase type selection screen shown in FIG. 4A is displayed on the display 26. On the purchase type selection screen, a supply purchase tab marked "Supply purchase", a card purchase tab 32 marked "card purchase", and a currency purchase tab marked "in-game currency purchase" are displayed. When the supply purchase tab is tapped, screens for purchasing various supplies are displayed, and various supplies such as card designs can be purchased by operating the player.

When you tap the Currency Purchase tab, you can purchase in-game currency that is only available in-game. By using the in-game currency, the player can draw a lottery to win cards or purchase a deck set in which a plurality of cards are set. Here, tickets, rupi, and diamonds are provided as in-game currencies, and the products to be purchased and the time when each product can be purchased are set for each in-game currency. The in-game currency can be obtained as a reward for the game, purchased by billing, or both.

When the card purchase tab 32 is tapped, the card purchase screen shown in FIG. 4B is displayed. The card purchase screen is displayed differently depending on the distribution period and the distribution state (pre-state or this release state) during the distribution period. 4B, 4C and 4D show pre-state card purchase screens during the tenth delivery period. The card classification selection unit 34 is displayed on the card purchase screen. The card classification selection unit 34 is provided with a tenth card classification tab 34a, a ninth card classification tab 34b, an eighth card classification tab 34c, a seventh card classification tab 34d, and a sixth card classification tab 34e. Although not shown, the card classification selection unit 34 displays the 1st to 5th card classification tabs by performing a predetermined operation.

Further, on the right side of the card classification selection unit 34, a ticket information field 36a, a rupi information field 36b, a timetable information field 36c, and a point information field 36d are displayed. In the ticket information field 36a, the number of tickets in which a card pack containing eight cards can be purchased and the purchase tab marked "Purchase" are displayed. When the purchase tab displayed in the ticket information field 36a is tapped, the card pack is purchased using the ticket. As will be described in detail later, the purchase of a card pack here means a so-called gacha card lottery, and when the card pack is purchased, a lottery process for determining the cards by lottery is executed and the lottery is performed. Eight cards determined by the process are given to the player. That is, it can be said that the card pack purchase operation is an operation that requires a card lottery process.

Tickets are provided for each card classification. For example, a ticket that can be used to purchase a card pack of the 10th card classification cannot be used to purchase a card pack of another card classification. The number of tickets possessed displayed in the ticket information field 36a corresponds to the tab tapped in the card classification selection unit 34. Therefore, when the tenth card classification tab 34a is tapped, the number of tickets possessed for the tenth card classification is displayed in the ticket information field 36a and the ninth card classification tab 34b is tapped, as shown in FIG. 4B. As shown in FIG. 4D, the number of possessed tickets for the ninth card classification is displayed in the ticket information column 36a. Each ticket can be provided by the operator, for example, or can be obtained as a reward for the result of the card battle game.

In the rupi information column 36b, the number of rupi possessed by the player and the purchase tab marked "purchase" are displayed. When the purchase tab displayed in the rupi information field 36b is tapped, a card pack is purchased using a predetermined number of rupi. Rupi can be used for card packs of all card categories. However, in the pre-state, it is set so that you cannot purchase a card pack of a new card classification using Rupi. Therefore, as shown in FIG. 4B, in the pre-state, the purchase tab of the rupi information column 36b of the new card classification is grayed out, and it is displayed so as not to accept the player's operation.

In the diamond information column 36c, the number of diamonds possessed by the player and the purchase tab marked "Purchase" are displayed. When the purchase tab displayed in the diamond information field 36c is tapped, a card pack is purchased using a predetermined number of diamonds. Diamonds can be used for card packs of all card categories. Also, unlike Rupi, diamonds can be used to purchase card packs for new card classifications even in the pre-state.

In the point information field 36d, the current points acquired by the player and the acquisition tab marked "GET" are displayed. In this embodiment, one point is given to the player when the card pack is purchased once. Then, when the acquired points of the player reach the ceiling value (300 points in this case), the player can select and acquire a favorite card from a plurality of preset cards.

However, points are managed for each card classification. For example, if a card pack of the 10th card classification is purchased once, 1 point is added for the 10th card classification, and 10 card packs of the 9th card classification are added. If you purchase once, 10 points for 9th card classification will be added. Therefore, when the tenth card classification tab 34a is tapped, the points for the tenth card classification are displayed in the point information column 36d as shown in FIG. 4B, and when the ninth card classification tab 34b is tapped, the figure is shown. As shown in 4D, the points for the ninth card classification are displayed in the point information column 36d.

In addition, the cards that can be obtained when the points reach the ceiling value are limited to the card classification corresponding to the points that reach the ceiling value. Therefore, for example, as shown in FIG. 4D, when the points for the 9th card classification reach the ceiling value, the player taps the acquisition tab of the point information field 36d to determine a predetermined card belonging to the 9th card classification. Can be acquired by selecting, but cards belonging to other card categories cannot be acquired. Here, when the point value has not reached the ceiling value, as shown in FIG. 4B, the acquisition tab of the point information field 36d is grayed out, and the player's operation is not accepted. On the other hand, when the point value has reached the ceiling value, as shown in FIG. 4D, the acquisition tab of the point information field 36d is normally displayed, and an operation for selecting and acquiring one of the cards can be accepted. It has become.

Here, even when the points reach the ceiling value, it is possible to purchase a card pack of the same card classification by using a ticket or the like. However, when the points reach the ceiling value, only the acquisition tab of the point information field 36d may be valid, and it may not be possible to purchase a card pack of the same card classification using a ticket or the like. In addition, here, if the number of tickets possessed is 0, or if the number of rupi and diamonds is less than the required number, or if the card pack cannot be purchased, the purchase tab will be grayed out and the player's operation will be accepted. I try not to.

Here, in the present embodiment, the number of purchases of the new card classification is limited in the pre-state. Specifically, in the pre-state of the 10th period, the number of purchases of the card pack of the 10th card classification newly provided in the 10th period is limited. In other words, during the pre-state, the execution of the card lottery process exceeding the preset limit number of times (here, 800 times) is restricted. Therefore, in the pre-state of the 10th period, the card pack of the 10th card classification can be purchased only up to 100 times.

As shown in FIGS. 4B and 4C, for example, in the timetable information column 36c, the upper limit (denominator) of the number of purchases of the card pack and the number of purchases of the card pack (numerator) so far in the card classification are displayed. .. When the number of purchases of the card pack reaches the upper limit, the purchase tabs of the ticket information field 36a and the diamond information field 36c are grayed out, and the player's operation is not accepted.

However, the number of purchases of card packs is limited in the pre-state only for new card classifications, and the number of purchases for old card classifications is not limited. Therefore, as shown in FIG. 4D, when the old card classification is selected by the card classification selection unit 34, the number of purchases of the card pack and the upper limit thereof are not displayed.

Further, FIG. 5A shows a card purchase screen in the 10th period of the present release state. In this release state, there are no restrictions on the purchase of card packs for new card classifications. Therefore, as shown in FIG. 5A, the number of purchases of the card pack and the upper limit thereof are not displayed on the card purchase screen even for the new card classification. Also, in this release state, it will be possible to purchase a card pack with a new card classification using Rupi.

As described above, the player can select the card classification by tapping each tab of the card classification selection unit 34, and when the purchase operation of tapping the purchase tab is performed, any one selected by the player is performed. One of the multiple types of cards belonging to the card classification of is determined by lottery. Then, during the pre-state, for new cards belonging to a specific card classification, that is, a new card classification, execution of lottery processing exceeding the limit number of times is restricted, and for card classifications other than the specific card classification, that is, old cards belonging to the old card classification Can execute the lottery process exceeding the limit number of times. Further, in the new card, the execution of the lottery process exceeding the limit number of times is restricted during the pre-state, but the lottery process exceeding the limit number of times can be executed during the present release state.

Here, the current number of card pack purchases is compared with the maximum number of card pack purchases, and when the maximum number of purchases has been reached, the purchase tab is grayed out and displayed on the player terminal 1. So, I try not to accept purchase operations. However, the method of not accepting the purchase operation is not limited to this, and for example, the purchase operation may be transmitted to the server 100 to determine whether or not the purchase operation is possible on the server 100.

When any of the above purchase tabs is tapped to purchase the card pack, the lottery process is executed on the server 100. The player terminal 1 receives the result of the lottery process, that is, the lottery result information indicating the type of the card given to the player, from the server 100. On the player terminal 1, as shown in FIG. 5B, a lottery result screen for notifying the eight cards determined in the lottery process is displayed on the display 26 based on the received lottery result information.

Here, as described above, in the present embodiment, 1 point is given each time the card pack is purchased, and 300 points are set as the ceiling value, which is a point required for exchanging the card. On the other hand, in the pre-state, the upper limit of the number of purchases of the card pack of the new card classification is set to 100 times. In other words, in the pre-state, the points do not reach the ceiling value for the new card classification. In other words, in the pre-state, the point value does not reach the ceiling value even if the number of times the lottery process is executed reaches the limit number for the new card classification. As a result, there is no contradiction that the player can acquire a favorite card even though the purchase of the card pack is restricted.

The points earned in the pre-state will be carried over even after the transition to this release state. Furthermore, even if the delivery period is updated, the points will be carried over as they are. As a result, the player does not feel a loss due to the expiration of points. However, points are not given in the pre-state, and points may be given only in this release state. Further, when the delivery period is updated, the points may be reset.

As described above, the cards determined by the lottery process, that is, the cards acquired by the player by lottery and the cards acquired by exchanging points are stored as possession cards. The player selects a plurality of (for example, 40) cards from the possessed cards to form one deck. The player can organize and save a plurality of decks, and can select one of the saved decks and use it in the card battle game. The organization of the deck will be described below.

FIG. 6A is a diagram illustrating an example of a card setting screen. FIG. 6B is a diagram illustrating an example of a format selection screen in the pre-state. FIG. 6C is a diagram illustrating an example of a deck selection screen. When the card screen selection unit 30d of the menu bar 30 is tapped, the card setting screen shown in FIG. 6A is displayed. On the card setting screen, a deck organization tab 40a and a card list generation tab 40b are displayed. When the deck organization tab 40a is tapped, the format selection screen shown in FIG. 6B is displayed.

The display contents of the format selection screen differ depending on whether the distribution state is the pre-state or the transition state and the release state (excluding the transition state). On the format selection screen, a format selection tab 42 for selecting which format the deck corresponding to the deck is to be organized is displayed. In the pre-state and the transition state, the rotation selection tab 42a, the unlimited selection tab 42b, and the pre-rotation selection tab 42c are displayed as the format selection tab 42.

When the format selection tab 42 is tapped, the deck selection screen shown in FIG. 6C is displayed. On the deck selection screen, a list of decks organized by the player is displayed. Here, the decks can be organized corresponding to any format, and only the decks corresponding to the formats selected on the format selection screen are displayed on the deck selection screen.

For example, as shown in FIG. 6B, when the pre-rotation selection tab 42c is tapped on the format selection screen, a list of decks corresponding to pre-rotation is displayed as shown in FIG. 6C. Players can organize deck names when organizing decks. On the deck selection screen, the deck name is displayed on the icon corresponding to each deck.

Further, on the deck selection screen, a deck creation tab 44 marked as "newly created" is displayed. By tapping the deck creation tab 44, the player can newly organize a deck corresponding to the format selected on the format selection screen.

FIG. 7A is a diagram illustrating an example of a knitting method selection screen. FIG. 7B is a diagram illustrating an example of a deck organization screen in the initial state. FIG. 7C is a diagram illustrating an example of a deck knitting screen during knitting. FIG. 7D is a diagram illustrating an example of a copy source selection screen in the pre-state. When the deck creation tab 44 is tapped on the deck selection screen shown in FIG. 6C, the organization method selection screen shown in FIG. 7A is displayed on the display 26. On the knitting method selection screen, a newly created tab 46a marked as "newly created" and a copy tab 46b marked as "copy" are displayed.

When the new creation tab 46a is tapped, the deck organization screen is displayed as shown in FIG. 7B. In this deck organization screen, a plurality of blanks are displayed in the upper row, and cards possessed by the player (hereinafter referred to as possessed cards) are displayed in the lower row. However, the possessed cards displayed on the deck organization screen are limited to the cards corresponding to the format selected by the player. Therefore, for example, in the case of organizing the pre-rotation format in the pre-state of the 10th period, only the cards belonging to the 6th to 10th card categories are displayed among the possessed cards, and the rotation format is organized. Is displayed only for cards belonging to the 5th to 9th card categories.

Then, on the deck formation screen, as shown in FIG. 7C, by sliding the possessed card displayed in the lower row to the upper row, the slid possessed card is arranged in the blank. In this way, on the deck formation screen, the possessed cards arranged in the upper row are temporarily registered. Then, when the save tab 48 marked "Save" provided on the deck organization screen is tapped, the deck information is stored. A deck ID is assigned to this deck information, and card group information that can identify all possessed cards that are temporarily registered is stored in association with the deck ID. Although not shown, when the save tab 48 is tapped, a screen for editing the deck name is displayed, and when the editing of the deck name is completed, the deck name and the deck selection screen are displayed together with the card group information. The icon to be displayed is associated with the deck ID and stored.

Also, when the icon is tapped on the deck selection screen shown in FIG. 6C, the deck organization screen is displayed as shown in FIG. 7C. However, in this case, the cards constituting the deck selected on the deck selection screen are displayed in the upper row, and the possessed cards are displayed in the lower row. In this case, the card displayed in the upper row can be changed to the possessed card displayed in the lower row by the operation of the player.

Further, when the copy tab 46b is tapped on the knitting method selection screen, for example, the copy source selection screen shown in FIG. 7D is displayed. On the copy source selection screen, decks that can be selected as copy sources are displayed. Similar to the deck selection screen shown in FIG. 6C, the copy source selection screen is configured so that the player can select the currently stored deck. However, the deck that can be selected as the copy source differs depending on the distribution status and the format of the newly created deck, that is, the format of the copy destination.

Specifically, if the copy destination format is Unlimited, decks of all formats can be selected as the copy source. Therefore, when organizing a deck for Unlimited, all currently stored decks are displayed as copy sources on the copy source selection screen. On the other hand, when organizing a deck for pre-rotation, only the currently stored deck for pre-rotation is displayed on the copy source selection screen as shown in FIG. 7D.

When the icon displayed on the copy source selection screen is tapped, the deck organization screen is displayed as shown in FIG. 7C. In this case, the cards constituting the deck selected on the copy source selection screen are displayed in the upper row, and the possessed cards are displayed in the lower row, and a new deck can be organized based on the copy source deck. In this way, the deck copy function makes it possible to easily organize, for example, a deck in which only some cards are different.

Further, when organizing a deck for rotation, the deck displayed on the copy source selection screen differs depending on the distribution state.

FIG. 8A is a diagram illustrating an example of a format selection screen in the transition state. FIG. 8B is a diagram illustrating an example of a deck selection screen. FIG. 8C is a diagram illustrating an example of a knitting method selection screen. FIG. 8D is a diagram illustrating an example of a copy source selection screen in the transition state. In the transition state, when the deck organization tab 40a is tapped on the card setting screen shown in FIG. 6A, the format selection screen shown in FIG. 8A is displayed. In the transition state, the rotation selection tab 42a, the unlimited selection tab 42b, and the pre-rotation selection tab 42c are displayed as the format selection tab 42 on the format selection screen as in the pre-state.

Then, when the rotation selection tab 42a is tapped on the format selection screen, a list of rotation decks is displayed on the deck selection screen shown in FIG. 8B. Note that FIG. 8B shows a state in which no deck for rotation is stored. If no deck of the format selected by the player is stored, only the deck creation tab 44 is displayed on the deck selection screen.

When the deck creation tab 44 is tapped on the deck selection screen, the organization method selection screen shown in FIG. 8C is displayed. At this time, when the copy tab 46b is tapped, the copy source selection screen shown in FIG. 8D is displayed. Here, when organizing a rotation deck in the transition state, the pre-rotation deck and the rotation deck are displayed on the copy source selection screen. That is, in the transition state, when a new deck for rotation is created, the player can select a deck for pre-rotation and a deck for rotation as the copy source deck.

FIG. 9A is a diagram illustrating an example of a format selection screen in this release state. FIG. 9B is a diagram illustrating an example of a copy source selection screen in this release state. In this release state (excluding the transition state), when the deck organization tab 40a is tapped on the card setting screen shown in FIG. 6A, the format selection screen shown in FIG. 9A is displayed. In this release state (excluding the transition state), the rotation selection tab 42a and the unlimited selection tab 42b are displayed as the format selection tab 42 on the format selection screen. That is, in this release state (excluding the transition state), unlike the pre-state and the transition state, the pre-rotation selection tab 42c is not displayed. As described above, since the pre-rotation selection tab 42c is not displayed, it is not possible to organize a deck corresponding to the pre-rotation in the present release state (excluding the transition state).

Then, it is assumed that the rotation selection tab 42a is tapped on the format selection screen, the deck creation tab 44 is tapped on the deck selection screen (see FIG. 8B), and the copy tab 46b is tapped on the knitting method selection screen (see FIG. 8C). In this case, the copy source selection screen shown in FIG. 9B is displayed. When organizing a deck for rotation in this release state (excluding the transition state), only the deck for rotation is displayed on the copy source selection screen, and the decks for pre-rotation and unlimited are not displayed. That is, in the present release state (excluding the transition state), when a new rotation deck is created, the player can select only the already organized rotation deck as the copy source deck.

For example, in the pre-rotation period 10th period, cards belonging to the 5th to 9th card classifications can be used in the rotation card battle game, and cards belonging to the 6th to 10th card classifications can be used in the pre-rotation card battle game. It is available. In addition, in this release state (including the transition state) after the pre-state, cards belonging to the 6th to 10th card categories can be used in the rotation card battle game, and the pre-rotation card battle game cannot be executed. Become.

In the 10th period, the pre-rotation in the pre-state and the rotation in the present release state (including the transition state) are the same game conditions, and the cards that can be used are common. Therefore, the deck for pre-rotation organized in the pre-state also supports the rotation in the present release state (including the transition state). In the transition state, the rotation deck can be organized using the 10th pre-rotation deck as the copy source. As a result, after shifting to the present release state (including the transition state), the trouble of reorganizing the same deck as the deck used in the pre-state can be omitted, and the operability can be improved.

Further, in the present embodiment, as described above, each card can be acquired by lottery or by exchanging points, but the player can also generate each card by himself / herself. Each card can be generated using coins given to the player in the game. In addition, the player can disassemble unnecessary cards and convert them into coins. However, card generation and disassembly are partially restricted depending on the distribution status.

FIG. 10A is a diagram illustrating an example of a card list screen. FIG. 10B is a diagram illustrating an example of a card generation screen in the pre-state. FIG. 10C is a diagram illustrating an example of a card detail screen in the pre-state. FIG. 11A is a diagram illustrating an example of a card list screen. FIG. 11B is a diagram illustrating an example of a card generation screen in this release state. FIG. 11C is a diagram illustrating an example of a card detail screen in the present release state. When the card list generation tab 40b is tapped on the card setting screen shown in FIG. 6A, the card list screens shown in FIGS. 10A and 11A are displayed.

On the card list screen, a possession card tab 50a, a generation mode tab 50b, and a possession coin display field 50c are provided at the lower part of the display 26. The possessed card tab 50a and the generation mode tab 50b are configured to accept a player's tap operation. The possessed card tab 50a and the generation mode tab 50b are also displayed on the card generation screen. When the possessed card tab 50a is tapped, the card list screens shown in FIGS. 10A and 11A are displayed, and the generation mode tab 50b is tapped. Then, the card generation screens shown in FIGS. 10B and 11B are displayed. On the other hand, in the possessed coin display field 50c, the number of possessed coins possessed by the player is displayed.

As shown in FIGS. 10A and 11A, the cards possessed by the player and the number of cards possessed by the player are displayed on the card list screen. On the card list screen, cards that the player does not have may be displayed. Further, as shown in FIGS. 10B and 11B, all the provided cards are displayed on the card generation screen regardless of whether or not the player possesses them. However, the cards possessed by the player are displayed in color, whereas the cards not possessed by the player are displayed in gray out (shown by broken lines in FIGS. 10B and 11B). As a result, the player can easily identify whether or not the card is in his possession.

Further, in the pre-state, among the cards that the player does not have, the new card is concealed. In this confidential display, the name of the card and the function information described later are displayed, but the design is hidden. In FIG. 10B, among the cards in the lower row, up to the fourth card from the left is secretly displayed, and these four cards are new cards. On the other hand, in this release state (including the transition state), as shown in FIG. 11B, a pattern is also displayed for the new card. In addition, the confidential display of the new card may completely hide the name and function information of the card.

When each card is tapped on the card list screen and the card generation screen, the card details screen is displayed as shown in FIGS. 10C and 11C. On the card details screen, various information related to the tapped card is displayed, and a disassembly tab 52a and a generation tab 52b are provided. For example, in this release state (including the transition state), as shown in FIG. 11C, the number of coins earned is displayed on the disassembly tab 52a provided on the card details screen. When the disassembly tab 52a is tapped, the currently selected card is disassembled, and the player can acquire the number of coins earned displayed on the disassembly tab 52a. If the card is disassembled, the number of cards in possession will decrease.

That is, the player can exchange the possessed card for coins by tapping the disassembly tab 52a. The above disassembly function can be executed only on the cards possessed by the player. Therefore, although not shown, the disassembly tab 52a is grayed out on the card details screen of the card that the player does not have, and the tap operation cannot be accepted.

In addition, the number of coins consumed is displayed on the generation tab 52b provided on the card details screen. When the generation tab 52b is tapped, the number of coins consumed displayed on the generation tab 52b can be consumed to generate the selected card. When a card is generated, the number of possession of the card increases. That is, the player can exchange the possessed coins for a card by tapping the generation tab 52b. Such a card generation function can be executed regardless of whether or not the player possesses the card. That is, the player can generate cards for both the cards he has and the cards he does not have.

The provided cards may be provided with a card that can be generated and a card that cannot be generated, or all cards may be able to be generated. Furthermore, a card may be included in which a time when it can be generated and a time when it cannot be generated are set.

Here, in this release state (including the transition state), the card disassembly function and the generation function are not limited, but in the pre-state, the card disassembly function and the generation function are provided for some cards. Be restricted. Specifically, in the pre-state, new cards cannot be disassembled and generated. Therefore, in the pre-state, on the card details screen of the new card, as shown in FIG. 10C, the disassembly tab 52a and the generation tab 52b are displayed in a manner of notifying that the tap operation is not accepted. In this case, even if the disassembly tab 52a and the generation tab 52b are tapped, the tap operation is not accepted.

However, even in the pre-state, for the old card, the disassembly tab 52a and the generation tab 52b are operably provided on the card details screen as shown in FIG. 11C. That is, in the pre-state, only the old card can be disassembled and generated.

As described above, in the present embodiment, the generation tab 52b that accepts the operation (generation operation) for selecting and acquiring any card is provided, and the card selected by the generation operation is stored as a possession card. .. However, during the pre-state, the generation operation cannot be accepted for the new card, and the generation operation can be accepted during the current release state (including the transition state). In this way, in the pre-state, the acquisition by purchasing and generating new cards is restricted, so the player needs to play the card battle game with a limited number of possessed cards, and the original pleasure of the card battle game is improves.

In the pre-state, not only the new card but also the old card generation operation may not be accepted. Further, in the pre-state, a part of the new card may be able to be generated. Furthermore, the number of new cards that can be generated may be different depending on the time, such as increasing the number of new cards that can be generated in stages during the distribution period.

Next, an example of a card battle game using the above decks and cards will be described. FIG. 12A is a diagram illustrating an example of a battle format selection screen in this release state. FIG. 12B is a diagram illustrating an example of a battle format selection screen in the pre-state. FIG. 12C is a diagram illustrating an example of a deck selection screen. When the solo play selection unit 30b or the battle selection unit 30c of the menu bar 30 is tapped, the battle format selection screen shown in FIG. 12A or FIG. 12B is displayed. This battle format selection screen is a screen for selecting the format of the card battle game to be played.

In this release state, as shown in FIG. 12A, the rotation selection tab 42a and the unlimited selection tab 42b are displayed as the format selection tab 42 on the battle format selection screen. On the other hand, in the pre-state, as shown in FIG. 12B, the rotation selection tab 42a, the unlimited selection tab 42b, and the pre-rotation selection tab 42c are displayed as the format selection tab 42 on the battle format selection screen.

The player can select the format of the card battle game to be played by tapping any of the format selection tabs 42. Here, in the present release state, as shown in FIG. 12A, the pre-rotation selection tab 42c is not displayed. Therefore, in this release state, the card battle game using the deck for pre-rotation cannot be executed.

Further, when any of the format selection tabs 42 is tapped on the battle format selection screen, the deck selection screen shown in FIG. 12C is displayed. Only decks for the format selected by the player are displayed on this deck selection screen. Then, when any of the decks displayed on the deck selection screen is tapped, the deck confirmation tab 54a and the decision tab 54b are displayed. When the deck confirmation tab 54a is tapped, a deck confirmation screen (not shown) is displayed. On this deck confirmation screen, all the cards that make up the deck selected by the player are displayed. On the other hand, when the decision tab 54b is tapped, a card battle game using the selected deck is started.

FIG. 13 is a diagram illustrating an example of a card battle game. The card battle game in this embodiment is a two-player battle type, and cards to be the player's hand are randomly distributed from the deck selected by the player. Similarly, the opponent will also be randomly dealt cards that will be the opponent's hand from the deck selected by the opponent. Further, in the card battle game, the player's turn and the opponent's turn are alternately repeated. Each turn, randomly selected cards from the deck are added to your hand. In his / her turn, the player selects a basic card from his / her hand and puts it into play according to a predetermined rule, or uses a skill card to exert a predetermined effect.

In each turn, valid points are set, and consumption values are set for each card. When the player puts the card into play or uses it, the consumption value set on the card is subtracted from the valid points. The player can use the cards in his hand within the range of valid points.

In addition to the consumption value, the basic card is further set with two function values of attack power and physical strength. The attack power indicates the damage value given to the opponent, and the physical strength indicates the damage value until the card is destroyed. In the card battle game, a life value (20 in this case) is given to each player and the opponent, and the player and the opponent who first set the life value to 0 by the card attack wins.

FIG. 14A is a diagram illustrating an example of functional information for the ninth period. FIG. 14B is a diagram illustrating an example of functional information for the 10th pre-stage. FIG. 14C is a diagram illustrating an example of functional information for the 10th period. In a card battle game, the progress of the game, such as displaying cards and calculating the damage value when using cards, is executed based on functional information. Further, when displaying cards on the deck organization screen or the like described above, display control such as display of a pattern or display of each function value is performed based on the function information.

The function information stores all the information for each card. As an example, one card ID includes a card classification ID that identifies the card classification, a card name, illustration information displayed on the card, and a function value ( Consumption value, attack power, physical strength, special ability), the number that can be organized, which is the upper limit that can be organized in one deck, is associated.

For example, in this release state of the 9th period, as shown in FIG. 14A, the functional information for the 9th period is stored in the player terminal 1 and the server 100. In the function information for the 9th period, each of the above information is stored for all the cards belonging to the 1st to 9th card categories, that is, all the cards provided in the 9th period. Then, in this release state of the 9th period, the progress of the card battle game in the rotation and unlimited formats is controlled with reference to the functional information for the 9th period shown in FIG. 14A.

Then, when the distribution period reaches the 10th period, the function information for the 10th period pre-display shown in FIG. 14B is stored in the player terminal 1 and the server 100 while retaining the function information for the 9th period. That is, in the 10th period pre-state, two types of functional information for the 9th period and the 10th period pre-state are stored. Then, in the pre-state of the 10th period, the card battle game in the pre-rotation format is progress-controlled with reference to the function information for the 10th period pre-shown in FIG. 14B, and the card battle game in the rotation and unlimited formats. However, the progress is controlled with reference to the functional information for the 9th period shown in FIG. 14A.

Here, as shown by a thick line in FIG. 14B, some of the function values set on the same card are different between the function information for the 9th period and the function information for the 10th period pre. .. That is, in the 10th period pre-state, the function information for the 9th period in which the functions provided by the cards in the rotation card battle game are associated with each card, and the functions provided by the cards in the pre-rotation card battle game are provided. A plurality of functional information including the functional information for the 10th period pre-corresponding to each card is stored. Then, the card corresponds to both the rotation game condition in the pre-state of the 10th period and the pre-rotation game condition, and has the function information for the 9th period and the function information for the 10th period pre. Includes specific cards with different functions associated with.

The cards that can be used, that is, the game conditions, differ between the rotation that can be played in the pre-state of the 10th period and the pre-rotation. If the combination of cards that can be organized in the deck is changed, the functions of some cards may become too strong or too weak. By changing the functions of some of these cards, it is possible to provide an optimal game environment.

Then, when the pre-state of the 10th period is completed, the release state is reached with maintenance in between. In the maintenance between the pre-state of the 10th period and this release state, the function information for the 9th period is changed to the function information for the 10th period on the server 100, and the function information for the 10th period pre-state is changed. Is deleted. Further, when the player terminal 1 first communicates with the server 100 after the transition to the 10th release state, the functional information of the player terminal 1 is changed in the same manner as the server 100.

Therefore, in this release state of the 10th period, only the functional information for the 10th period shown in FIG. 14C is stored in the player terminal 1 and the server 100. In this release state of the 10th period, the progress of the card battle game in the rotation and unlimited formats is controlled with reference to the functional information for the 10th period shown in FIG. 14C.

As shown by the thick line in FIG. 14C, the functions of some of the cards are changed between the function information for the 10th period pre and the function information for the 10th period. However, these functional changes are not essential. In addition, here, in this release state, it was decided to delete the pre-function information for the same distribution period, but this pre-function information is retained in this release state, and the distribution period is updated. At that time, it may be updated with new pre-function information. Further, although the functional information in the 9th period and the 10th period has been described here, the functional information is updated in the same manner as described above in the other distribution periods.

The processing of the player terminal 1 and the server 100 for realizing the above-mentioned card battle game, and the functional unit that executes each of these processing will be described below. In the following, the processing related to the difference between the pre-state and the present release state will be described, and the description of other processing will be omitted.

(Functional part of player terminal 1)
FIG. 15 is a functional block diagram of the player terminal 1. The memory 12 of the player terminal 1 is provided with a program storage area 12a and a data storage area 12b. At the start of the game, the CPU 10 stores the terminal-side game control program (module) in the program storage area 12a.

The terminal-side game control program includes a function information receiving program 60, a state management program 61, a screen management program 62, an information update program 63, a deck information storage program 64, and a battle game execution program 65. The programs listed in FIG. 15 are examples, and a large number of other programs are provided in the terminal-side game control program.

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 control unit 1A by operating each program stored in the program storage area 12a. The terminal control unit 1A includes a function information receiving unit 60a, a state management unit 61a, a screen management unit 62a, an information updating unit 63a, a deck information storage unit 64a, and a battle game execution unit 65a.

Specifically, the CPU 10 operates the function information receiving program 60 to make the computer function as the function information receiving unit 60a. Similarly, the CPU 10 operates the state management program 61, the screen management program 62, the information update program 63, the deck information storage program 64, and the battle game execution program 65, and operates the state management unit 61a, the screen management unit 62a, and the information update unit, respectively. It functions as 63a, a deck information storage unit 64a, and a battle game execution unit 65a.

In the data storage area 12b, functional information storage unit 80, state information storage unit 81, purchase maximum number of times storage unit 82, purchase number of times storage unit 83, in-game currency information storage unit 84, and point storage are stored as storage units for storing data. Unit 85, ceiling value storage unit 86, purchase availability information storage unit 87, acquisition availability information storage unit 88, possession card information storage unit 89, first deck storage area 90, second deck storage area 91, third deck storage area 92, All card information storage units 93 and possession coin storage units 94 are provided. Each of the above storage units is an example, and a large number of other storage units are provided in the data storage area 12b.

(Functional part of server 100)
FIG. 16 is a functional block diagram of the server 100. The memory 112 of the server 100 is provided with a program storage area 112a and a data storage area 112b. In the program storage area 112a, a login processing program 160, a state management program 161, a lottery program 162, a lottery management program 163, a point exchange program 164, and a battle game execution program 165 are stored as server-side game control programs. The programs listed in FIG. 16 are examples, and a large number of other programs are provided in the server-side game control program.

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 causes the server 100 (computer) to function as the server control unit 100A by operating each program stored in the program storage area 112a. The server control unit 100A includes a login processing unit 160a, a state management unit 161a, a lottery unit 162a, a lottery management unit 163a, a point exchange unit 164a, and a battle game execution unit 165a.

Specifically, the CPU 110 operates the login processing program 160 to make the computer function as the login processing unit 160a. Similarly, the CPU 110 operates a state management program 161, a lottery program 162, a lottery management program 163, a point exchange program 164, and a battle game execution program 165, respectively, and operates a state management unit 161a, a lottery unit 162a, a lottery management unit 163a, and points, respectively. It functions as an exchange unit 164a and a battle game execution unit 165a.

In the data storage area 112b, functional information storage unit 180, state information storage unit 181, purchase upper limit number of times storage unit 182, purchase number of times storage unit 183, in-game currency information storage unit 184, and point storage are stored as storage units for storing data. Unit 185, ceiling value storage unit 186, purchase availability information storage unit 187, acquisition availability information storage unit 188, possession card information storage unit 189, first deck storage area 190, second deck storage area 191 and third deck storage area 192, All card information storage units 193 and possession coin storage units 194 are provided. Each of the above storage units is an example, and a large number of other storage units are provided in the data storage area 112b.

As described above, the data storage area 112b of the server 100 is provided with the same storage unit as the data storage area 12b of the player terminal 1, and in the present embodiment, all the information stored in the data storage area 12b is data. It is also stored in the storage area 112b. The processing performed by the terminal control unit 1A and the server control unit 100A described above will be described below.

(Communication processing between player terminal 1 and server 100)
FIG. 17 is a first sequence diagram illustrating the processing of the player terminal 1 and the server 100. When the player inputs an operation for starting the game, the player terminal 1 executes the login request process. In this login request processing, login information is transmitted to the server 100 (P1). Upon receiving the login information, the server 100 executes the login process (S1).

FIG. 18 is a flowchart illustrating an example of the login process (S1) in the server 100. Upon receiving the login information, the login processing unit 160a identifies the player terminal 1 and acquires the last login date and time (S1-1). Then, the login processing unit 160a determines whether or not the user has logged in in the distribution state (pre-state or this release state) in the current distribution period (S1-2). If you are not logged in (NO in S1-2), various information for the current distribution status is set as download information (S1-3). Here, the download destination of the function information corresponding to the current distribution state is set.

Further, the login processing unit 160a acquires the state information updated by the state management unit 161a based on the date and time from the state information storage unit 181 (S1-4) and sets it as download information (S1-5). The status information includes the current distribution period, and three distribution states of the pre-state, the transition state, and the present release state, such as the nth period pre-state, the nth period transition state, and the nth period main release state. The information is configured so that it can be identified which one.

Returning to FIG. 17, when the above login process (S1) is executed, the player terminal 1 acquires download information indicating the download destination of information such as various data and programs for executing the game, and the acquired download. Based on the information, various information is downloaded to the player terminal 1 (P2). As a result, various information will be updated on the player terminal 1 when logging in for the first time after the distribution period and the distribution state are updated. When logging in for the first time, the function information receiving unit 60a downloads the function information corresponding to the current distribution state and stores it in the function information storage unit 80, or the function information from the function information storage unit 80. To delete.

Further, here, the state management unit 61a receives the state information set by the server 100 and stores it in the state information storage unit 81. As a result, the player terminal 1 can grasp the current distribution period and distribution state.

FIG. 19 is a second sequence diagram illustrating the processing of the player terminal 1 and the server 100. When the card purchase tab 32 (see FIG. 4A) is tapped on the player terminal 1, the terminal control unit 1A performs a request information transmission process (P11) for transmitting the request information to the server 100. When the server 100 receives the request information, the server 100 executes the purchase information derivation process (S11).

FIG. 20 is a flowchart illustrating an example of the purchase information derivation process (S11) in the server 100. Upon receiving the request information, the server control unit 100A determines whether it is in the pre-state (S11-1). If it is in the pre-state (YES in S11-1), the server control unit 100A acquires the maximum number of purchases of the card pack of the new card classification in the current distribution period stored in the maximum number of purchases storage unit 182. (S11-2), set the purchase upper limit number of times information (S11-3). Further, the server control unit 100A acquires the number of purchases of the new card classification in the current distribution period, that is, the number of purchases, which is stored in the purchase number storage unit 183 (S11-4), and obtains the purchase number information. Set (S11-5).

Then, when the number of purchases is less than the upper limit of purchases (YES in S11-6), the server control unit 100A sets the purchaseable information indicating that the purchases are possible (S11-7), and the number of purchases is the upper limit of purchases. If it is not less than the number of times (NO in S11-6), non-purchasable information indicating that the purchase is impossible is set (S11-8).

Further, the server control unit 100A acquires and sets the in-game currency information (the number of tickets, rupi and diamonds) stored in the in-game currency information storage unit 184 regardless of whether or not it is in the pre-state. (S11-9). Further, the server control unit 100A increments the card classification identification number n (S11-10), and acquires the points of the nth card classification corresponding to the card classification identification number n stored in the point storage unit 185 (S11-10). S11-11) and set (S11-12).

Further, the server control unit 100A acquires and sets the ceiling value of the nth card classification corresponding to the card classification identification number n stored in the ceiling value storage unit 186 (S11-13) (S11-14). Then, when the current point is equal to or higher than the ceiling value (YES in S11-15), the server control unit 100A sets the acquireable information indicating that the card can be acquired by the point (S11-16), and currently When the points of are not equal to or higher than the ceiling value (NO in S11-15), the non-acquirable information indicating that the card cannot be acquired by the points is set (S11-17).

When the card classification identification number n is the maximum value (YES in S11-18), the server control unit 100A sets the card classification identification number n to 0 (S11-19) and ends the purchase information derivation process. On the other hand, when the card classification identification number n is not the maximum value (NO in S11-18), the server control unit 100A repeats the process from S11-10. As a result, point information, ceiling price information, acquireable information or non-acquirable information is set for all currently provided card classifications. As shown in FIG. 19, each information set in the purchase information derivation process is received as purchase information in the purchase screen display process (P12) executed in the player terminal 1.

FIG. 21 is a flowchart illustrating an example of the purchase screen display process (P12) in the player terminal 1. The information updating unit 63a stores the received purchase information (P12-1). Here, the information updating unit 63a stores the maximum number of purchases in the maximum number of purchases storage unit 82, stores the number of purchases in the number of purchases storage unit 83, and stores the number of tickets, rupi, and diamonds in the in-game currency information storage unit 84. Is stored, points for each card classification are stored in the point storage unit 85, ceiling values for each card classification are stored in the ceiling value storage unit 86, and purchaseable information or purchase received as purchase information is stored in the purchase availability information storage unit 87. The impossible information is stored, and the acquireable information or the non-acquirable information received as purchase information is stored in the acquisition availability information storage unit 88.

Then, the state information of the state information storage unit 81 is confirmed, and if it is currently in the pre-state (YES on P12-2), the screen management unit 62a generates a card purchase screen for the pre-state (see FIG. 4B). (P12-3). Here, regarding the new card classification, it is possible to purchase only by using a ticket or a diamond, and a screen displaying the maximum number of purchases and the number of purchases is generated. At this time, if the number of purchases has reached the maximum number of purchases, a card purchase screen is generated so that purchases by using tickets and diamonds are also impossible.

On the other hand, if it is not currently in the pre-state (NO on P12-2), the screen management unit 62a generates a card purchase screen (see FIG. 5A) for this release state (P12-4). Here, a card purchase screen that enables purchase by using tickets, rupi, and diamonds is generated. In addition, when the points corresponding to the new card classification in the current distribution period are equal to or higher than the ceiling value (YES on P12-5), the screen management unit 62a displays the normal display acquisition tab that can be tapped in the point information field 36d. (See FIG. 4D) is generated (P12-6).

On the other hand, when the points corresponding to the new card classification in the current distribution period are not equal to or higher than the ceiling value (NO on P12-5), the screen management unit 62a displays the grayed out acquisition tab in the point information field 36d where tap operation is not possible. (See FIG. 4B) is generated (P12-7). Then, the screen management unit 62a displays the card purchase screen generated as described above on the display 26 (P12-8).

Here, when the card purchase screen is displayed, the ticket information column 36a, the rupi information column 36b, the diamond information column 36c, and the point information column 36d corresponding to the new card classification in the current distribution period are the top pages of the card purchase screen. Is displayed on the display 26. Although detailed explanation is omitted, when each tab of the card classification selection unit 34 is tapped, the ticket information field 36a, the rupi information field 36b, the diamond information field 36c, and the point information corresponding to the card classification of the tapped tab are tapped. The column 36d is displayed on the display 26.

Returning to FIG. 19, when the purchase tab is tapped on the card purchase screen, the terminal control unit 1A executes the lottery request process (P13) for transmitting the lottery request information to the server 100. The lottery request information is configured so that the card classification can be identified, and the lottery request information corresponding to the tab tapped by the card classification selection unit 34 is transmitted to the server 100. When the server 100 receives the lottery request information, the server 100 performs the lottery execution process (S12).

FIG. 22 is a flowchart illustrating an example of the lottery execution process (S12) in the server 100. Upon receiving the lottery request information, the lottery unit 162a confirms the purchase currency type (S12-1). Here, the purchase currency type is any in-game currency of ticket, rupi, and diamond. Next, the lottery management unit 163a confirms the card classification corresponding to the received lottery request information (S12-2). It is a new card classification in the current distribution period (YES in S12-3), and if it is currently in the pre-state (YES in S12-4), it is determined whether the number of purchases is less than the maximum number of purchases (S12-). 5).

If the number of purchases is not less than the maximum number of purchases, that is, if the number of purchases has reached the maximum number of purchases (NO in S12-5), the lottery management unit 163a executes a predetermined error process (S12-6). ). In this case, the purchase of the card, that is, the lottery of the card is not executed. Further, the lottery management unit 163a executes error processing (S12-6) even when the purchased currency is less than the required amount (NO in S12-7), and does not execute the card lottery.

When it is determined in S12-3 to S12-7 that the conditions for executing the card lottery are satisfied, the lottery unit 162a increments the lottery number identification number n (S12-8). Then, the lottery unit 162a sets a lottery table corresponding to both the card classification and the lottery number identification number (S12-9). A lottery table is provided for each card classification, and a winning ratio is set for all the cards belonging to the card classification. The lottery unit 162a acquires a randomly generated random number value, and performs a determination process of determining any one card based on the acquired random number value and the lottery table (S12-10).

Then, the lottery unit 162a stores the card information determined in the determination process (S12-11) and sets the card information (S12-12). The card information set here is received by the player terminal 1. The lottery unit 162a determines whether the lottery number identification number n is the maximum (8 in this case) (S12-13), and if it is not the maximum (NO in S12-13), the process is repeated from S12-8.

Further, if the lottery number identification number n is the maximum (YES in S12-13), the lottery unit 162a uses the eight card information stored in S12-11 as possession card information in the possession card information storage unit 189. Is stored in association with the player ID (S12-14). The possessed card information storage unit 189 is configured to be able to store the possessed number in association with all the card information, and here, the possessed number of the corresponding card information is updated.

Further, the server control unit 100A updates the purchase currency (ticket, rupi, and diamond) used for purchasing the card in the in-game currency information storage unit 184 (S12-15), and sets the updated purchase currency information. (S12-16). The purchase currency information set here is received by the player terminal 1.

Further, the server control unit 100A adds 1 to the points stored in the point storage unit 185, and 1 adds the number of purchases stored in the purchase number storage unit 183 (S12-17). In the point storage unit 185 and the purchase number storage unit 183, points and the number of purchases are stored for each card classification, respectively. Then, the server control unit 100A sets the point information indicating the updated points and the purchase number information indicating the number of purchases after the update (S12-18). The point information and the purchase count information set here are received by the player terminal 1.

Returning to FIG. 19, when the lottery execution process (S12) is performed as described above, the player terminal 1 receives the above card information, purchase currency information, point information, and purchase count information as lottery result information. When the lottery result information is received, the lottery result reflection process (P14) is performed on the player terminal 1.

FIG. 23 is a flowchart illustrating an example of the lottery result reflecting process in the player terminal 1. Upon receiving the lottery result information, the screen management unit 62a analyzes the card information received as the lottery result information (P14-1), and generates and displays the lottery result screen (see FIG. 5B) (P14-2). Further, the information updating unit 63a stores the received card information as the possessed card information in the possessed card information storage unit 89 based on the analysis result of the card information (P14-3). The possessed card information storage unit 89 is configured to be able to store the possessed number in association with all the card information, and here, the possessed number of the corresponding card information is updated.

Then, the information update unit 63a updates the number of purchase currency information (tickets, rupi and diamonds) of the in-game currency information storage unit 84 based on the purchase currency information received as the lottery result information (P14-4), and points. Based on the information, the points of the point storage unit 85 are updated (P14-5). Further, the information updating unit 63a updates the number of purchases stored in the purchase number storage unit 83 based on the purchase number information (P14-6). As a result, information is shared between the player terminal 1 and the server 100.

Returning to FIG. 19, when the acquisition tab is tapped on the card purchase screen, the terminal control unit 1A executes the acquisition request process (P15). In the acquisition request processing, cards that can be exchanged for points are displayed, and when the player selects a card that can be exchanged for points, the acquisition request information is transmitted to the server 100. The acquisition request information is configured so that the card classification ID and the card ID can be identified. When the server 100 receives the acquisition request information, the server 100 performs the acquisition execution process (S13).

FIG. 24 is a flowchart illustrating an example of the acquisition execution process (S13) in the server 100. Upon receiving the acquisition request information, the point exchange unit 164a analyzes the received acquisition request information (S13-1), and among the points stored in the point storage unit 185, the points of the card classification shown in the acquisition request information. Is determined to be greater than or equal to the ceiling value (300) (S13-2). If the points stored in the point storage unit 185 are not equal to or higher than the ceiling value (NO in S13-2), the point exchange unit 164a executes error processing (S13-3).

On the other hand, if the points stored in the point storage unit 185 are equal to or higher than the ceiling value (YES in S13-2), the point exchange unit 164a sets the acquisition information indicating the acquisition of the card indicated in the acquisition request information (S13). -4). Then, the server control unit 100A stores the acquired card information as possessed card information (S13-5). Further, the point exchange unit 164a subtracts the ceiling value (300) from the points stored in the point storage unit 185 (S13-6), and sets the updated point information (S13-7).

Returning to FIG. 19, when the acquisition execution process (S13) is performed as described above, the player terminal 1 receives the acquisition information and the point information as the acquisition result information. When the acquisition result information is received, the acquisition result reflection process (P16) is performed on the player terminal 1.

FIG. 25 is a flowchart illustrating an example of the acquisition result reflection process (P16) in the player terminal 1. Upon receiving the acquisition result information, the screen management unit 62a analyzes the acquisition information received as the acquisition result information (P16-1), generates and displays the acquisition result screen (P16-2). Further, the information updating unit 63a stores (increases the number of possessed cards) the card information shown in the received acquired information in the possessed card information storage unit 89 as possessed card information based on the analysis result of the acquired information (P16-). 3). Further, the information updating unit 63a updates the points stored in the point storage unit 85 based on the point information received as the acquisition result information (P16-4).

FIG. 26 is a third sequence diagram illustrating the processing of the player terminal 1 and the server 100. When the deck organization tab 40a (see FIG. 6A) is tapped on the player terminal 1, the screen management unit 62a executes the format selection screen display process (P21).

FIG. 27 is a flowchart illustrating an example of the format selection screen display process (P21) in the player terminal 1. The screen management unit 62a confirms the state information stored in the state information storage unit 81 (P21-1). Then, if it is in the pre-state or the transition state (YES in P21-2), the screen management unit 62a generates a format selection screen for the pre-state (see FIG. 6B) (P21-3), and the generated format selection screen. Is displayed on the display 26 (P21-5). The screen management unit 62a generates a rotation selection tab 42a, an unlimited selection tab 42b, and a pre-rotation selection tab 42c on the format selection screen for the pre-state.

On the other hand, if it is neither the pre-state nor the transition state (NO on P21-2), the screen management unit 62a generates a format selection screen (see FIG. 9A) for this release state (P21-4), and generates it. The format selection screen is displayed on the display 26 (P21-5). The screen management unit 62a generates a rotation selection tab 42a and an unlimited selection tab 42b on the format selection screen for this release state.

Returning to FIG. 26, when the format selection screen is displayed as described above, the deck organization process (P22) is executed in the player terminal 1. In the following, the description of the processing related to the Unlimited format will be omitted.

FIG. 28 is a flowchart illustrating an example of the deck formation process (P22) in the player terminal 1. When the rotation selection tab 42a is tapped (YES on P22-1), the screen management unit 62a loads the deck ID stored in the first deck storage area 90, and the deck selection screen is based on the loaded deck ID. (See FIG. 8B) is displayed (P22-2). Further, when the pre-rotation selection tab 42c is tapped on the deck selection screen (YES on P22-3), the screen management unit 62a loads the deck ID stored in the second deck storage area 91, and the loaded deck. The deck selection screen (see FIG. 6C) is displayed based on the ID (P22-4).

The first deck storage area 90 stores deck information for rotation during the current distribution period, and the second deck storage area 91 stores deck information for pre-rotation during the current distribution period. The third deck storage area 92 stores deck information for Unlimited. Therefore, in the above P22-2, the deck for rotation is displayed on the deck selection screen, and in the above P22-4, the deck for pre-rotation is displayed on the deck selection screen.

Further, when the icon (deck) is tapped on the deck selection screen (YES on P22-5), the screen management unit 62a displays the deck organization screen (see FIG. 7C) (P22-6). Here, the screen management unit 62a is a card stored in the first deck storage area 90, the second deck storage area 91, and the third deck storage area 92, which are associated with the deck ID corresponding to the tapped icon. Load information (card group information). Then, based on the loaded card information, the cards are displayed at the top of the deck formation screen.

Further, when the deck creation tab 44 is tapped on the deck selection screen (YES on P22-7), the screen management unit 62a displays the knitting method selection screen (see FIG. 7A) (P22-8). Further, when the new creation tab 46a is tapped on the knitting method selection screen (YES on P22-9), the screen management unit 62a loads the possession card corresponding to the currently selected format from the possession card information storage unit 89. Then, the deck organization screen (see FIG. 7B) in which the possessed cards are arranged in the lower row is displayed (P22-10).

Further, when a player operation such as sliding a card is input on the deck formation screen (YES on P22-11), the screen management unit 62a updates the display such as arranging the card on the upper stage of the deck formation screen. , Temporarily register the information of the cards placed in the upper row (P22-12).

When the save tab 48 is tapped (YES on P22-13), the deck information storage unit 64a executes the deck information storage process (P23).

FIG. 29 is a flowchart illustrating an example of deck information storage processing (P23) in the player terminal 1. If the format of the newly stored deck is rotation (YES on P23-1), the deck information storage unit 64a has all the card information (temporarily registered) selected (temporarily registered) on the deck organization screen (card group information). The deck information including the above is stored in the first deck storage area 90 (P23-2).

If the format of the deck to be newly stored is pre-rotation (YES on P23-3), the deck information storage unit 64a stores the deck information including all the card information selected on the deck formation screen as the second deck. It is stored in the storage area 91 (P23-4). If the format of the newly stored deck is Unlimited (NO on P23-3), the deck information storage unit 64a stores the deck information including all the card information selected on the deck formation screen in the third deck. It is stored in the area 92 (P23-5). Then, the deck information storage unit 64a sets the deck information stored in the above storage area (P23-6). The deck information set here is transmitted to the server 100.

Returning to FIG. 28, when the copy tab 46b is tapped on the knitting method selection screen (YES on P22-14), the screen management unit 62a confirms the state information stored in the state information storage unit 81 (P22-15). ), The copy source selection screen (see FIG. 7D) is displayed (P22-16).

Here, when the current distribution state is the pre-state and the copy destination format is rotation, the screen management unit 62a loads and loads the deck ID stored in the first deck storage area 90. The copy source selection screen is displayed based on the deck ID. Further, when the current distribution state is the pre-state and the copy destination format is the pre-rotation, the screen management unit 62a loads and loads the deck ID stored in the second deck storage area 91. The copy source selection screen is displayed based on the deck ID.

Further, the screen management unit 62a has a deck ID stored in the first deck storage area 90 and the second deck storage area 91 when the current distribution state is the transition state and the copy destination format is rotation. Is loaded, and the copy source selection screen is displayed based on the loaded deck ID.

Further, the screen management unit 62a has a deck ID stored in the first deck storage area 90 when the current distribution state is the present release state (excluding the transition state) and the copy destination format is rotation. Is loaded, and the copy source selection screen is displayed based on the loaded deck ID.

Then, when one of the icons is tapped on the copy source selection screen and the copy source determination operation for determining the copy source deck is input (YES on P22-17), the deck information storage unit 64a displays the deck organization screen (YES). (See FIG. 7C) is displayed (P22-18). Here, the screen management unit 62a loads the card information (card group information) associated with the deck ID corresponding to the tapped icon. Then, based on the loaded card information, the cards are displayed at the top of the deck formation screen.

According to the deck information storage process (P23) shown in FIG. 29, the deck information for pre-rotation (for example, 6th to 10th card classification) selected from the possessed cards based on the player's operation during the pre-state is The deck information for rotation (for example, the 5th to 9th card classification) different from the pre-rotation is stored in the second deck storage area 91, and is stored in the first deck storage area 90. Then, in the maintenance between the pre-state and the transition state, the deck information stored in the first deck storage area 90 is deleted. During the transition state after maintenance, deck information corresponding to rotation (for example, 6th to 10th card classification) is stored in the 1st deck storage area 90 based on the operation of the player.

Further, according to the deck formation process (P22) shown in FIG. 28, for pre-rotation (for example, 6th to 10th) stored in the second deck storage area 91 during the pre-state based on the operation of the player during the transition state. The deck information of (card classification) can be copied to the first deck storage area 90.

Returning to FIG. 26, when the deck information set in the deck formation process is transmitted to the server 100 in the player terminal 1, the deck information storage process (S21) is performed in the server 100. Similar to the player terminal 1, the server 100 is provided with a first deck storage area 190, a second deck storage area 191 and a third deck storage area 192, and the deck information stored in the player terminal 1 is stored in the server. Also in 100, it is stored in the storage area in the same manner as the player terminal 1.

Further, when the card list generation tab 40b (see FIG. 6A) is tapped on the player terminal 1, the screen management unit 62a executes the card list generation screen display process (P25).

FIG. 30 is a flowchart illustrating an example of the card list generation screen display process (P25) in the player terminal 1. The screen management unit 62a confirms the state information stored in the state information storage unit 81 (P25-1). If it is in the pre-state (YES in P25-2), the screen management unit 62a generates a card list screen (see FIG. 10A) and a card generation screen (see FIG. 10B) for the pre-state (P25-3). , The generated screen is displayed on the display 26 (P25-5).

Here, the screen management unit 62a loads the possessed card information from the possessed card information storage unit 89, and arranges all the possessed cards on the card list screen. Further, the screen management unit 62a loads all the card information currently provided from the all card information storage unit 93, determines whether or not the card information is possessed, and generates a card generation screen. Here, among the new cards in the current distribution period, the cards that you do not have are displayed in secret, the other old cards that you do not have are displayed in gray out, and the cards you have are displayed in color. Generate and display the generation screen.

On the other hand, when it is not in the pre-state (NO on P25-2), the screen management unit 62a generates a card list screen (see FIG. 11A) and a card generation screen (see FIG. 11B) for this release state (P25-4). , The generated screen is displayed on the display 26 (P25-5). Here, the screen management unit 62a generates and displays a card generation screen so that the cards that are not possessed are displayed in gray out and the cards that are possessed are displayed in color.

Returning to FIG. 26, when the card list screen and the card generation screen are displayed as described above, the card generation / disassembly process (P26) is executed in the player terminal 1.

FIG. 31 is a flowchart illustrating an example of the card generation / disassembly process (P26) in the player terminal 1. When the card displayed on the card list screen or the card generation screen is tapped (YES on P26-1), the screen management unit 62a determines whether the card is currently in the pre-state (P26-2). Then, if the screen management unit 62a is in the pre-state (YES in P26-2), the card detail screen for the pre-state (see FIG. 10C) is generated (P26-3), and the generated card detail screen is displayed on the display 26. Is displayed on (P26-5).

Here, the screen management unit 62a loads the card information from the all card information storage unit 93 and generates a card detail screen for the tapped card. At this time, the screen management unit 62a generates a card detail screen so that the disassembly tab 52a and the generation tab 52b are displayed in gray out when the tapped card is a new card classification in the current distribution period.

In addition, the screen management unit 62a generates a card detail screen so that the disassembly tab 52a is displayed in gray out when the tapped card is not a new card classification in the current distribution period but a card that is not possessed. To do. Further, the screen management unit 62a generates a card detail screen so that the generation tab 52b is displayed in gray out when the coins necessary for generating the tapped card are not possessed.

On the other hand, if the screen management unit 62a is not currently in the pre-state (NO on P26-2), the screen management unit 62a generates a card detail screen for this release state (see FIG. 11C) (P26-4), and the generated card detail screen. Is displayed on the display 26 (P26-5). Here, the screen management unit 62a displays the disassembly tab 52a in gray out when it does not have the tapped card, and when it does not have the coins necessary to generate the tapped card, the generation tab A card detail screen is generated so that 52b is displayed in gray out.

When the disassembly tab 52a is tapped (YES on P26-6), the card disassembly process (P26-7) is executed. In this card disassembly process, the screen management unit 62a displays the disassembly animation, and the information updating unit 63a adds the number of coins corresponding to the disassembled card to the number of possessed coins stored in the possessed coin storage unit 94. Further, the information updating unit 63a reduces the number of decomposed possessed cards among the possessed card information stored in the possessed card information storage unit 89.

When the generation tab 52b is tapped (YES on P26-8), the card generation process (P26-9) is executed. In this card generation process, the screen management unit 62a displays the generation animation, and the information update unit 63a subtracts the number of coins corresponding to the generated card from the number of possessed coins stored in the possessed coin storage unit 94. Further, the information updating unit 63a increases the number of possessed cards generated in the possessed card information storage unit 89.

According to the card generation / disassembly process described above, the taps of the disassembly tab 52a and the generation tab 52b cannot be accepted for the new card during the pre-state, and after this release state (including the transition state), the disassembly tab 52a and the disassembly tab 52a and It is possible to accept taps on the generation tab 52b.

Returning to FIG. 26, when the card is generated or disassembled in the card generation / disassembly process (P26), the generated / disassembled information such as the generated or disassembled card information, the number of updated coins, and the possessed card information is generated in the player terminal 1. Is transmitted to the server 100. When the server 100 receives the generated / decomposed information, the card information storage process (S22) for updating the information of the possessed card information storage unit 189 and the possessed coin storage unit 194 is executed in the same manner as in the player terminal 1.

Further, when the solo play selection unit 30b or the battle selection unit 30c of the menu bar 30 is tapped, a screen for setting game conditions such as a format is displayed. For example, when the game condition is set after the solo play selection unit 30b is tapped, the battle game execution unit 65a uses the possession card stored in the possession card information storage unit 89 to perform a card battle game execution process (P27). )I do.

During the pre-state, the battle game execution unit 65a uses the deck information stored in the first deck storage area 90 (if the distribution period is the tenth period, the fifth to ninth card classifications) based on the player's operation. The game corresponding to rotation is executed, and the game corresponding to pre-rotation is played using the deck information stored in the second deck storage area 91 (6th to 10th card classification if the distribution period is the 10th period). Run. Further, during this release state (including the transition state), the battle game execution unit 65a is based on the player's operation, and the deck information stored in the first deck storage area 90 (if the distribution period is the tenth period). Using the 6th to 10th card classifications), the game corresponding to the rotation of the same game conditions as the pre-rotation is executed.

When the card battle game execution process is completed, the game result information is transmitted from the player terminal 1 to the server 100. The server 100 updates the data storage area 112b based on the game result information received by the server control unit 100A (S23). Although detailed description is omitted, when the battle selection unit 30c is tapped, the battle game execution unit 65a of the player terminal 1 and the battle game execution unit 165a of the server 100 cooperate to play a card battle game. Execute by communication battle.

Here, in the above embodiment, a case where a constant ceiling value is set regardless of the number of times a card is acquired by using points has been described. However, different ceiling values may be set depending on the number of times the card is acquired by using points. A modified example of this game will be described below. In the following description of the modified example, the same components as those in the above embodiment are designated by the same reference numerals, and the details thereof will be omitted.

FIG. 32 is a diagram illustrating an example of a card purchase screen according to a modified example. In the modified example, the ceiling value is set as follows for each card pack. That is, in the target card pack, if the number of times the card is acquired using points is 0, in other words, if the card has never been acquired using points, the ceiling value is set to 400 points. To. That is, the initial setting value of the ceiling value is 400 points.

Then, when the player acquires a card by using 400 points for the card pack, 200 points are set as the ceiling value. In this modified example, the same ceiling value (200 points) is set regardless of the number of times the card is acquired from the second time onward. In this way, the ceiling value of each card pack is initially set to 400 points as the initial setting value, and from the second time onward, 200 points that are easier to reach than the initial setting value are set.

As described above, in this modification, the point value required for card acquisition differs depending on the number of times the card is acquired based on the tap (second operation) of the acquisition tab. More specifically, if the number of times the card was acquired based on the tap of the acquisition tab is the first number (0 times), the number of times the card is acquired based on the tap of the acquisition tab is larger than the first number of times. Compared to the second number of times (one or more times), more points are required to acquire the card.

As described in the above embodiment, the card pack can be purchased using in-game currency such as a ticket. Therefore, if the ceiling value is set low, each player can easily obtain the necessary cards without charging, for example, and the superiority of the player who has charged a lot cannot be secured. Will end up. As in this modification, by setting the ceiling value high at the beginning and setting the ceiling value low after the second time, many players can obtain the desired card, but some players can obtain the desired card. It is possible to secure superiority.

The configuration and processing of the server 100 for executing the game according to the above modification will be described below. Here, only the points different from the above-described embodiment will be described.

FIG. 33 is a functional block diagram of the player terminal 1 according to the modified example. The data storage area 12b in the memory 12 of the player terminal 1 is further provided with an acquisition number storage unit 95 in addition to the storage units and storage areas described in the above embodiment. The acquisition number storage unit 95 stores the number of times a card has been acquired using points for each card pack (card pack ID).

FIG. 34 is a functional block diagram of the server 100 according to the modified example. The data storage area 112b in the memory 112 of the server 100 is further provided with an acquisition number storage unit 195 in addition to the storage units and storage areas described in the above embodiment. In the acquisition number storage unit 195, the number of times a card is acquired by using points is stored for each card pack (card pack ID).

Then, in this modification, in the purchase information derivation process (FIG. 20), the process is performed as follows. That is, in S11-9, the server control unit 100A has in-game currency information (number of tickets, rupi, and diamonds) stored in the in-game currency information storage unit 184 regardless of whether or not it is in the pre-state. To get and set. Further, in S11-9, the server control unit 100A acquires and sets the number of times (hereinafter, referred to as the number of acquisitions) stored in the acquisition number storage unit 195. The other processes in the purchase information derivation process are the same as those in the above embodiment.

Further, in this modification, in the above purchase screen display process (FIG. 21), the process is performed as follows. That is, in P12-1, the information update unit 63a stores the maximum number of purchases in the maximum number of purchases storage unit 82, stores the maximum number of purchases in the purchase number storage unit 83, and stores the ticket and rupi in the in-game currency information storage unit 84. And the number of diamonds are stored, the points for each card classification are stored in the point storage unit 85, the ceiling value for each card classification is stored in the ceiling value storage unit 86, and the purchase availability information storage unit 87 receives the purchase as purchase information. Possible information or non-purchasable information is stored, the acquisitionable / non-acquirable information received as purchase information is stored in the acquisition availability information storage unit 88, and the acquisition number of times is stored in the acquisition number storage unit 95.

Further, in P12-6 to P12-8, the screen management unit 62a reaches the number of acquisitions, the possession points, the current ceiling value, and the value obtained by subtracting the possession points from the ceiling value, that is, the ceiling value, as shown in FIG. The remaining point value required for this is displayed in the point information column 36d. If the possessed points have reached the ceiling value, the remaining point value required to reach the ceiling value is not displayed.

Further, in this modification, the acquisition execution process on the server 100 described above is executed as shown in FIG. 35.

FIG. 35 is a flowchart illustrating an example of the acquisition execution process (P13) according to the modified example. In the acquisition execution process shown in FIG. 35, the processes S13-1 to S13-7 are the same as the acquisition execution process shown in FIG. 24 described in the above embodiment. In this modification, the processes S13-8 to S13-13 are executed following the process S13-7.

That is, the point exchange unit 164 updates the number of acquisitions stored in the acquisition number storage unit 195 (S13-8). Here, the point exchange unit 164 adds 1 to the number of acquisitions of the acquisition number storage unit 195. Then, the point exchange unit 164a sets the updated acquisition number information (S13-9). Further, in S13-8, if the number of acquisitions after the update is 1 or more (YES in S13-10), the server control unit 100A stores 200 as the ceiling value in the ceiling value storage unit 186, and the acquisition after the update. If the number of times is not 1 or more (NO in S13-10), that is, if no data is set in the acquisition number storage unit 195, the server control unit 100A stores 400 as the ceiling value in the ceiling value storage unit 186. Finally, the server control unit 100A sets the updated ceiling value information stored in the ceiling value storage unit 186 in S13-11 or S13-12 (S13-13).

In this modification, in P16-4 of the above acquisition result reflection process (FIG. 25), the information update unit 63a updates the points stored in the point storage unit 85 based on the point information received as the acquisition result information. In addition to this, the number of acquisitions stored in the acquisition number storage unit 95 is updated based on the acquisition number information, and the ceiling value stored in the ceiling value storage unit 86 is updated based on the ceiling value information. Further, based on the various information updated in this way, the display shown in FIG. 32 is performed in the above purchase screen display process.

By the above processing, according to this modification, the ceiling value becomes variable according to the number of times the card is acquired by using the points. However, the above process is an example, and the process for making the ceiling value variable can be appropriately designed.

Further, in the above modification, when the number of times the card is acquired by using the points is two or more, the set ceiling value is set low. However, on the contrary, when the number of times the card is acquired by using the points is two or more, the set ceiling value may be increased.

Further, in the above modified example, if the number of times the card is acquired by using the points is two or more, the same ceiling value is set. However, the ceiling value may be set to be lowered stepwise even when the card is acquired for the second time or later. According to the above modification, since the processes S13-10 to S13-12 of FIG. 35 are provided, the ceiling value can be easily changed.

Further, in the above modification, the ceiling value is set in advance with respect to the number of times the card is acquired by using the points. However, for example, each time a card is acquired using points, the ceiling price may be determined by lottery. At this time, the selection ratio of the ceiling value to be determined may be different depending on the number of times the card is acquired by using the points, or the ceiling value is determined under the same selection ratio regardless of the number of times the card is acquired. May be good.

Further, in the above modification, the ceiling value is set in the same manner for all the card packs, but the ceiling value setting conditions may be different for each card pack.

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 to those skilled in the art that various modifications or modifications can be conceived within the scope of the claims, and it is understood that they also naturally belong to the technical scope.

In the above-described embodiment and modified example, when purchasing cards, a plurality of cards are collectively purchased as a card pack. That is, eight lottery processes are executed based on one operation of the purchase tab (one lottery request operation). However, one lottery process may be executed by one lottery request operation.

Further, in the above-described embodiment and modification, each card belongs to one of the card classifications. However, no card classification is provided, and one of the provided cards may be determined by a lottery process.

Further, in the above-described embodiment and modification, all the cards belong to one of the card classifications, but cards that do not belong to any of the card classifications may be provided. In this case, for example, a card that does not belong to any of the card classifications may be used in rotation for the entire period, or may be used in rotation only for a preset period.

Further, in the above-described embodiment and modified example, the case where both the computer battle and the communication battle with other players can be executed has been described, but only one of these may be executed. Moreover, the content of the game in the above embodiment is only an example. In the above embodiment, it is assumed that a card battle game in which a card is used as a game medium can be played. For example, an action game or role-playing in which a character is provided as a game medium and a battle game is executed using a possessed character. It may be a game.

In any case, based on the lottery request operation input by the player, a lottery process for determining one of a plurality of types of game media provided in advance by lottery is executed, and the determined game medium is the possessed game medium. As long as the predetermined game is executed using the possessed game medium stored in the storage unit in association with the player ID and stored in the storage unit, the content of the game is not particularly limited.

Further, in the above-described embodiment and modification, in the player terminal 1 and the server 100, the display content is changed based on the current distribution period and the distribution state, and the display content restricts a predetermined operation for each distribution state. The case of doing so was explained. However, for example, a different program may be read at the time of updating the distribution period or the distribution state, and the processing may be different depending on the distribution period or the like without determining the current distribution period or the like.

Specifically, in the pre-state, a program including a process for restricting the execution of the lottery process exceeding the limit number of times is loaded, and in the present release state, a program for which the process for restricting the execution of the lottery process is not executed is loaded. You may let me. More specifically, in the pre-state, the execution of the lottery process exceeding the limit number of times is restricted for a specific card classification, and the lottery process exceeding the limit number of times can be executed for the card classifications other than the specific card classification. Load the program. On the other hand, in this release state, for all card classifications, a program that enables execution of lottery processing exceeding the limit number of times is loaded. As described above, in the pre-state, the game may be executed by starting a program whose execution of the lottery process is restricted, and in the present release state, the game may be executed by starting a program whose execution of the lottery process is not restricted. ..

Further, for example, during the pre-state, a program that makes it impossible to accept the operation for generating a predetermined card (first operation) is read, and during this release state, an operation for generating a predetermined card (first operation) is performed. You may load a program that allows you to accept.

Further, in the above-described embodiment and modification, the points do not reach the ceiling value in the pre-state. For example, the points reach the ceiling value in the pre-state, but in the pre-state, the points are used to play the card. The operation to be acquired (second operation) may not be accepted. In this case, for example, during the pre-state, a program that does not accept the operation (second operation) may be loaded, and in the present release state, a program that can accept the operation (second operation) may be loaded.

Further, for example, in the pre-state, the first deck information (first deck information) for identifying a plurality of cards corresponding to the first game condition selected from the possessed cards (possessed game medium) based on the operation of the player. (1 medium group information) is stored in the first storage area, and second deck information (second medium group information) for identifying a plurality of cards corresponding to a second game condition different from the first game condition is stored. The program to be stored in the second storage area is read, and in the present release state, the program to store the second deck information (second medium group information) in the first storage area is read based on the operation of the player.

Then, in the pre-state, the game using the first deck information (first medium group information) stored in the first storage area and the game stored in the second storage area are stored based on the operation of the player. The program that enables the game to be executed using the second deck information (second medium group information) is loaded, and in this release state, the second deck information stored in the first storage area is stored based on the operation of the player. The game using (second medium group information) can be executed, the game using the first deck information (first medium group information) cannot be executed, and further, based on the player's operation, the first during the pre-state. A program for storing (migrating, copying) the second deck information (second medium group information) stored in the second storage area in the first storage area may be loaded.

Further, the update process at the time of maintenance may be programmed in advance so that it is automatically performed at a predetermined date and time, or the update process may be performed manually.

Further, in the above-described embodiment and modification, the ceiling value is set for the number of purchased card packs, but the ceiling value may be set for the number of purchased cards. Further, whether or not the ceiling value has been reached may be managed not by the number of card pack purchases but by the number of times the lottery process is executed.

Further, in the above-described embodiment and modification, the lottery process can be executed indefinitely in the present release state, but the limited number of times can be executed within the range in which the lottery process can be executed more times than in the pre-state. It may be set. That is, in the present release state, a limit number of times larger than that in the pre-state may be set.

Further, in the above-described embodiment and modified example, the types of cards that can be acquired by using points are the same regardless of the number of times the cards are acquired by using points. However, for example, the types of cards that can be newly acquired may increase or decrease depending on the number of times the cards are acquired by using points.

Further, in the above-described embodiment and modification, the number of cards that can be acquired by using points is the same regardless of the number of cards that can be acquired by using points. However, for example, the number of newly acquired cards may increase or decrease depending on the number of times the cards are acquired by using points. As an example, if it is the first time to acquire a card by using points, 3 cards can be acquired, and from the second time onward, less than 3 cards or 4 or more cards can be acquired. You may do it.

Further, for example, a card that can be acquired only when the number of times the card is acquired by using points is a predetermined number may be included.

Further, for example, when the number of times a card is acquired by using points is two or more, a predetermined item other than the card, the above-mentioned ticket, or the like may be acquired in addition to the card or in place of the card.

In the above-described embodiment and modified example, the information processing system S, which is a client-server system, performs each of the above-mentioned information processing. However, the function of the server 100 in the above embodiment may be provided in the player terminal 1. In this case, the communication function is not essential, and the player terminal 1 functions as a game terminal device.

Further, the programs in the above-described embodiments and modifications may be stored in a storage medium readable by a computer and provided as a storage medium. Further, it may be provided as a game terminal device or an information processing system including this storage medium. Further, the above-described embodiment may be an information processing method that realizes each function and the steps shown in the flowchart.

The lottery unit 162a in the above embodiment and the modified example corresponds to the lottery unit of the present invention, and the possessed card information storage unit 89 and the possessed card information storage unit 189 correspond to the storage unit, and the process of S12-14 is executed. The terminal control unit 1A that executes the processes of the server control units 100A and P14-3 corresponds to the game medium storage unit, the battle game execution units 65a and 165a correspond to the game execution unit, and the pre-state corresponds to the previous period. The server control unit 100A and the screen management unit 62a that execute the processes of S11-1 to S11-8 correspond to the management unit, the card classification corresponds to the medium classification, and the generation tab 52b corresponds to the first operation reception unit. The information update unit 63a and the point exchange unit 164a correspond to the point update unit, and the point information column 36d corresponds to the second operation reception unit.

The present invention can be used in information processing systems, information processing methods and information processing programs.

1A Terminal control unit 36d Point information field 52b Generation tab 62a Screen management unit 63a Information update unit 65a, 165a Competitive game execution unit 89, 189 Possession card information storage unit 100A Server control unit 162a Lottery unit 164a Point exchange unit

Claims (10)

An information processing system including a player terminal and a server capable of communicating with the player terminal.
Either or both of the player terminal and the server
A lottery unit that executes a lottery process to determine one of a plurality of types of game media provided in advance by lottery based on a lottery request operation input by the player.
A game medium storage unit that stores the game medium determined by the lottery unit as a possession game medium in the storage unit in association with the player ID.
A game execution unit that executes a predetermined game using the possessed game medium stored in the storage unit, and
During the period prior to the predetermined time, the execution of the lottery process exceeding the preset limit number of times is restricted, and after the predetermined time, the management unit capable of executing the lottery process exceeding the limit number of times. ,
A point update unit that updates a predetermined point value based on the execution of the lottery process,
A ceiling acquisition unit that can be acquired by selecting one of the game media when the point value reaches a preset ceiling value.
With
The ceiling value is a value that the point value does not reach when the number of times the lottery process is executed is within the limit number of times, and the information processing is a value that the point value can reach after the predetermined time. system. The information processing system according to claim 1, wherein the ceiling value set next may differ depending on the number of times the point value reaches the ceiling value and acquires the game medium. When the number of times the point value reaches the ceiling value and acquires the game medium is the first number of times, the number of times the point value reaches the ceiling value and acquires the game medium is more than the first number of times. The information processing system according to claim 2, wherein more point values are required to acquire the game medium as compared with the case where the second number of times is large. An information processing system including a player terminal and a server capable of communicating with the player terminal.
Either or both of the player terminal and the server
A lottery unit that executes a lottery process to determine one of a plurality of types of game media provided in advance by lottery based on a lottery request operation input by the player.
A game medium storage unit that stores the game medium determined by the lottery unit as a possession game medium in the storage unit in association with the player ID.
A game execution unit that executes a predetermined game using the possessed game medium stored in the storage unit, and
The time determination process for determining which period is in the prior period before the predetermined period or in the current period after the predetermined period is executed, and when it is determined that the period is at least during the prior period, the said A management unit that executes a number-of-times determination process that compares the number of times the lottery process has been executed with a preset limit number of times.
With
The management department
The lottery process can be executed when the number of times the lottery process has been executed is less than the limit number of times during the previous period and during the present period.
An information processing system that limits the execution of the lottery process when the number of times the lottery process has been executed is equal to or greater than the limit number of times during the previous period. A plurality of media classifications to which the plurality of types of the game media belong are provided.
The plurality of media classifications differ from each other in at least a portion of the game media to which they belong.
The lottery request operation is configured so that the medium classification can be selected.
The lottery section
In the lottery process, one of a plurality of types of the game media belonging to the medium classification of any one selected in the lottery request operation is determined by lottery.
The management department
During the previous period, the execution of the lottery process exceeding the limit number of times is restricted for a specific medium classification, and the lottery process exceeding the limit number of times can be executed for media classifications other than the specific medium classification. The information processing system according to any one of claims 1 to 4. One or both of the player terminal and the server
A first operation receiving unit that accepts a first operation for selecting and acquiring one of the game media upon the establishment of a predetermined condition is provided.
The game medium storage unit
The game medium selected by the first operation is stored in the storage unit as the possessed game medium.
The management department
The information processing system according to any one of claims 1 to 5, wherein the first operation cannot be accepted during the previous period, and the first operation can be accepted after the predetermined time. An information processing method executed by either or both of a player terminal and a server capable of communicating with the player terminal.
A step of executing a lottery process of determining one of a plurality of types of game media provided in advance by lottery based on a lottery request operation input by the player, and
A step of storing the determined game medium as a possession game medium in the storage unit in association with the player ID.
A step of executing a predetermined game using the possessed game medium stored in the storage unit, and
A step of limiting the execution of the lottery process exceeding a preset limit number of times during a period prior to a predetermined time, and
A step that enables the lottery process that exceeds the limit number of times to be executed after the predetermined time, and
A step of updating a predetermined point value based on the execution of the lottery process, and
When the point value reaches a preset ceiling value, one of the game media can be selected and acquired.
Including
The ceiling value is a value that the point value does not reach when the number of times the lottery process is executed is within the limit number of times, and the information processing is a value that the point value can reach after the predetermined time. Method. An information processing method executed by either or both of a player terminal and a server capable of communicating with the player terminal.
Based on the lottery request operation input by the player, a step of executing a lottery process of determining one of a plurality of types of game media provided in advance by lottery, and
A step of storing the game medium determined by the lottery process in the storage unit in association with the player ID as the possessed game medium.
A step of executing a predetermined game using the possessed game medium stored in the storage unit, and
The time determination process for determining which period is in the prior period before the predetermined period or in the current period after the predetermined period is executed, and when it is determined that the period is at least during the prior period, the above-mentioned A step of executing a number determination process for comparing the number of times the lottery process has been executed with a preset limit number of times, and
Including
The lottery process can be executed when the number of times the lottery process has been executed is less than the limit number of times during the previous period and during the present period.
An information processing method in which the execution of the lottery process is restricted when the number of times the lottery process has been executed is equal to or greater than the limit number of times during the previous period. A lottery unit that executes a lottery process to determine one of a plurality of types of game media provided in advance by lottery based on a lottery request operation input by the player.
A game medium storage unit that stores the game medium determined by the lottery unit as a possession game medium in the storage unit in association with the player ID.
A game execution unit that executes a predetermined game using the possessed game medium stored in the storage unit, and
During the period prior to the predetermined time, the execution of the lottery process exceeding the preset limit number of times is restricted, and after the predetermined time, the management unit capable of executing the lottery process exceeding the limit number of times. ,
A point update unit that updates a predetermined point value based on the execution of the lottery process,
A ceiling acquisition unit that can be acquired by selecting one of the game media when the point value reaches a preset ceiling value.
To make the computer work
The ceiling value is a value that the point value does not reach when the number of times the lottery process is executed is within the limit number of times, and the information processing is a value that the point value can reach after the predetermined time. program. A lottery unit that executes a lottery process to determine one of a plurality of types of game media provided in advance by lottery based on a lottery request operation input by the player.
A game medium storage unit that stores the game medium determined by the lottery unit as a possession game medium in the storage unit in association with the player ID.
A game execution unit that executes a predetermined game using the possessed game medium stored in the storage unit, and
The time determination process for determining which period is in the prior period before the predetermined period or in the current period after the predetermined period is executed, and when it is determined that the period is at least during the prior period, the said A management unit that executes a number-of-times determination process that compares the number of times the lottery process has been executed with a preset limit number of times.
To make the computer work
The management department
The lottery process can be executed when the number of times the lottery process has been executed is less than the limit number of times during the previous period and during the present period.
An information processing program that limits the execution of the lottery process when the number of times the lottery process has been executed is equal to or greater than the limit number of times during the previous period.

Images