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

Abstract

An object of the present invention is to reduce communication load or processing load when realizing a replay function. [Solution] An information processing program includes processing for executing a battle game including a plurality of turns based on a player's operation on either or both of a player terminal and a server that can communicate with the player terminal; A process of storing the first information in the server as the battle game is executed, a process of storing the second information in the player terminal as the battle game is executed, and the execution contents of the battle game after the battle game is executed. In the process of executing the replay function, if the second information of the battle game is not stored in the player terminal, the turn is executed based on at least the first information. A first replay function that cannot be specified is executed, and when second information of a battle game is stored in a player terminal, a second replay function that can specify a turn is executed based on at least the second information. [Selection diagram] Figure 26

Description

Article 30, Paragraph 2 of the Patent Act applies on June 15, 2020 https://www. youtube. com/@shadowverse_jp https://www. youtube. com/watch? v=dUDjyCn67hI Although the internal mechanism is not disclosed, the invention is disclosed as a readable summary of the invention June 21, 2020 https://twitter. com/shadowverse_jp https://twitter. com/shadowverse_jp/status/1671353495818207232 https://shadowverse. jp/news/ https://shadowverse. jp/news/? Announce_id = 2712 Although the internal mechanism is not disclosed, the invention is disclosed as a readable summary of the invention June 27, 2020 https://twitter. com/shadowverse_jp https://twitter. com/shadowverse_jp/status/1673617162718838784 Although the internal mechanism is not disclosed, the invention is disclosed as a readable summary of the invention on June 27, 2020 at https://shadowverse. jp https://apps. apple. com/jp/app/id1050059017? &mt=8 https://play. google. com/store/apps/details? id=jp. co. cygames. Shadowverse&hl=ja https://dmm. shadowverse. jp https://steam. shadowverse. jp https://store. steam powered. A game service implementing the system according to the present invention is released at com/app/453480/Shadowverse_CCG/

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

Patent Document 1 discloses a replay function that allows a player to review the play content after playing the game by storing the play content of the game.

Patent No. 6737558

When implementing the replay function as described above, there is a problem in that the communication load or processing load increases.

An object of the present invention is to provide an information processing system, an information processing method, and an information processing program that can reduce communication load or processing load when realizing a replay function.

In order to solve the above problems, the information processing program
Either or both of the player terminal and the server that can communicate with the player terminal,
A process of executing a battle game including multiple turns based on player operations;
a process of storing first information in the server as the battle game is executed;
a process of storing second information in the player terminal as the battle game is executed;
After the battle game is executed, a process of executing a replay function that reproduces the execution contents of the battle game;
carry out the
In the process of executing the replay function,
If the second information of the battle game is not stored in the player terminal, at least based on the first information, a first replay function in which a turn cannot be specified is executed;
When the second information of the battle game is stored in the player terminal, a second replay function is caused to specify a turn based on at least the second information.

The first information includes:
Operation information indicating the content of the player's operation in the battle game may be included.

The second information includes:
Turn start information indicating the situation at the start of each turn, result information indicating a play result based on the player's operation in each turn, and the operation information may be included.

In order to solve the above problems, the information processing method is
An information processing method performed by one or both of a player terminal and a server capable of communicating with the player terminal, the method comprising:
Either or both of the player terminal and the server,
A process of executing a battle game including multiple turns based on player operations;
a process of storing first information in the server as the battle game is executed;
a process of storing second information in the player terminal as the battle game is executed;
After the battle game is executed, a process of executing a replay function that reproduces the execution contents of the battle game;
carry out the
In the process of executing the replay function,
If the second information of the battle game is not stored in the player terminal, at least based on the first information, a first replay function that does not allow specifying a turn is executed;
If the second information of the battle game is stored in the player terminal, a second replay function is executed that allows a turn to be designated based on at least the second information.

In order to solve the above problems, the information processing system
comprising a player terminal and a server capable of communicating with the player terminal,
In either or both of the player terminal and the server,
A process of executing a battle game including multiple turns based on player operations;
a process of storing first information in the server as the battle game is executed;
a process of storing second information in the player terminal as the battle game is executed;
After the battle game is executed, a process of executing a replay function that reproduces the execution contents of the battle game;
carry out the
In the process of executing the replay function,
If the second information of the battle game is not stored in the player terminal, at least based on the first information, a first replay function that does not allow specifying a turn is executed;
When the second information of the battle game is stored in the player terminal, a second replay function is executed that allows a turn to be designated based on at least the second information.

According to the present invention, it is possible to reduce the communication load or processing load when realizing the replay function.

FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system. FIG. 2A is a diagram illustrating the hardware configuration of the player terminal. FIG. 2B is a diagram illustrating the hardware configuration of the server. FIG. 3A is a diagram showing an example of a home screen. FIG. 3B is a diagram illustrating an example of a card setting screen. FIG. 3C is a diagram illustrating an example of a deck selection screen. FIG. 3D is a diagram illustrating an example of a deck organization screen in an initial state. FIG. 4A is a diagram illustrating an example of a deck formation screen during formation. FIG. 4B is a diagram illustrating an example of a card list screen. FIG. 4C is a diagram illustrating an example of a card generation screen. FIG. 4D is a diagram illustrating an example of a card details screen. FIG. 5 is a diagram illustrating an example of a battle screen. FIG. 6A is a diagram illustrating an example of a follower card. FIG. 6B is a diagram illustrating an example of a spell card. FIG. 6C is a diagram illustrating an example of an amulet card. FIG. 7 is a diagram illustrating an example of the ability. FIG. 8A is a first diagram illustrating an example of a battle screen transition. FIG. 8B is a second diagram illustrating an example of the transition of the battle screen. FIG. 8C is a third diagram illustrating an example of the transition of the battle screen. FIG. 9A is a fourth diagram illustrating an example of the transition of the battle screen. FIG. 9B is a fifth diagram illustrating an example of the transition of the battle screen. FIG. 9C is a sixth diagram illustrating an example of the transition of the battle screen. FIG. 10A is a seventh diagram illustrating an example of a battle screen transition. FIG. 10B is an eighth diagram illustrating an example of the transition of the battle screen. FIG. 10C is a ninth diagram illustrating an example of the transition of the battle screen. FIG. 11A is a tenth diagram illustrating an example of the transition of the battle screen. FIG. 11B is an eleventh diagram illustrating an example of the transition of the battle screen. FIG. 12A is a first diagram illustrating an example of a battle screen during evolution. FIG. 12B is a second diagram illustrating an example of a battle screen during evolution. FIG. 13 is a diagram illustrating an example of first information and second information. FIG. 14A is a diagram illustrating an example of a replay selection screen. FIG. 14B illustrates an example of a guild screen. FIG. 15 is a diagram illustrating the first replay function and the second replay function. FIG. 16A is a first diagram illustrating the first replay function. FIG. 16B is a second diagram illustrating the first replay function. FIG. 16C is a third diagram illustrating the first replay function. FIG. 17A is a first diagram illustrating the second replay function. FIG. 17B is a second diagram illustrating the second replay function. FIG. 18A is a third diagram illustrating the second replay function. FIG. 18B is a fourth diagram illustrating the second replay function. FIG. 19A is a fifth diagram illustrating the second replay function. FIG. 19B is a sixth diagram illustrating the second replay function. FIG. 19C is a seventh diagram illustrating the second replay function. FIG. 20A is an eighth diagram illustrating the second replay function. FIG. 20B is a ninth diagram illustrating the second replay function. FIG. 20C is a tenth diagram illustrating the second replay function. FIG. 21 is a functional block diagram of the player terminal. FIG. 22 is a functional block diagram of the server. FIG. 23 is a flowchart illustrating an example of a terminal-side card battle game execution process. FIG. 24 is a flowchart illustrating an example of server-side card battle game execution processing. FIG. 25 is a flowchart illustrating an example of a replay selection screen display process. FIG. 26 is a flowchart illustrating an example of the first replay function execution process. FIG. 27 is a flowchart illustrating an example of the second replay function execution process.

One aspect of the embodiment of the present invention will be described in detail below with reference to the accompanying drawings. The dimensions, materials, and other specific numerical values shown in these embodiments are merely examples for easy understanding, and do not limit the present invention unless otherwise specified. In this specification and the drawings, elements with substantially the same functions and configurations are given the same reference numerals to omit redundant explanation, and elements not directly related to the present invention are omitted from illustration. do.

(Overall configuration of information processing system S)
FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system S. As shown in FIG. The information processing system S is a so-called client server system including a player terminal 1, a server 1000, and a communication network N having a communication base station Na.

Player terminal 1 can establish communication with server 1000 via communication network N. The player terminal 1 includes a wide range of electronic devices that can be connected to the server 1000 for wireless or wired communication. Examples of the player terminal 1 include a smartphone, a mobile phone, a tablet device, a personal computer, and a game device. In this embodiment, a case where a smartphone is used as the player terminal 1 will be described.

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

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

In the information processing system S of this embodiment, the player terminal 1 and the server 1000 function as a game device G. The player terminal 1 and the server 1000 are each assigned the role of controlling the progress of the game, and the game can progress through cooperation between the player terminal 1 and the server 1000.

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

Further, as shown in FIG. 2B, the server 1000 includes a CPU 1010, a storage section 1012, a bus 1014, an input/output interface 1016, a storage device 1018, a communication section 1020, an input section 1022, and an output section 1024.

Note that the configurations and functions of the CPU 1010, storage section 1012, bus 1014, input/output interface 1016, storage device 1018, communication section 1020, input section 1022, and output section 1024 of the server 1000 are the same as the CPU 10 and the storage section of the player terminal 1, respectively. 12, bus 14, input/output interface 16, storage device 18, communication section 20, input section 22, and output section 24. Therefore, below, the hardware configuration of the player terminal 1 will be explained, and the explanation of the server 1000 will be omitted.

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

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

The storage device 18 is composed of a semiconductor memory and stores various programs and data. In the player terminal 1, programs and data stored in the storage device 18 are loaded into the storage unit 12 by the CPU 10.

The communication unit 20 is wirelessly connected to the communication base station Na, and sends and receives information such as various data and programs to and from the server 1000 via the communication network N. In the player terminal 1, programs and the like received from the server 1000 are stored in the storage unit 12 or the storage device 18.

