Game program, game system, game device, and game processing method

Abstract

To provide a game program, a game system, a game device, and a game processing method that allow a multi-play to be enjoyed even in a game of the nature in which it is difficult to progress the same game while synchronizing the game progress state in real time.SOLUTION: A game using a user character is started on the basis of a first start instruction input, the progress of the game is finished at a subsequent first timing, and the progress state data up to then is transmitted to a server. A game based on the progress state data transmitted to the server by an information processing terminal of another user different from a user on the basis of a second start instruction input of the user and acquired from the server, which uses another user character used by the another user in the game, and the user character of the user, is started. At a second timing after the game is started, the progress of the game is finished and the progress state data is transmitted to the server.SELECTED DRAWING: Figure 5

Description

Technical Field

[0001] The present disclosure relates to game processing for executing a game on a user's information processing terminal.

Background Art

[0002] Conventionally, a game system including a multiplayer mode in which a plurality of game machines communicate with each other to synchronize game situations and allow users to play games together with other users has been known (for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The above game system can be said to be a suitable system for performing communication battle play in, for example, a racing game or the like. However, depending on the nature and genre of the game, it has been difficult to play the same game among multiple players while synchronizing the progress of the game in real time with other game machines.

[0005] Therefore, an object of the present disclosure is to provide a game program, a game system, a game device, and a game processing method that enable multiplayer play even in games that are difficult to play the same game while synchronizing the progress of the game in real time.

Means for Solving the Problems

[0006] In order to achieve the above object, for example, the following configuration examples can be cited.

[0007] (Configuration 1) Configuration 1 is a game program for executing a game on a user's information processing terminal, which causes the computer of the information processing terminal to function as a first game start means, a first game progress means, a first transmission means, a second game start means, a second game progress means, and a second transmission means. The first game start means starts a game based on predetermined initial setting data based on a first start instruction input by the user and using the user character of the user. The first game progress means progresses the game started by the first start instruction input based on the operation input of the user. The first transmission means ends the progress of the game at the first timing after the game is started by the first start instruction input, and transmits progress status data indicating the progress status of the game at the first timing to the server. The second game start means is a game based on progress status data transmitted to the server by another information processing terminal of another user different from the user based on a second start instruction input of the user and acquired by the user's information processing terminal from the server, and uses the other user character used in the game by the other user and the user character of the user to start the game. The second game progress means progresses the game started based on the second instruction input based on the operation input of the user. The second transmission means ends the progress of the game at the second timing after the game is started based on the second instruction input, transmits progress status data indicating the progress status of the game at the second timing to the server, and if the victory condition of the game is satisfied before the second timing arrives, transmits progress status data indicating the progress status of the game until the victory condition is satisfied to the server.

[0008] According to the above configuration example, it is possible to cooperate and progress the same game without performing real-time communication between a plurality of information processing terminals. Also, in the game started based on the second start input, in addition to the character owned by oneself, the characters of other users can also be used. As a result, for example, it is possible to overcome an unfavorable game development due to a lack of combat power, improve the tacticity, and also improve the interestingness of the game.

[0009] (Configuration 2) In Configuration 2, in the above Configuration 1, the game may be a turn-based strategy game. And the first timing may be the timing when the number of turns equal to the first number of turns has elapsed since the start of the game by the first start instruction input, and the second timing may be the timing when the number of turns equal to the second number of turns has elapsed since the start of the game by the second start instruction input.

[0010] According to the above configuration example, in a turn-based strategy game, cooperative play can be made enjoyable for the user. In particular, in a turn-based strategy game, since the play time of one map tends to be long, asynchronous cooperative play is enabled, so that users can participate in the game at their own pace and enjoy cooperative play.

[0011] (Configuration 3) In Configuration 3, in the above Configuration 2, the first game progress means and the second game progress means, in the above game, when it is the user's turn, the game is progressed based on the operation of the user, and when it is the opponent's turn, the game is progressed based on the operation of the computer based on AI control. When the user's turn and the opponent's turn are each finished for one turn, it may be determined that one turn has elapsed in the count of the first number of turns and the second number of turns.

[0012] According to the above configuration example, in a turn-based strategy game, cooperative play in a form where the turns of the user side are shared by a plurality of users for the turn of the opponent controlled by AI can be provided. Thereby, a way of enjoying the game where a plurality of users combine their forces and face the opponent (by AI control) can be provided.

[0013] (Configuration 4) In Configuration 4, in any of the above Configurations 1 to 3, the first game progress means may progress the game by controlling the user character in the virtual space based on the user's operation input, and the second game progress means may progress the game by controlling the user character and other user characters in the virtual space based on the user's operation input.

[0014] According to the above configuration example, since it is possible to operate not only the character owned by oneself but also the characters of other users, it is possible to adopt a fighting method that also utilizes the characters of other users, and the strategic and tactical nature of the game can be improved.

[0015] (Configuration 5) In Configuration 5, in the above Configuration 4, the second game start means may start the game after arranging the user's user character at a predetermined position in the virtual space determined based on the acquired previous situation data.

[0016] According to the above configuration example, the appearance position of the user character at the start of the second game can be made different according to the progress of the game. As a result, it is also possible to quickly deploy the user character to the front line.

[0017] (Configuration 6) In Configuration 6, in the above Configuration 5, the second game start means arranges the user character at a supportable position predetermined as a position where the user character can be arranged, and the number of supportable positions may be changed according to the progress of the game.

[0018] According to the above configuration example, it is possible to provide a game development in which while restricting the positions where the user character can be arranged to a certain extent, the number of such positions is gradually increased according to the progress of the game. This prevents the game balance from being disrupted by allowing the character to be placed anywhere, and an appropriate balance can be achieved. Also, even when joining the game midway, the user character can be quickly deployed to the front line.

[0019] (Configuration 7) In Configuration 7, in the above Configuration 1, when the first game progress means and / or the second game progress means end the game progress, they may present a plurality of prepared options to the user. Then, when any option is designated by the user from the plurality of options, the first transmission means and / or the second transmission means transmit the option data regarding the designated option to the server in association with the progress status data, and when there is option data associated with the progress status data acquired from the server, the second game start means may output an image based on the option data.

[0020] According to the above configuration example, it is possible to convey some intention to other users who will play after one's own play in the form of a support message or the like selected from options. Also, when one plays oneself, it is possible to confirm the intention from the predecessor. Thereby, simple communication can be achieved among users, and the interestingness of the game can be improved.

[0021] (Configuration 8) In Configuration 8, in any of the above Configurations 1 to 7, the second game start means may output a replay showing the progress of the game up to the first timing or the second timing based on the progress status data acquired from the server before the start of the game.

[0022] According to the above configuration example, it is possible to let the user grasp the game development up to the current play. Also, since the play content of other users can be viewed, it can be used as a reference for one's own play.

[0023] (Configuration 9) In Configuration 9, in the above Configuration 8, the second game start means may output a replay showing the progress of the game up to the first timing or the second timing based on the progress status data acquired from the server before the start of the game.

[0024] According to the above configuration example, before the start of the game, the game progress can be grasped in detail by replay. Also, the user can select whether to play from the continuation after grasping the game progress with the replay.

[0025] (Configuration 10) In Configuration 10, in any of the above Configurations 1 to 9, after the game progress by the first game progress means or the second game progress means ends, when there is an input of a progress status confirmation instruction by the user, the progress status data is acquired from the server according to the input, and based on the progress status data, a replay showing the progress of the game may be output.

[0026] According to the above configuration example, it is possible to confirm what kind of results the game in which one participated has become afterwards. Also, since the play content of other users can be viewed, it can be used as a reference for one's own play.

[0027] (Configuration 11) In Configuration 11, in any of the above Configurations 1 to 10, when the game program satisfies the victory condition of the game by the second timing, a first reward giving means for giving the user a first reward based on satisfying the victory condition of the game, and after the user's information processing terminal transmits the progress status data based on the game to the server, when the progress status of the game by other users satisfies the victory condition of the game, the computer may be further functioned as a second reward giving means for giving the user a second reward having a lower value than the first reward.

[0028] According to the above configuration example, when the user satisfies the victory condition in his own play, a better reward can be obtained, so the user's motivation towards achieving the victory condition can be enhanced.

[0029] (Configuration 12) In Configuration 12, in the above Configuration 11, when the second transmission means satisfies the defeat condition by the second timing, it may transmit the progress data until the defeat condition is satisfied to the server. And when the game program satisfies the defeat condition of the game by the second timing, the computer may be further functioned as third reward giving means for giving a third reward having a lower value than the first reward to the user based on the fact that the defeat condition of the game is satisfied.

[0030] According to the above configuration example, even when losing the game, if the user participates in the game, they can receive a reward, so it is possible to provide motivation for the user to participate in the game.

[0031] (Configuration 13) In Configuration 13, in any of the above Configurations 1 to 12, the game program may cause the computer to execute a game application including a game started by the first game start means or the second game start means and a cultivation game different from the game and capable of cultivating a user character. And the first game start means and the second game start means may start a game using the user character cultivated in the cultivation game.

[0032] According to the above configuration example, the user can have the character cultivated in the cultivation game used by other users. Also, conversely, the user can use the character cultivated by others in their own play. Thereby, it is possible to provide fun such that each user shows off the characters they have cultivated to each other. Also, it becomes possible to proceed with the game using the characters cultivated by others. For example, it is possible to check the performance of the character after growth and enhance the motivation for cultivating the characters owned by the user himself / herself.

[0033] (Configuration 14) In Configuration 14, in the above Configuration 13, when the number of other user characters used in the game by other users has reached a predetermined number, the second game start means may start the game without allowing the user's user character to appear in the game, or may start the game by swapping the other user character and the user character.

[0034] According to the above configuration example, by suppressing the number of available (appearing) characters to a predetermined number or less, it is possible to prevent the game balance from being disrupted by the fact that characters can be used without numerical restrictions, and to maintain an appropriate balance.

[0035] (Configuration 15) In Configuration 15, in the above Configuration 1, the first game start means starts a game using the user character selected by the user among a plurality of user characters, and the second game start means may start the game using the other user character used by another user in the game and a user character different from the other user character among the plurality of user characters.

[0036] According to the above configuration example, it is possible to prevent the same (duplicate) character from being used within the same game. As a result, for example, it is possible to prevent a game development in which only characters with powerful performance (the same) appear, and to increase the opportunity to use various characters with different performances and personalities.

[0037] (Configuration 16) In Configuration 16, the first transmission means may transmit the progress status data to the server after designating the range of other users who can acquire the progress status data based on the user's operation input.

[0038] According to the above configuration example, for example, when a person who is somewhat familiar with the game is added as a friend, the possibility of the game being cleared after the user plays can be increased.

Effects of the Invention

[0039] According to the present disclosure, it is possible to play the same game in cooperation among a plurality of users without synchronizing the progress of the game by communicating in real time among a plurality of information processing terminals.

Brief Description of Drawings

[0040]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Mode for Carrying Out the Invention

[0041] Hereinafter, an embodiment of the present invention will be described. FIG. 1 is a schematic diagram showing an overall view of an information processing system (game system) according to this embodiment. The information processing system 100 of this embodiment includes a server 1 and a plurality of information processing terminals 2. The server 1 and the information processing terminal 2 are configured to be communicable via a network 10 such as the Internet. In this embodiment, information processing is executed with such a configuration. Hereinafter, as an example of the information processing, game processing will be described as an example. Specifically, a game program is installed on the information processing terminal 2, and game processing executed while communicating with the server 1 as necessary will be exemplified.

[0042] [Hardware Configuration of Server] Next, the hardware configuration of the server 1 will be described. FIG. 2 is a block diagram showing the hardware configuration of the server 1. The server 1 includes at least a processor 11, a storage unit 12, and a communication unit 13. The processor unit 11 executes various programs for controlling the server 1. The storage unit 12 stores various programs executed by the processor unit 11 and various data used. The communication unit 13 is connected to a network by wired or wireless communication and transmits and receives predetermined data to and from the information processing terminal 2 or another server (not shown).

[0043] [Hardware Configuration of Information Processing Terminal] Next, the information processing terminal 2 will be described. The information processing terminal 2 is, for example, a smartphone, a stationary or portable game device, a tablet terminal, a mobile phone, a personal computer, a wearable terminal, or the like. Further, the information processing according to the present embodiment is also applicable to a game system including the game device or the like as described above and a predetermined server. In the present embodiment, a stationary game device (hereinafter simply referred to as a game device) will be described as an example of the information processing terminal 2.

[0044] FIG. 3 is a block diagram showing an example of the hardware configuration of the game device 2 according to the present embodiment. In FIG. 3, the game device 2 includes a processor 21. The processor 21 is an information processing unit that executes various information processes executed in the game device 2 and may be configured from, for example, only a CPU (Central Processing Unit), or may be configured from a SoC (System-on-a-chip) including a plurality of functions such as a CPU function and a GPU (Graphics Processing Unit) function. The processor 21 executes various information processes by executing an information processing program (for example, a game program) stored in the storage unit 22. Note that the storage unit 22 may be, for example, an internal storage medium such as a flash memory or a DRAM (Dynamic Random Access Memory), or may be configured to use an external storage medium or the like mounted in a slot not shown.

[0045] In addition, the game device 2 includes a wireless communication unit 23 for the game device 2 to perform wireless communication with other game devices 2 and a predetermined server device. As the wireless communication, for example, Internet communication or short-range wireless communication is used.

[0046] The game device 2 also includes a controller communication unit 24 for the game device 2 to perform wired or wireless communication with the controller 4.

[0047] A display unit 5 (for example, a TV, etc.) is connected to the game device 2 via an image and audio output unit 25. The processor 21 outputs the generated image and audio (for example, by executing the above information processing) to the display unit 5 via the image and audio output unit 25.

[0048] Next, the controller 4 will be described. Although not shown, the controller 4 of the present embodiment has a vertically long housing and can be held in a vertically long orientation. The housing has a shape and size that can be held with one hand when held in a vertically long orientation.

[0049] The controller 4 includes at least one analog stick 42 which is an example of a direction input device. The analog stick 42 can be used as a direction input unit capable of inputting a direction. The user can input a direction corresponding to the tilting direction (and an input of a magnitude corresponding to the tilted angle) by tilting the analog stick 42. The controller 4 also includes a button unit 43 including various operation buttons. For example, the controller 4 may include a plurality of operation buttons on the main surface of the housing.

[0050] The controller 4 also includes an inertial sensor 44. Specifically, the controller 4 includes an acceleration sensor and an angular velocity sensor as the inertial sensor 44. In the present embodiment, the acceleration sensor detects the magnitude of acceleration along a predetermined three-axis direction. The angular velocity sensor detects the angular velocity around a predetermined three axes.

[0051] In addition, the controller 4 also includes a communication unit 41 for performing wired or wireless communication with the controller communication unit 24. Information indicating the direction input content for the analog stick 42, the pressed state of the button unit 43, and various detection results by the inertial sensor 44 are repeatedly output to the communication unit 41 at appropriate timings and transmitted to the game device 2.

[0052] [Regarding the game assumed in this embodiment] Next, the game processing executed in this embodiment will be described. As a premise, the outline of the game assumed in this embodiment will be described. The game assumed in this embodiment is a turn-based strategy type simulation game (hereinafter referred to as TBSG). Also, in this embodiment, a TBSG is assumed in which battles are fought between a total of two armies, one for the player's army and one for the enemy army. In this TBSG, the pieces in the simulation game are called "units". Further, the units of the player's army are called "player units", and the units of the enemy army are called "enemy units".

[0053] FIG. 4 shows an example of a battle screen in this game. As shown in FIG. 4, in this game, a game image obtained by imaging a virtual three-dimensional space with a virtual camera is displayed. Also, the ground in the virtual three-dimensional space is divided into rectangular grids, and the user can move each unit in units of grids. Note that the virtual space that is the game space may be a two-dimensional space. Also, in this game, the player units and the enemy units are each humanoid characters. And this game is a TBSG in which each unit is equipped with a predetermined weapon and battles are fought between units using this weapon. Note that in this game, it is assumed that there are no duplicate characters (identical characters) among the characters that are the player units. That is, each character is considered to be a "different person". Note that the determination of duplicate characters may be made, for example, by whether the names of the characters are the same or whether the internal data such as the IDs assigned to the characters are the same.

[0054] [Regarding the First Game Mode] In this game, there are a first game mode in which a user can play the game alone and a second game mode in which a plurality of users can play on a single map. In the first game mode, the user can progress the game along a predetermined story. Also, by progressing the story, the user can increase the number of friendly units that the user owns. In addition, the friendly units in this game have a growth element, and in the first game mode, each unit can be trained. Specifically, each individual unit is provided with a "unit level", and in the first game mode, by repeatedly sending out the same unit on missions, etc., the user can earn experience points and raise the unit level. As the unit level increases, the performance of that unit is also enhanced and improved.

[0055] [Regarding the Second Game Mode] On the other hand, the second game mode is a game mode in which multiple users take turns in relay as the same "own army" for a predetermined map prepared in advance and proceed with the game. This is intended to provide users with a new type of multiplayer that has never existed before in TBSG. For example, in TBSG, when attempting to play multiplayer via the network using a predetermined map, it is conceivable to connect multiple game consoles via the network and play a communication game while synchronizing in real time, similar to when playing a communication battle in a racing game or a fighting game. However, in the case of TBSG, it is generally considered that the play time for one map is relatively long. Also, since TBSG progresses in an alternating manner between the own army phase (turn) and the enemy army phase, there will be a waiting time for the user during the enemy army phase. Considering such factors as the length of the play time for one map and the existence of the waiting time during the enemy army phase, it is considered that real-time communication play is not suitable for TBSG without any special measures. Therefore, in this embodiment, for one map, a form of (asynchronous) cooperative play is provided in which multiple users separately take charge of the operations for each predetermined turn of the own army phase and aim to clear that map (note that the enemy army phase is AI-controlled). That is, each user only needs to connect to the network only when they are in charge of the operation. Hereinafter, TBSG in the second game mode will be referred to as "relay battle".

[0056] Also, in the said relay battle, it is assumed that the said unit cannot obtain experience points and cannot grow. In other words, the second game mode also has an aspect of being a game mode that provides a venue for the active use of the own army units grown in the first game mode. Hereinafter, the outline of the said relay battle will be explained.

[0057] In the following description, "one turn" is intended to mean one set consisting of one turn of our army's phase and one turn of the enemy army's phase. For example, when referring to "one turn has passed", it means that one turn each of our army's phase and the enemy army's phase has passed.

[0058] [Regarding the overall flow of the relay battle] FIG. 5 is a diagram showing the overall communication and processing flow of the relay battle in the present embodiment. Here, as an example, it is assumed that there is a first game machine operated by a first user and a second game machine operated by a second user. And the flow in which the second user takes over and plays the relay battle started by the first user is illustrated. In the following description, the first user starting the relay battle is referred to as "initiating". Also, the user who initiates is called the "initiating user". In the present embodiment, it is assumed that each user can only take over (participate) in the same relay battle once. Also, it is assumed that the user who has initiated cannot take over the relay battle by themselves. In the following description, each user who has taken over the relay battle initiated by another user is collectively referred to as the "taking-over user".

[0059] In FIG. 5, first, as process P1, a first user initiates a relay battle on a first game machine. For example, the first user selects a predetermined map from among a plurality of maps prepared in advance for the relay battle. Then, the first user instructs the start of the relay battle using the map. Thereafter, a "departure preparation screen" for the relay battle is displayed. FIG. 6 shows an example of the departure preparation screen. On the departure preparation screen, the map used in this relay battle (the display range of which can be changed) and a departure preparation menu are displayed. The first user performs a predetermined operation on the screen to select a unit to be dispatched to the relay battle from the units owned by the user and arranges it on the map related to the relay battle (the positions where the units can be arranged will be described separately later). In this embodiment, the upper limit of the number of units that the first user (initiating user) can dispatch is up to 5 units, and the upper limit of the number of units that the second user and subsequent users (successor users) can dispatch is up to 2 units. In other embodiments, the upper limit of the number of units dispatched by each user may be other values.

[0060] Returning to FIG. 5, next, as process P2, the first user plays the relay battle for a predetermined number of turns. In this embodiment, the predetermined number of turns is 2. Note that the predetermined number of turns is an example, and in other embodiments, other values may be used.

[0061] Next, as process P3, result data related to the first user's play is transmitted from the first game machine to the server. The result data includes log data indicating the action content and battle results of the friendly and enemy units in each turn, etc. In other words, the result data is data indicating the progress of the game related to each user's play.

[0062] Next, as process P4, based on the result data received from the first game machine, relay battle data related to the relay battle initiated by the first user is newly registered on the server.

[0063] Next, as process P5, in the second game machine, the second user performs an instruction operation for "taking over" the relay battle. That is, an operation is performed to indicate that the second user takes over and plays the relay battle initiated by another user. In response to this, a request for data of relay battles that can be taken over is sent from the second game machine to the server.

[0064] Next, as process P6, in the server, in response to the request from the second game machine, a predetermined number of data of relay battles that can be taken over at this time are selected and sent to the second game machine. Here, it is assumed that the data of the relay battle initiated by the first user is also included in the selected predetermined number of data of relay battles.

[0065] Next, as process P7, in the second game machine, a list of relay battles that can be taken over is presented based on the data received from the server. The second user can select a predetermined relay battle from this list and refer to the information related to that relay battle. In this embodiment, as one of the information, in the second game machine, based on the data of the relay battle (the above result data), the previous play content and the progress of the game (progress status) are reproduced as a "replay". For example, when the relay battle of the first user is selected, the actual TBSG screen is displayed, and the actions and battle contents of each unit used by the first user are reproduced in order from the first turn. Thereby, the second user can know how the first user advanced the game. Note that, unlike the case of taking over data from a spontaneous user such as the first user, in the case of a relay battle where there is a taking-over user who took over the data from a spontaneous user and played the relay battle, or a next taking-over user who took over the data from a taking-over user and played the relay battle, when there are multiple users who played before oneself (hereinafter collectively referred to as predecessors), the play content for all predecessors is replayed in order.

[0066] Next, as process P8, an operation of determining a relay battle to be carried over from the above list is performed on the second gaming machine. Here, as an example, among the relay battles presented to the second user as relay battles that can be carried over, it is assumed that the relay battle initiated by the first user is determined to be carried over. In response to this operation, a carry-over determination notification is sent to server 1.

[0067] Next, as process P9, on server 1, during the play of the second user, a process of temporarily locking the data related to the relay battle so that the relay battle initiated by the first user is not treated as a "carry-over possible" relay battle is performed.

[0068] Next, as process P10, on the second gaming machine, a sortie preparation screen is displayed, and the second user selects and arranges (up to two units) the units to sortie with in the relay battle from the units they own.

[0069] Next, as process P11, on the second gaming machine, the second user plays for a predetermined number of turns (two turns in this example). At this time, the second user can operate not only the friendly units they have sent out but also the friendly units sent out by the first user (hereinafter referred to as predecessor units). For example, if the first user sends out five units and the second user sends out only two units, the second user can operate a total of seven friendly units.

[0070] Next, as process P12, result data related to the play of the second user is sent from the second gaming machine to the server.

[0071] Next, as process P13, on server 1, the result data from the second gaming machine is received. Then, on server 1, based on the result data, the data of the relay battle initiated by the first user is updated. At the same time, the lock placed on the data of the relay battle is also released. As a result, the updated data of the relay battle is treated as a relay battle that can be carried over.

[0072] After this, if other users such as a third user and a fourth user participate as relay users, the processes P5 to P13 are repeated for each user. Then, when a predetermined victory condition (for example, defeating a boss character) or defeat condition (for example, total destruction of one's own army) set for the relay battle is satisfied, the relay battle ends. And when the relay battle ends, a predetermined reward is given to the participants in the relay battle (by an operation for progress confirmation described later).

[0073] As described above, the relay battle of this embodiment is configured to perform the operation of one's own army in the TBSG while being taken over by a plurality of users every predetermined number of turns. And as described above, in the relay battle, each user can also operate the predecessor unit. Therefore, the later the takeover timing (the number of turns from the start of the relay battle) is for the user, the more play using a larger number of one's own army units becomes possible. FIG. 7 shows an example of the relationship between the passage of turns and the number of operable units. In FIG. 7, a relay battle in which five users, users 1 to 5, participate is assumed. Also, it is an example in which each user performs operations for two turns. Also, in the map, an upper limit number of one's own army units going out on a mission is provided, and it is assumed that the number is 10. In FIG. 7, user 1, who is the first user, has sent out five units on a mission. Therefore, the units operable by user 1 are the five units. Next, user 2, who took over after this, has sent out two units on a mission. Therefore, a total of seven units are operable in combination with the units of user 1. Also, user 3, who took over after this, has also sent out two units on a mission, and user 3 can operate a total of nine units including the predecessor units.

[0074] Next, if user 4 takes over the relay battle later, since 9 units have already been dispatched (exist on the map), basically only 1 unit can be dispatched. However, when the maximum dispatch limit is reached, it is also possible for user 4 to further dispatch the units owned by user 4 in such a way that they are "exchanged" with the existing units. In Fig. 7, as an example of the exchange, unit 4, which is the unit dispatched by user 1, is exchanged with the unit of user 4 is shown (it means that user 4 has dispatched a total of 2 units of his own). As a result, user 4 can operate a total of 10 units including the predecessor unit.

[0075] Here, assume that in the play by user 4, unit 1 is defeated by the enemy (when it is defeated in the 7th turn). In this case, the said unit 1 no longer exists on the map, and at the time of the 8th turn, the number of friendly units is 9. After that, when it is taken over from user 4 to user 5, user 5 can basically dispatch only 1 unit. However, as described above, when the maximum dispatch limit is reached, by "exchanging" with the existing units, user 5's owned units can be further dispatched. In the example of Fig. 7, it shows an example where user 5 dispatches the unit owned by user 5 as the previously defeated unit 1 and also dispatches user 5's unit by exchanging it with the unit of user 2 as unit 6. As a result, user 5 can also operate a total of 10 units including the predecessor unit.

[0076] In this way, when a user takes over a relay battle, each taking-over user can deploy their own units (up to 2 units) within the limit of the deployment upper limit provided for each map. Therefore, the user can choose between two ways of enjoying the game: participating (taking over) at an early stage after the relay battle is initiated according to their own playing style, etc., and participating at a stage where a certain number of turns have passed. In the former case, since the number of units to be operated is small, the time spent on gameplay is also small, and it is possible to participate casually. Therefore, for example, users who have difficulty finding time to play the game carefully can participate at an early stage, quickly finish their part of the game, and then wait for the clear reward. On the other hand, users who have time to play the game carefully or are accustomed to TBSG can also choose to participate in the relay battle at a late stage. As a result, more units can be operated, so they can enjoy the game carefully (the strategic nature of the game is enhanced when the number of operable units is larger). Furthermore, by fulfilling the victory conditions of the map during their own play, they can clear the relay battle and expect to be thanked by the predecessor. In particular, in this embodiment, each unit has a growth element as described above. Therefore, when multiple advanced players take over a relay battle initiated by a beginner (a battle situation with low unit levels and difficult to clear), it is possible to change the battle situation and force a clear by deploying high-level units. In this way, in the relay battle of this embodiment, it is also possible to provide different ways of enjoying the game according to the user's playing style.

[0077] [Overview of Various Processes Related to Relay Battle] In addition, in the relay battle of this embodiment, various controls as shown below are further performed to improve the convenience for users and the interestingness of the game.

[0078] [Progress Confirmation Function after Spontaneous or Takeover] First, in this embodiment, the user can check the progress of the game after spontaneously or inheriting and finishing playing. For example, for a spontaneous user who initiated a relay battle, after their own play is over, by performing a predetermined operation for "progress check", the data of the relay battle at that time can be obtained from the server, and the replay up to that point is played back. Thereby, the spontaneous user can check what happened to the relay battle they initiated. For example, if there is an inheriting user, following the replay related to the play of the spontaneous user, the replays of each inheriting user are played back in order. The same applies when the user themselves becomes an inheriting user. That is, following the replay of the spontaneous user, the replays of the inheriting users including oneself are played back in order. Thereby, the progress after one's own play can be checked, and the play of other users can also be checked, so it is also possible to utilize it in future play by referring to the fighting methods of other users. Incidentally, when the spontaneous user performs the progress check operation and has not yet been inherited by other users, only the replay of the spontaneous user will be played back. Furthermore, as a result of the progress check, if the victory condition or defeat condition is satisfied and the relay battle has ended, a predetermined reward is given to the user who performed the progress check.

[0079] [Regarding the boosting points] Next, the deployment positions (departure positions) of our own army units will be described. First, regarding the positions (initial deployment positions) where spontaneous users deploy our own army units, they are determined in advance for each map used in relay battles. A spontaneous user can deploy our own army units at any of the determined initial deployment positions. On the other hand, the positions where a successor user can deploy our own army units are the squares where "support points" are set and the four surrounding squares adjacent to them. Hereinafter, these squares will be collectively referred to as "supportable squares". Fig. 8 shows an example of a support point and supportable squares. Also, Fig. 8 is a schematic diagram showing a bird's-eye view of a part of the virtual space related to the TBSG of the present embodiment. In Fig. 8, four support points indicated by circles are set. The positions of the support points are set in advance for each map. Also, the support points are set in either an "active" or "non-active" state. Immediately after the start of the relay battle, only some of the multiple support points are active, and the rest are non-active. In Fig. 8, the active support points are shown in black, showing a state where there are two active support points and two non-active support points. Then, as the game progresses, as shown in Fig. 9, when our own army unit moves to a square with a non-active support point and "waits" (action ends), the state of the support point changes from non-active to active. Our own army unit can be deployed at the squares of this "active" support point and the four surrounding squares adjacent to it.

[0080] The reason for providing such reinforcement points is to change (expand) the deployable positions according to the game situation (the progress of the relay battle game). For example, in FIG. 8 above, assume that there is only one lower left reinforcement point out of four. Then, assume a situation where the game progresses and the front line of the battle is near the upper end in FIG. 8. In this case, when starting a relay battle by inheritance, it may be difficult to deploy friendly units to the front line. For example, even if a friendly unit is deployed at the position of the lower left reinforcement point, it may not be able to move to the position of the front line during the user's play (for example, two turns of play). On the other hand, if all four reinforcement points in FIG. 8 are available from the initial stage of the game, it becomes possible for the inheriting user to place a friendly unit near, for example, the enemy general character (boss character) shortly after the start of the relay battle. As a result, it is also conceivable that an undesirable development may occur from the perspective of game balance and the like. Therefore, in this embodiment, a plurality of reinforcement points arranged at a certain distance are prepared, and it is configured to be able to gradually increase the active reinforcement points as the game progresses. This can make the game balance appropriate. For example, it is possible to avoid a development where an attack can be made on the boss character from the early stage of the relay battle, and to have a game development where the front line is gradually pushed forward. Also, for a user who inherits a game that has progressed to a certain extent, if the reinforcement point near the front line becomes active, it becomes possible to quickly send the units owned by the user to the front line, and to fully enjoy the relay battle by having the units deployed by the user fight on the front line and the like.

[0081] [Regarding the placement operation of the inheriting user] Next, a specific example of the case where the inheriting user arranges a unit he / she owns will be described. First, on the sortie preparation screen, when the inheriting user selects a unit to be sent on a sortie (hereinafter referred to as the supporting unit), it is automatically arranged in one of the available supporting squares once (see, for example, FIG. 10). After that, based on the user's operation, the arrangement position can be manually changed among the available supporting squares (see FIG. 11). Then, when the user gives a sortie order, the self-army phase starts with the supporting unit being arranged on the map (on a predetermined supporting square) from the beginning. In this regard, in other embodiments, at the stage of the sortie preparation screen, instead of actually arranging the supporting unit on the map, it may be sufficient to only specify the unit to be sent on a sortie. And the actual arrangement may be performed immediately after the start of the first self-army phase in this play (immediately after the sortie order). Or, instead of the timing immediately after the start of the first self-army phase, the arrangement may be made after several turns, such as when it becomes the second self-army phase. Further, in still other embodiments, the user may be able to specify the timing (turn) of appearance. Thereby, the user can be made to consider the timing of appearance in the strategy, and the strategic nature of the game can be further improved.

[0082] Here, when there are other units in the supporting square, that supporting square is treated as not being available (occupied), and the supporting unit cannot be arranged on that square. For example, as shown in FIG. 12, when 4 out of 5 supporting squares are occupied, even if the inheriting user can send out up to 5 units he / she owns, he / she can only send out 1 supporting unit. Also, if all the supporting squares are occupied, the inheriting user cannot send out his / her own self-army unit as a supporting unit (will play only using the previous user's unit).

[0083] Next, supplement the above "replacement". As described above, when the number of own units on the map reaches the sortie limit, the existing own units can be taken over by "replacement" and replaced with the user's units. At this time, the appearance position (placement position) of the unit to be replaced will be any of the available supportable squares. For example, when replacing the predecessor unit A with the support unit B, the support unit B will not appear in the square where the predecessor unit A is located, but will appear in an available supportable square. Therefore, when all the supportable squares are occupied, there is no square for the support unit B to be replaced to appear, so in this case, "replacement" cannot be performed.

[0084] Also, supplement the timing when "replacement" is actually performed. In this embodiment, on the sortie preparation screen, only the unit to be replaced is specified, and the actual replacement is assumed to be performed immediately after the start of the first own phase after sortie. In this regard, in other embodiments, "replacement" may be performed at a timing other than immediately after sortie, such as the second turn after sortie.

[0085] Also, in this embodiment, as described above, the unit is a humanoid character and there are no duplicate characters. Therefore, even if it is a unit owned by the inheriting user, it is assumed that the same character that already exists on the map cannot be sortie. In this regard, in other embodiments, the same character may be made sortieable by the above "replacement". That is, it may be possible to exchange a character of another user with one's own owned character that is the same as this.

[0086] [Regarding the comment function] Next, the comment function will be described. In the relay battle according to the present embodiment, when each user finishes their own play, they can leave a comment for the user who will take over later (or a user who may take over). Then, the taking-over user can view the comments from the users who have played so far (hereinafter referred to as the predecessors). Specifically, the comment is displayed at the timing when the playback of the replay ends before actually starting the play. Here, in the present embodiment, the comment can be selected from prepared fixed phrases (in other words, the user cannot freely input a comment). Specifically, after each user finishes playing a predetermined number of turns, a comment selection screen as shown in FIG. 13 is displayed, for example. On the comment selection screen, a plurality of fixed phrases are presented to the user as options. Then, when the user selects a predetermined fixed phrase from among them, the result data including the selection result is transmitted to the server.

[0087] Note that the timing for displaying the above comment is just an example, and in other embodiments, it is not limited to being displayed together with the replay. For example, the comments of the predecessors may be collectively displayed at the timing when the taking-over user departs (at the start of the first friendly phase of the taking-over user). Alternatively, the comment may be displayed as one of various types of information when presenting the relay battle information.

[0088] Also, in other embodiments, regarding the content set as a comment, in addition to the above fixed phrases, a plurality of predetermined images (icons and stamp images) may be presented as options and made selectable by the user in combination with the fixed phrases.

[0089] [Regarding Rewards] Next, a supplement regarding the reward associated with the end of the relay battle described above will be provided. In this embodiment, when the relay battle ends, a reward is given to all users who participated in that relay battle. The grade of this reward differs depending on whether the victory condition is satisfied at the end (that is, when winning) and whether the defeat condition is satisfied at the end (that is, when losing). Specifically, a higher-grade reward is given when winning than when losing. Note that the specific determination of the reward content may be made by lottery. For example, for the victory reward, it may be determined by lottery from a group of items with a higher grade than the defeat reward. Also, in addition to making the grade of the reward itself different, the number or quantity of the rewards given may be made different. For example, even if the rewards themselves are the same items or in-game currency, the number or quantity of the victory rewards may be more than that of the defeat rewards. Regarding the content of the defeat reward, in addition to determining it by lottery, the same content of the reward may be given uniformly to all participants. By preparing both the victory reward and the defeat reward in this way, it is possible to encourage active participation in the relay battle and make it less likely for the situation where no one participates in the relay battle and it is left unattended to occur.

[0090] Also, regarding the victory reward, furthermore, the grade of the reward differs between the user who satisfied the victory condition in the play they were in charge of and the user who could not satisfy the victory condition in their play. In this embodiment, a higher-grade reward is given to the user who satisfied the victory condition in the play they were in charge of than to other users. That is, the user who finally determined the victory condition will receive a better reward. This can provide the user with the motivation to achieve the victory condition by their own hands. That is, it is possible to provide the user with the motivation to actively participate in a relay battle in a state where the game has progressed to a certain extent (where the combat power and the battle situation are in order and the possibility of satisfying the victory condition is considered to be high).

[0091] [Details of the game processing of this embodiment] Next, with reference to FIGS. 14 to 28, the game processing in this embodiment will be described in more detail.

[0092] [Regarding Usage Data] First, various data used in this embodiment will be described. Here, first, the data used in the server 1 will be described, and then the data used in the game device 2 will be described.

[0093] [Regarding Data Stored in Server 1] FIG. 14 is a memory map showing an example of various data stored in the storage unit 12 of the server 1. The storage unit 12 stores a management program 501, relay battle data 502, and the like.

[0094] The management program 501 is a program for realizing various functions that the server undertakes in the game processing according to this embodiment. Specifically, it is a program for executing the processing according to the flowchart of FIG. 20 described later.

[0095] The relay battle data 502 is a database for managing the above relay battle in the server 1. FIG. 15 shows an example of the data configuration of the relay battle data 502. As shown in FIG. 15, the relay battle data 502 is a database composed of a set of records including at least items of battle ID 511, last update date and time 512, map ID 513, lock flag 514, end flag 515, and battle log data 516.

[0096] The battle ID 511 is an ID for uniquely identifying each relay battle. The last update date and time 512 is information indicating the last update date and time of the record. The map ID 513 is information for specifying the map used in the relay battle related to the record. In this embodiment, since several types of maps for relay battles are prepared in advance, an ID for specifying any of these is stored as the map ID 513.

[0097] The lock flag 514 is a flag indicating whether the relay battle related to that record is being played by a predetermined user. When the lock flag 514 is on, it indicates that it is in a state of being played by a predetermined user. Assume that the initial value of the lock flag 514 is off. The end flag 515 is a flag indicating whether the relay battle related to that record has satisfied the end condition. When the end flag 515 is off, it means that the relay battle has not yet satisfied the end condition and can be selected as a relayable relay battle. When the end flag 515 is on, since the relay battle has ended, it will not be selected as a relayable relay battle. Also, assume that the initial value of the end flag 515 is off.

[0098] The battle log data 516 is data indicating the play content (progress) in the relay battle related to that record. Also, the battle log data 516 is a set of the above result data transmitted from each game device 2. FIG. 16 shows an example of the data configuration of the battle log data 516. The battle log data 516 is a database composed of a set of records including at least the items of user ID 521, result data 522, and registration date and time 523. The result data 522 is data indicating the play content of each user, etc., and stores the transmission result data 608 described later transmitted from the game device 2. The user ID 521 is an ID for identifying the user who transmitted the result data 522, and the registration date and time 523 is the registration date and time of that record (result data 522).

[0099] In addition, although not shown, various data for transmission to the game device 2, etc. can also be appropriately generated as needed and stored in the storage unit 12. Also, various data received from the game device 2 can also be temporarily stored in the storage unit 12.

[0100] [Regarding the data stored in the game device 2] Next, the data stored in the game device 2 will be described. FIG. 17 is a memory map showing an example of various data stored in the storage unit 22 of the game device 2. In the storage unit 22 of the game device 2, a game program 601, map master data 602, unit master data 603, owned unit data 604, comment master data 605, relay battle management data 606, operation data 611, etc. are stored.

[0101] The game program 601 is a program for executing the game process according to the present embodiment. Specifically, it is a program for executing the process according to the flowchart of FIG. 21 described later.

[0102] The map master data 602 is data that defines the configuration of the map of the TBSG used in the first game mode and the map of the TBSG used in the second game mode. Specifically, it includes various information for constructing the map, such as the size of each map (the number of squares), information indicating the terrain of each square, its appearance, terrain effects, etc. In addition, the map master data 602 also includes information defining the victory conditions and defeat conditions in each map.

[0103] The unit master data 603 is data that defines all friendly units that appear in this game. In the unit master data 603, for example, for each unit, a unit ID, character name, various status information, unit level, information indicating the appearance, etc. are defined.

[0104] The owned unit data 604 is data indicating the units owned by the user.

[0105] The comment master data 605 is data that records a plurality of fixed phrases used as comments as described above.

[0106] The relay battle management data 606 is data used when the game device 2 executes processing related to relay battles. The relay battle management data 606 includes at least the spontaneous / relay history data 607, transmission result data 608, received battle log data 609, and TBSG processing data 610.

[0107] The spontaneous / relay history data 607 is data indicating the history of relay battles initiated by the user and relay battles (participated in) taken over. FIG. 18 is an example of the data configuration of the spontaneous / relay history data 607. The spontaneous / relay history data 607 is a database composed of a set of records including at least the fields of history number 621, date / time data 622, battle ID 623, and reward flag 624. The history number 621 is an ID for uniquely identifying each record. The date / time data 622 is data indicating the date and time when the relay battle was initiated or taken over. The battle ID 623 is information for specifying the relay battle initiated or taken over, and is information corresponding to the battle ID 511 of the above relay battle data 502. The reward flag 624 is a flag indicating whether the reward for that relay battle has been granted. If it has been granted, it is set to on, and if not, it is set to off.

[0108] Returning to FIG. 17, next, the transmission result data 608 is data for transmission to the server 1 and is data indicating the play content of the TBSG advanced by the user on the game device 2. At least a part of the transmission result data 608 will be stored in the server 1 as the result data 522 of the battle log data 516. FIG. 19 shows an example of the data configuration of the transmission result data 608. The transmission result data 608 at least includes user information 631, battle ID 632, TBSG log data 633, and designated comment data 634. The user information 631 is information for identifying the user who transmitted the transmission result data 608. The battle ID 632 is information for identifying the relay battle spontaneously or inherited by the user and is also information corresponding to the battle ID 511 of the relay battle data 502. The TBSG log data 633 is data indicating the play content in the TBSG. For example, it includes information indicating the turn taken by the user, the operation content of the user, the action content of each unit, information indicating the result of the battle, and the like. The designated comment data 634 is information for identifying the comment selected by the user. In addition, the transmission result data 608 may also include information for identifying the map used in the relay battle, information indicating the transmission date and time, and the like.

[0109] Returning to FIG. 17, next, the received battle log data 609 stores the battle log data 516 received from the server 1.

[0110] The TBSG processing data 610 is data used when the game device 2 performs processing of the TBSG related to the relay battle. The data includes unit list data for managing the positions of each unit on the map and the states of each unit. Regarding the generation of the unit list data, when inheriting and playing the relay battle, the positions of existing units and the like will be determined based on the received battle log data 609.

[0111] Next, the operation data 611 is data indicating the content of the operations performed by the player on the controller 4. It is data transmitted from the controller 4 to the processor 21 at predetermined time intervals, and includes information indicating the pressed state of various buttons and information indicating the input content for the analog stick, etc.

[0112] In addition, although not shown in the drawings, various data necessary for game processing, such as data on items owned by the user and data related to the first game mode, are also stored in the storage unit 22.

[0113] Next, the details of the game processing in this embodiment will be described. Here, the processing related to the server 1 will be described first, and then the processing related to the game device 2 will be described. In this embodiment, the following flowchart is realized by one or more processors reading and executing the above program stored in one or more memories. Also, the said flowchart is merely an example of the processing process. Therefore, if the same result can be obtained, the processing order of each step may be changed. Also, the values of variables and the threshold values used in the determination steps are also merely examples, and other values may be adopted as necessary.

[0114] [Processing Executed by Server 1] FIG. 20 is a flowchart showing details of the relay battle management process executed by server 1. In FIG. 20, first, in step S1, the processor 11 of server 1 determines whether it has received the transmission result data 608 from a predetermined game device 2. As a result of this determination, if it has received (YES in step S1), then in step S2, the processor 11 updates the relay battle data 502 based on the received data. Specifically, if the received transmission result data 608 pertains to a self-initiated relay battle, the processor 11 generates a new record related to that relay battle based on the received data and newly registers it in the relay battle data 502. In this embodiment, when a relay battle is self-initiated, a battle ID is generated on the game device 2 side and is included in the transmission result data. Also, at this time, the battle ID is generated to be a unique ID using a unique terminal ID number, user ID, etc. for each game device. Therefore, if the battle ID does not exist in the relay battle data 502, server 1 can determine that it is result data related to a self-initiated relay battle. On the other hand, if the received transmission result data 608 pertains to a relay battle that has been taken over, the content of the relay battle data 502 is updated based on the received data. Specifically, the processor 11 identifies the battle ID 511 based on the received data. Then, the processor 11 adds a new record based on the received data to the battle log data 516 of the relay battle related to the identified battle ID 511. Also, the processor 11 determines whether the relay battle has ended (whether the victory condition or defeat condition has been met) based on the transmission result data 608, and if it has ended, sets the end flag 515 to on. Further, if the relay battle corresponding to the received transmission result data 608 is locked, the processor 11 releases the lock. That is, the processor 11 sets the lock flag 514 to off.

[0115] On the other hand, as a result of the determination in step S1, if the transmission result data 608 has not been received (NO in step S1), the process of step S2 above is skipped.

[0116] Next, in step S3, the processor 11 determines whether it has received a data request (request) for a relay battle that can be inherited from a predetermined game device 2. As a result of this determination, if the request has been received (YES in step S3), in step S4, the processor 11 refers to the relay battle data 502 and selects a predetermined number of relay battles for which the end flag 515 is off (relay battles that can be inherited). Note that any selection method may be used. Then, the data related to the selected relay battle is transmitted to the game device 2 that is the source of the request.

[0117] On the other hand, as a result of the determination in step S3, if a data request for a relay battle that can be inherited has not been received (NO in step S3), the process of step S4 is skipped.

[0118] Next, in step S5, the processor 11 determines whether it has received a transfer decision notice from a predetermined game device 2. The notice is a notice transmitted from a predetermined game device as a result of an operation in which a predetermined user decides to inherit a predetermined relay battle. As a result of this determination, if the transfer decision notice has not been received (NO in step S5), the process proceeds to step S9 described later. On the other hand, if the transfer decision notice has been received (YES in step S5), next, in step S6, the processor 11 determines whether the relay battle specified as the transfer target in the notice is currently locked based on the lock flag 514. This is, for example, assuming a case where different users make a relay battle transfer decision at approximately the same timing. Also, for example, it is assumed that while a user is checking information related to a predetermined relay battle (such as replay viewing), another user decides to transfer the relay battle. As a result of this determination, if it is locked (YES in step S6), in step S7, the processor 11 transmits a non-transferable notice to the source of the transfer decision notice. Then, the process proceeds to step S9 described later.

[0119] On the other hand, if it is not locked (NO in step S6), in step S 8 , the processor 11 sets the lock flag 514 related to the relay tote specified in the handover determination notification to ON. Further, the processor 11 transmits a handover possible notification to the source of the handover determination notification.

[0120] Next, in step S9, the processor 11 determines whether it has received a progress confirmation request from a predetermined game device 2. The progress confirmation request is a request for data for progress confirmation as described above. As a result of this determination, if the progress confirmation request has been received (YES in step S9), in step S10, the processor 11 acquires data related to the relay tote specified in the progress confirmation request from the relay tote data 502. Then, the processor 11 transmits the data to the game device 2 that is the source of the request. Thereafter, the process returns to step S1 above, and the process is repeated.

[0121] On the other hand, if the progress confirmation request has not been received as a result of the determination in step S9 (NO in step S9), the process of step S10 is skipped.

[0122] Thus, the description of the process executed by the server 1 ends.

[0123] [Regarding the Process Executed by the Game Device 2] Next, the process executed by the game device 2 will be described. Here, only the process related to the relay tote (relay tote related process) will be described, and the description of other game processes will be omitted.

[0124] FIG. 21 is a flowchart showing details of the relay tote related process executed by the game device 2. First, in step S21, the processor 21 of the game device 2 displays a relay tote menu as shown in, for example, FIG. 22.

[0125] Next, in step S22, the processor 21 acquires operation data 611. In the subsequent step S23, the processor 21 determines, based on the operation data 611, whether an operation to initiate a relay battle has been performed in the relay battle menu. As a result of this determination, if an initiation operation has been performed (YES in step S23), in step S24, the processor 21 executes an initiation battle process.

[0126] FIG. 23 is a flowchart showing details of the initiation battle process. First, in step S31, the processor 21 displays a map selection screen that lists the maps designated for the relay battle based on the map master data 602.

[0127] Next, in step S32, the processor 21 acquires operation data 611. In the subsequent step S33, the processor 21 determines, based on the operation data 611, whether any map has been selected. If no map has been selected (NO in step S33), the process returns to step S31 and the process is repeated.

[0128] On the other hand, if any map has been selected (YES in step S33), in step S34, the processor 21 executes a TBSG process using the selected map. FIGS. 24 to 25 are flowcharts showing details of the TBSG process. First, in step S41, the processor 21 reads the data of the selected map from the map master data 602 and generates and displays a sortie preparation screen (not shown) based on this. At this time, when playing in succession, a sortie preparation screen reflecting the battle situation (positions of friendly and enemy units, etc.) at the time of succession is generated based on the received battle log data 609.

[0129] Next, in step S42, the processor 21 acquires the operation data 611. Further, the processor 21 executes various processes related to the preparation for dispatch based on the operation content indicated by the operation data 611. Specifically, processes such as determining the unit to be dispatched and determining its deployment position are executed. Regarding the deployment position, as described above, it is automatically deployed to the supportable square once, and then the deployment position can be changed based on the user's operation.

[0130] Next, in step S43, the processor 21 determines whether a dispatch instruction has been given on the dispatch preparation screen based on the operation data 611. If no dispatch instruction has been given (NO in step S43), the process returns to step S41 above and the process is repeated.

[0131] On the other hand, if a dispatch instruction has been given (YES in step S43), in step S44, the processor 21 ends the dispatch preparation screen and displays a screen related to the TBSG (see FIG. 4 above). At this time, in the case of a spontaneous start, a screen in which the friendly and enemy units are arranged at the preset initial deployment positions (a screen reflecting the operation content on the dispatch preparation screen) is displayed. On the other hand, in the case of a handover, a screen that further reflects the operation content on the dispatch preparation screen on the content reflected based on the battle situation (positions of friendly and enemy units, etc.) at the time of handover in the received battle log data 609 is displayed.

[0132] Next, in step S45, the processor 21 acquires the operation data 611 and executes the process for the friendly phase based on the operation content. Specifically, the processor 21 executes processes such as moving the friendly unit based on the operation data 611 and engaging in battle with a predetermined enemy unit. Also, the processor 21 temporarily stores in the storage unit 22 the operation content of the user and the action content (operation log, action log) of the friendly unit in the friendly phase in order to create the transmission result data 608 later. Further, the processor 21 also appropriately generates and displays a game screen (such as a battle scene) that reflects the process based on the above operation content.

[0133] Next, in step S46, the processor 21 determines whether the end condition (win condition or loss condition) set for the currently playing map is satisfied. If the end condition is not satisfied (NO in step S46), in step S47, the processor 21 executes the processing for the enemy phase. Specifically, the processor 21 causes the enemy units to act under AI control. Also, the processor 21 temporarily stores in the storage unit 22 the action details of the enemy units in the enemy phase, etc., in order to create the transmission result data 608 later.

[0134] Next, in step S48, the processor 21 determines whether the above end condition is satisfied. If the end condition is not satisfied (NO in step S48), in step S49, the processor 21 determines whether a predetermined number of turns has elapsed since the start of the current play. In this embodiment, since the case where the predetermined number of turns is 2 is taken as an example, it is determined whether the play for two turns has ended since the start of the play by the spontaneous user or the inherited user respectively. As a result of this determination, if the predetermined number of turns has not elapsed (NO in step S49), the process returns to step S44 above and the processing is repeated. On the other hand, if the predetermined number of turns has elapsed (YES in step S49), the process proceeds to step S51 described later.

[0135] On the other hand, if it is determined in the result of the determination in step S46 or step S48 that the end condition is satisfied (YES in step S46 or step S48), in step S50, the processor 21 gives a predetermined reward according to the result of the play to the user who satisfied the end condition. Specifically, the data indicating the items owned by the user is updated. Note that the reward according to the result of the play, that is, the grade of the reward to be given is as described above. After that, the process proceeds to step S51 described later.

[0136] Next, in step S51 of FIG. 25, the processor 21 ends the TBSG screen and displays a comment selection screen (see FIG. 13 above). Next, in step S52, the processor 21 acquires the operation data 611 and selects a predetermined comment from the comment selection screen based on the operation content.

[0137] Next, in step S53, the processor 21 generates the above-described transmission result data 608 and transmits it to the server 1. Specifically, the processor 21 generates TBSG log data 633 indicating the action content of each unit and the operation content of the user, etc. in the own army phase and the enemy army phase based on the data temporarily recorded in steps S45 and S47 above. Even when the end condition is satisfied in this play, data indicating the play content until the end condition is reached is generated as TBSG log data 633. Further, the processor 21 also generates designated comment data 634 based on the selected comment. Also, when this TBSG play is spontaneous, the processor 21 generates a battle ID 632 using, for example, the terminal unique number and the user ID (so as to be a unique ID). On the other hand, in the case of a play by inheritance, the battle ID information included in the received battle log data 609 is directly used. Then, the processor 21 appropriately sets the user information 631, generates the transmission result data 608, and transmits it to the server 1. After that, the processor 21 ends the TBSG process.

[0138] Returning to FIG. 23, next, in step S35, the processor 21 updates the spontaneous / relay history data 607. Specifically, the processor 21 generates a record in which a new history number 621 and a battle ID 623 indicating the relay battle spontaneously initiated this time are set, and adds it to the spontaneous / relay history data 607. At this time, if a reward is given in step S50 in this play, the processor 21 sets the reward flag 624 to on and then adds the record. Conversely, if not, the processor 21 sets the reward flag 624 to off and then adds the record. After that, the processor 21 ends the spontaneous battle process.

[0139] Return to FIG. 21. If the spontaneous battle process is completed, return to step S21 above and the process is repeated.

[0140] On the other hand, if as a result of the determination in step S23, no spontaneous operation has been performed (NO in step S23), in step S25, the processor 21 determines whether an operation to take over the relay battle from the relay battle menu has been performed based on the operation data 611. If as a result of this determination, a takeover operation has been performed (YES in step S25), in step S26, the processor 21 executes a takeover battle process.

[0141] FIGS. 26 to 27 are flowcharts showing details of the takeover battle process. First, in step S61, the processor 21 sends a data request for relay battles that can be taken over to the server. Next, in step S62, the processor 21 receives the data of the relay battles sent from the server 1 in response to the above request. Further, the processor 21 generates received battle log data 609 based on the received data (for example, copies each battle log data 516 included in the received data to the received battle log data 609).

[0142] Next, in step S63, the processor 21 generates and displays a list of the received relay battles based on the received data of the relay battles.

[0143] Next, in step S64, the processor 21 acquires the operation data 611 and determines whether an operation has been performed to decide not to take over any of the relay battles displayed in the list. If as a result of this determination, an operation not to take over any relay battles has been performed (YES in step S64), the processor 21 ends the takeover battle process. In other embodiments, in this case, it may return to step S61 above to request data of other relay battles (that is, a process of updating the list may be performed).

[0144] On the one hand, when no operation to take over any relay battle is being performed (NO in step S64), next, in step S65, the processor 21 acquires the operation data 611 and determines whether an operation to refer to the information of any relay battle has been performed from among the list. As a result of this determination, if no operation to refer to the information has been performed (NO in step S65), the process returns to step S63 above and the processing is repeated. On the other hand, if an operation to refer to the information has been performed (YES in step S65), in step S66, the processor 21 displays information regarding the selected relay battle based on the received battle log data 609. Specifically, the number of turns that have progressed so far, information on the friendly and enemy units that have been deployed, the status of the support points, etc. are displayed. Furthermore, based on the received battle log data 609, a replay of the game progress so far is also displayed. Also, at the timing when the replay for each predecessor has ended, the above comments set by each predecessor are also displayed. For example, if there are three predecessors and the default number of turns is 2, the comment of the first predecessor is displayed at the end of the replay of turns 1 to 2 after the relay battle starts, the comment of the second predecessor is displayed at the end of the replay of turns 3 to 4, and the comment of the third predecessor is displayed at the end of the replay of turns 5 to 6.

[0145] Next, in step S67, the processor 21 determines based on the operation data 611 whether an operation to decide to take over any one of the above relay battles has been performed. As a result of this determination, if no operation to decide to take over has been performed (NO in step S67), the process returns to step S63 above and the processing is repeated. On the other hand, if an operation to decide to take over has been performed (YES in step S67), in step S68 of FIG. 27, the processor 21 transmits a takeover decision notice including information specifying the relay battle that has been decided to be taken over to the server 1.

[0146] Next, in step S69, the processor 21 determines whether it has received a transferable notification from the server 1. As a result of this determination, if it has not received a transferable notification from the server 1 (i.e., it has received the non-transferable notification) (NO in step S69), in step S72, the processor 21 displays that the transfer cannot be performed. Then, it returns to step S61 above, and the process is repeated.

[0147] On the other hand, if it has received a transferable notification (YES in step S69), next, in step S70, the processor 21 executes the TBSG process. Since this process is the same as the process in step S34 described above, the description is omitted.

[0148] Next, in step S71, the processor 21 updates the spontaneous / transfer history data 607. Specifically, the processor 21 generates a record with the battle ID 623 indicating the relay battle that was transferred this time, and adds it to the spontaneous / transfer history data 607. Also, similarly to the above, if a reward has been given in this play, the processor 21 sets the reward flag 624 to on and then adds the record. After that, the processor 21 ends the transfer battle process.

[0149] Returning to Figure 21, if the transfer battle process ends, it returns to step S21 above, and the process is repeated.

[0150] On the other hand, as a result of the determination in step S25 above, if an operation to transfer the relay battle has not been performed (NO in step S25), in step S27, the processor 21 determines whether an operation to check the progress has been performed from the relay battle menu based on the operation data 611. As a result of this determination, if an operation to check the progress has been performed (YES in step 27), in step S28, the processor 21 executes the progress check process.

[0151] Figure 28 is a flowchart showing the details of the above progress confirmation process. First, in step S81, the processor 21 refers to the spontaneous / handover history data 607 and sends a progress confirmation request specifying the battle ID 623 of one or more relay battles that the user has spontaneously or taken over to the server 1.

[0152] Next, in step S82, the processor 21 receives the relay battle data sent from the server 1 in response to the above request.

[0153] Next, in step S83, the processor 21 generates and displays a selection screen for the relay battle for which progress is to be confirmed based on the received relay battle data. Although not shown in the figure, in this screen, the relay battles that the user has spontaneously or taken over are listed. When listing the relay battles, a predetermined image (such as an icon) may be added to the image indicating each relay battle so that the user can distinguish between relay battles for which rewards have not been given, relay battles for which rewards have been given, and relay battles that have not yet ended.

[0154] Next, in step S84, the processor 21 acquires the operation data 611 and determines whether an operation instructing the start of replay of any of the relay battles has been performed based on the operation content. As a result of this determination, if an instruction to start replay has been given (YES in step S84), in step S85, the processor 21 performs a replay process based on the data of the relay battle selected by the user.

[0155] Next, in step S86, the processor 21 determines whether or not the replay process in step S85 has ended. For example, when the replay is played to the end, or when an instruction to cancel the replay is received from the user during the replay, it is determined that the replay process has ended. As a result of this determination, if it has not ended (NO in step S86), the processor 21 returns to step S85 above and continues the replay process. On the other hand, if it has ended (YES in step S86), it returns to step S83 above and the process is repeated.

[0156] On the other hand, as a result of the determination in step S84, if an instruction to start replay has not been given (NO in step S84), in step S87, the processor 21 acquires the operation data 611 and determines, based on the operation content, whether or not an instruction to confirm the reward of any relay battle has been given. As a result of this determination, if an instruction to confirm the reward has not been given (NO in step S87), next, in step S88, the processor 21 determines whether or not an end operation of the progress confirmation process has been performed based on the operation data 611. If the end operation has not been performed (NO in step S88), it returns to step S83 above and the process is repeated. If the end operation has been performed (YES in step S88), the processor 21 ends the progress confirmation process.

[0157] On the other hand, as a result of the determination in step S87, if an instruction to confirm the reward has been given (YES in step S87), in step S89 of FIG. 29, the processor 21 determines, based on the end flag 515, whether or not the relay battle for which the instruction to confirm the reward has been given is a relay battle for which the end condition has been satisfied. As a result of this determination, if it is a relay battle for which the end condition has not yet been satisfied (NO in step S89), in step S93, the processor 21 displays that the relay battle has not yet ended. Then, the process returns to the process of step S83 above.

[0158] On the other hand, in the case of a relay battle where the end condition is satisfied (YES in step S89), in step S90, the processor 21 determines whether the relay battle for which the above reward confirmation instruction was given is a relay battle for which the reward has not yet been granted, based on the above reward flag 624. As a result of this determination, in the case of a relay battle for which the reward has not yet been granted (YES in step S90), in step S91, the processor 21 executes a process of granting a reward. In this process, the same process as in step S50 above is executed. Regarding the determination of victory / defeat that is a prerequisite for the granting of the reward, it may be determined based on the battle log data 516 of the received relay battle data 502. In this regard, in other embodiments, when the relay battle ends, information indicating whether the end is due to victory or defeat may be included in the transmission result data 608 and sent and registered in the server 1. In this case, as information indicating the end state of the relay battle, instead of the above end flag 515, for example, "end state data" indicating any one of "not ended", "victory", and "defeat" may be used. Then, in the process of step S87, the processor 21 may determine whether to grant a victory reward or a defeat reward by referring to the end state data.

[0159] Next, in step S92, the processor 21 updates the spontaneous / transfer history data 607. Specifically, the processor 21 The reward confirmation instruction has been given sets the reward flag 624 related to the relay battle to on.

[0160] On the other hand, as a result of the determination in step S90, in the case of a relay battle for which the reward has already been granted (NO in step S90), in step S94, the processor 21 displays that the reward has already been granted. Then, the process returns to the process of step S83 above.

[0161] Returning to FIG. 21, if the above progress confirmation process ends, the process returns to step S21 above and the process is repeated.

[0162] On the other hand, if as a result of the determination in step S27, the progress confirmation operation has not been performed (NO in step S27), in step S29, the processor 21 determines whether an operation to end the relay battle menu has been performed based on the operation data 611. If as a result of this determination, the end operation of the relay battle menu has not been performed (NO in step S29), the process returns to step S21 and the processing is repeated. If the end operation of the relay battle menu has been performed (YES in step S29), the processor 21 ends the relay battle related processing.

[0163] Thus, the detailed description of the game processing of this embodiment is completed.

[0164] As described above, in this embodiment, in the TBSG, for one map, a cooperative multiplayer game is provided in which different users operate in their own army phases turn by turn aiming to clear the game. So to speak, a new multiplayer game is provided where the battle continues while the commanders on the battlefield are replaced. Thereby, it is possible to provide users with a way of enjoying the game, for example, by a plurality of users cooperating to defeat a powerful enemy.

[0165] In addition, when participating in the above relay battle, the inheriting user can deploy the units he / she owns that have grown in the above first game mode. Thereby, it is also possible to provide a way of enjoying the game where each user shows off the units they have grown to other users and enjoys it.

[0166] Furthermore, in this embodiment, since it is possible to take over and play the relay battle, for example, even if the spontaneous user is not good at TBSG, a takeover user who is good at TBSG can take over and play, or the takeover user can send out more powerful units, etc., and finally clear the game (and obtain the victory reward). Therefore, even users who are not good at TBSG or beginners can easily participate and enjoy TBSG. Also, for users who are not good at head-to-head battles between users, since it is in the form of cooperative play, it is also possible to let multiple users enjoy the game play.

[0167] Also, if a user takes over and plays the game that another user has played without synchronizing the game situation with the other user, depending on the progress of the game, the future development of the game is directed by the play of the other user, and it is considered that there is little room for the user to intervene in the progress of the game. In this regard, in this embodiment, as described above, it is possible to additionally send out one's own owned units when taking over. Therefore, there is room to greatly change the development of the game that was directed by the play of the other user. This increases the tactics that the user can adopt and can improve the interestingness of the game.

[0168] Also, in this embodiment, when taking over the relay battle, the previous battles are presented in a replay. Therefore, even when participating midway in the relay battle, the user can determine subsequent strategies and tactics, such as which units are appropriate to send out. This improves the strategic nature and interestingness of TBSG. Also, after participating in the relay battle, the subsequent progress can also be confirmed in the above replay. With such a replay function, since it is possible to see how other users play, the possibility of obtaining new discoveries and realizations also increases. By obtaining such new discoveries and realizations, the user can try new ways of playing and further improve the interestingness of the game.

[0169] In addition, as described above, two ways of enjoying the game can be provided: one is to participate at an early stage after the relay battle is initiated, and the other is to participate after a certain number of turns have passed. This enables the provision of an appropriate way of enjoying the game according to the user's play style.

[0170] [Modification Example] In the above embodiment, an example is given in which any user can take over the relay battle after it is initiated. In other embodiments, when registering the initiated relay battle with Server 1, the registration may be limited to users who can take it over. For example, when transmitting the above result data to Server 1, based on a predetermined operation of the initiating user, a setting may be added such that only other users who are "friends" registered by the initiating user can take it over, and the result data may be transmitted accordingly. Additionally, alternatively, a password may be set for the initiated relay battle and the result data may be transmitted. Then, when the relay battle is taken over, the taking-over user may be required to input the password.

[0171] In the above embodiment, an example is shown in which after the relay battle is initiated, the progress of the game is once terminated after a predetermined number of turns have passed, and the result data is transmitted. In this regard, in other embodiments, after the relay battle is initiated voluntarily, for example, the progress of the game may be terminated at the timing when a predetermined time such as 10 minutes has passed. Alternatively, the progress of the game may be terminated at the timing when a predetermined in-game event occurs (in other words, if the predetermined in-game event is not allowed to occur, the game may be playable until the end condition is satisfied). An example of a predetermined in-game event may be the defeat of a mid-boss character placed on the map or the placement of a character at a predetermined position on the map.

[0172] In addition, the order of processing for ending the game progress and transmitting the above result data is not limited to the above example, and either may be processed first, or the processing may proceed in parallel. Also, for example, regarding the result data, it may be transmitted every time one turn ends.

[0173] Also, in the above embodiment, after a relay battle is initiated, a relay battle (map) may be prepared in which the initiator can clear (or lose) the game without passing it on to anyone. And when the game ends without being passed on to anyone, although the reward is given, the transmission process of the result data to the server 1 may be omitted. This is because there is no need to pass it on, and thus there is no need to transmit the result data.

[0174] Also, in the above embodiment, the case where the inheriting user can inherit the same relay battle only once and the initiating user cannot inherit it by himself / herself has been described as an example. In other embodiments, if it is not a consecutive inheritance, the same user may be able to inherit it multiple times. For example, after user B inherits the relay battle initiated by user A, and then user C inherits it, user B may be able to inherit it again. Also, for the initiating user A, if an inheritance by other users such as user B or user C has occurred, he / she may be able to inherit the battle he / she initiated by himself / herself in the form of inheriting this.

[0175] In addition, in the above-described embodiment, an example was shown in which the timing for temporarily locking relay battle data so as not to be selected as a relayable relay battle is the timing when a relay determination notification is received from the game device 2. In this regard, in other embodiments, for example, at the timing of transmitting a plurality of listed relay battle data to the game device 2, control may be performed to lock all of the listed relay battle data. Further, when a relay determination notification is received from a predetermined game device 2, a notification indicating that the relay battle specified in the notification has become non-relayable may be transmitted to the game devices that have already transmitted the relay battle as candidates for relayable relay battles. Then, the game device that has received the notification may promptly display that fact after reception. For example, when another user determines to take over a specific relay battle while the user is viewing a replay of the relay battle, a display such as "This relay battle has been taken over by another user" may be popped up and displayed.

[0176] In addition, after the relay battle data is locked as described above, in case it is left unattended without the above-mentioned predetermined number of turns elapsing (when the result data is never transmitted), a time limit may be set for the locked time. For example, for a certain relay battle, if 24 hours or more have passed since it was locked, a process may be performed to forcibly set the above-mentioned lock flag 514 to off. In addition, as a case where such a relay battle is left unattended, for example, before the play of the above-mentioned predetermined number of turns ends, the play is interrupted due to the battery of the game device 2 running out or the like, and the result of the play cannot be transmitted.

[0177] In addition, in the above-described embodiment, an example was given in which the above-mentioned predecessor unit can also be operated by the user himself / herself. However, in other embodiments, the predecessor unit may be under AI control. Thereby, the trouble of operating the predecessor unit can be saved, and the convenience for the user can be improved.

[0178] In addition, in the above-described embodiment, an example in which a comment can be left when each user's play ends was given. Regarding such a comment, it may be made mandatory to leave it, or it may be made possible to leave it optionally.

[0179] In addition, in the above-described embodiment, an example in which the number of turns played by the originator and the number of turns played by the successor user (the above-mentioned predetermined number of turns) are the same was given, but the two may be different numbers of turns. For example, the originator may be able to play only 5 turns and the successor user may be able to play only 3 turns.

[0180] In addition, in the above-described embodiment, a TBSG using characters that can be cultivated by a user was described as an example of a game. Regarding the type of such a game, for example, the above-described cooperative play processing is applicable also to games such as shogi, go, and chess, which are advanced while alternating turns. However, depending on the game, it may not be possible to add characters (pieces) etc. owned by the user at the time of inheritance.

[0181] In addition, in the above-described embodiment, the case where the relay battle-related process itself is executed by a single game device 2 has been described. In other embodiments, the above relay battle-related process may be executed in an information processing system including a plurality of information processing terminals. For example, in an information processing system including a terminal-side device and a server-side device that can communicate with the terminal-side device via a network, a part of the above relay battle-related process may be executed by the server-side device. Furthermore, in an information processing system including a terminal-side device and a server-side device that can communicate with the terminal-side device via a network, the main process of the above series of processes may be executed by the server-side device, and a part of the process may be executed by the terminal-side device. Also, in the above information processing system, the server-side system may be configured by a plurality of information processing terminals, and the plurality of information processing terminals may share and execute the processes to be executed on the server side. It may also be configured as so-called cloud gaming. For example, the game device 2 may be configured to send operation data indicating a user's operation to a predetermined server, various game processes are executed on the server, and the execution results are streamed and distributed to the game device 2 as video and audio.

Explanation of Signs

[0182] 2 Game device 4 Controller 5 Display unit 21 Processor 22 Storage unit 23 Wireless communication unit 24 Controller communication unit 25 Image and audio output unit

Claims

1. A game program for executing a game on a user's information processing terminal, causing the computer of the information processing terminal to a first game start means for starting the game based on the predetermined initial setting data, which is the game using the user's user character, based on a first start instruction input by the user; a first game progress means for progressing the game started by the first start instruction input based on the operation input of the user; a first transmission means for ending the progress of the game at a first timing after the game is started by the first start instruction input, and transmitting progress status data indicating the progress status of the game at the first timing to the server; a second game start means for starting the game using the other user character used in the game by the other user and the user's user character based on a second start instruction input of the user, which is the game based on the progress status data transmitted to the server by another information processing terminal operated by another user different from the user and acquired by the user's information processing terminal from the server; a second game progress means for progressing the game started based on the second start instruction input based on the operation input of the user; functioning as a second transmission means for ending the progress of the game at a second timing after the game is started based on the second start instruction input, transmitting progress status data indicating the progress status of the game at the second timing to the server, and if the victory condition of the game is satisfied before the second timing arrives, transmitting progress status data indicating the progress status of the game until the victory condition is satisfied to the server; the game is a turn-based strategy game, the first timing is a timing when a first number of turns have elapsed since the start of the game by the first start instruction input, the second timing is a timing when a second number of turns have elapsed since the start of the game by the second start instruction input, the game progress status data is data capable of reproducing the progress of the game up to the first timing The second game start means is a game program that starts the game in a state where the progress of the game at the first timing is reproduced. **Claim 2** The first game progress means and the second game progress means In the game, when it is the user's turn, the game is advanced based on the operation of the user, and when it is the turn of the other player, the game is advanced based on the operation of the computer based on AI control. The game program according to claim 1, wherein when one turn of the user's turn and the turn of the other player is completed, it is determined that one turn has elapsed in the count of the first turn number and the second turn number. **Claim 3** The first game progress means advances the game by controlling the user character in the virtual space based on the operation input of the user. The second game progress means advances the game by controlling the user character and the other user character in the virtual space based on the operation input of the user. The game program according to claim 1. **Claim 4** The second game start means arranges the user character of the user at a predetermined position in the virtual space determined based on the acquired progress status data, and then starts the game. The game program according to claim 3. **Claim 5** The second game start means arranges the user character at a supportable position predetermined as a position where the user character can be arranged. The number of supportable positions can change according to the progress of the game. The game program according to claim 4. **Claim 6** When the first game progress means and / or the second game progress means ends the progress of the game, a plurality of prepared options are presented to the user. When any option is designated by the user from the plurality of options, the first transmission means and / or the second transmission means transmits option data regarding the designated option to the server in association with the progress status data. When there is option data associated with the progress status data acquired from the server, the second game start means outputs an image based on the option data. The game program according to claim 1. **Claim 7** The second game start means outputs, before the start of the game, a replay indicating the progress of the game up to the timing when the progress of the game indicated by the progress data acquired from the server ends, based on the progress data. The game program according to claim 1.

8. The second game start means starts the game when there is the second start instruction input by the user after the output of the replay. The game program according to claim 7.

9. After the game progress by the first game progress means or the second game progress means ends, when there is a progress status confirmation instruction input by the user, the progress data is acquired from the server in response to the input, and based on the progress data, a replay indicating the progress of the game is output. The game program according to claim 1.

10. The game program is a first reward giving means for giving a user a first reward based on satisfying the victory condition of the game when the victory condition of the game is satisfied by the second timing; The computer is further caused to function as a second reward giving means for giving the user a second reward having a lower value than the first reward when the progress status of the game by the other user satisfies the victory condition of the game after the information processing terminal of the user transmits the progress data based on the game to the server. The game program according to claim 1.

11. When the second transmission means satisfies the defeat condition by the second timing, it transmits the progress data up to the time when the defeat condition is satisfied to the server, The game program further causes the computer to function as a third reward giving means for giving the user a third reward having a lower value than the first reward based on satisfying the defeat condition of the game when the game satisfies the defeat condition by the second timing. The game program according to claim 10.

12. The game program causes the computer to execute a game application including the game started by the first game start means or the second game start means and a cultivation game different from the game and capable of cultivating the user character. The game program according to claim 1, wherein the first game start means and the second game start means start the game using the user character cultivated in the cultivation game.

13. The game program according to claim 12, wherein when the number of other user characters used in the game by the other user reaches a predetermined number, the second game start means starts the game without making the user character of the user appear in the game, or starts the game by exchanging the other user character and the user character.

14. The first game start means starts the game using the user character selected by the user among a plurality of user characters. The game program according to claim 1, wherein the second game start means starts the game using the other user character used by the other user in the game and a user character different from the other user character among the plurality of user characters.

15. The game program according to claim 1, wherein the first transmission means designates the range of the other users who can acquire the progress status data based on the operation input of the user, and then transmits the progress status data to the server.

16. A game system having a server and a plurality of information processing terminals, The computer of the first information processing terminal, A first game start means for starting the game using the user character of the first user, which is the game based on predetermined initial setting data based on a first start instruction input by the first user; A first game progress means for progressing the game started by the first start instruction input based on the operation input of the first user; A first transmission means for ending the progress of the game at a first timing after the game is started by the first start instruction input and transmitting progress status data indicating the progress status of the game at the first timing to the server. A game that is transmitted to the server by a second information processing terminal operated by a second user different from the first user, and is acquired by the first information processing terminal from the server, based on the progress data. The game uses the user character of the second user used in the game by the second user and the user character of the first user, and a second game start means for starting the game based on a second start instruction input of the first user. A second game progress means for progressing the game started based on the second start instruction input based on an operation input of the first user. After the game is started based on the second start instruction input, at a second timing, the progress of the game is terminated, progress data indicating the progress status of the game at the second timing is transmitted to the server, and if the victory condition of the game is satisfied before the second timing arrives, progress data indicating the progress status of the game until the victory condition is satisfied is transmitted to the server. It comprises a second transmission means. The game is a turn-based strategy game. The first timing is a timing when a first number of turns have elapsed since the start of the game by the first start instruction input. The second timing is a timing when a second number of turns have elapsed since the start of the game by the second start instruction input. The game progress data is data capable of reproducing the progress of the game up to the first timing. The second game start means starts the game in a state where the progress of the game at the first timing is reproduced. A game system. [

17. ] A game device Game start means for starting a game based on predetermined initial setting data based on a first start instruction input by a user, and using the user character of the user. First game progress means for progressing the game started by the first start instruction input based on an operation input of the user. At a first timing after the game is started by the first start instruction input, the progress of the game is terminated, and first transmission means for transmitting progress data indicating the progress status of the game at the first timing to a server. A game that is transmitted to the server by another information processing terminal operated by another user different from the user, and is acquired by the information processing terminal of the user from the server, based on the progress data. In this game, another user character used in the game by the other user and the user character of the user are used. A second game start means for starting the game based on a second start instruction input of the user; A second game progress means for progressing the game started based on the second start instruction input based on an operation input of the user; After the game is started based on the second start instruction input, at a second timing, the progress of the game is terminated, and progress data indicating the progress status of the game at the second timing is transmitted to the server. If the victory condition of the game is satisfied before the second timing arrives, progress data indicating the progress status of the game until the victory condition is satisfied is transmitted to the server. A second transmission means; The game is a turn-based strategy game; The first timing is a timing when a first number of turns have elapsed since the start of the game by the first start instruction input; The second timing is a timing when a second number of turns have elapsed since the start of the game by the second start instruction input; The game progress data is data capable of reproducing the progress of the game up to the first timing; The second game start means is a game device that starts the game in a state where the progress status of the game at the first timing is reproduced.

18. A game processing method for causing a computer of a user's information processing terminal to execute, comprising: Causing the computer to: Based on a first start instruction input by the user, start the game based on predetermined initial setting data, using the user character of the user; Progress the game started by the first start instruction input based on an operation input of the user; At a first timing after the game is started by the first start instruction input, terminate the progress of the game, and cause the progress data indicating the progress status of the game at the first timing to be transmitted to the server; A game that is transmitted to the server by another information processing terminal operated by another user different from the user, and is acquired by the information processing terminal of the user from the server, based on the progress data. In this game, the other user character used in the game by the other user and the user character of the user are used, and the game is started based on a second start instruction input by the user. The game started based on the second start instruction input is advanced based on the operation input of the user. After the game is started based on the second start instruction input, at a second timing, the progress of the game is terminated, and progress data indicating the progress status of the game at the second timing is transmitted to the server. If the victory condition of the game is satisfied before the second timing arrives, the progress data indicating the progress status of the game until the victory condition is satisfied is transmitted to the server. The game is a turn-based strategy game. The first timing is the timing when the number of turns of the first turn number has elapsed since the start of the game by the first start instruction input. The second timing is the timing when the number of turns of the second turn number has elapsed since the start of the game by the second start instruction input. The game progress data is data that can reproduce the progress of the game up to the first timing. In the start of the game by the second start instruction input, the game is started in a state where the progress status of the game at the first timing is reproduced. A game processing method.

Images