System, method, and storage medium storing game program for progressing game using character

Abstract

To improve convenience when a user makes a character execute an action.SOLUTION: A system according to an aspect of the present invention progresses a game using a character having a first part and a second part. A game system according to one aspect of the present invention includes one or more processors, and the one or more processors cause a character to execute a first action using a first body part in a first period based on a first command, cause the character to execute a first preparatory action using a second body part in a first preparatory action period overlapping at least a part of the first period based on a second command, and cause the character to execute a second action using the first body part in a second period after the first period after completion of the first action and the first preparatory action.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The disclosure of this specification mainly relates to a game system, a game processing method, and a game program that progress a game using characters. [Background technology]

[0002] Many games feature user characters that act in response to user operations. For example, in a battle event in a game, a battle takes place between a user character operated by a user and an enemy character. In this battle, the user character can perform actions in response to commands input by the user. The user character can perform various actions such as attacking an enemy character, healing an ally character, and using a special move. A battle between a player character and an enemy character in a conventional game is described, for example, in Japanese Patent Application Laid-Open No. 2024-003217 (Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2024-003217 Summary of the Invention [Problem to be solved by the invention]

[0004] As described in Patent Document 1, in conventional game battles, when a user inputs a command, the user's character executes an action corresponding to the input command, and after the execution of that action, a command for executing a subsequent action is accepted. This prevents multiple actions from being executed in parallel. Therefore, after a user inputs a command to execute a preceding action, the user cannot execute the subsequent action until the preceding action is completed. For some actions, such as the execution of a special move, the action is executed after a predetermined preparation period has elapsed since the command was accepted (see, for example, paragraphs

[0105] to

[0121] of Patent Document 1). This means that it takes a particularly long time from the acceptance of a command for such an action until another action can be executed. In game battles, the inability to execute a subsequent action until the execution of a preceding action is completed presents an inconvenient constraint for users who control characters and fight enemy characters.

[0005] One of the objectives of the various inventions described herein is to improve the convenience for users when causing characters to perform actions, and one more specific objective of the various inventions described herein is to provide a system, method, and program that can start preparation for performing a subsequent action before the completion of a previous action.

[0006] The various inventions disclosed in this specification may solve or alleviate at least part of the problems described in the "Mode for Carrying Out the Invention" of this specification, or problems that can be understood from the description of the "Mode for Carrying Out the Invention," instead of or in addition to the above-mentioned problems. When the present specification describes the effects of an embodiment of the present invention, the problems of the invention corresponding to that embodiment can be understood based on the description of the effects. [Means for solving the problem]

[0007] The inventions described in this specification or that can be understood from the description of this specification may be collectively referred to as "the present invention." A game system according to one aspect of the present invention progresses a game using a character having a first part and a second part. The game system according to one aspect of the present invention includes one or more processors. The one or more processors cause the character to perform a first action using the first part during a first period based on a first command. The one or more processors also cause the character to perform a first preparatory action using the second part during a first preparatory action period that overlaps with at least a portion of the first period based on a second command. The one or more processors also cause the character to perform a second action using the first part during a second period that follows the first period, after completion of the first action and the first preparatory action. [Effects of the Invention]

[0008] According to an embodiment of the present invention, it is possible to improve the convenience for the user when causing a character to perform an action. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a block diagram showing a game system 1 according to an embodiment of the present invention. [Figure 2] 1 is a schematic diagram showing an example of a game screen in a battle event of a game provided by the game system 1. FIG. [Figure 3] FIG. 10 is a schematic diagram illustrating an example of processing timing of a plurality of actions executed in a battle event. [Figure 4] FIG. 10 is a schematic diagram illustrating another example of the processing timing of multiple actions executed in a battle event. [Figure 5] FIG. 10 is a schematic diagram illustrating yet another example of the processing timing of multiple actions executed in a battle event. [Figure 6]FIG. 10 is a schematic diagram illustrating yet another example of the processing timing of multiple actions executed in a battle event. [Figure 7] FIG. 10 is a schematic diagram illustrating yet another example of the processing timing of multiple actions executed in a battle event. [Figure 8] FIG. 10 is a schematic diagram illustrating yet another example of the processing timing of multiple actions executed in a battle event. [Figure 9] FIG. 10 is a schematic diagram illustrating yet another example of the processing timing of multiple actions executed in a battle event. [Figure 10] FIG. 10 is a schematic diagram illustrating yet another example of the processing timing of multiple actions executed in a battle event. [Figure 11] 1 is a block diagram showing a server included in the game system 1. FIG. [Figure 12] 2 is a diagram illustrating user management data stored in the game system of FIG. 1. FIG. [Figure 13] 2 is a diagram illustrating game content management data stored in the game system of FIG. 1. FIG. [Figure 14] 1 is a block diagram showing a user device provided in the game system 1. FIG. [Figure 15] 2 is a diagram illustrating action management data stored in the game system of FIG. 1. FIG. [Figure 16] FIG. 10 is a flowchart illustrating the flow of battle processing in one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0010] Various embodiments of the present invention will be described below with reference to the drawings as appropriate. Note that components common to multiple drawings are assigned the same reference numerals throughout the multiple drawings. The embodiments of the present invention described below do not limit the invention according to the claims. Elements described in the following embodiments are not necessarily essential to the solution of the invention.

[0011] A game system 1 according to one embodiment of the present invention will be described with reference to Figures 1 to 8. The game system 1 is an example of a game system to which the present invention is applied.

[0012] 1 Overview of Game System 1 First, an overview of a game system 1 according to one embodiment will be described with reference to FIG. 1. FIG. 1 is a block diagram illustrating the game system 1. As illustrated in FIG. 1, the game system 1 includes a user device 10 and a server 20. The game system 1 may also include a storage 30. Although FIG. 1 shows one user device 10 for simplicity of illustration, the game system 1 may include multiple user devices. The user device 10, the server 20, and the storage 30 are communicatively connected to each other via a network 5. The network 5 may be a single network or may be configured by connecting multiple networks. The network 5 may be, for example, the Internet, a mobile communication network, or a combination thereof. The network 5 may be any network that enables communication between electronic devices.

[0013] The user device 10 executes a set of instructions contained in a computer program to realize various game-related functions. The server 20 can provide various game-related services to the user device 10. The user device 10 and the server 20 can cooperate with each other as necessary to realize various game functions.

[0014] The game system 1 shown in FIG. 1 is an example of a system to which the present invention can be applied. Not all of the elements of the game system 1 shown in FIG. 1 are necessarily required to realize the present invention. For example, the user device 10 may provide a game on a stand-alone basis. In this case, the server 20 is not an essential component of the game system 1.

[0015] 2. Overview of games provided by game system 1 The game system 1 can provide games of various genres. A game provided by the game system 1 may include multiple game parts. For example, a game provided by the game system 1 may include a battle game part in which a user character operated by a user fights an enemy character. In the battle game part, a user party consisting of multiple user characters may fight the enemy character. In this specification, a character operated by a user in the battle game part may be referred to as the user's "user character." The multiple user characters included in the user party may be divided into multiple categories, including frontline and rearline. A game provided by the game system 1 may have an exploration part in which the player explores the game field. If an enemy character is encountered during play in the exploration part, the game mode may be switched from the exploration part to the battle game part.