The input unit 22 includes, for example, a touch panel for inputting (receiving operations) a player's operations, buttons, a keyboard, a mouse, a cross key, an analog controller, and the like. Further, the input unit 22 may be a dedicated controller provided in the player terminal 1 or connected (externally attached) to the player terminal 1. Furthermore, the input unit 22 may be configured with an acceleration sensor that detects the tilt or movement of the player terminal 1, or a microphone that detects the player's voice. That is, the input unit 22 broadly includes devices that can input the player's intention in a discernible manner.

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

(Game content)
Next, the content of the game provided by the information processing system S (game device G) of this embodiment will be explained using an example. The game of this embodiment is a so-called digital card game. Players acquire and possess multiple types of digital cards (game media, hereinafter simply referred to as cards) provided by the operator through a lottery, etc., and use the cards they own to play against the computer or other players. You can play battle games. Below, the game content of this embodiment will be explained in detail.

FIG. 3A is a diagram showing an example of a home screen. FIG. 3B is a diagram illustrating an example of a card setting screen. FIG. 3C is a diagram illustrating an example of a deck selection screen. FIG. 3D is a diagram illustrating an example of a deck organization screen in an initial state. FIG. 4A is a diagram illustrating an example of a deck formation screen during formation. FIG. 4B is a diagram illustrating an example of a card list screen. FIG. 4C is a diagram illustrating an example of a card generation screen. FIG. 4D is a diagram illustrating an example of a card details screen.

When the application for this game is started on the player terminal 1, communication between the player terminal 1 and the server 1000 is started, a login state is established, and the game is started. When the game starts, various game screens are displayed on the touch panel 26 of the player terminal 1. In this embodiment, the game screen is roughly divided into a normal screen and a battle screen.

The normal screen is a screen mainly used by the player to make various settings and confirm information. On the other hand, the battle screen is a screen displayed on the touch panel 26 from the start to the end of the card battle game. Here, all screens other than the battle screen become normal screens. The normal screen includes a plurality of screens such as a home screen shown in FIG. 3A, a card setting screen shown in FIG. 3B, a shop screen (not shown), and a menu screen.

The home screen shown in FIG. 3A is the first screen displayed after login. As shown in FIG. 3A, a menu bar 30 is displayed at the bottom of the touch panel 26 on the home screen. The menu bar 30 is provided with a plurality of operation units that can be operated (tapped) by the player. The menu bar 30 includes a home screen selection operation section 30a labeled "Home," a solo play selection operation section 30b labeled "Solo Play," a multiplayer selection operation section 30c labeled "Battle," and a "Card." A card setting screen selection operation section 30d labeled "Shop", a shop screen selection operation section 30e labeled "Others", and a menu screen selection operation section 30f labeled "Others" are provided.

When the home screen selection operation section 30a is tapped, the home screen shown in FIG. 3A is displayed on the touch panel 26. Further, when the solo play selection operation section 30b is tapped, various setting screens are displayed, and when settings are made on the setting screen, a card battle game based on a computer battle is started. When the multiplayer selection operation section 30c is tapped, various setting screens are displayed, and when settings are made on the setting screen, a card battle game by communication battle with other players is started.

When the card setting screen selection operation section 30d is tapped, a card setting screen shown in FIG. 3B is displayed on the touch panel 26, and it is possible to organize a deck, display a list of cards, disassemble and generate cards, etc., which will be described later. Further, when the shop screen selection operation section 30e is tapped, a shop screen is displayed on the touch panel 26, and cards can be won by lottery by consuming in-game currency and items. Further, when the menu screen selection operation section 30f is tapped, a menu screen (not shown) is displayed on the touch panel 26, and game settings and various information can be confirmed. Further, a plurality of operation units are displayed on the menu screen (not shown). When a predetermined operation unit displayed on the menu screen (not shown) is operated, a replay selection screen (FIG. 14A), which will be described later, is displayed. This replay selection screen will be described later. Note that in the menu bar 30, the operation units corresponding to each screen are highlighted so that the screen currently displayed on the touch panel 26 can be identified.

A header display area 31 is provided at the upper left of the home screen shown in FIG. 3A. The header display area 31 displays the player name, player icon, and battle points (BP) associated with the player ID. Note that battle points can be earned when winning a card battle game played through communication with another player, and are deducted when losing a card battle game played through communication play against another player.

A home menu 32 is displayed at the right end of the home screen. The home menu 32 includes a gift screen selection operation section 32a labeled "Gift," an information screen selection operation section 32b labeled "Information," a mission screen selection operation section 32c labeled "Mission," and a "Guild" screen selection operation section 32c labeled "Mission." ” A guild screen selection operation section 32d is provided.

When the gift screen selection operation section 32a is tapped, a gift screen (not shown) displaying items distributed by the operator, for example, is displayed on the touch panel 26. Further, when the information screen selection operation section 32b is tapped, an information screen (not shown) that displays update information, maintenance information, etc. is displayed on the touch panel 26. Further, when the mission screen selection operation section 32c is tapped, a mission screen (not shown) displaying a preset mission is displayed on the touch panel 26. Further, when the guild screen selection operation section 32d is tapped, a guild screen (FIG. 14B) regarding a guild (group) made up of a plurality of players is displayed on the touch panel 26. The guild screen will be explained in detail later.

The card setting screen shown in FIG. 3B is displayed on the touch panel 26 by tapping the card setting screen selection operation section 30d. A deck organization tab 33a and a card list generation tab 33b are displayed on the card setting screen. When the deck organization tab 33a is tapped, a deck selection screen shown in FIG. 3C is displayed. A list of decks created by the player is displayed on the deck selection screen. The player can name the deck when assembling the deck. On the deck selection screen, the deck name is displayed on the icon corresponding to each deck.

Further, a deck creation tab 34 labeled "New Creation" is displayed on the deck selection screen. When the player taps the deck creation tab 34, a deck creation screen shown in FIG. 3D is displayed on the touch panel 26, and a new deck can be created.

On the deck composition screen, a plurality of blank columns are displayed in the upper row, and cards owned by the player (hereinafter referred to as owned cards) are displayed in the lower row. Then, on the deck composition screen, as shown in FIG. 4A, by sliding the owned cards displayed in the lower row to the upper row, the slid owned cards are arranged in the blank space in the upper row. In this way, on the deck composition screen, the cards placed in the upper row are provisionally registered.

Then, when the save tab 35 labeled "Save" provided on the deck organization screen is tapped, the deck information is stored. A deck ID is given to this deck information. In addition, card group information that allows identification of all temporarily registered owned cards is stored in association with the deck ID. Although not shown, when the save tab 35 is tapped, a screen for editing the deck name is displayed. When editing of the deck name is completed, the card group information is stored in association with the deck ID. Further, the deck name and the icon displayed on the deck selection screen or the like are stored in association with the deck ID.

Also, when an icon is tapped on the deck selection screen shown in FIG. 3C, a deck organization screen is displayed as shown in FIG. 4A. However, 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, by the player's operation, the card displayed in the upper row can be changed to the owned card displayed in the lower row.

Note that in the card battle game, a predetermined number of cards (for example, 40) are used. Therefore, on the deck composition screen, deck information including card group information for the specified number of cards is usually stored by tapping the save tab 35 after a specified number of owned cards are temporarily registered by the player's operation. That will happen. However, even if the number of temporarily registered cards is less than the specified number or exceeds the specified number, it is possible to save the deck information, but the deck information cannot be saved in the card battle game. cannot be used in

When the card list generation tab 33b is tapped on the card setting screen, a card list screen shown in FIG. 4B is displayed on the touch panel 26. In this card list screen, a possession card tab 36a, a generation mode tab 36b, and a possession coin display field 36c are provided at the bottom of the touch panel 26. The possession card tab 36a and the generation mode tab 36b are configured to accept tap operations from the player. The possession card tab 36a and the generation mode tab 36b are also displayed on the card generation screen, and when the possession card tab 36a is tapped, the card list screen shown in FIG. 4B is displayed, and when the generation mode tab 36b is tapped, the card list screen shown in FIG. 4B is displayed. , the card generation screen shown in FIG. 4C is displayed. On the other hand, the number of coins (the number of owned coins), which are in-game currency, owned by the player is displayed in the owned coin display field 36c.

As shown in FIG. 4B, the cards owned by the player and the number of cards owned are displayed on the card list screen. Note that cards that the player does not possess may be displayed on the card list screen. Furthermore, as shown in FIG. 4C, the card generation screen displays all provided cards, regardless of whether the player owns them or not. However, cards that the player owns are displayed in color, whereas cards that the player does not own are displayed in gray out (indicated by a broken line in FIG. 4C). This allows the player to easily identify whether or not the card is in his or her possession.

When each card is tapped on the card list screen and the card generation screen, a card details screen is displayed as shown in FIG. 4D. On the card details screen, various information related to the tapped card is displayed. Further, on the card details screen, a disassembly tab 37a and a generation tab 37b are provided. The number of earned coins is displayed on the decomposition tab 37a. When the disassembly tab 37a is tapped, the currently selected card is disassembled, and the player can earn the number of earned coins displayed on the disassembly tab 37a. Note that when a card is disassembled, the number of cards in possession decreases.

Further, the number of consumed coins is displayed on the generation tab 37b. When the generation tab 37b is tapped, the selected card can be generated by consuming the number of consumption coins displayed on the generation tab 37b. When a card is generated, the number of cards in possession increases. That is, by tapping the generation tab 37b, the player can exchange the coins he/she has for cards. Such a card generation function can be executed regardless of whether the player has a card or not. That is, the player can generate cards for both cards that the player owns and cards that the player does not own.

Note that the provided cards may include cards that can be generated and cards that cannot be generated, or all cards may be generated. Furthermore, a card may be included in which a time when generation is possible and a time when generation is not possible are set.

Further, as will be described in detail later, among the cards there are cards that can evolve during the card battle game. In this embodiment, "evolution" means that the card selected by the player is changed to another card. As a card evolves, its performance will be enhanced.

The card details screen is provided with a first button 37c and a second button 37d. On the card details screen of the evolvable card, the first button 37c is enabled. Although not shown, when the first button 37c is tapped, the details of the evolved card are displayed on the card details screen.

