Information Processing System, Information Processing Method, and Information Processing Program

Abstract

In the pre-release state of the ninth period, the information processing system stores the deck information composed of cards belonging to the fourth card category to the eighth card category corresponding to the first game condition in the first storage area, and stores the deck information composed of cards belonging to the fifth card category to the ninth card category corresponding to the second game condition different from the first game condition in the second storage area. In the main release state of the ninth period, the information processing system stores the deck information composed of cards belonging to the fifth card category to the ninth card category corresponding to the second game condition in the first storage area. In the main release state, the information processing system can transfer the deck information stored in the second storage area in the pre-release state to the first storage area based on the player's operation.

Description

Technical Field

[0001] The present invention relates to an information processing system, an information processing method, and an information processing program. Background Art

[0002] As shown in, for example, Patent Document 1, a digital card game that enables players to battle against each other through communication has been conventionally proposed. In such a digital card game, a player can obtain cards used in a battle game by performing a lottery (so-called gacha) for free or for a fee.

[0003] Prior Art Documents

[0004] Patent Documents

[0005] Patent Document 1: Japanese Unexamined Patent Application Publication No. 2018-995 Summary of the Invention

[0006] Problems to be Solved by the Invention

[0007] In a digital card game, as cards provided are sequentially added, the cards available in a battle game periodically change. For this reason, every time the available cards change, a player needs to organize the cards used in the battle game, which causes a problem of requiring a player to perform complex operations.

[0008] An object of the present invention is to provide an information processing system, an information processing method, and an information processing program that can enhance the simplicity of operations performed by a player.

[0009] Means for Solving the Problems

[0010] To solve the above problems, an information processing system includes: a game medium storage unit that stores, in a storage unit, the game media owned by a player among multiple types of game media as owned game media in a manner associated with the player ID; a media group information storage unit that stores, in a first storage area during a preparatory period before a specified time, first media group information for identifying a plurality of the game media corresponding to a first game condition selected from the owned game media based on a player's operation, and stores second media group information for identifying a plurality of the game media corresponding to a second game condition different from the first game condition in a second storage area, and stores the second media group information in the first storage area based on the player's operation during a subsequent period after the specified time; a game execution unit that can execute, during the preparatory period, a game using the first media group information stored in the first storage area and a game using the second media group information stored in the second storage area based on the player's operation, and can execute, during the subsequent period, a game using the second media group information stored in the first storage area based on the player's operation, and cannot execute a game using the first media group information; and a transition unit that stores, during the subsequent period, the second media group information stored in the second storage area during the preparatory period in the first storage area based on the player's operation.

[0011] In addition, the information processing system may further include: a function information storage unit that stores a plurality of function information, the plurality of function information including first function information and second function information, wherein, in the first function information, functions implemented by game media corresponding to at least the first game condition are associated with the corresponding game media, and in the second function information, functions implemented by game media corresponding to at least the second game condition are associated with the corresponding game media, wherein the game execution unit progresses the game based on the function information, and the game media may include a specific game media that corresponds to both the first game condition and the second game condition and is associated with functions different between the first function information and the second function information.

[0012] To solve the above problems, an information processing method includes the following steps: storing game media owned by a player among multiple types of game media as owned game media in a storage unit in a manner associated with the player ID; during a preparatory period before a specified time, storing first media group information for identifying a plurality of the game media corresponding to a first game condition selected from the owned game media based on a player's operation in a first storage area, and during the preparatory period, storing second media group information for identifying a plurality of the game media corresponding to a second game condition different from the first game condition in a second storage area, and during a subsequent period after the specified time, storing the second media group information in the first storage area based on the player's operation; during the preparatory period, being able to execute a game using the first media group information stored in the first storage area and a game using the second media group information stored in the second storage area based on the player's operation, and during the subsequent period, being able to execute a game using the second media group information stored in the first storage area based on the player's operation, and during the subsequent period, not being able to execute a game using the first media group information; and during the subsequent period, based on the player's operation, storing the second media group information stored in the second storage area during the preparatory period in the first storage area.

[0013] In order to solve the above problems, an information processing program causes a computer to function as: a game medium storage unit that stores, in a storage unit, game mediums owned by a player among a plurality of types of game mediums as owned game mediums in a manner associated with a player ID; a medium group information storage unit that stores, in a first storage area during a preparatory period before a specified time, first medium group information for identifying a plurality of the game mediums corresponding to a first game condition selected from the owned game mediums based on a player's operation, and stores second medium group information for identifying a plurality of the game mediums corresponding to a second game condition different from the first game condition in a second storage area, and during a subsequent period after the specified time, stores the second medium group information in the first storage area based on a player's operation; a game execution unit that, during the preparatory period, can execute a game using the first medium group information stored in the first storage area and a game using the second medium group information stored in the second storage area based on a player's operation, and during the subsequent period, can execute a game using the second medium group information stored in the first storage area based on a player's operation and cannot execute a game using the first medium group information; and a transition unit that, during the subsequent period, stores, based on a player's operation, the second medium group information stored in the second storage area during the preparatory period in the first storage area.

[0014] Effects of the Invention

[0015] According to the present invention, the simplicity of operations performed by a user can be enhanced. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is an explanatory diagram showing a schematic configuration of an information processing system.

[0017] Figure 2A is a diagram for explaining the hardware configuration of a player terminal. Figure 2B is a diagram for explaining the hardware configuration of a server.

[0018] Figure 3A is a diagram for explaining a distribution period of a game. Figure 3B is a diagram for explaining a card classification provided in each distribution period. Figure 3C is a diagram for explaining the relationship between a distribution period and a format.

[0019] Figure 4A is a diagram showing an example of a purchase type selection screen. Figure 4B is a diagram for explaining an example of a card purchase screen in a pre-release state. Figure 4CIt is a figure for explaining the limited number of times. Figure 4D It is a figure for explaining the upper limit function.

[0020] Figure 5A It is a figure for explaining an example of the card purchase screen in the main release state. Figure 5B It is a figure for explaining an example of the lottery result screen.

[0021] Figure 6A It is a figure for explaining an example of the card setting screen. Figure 6B It is a figure for explaining an example of the format selection screen in the pre-release state. Figure 6C It is a figure for explaining an example of the card deck selection screen.

[0022] Figure 7A It is a figure for explaining an example of the organization method selection screen. Figure 7B It is a figure for explaining an example of the card deck organization screen in the initial state. Figure 7C It is a figure for explaining an example of the card deck organization screen during the organization period. Figure 7D It is a figure for explaining an example of the copy source selection screen in the pre-release state.

[0023] Figure 8A It is a figure for explaining an example of the format selection screen in the transition state. Figure 8B It is a figure for explaining an example of the card deck selection screen. Figure 8C It is a figure for explaining an example of the organization method selection screen. Figure 8D It is a figure for explaining an example of the copy source selection screen in the transition state.

[0024] Figure 9A It is a figure for explaining an example of the format selection screen in the main release state. Figure 9B It is a figure for showing an example of the copy source selection screen in the main release state.

[0025] Figure 10A It is a figure for explaining an example of the card list screen. Figure 10B It is a figure for explaining an example of the card creation screen in the pre-release state. Figure 10C It is a figure for explaining an example of the card details screen in the pre-release state.

[0026] Figure 11A It is a figure for explaining an example of the card list screen. Figure 11B It is a figure for explaining an example of the card creation screen in the main release state. Figure 11C It is a figure for explaining an example of the card details screen in the main release state.

[0027] Figure 12AIt is a figure showing an example of the battle format selection screen in the main release state. Figure 12B It is a figure showing an example of the battle format selection screen in the pre-release state. Figure 12C It is a figure showing an example of the deck selection screen.

[0028] Figure 13 It is a figure showing an example of a card battle game.

[0029] Figure 14A It is a figure showing an example of the function information used in the ninth issue. Figure 14B It is a figure showing an example of the function information used in the pre-release state of the tenth issue. Figure 14C It is a figure showing an example of the function information used in the tenth issue.

[0030] Figure 15 It is a functional block diagram of the player terminal.

[0031] Figure 16 It is a functional block diagram of the server.

[0032] Figure 17 It is the first sequence diagram showing the processing in the player terminal and the server.

[0033] Figure 18 It is a flowchart showing an example of the login processing in the server.

[0034] Figure 19 It is the second sequence diagram showing the processing in the player terminal and the server.

[0035] Figure 20 It is a flowchart showing an example of the purchase information export processing in the server.

[0036] Figure 21 It is a flowchart showing an example of the purchase screen display processing in the player terminal.

[0037] Figure 22 It is a flowchart showing an example of the lottery execution processing in the server.

[0038] Figure 23 It is a flowchart showing an example of the lottery result reflection processing in the player terminal.

[0039] Figure 24 It is a flowchart showing an example of the acquisition execution processing in the server.

[0040] Figure 25 It is a flowchart showing an example of the acquisition result reflection processing in the player terminal.

[0041] Figure 26It is the third sequence diagram for explaining the processing in the player terminal and the server.

[0042] Figure 27 It is a flowchart showing an example of the format selection screen display processing in the player terminal.

[0043] Figure 28 It is a flowchart showing an example of the card deck organization processing in the player terminal.

[0044] Figure 29 It is a flowchart showing an example of the card deck information storage processing in the player terminal.

[0045] Figure 30 It is a flowchart showing an example of the card list / creation screen display processing in the player terminal.

[0046] Figure 31 It is a flowchart showing an example of the card creation / destruction processing in the player terminal. Detailed implementation mode

[0047] Aspects of embodiments of the present invention will be described in detail below with reference to the accompanying drawings. The numerical values etc. given in this embodiment are merely examples for easy understanding and do not limit the present invention unless otherwise specifically mentioned. In this specification and the drawings, elements having substantially the same functions and structures are attached with the same reference numerals and are not repeatedly described, and elements not directly related to the present invention are not shown.

[0048] (Overall structure of information processing system S)

[0049] Figure 1 It is an explanatory diagram showing the schematic structure of the information processing system S. The information processing system S is a so-called client-server system including the player terminal 1, the server 100, and the communication network 200 having the communication base station 200a.

[0050] Each player terminal 1 can establish communication with the server 100 via the communication network 200. The player terminal 1 widely includes electronic appliances that can be communicatively connected to the server 100 by wire or wirelessly. Examples of the player terminal 1 include smart phones, mobile phones, tablet devices, personal computers, game devices, etc. This embodiment will be described in the case of using a smart phone as the player terminal 1.

[0051] The server 100 is communicatively connected to a plurality of player terminals 1. The server 100 accumulates various information (player information) for each player playing the game. In addition, the server 100 updates the accumulated information based on the operations input from the player terminal 1 and controls the progress of the game.

[0052] The communication base station 200a is connected to the communication network 200 and transmits and receives information wirelessly with respect to the player terminal 1. The communication network 200 is composed of a mobile phone network, the Internet, a local area network (LAN), a dedicated line, etc., and realizes a wired or wireless communication connection between the player terminal 1 and the server 100.

[0053] In the information processing system S of the present embodiment, the player terminal 1 and the server 100 serve as game devices G. The player terminal 1 and the server 100 are respectively assigned the responsibilities for controlling the progress of the game, so that the game can progress through the cooperation between the player terminal 1 and the server 100.

[0054] (Hardware structures of the player terminal 1 and the server 100)

[0055] Figure 2A FIG. is for explaining the hardware structure of the player terminal 1. In addition, Figure 2B FIG. is for explaining the hardware structure of the server 100. As Figure 2A shown, the player terminal 1 is configured to include a central processing unit (CPU) 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.

[0056] In addition, as Figure 2B shown, the server 100 is configured to include 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.

[0057] The structures 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 basically the same as those of the CPU 10, the memory 12, 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 of the player terminal 1. Therefore, the following will give an explanation of the hardware structure of the player terminal 1, and the explanation of the server 100 will be omitted.

[0058] The CPU 10 runs the programs stored in the memory 12 to control the progress of the game. The memory 12 is composed of a read-only memory (ROM) or a random access memory (RAM), and stores the programs and various data required to control the progress of the game. The memory 12 is connected to the CPU 10 via the bus 14.