[0016] A battle event that takes place in the battle game part will be described with reference to Fig. 2. Fig. 2 shows an example of a game screen 50 that is displayed on the user device 10 in response to the start of a battle event. In the example shown in Fig. 2, a battle is taking place between a user character C51 and an enemy character C52. An image of the user character C51, which is controlled by the user, and an image of the enemy character C52 are displayed on the game screen 50. The enemy character C52 may be controlled by a computer, or may be controlled by a user other than the user who controls the user character C51.

[0017] In the game screen 50 showing a battle event, a life L51 may be displayed in association with the user character C51, and a life L52 may be displayed in association with the enemy character C52. When the user character C51 is attacked, the life L51 decreases, and when the enemy character C52 is attacked, the life L52 decreases. Life may be restored by using an item or magic. In a battle event, a character that fulfills the victory conditions becomes the winner. For example, the character that first reduces the opponent's life to zero becomes the winner of the battle event.

[0018] When a battle event starts, the user can operate the user device 10 to input a command to instruct the user character C51 to perform an action. In this specification, a command that instructs a user character (e.g., the user character C51) participating in the battle event to perform an action may be referred to as an "action command." The user character C51 performs an action corresponding to the action command input to the user device 10. The action performed by the user character C51 may include various actions such as attacking an enemy character (e.g., the enemy character C52), using magic, healing an ally character, and using a special move.

[0019] When the user character C51 performs an action, a game effect corresponding to that action occurs. For example, when the user character C51 attacks an enemy character, the user character C51 inflicts damage on the enemy character C52, resulting in a game effect in which the enemy character's life is reduced. When the user character C51 uses magic, a game effect corresponding to the magic used occurs.

[0020] Furthermore, when the user character C51 performs an action, the user device 10 generates a visual effect corresponding to the action. For example, the user device 10 can display an animation corresponding to the action being performed by the user character C51 on the game screen 50, generate a sound effect corresponding to the action from a speaker, or generate a vibration corresponding to the action. The visual effect generated by the user device 10 can vary depending on the type of game, the hardware configuration of the user device 10, the game settings set by the user, etc.

[0021] The actions of the user character C51 can be divided into charge actions and normal actions.

[0022] A charge action is an action that is initiated after a predetermined preparation period has elapsed since the input of an action command. When an action command for executing a charge action is input, the charge action becomes executable after the preparation period (e.g., 1 to 10 seconds) set for the action command has elapsed since the action command was accepted. The charge action may be executed automatically after the preparation period has elapsed, or may be executed in response to an additional command input by the user after the preparation period has elapsed. Because charge actions take longer than normal actions from command input to start of execution, they can produce game effects that are more advantageous to the user than normal actions. Charge actions can include, for example, actions that use special moves that can inflict greater damage on enemy characters than normal attacks, actions that use powerful attack magic that can inflict greater damage on enemy characters than normal magic, actions that use powerful recovery magic that provides a significant recovery effect on ally characters, actions that use special items, and other actions that produce game effects that are more advantageous than normal actions.

[0023] Because a predetermined preparation period must elapse after an action command is received in order to execute a charge action, the frequency with which charge actions are executed is lower than the frequency with which normal actions are executed. By making the elapse of the preparation period after command input the execution condition for a charge action, it is possible to execute charge actions, which generate game effects that are more advantageous than normal actions, less frequently than the execution frequency of normal actions. Therefore, making the elapse of the preparation period after command input the execution condition for a charge action helps maintain game balance.

[0024] During the preparation period for a charge action, the user character C51 performs a preparatory action for executing the charge action. For example, when a powerful magic spell is used as the charge action, the user character C51 may perform a preparatory action of chanting a spell to generate the magic spell. When a special move is used as the charge action, the user character C51 may perform a pose to activate the special move as the preparatory action. The user device 10 may generate a dramatic effect corresponding to the preparatory action. For example, when a spell is chanted as the preparatory action, an animation of the user character C51 chanting the spell may be displayed on the game screen 50.

[0025] Actions performed by the user character C51 are broadly divided into preparatory actions that are performed to enable the execution of a charge action, and game actions that are performed to generate a game effect other than a charge action (for example, a game effect of inflicting damage on the enemy character C52). Game actions are further classified into normal actions and charge actions. A preparatory action is an action that is performed to enable the execution of a charge action associated with the preparatory action. Therefore, when the execution of the preparatory action is completed, the charge action associated with the preparatory action becomes executable. As described above, a charge action may be automatically executed in response to the completion of the preparatory action, or may be executed in response to the receipt of an additional command input from the user after the completion of the preparatory action.

[0026] A plurality of body parts are set for the user character. For example, in the example shown in FIG. 2, two body parts are set for the user character C51: a first body part C51a corresponding to the staff held in the hand, and a second body part C51b corresponding to the mouth. Three or more body parts may be set for the user character C51. Weapons, armor, or other items equipped by the user character C51 may be set as body parts for the user character C51.

[0027] Actions that the user character C51 can perform (charge actions, normal actions, and preparatory actions) are associated with any of a plurality of body parts set for the user character C51. In one aspect, of the actions that the user character C51 can perform, charge actions and normal actions are both associated with the first body part C51a, and preparatory actions are associated with the second body part C51b.

[0028] When the user character C51 performs an action associated with the first part C51a, the user device 10 may generate a dramatic effect related to the action using the first part C51a. For example, when the user character C51 performs a normal attack (normal action) using the first part C51a, a game screen 50 including an animation in which the user character C51 attacks the enemy character C52 with the first part C51a (a staff) may be displayed on the display.

[0029] When the user character C51 performs a preparatory action using the second body part C51b, an animation of the user character C51 performing the preparatory action using the second body part C51b may be displayed on the game screen 50. For example, when using a powerful lightning spell as a charge action, the user character C51 may perform a preparatory action by chanting a spell to generate the spell using the second body part C51b (mouth). In this case, the game screen 50 including an animation of the user character C51 chanting a spell with his / her mouth may be displayed on the display.

[0030] As described above, in one aspect, charge actions and normal actions performed by the user character C51 are associated with the first region C51a, and preparatory actions for performing charge actions are associated with the second region C51b. If the user character C51 is capable of performing multiple normal actions, some of the multiple normal actions may be associated with the second region C51b. If the user character C51 is capable of performing multiple charge actions, some of the multiple charge actions may be associated with the second region C51b. If the user character C51 is capable of performing multiple preparatory actions, some of the multiple preparatory actions may be associated with the first region C51a.

[0031] 3 Action Parallelism in Combat Events Next, with reference to FIG. 3, an example of processing in which a user character participating in a battle event executes multiple actions in parallel will be described in one aspect of the present invention. FIG. 3 is a schematic diagram showing a time series of processing flows for a first action and a second action in an embodiment of the present invention. In FIG. 3, it is assumed that the first action is a normal action, and the second action is a charge action. Furthermore, the first preparatory action is a preparatory action for executing the second action. In FIG. 3, it is assumed that the first action and the second action are associated with a first part C51a of the user character C51, and the first preparatory action is associated with a second part C51b of the user character C51.

[0032] In one aspect of the present invention, two actions associated with different parts of the user character C51 can be executed in parallel. In the example shown in FIG. 3, the first action is associated with the first part C51a of the user character C51, while the first preparatory action is associated with the second part C51b of the user character C51. Therefore, the first action and the first preparatory action can be executed in parallel. That is, the user character C51 can execute the first preparatory action while executing the first action. On the other hand, two actions associated with the same part of the user character C51 cannot be executed in parallel. For example, since the first action and the second action are both associated with the first part C51a, the first action and the second action cannot be executed in parallel. If the first action is executed first, the second action must wait until the first action is finished before it can be executed.