Note that the above card details screen is displayed both during the card battle game and outside the card battle game. During a card battle game, a card detail screen can be displayed not only for the player's own cards but also for the opponent's cards. Therefore, during the card battle game, the player can understand what kind of cards the opponent can evolve into.

Next, the card battle game will be explained. Below, after explaining the outline of the card battle game, details of the cards and details of the card battle game will be explained in order. Note that here, a card battle game in which players compete against other players will be explained. Further, in the following, another player who is an opponent will be referred to as an opponent.

FIG. 5 is a diagram illustrating an example of a battle screen. When the multiplayer selection operation section 30c of the menu bar 30 is tapped, various setting screens are displayed, and when settings are made on the setting screen, the card battle game is started. While the card battle game is being executed, a battle screen shown in FIG. 5 is displayed on the touch panel 26.

The battle screen is divided into a player display area 40a where the player's cards, information, etc. are displayed, and an opponent display area 40b where the opponent's cards, information, etc. are displayed. A player leader 41a is displayed at the bottom center of the player display area 40a. In addition, the physical strength 42a and evolution points 43a of the player leader 41a are displayed near the player leader 41a.

Similarly, the opponent's leader 41b is displayed in the upper center of the opponent display area 40b. Furthermore, the physical strength 42b and evolution points 43b of the opponent leader 41b are displayed near the opponent leader 41b. Note that the physical strength 42a of the player's leader 41a and the physical strength 42b of the opponent's leader 41b are set to 20 as initial values.

Further, in the player display area 40a, a player's deck area 44a is provided at the right end, a player's hand area 45a is provided at the lower right, and a player's field 46a is provided at the center. In the deck area 44a, cards of unused players are placed face down, that is, in an unidentifiable state. In the hand area 45a, cards in the player's hand are arranged so that they can be identified by the player. In the field 46a, cards etc. taken out from the hand area 45a are arranged so that they can be identified by the player.

Similarly, in the opponent display area 40b, the opponent's deck area 44b is provided at the right end, the opponent's hand area 45b is provided at the upper left, and the opponent's field 46b is provided at the center. The opponent's unused cards are placed face down in the deck area 44b. In the hand area 45b, the cards in the opponent's hand are arranged in such a way that they cannot be identified by the player, that is, they are placed face down. In the field 46b, cards etc. taken out from the hand area 45b are arranged so that they can be identified by the player.

At the upper right of the player display area 40a, a turn end button 47 that accepts a tap from the player and a play point display section 48a that displays the player's play points (PP) are provided. The play point display section 48a displays the maximum play point in the current turn as the denominator and the available play points as the numerator. Moreover, the maximum play point and the usable play point are displayed in the play point display section 48a in a manner that allows identification of the maximum play point and the usable play point. Furthermore, a play point display section 48b that displays the opponent's play points is provided near the leader 41b in the opponent display area 40b.

Furthermore, a battle log button 49 is provided at the left end of the battle screen. The battle log button 49 is provided so as to be able to accept tap operations from the player. When the battle log button 49 is tapped, a battle log indicating various events that have occurred during execution of the battle game since the battle log button 49 was tapped is displayed superimposed on the battle screen.

The card battle game in this embodiment is of a two-player type, and cards that become the player's hand are randomly distributed from a deck selected by the player. Similarly, the opponent's hand is randomly dealt a card from the deck selected by the opponent. Furthermore, in a card battle game, the player's turn and the opponent's turn are repeated alternately. Each turn, a randomly selected card from the deck is added to your hand.

During the player's turn, the player selects a follower card or amulet card, which will be described later, from among the cards placed in the player's hand area 45a and places it on the field 46a, according to predetermined rules, or uses a spell card to Activate a predetermined effect. In addition, in the following, follower cards or amulet cards placed in the hand areas 45a and 45b are placed on the field 46a and 46b, and spell cards placed in the hand areas 45a and 45b are used to activate a predetermined effect. The act of moving the cards placed in the hand areas 45a and 45b to another area is called "play."

In the card battle game, the player's leader 41a and the opponent's leader 41b have physical strength 42a and 42b, respectively, and the player who first reduces the opponent's physical strength 42a and 42b to 0 by attacking with cards, etc. wins. . Next, details of the cards used in the card battle game of this embodiment will be explained.

FIG. 6A is a diagram illustrating an example of a follower card. FIG. 6B is a diagram illustrating an example of a spell card. FIG. 6C is a diagram illustrating an example of an amulet card. Cards used in the card battle game of this embodiment are classified into one of the following card types: follower cards, spell cards, and amulet cards.

As shown in FIGS. 6A to 6C, a name 51, class 52, type 53, and cost 54 are set for each card, regardless of the card type. The name 51 is uniquely set for each card. That is, the name 51 can also be said to be a card name. A plurality of classes 52 are provided, and each card is classified into one of the classes. A plurality of types 53 are provided, and each card may be classified into one of the types or not classified into any type. The cost 54 indicates the play points required to play the card, and by consuming the play points equivalent to the cost, the card becomes playable.

The follower card shown in FIG. 6A is a card that can attack the opponent's leader 41b and the follower card placed on the opponent's field 46b in the card battle game. The follower card has a name 51, class 52, type 53, cost 54, ability 55, attack power 56, and physical strength 57. The attack power 56 indicates the amount of damage inflicted on the opponent's leader 41b targeted for attack or the follower card placed on the opponent's field 46b when the follower card attacks. When receiving damage, physical strength 57 decreases by the amount of damage received, and when it reaches 0, the follower card is destroyed. Note that the destroyed card is hidden from the field 46a and sent to a graveyard (not shown). However, unlike destruction, there is also a state in which the object is hidden from the field 46b, such as extinction, in which it is not sent to the graveyard.

Further, the follower card can evolve by consuming evolution points 43a and 43b. The evolved follower card has increased attack power 56 and physical strength 57, or has a predetermined ability 55 added to it. That is, by evolving a follower card, its performance (ability 55, attack power 56, physical strength 57) is enhanced.

The spell card shown in FIG. 6B has a name 51, a class 52, a type 53, a cost 54, and an ability 55. When a spell card is played, ability 55 (effect) is activated and the spell card is destroyed. That is, a spell card is a card that cannot be put into play 46a or 46b.

The amulet card shown in FIG. 6C has a name 51, a class 52, a type 53, a cost 54, and an ability 55. The amulet card is a card that, when played, remains in the field 46a and activates the ability 55.

FIG. 7 is a diagram illustrating an example of the ability 55. Note that the abilities 55 shown in FIG. 7 are just an example, and other abilities 55 may be provided, or some abilities 55 may not be provided. Further, although the explanation here assumes that the card is the player's card, the same applies to the opponent's card.

As shown in FIG. 7, the abilities 55 include fanfare, last word, protection, charge, sprint, special attack, drain, direct summon, evolution, fusion, and the like. Fanfare is an ability that activates the effect written after "Fanfare" when a card is put out from the hand area 45a to the field 46a (when the card is played). For example, in the example of the follower card shown in FIG. 6A, when the follower card is placed on the field 46a, the effect of "draw one card" is activated, and one card is drawn from among the cards placed in the deck area 44a. A card is determined by lottery, and the determined card is placed in the hand area 45a.

Last Word is an ability that activates the effect written after "Last Word" when a card is destroyed. Guardianship is an ability that, when a card with guardianship set is placed on the field 46a, makes it impossible for the opponent to attack cards other than the card with guardianship set. Charge is an ability that allows you to attack your opponent's follower card in the turn it is played on the field 46a.

Dash is an ability that allows you to attack your opponent's follower card and leader 41b in the turn it is put on the field 46a. Special ability is an ability that allows you to destroy your opponent's follower card, regardless of the physical strength of your opponent's follower card, if you attack and inflict damage on your opponent's follower card. Drain is an ability that, when a player deals damage to an opponent's follower card or leader 41b during a player's turn, recovers the physical strength 42a of one's own leader 41a by the amount of damage dealt.

Direct summoning is an ability in which a card is directly put out from the deck area 44a to the field 46a when a preset condition is met. When evolved is an ability that activates the effect listed after "when evolved" when a follower card evolves. Fusion is an ability that is given to a base card that is a fusion source, and is an ability that strengthens a card by fusing a card placed in the hand area 45a that meets preset conditions as a material card. . Note that in one card, a plurality of abilities 55 may be set overlappingly, or even one ability 55 may not be set.

In this embodiment, a deck is formed by combining follower cards, spell cards, and amulet cards, and a card battle game is played using the formed deck. Furthermore, in this embodiment, a replay function is provided that allows the player to review the content of the play after playing the card battle game. This replay function will be described in detail later. Below, details of the card battle game will be explained.

FIG. 8A is a first diagram illustrating an example of a battle screen transition. FIG. 8B is a second diagram illustrating an example of the transition of the battle screen. FIG. 8C is a third diagram illustrating an example of the transition of the battle screen. FIG. 9A is a fourth diagram illustrating an example of the transition of the battle screen. FIG. 9B is a fifth diagram illustrating an example of the transition of the battle screen. FIG. 9C is a sixth diagram illustrating an example of the transition of the battle screen. FIG. 10A is a seventh diagram illustrating an example of a battle screen transition. FIG. 10B is an eighth diagram illustrating an example of the transition of the battle screen. FIG. 10C is a ninth diagram illustrating an example of the transition of the battle screen. FIG. 11A is a tenth diagram illustrating an example of the transition of the battle screen. FIG. 11B is an eleventh diagram illustrating an example of the transition of the battle screen.

When the card battle game starts, initial information including deck information to be used and leader information indicating the player's leader is transmitted from the player terminal 1 to the server 1000. Note that initial information including deck information and leader information indicating the opponent's leader is also transmitted from the opponent's player terminal 1 to the server 1000. The server 1000 randomly determines who goes first and who goes second. Additionally, the server 1000 randomly assigns an index (for example, a number from 1 to 40) to all cards shown in the deck information. Furthermore, the server 1000 determines three initial candidate cards and three replacement candidate cards from among the cards shown in the deck information.

The server 1000 includes first-player and second-player information indicating whether the player plays first or second, index information indicating the index of the player's card, exchange information indicating the initial candidate card and exchange candidate card, and leader information indicating the leader. Basic information is set to be obtainable by the player terminal 1.