[0059] The input / output interface 16 is connected to the bus 14. The storage unit 18, the communication unit 20, the input unit 22, and the output unit 24 are connected to the input / output interface 16.

[0060] The storage unit 18 is composed of a semiconductor memory such as a dynamic random access memory (DRAM), and stores various programs and data. At the player terminal 1, the CPU 10 loads the programs and data stored in the storage unit 18 into the memory 12 (RAM).

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

[0062] The input unit 22 is constituted by, for example, a touch screen, buttons, a keyboard, a mouse, arrow keys, or an analog controller used for inputting the operations of the player (accepting operations). Optionally, the input unit 22 may be a dedicated controller provided in or connected (externally connected) to the player terminal 1. Optionally, the input unit 22 may be constituted by an acceleration sensor that detects the tilt or movement of the player terminal 1 or a microphone that detects the voice of the player. That is, the input unit 22 widely includes devices that enable the player to input his or her intention in a recognizable manner.

[0063] The output unit 24 is configured to include a display device and a speaker. The output unit 24 may be a device connected (externally connected) to the player terminal 1. In the present embodiment, the player terminal 1 is equipped with a display 26 as the output unit 24, and is equipped with a touch screen as the input unit 22, where the touch screen covers the display 26.

[0064] (Game details)

[0065] Next, the details of the game provided by the information processing system S (game device G) in the present embodiment will be described by using examples. The game in the present embodiment is a so-called digital card game. The player obtains and owns cards of multiple types provided by the game administrator through a lottery or the like. The player can play the following card battle game: The player battles against a computer or another player by using the cards he or she owns. The details of the game in the present embodiment will be described in detail below.

[0066] Figure 3A It is a diagram for explaining the distribution period of the game. Figure 3B It is a diagram for explaining the card classification provided in each distribution period. Figure 3CThis is a diagram for explaining the relationship between the distribution time period and the format. In this embodiment, cards that vary according to the distribution time period are provided to players. Additionally, the game conditions (i.e., available cards) in the card battle game differ for each distribution time period. Here, as an example, one distribution time period consists of four months, and the distribution time period is updated every four months. As Figure 3A shown, the distribution time periods are described by the names of the (n - 1)th period, the nth period, and the (n + 1)th period. Note that n in the nth period describing the distribution time period is an arbitrary integer and increments by 1 every four months.

[0067] As Figure 3A shown, each distribution time period has two distribution states: the pre - release state (hereinafter may be referred to as the pre - state) and the main - release state. Here, as an example, the pre - release state lasts for one month, and the main - release state lasts for three months. In each distribution time period, first, the pre - release state is set, maintenance work is performed in the switching time period one month after the pre - release state, and then the main - release state is set. In other words, in each distribution time period, the pre - release state is set before the switching time period, and the main - release state is set after the switching time period.

[0068] Although described in detail below, each distribution time period has a transition state that lasts for a predetermined time period starting from the main - release state (switching time period). This transition state is provided to enable players to transfer data in the pre - release state. The game conditions of the playable card battle game are the same for the main - release state and the transition state. Here, as an example, the transition state is set to last for one week. Note that the transition state is set simultaneously with the main - release state.

[0069] As described above, in this embodiment, a card battle game using cards is provided. The cards used in the card battle game are provided by the game administrator, and each time the distribution time period is updated, the provision of new cards starts. Here, there are multiple card classifications to which the cards belong. In other words, each card belongs to at least one card classification, and at least a part of the cards belonging to multiple card classifications differ between the card classifications. As an example, in this embodiment, 120 types of cards belong to one card classification.

[0070] For example, as Figure 3B shown, in the eighth period, the eighth card classification is newly provided, in the ninth period, the ninth card classification is newly provided, and in the tenth period, the tenth card classification is newly provided. In short, in the nth period, multiple types of cards belonging to the nth card classification are newly provided. Additionally, in each distribution time period, the cards provided in the distribution time period before that distribution time period are also provided. Therefore, in the nth period, the cards belonging to the first card classification to the nth card classification are provided.

[0071] Hereinafter, the n-th card classification newly provided in the n-th period is referred to as the new card classification, and the card classification provided before the n-th period is referred to as the old card classification. In addition, the cards belonging to the new card classification are only referred to as new cards, and the cards belonging to the old card classification are referred to as old cards.

[0072] Note that the provision of cards in this embodiment means that the player is in a state where he / she can acquire cards. The state in which the player can use the cards in the card battle game is referred to as the possession of the cards. The player is allowed to acquire the provided cards by lottery or the like to possess the cards, and is allowed to use the possessed cards in the card battle game.

[0073] In addition, the card battle game in this embodiment is classified into three types of formats: rotation, unlimited, and prerotation. The format specifies the card classifications (i.e., cards) available in the card battle game, and it can be said that the format constitutes the game conditions in the card battle game. The player first selects the format before starting the card battle game and plays the card battle game by using only the cards corresponding to the selected format.

[0074] The rotation format is a format that enables the use of only the cards belonging to the latest five types of card classifications among the provided card classifications. On the other hand, the unlimited format is a format in which the player can not only use the latest five types of card classifications as in the rotation format in the same period, but also use all the possessed cards among the cards belonging to all the card classifications provided before. Therefore, the rotation format and the unlimited format differ in terms of the cards that can be used by the player in the card battle game. The player can select the two formats of rotation and unlimited at any time during each distribution period.

[0075] Here, as described above, each time the distribution period is updated, a new card classification is provided. For this reason, the latest five types of card classifications that can be used in the rotation format are different for each distribution period. Since Figure 3B as shown, the eighth card classification is newly provided in the eighth period, the latest five types of card classifications are composed of the fourth card classification to the eighth card classification. On the other hand, since the ninth card classification is newly provided in the ninth period, the latest five types of card classifications are composed of the fifth card classification to the ninth card classification. In the tenth period, the latest five types of card classifications are composed of the sixth card classification to the tenth card classification.

[0076] In addition, as Figure 3CAs shown, in the main release state during each distribution period, the latest five types of card classifications can be used in a rotation format. On the other hand, in the pre-release state during each distribution period, players can use the same card classifications as those available in the previous distribution period in the rotation format. More specifically, in the pre-release state of the eighth period, the third to seventh card classifications can be used in the rotation format. In the pre-release state of the ninth period, the fourth to eighth card classifications can be used in the rotation format. In the pre-release state of the tenth period, the fifth to ninth card classifications can be used in the rotation format.

[0077] In other words, the game conditions of the rotation format in the pre-release state are the same as those of the rotation format in the main release state of the previous distribution period. This means that in the pre-release state, players can continue to play the game in the rotation format of the main release state of the previous distribution period.

[0078] In addition, in the pre-release state, in addition to adding the rotation format, a pre-rotation format is also added. The pre-rotation format represents the same game conditions as those represented by the rotation format in the main release state of the same distribution period. Therefore, in the pre-release state of the eighth period, the fourth to eighth card classifications can be utilized in the pre-rotation format. In the pre-release state of the ninth period, the fifth to ninth card classifications can be utilized in the pre-rotation format. In the pre-release state of the tenth period, the sixth to tenth card classifications can be utilized in the pre-rotation format.

[0079] Therefore, in the pre-release state, players can not only play the game in the rotation format of the main release state of the previous distribution period, but also play the game in the form of the pre-rotation format in the rotation format of the main release state of the new distribution period. Note that players cannot play the game in the pre-rotation format in the main release state. The differences between the pre-release state and the main release state will be described in detail below.

[0080] Figure 4A It is a diagram showing an example of a purchase type selection screen. Figure 4B It is a diagram for explaining an example of a card purchase screen in the pre-release state. Figure 4C It is a diagram for explaining the limited number of times. Figure 4D It is a diagram for explaining the upper limit function. Additionally, Figure 5A It is a diagram for explaining an example of a card purchase screen in the main release state. Figure 5B It is a diagram for explaining an example of a lottery result screen. For example, when this game application is launched, the communication between the player terminal 1 and the server 100 starts, enters the login state, and the game starts.

[0081] As Figure 4AAs shown, during the game, a menu bar 30 is displayed on the display 26. A plurality of operation parts that can be operated (tapped) by the player are provided in the menu bar 30. Here, as examples of the operation parts, a main screen selection part 30a marked as "Home", a single-player game selection part 30b marked as "Sole-Play", a battle selection part 30c marked as "Battle", a card screen selection part 30d marked as "Card", and a purchase type selection part 30e marked as "Store" are provided in the menu bar 30.

[0082] When the main screen selection unit 30a is tapped, a predetermined main screen is displayed on the display 26. When the single-player game selection unit 30b is tapped, various setting screens are displayed. When settings are made on these setting screens, a card battle game in the form of a battle with a computer is started. When the battle selection unit 30c is tapped, various setting screens are displayed. When settings are made on these setting screens, a card battle game in the form of a battle with another player through communication is started. When the card screen selection unit 30d is tapped, as described below, card stack (deck) organization, card list display, card destruction / creation, etc. can be performed.

[0083] When the purchase type selection portion 30e is tapped, the display 26 displays Figure 4A The purchase type selection screen shown. On the purchase type selection screen, a material purchase tab labeled "Material Purchase", a card purchase tab 32 labeled "Card Purchase", and a currency purchase tab labeled "In-game Currency Purchase" are displayed. When the material purchase tab is tapped, a screen for purchasing various materials is displayed, so that the player can purchase various materials such as card patterns through the player's operation.

[0084] When the currency purchase tab is tapped, the player can purchase in-game currency that can only be used in the current game. By using the in-game currency, the player can perform a draw for obtaining cards. In addition, the player can purchase a card stack with multiple cards. Here, tickets, rupees, and diamonds are provided as in-game currencies. The goods to be purchased and the time period in which each commodity can be purchased are set for each in-game currency. Note that the player can obtain in-game currency by obtaining in-game currency as a game reward and / or by paying to purchase in-game currency.

[0085] When the card purchase tab 32 is tapped, the Figure 4B Note that the card purchase screen is displayed in different ways depending on the distribution time period and the distribution status (pre-release status or main release status) in the distribution time period. Figure 4B , Figure 4C and Figure 4DDisplays a card purchase screen in a pre-release state during a distribution period corresponding to the tenth period. A card classification selection section 34 is displayed on this card purchase screen. In the card classification selection section 34, a tenth card classification label 34a, a ninth card classification label 34b, an eighth card classification label 34c, a seventh card classification label 34d, and a sixth card classification label 34e are provided. Although not shown in this figure, the first card classification label to the fifth card classification label are displayed by performing a predetermined operation in the card classification selection section 34.

[0086] In addition, a ticket information column 36a, a rupee information column 36b, a diamond information column 36c, and a point information column 36d are displayed on the right side of the card classification selection section 34. In the ticket information column 36a, the number of tickets owned that can be used to purchase a card pack (composed of eight cards as a set) and a purchase label marked as "Purchase" are displayed. When the purchase label displayed in the ticket information column 36a is tapped, a card pack is purchased using tickets. Although it will be described in detail below, here, the purchase of a card pack means drawing cards by a lottery (so-called gacha). When a card pack is purchased, a lottery process for determining cards by lottery is executed. The eight cards determined by the lottery process are awarded to the player. In short, it can be said that the operation for purchasing a card pack is an operation for requesting a card lottery process.

[0087] Note that tickets are provided for each card classification. For example, tickets that can be used to purchase a card pack of the tenth card classification cannot be used to purchase a card pack of another card classification. The number of tickets owned displayed in the ticket information column 36a corresponds to the label tapped in the card classification selection section 34. Therefore, when the tenth card classification label 34a is tapped, as Figure 4B shown, the number of tickets owned for the tenth card classification is displayed in the ticket information column 36a. When the ninth card classification label 34b is tapped, as Figure 4D shown, the number of tickets owned for the ninth card classification is displayed in the ticket information column 36a. Players can obtain tickets, for example, as a result of tickets provided by the game administrator or as a reward for the result of a card battle game.