[0033] In one aspect of the present invention, one action performed by the user character C51 may be associated with two or more parts of the user character C51. For example, in the above example, a third part (e.g., the left hand of the user character C51) may be set to the user character C51 in addition to the first part C51a and the second part C51b, and the second action may be associated with both the first part C51a and the third part. In this case, if the first preparatory action is completed while the first action is being performed using the first part C51a and the timing to perform the second action arrives, the second action can be performed using the third part in parallel with the first action. If both the first part and the third part are being used to perform the action when the timing to perform the second action arrives, in response to the completion of the action performed using the first part or the action performed using the third part, the execution of the second action can be started using the part used for the completed action.

[0034] As shown in FIG. 3 , a first command is input to the user device 10 at time t11. When the first command is accepted, the user character C51 executes a first action corresponding to the first command using the first body part C51a associated with the first action. Because the first action is a normal action, the first action is started immediately after the first command is accepted without the execution of a preparatory action. The first action is executed during a first period from time t11 to time t12. When the first action is executed, a game effect corresponding to the first action is generated. For example, if the first action is a normal attack on the enemy character C21, damage to the enemy character C52 resulting from the execution of the first action is calculated during the first period, and the life L52 of the enemy character C52 is reduced by an amount corresponding to the calculated damage. Furthermore, while the first action is being executed, a dramatic effect corresponding to the first action is generated in the user device 10.

[0035] As shown in the figure, the user device 10 receives a second command instructing the execution of a second action, which is a charge action, at time t21 within the first period. When the user device 10 receives the second command, the user character C51 starts executing a first preparatory action using the second body part C51b. For example, in response to the reception of the second command, the user character C51 starts chanting a spell using the second body part C51b (mouth). The first preparatory action is executed over a first preparatory action period from the time t21 when the second command is received until time t22. Because the first action is executed using the first body part C51a while the first preparatory action is executed using the second body part C51b, the first action and the first preparatory action can be executed in parallel. Because the second command is received within the first period during which the first action is executed, and the first preparatory action is started in response to the reception of the second command, the first period and the first preparatory action period overlap.

[0036] When the first preparatory action is completed at time t22, the execution of the second action is started using the first part C51a of the user character C51. Like the first action, the second action is executed using the first part C51a of the user character C51, and therefore the first period (t11 to t12) in which the first action is executed does not overlap with the second period (t22 to t23) in which the second action is executed.

[0037] As described above, in one aspect of the present invention, a plurality of regions including a first region C51a and a second region C51b are set for the user character C51, and a first action, which is a normal action, is performed by the first region C51a, and a first preparatory action for preparing a second action, which is a charge action, is performed by the second region C51b. This allows the user character C51 to perform the first action and the first preparatory action in parallel. Therefore, the user can start the first preparatory action for performing the second action by inputting a second command without waiting for the completion of the preceding first action. Because the second action is a charge action, even if the second command is input, it is not executed until the first preparatory action period has elapsed. However, because the first preparatory action for preparing the second action and the first action are executed in parallel, the battle event can be progressed by executing the first action during the first preparatory action period in which the execution of the second action is awaited. Thus, according to one aspect of the present invention, the first preparatory action period during which the first preparatory action is performed to prepare for the execution of the second action can be utilized to execute other actions, thereby improving convenience for the user instructing the character to execute an action.

[0038] If multiple actions were executed in parallel without any restrictions, the number of actions executed in parallel would become too large, which could result in an excessive processing load for expressing the dramatic effects of each action and could disrupt the game balance. In one aspect of the present invention, two actions executed by the same part of the user character C11 cannot be executed in parallel, so the number of actions executed in parallel is limited. Therefore, according to the present invention, the adverse effects caused by an increase in the number of actions executed simultaneously are prevented.

[0039] If the first action and the first preparatory action are associated with the same part of the user character C51, when the first action and the first preparatory action are executed in parallel, the effect representing the first action and the effect representing the first preparatory action are displayed in association with the same part of the user character C51, making it difficult to display the effect of both actions in an orderly manner. In one aspect of the present invention, the first action and the first preparatory action executed in parallel are executed using different parts of the user character C51, so that the effect of both actions can be displayed in an orderly manner even when the first action and the first preparatory action are executed in parallel. For example, when a normal action of attacking an enemy character C52 using the first part C51a (a wand) and a preparatory action of casting a spell using the second part C51b (a mouth) are executed in parallel, these two actions can be displayed in a single animation.

[0040] Next, another example of a process in which a user character participating in a battle event executes multiple actions in parallel will be described with reference to Figures 4 and 5. In describing the process shown in Figures 4 and 5, differences from the process in Figure 3 will be mainly described.

[0041] First, the process shown in Fig. 4 will be described. The process shown in Fig. 4 differs from the process shown in Fig. 3 in that the first action has not yet been completed when the first preparatory action is completed. In the example shown in Fig. 4, the first preparatory action is completed at time t22, which is before time t12 when the first action is completed, so the first action is still being executed when the first preparatory action is completed. Therefore, the second action is not started immediately after the completion of the first preparatory action, but is started after the execution of the first action is completed at time t12.

[0042] Next, the process shown in FIG. 5 will be described. The process shown in FIG. 5 differs from the process shown in FIG. 4 in that the second command is input before the first command. As shown in FIG. 5, when the second command is input at time t21, the first preparatory action is initiated. The first preparatory action is completed at time t22. The first command is input at time t11 while the first preparatory action is being executed. While the first preparatory action is executed using the second region C51b, the first command is executed using the first region C51a. Therefore, even if the first preparatory action is being executed when the first command is input, the execution of the first action can be started in parallel with the first preparatory action in response to the acceptance of the first command. Because the first action is still being executed when the first preparatory action is completed at time t22, the second action is not started immediately after the completion of the first preparatory action, but after the execution of the first action is completed at time t12.

[0043] 4 and 5, the first action and the first preparatory action associated with different body parts are executed in parallel, so that the first preparatory action period for preparing the second action can be utilized for executing the first action. Also, in both of the examples shown in Fig. 4 and 5, two actions executed by the same body part of the user character C11 are not executed in parallel, so that it is possible to prevent adverse effects caused by an excessive number of actions executed in parallel.

[0044] Next, with reference to Figures 6 to 8, another example of a process in which a user character participating in a battle event executes multiple actions in parallel will be described. In the process shown in Figures 6 to 8, in addition to the first command and the second command, a third command is input to the user device 10. The third command is a command for causing the user character C11 to execute a third action, and the third action is a normal action executed by the first part C51a of the user character C11. In the description of the process shown in Figures 6 to 8, differences from the process in Figure 3 will be mainly described.

[0045] First, the processing shown in FIG. 6 will be described. In the example shown in FIG. 6, a third command is input at time t31 after the execution of the first action is completed. Time t31 overlaps with the first preparatory action period (the period from time t21 to t22) in which the first preparatory action is being executed. However, since the third action and the first preparatory action are executed on different parts of the user character C51, the third action is executed in parallel with the first preparatory action. The third action starts at time t31 when the third command is input and accepted, and continues to be executed until time t32. In other words, the third action is executed in the third period between time t31 and time t32.