Upon acquiring the basic information, the player terminal 1 displays on the touch panel 26 whether the player is playing first or playing second, as shown in FIG. . Thereafter, the player terminal 1 arranges three initial candidate cards in the initial card display area 60 based on the exchange information included in the basic information, as shown in FIG. 8B. Furthermore, the player terminal 1 displays an exchange display area 61 on the touch panel 26 for arranging cards to be exchanged.

If there is a card that the player wants to exchange among the initial candidate cards, as shown in FIG. 8C, the player moves the card that he wants to exchange to the exchange display area 61 by a slide operation. Then, when the enter button 62 is tapped by the player, the player terminal 1 returns the cards moved to the exchange display area 61 to the deck area 44a, and removes the initial candidate cards that have not been exchanged and the initial candidate cards that have been exchanged. The number of replacement candidate cards is determined as initial cards. Then, the player terminal 1 stores operation information including initial card information indicating the determined initial card, and transmits it to the server 1000.

Note that the server 1000 also receives operation information including initial card information from the opponent player terminal 1. When the server 1000 receives operation information from both the player and the opponent, it sets the player's player terminal 1 so that the opponent's operation information can be acquired, and shows only the number of cards included in the opponent's initial card information. It is possible to obtain information on the number of sheets. Similarly, upon receiving initial card information from both the player and the opponent, the server 1000 sets the opponent's player terminal 1 so that the player's operation information can be acquired, and the server 1000 sets the opponent's player terminal 1 to be able to acquire the player's operation information, It is possible to obtain number information indicating only the number of sheets.

After acquiring and storing the opponent's operation information, the player terminal 1 displays a battle screen on the touch panel 26, as shown in FIG. 9A. At this time, the player terminal 1 places the determined initial card in the hand area 45a so that it can be identified. Furthermore, the player terminal 1 places three cards indistinguishably in the hand area 45b based on the acquired operation information of the opponent.

After that, if the player goes first, the player terminal 1 stores the turn start information. The turn start information includes information indicating all the situations displayed on the battle screen at the start of the player's turn. For example, the turn start information may include information that identifies the value displayed on the physical strength 42a, 42b at the start of the player's turn. Further, the turn start information may include information that identifies the values displayed on the evolution points 43a and 43b at the start of the player's turn. Further, the turn start information may include information that identifies the types of cards placed in the hand areas 45a, 45b at the start of the player's turn. Further, the turn start information may include information identifying the types of cards placed on the fields 46a and 46b at the start of the player's turn. Further, the turn start time information may include information that identifies the value displayed on the play point display sections 48a, 48b at the start of the player's turn.

Further, when the player's turn starts, the player terminal 1 displays an image labeled "YOUR TURN" indicating that it is the player's turn on the touch panel 26, as shown in FIG. 9B. Then, the player terminal 1 determines one index of the card in the deck area 44a by lottery. That is, here, the player terminal 1 draws one card from the deck area 44a. Then, the player terminal 1 places the cards determined by lottery in the hand area 45a, as shown in FIG. 9C. Furthermore, the player terminal 1 stores operation information including the card information and transmits it to the server 1000. Further, the player terminal 1 stores this card information as play result information.

Further, the player terminal 1 adds 1 to the play point and updates and displays the play point display section 48a (here, the play point is set to 1). Further, the player terminal 1 stores play point information indicating updated play points as play result information.

Thereafter, as shown in FIG. 10A, for example, based on the player's operation, a follower card with a cost of 1 is placed on the field 46a by a slide operation from among the cards placed in the hand area 45a. In this case, the player terminal 1 subtracts 1 from the play point and updates the play point display section 48a. Further, the player terminal 1 stores card information indicating the card played on the field 46a as play result information. Further, the player terminal 1 stores play point information indicating updated play points as play result information.

Here, if the follower card placed on the field 46a has the ability 55 and the activation condition is met, the player terminal 1 activates the ability 55 for which the activation condition is satisfied. Further, in this case, the player terminal 1 stores the ability 55 of the activated card and ability information indicating the result of activation of the ability 55 as play result information.

Furthermore, the player terminal 1 stores operation information including card information indicating the card played on the field 46a, and transmits it to the server 1000. Upon receiving the operation information, the server 1000 sets the received operation information in the other player's player terminal 1 so that it can be acquired. As a result, at the opponent's player terminal 1, the card indicated by the card information included in the operation information is placed on the opponent's field 46b. Furthermore, on the opponent's player terminal 1, the opponent's play point display section 48b is updated and displayed.

Thereafter, when the player taps the turn end button 47, the player terminal 1 transmits turn end information indicating that the turn has ended to the server 1000. In addition, in the player terminal 1, when a card whose ability 55 is activated under the condition that the turn ends is on the field 46a, 46b, the ability 55 of that card is activated. Further, in this case, the player terminal 1 stores the ability 55 of the activated card and ability information indicating the result of activation of the ability 55 as play result information.

Upon receiving the turn end information from the player terminal 1, the server 1000 ends the player's turn, sets turn start information for starting the opponent's turn, and causes the opponent player terminal 1 to start the turn.

Then, as shown in FIG. 10B, the player's player terminal 1 displays an image labeled "ENEMY TURN" on the touch panel 26, indicating that it is the opponent's turn. Thereafter, operation information including card information of the card determined by lottery at the opponent's player terminal 1 is transmitted to the server 1000. When the player terminal 1 receives and stores the operation information from the server 1000, it arranges the cards indistinguishably in the hand area 45b based on the number information included in the operation information, as shown in FIG. 10C.

Note that at the start of a turn, one card is normally decided by drawing lots, but only in the first turn of the second player, two cards are decided by drawing lots. Furthermore, the player terminal 1 adds 1 to the opponent's play point and updates the play point display section 48b.

Thereafter, when the opponent ends the turn without playing any cards in the hand area 45b and receives turn start information from the server 1000, the player terminal 1 derives and stores the turn start information. Further, when the player's turn starts, the player terminal 1 displays an image labeled "YOUR TURN" indicating that it is the player's turn on the touch panel 26, and then displays the image on the deck area 44a, as shown in FIG. 11A. One index of a certain card is determined by lottery. Then, the player terminal 1 places the cards determined by lottery in the hand area 45a. Furthermore, the player terminal 1 stores operation information including the card information and transmits it to the server 1000. Further, the player terminal 1 stores this card information as play result information.

Further, the player terminal 1 adds 1 to the play point and updates and displays the play point display section 48a (here, the play point is set to 2). Further, the player terminal 1 stores play point information indicating updated play points as play result information.

Then, as shown in FIG. 11B, assume that the player slides the follower card placed on the field 46a to the opponent's leader 41b. At this time, the player terminal 1 determines that the opponent's leader 41b has been attacked by the follower card, and reduces the physical strength 42b of the opponent's leader 41b by the attack power 56 of the follower card. The player terminal 1 also stores, as play result information, parameter information indicating the attacked follower card, the attacked follower card or leader 41b, and the value of the parameter that changed as a result of the attack.

Furthermore, the player terminal 1 stores operation information including attack information indicating the attacked follower card and the attacked follower card or leader 41b, and transmits it to the server 1000. Upon receiving the operation information including this attack information, the server 1000 stores the received operation information. Then, the server 1000 sets the opponent's player terminal 1 to be able to acquire operation information including this attack information.

Next, I will explain the evolution of follower cards. In the card battle game of this embodiment, the follower cards can be evolved by consuming the evolution points 43a and 43b on and after the fifth turn of the first player and the fourth turn and later of the second player. It should be noted that the evolution points 43a and 43b are given 2 points if the player goes first, and 3 points if the player goes second.

FIG. 12A is a first diagram illustrating an example of a battle screen during evolution. FIG. 12B is a second diagram illustrating an example of a battle screen during evolution. For example, as shown in FIG. 12A, assume that an unevolved follower card is placed on the field 46a on the fifth turn of the first player. At this time, when the follower card placed in the field 46a is tapped, a card details tab 63 is displayed on the touch panel 26.

The card details tab 63 displays the ability of the tapped card. Further, an evolution button 63a is displayed on the card details tab 63. Note that the evolution button 63a is displayed only on the card details tab 63 of the follower card, and the evolution button 63a is not displayed on the card details tab 63 of spell cards and amulet cards. The evolution button 63a functions as an operation unit that accepts a tap from the player when evolution is possible. Therefore, in this embodiment, only follower cards are set as evolvable cards. Furthermore, if the follower card tapped by the player can evolve, the card details tab 63 displays the ability before evolution and the ability after evolution.

When the evolution button 63a of the card details tab 63 is tapped, an evolution animation is displayed. In the evolution animation, after the card before evolution is displayed, an unillustrated animation image of the card changing is displayed. When the display of the evolution animation ends, the evolved card is displayed on the field 46a, as shown in FIG. 12B. The player terminal 1 stores card information indicating that the card has evolved and the type of the evolved card as play result information.

Further, when the evolved card is displayed on the field 46a, the evolution point 43a is subtracted and displayed. The player terminal 1 stores evolution point information indicating the value of the evolution point 43a after subtraction as play result information.

Also, increases the attack power 56 and physical strength 57 of the evolved card. The player terminal 1 stores card information indicating the increased attack power 56 and physical strength 57 of the card as play result information.

Also, for follower cards that have "evolve time" as an ability, that ability will be activated. The player terminal 1 stores ability information indicating the activated ability as play result information.

Furthermore, the player terminal 1 stores operation information including evolution information indicating evolved follower cards, and transmits it to the server 1000. When the server 1000 receives the operation information including this evolution information, it sets the other player's player terminal 1 to be able to acquire the operation information including this evolution information.

The other player's player terminal 1 can recognize that the card has evolved and the card after the evolution based on the acquired operation information. Then, the other player's player terminal 1 executes processing for updating various displays and parameters related to evolution as described above, based on the acquired operation information. In addition, the opponent player terminal 1 stores evolution information indicating various displays related to evolution and update contents of parameters as play result information.

As described above, the player's turn and the opponent's turn are repeated alternately, and each time the player and the opponent play, attack, or evolve a card, the operation information is transmitted to the server 1000. As a result, the card battle game progresses. Further, operation information and play result information are stored in the player's player terminal 1 and the opponent's player terminal 1 each time the player and the opponent play, attack, or evolve cards.