[0088] In the rupee information column 36b, the number of rupees owned by the player and a purchase label marked as "Purchase" are displayed. When the purchase label displayed in the rupee information column 36b is tapped, a card pack is purchased using a predetermined number of rupees. Note that rupees can be used for card packs of all card classifications. However, it should be noted that in the pre-release state, a card pack of a new card classification cannot be purchased using rupees. For this reason, as Figure 4BAs shown, in the pre-release state, the purchase label in the rupee information bar 36b for the new card category is grayed out and is shown as not accepting player operations.

[0089] The number of diamonds the player owns and a purchase label marked "Purchase" are shown in the diamond information bar 36c. When the purchase label shown in the diamond information bar 36c is tapped, a card pack is purchased using a predetermined number of diamonds. Note that diamonds can be used for card packs in all card categories. Additionally, unlike rupees, diamonds can be used to purchase card packs for the new card category even in the pre-release state.

[0090] The current points obtained by the player and a get label marked "GET" are shown in the point information bar 36d. In this embodiment, when a card pack is purchased once, 1 point is given to the player. Furthermore, when the points obtained by the player reach the upper limit value (here, 300 points), the player can select and obtain his / her favorite card from among a plurality of pre-set cards.

[0091] However, it should be noted that points are managed separately for each card category. For example, when a card pack of the tenth card category is purchased once, 1 point is added to the points used for the tenth card category, and when a card pack of the ninth card category is purchased ten times, 10 points are added to the points used for the ninth card category. Therefore, when the tenth card category label 34a is tapped, as Figure 4B shown, the points used for the tenth card category are shown in the point information bar 36d. When the ninth card category label 34b is tapped, as Figure 4D shown, the points used for the ninth card category are shown in the point information bar 36d.

[0092] In addition, the cards that can be obtained when the points reach the upper limit value are limited to the cards belonging to the card category corresponding to the points that have reached the upper limit value. Therefore, for example, in the case where, as Figure 4D shown, the points used for the ninth card category reach the upper limit value, the player can select and obtain a predetermined card belonging to the ninth card category by tapping the get label in the point information bar 36d, but cannot obtain a card belonging to another card category. Here, this embodiment is configured such that: when the point value has not reached the upper limit value, as Figure 4B shown, the get label in the point information bar 36d is grayed out and does not accept player operations. On the other hand, when the point value has reached the upper limit value, as Figure 4D shown, the get label in the point information bar 36d is normally displayed, enabling an operation for selecting and obtaining one of the cards to be accepted.

[0093] Here, note that when the points reach the upper limit value, the player can still purchase card packs of the same card category by using tickets or the like. However, it should be noted that when the points reach the upper limit value, only the acquisition label in the point information column 36d can be enabled, and the purchase of card packs of the same card category by using tickets or the like can be disabled. In addition, this embodiment is configured such that: if the player cannot purchase a card pack because the number of tickets owned is 0, or the number of rupees or diamonds does not meet the required amount, etc., the purchase label is grayed out and the player's operation is not accepted.

[0094] Here, in this embodiment, the number of purchases of card packs of a new card category is restricted in the pre-release state. More specifically, in the pre-release state of the tenth period, a limit is imposed on the number of purchases of card packs of the tenth card category newly provided in the tenth period. In other words, in the pre-release state, the execution of the card drawing process exceeding the preset limit number (here, 800) is restricted. Therefore, in the pre-release state of the tenth period, at most only 100 purchases of card packs of the tenth card category can be made.

[0095] For example, as Figure 4B and Figure 4C shown, in the diamond information column 36c, the upper limit number of purchases of card packs (denominator) and the number of purchases of card packs of the relevant card category so far (numerator) are displayed. When the number of purchases of card packs reaches the upper limit, the purchase labels in the ticket information column 36a and the diamond information column 36c are grayed out, and thus the player's operation is not accepted.

[0096] However, it should be noted that only the number of purchases of card packs in the pre-release state is restricted for new card categories, and the number of purchases of card packs of old card categories is not restricted. Therefore, when an old card category is selected using the card category selection unit 34 as Figure 4D shown, the number of purchases of card packs and the upper limit number of purchases are not displayed.

[0097] In addition, Figure 5A shows the card purchase screen in the main release state of the tenth period. In the main release state, there is no restriction on the purchase of card packs for new card categories. Therefore, as Figure 5A shown, for new card categories, the number of purchases of card packs and the upper limit number of purchases are not displayed on the card purchase screen either. In addition, in the main release state, it is also possible to purchase card packs of new card categories by using rupees.

[0098] As described above, the player can select a card category by tapping on each label in the card category selection section 34. When a purchase operation is performed by tapping on the purchase label, one of the multiple types of cards belonging to a card category selected by the player is determined by lottery. In addition, in the pre-release state, if the number of purchases exceeds the limit number of times, the execution of the lottery process for new cards belonging to a specific card category (i.e., the new card category) is restricted. For old cards belonging to the old card category (i.e., card categories other than the specific card category), the lottery process can be executed more than the limit number of times. Also, although the execution of the lottery process for new cards exceeding the limit number of times is restricted in the pre-release state, the lottery process for new cards can be executed more than the limit number of times in the main release state.

[0099] Here, the current number of purchases of the card pack is compared with the upper limit number of purchases of the card pack. When the number of purchases of the card pack reaches the upper limit number of purchases, the purchase label on the player terminal 1 is displayed in a grayed-out manner, thereby not accepting the purchase operation. However, it should be noted that the method for not accepting the purchase operation is not limited to this, and for example, it may include a method in which information indicating that a purchase operation has been performed is sent to the server 100, and then the server 100 determines whether a purchase can be made.

[0100] In the case where a card pack is purchased as a result of tapping on one of the above purchase labels, a lottery process is executed in the server 100. The player terminal 1 receives the result of this lottery process, that is, lottery result information indicating the type of card awarded to the player. In the player terminal 1, as Figure 5B shown, based on the received lottery result information, a lottery result screen for reporting the lottery results of the 8 cards determined by the lottery process is displayed on the display 26.

[0101] Here, in this embodiment, as described above, each time a player purchases one card pack, he / she is given 1 point. In addition, the upper limit value of the points required for exchanging cards is set to 300. On the other hand, in the pre-release state, the upper limit number of times of purchasing a card pack of the new card category is set to 100. In short, in the pre-release state, the points of the new card category cannot reach the upper limit value. In other words, in the pre-release state, even if the number of times the lottery process is executed reaches the limit number of times, the point value of the new card category does not reach the upper limit value. This prevents the occurrence of the following contradiction: the player can obtain his / her favorite cards regardless of the restrictions imposed on the purchase of card packs.

[0102] Note that even after entering the main release state, the points obtained in the pre-release state are inherited. Additionally, in the case of updating the distribution period, the points are inherited as they are. This can prevent players from feeling a sense of loss due to point expiration. However, it should be noted that players do not need to be given points in the pre-release state and can be given points only in the main release state. Also, in the case of updating the distribution period, the points can be reset.

[0103] As described above, the cards determined by the lottery process (i.e., the cards obtained by the player through the lottery) and the cards obtained by redeeming points are stored as owned cards. The player organizes a deck by selecting multiple (e.g., 40) cards from the owned cards. The player can organize and save multiple decks. The player can select one of the saved decks and use it in the card battle game. The organization of the deck will be described below.

[0104] Figure 6A It is a diagram for explaining an example of the card setting screen. Figure 6B It is a diagram for explaining an example of the format selection screen in the pre-release state. Figure 6C It is a diagram for explaining an example of the deck selection screen. When tapping the card screen selection section 30d in the menu bar 30, the Figure 6A shown card setting screen is displayed. On this card setting screen, a deck organization label 40a and a card list / creation label 40b are displayed. When tapping the deck organization label 40a, the Figure 6B shown format selection screen is displayed.

[0105] The format selection screen displays different contents depending on whether the distribution state is the pre-release state and the transition state or the main release state (excluding the transition state). On the format selection screen, a format selection label 42 for selecting the format for determining the deck to be organized is displayed. In the pre-release state and the transition state, a rotation format selection label 42a, an unlimited format selection label 42b, and a pre-rotation format selection label 42c are displayed as the format selection label 42.

[0106] When tapping one of the format selection labels 42, the Figure 6C shown deck selection screen is displayed. On this deck selection screen, a list of the decks organized by the player is displayed. Here, the decks can be organized to correspond to one of the formats, and only the decks corresponding to the format selected on the format selection screen are displayed on the deck selection screen.

[0107] For example, when tapping the pre-rotation format selection label 42c on the format selection screen as Figure 6B shown, as Figure 6CAs shown, a list of card decks corresponding to the pre-rotation format is displayed. When organizing a card deck, the player can organize the card deck name. On the card deck selection screen, the card deck name is displayed on the icon corresponding to each card deck.

[0108] In addition, on the card deck selection screen, a create card deck label 44 marked as "Newly Created" is displayed. By tapping the create card deck label 44, the player can organize a new card deck corresponding to the format selected on the format selection screen.

[0109] Figure 7A It is a diagram for explaining an example of the organization method selection screen. Figure 7B It is a diagram for explaining an example of the card deck organization screen in the initial state. Figure 7C It is a diagram for explaining an example of the card deck organization screen during organization. Figure 7D It is a diagram for explaining an example of the copy source selection screen in the pre-release state. When tapping the create card deck label 44 on the Figure 6C shown card deck selection screen, the Figure 7A shown organization method selection screen is displayed on the display 26. A newly created label 46a marked as "Newly Created" and a copy label 46b marked as "Copy" are displayed on this organization method selection screen.

[0110] When tapping the newly created label 46a, the card deck organization screen is displayed as Figure 7B shown. On this card deck organization screen, multiple blank spaces are displayed in the upper row, and the cards owned by the player (hereinafter referred to as owned cards) are displayed in the lower row. However, it should be noted that the owned cards displayed on the card deck organization screen are limited to the cards corresponding to the format selected by the player. Therefore, for example, in the pre-release state of the tenth issue, when organizing the pre-rotation format, only the cards belonging to the sixth card category to the tenth card category among the owned cards are displayed, and when organizing the rotation format, only the cards belonging to the fifth card category to the ninth card category are displayed.

[0111] In addition, on the card deck organization screen, the player slides the owned cards displayed in the lower row to the upper row, thus as Figure 7CAs shown, the shifted owned cards are arranged in the blank space. By doing so, the owned cards arranged in the upper row on the deck organization screen are temporarily registered. In addition, when the save label 48 marked "Save" provided on the deck organization screen is tapped, the deck information is stored in the memory card. The deck information is assigned a deck ID, and the deck group information that can identify all the temporarily registered owned cards is stored in association with the deck ID. Although not shown in this figure, when the save label 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, the icons displayed on the deck selection screen, etc., and the deck group information are stored in association with the deck ID.

[0112] When tapping the icon on the Figure 6C deck selection screen shown, the deck organization screen is also displayed as Figure 7C shown. However, it should be noted that in this case, the cards constituting the deck selected on the deck selection screen are displayed in the upper row, and the owned cards are displayed in the lower row. In this case, the cards displayed in the upper row can be exchanged with the owned cards displayed in the lower row by the operation of the player.

[0113] In addition, when the copy label 46b is tapped on the organization method selection screen, a copy source selection screen as shown in Figure 7D is displayed. The decks that can be selected as the copy source are displayed on the copy source selection screen. Similar to the Figure 6C deck selection screen shown, the copy source selection screen is configured such that the player can select the currently stored decks. However, it should be noted that the decks that can be selected as the copy source differ depending on the distribution state and the format of the newly created deck (i.e., the format of the copy destination).

[0114] More specifically, in the case where the format of the copy destination is the unrestricted format, the player can select any format of deck as the copy source. Therefore, when organizing the deck used for the unrestricted format, all the currently stored decks are displayed on the copy source selection screen to be selectable as the copy source. On the other hand, when organizing the deck used for the pre-rotation format, as Figure 7D shown, only the decks used for the currently stored pre-rotation format are displayed on the copy source selection screen.