[0046] The first preparatory action is completed at time t22 within the third period. Because the third action is being executed when the first preparatory action is completed, the second action is not started immediately after the first preparatory action is completed, but is started after the execution of the third action is completed at time t32.

[0047] The first preparatory action is performed using the second part C51b of the user character C51, and therefore can be performed in parallel with both the first action and the third action performed using the first part C51a. In the example shown in FIG. 6, the first preparatory action period (t21 to t22) in which the first preparatory action is performed overlaps with both the first period (t11 to t12) in which the first action is performed and the third period (t31 to t32) in which the third action is performed. The first preparatory action period overlaps with at least a portion of the first period. In the example shown in FIG. 6, a portion of the first preparatory action period overlaps with a portion of the first period. In another aspect, the first period may be included in the first preparatory action period. Conversely, the first preparatory action period may be included in the first period. Furthermore, the first preparatory action period overlaps with at least a portion of the third period. In the example shown in FIG. 6, a portion of the first preparatory action period overlaps with a portion of the third period. In another embodiment, the third period may be included in the first preparatory action period, or conversely, the first preparatory action period may be included in the third period.

[0048] In the example shown in FIG. 6, the third action is executed in a third period between time t12 when the execution of the first action is completed and time t32 when the second action is started.

[0049] Next, the processing shown in Fig. 7 will be described. In the example shown in Fig. 7, the third command is input at time t31, which overlaps with the first period in which the first action is being executed. Therefore, the third action is not executed immediately after the third command is input, but is executed in response to the completion of the execution of the first action at time t12. In other words, the execution of the third action is reserved in response to the acceptance of the third command, and this reserved third action is executed in response to the completion of the execution of the first action and the creation of a vacancy in the first portion C51a.

[0050] The period from time t31 when the third command is input to time t12 when execution of the third action begins is considered to be a reservation period during which execution of the third action is reserved. If another command for executing another normal action is input during this reservation period, the reservation of the third action is canceled, and instead, the execution of the action corresponding to the other command newly input during the reservation period may be reserved. By limiting the number of normal actions that can be reserved to one, it is possible to save on the computational resources and memory capacity that would be used to reserve multiple actions.

[0051] 7, even if the third command is input during the first period, the third action is executed during the third period between time t12 when the execution of the first action is completed and time t32 when the second action is started. Therefore, the third period during which the third action is executed does not overlap with the first period during which the first action is executed.

[0052] Next, the processing shown in Fig. 8 will be described. In the example shown in Fig. 8, the third command is input at time t31, which overlaps with the second period (the period from time t22 to t23) in which the second action is being executed. Therefore, the third action is not executed immediately after the third command is input, but is executed in response to the execution of the second action being completed at time t12. Thus, in the example shown in Fig. 8, if the third command is input during the second period, the third action specified in this third command is executed in the third period after time t23, when the execution of the second action is completed. In other words, in the example shown in Fig. 8, the execution of the third action is reserved in response to the acceptance of the third command, and this reserved third action is executed in response to the completion of the execution of the second action and the availability of space in the first portion C51a.

[0053] 6 to 8, at least one of the first action and the third action associated with the first region C51a and the first preparatory action associated with the second region C51b are executed in parallel, so that the first preparatory action period for preparing the second action can be utilized for executing the first action and the third action. Also, in any of the examples shown in Figures 6 to 8, two actions executed by the same region of the user character C11 are not executed in parallel, so that it is possible to prevent adverse effects caused by an excessive number of actions being executed simultaneously.

[0054] Next, with reference to FIGS. 9 and 10 , another example of a process in which a user character participating in a battle event executes multiple actions in parallel will be described. In the process shown in FIGS. 9 and 10 , in addition to the first command and the second command, a fourth command is input to the user device 10. The fourth command is a command for causing the user character C11 to execute a fourth action, and the fourth action is a charge action executed by the first part C51a of the user character C11. Because the fourth action is a charge action, execution of the fourth action begins after a predetermined preparation period has elapsed after the fourth command is accepted. In the example shown in FIGS. 9 and 10 , a second preparatory action is executed to execute the fourth action. The second preparatory action is a preparatory action for executing the fourth action. In the description of the process shown in FIGS. 9 and 10 , differences from the process shown in FIG. 3 will be mainly described.

[0055] First, the processing shown in FIG. 9 will be described. In the example shown in FIG. 9, a fourth command is input at time t41 after the execution of the first action is completed. Time t41 overlaps with the first preparatory action period (the period from time t21 to t22) during which the first preparatory action is being executed. The second preparatory action executed in response to the fourth command is executed using the second region C51b of the user character C51, just like the first preparatory action. Therefore, the second preparatory action is not started immediately in response to the acceptance of the fourth command at time t41, but is started after the execution of the first preparatory action is completed at time t22. In other words, the execution of the second preparatory action is reserved in response to the acceptance of the fourth command, and this reserved second preparatory action is executed in response to the completion of the execution of the first preparatory action and the availability of the second region C51b.

[0056] When the execution of the first preparatory action is completed at time t22, the execution of the second action associated with the first preparatory action is started, and the execution of the reserved second preparatory action is also started. Thus, a part of the second preparatory action period (time t22 to t42) in which the second preparatory action is executed overlaps with the second period (time t22 to t23) in which the second action is executed. Because the second preparatory action is executed using the second part C51b, while the second action is executed using the first part C51a, the second preparatory action and the second action can be executed in parallel.

[0057] When the execution of the second preparatory action is completed at time t42, the execution of the fourth action begins. The fourth action is executed in a fourth time period from time t42 to time t43. In another aspect, if the second preparatory action is completed earlier than the second action (i.e., if time t42 is earlier than time t23), the fourth action is executed after the second action is completed, rather than immediately after the second preparatory action is completed.

[0058] Next, the processing shown in Fig. 10 will be described. The example shown in Fig. 10 differs from the processing in Fig. 9 in which the fourth command is input during the first preparatory action period in that the fourth command is input during the second period. In the processing shown in Fig. 10, an action using the second part C51b has not been executed at the time the fourth command is accepted, so the second preparatory action is started in response to the acceptance of the fourth command.

[0059] 9 and 10, the second action associated with the first region C51a and the second preparatory action associated with the second region C51b are executed in parallel, so that the second preparatory action period for preparing the fourth action can be utilized for executing the second action. Also, in both of the examples shown in Fig. 9 and 10, two actions executed by the same region of the user character C11 are not executed in parallel, so that it is possible to prevent adverse effects caused by an excessive number of actions executed in parallel.

[0060] The processes described with reference to FIGS. 3 to 10 are examples of processes for executing multiple actions in parallel according to some aspects of the present invention. The specific processes shown in FIGS. 3 to 10 are merely examples of processes to which the present invention can be applied. In the present invention, whether two actions can be executed in parallel is determined according to a parallel processing condition. One example of a parallel processing condition is that different actions associated with different parts of the user character C51 can be executed in parallel, but two or more actions cannot be executed in parallel using one part of the user character C51. According to this parallel processing condition, it is determined whether multiple actions specified by input commands can be executed in parallel by the user character C11. The processes shown in FIGS. 3 to 10 are examples of processes to which the above parallel processing condition is applied. Processes to which the present invention can be applied are not limited to the processes shown in FIGS. 3 to 10. The present invention encompasses various aspects including the processing of multiple actions whose parallel execution is determined according to a parallel processing condition.