Then, when the physical strength 42a of the player's leader 41a or the physical strength 42b of the opponent's leader 41b becomes 0, the winner or loser is determined. When the winner or loser is determined, the player's player terminal 1 and the opponent's player terminal 1 transmit win/loss result information indicating that the winner or loser has been determined to the server 1000.

Upon receiving the win/loss result information, the server 1000 executes a check process to check whether the win/loss is correct based on the information received so far. If it is determined in the check process that the outcome is correct, the server 1000 generates first information based on the information received during the card battle game, and stores it in association with the player ID. Additionally, the server 1000 updates the list information stored in association with the player ID. The list information includes information indicating a list of card battle games whose execution has ended. Specifically, the list information includes information indicating the opponent's name (player name), the opponent's leader, the date and time of the match, and the winner or loser for each card battle game that has been completed.

Note that the list information may include up to 30 card battle games. In this case, if a new card battle game ends with the list information including 30 card battle games, the server 1000 stores information related to the card battle game with the oldest battle date and time included in the list information. You may delete it. At this time, the server 1000 may delete the first information corresponding to the deleted card game from the list information. This makes it possible to suppress the number of first pieces of information stored in the server 1000.

Furthermore, the player terminal 1 generates and stores second information based on the information stored during the card battle game. The player terminal 1 may delete the second information corresponding to the deleted card game from the list information. This makes it possible to suppress the number of second information stored in the player terminal 1.

FIG. 13 is a diagram illustrating an example of first information and second information. As shown in FIG. 13, the first information includes basic information, operation information, and win/loss information received from the player's player terminal 1 and the opponent's player terminal 1 during the progress of the card battle game. The operation information includes information in which all operations performed by either the player or the opponent player are arranged in chronological order during the progress of the card battle game.

Further, as shown in FIG. 13, the second information includes basic information, turn start information, operation information, play result information, and win/loss information that the player's player terminal 1 has stored during the course of the card battle game. included. The turn start information is provided for each player's turn, and includes information indicating all the situations displayed on the battle screen at the start of the player's turn. Further, the play result information is provided for each turn of the player, and includes information in which results resulting from each operation performed by either the player or the opponent player during each turn are arranged in chronological order.

As mentioned above, in this embodiment, a replay function is provided. By using the replay function, the player can review the content of the card battle game after playing the card battle game as described above. Furthermore, in this embodiment, two types of replay functions, a first replay function and a second replay function, are provided as replay functions.

The first replay function and the second replay function use different information when executing the replay function. Specifically, when the first replay function is executed, the player terminal 1 acquires first information from the server, and executes the replay function based on the acquired first information. Furthermore, when the second replay function is executed, the player terminal 1 executes the replay function based on the second information stored in itself. As will be described in detail later, the second replay function is different in that the player can specify a turn that he/she wishes to review, whereas the first replay function does not allow the player to specify a turn.

FIG. 14A is a diagram illustrating an example of a replay selection screen. When a predetermined operation unit displayed on a menu screen (not shown) is operated, the player terminal 1 acquires list information from the server 1000. Then, the player terminal 1 displays the replay selection screen shown in FIG. 14A on the touch panel 26 based on the acquired list information. As shown in FIG. 14A, an information display area 70 is displayed on the replay selection screen for each card battle game included in the list information. The information display area 70 displays the opponent's name (player name), opponent's leader, match date and time, and wins and losses based on the list information. Further, in the information display area 70, a replay operation section 70a is displayed.

When the replay operation section 70a is operated, a replay function is executed. Additionally, an additional display 70b indicating that the second replay function cannot be used as a replay function may be displayed in the information display area 70. The additional display 70b is displayed when the second information related to the card battle game is not stored in the player terminal 1. FIG. 14A shows a case where the second information is not stored in the player terminal 1 and the additional display 70b is displayed regarding the card battle game with player A.

For example, when the cache is cleared on the player terminal 1, the second information is cleared from the player terminal 1. In this case, the second information related to the card battle game is not stored in the player terminal 1. Further, when the player plays the card battle game on another terminal, the second information is stored on the other terminal, so the second information related to the card battle game is not stored on the player terminal 1. Further, even if the second information is not generated in the player terminal 1 for some reason, the second information related to the card battle game is not stored in the player terminal 1.

If the second information is stored for the selected card battle game, the player terminal 1 uses the second replay function based on the second information. Further, if the second information is not stored for the selected card battle game, the player terminal 1 acquires the first information corresponding to the selected card battle game from the server 1000. Then, the player terminal 1 uses the first replay function based on the acquired first information.

FIG. 14B is a diagram illustrating an example of a guild screen. As described above, in the game of this embodiment, a guild can be formed by a plurality of players. For example, when one player creates a guild, the server 1000 stores the player ID of the player who created the guild in association with the group ID of the guild. When another player performs an operation to join a guild, the group ID of the guild and the player ID of the player who performed the join operation are stored in association with each other. Note that the players who form the guild are referred to as guild members.

Various information can be shared between guild members using the guild screen shown in FIG. 14B. A display area 80 is displayed on the guild screen. At the bottom of the display area 80, there is a deck sharing operation section 80a marked with "Deck Sharing", a replay sharing operation section 80b marked with "Replay Sharing", a battle recruitment operation section 80c marked with "Competition Recruitment", and " A chat operation section 80d labeled "Chat" is provided.

When the deck sharing operation section 80a is tapped, the player can share the deck information he or she has created with the guild members. This allows guild members to view shared deck information.

Further, when the competition recruitment operation section 80c is tapped, the player can recruit opponents for the card battle game from among the guild members. This allows card battle games to be played between guild members.

Further, when the chat operation section 80d is tapped, characters (text information) can be posted by the player's operation. As shown in FIG. 14B, when a guild member belonging to the same guild displays a guild screen, the posted characters are displayed on the touch panel 26 of the player terminal 1 that displayed the guild screen.

Furthermore, when the replay sharing operation section 80b is tapped, the player can share the content of his or her card battle game play with other players. When the play content is shared, as shown in FIG. 14B, when a guild member belonging to the same guild displays the guild screen, a shared replay item 81 is displayed on the touch panel 26 of the player terminal 1 that displayed the guild screen. be done. The shared replay item 81 displays the names (player names) of both players who competed, the leaders of both players who competed, the date and time of the competition, and the outcome. Further, in the shared replay item 81, a replay operation section 81a is displayed.

When the replay operation section 81a is operated, a replay function is executed. In this embodiment, when the replay operation section 81a is operated, the first replay function is always used. When the replay operation section 81a is operated, the player terminal 1 acquires first information corresponding to the selected card battle game from the server 1000. Then, the player terminal 1 performs a replay using the first replay function based on the acquired first information. Below, the first replay function will be explained first, and then the second replay function will be explained.

FIG. 15 is a diagram illustrating the first replay function and the second replay function. When the first replay function is used, the player terminal 1 sequentially generates battle screens until just before the turn starts, based on the basic information and operation information included in the acquired first information. Then, the player terminal 1 causes the battle screen to change by sequentially displaying the generated battle screens.

Specifically, after the player terminal 1 generates a battle screen as shown in FIG. 15 based on the basic information, it sequentially reads out the operation information in chronological order and continues to display the battle screen until just before the start of the turn. They are generated sequentially. At this time, as shown in FIG. 15, a first operation section 90 and a second operation section 91 are provided at the upper right of the battle screen.

When the first operation unit 90 is tapped, the player terminal 1 temporarily stops the transition of the battle screen being executed. If the first operation unit 90 is tapped again during the pause, the player terminal 1 ends the pause and restarts the transition of the battle screen. Note that the first operation unit 90 is displayed in a manner that allows identification of whether the current state is paused or not.

The second operation unit 91 is an operation unit that can be tapped during a pause. When the second operation unit 91 is tapped during the pause, the player terminal 1 sequentially transitions the battle screen based on the operation information until immediately before the next operation by the player or the opponent player is executed. Then, after the player terminal 1 transitions the battle screen until just before the next operation by the player or the opponent player is executed, the player terminal 1 pauses the transition of the battle screen again. This makes it possible to suppress the possibility that the battle screen will continuously change one after another and the player will miss the battle screen.

FIG. 16A is a first diagram illustrating the first replay function. FIG. 16B is a second diagram illustrating the first replay function. FIG. 16C is a third diagram illustrating the first replay function. FIG. 16A shows the battle screen immediately before the start of the turn. As shown in FIG. 16A, when the battle screen immediately before the start of a turn is displayed, in addition to the first operation section 90 and the second operation section 91, a third operation section 92 is displayed. Thereafter, the player terminal 1 sequentially changes the battle screen until the end of the battle based on the basic information and operation information included in the first information.

Specifically, the player terminal 1 sequentially reads the operation information in chronological order, and performs various calculation processes including damage calculation etc. based on the read operation information. Then, the player terminal 1 sequentially generates battle screens based on the results of various calculation processes, and sequentially displays the generated battle screens as shown in FIGS. 16B and 16C.

If the various calculation processes described above are performed on the server 1000 side, there is a possibility that the number of times and frequency of communication between the server 1000 and the player terminal 1 will increase. In this embodiment, in the first replay function, the player terminal 1 is responsible for various calculation processes required to generate a battle screen each time the first replay function is executed. This makes it possible to suppress the possibility that the number and frequency of communications between the server 1000 and the player terminal 1 will increase. Furthermore, since there is no need to perform various calculation processes on the server 1000 side, the processing load on the server 1000 can be reduced. Furthermore, the data size of the operation information itself can be made relatively small. This makes it possible to suppress the possibility that the data size of the first information including operation information in the server 1000 becomes enormous.

When the third operation unit 92 is tapped, the player terminal 1 fast-forwards the battle screen transition. Furthermore, when the third operation unit 92 is tapped again during fast-forwarding, the player terminal 1 ends the fast-forwarding of the battle screen transition and performs the battle screen transition at the normal speed. Note that the third operation unit 92 is displayed in a manner that allows identification of whether the current state is fast forwarding or not.

In addition, in this embodiment, the battle screen transition is performed in fast forward, and when the player terminal 1 reaches just before the start of the player's next turn, the player terminal 1 forcibly ends the fast forward and returns the battle screen to normal speed. Perform the transition. Note that when the third operation unit 92 is tapped again in this state, the player terminal 1 fast-forwards the battle screen transition again. This makes it possible to suppress the possibility that the player will forget to cancel fast forwarding and miss the battle screen.