[0115] When tapping the icon displayed on the copy source selection screen, a deck organization screen similar to the Figure 7C screen shown is displayed. In this case, the cards constituting the deck selected on the copy source selection screen are displayed in the upper row, and the owned cards are displayed in the lower row, so that a new deck can be organized based on the deck used as the copy source. Therefore, by using the deck copy function, it is possible to easily organize a deck in which only some of the cards are replaced with different cards.

[0116] In addition, when organizing the card deck used in the rotation format, the copy source selected on the screen varies depending on the distribution status.

[0117] Figure 8A It is a diagram for explaining an example of the format selection screen in the transition state. Figure 8B It is a diagram for explaining an example of the card deck selection screen. Figure 8C It is a diagram for explaining an example of the organization method selection screen. Figure 8D It is a diagram for explaining an example of the copy source selection screen in the transition state. In the transition state, when tapping on the card deck organization label 40a on the Figure 6A shown card setup screen, the Figure 8A shown format selection screen is displayed. In the transition state, similar to the pre-release state, on the format selection screen, the rotation format selection label 42a, the unlimited format selection label 42b, and the pre-rotation format selection label 42c are displayed as the format selection labels 42.

[0118] Furthermore, when tapping on the rotation format selection label 42a on the format selection screen, a list of the card decks used in the rotation format is displayed on the Figure 8B shown card deck selection screen. Note that Figure 8B shows a state where the card decks used in the rotation format are not stored. If there is no stored card deck for the format selected by the player, only the create card deck label 44 is displayed on the card deck selection screen.

[0119] When tapping on the create card deck label 44 on the card deck selection screen, the Figure 8C shown organization method selection screen is displayed. At this time, when tapping on the copy label 46b, the Figure 8D shown copy source selection screen is displayed. Here, when organizing the card deck used in the rotation format in the transition state, the card decks used in the pre-rotation format and the rotation format are displayed on the copy source selection screen. More specifically, in the transition state, when newly creating a card deck used in the rotation format, the player can select the card deck used in the pre-rotation format or the card deck used in the rotation format as the card deck to be used as the copy source.

[0120] Figure 9A It is a diagram for explaining an example of the format selection screen in the main release state. Figure 9B It is a diagram for showing an example of the copy source selection screen in the main release state. In the main release state (excluding the transition state), when tapping on the card deck organization label 40a on the Figure 6A shown card setup screen, the Figure 9AThe format selection screen shown. In the main release state (except the transition state), the rotation format selection label 42a and the unrestricted format selection label 42b are displayed on the format selection screen as the format selection label 42. In short, in the main release state (except the transition state), different from the pre-release state and the transition state, the pre-rotation format selection label 42c is not displayed. Since the pre-rotation format selection label 42c is not displayed as described above, it is not possible to organize a card deck corresponding to the pre-rotation format in the main release state (except the transition state).

[0121] In addition, it is assumed that: the rotation format selection label 42a is tapped on the format selection screen, the create deck label 44 is tapped on the deck selection screen (refer to Figure 8B ), and the copy label 46b is tapped on the organization method selection screen (refer to 8C). Under this assumption, the Figure 9B shown copy source selection screen is displayed. When organizing a deck for the rotation format in the main release state (except the transition state), only the decks for the rotation format are displayed on the copy source selection screen, and the decks for the pre-rotation format and the unrestricted format are not displayed. In short, when newly creating a deck for the rotation format in the main release state (except the transition state), the player can only select the decks for the organized rotation format as the decks to be used as the copy source.

[0122] For example, in the pre-release state of the tenth period, cards belonging to the fifth card category to the ninth card category can be used in the card battle game of the rotation format, and cards belonging to the sixth card category to the tenth card category can be used in the card battle game of the pre-rotation format. In addition, in the main release state (including the transition state) after the pre-release state, cards belonging to the sixth card category to the tenth card category can be used in the card battle game of the rotation format, and the card battle game of the pre-rotation format cannot be executed.

[0123] In the tenth period, the pre-rotation format in the pre-release state and the rotation format in the main release state (including the transition state) represent the same game conditions and the available cards are common. Therefore, the deck for the pre-rotation format organized in the pre-release state also corresponds to the rotation format in the main release state (including the transition state). In the transition state, it is possible to organize a deck for the rotation format by using the deck for the pre-rotation format in the tenth period as the copy source. By doing so, after transitioning to the main release state (including the transition state), the player is spared the trouble of organizing the same deck again as the deck used in the pre-release state, thereby enhancing the operability.

[0124] In this embodiment, the player can not only obtain cards by lottery or point redemption as described above, but also create cards by himself / herself. The player can create cards by using the coins granted to him / her in the game. In addition, the player can transform unnecessary cards into coins by destroying the cards. However, it should be noted that the creation and destruction of cards are partially restricted according to the distribution status.

[0125] Figure 10A It is a diagram for explaining an example of the card list screen. Figure 10B It is a diagram for explaining an example of the card creation screen in the pre-release state. Figure 10C It is a diagram for explaining an example of the card details screen in the pre-release state. Figure 11A It is a diagram for explaining an example of the card list screen. Figure 11B It is a diagram for explaining an example of the card creation screen in the main release state. Figure 11C It is a diagram for explaining an example of the card details screen in the main release state. When tapping on the card list / create label 40b on the card settings screen shown in Figure 6A the card list screens shown in Figure 10A and Figure 11A are displayed.

[0126] On this card list screen, a possessed card label 50a, a creation mode label 50b, and a possessed coin display bar 50c are provided at the lower part of the display 26. The possessed card label 50a and the creation mode label 50b are configured to be able to accept the player's tapping operation. The possessed card label 50a and the creation mode label 50b are also displayed on the card creation screen. When tapping on the possessed card label 50a, the card list screens shown in Figure 10A and Figure 11A are displayed. When tapping on the creation mode label 50b, the card creation screens shown in Figure 10B and Figure 11B are displayed. On the other hand, the number of possessed coins owned by the player is displayed in the possessed coin display bar 50c.

[0127] As shown in Figure 10A and Figure 11A the cards possessed by the player and the number of possessed cards are displayed on the card list screen. Note that cards not possessed by the player can be displayed on the card list screen. In addition, on the card creation screen, as shown in Figure 10B and Figure 11B all provided cards are displayed regardless of whether the cards are possessed by the player. However, it should be noted that the cards possessed by the player are displayed in color, while the cards not possessed by the player are displayed in a grayscale manner ( Figure 10B and Figure 11Bas shown by the dashed lines). This enables players to easily identify whether each of the displayed cards is owned by the player himself / herself.

[0128] In addition, in the pre-release state, new cards among the cards not owned by the player are displayed in a hidden manner. In this hidden display, although the card name and function information (described below) are displayed, the pattern is not displayed. In Figure 10B it, among the cards in the lower row, the leftmost card to the fourth card from the left are displayed in a hidden manner, which means these four cards are new cards. On the other hand, in the main release state (including the transition state), as Figure 11B shown, the pattern of the new cards is also displayed. Note that in the hidden display of the new cards, the card name and function information can also be completely hidden.

[0129] When tapping on each card on the card list screen and the card creation screen, as Figure 10C and Figure 11C shown, the card details screen is displayed. On the card details screen, various information related to the tapped card is displayed, and a destroy label 52a and a create label 52b are provided. For example, in the main release state (including the transition state), as Figure 11C shown, the number of coins obtained is displayed on the destroy label 52a provided on the card details screen. When tapping on the destroy label 52a, the currently selected card is destroyed. By destroying this card, the player can obtain the same number of coins as the number of coins indicated by the number of coins obtained on the destroy label 52a. Note that when a card is destroyed, the number of related owned cards decreases.

[0130] In other words, the player can exchange the owned cards for coins by tapping on the destroy label 52a. The above-mentioned destroy function can only be applied to the cards owned by the player. Therefore, although not shown in this figure, on the card details screen of the cards not owned by the player, the destroy label 52a is grayed out and thus does not accept the tap operation.

[0131] In addition, the number of coins consumed is displayed on the create label 52b provided on the card details screen. When tapping on the create label 52b, the selected card can be created by consuming the same number of coins as the number of coins indicated by the number of coins consumed on the create label 52b. When creating a card, the number of related owned cards increases. In other words, the player can exchange the owned coins for cards by tapping on the create label 52b. This card creation function can be executed regardless of whether the player owns the card. More specifically, the player can create owned cards and non-owned cards.

[0132] Note that the provided cards may include cards that can be created and cards that cannot be created, or optionally, all cards can be created. Additionally, the provided cards may include cards that can only be created during a specified time period and cannot be created during other time periods.

[0133] Here, in the main release state (including the transition state), there are no restrictions on the card destruction function and the creation function. On the other hand, in the pre-release state, the card destruction function and the creation function are restricted for some cards. More specifically, in the pre-release state, new cards cannot be destroyed or created. Therefore, in the pre-release state, as Figure 10C shown, on the card details screen of a new card, the destroy label 52a and the create label 52b are displayed in a way that reports non-acceptance of tap operations. In this case, even if the destroy label 52a and the create label 52b are tapped, the tap operations are not accepted.

[0134] However, it should be noted that, similar to the Figure 11C screen shown, even in the pre-release state, the destroy label 52a and the create label 52b on the card details screen of an old card are provided as operable. In short, only old cards can be destroyed and created in the pre-release state.

[0135] As described above, in this embodiment, a create label 52b that accepts an operation (create operation) for selecting and obtaining one of the cards is provided so that the card selected via the create operation is stored as an owned card. However, it should be noted that the create operation for a new card cannot be accepted in the pre-release state, but the create operation for a new card can be accepted in the main release state (including the transition state). Therefore, since the acquisition of new cards via purchase and creation is restricted in the pre-release state, players have no choice but to play the card battle game with the limited owned cards, which enhances the true fun of the card battle game.

[0136] Note that in the pre-release state, not only can the create operation for a new card not be accepted, but also the create operation for an old card cannot be accepted. Additionally, the creation of some new cards can be allowed in the pre-release state. Furthermore, by, for example, increasing the number of new cards that can be created in stages during the distribution time period, the number of new cards that can be created can be changed for each time period.

[0137] Next, an example of a card battle game using the above-mentioned card deck and cards will be described. Figure 12A is a diagram for illustrating an example of a battle format selection screen in the main release state. Figure 12B is a diagram for illustrating an example of a battle format selection screen in the pre-release state. Figure 12CThis is a diagram for illustrating an example of the deck selection screen. When tapping the single-player game selection section 30b or the battle selection section 30c in the menu bar 30, the Figure 12A or Figure 12B shown battle format selection screen is displayed. This battle format selection screen is a screen for selecting the format of the card battle game to be played.

[0138] In the main release state, as Figure 12A shown, the rotation format selection label 42a and the unlimited format selection label 42b are displayed as the format selection labels 42 on the battle format selection screen. On the other hand, in the pre-release state, as Figure 12B shown, the rotation format selection label 42a, the unlimited format selection label 42b, and the pre-rotation format selection label 42c are displayed as the format selection labels 42 on the battle format selection screen.

[0139] By tapping one of the format selection labels 42, the player can select the format of the card battle game to be played. Here, in the main release state, as Figure 12A shown, the pre-rotation format selection label 42c is not displayed. Therefore, in the main release state, a card battle game using the deck for the pre-rotation format cannot be executed.

[0140] In addition, when tapping one of the format selection labels 42 on the battle format selection screen, the Figure 12C shown deck selection screen is displayed. On this deck selection screen, only the decks for the format selected by the player are displayed. Further, when tapping one of the decks displayed on the deck selection screen, the deck confirmation label 54a and the OK label 54b are displayed. When tapping the deck confirmation label 54a, a deck confirmation screen (not shown in the figure) is displayed. On this deck confirmation screen, all the cards constituting the deck selected by the player are displayed. On the other hand, when tapping the OK label 54b, the card battle game using the selected deck starts.