[0061] Next, the game system 1 to which the present invention is applied will be described in more detail with reference to FIGS.

[0062] 4. Server equipment As described above, the game system 1 can include a server 20. First, the server 20 will be described with reference to FIG.

[0063] 4-1 Server configuration The server 20 includes a processor 21 , a memory 22 , a user interface 23 , a communication interface 24 , and a storage 25 .

[0064] The processor 21 is an arithmetic device that loads an operating system and various other programs from the storage 25 or other storage into the memory 22 and executes instructions included in the loaded programs. The processor 21 is, for example, a CPU, an MPU, a DSP, a GPU, various other arithmetic devices, or a combination of these. The processor 21 may be realized by an integrated circuit such as an ASIC, a PLD, an FPGA, or an MCU.

[0065] The memory 22 is used to store instructions to be executed by the processor 21 and various other data. The memory 22 is a main memory that can be accessed at high speed by the processor 21. The memory 22 is configured by, for example, a RAM such as a DRAM or an SRAM.

[0066] The user interface 23 includes an input interface that accepts input from a user or operator, and an output interface that outputs various information under the control of the processor 21. The input interface is a keyboard, a pointing device such as a mouse, a touch panel, or any other information input device that can input user input. The output interface is, for example, a liquid crystal display, an organic EL (Electro-Luminescence) display, a display panel, or any other information output device that can output the calculation results of the processor 11.

[0067] The communication interface 24 is implemented as hardware, firmware, or communication software such as a TCP / IP driver or a PPP driver, or a combination of these. The server 20 can send and receive data to and from other information devices, including the user device 10, via the communication interface 24.

[0068] The storage 25 is an external storage device that is accessed by the processor 21. The storage 25 is, for example, a magnetic disk, an optical disk, a semiconductor memory, or any other storage device capable of storing data.

[0069] 4-2 Data stored on the server device The storage 25 stores user management data 25a, game content management data 25b, and other data necessary for providing the game.

[0070] The user management data 25a will be described with reference to Fig. 12. The user management data 25a is a data set in which various data related to users who play games provided by the game system 1 are structurally stored. The user management data 25a may include user account information, user parameters which are various parameters set for the user, owned game media information related to game media owned by the user, used game media information related to used game media used by the user in the game, and various other data related to the user.

[0071] The account information is, for example, a user ID that identifies a user. The account information may also include a username. In the game system 1, a user is uniquely identified by the user ID. The username indicates the name of the user used in the game.

[0072] The user parameters of a user may include the user's rank, experience points, acquired points, and other user parameters associated with the user that change as the user plays the game. The user's rank is a parameter that indicates the user's proficiency with the game. The rank may increase as the user plays the game.

[0073] The owned game media information of a user is information about game media owned by the user in a game. Game media is electronic data used in a game. Game media may include, for example, characters, cards, items, points, in-service currency (or in-game currency), tokens (e.g., Non-Fungible Tokens (NFTs)), tickets, characters, avatars, parameters, and other electronic data used in the game. Game media may be acquired, owned, used, managed, exchanged, combined, enhanced, sold, discarded, or gifted by a user in a game. Game media may also be used in ways other than those described above. The owned game media information may include a game media ID that identifies game media owned by the user in a game. When a game medium is acquired by a user, the game media ID that identifies the game medium is stored as owned game media information in association with the user ID of the user. Hereinafter, unless otherwise specified, game media "owned" by a user refers to the game media associated with the user ID of the user. Furthermore, "granting" game media to a user means associating the game media with the user's user ID as game media "owned" by the user. "Discarding" game media owned by a user means dissociating the game media from the user's user ID. "Consuming" game media owned by a user means generating an in-game effect in response to dissociating the game media from the user's user ID. "Selling" game media owned by a user means dissociating the game media from the user's user ID and associating other game media (e.g., virtual currency or items) with the user ID as game media owned by the user. "Transferring" game media owned by user A to user B means dissociating the game media from user A's user ID and associating the game media with user B's user ID. "Creating" game media means defining or determining at least a portion of the information related to the game media.

[0074] The used game medium information is information indicating the game medium used by the user in a game part (e.g., a battle game part). The game medium used by the user in the battle game part is selected from among the owned game media. The character used by the user in the battle game part (i.e., the user character) may be selected in response to a selection operation by the user or automatically from among the used game media. When multiple user characters are selected to execute the battle game part, a party may be formed from the selected multiple user characters. In this case, the used game medium information may include a party ID for identifying the party formed from the user characters selected as the used game medium.

[0075] The user management data 25a may include friend information. The friend information for a user indicates the user IDs of users who are friends with the user. For example, if user A is friends with users B and C, the friend information for user A includes the user IDs of users B and C. Users who are friends can play games together.

[0076] Some of the data stored as the user management data 25a is updated as the game progresses. For example, a user's rank increases as the user plays the game. Some of the data stored as the user management data 25a is not updated as the game progresses. For example, the user ID remains unchanged even as the game progresses.

[0077] The game content management data 25b will be described with reference to FIG. 13. The game content management data 25b is a data set in which various data related to game content, such as characters used by users in games provided by the game system 1, is structurally stored. The game content management data 25b includes data related to user characters. The game content management data 25b includes game content identification information, game content names (character names, etc.), and game content information for various user characters.

[0078] The game media identification information of a user character is, for example, a character ID that identifies the character. The game media identification information may also include a character name that indicates the name of each character.

[0079] The game media information of a user character includes various information indicating the characteristics of the user character. The character information includes, for example, rarity, cost, life, attack power, defense power, and game function information. Rarity is information indicating the rarity (scarcity value) of the user character. In other words, the rarity associated with a certain user character indicates the difficulty of obtaining that user character.

[0080] The cost is a parameter used when determining the deck to be used in the battle game part. For example, a party (sometimes called a deck) is set with an upper limit on the total cost of the user characters that can be included in the party. The user can select the user characters to be included in the party so that the total cost does not exceed the upper limit.

[0081] Life is a parameter used to determine whether a user wins or loses in a battle game part. In the battle game part, the user's character loses life when attacked by an enemy character. Life may be restored to an upper limit or a lower limit by using a recovery item. When the lives of all characters included in the user's deck reach zero, the user may be determined to have lost the battle game part.

[0082] The attack power of a user character is a parameter that contributes to the amount of damage inflicted on an enemy character by an attack from the user character. The larger the attack power value, the greater the amount of damage inflicted on an enemy character. The defense power of a user character is a parameter that contributes to the amount of damage the user character receives from an attack from an enemy character. The larger the defense power value, the greater the amount of damage the user character receives from an attack from an enemy character.

[0083] At least a portion of the user management data 25a and the game content management data 25b is referenced by the user device 10 as needed. At least a portion of the user management data 25a and the game content management data 25b may be stored in the user device 10 as needed.

[0084] 4-3 Server Functions The processor 21 of the server 20 functions as a game control unit 21a by executing an instruction set included in a program stored in the storage 25 and, as necessary, other instruction sets. The game control unit 21a processes requests and notifications from the user device 10 based on predetermined game logic, and also provides the user device 10 with various game data for executing the game, thereby controlling the progress of the game.