Additionally, if the battle log button 49 is tapped while using the first replay function, the player terminal 1 records various events that occurred in the battle game being reproduced after the battle log button 49 was tapped as a battle log. indicate.

Next, the second replay function will be explained. When the second replay function is used, the player terminal 1 displays the battle screen just before the start of the turn based on the basic information and play result information included in the acquired second information, and the turn start information. Transition sequentially until . Specifically, after the player terminal 1 generates a battle screen as shown in FIG. 15 based on the basic information, it sequentially reads play result information in chronological order, and displays the battle screen until just before the start of the turn. are transitioned sequentially. Even when the second replay function is used, the first operation section 90 and the second operation section 91 are provided at the upper right of the battle screen, and the contents displayed on the battle screen are different from those when the first replay function is used. It will be the same.

FIG. 17A is a first diagram illustrating the second replay function. FIG. 17B is a second diagram illustrating the second replay function. FIG. 18A is a third diagram illustrating the second replay function. FIG. 18B is a fourth diagram illustrating the second replay function. FIG. 19A is a fifth diagram illustrating the second replay function. FIG. 19B is a sixth diagram illustrating the second replay function. FIG. 19C is a seventh diagram illustrating the second replay function. FIG. 20A is an eighth diagram illustrating the second replay function. FIG. 20B is a ninth diagram illustrating the second replay function. FIG. 20C is a tenth diagram illustrating the second replay function.

FIG. 17A shows the battle screen immediately before the start of the turn. When reaching just before the start of the turn, the player terminal 1 displays a battle screen based on the turn start time information. As described above, the turn start information includes information indicating all the situations displayed on the battle screen at the start of the player's turn. Therefore, it is possible to generate a battle screen without requiring various calculation processes such as the first replay function.

Further, as shown in FIG. 17A, the first operation section 90 and the second operation section 91 are not displayed on the battle screen immediately before the start of the turn. As shown in FIG. 17A, in the second replay function, the first operation section 90a and the second operation section 91a are displayed at the upper left. The first operating section 90a and the second operating section 91a have substantially the same functions as the first operating section 90 and the second operating section 91. Thereafter, the player terminal 1 sequentially changes the battle screen until the end of the battle based on the basic information, turn start information, operation information, and play result information included in the second information.

Specifically, the player terminal 1 sequentially reads operation information and play result information in chronological order, and performs various calculation processes including damage calculation etc. based on the read operation information and play result information. 17B, FIG. 18A, and FIG. 18B, the generated battle screens are sequentially displayed.

Further, the second replay function includes a skip function in which the player specifies a turn that he or she wishes to review the play contents and changes the screen immediately before the start of the specified turn. As the operation units for using the skip function, a first skip operation unit 93, a second skip operation unit 94, and a third skip operation unit 95 are displayed at the upper left of the battle screen, as shown in FIG. 17A. .

The first skip operation section 93 displays the current number of turns. For example, in the case of FIGS. 17A and 17B, "1" is displayed as the current number of turns. Furthermore, in the case of FIGS. 18A and 18B, "2" is displayed as the current number of turns.

Further, when the first skip operation section 93 is tapped, a turn designation display 96 is displayed as shown in FIG. 19A. The turn designation display 96 displays a plurality of operation sections 96a in which transition destination turns are written. The player can make a transition to an arbitrary turn by tapping the operation section 96a.

For example, as shown in FIG. 19A, when the current turn is 2 turns, it is assumed that the operation section 96a labeled "1 turn" is tapped and 1 turn is designated as the transition destination. In this case, based on the tap on the operation unit 96a, as shown in FIG. 19B, a transition image with "SKIPPING" written on the entire surface of the battle screen is displayed for a predetermined period of time.

When the display of the transition image is finished, as shown in FIG. 19C, the player terminal 1 displays a battle screen based on the turn start information corresponding to the transition destination turn.

Further, the second skip operation unit 94 can specify the previous turn as the transition destination turn. Note that when there is no previous turn, such as when the current turn is the first turn, the second skip operation section 94 is displayed in an inoperable manner as shown in FIG. 19C.

For example, as shown in FIG. 20A, when the current turn is turn 2, it is assumed that the second skip operation section 94 is tapped and the previous turn, that is, the first turn, is designated as the transition destination. In this case, based on the tap of the second skip operation unit 94, as shown in FIG. 20B, a transitioning image with "SKIPPING" written on the entire surface of the battle screen is displayed for a predetermined period of time.

When the display of the transition image is finished, as shown in FIG. 20C, the player terminal 1 displays a battle screen based on the turn start information corresponding to the transition destination turn.

Further, the third skip operation unit 95 can specify the next turn as the transition destination turn. Note that if the current turn is the final turn and there is no next turn, the third skip operation section 95 is displayed in an inoperable manner.

Assume that the third skip operation section 95 is tapped and the next turn after the turn is specified as the transition destination. In this case, based on the tap of the second skip operation unit 94, as shown in FIG. 20B, a transitioning image with "SKIPPING" written on the entire surface of the battle screen is displayed for a predetermined period of time. Then, when the display of the transitioning image ends, the player terminal 1 displays a battle screen based on the turn start time information corresponding to the transition destination turn.

In addition, as described above, in the first replay function, when the battle screen is transitioning in fast forward and the player terminal 1 reaches the point just before the start of the player's next turn, the player terminal 1 forcibly ends the fast forward. do. On the other hand, in the second replay function, even if the battle screen is transitioning in fast forward and the player terminal 1 reaches the point just before the start of the player's next turn, the player terminal 1 does not forcibly end the fast forward. , Continue fast forwarding to transition between battle screens. In the second replay function, even if the player misses the battle screen due to fast forwarding, by using the skip function, it is possible to display the missed battle screen again. This makes it possible to improve the player's convenience.

For example, if you try to reproduce the battle screen at the start of a turn based on operation information, it will be necessary to reproduce all events from the current turn to the specified turn, which increases the processing load on the player terminal 1. There is a risk that it will increase. Also, if the specified turn is earlier than the current turn, if you try to reproduce the battle screen at the start of the specified turn, all events from the start of the card battle game to the specified turn will be displayed. , and the processing load on the player terminal 1 may increase. If the processing load on the player terminal 1 increases, the time it takes until the battle screen for a designated turn is displayed becomes longer, which may actually impair the player's convenience.

The second replay function uses turn start information that includes information showing all the situations displayed on the battle screen at the start of the player's turn, regardless of the turn the transition destination is. , it becomes possible to easily generate battle screens. Therefore, it is possible to suppress the possibility that the processing load on the player terminal 1 will increase. Thereby, it is possible to reduce the possibility that the time until the battle screen of a designated turn is displayed becomes long, and it is possible to improve convenience for the player.

Furthermore, with the second replay function, it is possible to generate a battle screen based on the second information stored in the player terminal 1. Therefore, it is possible to suppress the possibility that the number and frequency of communications between the server 1000 and the player terminal 1 will increase. Furthermore, the processing load on the server 1000 can be reduced. Furthermore, since the second information is stored only in the player terminal 1, it is possible to suppress the possibility that the amount of data stored in the server 1000 will increase.

Furthermore, in the first replay function described above, when the battle log button 49 is tapped, various events that occur in the battle game being reproduced after the battle log button 49 is tapped are displayed as a battle log. On the other hand, in the second replay function, when the battle log button 49 is tapped, various events that occurred in the battle game before the battle log button 49 was tapped, and after the battle log button 49 was tapped, Various events occurring in the battle game being reproduced are generated based on operation information and play result information and displayed as a battle log. This makes it possible to increase the amount of information in the battle log that is displayed immediately after the player taps the battle log button 49, making it possible to improve the player's convenience.

Below, the processes of the player terminal 1 and the server 1000 for realizing the above-described card battle game and replay function, and the functional units that perform these processes will be explained. Note that, below, processing related to realizing the replay function will be particularly explained, and explanation of other processing will be omitted.

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

The terminal side game control program includes a game execution control program 300, a card battle game execution control program 301, a display control program 302, a first replay control program 303, and a second replay control program 304. Note that the programs listed in FIG. 21 are just examples, and the terminal-side game control program includes many other programs.

The CPU 10 operates each program stored in the program storage area 12a and updates data in each storage section of the data storage area 12b. Then, the CPU 10 causes the player terminal 1 (computer) to function as the terminal control unit 1A by operating each program stored in the program storage area 12a. The terminal control section 1A includes a game execution control section 300a, a card battle game execution control section 301a, a display control section 302a, a first replay control section 303a, and a second replay control section 304a.

Specifically, the CPU 10 operates the game execution control program 300 to cause the computer to function as the game execution control section 300a. Similarly, the CPU 10 operates a card battle game execution control program 301, a display control program 302, a first replay control program 303, and a second replay control program 304, respectively. It functions as a first replay control section 303a and a second replay control section 304a.

The data storage area 12b is provided with a game information storage section 400, a player information storage section 401, a first information storage section 402, and a second information storage section 403 as storage sections for storing data. Note that each of the storage units described above is an example, and the data storage area 12b is provided with many other storage units.

The game execution control unit 300a controls the progress of the entire game. The game execution control unit 300a, for example, logs into the game in response to a player's operation, or determines whether the game information for the entire game has been updated.

The card battle game execution control unit 301a is in charge of control for executing the card battle game. For example, the card battle game execution control unit 301a controls the progress of the card battle game based on operations input to the player terminal 1.

The display control unit 302a controls the display of images displayed on the touch panel 26 according to the player's operations and the progress of the game.

The first replay control unit 303a is in charge of control for realizing the first replay function. For example, the first replay control unit 303a controls execution of the first replay function based on an operation input to the player terminal 1.

The second replay control unit 304a is in charge of control for realizing the second replay function. For example, the second replay control unit 304a controls execution of the second replay function based on an operation input to the player terminal 1.

(Functional part of server 1000)
FIG. 22 is a functional block diagram of the server 1000. The storage unit 1012 of the server 1000 is provided with a program storage area 1012a and a data storage area 1012b. The program storage area 1012a stores a game execution control program 1300 and a card battle game execution control program 1301 as server-side game control programs. Note that the programs listed in FIG. 22 are just examples, and the server-side game control program includes many other programs.