[0141] Figure 13 This is a diagram for illustrating an example of the card battle game. The card battle game according to this embodiment is a two-player game, and the cards to be used as the player's hand are randomly distributed from the deck selected by the player. Similarly, the cards to be used as the opponent's cards are also randomly distributed to the opponent from the deck selected by the opponent. In addition, in the card battle game, the player's turn and the opponent's turn are alternately repeated. In each turn, a card randomly selected from the deck is added to the hand. In his / her own turn, the player places the basic card on the table by selecting the basic card from the player's own hand according to a predetermined rule, generates a predetermined effect by using a skill card, and so on.

[0142] Note that available points are set in each round, and a consumption value is set in each card. When a player places a card on the table or uses a card, the consumption value set in the card is subtracted from the available points. The player can use the cards in their hand within the range of the available points.

[0143] In addition to the consumption value, two function values, attack power and physical strength, are set in the basic cards. The attack power represents the damage value given to the opponent, and the physical strength represents the damage value of the remaining ability until the relevant card is destroyed. In the card battle game, a health value (here 20) is given to each of the player and the opponent, and the player or opponent who first reduces the competitor's health value to 0 is the winner.

[0144] Figure 14A This is a diagram for exemplifying the function information used in the ninth period. Figure 14B This is a diagram for exemplifying the function information used in the pre-release state of the tenth period. Figure 14C This is a diagram for exemplifying the function information used in the tenth period. In the card battle game, the progress of the game (such as the display of cards and the calculation of damage values when using cards) is based on the function information. When displaying cards on the above-mentioned card deck organization screen, the display control (such as display patterns and function values) is also based on the function information.

[0145] The function information stores all information related to each card. For example, a card ID is associated with the following: a card classification ID for identifying the card classification; the name of the card; the illustration information shown on the card; function values (consumption value, attack power, physical strength, special ability); and the organizable quantity indicating the upper limit of the number of cards that can be organized in a card deck.

[0146] For example, in the main release state of the ninth period, as Figure 14A shown, the function information used in the ninth period is stored in the player terminal 1 and the server 100. The function information used in the ninth period stores the above-mentioned information related to all cards belonging to the first card classification to the ninth card classification (that is, the cards provided in the ninth period). In addition, in the main release state of the ninth period, referring to Figure 14A the function information used in the ninth period shown, the progress of the card battle game in the rotation format and the unlimited format is controlled.

[0147] In addition, when the distribution period is the tenth period, while maintaining the function information used in the ninth period, Figure 14BThe function information used in the pre-release state of the tenth period shown is stored in the player terminal 1 and the server 100. That is, in the pre-release state of the tenth period, two types of function information, namely the function information used in the ninth period and the function information used in the pre-release state of the tenth period, are stored. In addition, in the pre-release state of the tenth period, with reference to Figure 14B the function information used in the pre-release state of the tenth period shown, the progress of the card battle game in the pre-rotation format is controlled, and with reference to Figure 14A the function information used in the ninth period shown, the progress of the card battle games in the rotation format and the unlimited format is controlled.

[0148] Here, as shown by the thick line frame in Figure 14B , some of the function values set as the function information used in the ninth period in the card are different from the corresponding function values set as the function information used in the pre-release state of the tenth period in the same card. More specifically, in the pre-release state of the tenth period, a plurality of function information is stored, including: the function information used in the ninth period, in which the functions implemented by the cards in the card battle game in the rotation format are associated with the respective cards; and the function information used in the pre-release state of the tenth period, in which the functions implemented by the cards in the card battle game in the pre-rotation format are associated with the respective cards. In addition, the cards include specific cards that correspond to both the game conditions used in the rotation format and the game conditions used in the pre-rotation format in the pre-release state of the tenth period, and are assigned functions different between the function information used in the ninth period and the function information used in the pre-release state of the tenth period.

[0149] The rotation format and the pre-rotation format that can be used to play the game in the pre-release state of the tenth period are different in terms of the available cards, that is, they constitute different game conditions. When changing the combination of cards that can be organized in the card deck, there is a risk that the functions of some cards become too strong or too weak. The best game environment can be provided by changing the functions of some such cards.

[0150] In addition, at the end of the pre-release state of the tenth period, after the maintenance work, the main release state starts. During the maintenance work between the pre-release state and the main release state of the tenth period, the function information used in the ninth period is changed to the function information used in the tenth period, and the function information used in the pre-release state of the tenth period is deleted in the server 100. In addition, when the player terminal 1 communicates with the server 100 for the first time after entering the main release state of the tenth period, the function information in the player terminal 1 is also changed in the same way as the server 100.

[0151] Therefore, in the main release state of the tenth period, only Figure 14CThe function information used in the tenth period shown is stored in the player terminal 1 and the server 100. In the main release state of the tenth period, refer to Figure 14C the function information used in the tenth period shown to control the progress of the card battle game in the rotation format and the unlimited format.

[0152] Here, as Figure 14C shown by the thick line frame of, the functions of some cards in the function information used in the pre-release state of the tenth period are changed in the function information used in the tenth period. However, it should be noted that these changes in functions are not necessary. In this embodiment, although the function information used in the pre-release state in the same distribution period is deleted in the main release state, the function information used in the pre-release state can be maintained in the main release state so that the function information used in the pre-release state can be updated to the function information used in the new pre-release state when updating the distribution period. In addition, although the function information in the ninth and tenth periods is described here, the function information in other distribution periods is also updated in the same manner as described above.

[0153] The processing in the player terminal 1 and the server 100 for implementing the above card battle game, and the functional units for executing these processes will be described below. Note that the following description particularly focuses on the processes related to the differences between the pre-release state and the main release state, and the description of other processes will be omitted.

[0154] (Functional units of the player terminal 1)

[0155] Figure 15 is a functional block diagram of the player terminal 1. A program storage area 12a and a data storage area 12b are provided in the memory 12 of the player terminal 1. When the game starts, the CPU 10 stores the terminal-side game control program (module) in the program storage area 12a.

[0156] 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 card deck information storage program 64, and a battle game execution program 65. Note that Figure 15 the programs listed in are examples, and a large number of other programs are also provided as the terminal-side game control program.

[0157] The CPU 10 runs each program stored in the program storage area 12a and updates the data in each storage unit of the data storage area 12b. In addition, the CPU 10 runs each program stored in the program storage area 12a, whereby the player terminal 1 (computer) functions as the terminal control unit 1A. The terminal control unit 1A includes a function information receiving unit 60a, a status management unit 61a, a screen management unit 62a, an information update unit 63a, a card deck information storage unit 64a, and a battle game execution unit 65a.

[0158] More specifically, the CPU 10 runs the function information receiving program 60, whereby the computer functions as the function information receiving unit 60a. Similarly, the CPU 10 runs the status management program 61, the screen management program 62, the information update program 63, the card deck information storage program 64, and the battle game execution program 65, whereby the computer functions as the status management unit 61a, the screen management unit 62a, the information update unit 63a, the card deck information storage unit 64a, and the battle game execution unit 65a, respectively.

[0159] In the data storage area 12b, as storage units for storing data, a function information storage unit 80, a status information storage unit 81, an upper limit purchase count storage unit 82, a purchase count storage unit 83, an in-game currency information storage unit 84, a point storage unit 85, an upper limit value storage unit 86, an able / unable to purchase information storage unit 87, an able / unable to obtain information storage unit 88, an owned card information storage unit 89, a first card deck storage area 90, a second card deck storage area 91, a third card deck storage area 92, an all card information storage unit 93, and an owned coin storage unit 94 are provided. Note that these storage units are examples, and a large number of other storage units are provided in the data storage area 12b.

[0160] (Function units of server 100)

[0161] Figure 16 is a functional block diagram of the server 100. In the memory 112 of the server 100, a program storage area 112a and a data storage area 112b are provided. In the program storage area 112a, a login processing program 160, a status 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. Note that Figure 16 the programs listed are examples, and a large number of other programs are also provided as server-side game control programs.

[0162] The CPU 110 runs each program stored in the program storage area 112a and updates the data in each storage unit of the data storage area 112b. In addition, the CPU 110 runs each program stored in the program storage area 112a, whereby the server 100 (computer) functions as the server control unit 100A. The server control unit 100A includes a login processing unit 160a, a status management unit 161a, a lottery unit 162a, a lottery management unit 163a, a point exchange unit 164a, and a battle game execution unit 165a.

[0163] More specifically, the CPU 110 runs the login processing program 160, whereby the computer functions as the login processing unit 160a. Similarly, the CPU 110 runs the status management program 161, the lottery program 162, the lottery management program 163, the point exchange program 164, and the battle game execution program 165, whereby the computer functions as the status management unit 161a, the lottery unit 162a, the lottery management unit 163a, the point exchange unit 164a, and the battle game execution unit 165a, respectively.

[0164] In the data storage area 112b, as storage units for storing data, a function information storage unit 180, a status information storage unit 181, an upper limit purchase count storage unit 182, a purchase count storage unit 183, in-game currency information storage unit 184, a point storage unit 185, an upper limit value storage unit 186, an able / unable to purchase information storage unit 187, an able / unable to obtain information storage unit 188, an owned card information storage unit 189, a first card deck storage area 190, a second card deck storage area 191, a third card deck storage area 192, an all card information storage unit 193, and an owned coin storage unit 194 are provided. Note that the above storage units are examples, and a large number of other storage units are provided in the data storage area 112b.

[0165] Therefore, storage units identical to those in the data storage area 12b of the player terminal 1 are provided in the data storage area 112b of the server 100, and in this embodiment, all the information stored in the data storage area 12b is also stored in the data storage area 112b. The processing performed by the above terminal control unit 1A and server control unit 100A will be described below.

[0166] (Communication processing between the player terminal 1 and the server 100)

[0167] Figure 17This is the first sequence diagram for explaining the processing in the player terminal 1 and the server 100. When the player inputs an operation to start the game, the player terminal 1 executes a login request process. In this login request process, login information (P1) is sent to the server 100. When the login information is received, the server 100 executes a login process (S1).