[0085] 5 User Device As described above, the game system 1 may include a user device 10. Next, the user device 10 will be described with further reference to FIG.

[0086] 5-1 User device configuration The user device 10 may be a smartphone, a personal computer (PC), a mobile phone, a tablet terminal, a personal computer, an e-book reader, a wearable computer, a game console, a head-mounted display, or any other type of information processing device. The user device 10 is intended to be used by a game player (user). A first user can input information into the user device 10 and play the game through the video and audio output from the user device 10.

[0087] The user device 10 includes a processor 11, a memory 12, a user interface 13, a communication interface 14, and a storage 15. The descriptions of the processor 21, the memory 22, the user interface 23, the communication interface 24, and the storage 25 of the server 20 also apply to the processor 11, the memory 12, the user interface 13, the communication interface 14, and the storage 15 of the user device 10.

[0088] 5-2 Data stored on user devices The storage 15 stores a game application 15a for providing various game functions, action management data 15b, and various other data.

[0089] Instructions included in the game application 15a can be executed by the processor 11. Details of functions realized by executing the game application 15a will be described later. The game application 15a may be downloaded to the user device 10, for example, from an application distribution platform (not shown). The user device 10 can obtain data necessary to progress through the game part from the server 20 as needed, and store the obtained data in the storage 15.

[0090] The action management data 15b will be described with reference to Fig. 15. The action management data 15b is a data set in which data related to game actions performed by user characters in a game provided by the game system 1 is structurally stored. In one aspect, the action management data 15b includes action identification information for identifying the action, body part information, execution time, and game effect. When multiple user characters are used in a game provided by the game system 1, the action management data 15b may be stored for each user character.

[0091] The action identification information is data for identifying an action executed by a user character in a battle, and may be, for example, an action ID for identifying the action. The action identification information may include the name of the action.

[0092] Body part information is a body part ID that identifies which body part of the user character will be used to perform an action, among multiple body parts set on the user character. By storing body part IDs in association with action IDs, it is possible to manage which body part of the user character will be used to perform an action identified by the action ID. Only one body part ID may be stored in association with one action ID, or multiple body part IDs may be stored in association with one action ID. When an action is performed using multiple body parts of the user character, multiple body part IDs that identify each of the multiple body parts used to perform the action are associated with one action ID that identifies the action.

[0093] The execution time represents the time during which a game action specified by a command is executed in a battle event. The execution time may be calculated from the time the battle event starts. For example, if a game action is executed between 10 and 12 seconds after the start of a battle event, 10 to 12 seconds can be stored as the execution time. The execution time is set in response to the acceptance of a command to execute an action in a battle event. If an action is executed immediately in response to the acceptance of a command, the execution time of the action can be determined based on the time the command was accepted and the action duration set for the action (e.g., a time corresponding to the first period for a first action). For some game actions, a period (sometimes referred to as a "cooldown period") may be set during which the user character C51 who executed the game action cannot execute another action after the user character C51 executes the game action and the corresponding game effect is generated. For game actions for which such a cooldown period is set, not only the period during which the process of generating the game effect is performed but also the cooldown period is included in the action duration of the game action. When a command is accepted and the execution of an action specified by the command is reserved, the execution time of the action can be determined based on the time when the reserved action starts and the action duration set for the action. This is set for game actions that are currently being executed and game actions that are reserved for execution. For game actions that are not being executed and not reserved for execution, a null value may be set as the execution time. The execution time set in the action management data 15b is updated every time a command to execute an action is accepted in a battle event.

[0094] The game effect information of an action includes various information indicating game effects that occur when an action is executed by a user character. Game effects that occur when an action is executed may include a normal attack on an enemy character, the use of various types of magic (e.g., fire magic, lightning magic), the use of an item, and the activation of a special move. When the action ID is identification information for a preparatory action, an action that is executed after the preparatory action is completed may be stored as an associated action related to the preparatory action.

[0095] At least a portion of the action management data 15b may be stored in the server 20, if necessary.

[0096] 5-3 User Device Functions The processor 11 of the user device 10 functions as a game progression unit 11a, a command processing unit 11b, and an action execution unit 11c by executing the instruction set included in the game application 15a and, if necessary, other instruction sets.

[0097] 5-3-1 Game Progression Section 11a The game progression unit 11a progresses the game in accordance with the command set included in the game application 15a and, if necessary, based on input from the first user via the user interface 13 of the user device 10 (for example, physical buttons on a game console or a GUI displayed on a touch panel). The game progression unit 11a can also progress the game in cooperation with the server 20. Operational inputs from the user include, for example, inputs for specifying the movement of the user character within the game field, inputs for changing game settings, and various other inputs related to the progress of the game.

[0098] The game progression unit 11a is able to generate requests related to the progress of the game based on a command set included in the game application 15a and input from the user, and to send the generated requests to the server 20. The game progression unit 11a can also receive various game data related to the progress of the game from the server 20, and progress the game based on the game data. The game progression unit 11a can display images according to the progress of the game on the user interface 13 (e.g., a display). For example, the game progression unit 11a can execute processing related to a battle event between a user character and an enemy character by performing processing based on game logic corresponding to a battle game part.

[0099] The game progression unit 11a may obtain data necessary for the progression of the game from the various types of data stored in storage 25 of the server 20, and store the obtained data in storage 15. When necessary for game processing, the game progression unit 11a can read data from storage 15 as appropriate, and perform calculations using the read data.

[0100] 5-3-2 Command processing unit 11b The user device 10 accepts various command inputs from the user via the user interface 13 during a battle event in which the user character C51 participates. The commands input by the user include action commands that instruct the user character C51 participating in the battle event to perform a predetermined action. A display of the user device 10 may display multiple candidate commands that the user can select. The user may input a command by operating the user interface 13 (e.g., a controller or a touch panel) to select a desired command from the candidate commands.

[0101] The command processing unit 11b identifies which of the multiple body parts set on the user character C51 the action specified in the input action command will be executed on. In one aspect, the command processing unit 11b can refer to the action management data 15b to identify the body part ID associated with the action ID included in the input action command. The body part identified by the body part ID thus identified is the body part that will execute the action specified in the input action command.

[0102] The command processing unit 11b determines the execution timing of the action specified by the input action command. If the input action command is a command requesting the execution of a normal action, the execution timing of the normal action is determined. If the input action command is a command requesting the execution of a charge action, the execution timing of a preparatory action to enable the execution of the charge action is determined. The execution timing of the action specified by the input action command is determined in accordance with the parallel processing conditions described above.

[0103] 7, if a third command specifying the execution of a third action associated with the first part C51a is received during the execution of a first action associated with the first part C51a, the execution of the action specified in this third command needs to be suspended until time t12 when the execution of the preceding first action is completed. Therefore, the command processing unit 11b determines a time after time t12 when the execution of the preceding first action is completed (for example, a time immediately after time t12) as the execution start time of the third action.

[0104] 7, when a second command specifying the execution of a second action, which is a charge action, is received during the execution of a first action associated with the first location C51a, the first preparatory action performed to prepare for the second action can be executed in response to the reception of the second command, regardless of whether the execution of the first action has been completed. Therefore, the command processing unit 11b determines the time immediately after the time t21 when the second command is received as the execution start time of the first preparatory action.

[0105] The command processing unit 11b may store the execution start time determined as described above as part of the action management data 15b.