The CPU 1010 operates each program stored in the program storage area 1012a and updates the data in each storage section of the data storage area 1012b. Then, the CPU 1010 causes the server 1000 (computer) to function as the server control unit 1000A by operating each program stored in the program storage area 1012a. The server control unit 1000A includes a game execution control unit 1300a and a card battle game execution control unit 1301a.

Specifically, the CPU 1010 operates the game execution control program 1300 to cause the computer to function as the game execution control section 1300a. Similarly, the CPU 1010 operates a card battle game execution control program 1301 to function as a card battle game execution control section 1301a.

The data storage area 1012b is provided with a game information storage section 1400, a player information storage section 1401, and a first information storage section 1402 as storage sections for storing data. Note that each of the storage units described above is an example, and the data storage area 1012b is provided with many other storage units.

The game execution control unit 1300a controls the progress of the entire game. For example, upon receiving the login information from the player terminal 1, the game execution control unit 1300a sets the player information (deck information, BP, etc.) stored in the player information storage unit 1401 so that the player terminal 1 can acquire it. Furthermore, when the game information for the entire game is updated, the game execution control unit 1300a reads the updated game information from the game information storage unit 1400 and sets it so that the player terminal 1 can acquire it.

The card battle game execution control unit 1301a is in charge of control for executing the card battle game.

(Communication processing between player terminal 1 and server 1000)
Below, basic processing of the player terminal 1 and the server 1000 will be explained. In the following description, the processing performed at the player terminal 1 will be referred to as Pn (n is an arbitrary integer). Further, the processing performed in the server 1000 is denoted by Sn (n is an arbitrary integer).

FIG. 23 is a flowchart illustrating an example of a terminal-side card battle game execution process. When the solo play selection operation section 30b or multiplay selection operation section 30c of the menu bar 30 is tapped, various setting screens are displayed, and when settings are made on the setting screen, the terminal side card battle game execution process is started.

When the card battle game execution process is started, the card battle game execution control unit 301a transmits initial information including deck information used in the card battle game and leader information indicating the player's leader to the server 1000 (P1 -1). When the server 1000 receives initial information from both the player and the opponent, it sets basic information including first and second attack information, index information, exchange information, and leader information so that the player and the opponent's player terminals 1 can acquire them. be done.

When the basic information is set in the server 1000, the card battle game execution control unit 301a acquires the basic information from the server 1000 and stores it in the second information storage unit 403 (P1-3).

The card battle game execution control unit 301a and display control unit 302a execute turn start pre-processing based on the basic information stored in step P1-3 above (P1-5). In the turn start pre-processing, the card battle game execution control unit 301a and the display control unit 302a execute various processes for displaying the battle screens shown in FIGS. 8A, 8B, 8C, and 9A.

Thereafter, the card battle game execution control unit 301a determines whether it is the player's turn based on the first-player-second-player information or the turn start information transmitted from the server 1000 (P1-7). Then, if it is the player's turn (YES in P1-7), the card battle game execution control unit 301a moves the process to step P1-9. On the other hand, if it is not the player's turn, that is, it is the opponent's turn (NO in P1-7), the card battle game execution control unit 301a moves the process to step P1-27.

The card battle game execution control unit 301a stores turn start information in the second information storage unit 403 (P1-9). As described above, the turn start information includes information indicating all the situations displayed on the battle screen at the start of the player's turn.

The card battle game execution control unit 301a and the display control unit 302a execute a process at the start of the player's turn in response to the start of the player's turn (P1-11). In the own turn start process, as shown in FIG. 9B, an image labeled "YOUR TURN" indicating that it is the player's turn is displayed on the touch panel 26.

Further, the card battle game execution control unit 301a and the display control unit 302a execute a control process during the player's turn to control the progress of the game during the player's turn (P1-13). For example, in the control process during the own turn, the card battle game execution control unit 301a executes various lottery processes, various calculation processes including damage calculation, parameter update process, etc., and controls the progress of the game. In addition, the display control unit 302a controls various effects on the battle screen during the player's turn based on the results of various lottery operations, various calculation processes including damage calculation, parameter update processes, etc., performed by the card battle game execution control unit 301a. Execute.

Further, the card battle game execution control unit 301a stores operation information resulting from the player's operations during the player's turn in the second information storage unit 403, and transmits it to the server 1000 (P1-15). The operation information includes the above-mentioned card information, attack information, evolution information, and the like.

Further, the card battle game execution control unit 301a stores play result information generated based on the result of the game progress during the player's turn in the above step P1-13 in the second information storage unit 403 (P1-17 ). The play result information includes the above-mentioned card information, play point information, ability information, parameter information, evolution point information, evolution information, and the like.

The card battle game execution control unit 301a determines whether the player's turn has ended in response to the player's operation of the turn end button 47 (P1-19). Then, the card battle game execution control unit 301a moves the process to P1-13 if the player's turn has not ended (NO in P1-19), and if the player's turn has ended (YES in P1-19). , executes turn end processing (P1-21).

Further, the card battle game execution control unit 301a transmits turn end information indicating that the player's turn has ended to the server 1000 (P1-23).

Further, the card battle game execution control unit 301a determines whether the physical strength 42a of the player's leader 41a or the physical strength 42b of the opponent's leader 41b has become 0, and the winner or loser has been determined (P1-25). If the winner or loser is determined (YES at P1-25), the card battle game execution control unit 301a moves the process to step P1-39. If the winner or loser has not been determined (NO in P1-25), the card battle game execution control unit 301a moves the process to step P1-7.

The card battle game execution control section 301a and the display control section 302a execute the opponent's turn start process in response to the start of the opponent's turn (P1-27). In the process at the start of the opponent's turn, as shown in FIG. 10B, an image labeled "ENEMY TURN" indicating that it is the player's turn is displayed on the touch panel 26.

Further, the card battle game execution control unit 301a obtains operation information resulting from the opponent's operation during the opponent's turn from the server 1000, and stores it in the second information storage unit 403 (P1-29).

Furthermore, the card battle game execution control unit 301a and the display control unit 302a execute an opponent's turn control process to control the progress of the game during the opponent's turn based on the operation information acquired in step P1-29. P1-31). For example, in the control process during the opponent's turn, the card battle game execution control unit 301a executes various lottery processes, various calculation processes including damage calculation, parameter update process, etc. based on the operation information, and controls the progress of the game. do. The display control unit 302a also controls various effects on the battle screen during the opponent's turn based on the results of various lottery operations, various calculation processes including damage calculation, parameter update processes, etc., performed by the card battle game execution control unit 301a. Execute.

Further, the card battle game execution control unit 301a stores play result information generated based on the result of the game progress during the opponent's turn in step P1-31 in the second information storage unit 403 (P1-33 ).

The card battle game execution control unit 301a determines whether turn end information indicating that the opponent's turn has ended has been obtained from the server 1000 (P1-35). Then, when the turn end information is acquired (YES at P1-35), the card battle game execution control section 71a executes the opponent's turn end processing (P1-37). Further, if the turn end information has not been acquired (NO in P1-35), the card battle game execution control unit 71a moves the process to step P1-29.

The card battle game execution control section 301a stores win/loss information indicating that the winner has been determined in the second information storage section 403, and transmits it to the server 1000 (P1-39).

The card battle game execution control unit 301a also generates second information based on the basic information, turn start information, operation information, play result information, and win/loss information stored in the second information storage unit 403 during the card battle game. It is generated and stored in the second information storage unit 403 (P1-41).

Then, the card battle game execution control unit 301a executes a card battle game end process to end the card battle game (P1-43), and ends the terminal side card battle game execution process.

FIG. 24 is a flowchart illustrating an example of server-side card battle game execution processing. When the card battle game execution control unit 1301a of the server 1000 receives initial information from both the player and the opponent (YES in S1-1), the card battle game execution control unit 1301a receives the initial information from both the player and the opponent (YES in S1-1), and receives the initial information including the first-player-last-player information, index information, exchange information, and leader information. Basic information is generated and stored in the first information storage unit 1402 so that both the player and the opponent can obtain it (S1-3).

Further, when the card battle game execution control unit 1301a receives operation information from either the player or the opponent (YES in S1-5), the card battle game execution control unit 1301a stores the received operation information in the first information storage unit 1402, and the card battle game execution control unit 1301a stores the received operation information in the first information storage unit 1402, and The information is made available for acquisition (S1-7).

Further, when the card battle game execution control unit 1301a receives turn end information from either the player or the opponent (YES in S1-9), the card battle game execution control unit 1301a stores the received turn end information in the first information storage unit 1402, and The other party can obtain it (S1-11). Further, the card battle game execution control unit 1301a generates turn start information, stores it in the first information storage unit 1402, and makes it available for both the player and the opponent (S1-13).

Further, when winning/losing information is received from both the player and the opponent (YES in S1-15), the card battle game execution control unit 1301a stores the received winning/losing information in the first information storage unit 1402 (S1-17). . Furthermore, the card battle game execution control unit 1301a executes a check process to check whether the outcome is correct based on the information received so far (S1-19).

Further, the card battle game execution control unit 1301a generates first information based on the basic information, operation information, and win/loss information stored in the first information storage unit 1402 during the card battle game, and generates first information in the first information storage unit 1402. (S1-21).

The card battle game execution control unit 1301a updates the list information stored in the first information storage unit 1402 in association with the player ID (S1-23). The list information includes information indicating the opponent's name (player name), the opponent's leader, the date and time of the match, and the winner or loser for each card battle game that has been completed.

FIG. 25 is a flowchart illustrating an example of a replay selection screen display process. When a predetermined operation unit displayed on the menu screen (not shown) is operated (YES in P2-1), the game execution control unit 300a acquires list information from the server 1000 (P2-3).

The game execution control unit 300a also checks the second information stored in the second information storage unit 403 (P2-5).

The display control unit 302a displays the replay selection screen shown in FIG. 14A based on the list information and the second information (P2-7). At this time, the display control unit 302a displays the additional display 70b when the second information is not stored in the second information storage unit 403 regarding the card battle game included in the list information. Furthermore, when the player performs a scroll operation on the replay selection screen, the display control unit 302a updates the display content of the replay selection screen.