[0168] Figure 18 This is a flowchart showing an example of the login process (S1) in the server 100. When the login information is received, the login processing unit 160a identifies the player terminal 1 and obtains the last login date and time (S1-1). In addition, the login processing unit 160a determines whether a login has been performed in the current distribution period in the distribution state (pre-release state or main-release state) (S1-2). If no login has been performed (\"No\" in S1-2), the login processing unit 160a sets various information used in the current distribution state as download information (S1-3). Here, the download destination of the function information corresponding to the current distribution state is set.

[0169] In addition, the login processing unit 160a obtains the status information updated by the status management unit 161a based on the date and time from the status information storage unit 181 (S1-4), and sets the obtained status information as download information (S1-5). Note that the status information is information configured to be able to identify the current distribution period and one of the three distribution states (i.e., pre-release state, transition state, and main-release state) (such as the pre-release state of the nth period, the transition state of the nth period, and the main-release state of the nth period, etc.).

[0170] Return reference Figure 17 When the above login process (S1) is executed, the player terminal 1 obtains download information indicating the download destinations of information (such as various data and programs) for executing the game, and downloads various information to the player terminal 1 based on the obtained download information (P2). By doing so, when logging in for the first time after updating the distribution period or distribution state, various information is updated in the player terminal 1. In addition, 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 the downloaded function information in the function information storage unit 80, or deletes the function information from the function information storage unit 80.

[0171] In addition, here, the status management unit 61a receives the status information set in the server 100 and stores the received status information in the status information storage unit 81. By doing so, the current distribution period and distribution state can be grasped in the player terminal 1.

[0172] Figure 19This is the second sequence diagram for explaining the processing in the player terminal 1 and the server 100. When the card purchase label 32 (refer to 4A) is tapped in the player terminal 1, the terminal control unit 1A executes a request information sending process (P11) for sending request information to the server 100. When the request information is received, the server 100 executes a purchase information derivation process (S11).

[0173] Figure 20 This is a flowchart showing an example of the purchase information derivation process (S11) in the server 100. When the request information is received, the server control unit 100A determines whether the distribution status is a pre-release status (S11-1). If the distribution status is a pre-release status (Yes in S11-1), the server control unit 100A obtains the upper limit of the purchase times of the card pack of the new card classification in the current distribution period, that is, the upper limit of the purchase times stored in the upper limit purchase times storage unit 182 (S11-2), and sets the upper limit of the purchase times information (S11-3). In addition, the server control unit 100A obtains the purchase times (the number of purchased card packs) of the card pack of the new card classification in the current distribution period, that is, the purchase times stored in the purchase times storage unit 183 (S11-4), and sets the purchase times information (S11-5).

[0174] Then, when the purchase times is less than the upper limit of the purchase times (Yes in S11-6), the server control unit 100A sets the purchasable information indicating that it is possible to purchase (S11-7). When the purchase times is not less than the upper limit of the purchase times (No in S11-6), the server control unit 100A sets the non-purchasable information indicating that it is not possible to purchase (S11-8).

[0175] In addition, regardless of whether the distribution status is a pre-release status, the server control unit 100A obtains the in-game currency information (the number of tickets, rupees, and diamonds) stored in the in-game currency information storage unit 184, and sets the obtained in-game currency information (S11-9). In addition, the server control unit 100A increments the card classification identification number n (S11-10), obtains the points of the nth card classification corresponding to the card classification identification number n (that is, the points stored in the point storage unit 185) (S11-11), and sets the obtained points (S11-12).

[0176] In addition, the server control unit 100A acquires the upper limit value of the nth card classification corresponding to the card classification identification number n (i.e., the upper limit value stored in the upper limit value storage unit 186) (S11-13), and sets the acquired upper limit value (S11-14). Then, when the current point is equal to or greater than the upper limit value (Yes in S11-15), the server control unit 100A sets the acquirable information indicating that a card can be acquired by using points (S11-16). When the current point is not equal to or greater than the upper limit value (No in S11-15), the server control unit 100A sets the non-acquirable information indicating that a card cannot be acquired by using points (S11-17).

[0177] 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 export 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 the above step S11-10. By doing so, point information, upper limit value information, and acquirable or non-acquirable information are set for all currently provided card classifications. As Figure 19 shown, in the purchase screen display process (P12) executed in the player terminal 1, each piece of information set in the above purchase information export process is received as purchase information.

[0178] Figure 21 is a flowchart for explaining an example of the purchase screen display process (P12) in the player terminal 1. The information update unit 63a stores the received purchase information (P12-1). Here, the information update unit 63a stores the upper limit purchase times in the upper limit purchase times storage unit 82, stores the purchase times in the purchase times storage unit 83, stores the quantities of tickets, rupees, and diamonds in the in-game currency information storage unit 84, stores the points of each card classification in the point storage unit 85, stores the upper limit values of each card classification in the upper limit value storage unit 86, stores the acquirable / non-acquirable information received as purchase information in the acquirable / non-acquirable information storage unit 87, and stores the acquirable / cannot-acquire information received as purchase information in the acquirable / cannot-acquire information storage unit 88.

[0179] Then, the status information in the status information storage unit 81 is checked, and if the current distribution status is the pre-release status (Yes in P12-2), the screen management unit 62a generates a card purchase screen for the pre-release status (refer to Figure 4B)(P12-3). Here, for the new card classification, only purchases using tickets or diamonds are allowed, and in addition, a screen showing the upper limit of the purchase count and the purchase count is generated. At this time, if the purchase count reaches the upper limit of the purchase count, a card purchase screen that does not allow purchases using tickets and diamonds to be made is generated.

[0180] On the other hand, if the current distribution state is not the pre-release state ("No" in P12-2), the screen management unit 62a generates a card purchase screen for the main release state (refer to Figure 5A )(P12-4). Here, a card purchase screen that allows purchases using tickets, rupees, and diamonds is generated. In addition, when the points corresponding to the new card classification in the current distribution period are equal to or greater than the upper limit value ("Yes" in P12-5), the screen management unit 62a generates an acquisition label that allows a tap operation and is normally displayed in the point information column 36d (refer to Figure 4D )(P12-6).

[0181] On the other hand, when the points corresponding to the new card classification in the current distribution period are not equal to or greater than the upper limit value ("No" in P12-5), the screen management unit 62a generates a grayed-out acquisition label that cannot be tapped in the point information column 36d (refer to Figure 4B )(P12-7). Then, the screen management unit 62a displays the card purchase screen generated as described above on the display 26 (P12-8).

[0182] Here, when the card purchase screen is to be displayed, a ticket information column 36a, a rupee information column 36b, a diamond information column 36c, and a point information column 36d corresponding to the new card classification in the current distribution period are displayed on the display 26 as the top page of the card purchase screen. Although detailed description is omitted, when each label in the card classification selection unit 34 is tapped, a ticket information column 36a, a rupee information column 36b, a diamond information column 36c, and a point information column 36d corresponding to the card classification of the tapped label are displayed on the display 26.

[0183] Return to reference Figure 19 , when the purchase label is tapped on the card purchase screen, the terminal control unit 1A executes a lottery request process for sending lottery request information to the server 100 (P13). The lottery request information is configured to be able to identify the card classification, and the lottery request information corresponding to the label tapped in the card classification selection unit 34 is sent to the server 100. When the lottery request information is received, the server 100 executes a lottery execution process (S12).

[0184] Figure 22It is a flowchart for explaining an example of the lottery execution process (S12) in the server 100. When receiving lottery request information, the lottery unit 162a confirms the type of purchase currency (S12-1). Here, the type of purchase currency is one of the in-game currencies: tickets, rupees, and diamonds. Next, the lottery management unit 163a confirms the card category corresponding to the received lottery request information (S12-2). If the card category is a new card category during the current distribution period (yes in S12-3), and the current distribution status is the pre-release status (yes in S12-4), then it is judged whether the number of purchases is less than the upper limit of the number of purchases (S12-5).

[0185] If the number of purchases is not less than the upper limit of the number of purchases, that is, if the number of purchases reaches the upper limit of the number of purchases (no in S12-5), then the lottery management unit 163a executes a predetermined error process (S12-6). In this case, the purchase of cards, that is, the drawing of cards, is not executed. In addition, the lottery management unit 163a also executes an error process (S12-6) when the amount of purchase currency does not reach the required amount (no in S12-7), whereby the drawing of cards is not executed.

[0186] If the conditions for drawing cards are satisfied in the above steps from S12-3 to S12-7, then the lottery unit 162a increments the lottery count identification number n (S12-8). Then, the lottery unit 162a sets a lottery table corresponding to both the card category and the lottery count identification number (S12-9). Note that a lottery table is provided for each card category, and the winning rate is set for all cards belonging to the relevant card category. The lottery unit 162a obtains a randomly generated random value, and based on the obtained random value and the lottery table, executes a judgment process for determining one of the cards (S12-10).

[0187] Then, the lottery unit 162a stores the card information related to the card determined in the judgment process (S12-11), and sets the relevant card information (S12-12). The card information set here is received by the player terminal 1. The lottery unit 162a judges whether the lottery count identification number n is the maximum (here it is 8) (S12-13). If the lottery count identification number n is not the maximum (no in S12-13), then the process is repeated from the above step 1-8.

[0188] In addition, if the lottery draw count identification number n is the largest ("Yes" in S12-13), the lottery draw unit 162a stores the eight card information stored in the above step S12-11 in the owned card information storage unit 189 in association with the player ID as the owned card information (S12-14). Note that the owned card information storage unit 189 is configured to be able to store the owned card information such that the number of owned cards is associated with the card information related to each card, and here, the number of owned cards in the corresponding card information is updated.

[0189] In addition, the server control unit 100A updates the purchase currency (tickets, rupees, and diamonds) for purchasing cards 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.

[0190] In addition, the server control unit 100A adds 1 to the points stored in the point storage unit 185 and adds 1 to the purchase count stored in the purchase count storage unit 183 (S12-17). Note that in the point storage unit 185 and the purchase count storage unit 183, the points and purchase counts are stored classified by each card. Then, the server control unit 100A sets the point information indicating the updated points and the purchase count information indicating the updated purchase count (S12-18). The point information and the purchase count information set here are received by the player terminal 1.

[0191] Return reference Figure 19 When the lottery draw execution process (S12) is executed as described above, the player terminal 1 receives the above card information, purchase currency information, point information, and purchase count information as the lottery draw result information. When receiving the lottery draw result information, the player terminal 1 executes the lottery draw result reflection process (P14).

[0192] Figure 23 is a flowchart for explaining an example of the lottery draw result reflection process in the player terminal 1. When receiving the lottery draw result information, the screen management unit 62a analyzes the card information received as the lottery draw result information (P14-1), and generates and displays the lottery draw result screen (reference Figure 5B )(P14-2). In addition, based on the analysis result of the card information, the information update unit 63a stores the received card information in the owned card information storage unit 89 as the owned card information (P14-3). Note that the owned card information storage unit 89 is configured to be able to store the owned card information such that the number of owned cards is associated with the card information related to each card, and here, the number of owned cards in the corresponding card information is updated.

[0193] Then, the information update unit 63a updates the quantities (P14-4) of the purchased currency information (tickets, rupees, and diamonds) in the in-game currency information storage unit 84 based on the purchased currency information received as the lottery result information, and updates the points (P14-5) in the point storage unit 85 based on the point information. In addition, the information update unit 63a updates the number of purchases stored in the purchase number storage unit 83 based on the purchase number information (P14-6). By doing so, information is shared between the player terminal 1 and the server 100.

[0194] Return reference Figure 19 , when the acquisition label is tapped on the card purchase screen, the terminal control unit 1A executes the acquisition request process (P15). In the acquisition request process, the cards that can be exchanged with points are displayed, and when the player selects the card to be exchanged with points, the acquisition request information is sent to the server 100. The acquisition request information is configured to be able to identify the card classification ID and the card ID of the card. When the acquisition request information is received, the server 100 executes the acquisition execution process (S13).

[0195] Figure 24 is a flowchart for explaining an example of the acquisition execution process (S13) in the server 100. When the acquisition request information is received, the point exchange unit 164a analyzes the received acquisition request information (S13-1), and determines whether the points of the card classification indicated in the acquisition request information among the points stored in the point storage unit 185 are equal to or greater than the upper limit value (300) (S13-2). If the points stored in the point storage unit 185 are not equal to or greater than the upper limit value ( "No" in S13-2), the point exchange unit 164a executes an error process (S13-3).

[0196] On the other hand, if the points stored in the point storage unit 185 are equal to or greater than the upper limit 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 card information related to the acquired card as the owned card information (S13-5). In addition, the point exchange unit 164a subtracts the upper limit value (300) from the points stored in the point storage unit 185 (S13-6), and sets the updated point information (S13-7).

[0197] Return reference Figure 19 , when the acquisition execution process (S13) is executed as described above, the player terminal 1 receives the above acquisition information and point information as the acquisition result information. When the acquisition result information is received, the player terminal 1 executes the acquisition result reflection process (P16).

[0198] Figure 25This is a flowchart for illustrating an example of the acquisition result reflection process (P16) in the player terminal 1. When receiving acquisition result information, the screen management unit 62a analyzes the acquisition information (P16-1) received as the acquisition result information, and generates and displays an acquisition result screen (P16-2). In addition, based on the analysis result of the acquisition information, the information update unit 63a stores the card information indicated in the received acquisition information as owned card information in the owned card information storage unit 89 (increasing the number of owned cards) (P16-3). In addition, based on the point information received as the acquisition result information, the information update unit 63a updates the points stored in the point storage unit 85 (P16-4).

[0199] Figure 26 This is the third sequence diagram for illustrating the processes in the player terminal 1 and the server 100. When tapping the card deck organization label 40a in the player terminal 1 (see Figure 6A ), the screen management unit 62a executes the format selection screen display process (P21).

[0200] Figure 27 This is a flowchart for illustrating an example of the format selection screen display process (P21) in the player terminal 1. The screen management unit 62a confirms the status information stored in the status information storage unit 81 (P21-1). Then, if the current distribution status is the pre-release status or the transition status (yes in P21-2), the screen management unit 62a generates a format selection screen for the pre-release status (refer to Figure 6B )(P21-3), and displays the generated format selection screen on the display 26 (P21-5). The screen management unit 62a generates a rotation format selection label 42a, an unrestricted format selection label 42b, and a pre-rotation format selection label 42c on the format selection screen for the pre-release status.

[0201] On the other hand, if the distribution status is not the pre-release status or the transition status (no in P21-2), the screen management unit 62a generates a format selection screen for the main release status (refer to Figure 9A )(P21-4), and displays the generated format selection screen on the display 26 (P21-5). The screen management unit 62a generates a rotation format selection label 42a and an unrestricted format selection label 42b on the format selection screen for the main release status.

[0202] Returning to reference Figure 26 , when the format selection screen is displayed as described above, the card deck organization process (P22) is executed in the player terminal 1. Note that the description of the process related to the unrestricted format will be omitted hereinafter.

[0203] Figure 28This is a flowchart showing an example of the card deck organization process (P22) in the player terminal 1. When the rotation format selection label 42a is tapped (Yes in P22-1), the screen management unit 62a loads the card deck ID stored in the first card deck storage area 90, and displays a card deck selection screen based on the loaded card deck ID (see Figure 8B )(P22-2). Additionally, when the pre-rotation format selection label 42c is tapped on the card deck selection screen (Yes in (P22-3)), the screen management unit 62a loads the card deck ID stored in the second card deck storage area 91, and displays a card deck selection screen based on the loaded card deck ID (see Figure 6C )(P22-4).

[0204] Note: The first card deck storage area 90 stores the card deck information for the rotation format in the current distribution period; the second card deck storage area 91 stores the card deck information for the pre-rotation format in the current distribution period; and the third card deck storage area 92 stores the card deck information for the unrestricted format. Therefore, in step P22-2 above, the card deck for the rotation format is displayed on the card deck selection screen, and in step P22-4 above, the card deck for the pre-rotation format is displayed on the card deck selection screen.

[0205] Furthermore, when an icon (card deck) is tapped on the card deck selection screen (Yes in P22-5), the screen management unit 62a displays a card deck organization screen (see Figure 7C )(P22-6). Here, the screen management unit 62a loads the following card information (card group information) that is associated with the card deck ID corresponding to the tapped icon and is stored in the first card deck storage area 90, the second card deck storage area 91, and the third card deck storage area 92. Then, based on the loaded card information, the screen management unit 62a displays the cards in the upper row on the card deck organization screen.

[0206] In addition, when the create card deck label 44 is tapped on the card deck selection screen (Yes in P22-7), the screen management unit 62a displays an organization method selection screen (see Figure 7A )(P22-8). Additionally, when the newly created label 46a is tapped on the organization method selection screen (Yes in P22-9), the screen management unit 62a loads the owned cards corresponding to the currently selected format from the owned card information storage unit 89, and displays a card deck organization screen with the owned cards arranged in the lower row (see Figure 7B )(P22-10).

[0207] In addition, when a player's operation (such as swiping a card, etc.) is input on the deck organization screen (being "Yes" in P22-11), the screen management unit 62a updates the display (such as arranging the cards in the upper row on the deck organization screen, etc.), and temporarily registers information related to the cards arranged in the upper row (P22-12).

[0208] In addition, when the save label 48 is tapped (being "Yes" in P22-13), the deck information storage unit 64a performs a deck information storage process (P23).

[0209] Figure 29 It is a flowchart for explaining an example of the deck information storage process (P23) in the player terminal 1. If the format of the deck to be newly stored is the rotation format (being "Yes" in P23-1), the deck information storage unit 64a stores the deck information including the card information (card group information) related to all the cards selected (temporarily registered) on the deck organization screen in the first deck storage area 90 (P23-2).

[0210] In addition, if the format of the deck to be newly stored is the pre-rotation format (being "Yes" in P23-3), the deck information storage unit 64a stores the deck information including the card information related to all the cards selected on the deck organization screen in the second deck storage area 91 (P23-4). Note that if the format of the deck to be newly stored is the unrestricted format (being "No" in P23-3), the deck information storage unit 64a stores the deck information including the card information related to all the cards selected on the deck organization screen in the third deck storage 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 sent to the server 100.

[0211] Return reference Figure 28 , when the copy label 46b is tapped on the organization method selection screen (being "Yes" in P22-14), the screen management unit 62a confirms the status information stored in the status information storage unit 81 (P22-15), and displays a copy source selection screen (reference Figure 7D )(P22-16).

[0212] Here, when the current distribution state is the pre-release state and the format of the copy destination is the rotation format, the screen management unit 62a loads the deck ID stored in the first deck storage area 90, and displays the copy source selection screen based on the loaded deck ID. In addition, when the current distribution state is the pre-release state and the format of the copy destination is the pre-rotation format, the screen management unit 62a loads the deck ID stored in the second deck storage area 91, and displays the copy source selection screen based on the loaded deck ID.

[0213] In addition, when the current distribution state is the transition state and the format of the copy destination is the rotation format, the screen management unit 62a loads the deck IDs stored in the first deck storage area 90 and the second deck storage area 91, and displays the copy source selection screen based on the loaded deck IDs.

[0214] In addition, when the current distribution state is the main release state (excluding the transition state) and the format of the copy destination is the rotation format, the screen management unit 62a loads the deck ID stored in the first deck storage area 90, and displays the copy source selection screen based on the loaded deck ID.

[0215] Then, when one of the icons is tapped on the copy source selection screen and a copy source determination operation for determining the deck to be used as the copy source is input ("Yes" in P22-17), the deck information storage unit 64a displays the deck organization screen (refer to Figure 7C )(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, the screen management unit 62a displays the cards in the upper row on the deck organization screen based on the loaded card information.

[0216] According to Figure 29 the deck information storage process shown (P23), for the deck composed of the cards selected from the owned cards based on the player's operation in the pre-release state, the deck information used for the pre-rotation format (e.g., the sixth card category to the tenth card category) is stored in the second deck storage area 91, and the deck information used for the rotation format different from the pre-rotation format (e.g., the fifth card category to the ninth card category) is stored in the first deck storage area 90. Then, during the maintenance work between the pre-release state and the transition state, the deck information stored in the first deck storage area 90 is deleted. In the transition state after the maintenance work, based on the player's operation, the deck information corresponding to the rotation format (e.g., the sixth card category to the tenth card category) is stored in the first deck storage area 90.

[0217] In addition, according to Figure 28The card deck organization process (P22) shown can copy the card deck information used in the pre-rotation format (e.g., the sixth card category to the tenth card category) stored in the second card deck storage area 91 in the pre-release state to the first card deck storage area 90 in the transition state based on the player's operation.

[0218] Return reference Figure 26 , when the card deck information set in the card deck organization process is sent from the player terminal 1 to the server 100, the card deck information saving process (S21) is executed in the server 100. Similar to the player terminal 1, the server 100 is equipped with a first card deck storage area 190, a second card deck storage area 191, and a third card deck storage area 192. In the same manner as the player terminal 1, the card deck information stored in the player terminal 1 is also stored in the storage area of the server 100.

[0219] In addition, when tapping on the card list / create label 40b (reference Figure 6A ) on the player terminal 1, the screen management unit 62a executes the card list / create screen display process (P25).

[0220] Figure 30 is a flowchart for explaining an example of the card list / create screen display process (P25) in the player terminal 1. The screen management unit 62a confirms the status information stored in the status information storage unit 81 (P25-1). Then, if the current distribution state is the pre-release state ("Yes" in P25-2), the screen management unit 62a generates a card list screen for the pre-release state (reference Figure 10A ) and a card creation screen (reference Figure 10B ) (P25-3), and displays the generated screens on the display 26 (P25-5).

[0221] Here, the screen management unit 62a loads the owned card information from the owned card information storage unit 89 and arranges all the owned cards on the card list screen. In addition, the screen management unit 62a loads the card information related to all currently provided cards from the all card information storage unit 93, determines whether these cards are owned by the player, and generates a card creation screen. Here, the card creation screen is generated and displayed such that among the new cards in the current distribution time period, the cards not owned by the player are displayed in a hidden manner, the other old cards not owned by the player are displayed in a grayed-out manner, and the owned cards are displayed in color.

[0222] On the other hand, if the current distribution state is not the pre-release state ("No" in P25-2), the screen management unit 62a generates a card list screen for the main release state (reference Figure 11A) and the card creation screen (Reference 11B) (P25-4), and display the generated screen on the display 26 (P25-5). Here, the screen management unit 62a generates and displays the card creation screen such that cards not owned by the player are displayed in a grayscale manner and owned cards are displayed in color.

[0223] Return reference Figure 26 , when the card list screen and the card creation screen are displayed as described above, a card creation / destruction process (P26) is executed in the player terminal 1.

[0224] Figure 31 is a flowchart for explaining an example of the card creation / destruction process (P26) in the player terminal 1. When a card displayed on the card list screen or the card creation screen is tapped ("Yes" in P26-1), the screen management unit 62a determines whether the current distribution state is a pre-release state (P26-2). Then, if the current distribution state is a pre-release state ("Yes" in P26-2), the screen management unit 62a generates a card detail screen for the pre-release state (Reference Figure 10C )(P26-3), and displays the generated card detail screen on the display 26 (P26-5).

[0225] 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 the card detail screen to display the destruction label 52a and the creation label 52b in a grayscale manner when the tapped card belongs to a new card category in the current distribution period.

[0226] In addition, the screen management unit 62a generates the card detail screen to display the destruction label 52a in a grayscale manner when the tapped card does not belong to a new card category in the current distribution period and is not owned by the player. Further, the screen management unit 62a generates the card detail screen to display the creation label 52b in a grayscale manner when the player does not have the coins required to create the tapped card.

[0227] On the other hand, if the current distribution state is not a pre-release state ("No" in P26-2), the screen management unit 62a generates a card detail screen for the main release state (Reference Figure 11C )(P26-4), and displays the generated card detail screen on the display 26 (P26-5). Here, the screen management unit 62a generates the card detail screen to display the destruction label 52a in a grayscale manner when the player does not own the tapped card, and to display the creation label 52b in a grayscale manner when the player does not have the coins required to create the tapped card.

[0228] In addition, when the destruction label 52a is tapped (Yes in P26-6), a card destruction process is executed (P26-7). In this card destruction process, the screen management unit 62a displays a destruction animation, and the information update unit 63a adds the number of coins corresponding to the destroyed card and the number of owned coins stored in the owned coin storage unit 94. In addition, the information update unit 63a decreases the number of owned cards corresponding to the destroyed card in the owned card information stored in the owned card information storage unit 89.

[0229] In addition, when the creation label 52b is tapped (Yes in P26-8), a card creation process is executed (P26-9). In this card creation process, the screen management unit 62a displays a creation animation, and the information update unit 63a subtracts the number of coins corresponding to the created card from the number of owned coins stored in the owned coin storage unit 94. In addition, the information update unit 63a increases the number of owned cards corresponding to the created card in the owned card information storage unit 89.

[0230] According to the above card creation / destruction process, the destruction label 52a and the creation label 52b cannot accept tap operations on new cards in the pre-release state, and for tap operations after the main release state (including the transition state) starts, the destruction label 52a and the creation label 52b are enabled.

[0231] Return reference Figure 26 When creating or destroying a card in the card creation / destruction process (P26), creation / destruction information (such as card information related to the created or destroyed card, the updated number of coins, and owned card information, etc.) is sent from the player terminal 1 to the server 100. When receiving the creation / destruction information, the server 100 executes a card information storage process (S22) for updating the information in the owned card information storage unit 189 and the owned coin storage unit 194 in the same manner as the player terminal 1.

[0232] In addition, when the single-player game selection unit 30b or the battle selection unit 30c in the menu bar 30 is tapped, a screen for setting game conditions such as format is displayed. For example, when setting game conditions after tapping the single-player game selection unit 30b, the battle game execution unit 65a executes a card battle game execution process (P27) by using the owned cards stored in the owned card information storage unit 89.

[0233] In the pre-release state, the combat game execution unit 65a executes a game corresponding to the rotation format based on the player's operation by using the deck information stored in the first deck storage area 90 (the fifth card classification to the ninth card classification when the distribution period is the tenth period), and executes a game corresponding to the pre-rotation format by using the deck information stored in the second deck storage area 91 (the sixth card classification to the tenth card classification when the distribution period is the tenth period). Additionally, in the main release state (including the transition state), the combat game execution unit 65a executes a game corresponding to the rotation format with the same game conditions as the pre-rotation format based on the player's operation by using the deck information stored in the first deck storage area 90 (the sixth card classification to the tenth card classification when the distribution period is the tenth period).

[0234] When the card battle game execution process ends, the game result information is sent 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 not described in detail, in the case of tapping the combat selection unit 30c, the combat game execution unit 65a in the player terminal 1 and the combat game execution unit 165a in the server 100 execute the card battle game in the form of a cooperative operation to conduct combat through communication.

[0235] Although aspects of the embodiments have been described with reference to the drawings, it goes without saying that the present invention is not limited to the above embodiments. Obviously, those skilled in the art can conceive various variations and modifications within the scope described in the claims, and it should be understood that these variations and modifications naturally fall within the technical scope of the present invention.

[0236] In the above embodiment, when purchasing cards, multiple cards are purchased at once as a card pack. More specifically, eight draw processes are executed based on a single operation on the purchase label (a single draw request operation). However, it is possible to execute a single draw process using a single draw request operation.

[0237] Additionally, in the above embodiment, each card belongs to one of the card classifications. However, in the case where no card classification is provided, it is possible to determine a single card from all the provided cards via a draw process.

[0238] Furthermore, in the above embodiment, although each card belongs to one of the card classifications, it is possible to provide cards that do not belong to any card classification. In this case, for example, a card that does not belong to any card classification may be able to be used in the rotation format at all times, or may only be able to be used in the rotation format during a preset period.

[0239] In addition, although the above-described embodiments have been illustrated by examples capable of performing both battles against a computer and battles against another player via communication, it is possible to perform only one of these two types of battles. Further, the details of the games in the above-described embodiments are merely examples. In the above-described embodiments, a card battle game using cards as a game medium can be played. However, for example, characters can be provided as a game medium, whereby an action game or a role-playing game that performs a battle game by using the owned characters can be realized.

[0240] There are no particular limitations on the details of the game, as long as the following are satisfied: a lottery process is performed in which one of a plurality of types of game media provided in advance is determined by lottery based on a lottery request operation input by a player; the determined game medium is stored in a storage unit in association with a player ID as an owned game medium; and a predetermined game is performed by using the owned game medium stored in the storage unit.

[0241] In addition, the above-described embodiments have been illustrated by the following examples: 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 predetermined operations are restricted according to the display content for each distribution state. However, for example, when the distribution period or the distribution state is updated, different programs can be read so that instead of determining the current distribution period, etc., the processing can be made different according to the distribution period, etc.

[0242] Specifically, in the pre-release state, a program including a process for restricting the execution of the lottery process in the case of exceeding a limit number of times can be read, and in the main-release state, a program that does not execute the process for restricting the execution of the lottery process can be read. More specifically, in the pre-release state, a program is read in which: for a specific card category, the execution of the lottery process exceeding the limit number of times is restricted; and for card categories other than the specific card category, the lottery process exceeding the limit number of times can be executed. On the other hand, in the main-release state, a program is read in which for all card categories, the lottery process exceeding the limit number of times can be executed. Therefore, in the pre-release state, the game can be executed by starting the program that restricts the execution of the lottery process, and in the main-release state, the game can be executed by starting the program that does not restrict the execution of the lottery process.

[0243] In addition, for example, in the pre-release state, a program for not accepting an operation (first operation) for creating a predetermined card can be read, and in the main-release state, a program for accepting an operation (first operation) for creating a predetermined card can be read.

[0244] In addition, in the above-described embodiment, the number of points in the pre-release state does not reach the upper limit value. However, for example, in the pre-release state, it is also possible to allow the number of points to reach the upper limit value, although operations (second operations) for obtaining cards by using points are not accepted in the pre-release state. In this case, for example, a program that does not accept the relevant operation (second operation) can be read in the pre-release state, and a program that can accept the relevant operation (second operation) can be read in the main release state.

[0245] In addition, for example: in the pre-release state, a program is read that stores first deck information (first medium group information) for identifying a plurality of cards corresponding to a first game condition selected from owned cards (owned game media) based on a player's operation in a first storage area, and stores 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 in a second storage area; and in the main release state, a program for storing the second deck information (second medium group information) in the first storage area based on a player's operation is read.

[0246] Furthermore: in the pre-release state, a program can be read that enables games using the first deck information (first medium group information) stored in the first storage area and games using the second deck information (second medium group information) stored in the second storage area based on a player's operation; and in the main release state, a program can be read that enables games using the second deck information (second medium group information) stored in the first storage area based on a player's operation, and does not enable games using the first deck information (first medium group information), and further stores (transfers, copies) the second deck information (second medium group information) stored in the second storage area in the pre-release state to the first storage area based on a player's operation.

[0247] In addition, the update process during maintenance work can be programmed to be automatically executed at a predetermined date and time, or alternatively, the update process can be manually executed.

[0248] In addition, in the above-described embodiment, although an upper limit value is set for the number of purchases of card packs, an upper limit value can be set for the number of purchases of cards. In addition, whether the upper limit value is reached can be managed based on the number of times the lottery process is executed rather than the number of purchases of card packs.

[0249] In addition, in the above-described embodiments, although the lottery process can be executed without limitation in the main release state, a limit number can be set within the range where the lottery process can be executed more times in the main release state than in the pre-release state. In short, more limit numbers can be set in the main release state than in the pre-release state.

[0250] Note that in the above-described embodiments, the information processing system S, which is a client-server system, executes each of the above-described information processes. However, the functions of the server 100 in the above-described embodiments can be provided in the player terminal 1. In this case, the communication function is not necessary, and the player terminal 1 serves as a game terminal device.

[0251] In addition, the programs in the above-described embodiments can be stored in a computer-readable storage medium and can be provided in the form of a storage medium. Furthermore, these programs can be provided in the form of a game terminal device or an information processing system including the storage medium. In addition, the above-described embodiments can be an information processing method for implementing each function and the steps shown in the flowcharts.

[0252] Note that the owned card information storage unit 89 and the owned card information storage unit 189 in the above-described embodiments correspond to the storage unit, the server control unit 100A for executing the processes of steps S12 - 14 and the terminal control unit 1A for executing the processes of steps P14 - 3 correspond to the game medium storage unit, the pre-release state corresponds to the preparation time period, the transition state corresponds to the post time period, the rotation format in the pre-release state during the predetermined distribution time period corresponds to the first game condition, the card deck corresponding to the first game condition corresponds to the first medium group information, the first card deck storage area 90 corresponds to the first storage area, the pre-rotation format in the pre-release state during the predetermined distribution time period or the rotation format in the main release state during the predetermined distribution time period corresponds to the second game condition, the card deck corresponding to the second game condition corresponds to the second medium group information, the second card deck storage area 91 corresponds to the second storage area, the card deck information storage unit 64a corresponds to the medium group information storage unit, the battle game execution units 65a and 165a correspond to the game execution unit, the terminal control unit 1A for executing the processes of steps P22 - 14 to P22 - 18 corresponds to the transition unit, the function information storage units 80 and 180 correspond to the function information storage unit, the function information corresponding to the card classification provided relatively earlier corresponds to the first function information, and the function information corresponding to the card classification provided relatively later corresponds to the second function information.

[0253] Industrial Applicability

[0254] The present invention can be used in an information processing system, an information processing method, and an information processing program.

[0255] Description of Reference Numerals

[0256] 1A Terminal Control Unit

[0257] 36d Point Information Bar

[0258] 52b Create a tag

[0259] 62a Picture Management Unit

[0260] 63a Information update unit

[0261] 64a Card stack information storage unit

[0262] 65a, 165a Combat Game Execution Unit

[0263] 80, 180 Function information storage unit

[0264] 89, 189 has card information storage unit

[0265] 90 First card pile storage area

[0266] 91 Second card pile storage area

[0267] 100A Server Control Unit

[0268] 162a Lottery Unit

[0269] 164a Points Exchange Unit

Claims

1. An information processing apparatus, comprising a memory, a computer, and a computer program stored in the memory, the computer program, when executed by the computer, implementing the following steps: Storing, in a storage unit, the game media owned by a player among a plurality of types of game media as owned game media in a manner associated with the player ID; In a preparatory period before a specified time, storing first media group information for identifying a plurality of the game media corresponding to a first game condition selected from the owned game media based on a player's operation in a first storage area, and storing second media group information for identifying a plurality of the game media corresponding to a second game condition different from the first game condition in a second storage area, and in a subsequent period after the specified time, storing the second media group information in the first storage area based on the player's operation; In the preparatory period, being able to execute a game using the first media group information stored in the first storage area and a game using the second media group information stored in the second storage area based on the player's operation, and in the subsequent period, being able to execute a game using the second media group information stored in the first storage area based on the player's operation, and not being able to execute a game using the first media group information; And In the subsequent period, storing, based on the player's operation, the second media group information stored in the second storage area in the preparatory period in the first storage area.

2. The information processing apparatus according to claim 1, the computer program, when executed by the computer, further implementing the following steps: Storing a plurality of function information, the plurality of function information including first function information and second function information, Wherein, In the first function information, the functions implemented by the game media corresponding to at least the first game condition are associated with the corresponding game media, and in the second function information, the functions implemented by the game media corresponding to at least the second game condition are associated with the corresponding game media, Wherein, the game progresses based on the function information, and The game media includes a specific game media, the specific game media corresponding to both the first game condition and the second game condition and being associated with functions different between the first function information and the second function information.

3. An information processing method, Comprising the following steps: Storing, in a storage unit, the game media owned by a player among a plurality of types of game media as owned game media in a manner associated with the player ID; In a preparatory time period before a specified time, first media group information for identifying a plurality of the game media corresponding to a first game condition selected from the owned game media based on a player's operation is stored in a first storage area, and in the preparatory time period, second media group information for identifying a plurality of the game media corresponding to a second game condition different from the first game condition is stored in a second storage area, and in a post time period after the specified time, the second media group information is stored in the first storage area based on the player's operation; In the preparatory time period, games using the first media group information stored in the first storage area and games using the second media group information stored in the second storage area can be executed based on the player's operation, and in the post time period, games using the second media group information stored in the first storage area can be executed based on the player's operation, and games using the first media group information cannot be executed in the post time period; And In the post time period, based on the player's operation, the second media group information stored in the second storage area in the preparatory time period is stored in the first storage area.

4. An information processing program product, which includes a computer program that, when executed by a computer, implements the following steps: Store the game media owned by the player among multiple types of game media as owned game media in a storage unit in a manner associated with the player ID; In a preparatory time period before a specified time, first media group information for identifying a plurality of the game media corresponding to a first game condition selected from the owned game media based on a player's operation is stored in a first storage area, and second media group information for identifying a plurality of the game media corresponding to a second game condition different from the first game condition is stored in a second storage area, and in a post time period after the specified time, the second media group information is stored in the first storage area based on the player's operation; In the preparatory time period, games using the first media group information stored in the first storage area and games using the second media group information stored in the second storage area can be executed based on the player's operation, and in the post time period, games using the second media group information stored in the first storage area can be executed based on the player's operation, and games using the first media group information cannot be executed in the post time period; And In the post time period, based on the player's operation, the second media group information stored in the second storage area in the preparatory time period is stored in the first storage area.

Images