[0106] Other examples of determining the execution timing of an action specified by an input action command can be understood by referring to Figures 3 to 10 and the descriptions in the detailed description corresponding to these figures.

[0107] 5-3-3 Action Execution Unit 11c The action execution unit 11c executes the action specified by the action command at the processing timing determined by the command processing unit 11b. By executing a game action based on the action command, a game effect corresponding to the game action is generated.

[0108] 6 Processing flow Next, the flow of battle processing in a battle event will be described with reference to Fig. 16. Fig. 16 is a flow diagram illustrating the general flow of game progress in a battle event. In the battle processing shown in Fig. 16, as shown in Fig. 2, a battle is taking place between a user character C51 and an enemy character C52, and it is assumed that a first command for executing a first action and a second command for executing a second action are input at the timing shown in Fig. 3, and that no action commands other than the first command and the second command are input.

[0109] First, in step S11, a battle event is started. The battle event is started, for example, in response to an encounter with an enemy character while moving in the game field. When the battle event is started, a game screen for progressing the battle (for example, the game screen 50 shown in FIG. 2) is displayed on the display of the user device 10.

[0110] When the battle event starts in step S11, the battle processing proceeds to step S12. In step S12, a first command is input in response to an operation by the user on the user device 10. The first command is input, for example, by pressing a physical button on a controller provided on the user device 10 or by selecting a virtual operation button displayed on a touch panel. The first command is an action command for causing the user character C51 to perform a normal action. The first action specified by the first command is associated with the first part C51a of the user character C51. In other words, the first action specified by the first command is performed by the user character C51 using the first part C51a.

[0111] When the input of the first command is accepted in step S12, the battle processing proceeds to step S13. In step S13, the first action specified by the first command is started. When the first action is started, processing is performed to generate a game effect corresponding to the first action. For example, if the first command is a command for performing a normal attack on the enemy character C52, damage to be inflicted on the enemy character C52 is calculated based on parameters such as attack power set for the user character C51 and other data as necessary. Furthermore, when the first action is started, a visual effect corresponding to the game effect generated by the first action is generated in the user device 10. For example, during the execution of the first action, an animation is displayed on the game screen 50 showing the user character C51 hitting the enemy character C52 with the first part C51a (stick).

[0112] In step S14, a second command is input in response to an operation by the user on the user device 10. As shown in FIG. 3, the second command is input during a first period in which the first action is executed. The second command is an action command for causing the user character C51 to execute the second action. The second action is a charge action that becomes executable after the first preparation action is completed.

[0113] Next, the battle processing proceeds to step S15. In step S15, the execution timing of the first preparatory action associated with the second action specified by the second command is determined. The execution timing of the first preparatory action is determined so as to satisfy the parallel processing condition described above. For example, the execution timing (execution start time) of the first preparatory action is set to the earliest time within a range that satisfies the parallel processing condition. As shown in FIG. 3, when the second command is accepted, the user character C51 is executing the first action using the first part C51a. Because the first preparatory action is executed using the second part C51b, the user character C51 can execute the first action and the first preparatory action in parallel. Therefore, in step S15, the time immediately after the time when the second command is accepted is determined as the execution timing of the first preparatory action.

[0114] When the execution timing of the first preparatory action is determined in step S15, in step S16, execution of the first preparatory action is started according to the execution timing determined in step S15. A predetermined preparation time is set for the first preparatory action. When the first preparatory action is continuously executed for the set first preparatory action period, the execution of the first preparatory action is completed and the second action becomes executable. The first preparatory action may be continuously executed while a button associated with the first preparatory action is pressed on the user device 10. The first preparatory action may be continuously executed after the second command is input as long as the user character C11 continues to participate in the battle event (for example, as long as life L51 does not become zero).

[0115] When the execution of the first preparatory action is completed, in step S17, the second action is executed using the first part C51a.

[0116] As described above, the first action and the second action are executed in the battle event.

[0117] The flow of the battle processing changes depending on various factors, such as the timing of inputting the action command, the duration of execution of each action, whether the action specified by the action command is a normal action or a charge action, and other factors. Battle processing flows other than the example shown in Figure 16 can be understood by referring to Figures 3 to 10 and the descriptions in the detailed explanations corresponding to these figures.

[0118] 7 Notes The game system 1 shown in FIG. 1 is an example of a system to which the present invention can be applied, and game systems to which the present invention can be applied are not limited to the one shown in FIG. 1. The game system 1 to which the present invention can be applied may not include some of the components shown in the figure. For example, the game system 1 may not include the storage 30. The game system 1 may include components that are not shown. Although FIG. 1 shows only one user device 10 for the sake of simplicity, the game system 1 may include any number of user devices 10 greater than or equal to two. The game system 1 may also include a cloud environment for distributing and processing processes to be executed by the user devices 10 or the server 20.

[0119] In the game system 1, there are no particular limitations on where data is stored. For example, various data that can be stored in storage 15 may be stored in a storage (e.g., storage 30) or a database server that is physically separate from storage 15. In this specification, data described as being stored in storage 15 may be stored in a single storage, or may be distributed and stored across multiple storages. Furthermore, in this specification and claims, when the term "storage" is used simply, it may refer to either a single storage or a collection of multiple storages, as long as the context allows. The above description of data that can be stored in storage 15 also applies to data stored in storage 25 as much as possible.

[0120] The embodiments of the present invention are not limited to the above-described embodiments, and various modifications are possible within the scope of the gist of the present invention. For example, some or all of the functions executed by processor 11 and processor 21 may be implemented by a processor not explicitly described herein, without departing from the spirit of the invention. Although processor 11 is illustrated as a single component in FIG. 1, processor 11 may be a collection of multiple physically separate processors. The same applies to processor 21. In this specification, programs or instructions included in the programs described as being executed by processor 11 and processor 21 may be executed by a single processor or may be distributed and executed by multiple processors. Furthermore, programs or instructions included in the programs executed by processor 11 and processor 21 may be executed by one or more virtual processors.

[0121] The programs executed by processor 11 and / or processor 21 may be stored in various types of non-transitory computer-readable media other than the illustrated storage. Non-transitory computer-readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic recording media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (e.g., magneto-optical disks), Compact Disc Read Only Memory (CD-ROM), CD-R, CD-R / W, and semiconductor memory (e.g., mask ROM, programmable ROM (PROM), erasable PROM (EPROM), flash ROM, random access memory (RAM)).