The game execution control unit 300a also determines whether a replay start operation based on the operation of the replay operation unit 70a shown in FIG. 14A or the operation of the replay operation unit 81a shown in FIG. 14B has been detected (P2-9 ). If a replay start operation is detected (YES in P2-9), the game execution control unit 300a moves the process to step P2-11. If the replay start operation is not detected (NO in P2-9), the game execution control unit 300a moves the process to step P2-7.

The game execution control unit 300a determines whether or not to execute the first replay function based on the replay start operation (P2-11). Specifically, the game execution control unit 300a determines to use the first replay function when the second information is not stored for the card battle game selected by operating the replay operation unit 70a. . Moreover, the game execution control unit 300a determines to use the second replay function when the second information is stored for the card battle game selected by operating the replay operation unit 70a. Further, the game execution control unit 300a determines to use the first replay function when the replay operation unit 81a is operated.

When executing the first replay function (YES in P2-11), the first replay control unit 303a acquires the first information corresponding to the selected card battle game from the server 1000 (P2-13), and A first replay function execution process is executed based on the first information obtained (P3). The first replay function execution process will be described in detail later.

Further, when executing the second replay function (NO in P2-11), the second replay control unit 304a executes the second replay function execution process based on the second information stored in the second information storage unit 403. Execute (P4). The second replay function execution process will be described in detail later.

FIG. 26 is a flowchart illustrating an example of the first replay function execution process. The first replay control unit 303a sequentially reads the acquired first information in chronological order (P3-1), and performs various calculation processes including damage calculation etc. based on the read first information (P3-1). P3-3). Then, the first replay control unit 303a sequentially generates battle screens based on the results of various calculation processes (P3-5).

The display control unit 302a executes playback-related processing to sequentially display the battle screens generated in step P3-5 (P3-7). At this time, the display control section 302a performs temporary stop or fast forwarding depending on the operation status of the first operation section 90, the second operation section 91, and the third operation section 92.

The first replay control unit 303a determines whether the transition of the battle screen has reached the end of the battle (P3-9). As a result, if the transition of the battle screen reaches the end of the battle (YES in P3-9), the first replay control unit 303a executes the first replay function ending process to end the first replay function (P3-11). ).

Further, if the transition of the battle screen has not reached the end of the battle (NO in P3-9), the first replay control unit 303a moves the process to step P3-1 described above.

FIG. 27 is a flowchart illustrating an example of the second replay function execution process. The second replay control unit 304a and the display control unit 302a sequentially read the second information stored in the second information storage unit 403 in chronological order (P4-1), and based on the read second information Then, battle screens are sequentially generated without performing various calculation processes including damage calculation etc. (P4-3).

Specifically, at the start of a player's turn, a battle screen is generated based on turn start information corresponding to the started turn. Thereafter, a battle screen reflecting the operation contents of the player or the opponent is generated based on the operation information until the time immediately before the start of the player's next turn is reached. Furthermore, based on the result information, the results of destruction of cards, updates of various parameters, etc. that occur based on the player's or opponent's operations are grasped, and a battle screen is generated based on the results of the player's or opponent's operations.

The display control unit 302a executes playback-related processing to sequentially display the battle screens generated in step P4-3 (P4-5). At this time, the display control unit 302a controls pause or fast forward depending on the operation status of the first operation unit 90, first operation unit 90a, second operation unit 91, second operation unit 91a, and third operation unit 92. conduct.

The second replay control unit 304a determines whether a skip operation based on the operation of any of the second skip operation unit 94, the third skip operation unit 95, and the operation unit 96a of the turn designation display 96 is detected. (P4-7). If a skip operation is detected (YES at P4-7), the display control unit 302a executes a pause process (P4-9).

Further, the second replay control unit 304a executes a transition destination determination process to determine a transition destination based on the detected skip operation (P4-11). For example, when the operation unit 96a of the turn designation display 96 is operated, the second replay control unit 304a determines the turn designated by the player as the transition destination. Further, when the second skip operation section 94 is operated, the second replay control section 304a determines the previous turn as the transition destination. Further, when the third skip operation section 95 is operated, the second replay control section 304a determines the next turn as the transition destination.

The display control unit 302a executes a line image display process to display a transition image on the entire battle screen for a predetermined period of time (P4-13).

Furthermore, when the display of the transitioning image is finished, the display control unit 302a displays a battle screen based on the turn start information corresponding to the transition destination turn (P4-15), and performs the process in step P4-15 above. move.

If a skip operation is not detected (NO in P4-7), the second replay control unit 304a determines whether the transition of the battle screen has reached the end of the battle (P4-17). As a result, if the transition of the battle screen reaches the end of the battle (YES in P4-17), the second replay control unit 304a executes a second replay function termination process to terminate the second replay function (P4-19). ).

Further, if the transition of the battle screen has not reached the end of the battle (NO in P4-17), the second replay control unit 304a moves the process to step P4-1 described above.

As described above, the player terminal 1 is provided with the game execution control program 300, the card battle game execution control program 301, the display control program 302, the first replay control program 303, and the second replay control program 304. Furthermore, the player terminal 1 includes a game execution control section 300a, a card battle game execution control section 301a, a display control section 302a, a first replay control section 303a, and a second replay control section 304a. However, some or all of these programs and functional units may be provided in the server 1000. That is, these programs and functional units may be provided in one or both of the player terminal 1 and the server 1000.

Further, the server 1000 is provided with a game execution control program 1300 and a card battle game execution control program 1301. Furthermore, the server 1000 includes a game execution control section 1300a and a card battle game execution control section 1301a. However, some or all of these programs and functional units may be provided in the player terminal 1. That is, these programs and functional units may be provided in one or both of the player terminal 1 and the server 1000.

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

Although the above embodiment has been described using a digital card game as an example, the genre and content of the game, such as a simulation game, are not particularly limited. In any case, any competitive game using game media may be used, and the opponent is not limited to a person but may be a computer. Therefore, the game medium is not limited to a digital card, and may be any game medium provided in a game, such as a character, a unit, a piece, or the like.

Note that in the above embodiment, the information processing system S, which is a client server system, performs each of the above information processes. However, the functions of the server 1000 in the above embodiment may be provided in the player terminal 1. Further, the functions of the player terminal 1 in the above embodiment may be provided in the server 1000. Further, the communication function is not essential, and, for example, the game device G may be capable of playing against a computer or playing against a plurality of players. In any case, the information processing program preferably causes the computer to perform the following processing.

(Processing performed by a computer)
A process of executing a battle game (card battle game) including multiple turns based on a player's operation (in the above embodiment, as an example, steps P1-1 to P1-39, steps S1-1 to S1-15) ).
A process of storing the first information in the server 1000 as the battle game is executed (in the above embodiment, as an example, S1-17).
A process of storing the second information in the player terminal 1 along with the execution of the battle game (in the above embodiment, as an example, step P1-41).
After the battle game is executed, a process of executing a replay function (first replay function or second replay function) for reproducing the execution content of the battle game (in the above embodiment, as an example, step P3 and step P4).
In the process of executing the replay function, if the second information of the battle game is not stored in the player terminal 1, the first replay function in which a turn cannot be specified is executed based on at least the first information (in the above embodiment, , as an example, step P3).
In the process of executing the replay function, if the second information of the battle game is stored in the player terminal 1, the second replay function that can specify a turn is executed based on at least the second information (in the above embodiment, , as an example, step P4).

Further, the first information may include operation information indicating the content of the player's operation in the battle game.

Further, the second information may include turn start information indicating the situation at the start of each turn, result information indicating the play result based on the player's operation in each turn, and operation information.

Moreover, the control processing shown in the above embodiment is only an example. In the above embodiment, a case has been described in which the control processing for executing the game is executed by the player terminal 1. That is, in the embodiment described above, the control process for executing the game is executed only by the player terminal 1. In this case, only the player terminal 1 functions as the game device G. However, a part of the control processing described above may be executed by the server 1000. That is, the information processing system S, which is a client server system including the player terminal 1 and the server 1000, may function as the game device G.

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

1 Player terminal 1000 Server S Information processing system

Claims (5)

Either or both of the player terminal and the server that can communicate with the player terminal,
A process of executing a battle game including multiple turns based on player operations;
a process of storing first information in the server as the battle game is executed;
a process of storing second information in the player terminal as the battle game is executed;
After the battle game is executed, a process of executing a replay function that reproduces the execution contents of the battle game;
carry out the
In the process of executing the replay function,
If the second information of the battle game is not stored in the player terminal, at least based on the first information, a first replay function that does not allow specifying a turn is executed;
When the second information of the battle game is stored in the player terminal, at least based on the second information, a second replay function that can specify a turn is executed;
Information processing program. The first information includes:
operation information indicating the contents of the player's operation in the battle game is included;
The information processing program according to claim 1. The second information includes:
Turn start information indicating the situation at the start of each turn, result information indicating the play result based on the player's operation in each turn, and the operation information.
The information processing program according to claim 2. An information processing method performed by one or both of a player terminal and a server capable of communicating with the player terminal, the method comprising:
Either or both of the player terminal and the server,
A process of executing a battle game including multiple turns based on player operations;
a process of storing first information in the server as the battle game is executed;
a process of storing second information in the player terminal as the battle game is executed;
After the battle game is executed, a process of executing a replay function that reproduces the execution contents of the battle game;
carry out the
In the process of executing the replay function,
If the second information of the battle game is not stored in the player terminal, at least based on the first information, a first replay function that does not allow specifying a turn is executed;
If the second information of the battle game is stored in the player terminal, at least based on the second information, a second replay function that can specify a turn is executed;
Information processing method. comprising a player terminal and a server capable of communicating with the player terminal,
In either or both of the player terminal and the server,
A process of executing a battle game including multiple turns based on player operations;
a process of storing first information in the server as the battle game is executed;
a process of storing second information in the player terminal as the battle game is executed;
After the battle game is executed, a process of executing a replay function that reproduces the execution contents of the battle game;
carry out the
In the process of executing the replay function,
If the second information of the battle game is not stored in the player terminal, at least based on the first information, a first replay function that does not allow specifying a turn is executed;
If the second information of the battle game is stored in the player terminal, at least based on the second information, a second replay function that can specify a turn is executed;
Information processing system.

Images