[0122] The functions performed by the components described herein may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), a CPU (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to perform the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may also be a programmed processor that executes programs stored in memory.

[0123] In this specification, a circuit, unit, or means is hardware that is programmed to realize or executes a described function. The hardware may be any hardware disclosed in this specification or any hardware known to be programmed to realize or execute the described function. If the hardware is a processor, which is considered a type of circuitry, the circuit, means, or unit is a combination of hardware and software used to configure the hardware and / or processor.

[0124] Although processes and procedures described herein are described as being performed by a single device, software, component, or module, such processes or procedures may be performed by multiple devices, multiple software, multiple components, and / or multiple modules. Furthermore, although data, tables, or databases described herein are described as being stored in a single memory, such data, tables, or databases may be stored in multiple memories within a single device or multiple memories distributed across multiple devices. Furthermore, the software and hardware elements described herein may be realized by combining them into fewer components or by breaking them down into more components.

[0125] In the processing procedures described in this specification, particularly in processing procedures described using flow charts or sequence diagrams, it is possible to omit some of the processes (steps) that make up the processing procedures, to add processes that are not explicitly stated as processes that make up the processing procedures, and / or to change the order of the processes, and processing procedures in which such omissions, additions, or changes in order have been made are also included within the scope of the present invention as long as they do not deviate from the spirit of the present invention.

[0126] The terms "first," "second," "third," etc. used in this specification and claims are used to identify components and do not necessarily limit the number, order, or content of the components. Furthermore, numbers used to identify components are used context-specifically, and numbers used in one context do not necessarily indicate the same configuration in another context. Furthermore, this does not prevent a component identified by a certain number from also fulfilling the function of a component identified by another number.

[0127] 8. Supplementary Notes This specification also discloses the following techniques:

[0128] [Appendix 1] A system for progressing a game using a character having a first part and a second part, the gaming system includes one or more processors; the one or more processors: causing the character to perform a first action using the first body part during a first period based on a first command; causing the character to perform a first preparatory action using the second body part during a first preparatory action period that overlaps with at least a portion of the first period based on a second command; After the first action and the first preparatory action are completed, the character is caused to perform a second action using the first body part in a second period that is subsequent to the first period. Game system. [Appendix 2] The first action is executed in response to the first command being accepted. 1. A game system as described in Appendix 1. [Appendix 3] the first preparation action is continuously executed while a predetermined input associated with the first preparation action is being made; 10. The system of claim 1 or 2. [Appendix 4] When the first preparation action has been continuously executed for a preparation time set for the second action, the first preparation action is completed. 1. A game system as described in Appendix 3. [Appendix 5] The first preparatory action period starts after the start time of the first period. 10. A game system according to any one of claims 1 to 4. [Appendix 6] The first preparatory action period starts before the start time of the first period. 6. A game system according to any one of claims 1 to 5. [Appendix 7] the one or more processors: causing the character to perform a third action using the first body part during a third period between an end time of the first period and a start time of the second period, based on a third command accepted after the end of the first period and before the end of the first preparatory action period; 10. A game system according to any one of claims 1 to 6. [Appendix 8] the one or more processors: causing the character to perform a third action using the first body part during a third period between an end time of the first period and a start time of the second period, based on a third command accepted during the first period; 10. A game system according to any one of claims 1 to 7. [Appendix 9] the first preparatory action period overlaps with at least a portion of the first period and at least a portion of the third period; 10. The game system of claim 7 or 8. [Appendix 10] the one or more processors: causing the character to perform a third action using the first body part during a third period that is after an end time of the second period, based on a third command accepted during the second period; 10. A game system according to any one of claims 1 to 9. [Appendix 11] the one or more processors: causing the character to perform a second preparatory action using the second body part during a second preparatory action period that overlaps with at least a portion of the second period based on a fourth command; After the second action and the second preparatory action are completed, in a fourth period that is later than the second period, the character is caused to perform the fourth action using the first body part. 11. A game system according to any one of claims 1 to 10. [Appendix 12] the one or more processors: causing the character to perform a second preparatory action using the second body part in a second preparatory action period that is later than the first preparatory action period, based on a fourth command received in the first preparatory action period; After the second action and the second preparatory action are completed, in a fourth period that is later than the second period, the character is caused to perform the fourth action using the first body part. 12. A game system according to any one of claims 1 to 11. [Appendix 13] A game processing method for progressing a game using a character having a first part and a second part. The game processing method is executed by one or more processors, causing the character to perform a first action using the first body part during a first period based on a first command; causing the character to perform a first preparatory action using the second body part during a first preparatory action period that overlaps with at least a portion of the first period based on a second command; After the first action and the first preparatory action are completed, in a second period after the first period, causing the character to perform a second action using the first body part; A game processing method comprising: [Appendix 14] A game program for progressing a game using a character having a first part and a second part, one or more processors, causing the character to perform a first action using the first body part during a first period based on a first command; causing the character to perform a first preparatory action using the second body part during a first preparatory action period that overlaps with at least a portion of the first period based on a second command; After the first action and the first preparatory action are completed, in a second period after the first period, causing the character to perform a second action using the first body part; A game program that executes the above. [Explanation of symbols]

[0129] 1. Game System 10 User Device 11 processors 11a Game Progression Section 11b Command processing section 11c Action Execution Department 20 servers

Claims

1. A game system in which a game is progressed using a character having a first part and a second part, the gaming system includes one or more processors; the one or more processors: causing the character to perform a first action using the first body part during a first period based on a first command; causing the character to perform a first preparatory action using the second body part during a first preparatory action period that overlaps with at least a portion of the first period based on a second command; after completion of the first action and the first preparatory action, causing the character to perform a second action using the first body part in a second period that is subsequent to the first period; Game system.

2. The first action is executed in response to the first command being accepted. The game system according to claim 1 .

3. the first preparation action is continuously executed while a predetermined input associated with the first preparation action is being made; The game system according to claim 1 .

4. When the first preparation action is continuously executed for a preparation time set for the second action, the first preparation action is completed. The game system according to claim 3 .

5. the first preparatory action period starts after the start time of the first period; The game system according to claim 1 .

6. The first preparatory action period starts before a start time of the first period. The game system according to claim 1 .

7. the one or more processors: causing the character to perform a third action using the first body part during a third period between an end time of the first period and a start time of the second period, based on a third command accepted after the end of the first period and before the end of the first preparation action period; The game system according to claim 1 .

8. the one or more processors: causing the character to perform a third action using the first body part during a third period between an end time of the first period and a start time of the second period, based on a third command accepted during the first period; The game system according to claim 1 .

9. the first preparatory action period overlaps with at least a portion of the first period and at least a portion of the third period; 9. The game system according to claim 7 or 8.

10. the one or more processors: causing the character to perform a third action using the first body part during a third period that is after an end time of the second period, based on a third command accepted during the second period; The game system according to claim 1 .

11. the one or more processors: causing the character to perform a second preparatory action using the second body part during a second preparatory action period that overlaps with at least a portion of the second period based on a fourth command; after completion of the second action and the second preparatory action, causing the character to perform the fourth action using the first body part in a fourth period that is after the second period; The game system according to claim 1 .

12. the one or more processors: causing the character to perform a second preparatory action using the second body part in a second preparatory action period that is after the first preparatory action period, based on a fourth command received in the first preparatory action period; after completion of the second action and the second preparatory action, causing the character to perform the fourth action using the first body part in a fourth period that is after the second period; The game system according to claim 1 .

13. A game processing method for progressing through a game using a character having a first part and a second part. The game processing method is executed by one or more processors, causing the character to perform a first action using the first body part during a first period based on a first command; causing the character to perform a first preparatory action using the second body part during a first preparatory action period that overlaps with at least a portion of the first period based on a second command; After the first action and the first preparatory action are completed, in a second period after the first period, causing the character to perform a second action using the first body part; A game processing method comprising:

14. A game program for progressing a game using a character having a first part and a second part, one or more processors, causing the character to perform a first action using the first body part during a first period based on a first command; causing the character to perform a first preparatory action using the second body part during a first preparatory action period that overlaps with at least a portion of the first period based on a second command; After the first action and the first preparatory action are completed, in a second period after the first period, causing the character to perform a second action using the first body part; A game program that executes the above.

Images