Program and system

Abstract

To provide a technique, by diversifying a method of updating the parameters of a character, which can further support diversifying the development, thereby further increasing the interest of a play.SOLUTION: A program causes a computer to function as: lottery means for performing lottery processing in which an attribute that can be associated with a character is a provision target, for one or more characters to be operated; storage means for storing information indicating the attribute provided according to the result of the lottery processing; imparting means for imparting a common first object to a user, regardless of which character the attribute is, by providing the attribute which has already been able to be associated with a character by the provision according to the result of the already performed lottery processing again according to the result of a newly performed lottery processing; and update means for performing update processing so that the parameters related to the attribute are caused to grow, by consuming the first object.SELECTED DRAWING: Figure 28

Description

[Technical field]

[0001] The present invention relates to a program and a system. [Background technology]

[0002] In some games, such as role-playing games and action role-playing games, a player progresses through the game by controlling a game character. In these games, for example, the game character is made to act in response to a user's input operation, and experience points are given to the game character by having the game character fight an enemy character, etc. As the game character grows, it can fight and defeat stronger enemy characters, and progress through the game.

[0003] As a technique for controlling a character, for example, there is Japanese Patent Application Laid-Open No. 2016-051266 (Patent Document 1). Patent Document 1 discloses a game operation method in which, in a video game executed by a smartphone, a user touches a character object displayed on a touch panel of the smartphone to control the character object by associating the direction of a slide operation on the touch panel with each action of the character object, such as movement or jump. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2016-051266 A Summary of the Invention [Problem to be solved by the invention]

[0005] As the game character grows, it becomes able to perform a greater variety of actions, and as a result, the user can enjoy playing the game even more.

[0006] For example, as a game character grows, it may acquire skills such as learning recovery spells or special attacks. Typically, as the game character gains experience points, the game character's level increases, and each time a certain level is reached, the game character acquires skills such as attack spells. However, if the game character's growth method is monotonous, the scope of play development will be narrowed, and it is necessary to further increase the interest of the game.

[0007] Some games provide various options for character development during the game, and allow the user to voluntarily intervene in the character development, resulting in a variety of game developments. For example, in some role-playing games, the player character is given a pre-assigned occupation, such as warrior, wizard, priest, or fighter, and the occupation can be changed during the game by changing jobs. For example, by making the skills acquired different depending on the occupation, the user can progress through the game in accordance with the character development method of his or her own devising.

[0008] However, in games that employ such a job change system, typically, the user will choose a new job of their own volition, but the character will often be at a low level after the new job. Therefore, the user must carefully grow the character after changing the job to a certain one. This requires the user to carefully consider which job to assign the character to in the first place, and makes the user cautious about changing the character's job. As a result, there is a problem that diverse game development may not be encouraged.

[0009] The present disclosure aims to provide technology that can help diversify developments by diversifying methods for updating object parameters, thereby making gameplay more interesting. [Means for solving the problem]

[0010] According to an embodiment of the present disclosure, a program is provided, which causes a computer to function as a lottery means for performing a lottery process for providing attributes that can be associated with one or more first objects to be operated, a storage means for storing information in a memory indicating the attributes provided according to the result of the lottery process, and an update means for executing a process for updating a parameter related to the provided attribute itself so as to grow the parameter by providing again the attribute that has already been provided according to the result of the already performed lottery process and can be associated with the first object according to the result of a newly performed lottery process.

[0011] According to an embodiment of the present disclosure, a system is provided, which includes: a selection means for performing a selection process for providing attributes that can be associated with one or more first objects to be operated, a storage means for storing information in a memory indicating the attributes provided according to the result of the selection process; and an update means for executing a process for updating a parameter related to the provided attribute itself so as to grow the parameter by providing again the attribute that has already been provided according to the result of a previously performed selection process and can be associated with the first object according to the result of a newly performed selection process.

[0012] According to one embodiment of the present disclosure, a method is provided that is executed on a computer including a processor and a memory, the method including a first step of causing the processor to store in the memory information indicating attributes that can be associated with one or more characters to be operated, a second step of performing a lottery process in which the attributes of the characters are provided, and a third step of performing a process for updating parameters related to the attributes by providing the attributes that can already be associated with the characters as a result of the lottery process. Effect of the Invention

[0013] According to the present disclosure, by diversifying the methods for updating character parameters, it is possible to diversify developments, thereby making gameplay more interesting. [Brief description of the drawings]

[0014] [Figure 1] FIG. 2 is a diagram illustrating a user terminal according to the present embodiment. [Diagram 2] FIG. 2 is a diagram illustrating a hardware configuration of a user terminal according to the present embodiment. [Diagram 3] FIG. 2 is a functional block diagram of a user terminal according to the present embodiment. [Figure 4] A figure showing an example of a game screen of a game displayed on a touch screen of a user terminal according to this embodiment. [Diagram 5] 13A and 13B are diagrams illustrating a process in which an operation detection unit detects a direction in which a player character is to be moved in response to an input operation by a user. [Figure 6] FIG. 2 is a diagram showing an action table of a player character (here, the player's own character). [Figure 7] FIG. 1A is a diagram showing an example of a manipulation object displayed on a touch screen, and FIG. 1B is a diagram showing a state in which the manipulation object has been elastically deformed. [Figure 8] 2 is a schematic diagram showing main functional modules implemented in the game program according to the present embodiment. FIG. [Figure 9] 10 is a flowchart showing a process for displaying information regarding a state of a player character within an operation object in this embodiment. [Figure 10] 10(A) and (B) are diagrams showing examples of game screens in the flowchart of FIG. [Figure 11]These are example screens when a user wants a player character to execute a specified action, where (A) is a diagram showing an example screen in which the player character is jumping, (B) is a diagram showing an example screen in which the input operation for the specified action is successful, and (C) is a diagram showing an example screen in which the input operation for the action is unsuccessful. [Figure 12] These are example screens when a user wants a player character to execute a specified action, where (A) is a diagram showing an example screen in which the player character is jumping, (B) is a diagram showing an example screen in which the input operation for the specified action is successful, and (C) is a diagram showing an example screen in which the input operation for the action is unsuccessful. [Figure 13] FIG. 13 is a diagram showing a game screen according to a modified example. [Figure 14] FIG. 13 is a diagram showing an operation object according to another modified example. [Figure 15] This figure shows a data structure of parameters of a game character that can be operated by a user, such as the player's character 100, and a data structure including a correspondence between the history of various actions performed by the game character in response to the user's input operations and the skills acquired by the game character. [Figure 16] 13 shows a situation in which the player's character 100 is notified that the player's character 100 has acquired a skill as a result of the player's character 100 taking an action in response to a user's input operation. [Figure 17] 13 shows an example of a skill list screen that allows the user to check the skills that the player's character 100 can acquire and the skills that the player's character 100 has mastered. [Figure 18] A flowchart showing a process in which the user terminal 1 updates the experience points for each skill for skill acquisition in accordance with the motion content of the player's character 100, and notifies the user that a skill has been acquired or developed. [Figure 19] 13 is a flowchart showing a process in which the user terminal 1 presents, on the touch screen 2, a screen showing a list of skills acquired by the player's character 100 in response to an input operation by the user. [Figure 20]13 is a flowchart showing a display process of a user interface image for allowing a user to change a player character in the second embodiment. [Figure 21] Fig. 22 is a diagram showing an example of a game screen in the flowchart shown in Fig. 20. Fig. 22 is a diagram showing an example of a game screen subsequent to the game screen shown in Fig. 21. [Figure 22] 22 is a diagram showing an example of a game screen subsequent to the game screen shown in FIG. 21. [Diagram 23] FIG. 13 is a diagram showing an example of a user interface image after a user has changed the player character. [Figure 24] 13 is a diagram showing an example of a game screen when a slide operation is input while a user interface image for changing a player character is being displayed. FIG. [Diagram 25] A diagram showing a character that a user can control in a game program and a data structure of character management information for managing characters that the user can control. [Figure 26] FIG. 13 shows a user interface image for switching between a first mode, in which the character is automatically changed during a battle with an enemy character without the user having to perform an input operation to change the character, and a second mode, in which the first mode is stopped, and a game screen in which the character is changed by auto-change. [Figure 27] 13 is a flowchart showing a process of identifying characters that will fight enemy characters among characters organized into a party in an auto-change application mode, and displaying the characters on the touch screen 2 in accordance with the identification result. [Figure 28] 13 is a table showing game media provided by the lottery process. [Figure 29] 1 shows an example of a screen displayed on the display 2 of a user's terminal in the lottery process. [Diagram 30] 13 is an example of a screen for displaying skills associated with a character's job. [Diagram 31] 4 is a flowchart according to the present embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] In the following, a technique for supporting diversifying the game development by diversifying the update of game character parameters will be described. First, (A) a mode in which predetermined information is displayed on a touch screen to assist a user in operating a game character by performing an input operation on the game character has been described, but the present invention is not limited to a configuration in which information indicating the operation of the game character is displayed on the touch screen. In addition, as a configuration in which a user's input operation is received, an example in which an input operation on a touch screen is received is shown, but the present invention is not limited to this, and the disclosure contents shown in the following embodiments may also be applied to a case in which a game character is operated by input to a game controller or the like. (B) Next, a game program in which various parameters of a character can be enhanced as a result of the character taking an action in response to a user's input operation or the like will be described. (C) In these configurations, a mode in which each character is further associated with an attribute called a job (occupation) will be described. In this embodiment, the attribute of each character is given to the user by a lottery process. Furthermore, when a character's job is changed, parameters such as the character's stamina and skill points are inherited from before the job change, and after the job change, the character can equip equipment items unique to the job and activate skills unique to the job. The game program updates parameters associated with the job, such as skills unique to the job, in the following manner. For example, when a job that has already been offered to a user is offered again by lottery, the game program may provide the user with material items for increasing parameters related to the job, or may increase parameters related to the job when the job is offered again. In the present disclosure, the configuration (c) above encourages the user to change the character's job, while the character's parameters related to the job itself are allowed to grow according to the result of the lottery process. This encourages the user to acquire new jobs one after another by lottery, which further supports diversification of the game development. In this way, the game program allows the character to perform actions such as attack, evasion, and jump in response to the user's input operation to grow the first parameters representing the character's performance. The game program grants the character's job, which is an attribute of the character, to the user by lottery. The game program updates the second parameters (such as skills specific to the job) according to the character's job by a method different from the growth method of the first parameters. Specifically, when the game program performs a lottery process to grant the character's job, if it is determined by lottery that a job already acquired by the user is to be provided (i.e., if the jobs overlap), it grants the user an item for updating the second parameters related to the job, or updates the second parameters related to the job. In the past, in a game in which the job change can be updated for each character, the parameters are initialized each time the job change is made (for example, returning to level 1). In addition, in the past, a game in which the user can change jobs by selecting an arbitrary job. Compared to this conventional example, the game program shown in the present disclosure assigns the character's job to the user by a lottery process, so the user does not have to hesitate about which job to select. In addition to the growth of basic parameters, the game program shown in the present disclosure allows the user to enjoy the growth of the character through the job. Furthermore, since the job can be grown by overlapping jobs through a lottery process to acquire a job, the user can be encouraged to try to acquire jobs one after another through lotteries. This allows the user to diversify the way the character grows, and encourages the user to play the game in a diversified way, thereby further improving the interest of the game.

[0016] First, an outline of a configuration for displaying on a touch screen the content of an action being performed by a game character in response to an input operation for causing the game character to move will be described below.

[0017] (1) A gaming method according to an embodiment of the present disclosure is a gaming method for controlling a character object displayed on a touch screen in accordance with an input operation by a user, the method comprising: The game method comprises: (a) displaying an operation object on the touch screen from a start point of the input operation to an end point of the input operation; (b) causing the character object to perform a predetermined action based on the input operation; (c) detecting a state of the character object in step (b); (d) displaying, on the touch screen, predetermined information associated with the detected state of the character object in association with the operation object.

[0018] According to the above method, feedback on an input operation can be given to a user intuitively.

[0019] (2) the operation object is an object displayed between the start point and the end point, In the step (a), the operation object is displayed such that one of the portion on the reference point side and the portion on the end point side is an enlarged portion larger than the other portion; In the step (d), the predetermined information may be displayed inside the enlarged portion.

[0020] According to the above method, by displaying the state display information on the enlarged portion of the operation object, which is dead space on the touch screen, it is possible to effectively utilize a small screen such as that of a smartphone.

[0021] (3) In step (d), the display angle of the predetermined information on the touch screen may be fixed, regardless of the positional relationship between the start point and the end point.

[0022] According to the above method, it is possible to ensure the visibility of the information displayed within the operation object.

[0023] (4) In step (b), a first input operation may be performed to put the character object into a first state, and a second input operation may be performed in the first state to execute the predetermined action.

[0024] (5) In step (b), a first input operation may be performed to put the character object into a first state and then into a second state, and the predetermined action may be executed by performing a second input operation in the first state or the second state.

[0025] According to these methods, even for an action that requires multiple input operations, it is possible to provide the user with feedback on the success or failure of the input operations in an easily understandable manner.

[0026] (6) A program according to one embodiment of the present disclosure is a program for causing a computer to execute the gaming method described in any one of (1) to (5) above.

[0027] According to this configuration, it is possible to provide a program that can give intuitive feedback to a user in response to an input operation.

[0028] [Details of the first embodiment of the present disclosure] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. For the sake of convenience, the description of the members having the same reference numbers as those already described in the description of the present embodiment will not be repeated.

[0029] A game program according to an embodiment of the present disclosure is executed in a user terminal 1 equipped with a touch screen 2, as shown in FIG. 1. The user terminal 1 executes the game program to provide the user with an environment for playing a game corresponding to the game program. The user terminal 1 installs the game program via, for example, a platform that distributes apps and the like. The user terminal 1 executes the game program installed in the user terminal 1 or a game program preinstalled in advance, thereby enabling the user to play the game. The user can operate a player character (an example of a character object) in the game via the touch screen 2. The user terminal 1 may be, for example, a portable terminal such as a smartphone, a PDA (Personal Digital Assistant), or a tablet computer, or may be a personal computer, a video game device, or the like.

[0030] The user terminal 1 may communicate with a game server via a network. In this case, all or part of the various functions related to the user terminal 1 in the following embodiments may be performed by the game server, and for example, game images generated by the game server may be displayed on the user terminal 1 using an application such as a browser. Furthermore, the user terminal may be configured to be able to communicate with another user terminal via the game server.

[0031] As shown in FIG. 2, the user terminal 1 includes, as a hardware configuration, a CPU (Central Processing Unit) 3, a main memory 4, an auxiliary memory 5, a transmission / reception unit 6, a display unit 7, and an input unit 8, which are connected to each other by a bus. Of these, the main memory 4 is composed of, for example, a DRAM (Dynamic Random Access Memory), and the auxiliary memory 5 is composed of, for example, a HDD (Hard Disk Drive). The auxiliary memory 5 stores a game program according to this embodiment. The game program is deployed on the main memory 4 and executed by the CPU 3. In addition, data generated while the CPU 3 is operating according to the game program and data used by the CPU 3 are also temporarily stored on the main memory 4. The transmission / reception unit 6 establishes a connection between the user terminal 1 and a network under the control of the CPU 3. The input unit 8 detects a user's operation on the display unit 7, which is the touch screen 2, and detects that some operation has been performed on the user terminal 1.

[0032] FIG. 3 shows an example of a functional block diagram of the user terminal 1 according to this embodiment. The display unit 7 and the input unit 8 in this embodiment correspond to the above-mentioned touch screen 2. As shown in FIG. 3, the touch screen 2 has a touch sensing unit 10 corresponding to the input unit 8 and a display 20 corresponding to the display unit 7. The touch screen 2 accepts a touch operation by the user (such as a physical contact operation on the touch screen 2). Specifically, the touch sensing unit 10 outputs an operation signal corresponding to the touch operation by the user to the control unit 30. The touch operation may be performed by the user's finger or a stylus or the like. The display 20 displays an image corresponding to the user operation based on a display signal output from the control unit 30. The display 20 is realized by, for example, an LCD (Liquid Crystal Display), an organic EL (electroluminescence) or other display device.

[0033] The control unit 30 executes a game program based on instructions from a user received by the touch sensing unit 10, and progresses the game while controlling the actions of a player character that functions as a player in the game world. By executing the game program, the control unit 30 exerts the functions of an input operation receiving unit 32, a character operation detection unit 34, an object control unit 36, and a display control unit 38.

[0034] The input operation receiving unit 32 receives an input operation from the user based on the output of the touch screen 2. Specifically, the input operation receiving unit 32 detects the approach of a user's finger or the like to the touch sensing unit 10 as coordinates of a coordinate system consisting of the horizontal and vertical axes of the surface constituting the touch screen 2.

[0035] The input operation receiving unit 32 determines a user's operation on the touch screen 2. The input operation receiving unit 32 determines, for example, (1) an "approaching operation," (2) a "release operation," (3) a "tapping operation," (4) a "long press operation (long touch operation)," (5) a "drag operation (swipe operation)," and other user operations. The user's operations determined by the input operation receiving unit 32 are not limited to those described above. For example, in the case where the touch sensing unit 10 has a mechanism capable of detecting the magnitude of pressure applied by the user to the touch sensing unit 10, the input operation receiving unit 32 determines the magnitude of the pressure applied by the user.

[0036] (1) An "approach operation" is an operation in which a user brings a finger or the like close to the touch screen 2. The touch screen 2 detects the approach of a user's finger or the like (including the user's finger or the like touching the touch screen 2) by the touch sensing unit 10, and outputs a signal according to the detected coordinates of the touch screen 2 to the input operation receiving unit 32. The control unit 30 determines that the state has changed from a state in which the approach of a user's finger or the like to the touch screen 2 is not detected to a state in which the control unit 30 detects the approach to the touch screen 2, and then determines that the state has changed to a "touch-on state" when the control unit 30 detects the approach.

[0037] (2) A "release operation" is an operation in which the user stops the state in which he or she is operating the touch screen 2 by approaching it. For example, when the user releases his or her finger from the state in which the finger is in contact with the touch screen 2, the control unit 30 determines that the user's operation is a "release operation." When the control unit 30 goes from a state in which the control unit 30 detects the approach of the user's finger or the like to the touch screen 2 to a state in which the control unit 30 does not detect the approach, it determines that the state has changed from a "touch-on state" to a "touch-off state."

[0038] (3) A "tap operation" refers to an approach operation in which a user brings a finger or the like close to the touch screen 2, and then performs a release operation at the position where the approach operation was performed. When the input operation receiving unit 32 detects that a user's finger or the like has approached based on the output of the touch screen 2 from a state in which an approach operation is not detected (a state in which the user's finger or the like is away from the touch screen 2 and the touch sensing unit 10 has not detected the approach of the user's finger or the like), the input operation receiving unit 32 holds the detected coordinates as an "initial touch position". When the coordinates of the initial touch position and the coordinates of the release operation are almost the same (when the coordinates of the release operation are detected within a certain range from the coordinates where the approach operation was detected), the control unit 30 determines that the user's operation is a "tap operation".

[0039] (4) A "long press operation" is an operation in which the user continues to press the touch screen 2. After detecting the user's operation and determining that it is an approach operation, if the duration of the approach operation at the coordinates where the approach operation was detected (or within a certain area including the coordinates) exceeds a certain period of time, the control unit 30 determines that the user's operation is a "long press operation" (a "long press operation" may also be referred to as a "long touch operation").

[0040] (5) A "drag operation" is an operation in which a user brings a finger or the like close to touch screen 2 and then slides the finger while maintaining the close contact state.

[0041] The character operation detection unit 34 detects the operation content of an input operation that causes a player character (hereinafter, also referred to as "own character") appearing in a game to perform a predetermined action, based on an input operation by the user on the touch screen 2. The character operation detection unit 34 detects, for example, a direction in which the player character is to move, based on the input operation by the user. That is, the character operation detection unit 34 accepts an input operation by the user that specifies the movement direction of the player character.

[0042] Specifically, when the user moves their finger closer to the touch screen 2 after removing their finger from the touch screen 2 and performs a drag operation, the character operation detection unit 34 detects the movement direction of the player character based on the coordinates of the initial touch position and the detection result of the touch screen 2, using the coordinates at which the input operation acceptance unit 32 detects that the user's finger has approached the touch sensing unit 10 as the initial touch position. Specific processing by the character operation detection unit 34 will be described later.

[0043] The object control unit 36 ​​controls processes such as generation, transformation, and movement of various objects that appear in a game that progresses as the user terminal 1 executes a game program, and various objects (e.g., a GUI (Graphical User Interface) screen) that are generated based on the user's operation content accepted by the input operation acceptance unit 32. The object control unit 36 ​​generates an operation object 40 that indicates the movement direction of the player character, for example, based on an input operation made by the user on the touch screen 2 to move the player character. Details of the operation object 40 will be described later.

[0044] The display control unit 38 determines the display contents of the display 20 in accordance with the control of the character operation detection unit 34 and the object control unit 36, and outputs various information such as images and text according to the determined display contents to the display 20. For example, the display control unit 38 performs a screen display in which, with the player character displayed in a certain area of ​​the display 20, an operation object 40 is displayed in accordance with an input operation accepted by the input operation acceptance unit 32, and the player character performs a predetermined action (for example, a movement or jump action).

[0045] FIG. 4 shows an example of a game screen displayed on the touch screen 2 of the user terminal 1 according to this embodiment. The example screen in FIG. 4 is a screen that accepts an input operation for making the player's character 100 (an example of a character object, a player character) operated by the user perform a predetermined action. The control unit 30 displays the player's character 100, which is a player character operated by the user, and the opponent character 200, which is an opponent (enemy) character, on the touch screen 2, and accepts an input operation for making the player's character 100 perform a predetermined action from the user. When the user terminal 1 is placed vertically, the player's character 100 and the opponent character 200 are displayed near the center of the touch screen 2 in the vertical direction (for example, within the central area when the touch screen 2 is divided into three in the vertical direction), for example, so that the field of view is slightly wider in the left-right direction in the direction of travel. For example, a cross section of the ground (the dot pattern part in FIG. 4) is displayed below the touch screen 2. The lower half of the touch screen 2, i.e., the part where the cross section of the ground is displayed, can be used as a space for operating an operation object 40 described later. The user can operate the player's character 100 by operating at any position on the touch screen 2. For example, when the user inputs a drag operation in a direction along the left-right direction of the display 20 (the direction of arrow A in FIG. 4), the control unit 30 accepts the drag operation and controls the player's character 100 to move in a direction corresponding to the direction of the drag operation (for example, the direction of arrow B).

[0046] Various user interface images (UI images) 300 are displayed on the left and right ends of the touch screen 2. The UI images 300 include, for example, a UI image 300A for displaying a map and a UI image 300B for activating a skill (one of the attack actions performed by the player's character 100 in the game).

[0047] 1. Controlling your character's movements 5 is a diagram showing a process in which the character operation detection unit 34 detects the direction in which the player's character 100 is moved in response to a user's input operation. The character operation detection unit 34 sets the position (initial touch position) at which the user approaches the touch sensing unit 10 and presses the touch screen 2 with a finger or the like from a state in which the user is not pressing the touch screen 2 as a starting point. When the input operation reception unit 32 determines that the user's operation is a drag operation, it detects the direction in which the player's character 100 is moved based on the coordinates of the starting point and the coordinates at which the touch screen 2 detects the approach of the user's finger or the like.

[0048] 5 shows a state (A) in which the user's finger is moved closer to the touch screen 2 after being removed from the touch screen 2. The input operation receiving unit 32 detects that the user's finger has approached the touch screen 2, and stores the detected coordinates in a memory (for example, the main memory 4 or the auxiliary memory 5) as an initial touch position.

[0049] In the example of FIG. 5, the coordinates of the initial touch position held in the memory are shown as initial touch position coordinates 55. The input operation receiving unit 32 stores the detection results of the touch screen 2 (the coordinates where the user's finger approaches the touch screen 2, and the fact that the user's finger has not been detected as approaching the touch screen 2 (detection result "null")) for a certain number of frames in the buffer memory 53. The buffer memory 53 can store the detection results on the touch screen 2 for a certain number of frames for each frame (11 frames from memory area fp[0] to memory area fp

[10] in the example of FIG. 5). The buffer memory 53 can be realized as, for example, a ring buffer.

[0050] In the example of state (A), the position where the user presses the touch screen 2 is shown as pressed position 50A (coordinates (x0, y0) on the touch screen 2).

[0051] 5 shows that the user has performed a drag operation on the touch screen 2 to move the pressed position on the touch screen 2 from pressed position 50A to pressed position 50B (coordinates (x9, y9) on the touch screen 2) in 10 frames (10 frames from memory area fp[0] to memory area fp[9]). The input operation receiving unit 32 stores the detection result of the touch screen 2 in the buffer memory 53 and, referring to the value held in the buffer memory 53, determines that the user's operation on the touch screen 2 is a drag operation.

[0052] State (C) in Figure 5 shows that the position where the user is pressing on the touch screen 2 has been moved from pressed position 50B to pressed position 50C (coordinates (x14, y14) on the touch screen 2) in five frames (five frames covering memory areas fp

[10] , fp[0], fp[1], fp[2], and fp[3]).

[0053] 5 shows a state (D) of the character operation detection unit 34 detecting an input operation that specifies the direction in which the user moves the player's character 100 in each of states (B) and (C). The character operation detection unit 34 manages information (writing position in the buffer memory 53) that indicates which memory area in the buffer memory 53 is the target for writing the coordinates of the pressed position detected by the touch screen 2.

[0054] In state (B), character operation detection unit 34 detects that the user has performed a drag operation from coordinates 51A (coordinates (x0, y0)) indicating the initial touch position to coordinates 51B (coordinates (x9, y9)) based on the determination result of input operation reception unit 32. Character operation detection unit 34 detects vector 52B ((y9-y0) / (x9-x0)) defined by coordinates 51A and 51B, starting from coordinates 51A of the initial touch position, as the direction in which player character 100 should be moved.

[0055] In state (C), character operation detection unit 34 detects that the user has performed a drag operation from coordinate 51B (coordinate (x9, y9)) to coordinate 51C (coordinate (x14, y14)) based on the determination result of input operation reception unit 32. Character operation detection unit 34 detects vector 52C ((y14-y0) / (x14-x0)) defined by coordinate 51A and coordinate 51C, starting from coordinate 51A of the initial touch position, as the direction in which player character 100 should be moved.

[0056] 2. Example of your character's movements 6 shows an action table 60 (action examples) of the player's character 100. The action table 60 is stored, for example, in the control unit 30 (display control unit 38). As shown in FIG. 6, the action table 60 has set therein predetermined actions to be executed by the player's character 100 based on the user's input operation and the state of the player's character 100 at the time of the input operation. Examples 1 to 8 illustrated in the action table 60 will be described in detail below.

[0057] Example 1: When the user performs a tap operation, regardless of the state of the player's character 100 (i.e., whether or not the player's character 100 is on the ground), the control unit 30 causes the player's character 100 to perform an attack action (e.g., swinging a sword that the player is holding). Example 2: When the user performs a horizontal slide operation (here, a direction along the left-right direction (horizontal direction) of the touch screen 2 is 0 degrees, and the side above the horizontal direction is positive and the side below is negative, for example, a drag operation within the range of -45 degrees to +30 degrees is referred to as a horizontal slide operation) and the player's character 100 lands on the ground, the control unit 30 moves the player's character 100 in the direction of the drag operation. Note that if the distance (slide amount) between the start point and end point of the drag operation is equal to or less than a predetermined threshold, the player's character 100 may be made to walk, and if the slide amount is greater than the predetermined threshold, the player's character 100 may be made to run. Example 3: When the user performs an upward slide operation (for example, a drag operation within the range of +60 degrees to +120 degrees is referred to as an upward slide operation) and the player's character 100 lands on the ground, the control unit 30 causes the player's character 100 to perform a jump action. Example 4: When the user performs an upward sliding operation similar to that of Example 3 and the player's character 100 does not land on the ground, the control unit 30 executes a jump action after the player's character 100 lands on the ground. That is, in this case, the jump action of the player's character 100 is repeated. Example 5: When the user performs a downward slide operation (for example, a drag operation within the range of -45 degrees to -135 degrees is referred to as a downward slide operation) and the player's character 100 lands on the ground, the control unit 30 causes the player's character 100 to crouch. Example 6: When the user performs a downward sliding operation similar to that of Example 5 and the player's character 100 does not land on the ground, the control unit 30 causes the player's character 100 to execute a downward attack action (so-called helmet splitting). Example 7: When the user performs a diagonally upward slide operation (for example, a drag operation within the range of +30 degrees to +60 degrees is referred to as a diagonally upward slide operation) and the player's character 100 lands on the ground, the control unit 30 makes the player's character 100 jump diagonally and move on the ground after landing. Example 8: When the user performs a diagonal upward sliding operation similar to that of Example 7 and the player's character 100 is in contact with an obstacle such as a wall, the control unit 30 causes the player's character 100 to kick the wall and jump upward (a so-called triple jump).

[0058] For example, when the control unit 30 receives an upward sliding operation (an example of a first input operation) from the user, the control unit 30 refers to the operation table 60 and sets the player's character 100 to a jumping state (an example of a first state), and when the control unit 30 receives a downward sliding operation (an example of a second input operation) from the user in the jumping state, the control unit 30 refers to the operation table 60 and causes the player's character 100 to perform a helmet split. In addition, when a diagonal sliding operation is received, the control unit 30 refers to the operation table 60 based on the diagonal upward sliding operation and sets the player's character 100 to a jumping state (first state) and then to a state in which the player's character 100 moves on the ground (an example of a second state). Then, when the control unit 30 receives a predetermined input operation (for example, a downward sliding operation) in the state in which the player's character 100 jumps or moves on the ground, the control unit 30 refers to the operation table 60 and causes the player's character 100 to perform a predetermined operation (a helmet split in the case of a jumping state, or crouching in the case of a moving state).

[0059] 3. Basic configuration of operation objects The operation object 40 (see FIG. 4) according to this embodiment is displayed on the touch screen 2 when the user's approach operation to the touch screen 2 is detected. The operation object 40 is an elastic object that indicates the direction in which the user moves the player's character 100. As shown in FIG. 7A, the operation object 40 is formed to have a circular base 42 around a reference position associated with a contact start point, which is a position where the touch screen 2 is contacted (for example, the initial touch position coordinates 51A in FIG. 5), as an initial shape at the time of finger contact. Note that the reference position does not have to be the coordinates where the finger first touches the touch screen 2, and may be, for example, the coordinates where the finger touches the touch screen 2 in a frame several frames after the frame where the finger first touches the touch screen. When the user performs a drag operation on the touch screen 2 from the contact start point to the contact end point (here, the contact end point means the final point in the state where the user's finger or the like touches the touch screen 2), as shown in FIG. 7B, the operation object 40 is elastically deformed as if it is pulled by the user's finger. At this time, the operation object 40 is configured to include, in addition to a base (enlarged portion) 42 displayed corresponding to the contact start point of the drag operation, a tip portion 44 located near the contact end point of the drag operation (note: the finger remains in contact with the touch screen 2), and a connection portion 46 connecting the base portion 42 and the tip portion 44. In this way, the operation object 40 is formed so as to be elastically extended in the direction of the drag operation input from the contact start point to the contact end point. Also, when the user further moves the finger or the like on the touch screen 2 while maintaining the contact end point in a contact state, the tip portion 44 also moves further following it, and the extension direction of the operation object 40 also changes. When the drag operation by the user is ended (i.e., when the user's finger is released from the contact end point on the touch screen 2), the elastically deformed operation object 40 is displayed so as to gradually shrink toward the contact start point according to its restoring force and to restore to the initial shape shown in (A) of FIG. 7, and is hidden after a certain time has passed. In addition, in FIG. 7A, a circular base portion 42 is formed with the contact starting point as the center, but this is not necessarily limited to this.For example, the base 42 may be formed by shifting a certain distance upward or downward from the contact start point. That is, the base 42 of the operation object 40 may be displayed corresponding to a predetermined position (reference position) associated with the contact start point. Also, without deforming the operation object 40 (base 42) formed at the contact start point in response to a drag operation, another object constituting a part of the operation object may be displayed from the contact start point toward the contact end point.

[0060] 4. Description of major functional modules The main functional modules implemented in the game program according to this embodiment and their operation processes will be described with reference to Figures 8 to 10. Through the functional modules, inputs as operation signals are processed and outputs as display signals are generated. The operation object control program module (operation object control PM) 80 shown in FIG. 8 is a module for controlling the operation object 40 based on the user's input operation through the touch screen 2 (touch sensing unit 10). The character control program module (character control PM) 90 is a module for controlling the movement of the player's character 100 in the virtual space in response to the user's input operation through the touch screen 2 to operate the player's character 100. The operation object control program module 80 includes an input operation reception program module (input operation reception PM) 82 and an operation object drawing program module (operation object drawing PM) 84. The input operation reception PM 82 has a function as the input operation reception unit 32 shown in FIG. 3, and the operation object drawing PM 84 has a function as the object control unit 36 ​​and the display control unit 38. The character control PM 90 has a function as the character operation detection unit 34.

[0061] When an input operation (e.g., approach operation) is performed on the touch screen 2 by a user's finger or the like, the input operation reception PM82 receives the input operation and stores information about the received input operation (input operation information) in a cache memory (e.g., the buffer memory 53 in FIG. 5) (step S1 in FIG. 9). Next, the character control PM90 obtains the input operation information from the input operation reception PM82 (step S2). Then, the character control PM90 obtains information about, for example, the state of the player's character 100 (whether the player's character 100 has landed on the ground, whether the player's character 100 has contacted an obstacle such as a wall, etc.) based on the situation in the game (step S3). Note that the "state of the player's character 100" here refers to a state related to the character's action (e.g., whether the player's character 100 has landed on the ground), and does not include an abnormal state of the character's status (e.g., poison or petrification).

[0062] Next, the character control PM90 controls the player's character 100 with reference to the motion table 60 in FIG. 6 based on the input operation information acquired in step S2 and the information on the player's character 100's state (hereinafter referred to as character state information) acquired in step S3 (step S4). For example, when the user performs a lateral slide operation and the player's character 100 lands on the ground, the character control PM90 acquires the lateral slide operation information and the information that the player's character 100 is in a state of landing on the ground, and moves the player's character 100 in the direction of the drag operation (the direction of the arrow C) as shown in FIG. 10 (A) based on the example 2 of the motion table 60 from these pieces of information. The character control PM90 can also control the opponent's character 200 based on the control result of the player's character 100. For example, when the player's character 100 attacks the opponent's character 200, the character control PM90 can cause the opponent's character 200 to perform an action that indicates that the character has received the attack.

[0063] Next, the operation object drawing PM84 in the operation object control PM80 acquires input operation information from the input operation reception PM82 and character state information from the character control PM90 (step S5). Then, the operation object drawing PM84 draws the operation object 40 based on the input operation information and character state information acquired in step S5, and displays it on the touch screen 2 (step S6). For example, when a horizontal slide operation is performed as in example 2 of FIG. 6, the operation object drawing PM84 acquires horizontal slide operation information from the input operation reception PM82, and displays the operation object 40 so as to be stretched from the initial touch position coordinates (contact start point) to the current touch position coordinates (contact end point), that is, in the direction of the arrow C', as shown in FIG. 10(A). At the same time, the operation object drawing PM84 displays information (for example, text information) corresponding to the state of the player character 100 inside the base 42 of the operation object 40, as shown in FIG. 10(A), based on the character state information acquired from the character control PM90. For example, when the user executes a lateral slide operation in the direction of the arrow C with the player's character 100 on the ground, "Run" is displayed in the base 42 of the operation object 40 (see FIG. 10A). Note that, when the slide amount of the lateral slide operation is equal to or less than a predetermined value, "Walk" may be displayed in the base 42 instead of "Run". Also, when the user executes an upward slide operation or an obliquely upward slide operation with the player's character 100 on the ground, as shown in FIG. 10B, the player's character 100 jumps in the direction of the arrow D, which is the direction of the drag operation, and the operation object 40 is stretched in the direction of the arrow D', and "Jump" is displayed in the base 42 of the operation object 40. When the process of step S6 is completed, the process returns to step S1 and is repeated.

[0064] On the touch screen 2, it is preferable that the display angle of the text information (such as "Run" or "Jump") displayed within the base 42 is fixed. That is, as shown in (A) and (B) of FIG. 10, when the text information is written horizontally, regardless of the angle of the tip 44 of the operation object 40 with respect to the base 42, the text information is displayed in a direction substantially parallel to the bottom side of the display unit. For example, even when a drag operation is input downward from the contact start point, or when an input operation is input such that the contact end point rotates around the contact start point, the display angle of the text information on the touch screen 2 is displayed in a direction that is easy for the user to view, and good visibility can be ensured.

[0065] Figure 11 shows examples of game screens when the user attempts to have his / her own character 100 perform a kabuto-wari action, where (A) shows an example of the screen in a state in which the user's own character 100 is jumping, (B) shows an example of the screen when the kabuto-wari input operation is successful, and (C) shows an example of the screen when the kabuto-wari input operation is unsuccessful. A helmet split (downward attack) can be executed when a downward slide operation is performed in a state where the player's character 100 is not on the ground (the state shown in FIG. 11(A)), as shown in Example 5 of the action table 60 in Fig. 6. That is, the control unit 30 puts the player's character 100 in a jump state where the player's character 100 is not on the ground based on an upward slide operation or a diagonally upward slide operation by the user, and when the control unit 30 receives an input of a downward slide operation by the user in this jump state, it causes the player's character 100 to execute a helmet split.

[0066] When the input operation of the helmet splitting is successful, that is, when a downward slide operation is input in the jump state, as shown in FIG. 11B, the control unit 30 causes the player's character 100 to execute the helmet splitting and displays information about the helmet splitting (e.g., "Attack") in the base 42 of the operation object 40. On the other hand, when the input operation of the helmet splitting is unsuccessful, for example, when the downward angle of the drag operation is insufficient, as shown in FIG. 11C, the control unit 30 does not cause the player's character 100 to execute the helmet splitting and displays information about the state of the player's character 100 at that time (e.g., "Jump") in the base 42 of the operation object 40. In this case, the user can easily recognize that the downward angle of the drag operation was insufficient by looking at the display "Jump". In this way, by displaying text information in the base 42, the success or failure of the input operation can be easily fed back to the user even for an action that requires multiple input operations such as the helmet splitting.

[0067] Figure 12, like Figure 11, is an example of a game screen when the user wants his / her own character 100 to perform a kabuto-wari action, where (A) shows an example of a screen in which the own character 100 is jumping, (B) shows an example of a screen when the kabuto-wari input operation is successful, and (C) shows an example of a screen when the kabuto-wari input operation is unsuccessful. As in the case of FIG. 11, when the input operation of the helmet split is successful, the control unit 30 causes the player's character 100 to execute the helmet split and displays information about the helmet split (e.g., "Attack") in the base 42 of the operation object 40, as shown in FIG. 12(B). On the other hand, when the input operation of the helmet split is unsuccessful, for example, when the player's character 100, which has jumped based on an upward slide operation or a diagonally upward slide operation, lands on the ground and then a downward slide operation is input, as shown in FIG. 12(C), the control unit 30 does not cause the player's character 100 to execute the helmet split and also displays information about the state of the player's character 100 at that time (e.g., "Run") in the base 42. In this case, the user can easily recognize by looking at the display "Run" that the input operation has failed because the player's character 100 performed a downward slide operation after landing on the ground.

[0068] As described above, according to this embodiment, the control unit 30 causes the player's character 100 to execute a predetermined action while displaying the operation object 40 on the touch screen 2 from the contact start point to the contact end point based on the user's input operation. Then, the control unit 30 detects the state of the player's character 100, and displays predetermined information (for example, the text information described above) associated with the detected state of the player's character 100 within the base 42 of the operation object 40 on the touch screen 2. This makes it possible to intuitively provide feedback on the input operation to the user.

[0069] The text information associated with the state of the player's character 100 is displayed within the base 42, which is an enlarged portion of the control object 40. In this way, by displaying the text information in the enlarged portion of the control object 40, which is dead space on the touch screen 2, it is possible to effectively use a narrow screen such as that of a smartphone.

[0070] In the above embodiment, as shown in Figs. 10 to 12, text information related to the state of the player's character 100 is displayed inside the base 42, which is an enlarged portion of the control object 40, but the present invention is not limited to this. As shown in Fig. 13, information related to the state of the player's character 100 (for example, "Run") may be displayed in the form of a speech bubble 48 from the control object 40. In other words, the information related to the player's character 100 may be displayed so as to accompany the control object 40.

[0071] In the above embodiment, the control object 40 is formed so that the base 42 is larger than the tip 44 as shown in Fig. 7 etc., but is not limited to this. As shown in Fig. 14, the tip 144 may be formed larger than the base 142. In this case, information regarding the state of the player's character 100 (for example, "Run") is displayed within the tip 144, which is an enlarged portion.

[0072] Furthermore, the character state information displayed in association with the operation object 40 is not limited to text information, but may be other symbols such as graphics.

[0073] 5. Explanation of the structure in which the more a character acts, the higher the character's parameters improve

[0074] Hereinafter, with reference to Figs. 15 to 19, a game program will be described in which various parameters of a character can be enhanced as a result of the character taking an action in response to an input operation or the like by a user.

[0075] 15 is a diagram showing a data structure of parameters of a game character that can be operated by a user, such as the player's character 100, and a data structure including a correspondence between a history of actions taken by the game character in response to input operations by the user and skills acquired by the game character. The user terminal 1 holds data having the data structure shown in FIG. 15 in the main memory 4 or the like, and progresses through the game while appropriately referring to the data.

[0076] 15 shows a data structure of parameters of a game character that can be operated by a user, such as the player's character 100. As shown in the illustrated example (A), the data structure of various parameters of the player's character 100 (for example, an example of parameters for a character named "H") includes an item "grade", an item "item name", an item "base value", an item "correction value for equipment", an item "correction value for skills", and an item "correction value for title".

[0077] The item "grade" indicates the range of skills that the player's character can acquire. In this embodiment, an example of grade "2" is shown, and the item "grade" is updated when the user fulfills a predetermined condition, such as obtaining a predetermined game medium while playing the game.

[0078] The item "item name" indicates the name of a parameter, and in this embodiment, the names of the parameters of the player's character 100 include "stamina value (HP: hit points)", "skill points (SP)", "attack value", and "defense value". "Stamina value (HP: hit points)" indicates the value of the stamina of the player's character 100. For example, when the "stamina value" runs out, the game is over and the game play may end. "Skill points (SP)" are parameters consumed when the player's character 100 activates a special motion (including a motion for performing an attacking action, a motion for performing a recovery action to recover stamina, etc.) in response to a predetermined input operation (long press operation, etc.). "Attack value" affects the amount of damage the player's character 100 inflicts on other characters. "Defense value" affects the amount of damage the player's character 100 receives from other characters, etc.

[0079] The "base value" item indicates the value of the parameter of the player's character 100 itself, without any correction from equipment items, etc. The "equipment correction value" item indicates the correction amount of the parameter due to associating the player's character 100 with a specific item, such as an equipment item. The "skill correction value" item indicates the correction amount of the parameter due to the skill acquired by the player's character 100 (details of the skills will be described later). The "title correction value" item indicates the correction amount according to a title object acquired by the user as the game is played (for example, the operator of the game program gives the user a title containing a specific name, and by having the title, effects are generated in the game, such as "increasing the upper limit of stamina value").

[0080] The illustrated example (B) of FIG. 15 shows the correspondence between the history of the game character performing various actions in response to the user's input operations and the skills acquired by the game character.

[0081] As shown in the illustrated example (B), the history of the actions taken by the character includes an item "grade" indicating the grade of the player's character 100, an item "skill name," an item "parameter correction content," an item "experience points," an item "level," and an item "experience point acquisition conditions."

[0082] The item "skill name" indicates the name of the skill that the player's character 100 can acquire.

[0083] The item "content of parameter correction" indicates the content of the parameter correction that is applied to the player's character 100 when the skill indicated in the item "skill name" reaches the item "level".

[0084] The item "Contents of parameter correction" may, for example, be: (i) a correction to the vitality value of the player's character 100; (ii) a correction to increase the attack power of an attack action when the player's character 100 performs an attack action in response to an input operation such as tapping; (iii) a correction to the upper limit of the number of times that an attack action can be performed consecutively (increasing the number of combos); (iv) a correction to shorten the time it takes for the player's character 100 to perform an animation of a game item collection action (e.g., an action of obtaining stones from a mine in the game field, an action of collecting flowers, an action of fishing, etc.) in response to a predetermined input operation in the game field; (v) a correction to the maximum number of skill points of the player's character 100; and (vi) a correction to the distance, speed, etc. of the player's character 100's evasive action when the player's character 100 performs an evasive action in response to an input operation such as flicking. (vii) to reduce the amount of damage received from an enemy character's attack when the player's character 100 is made to guard while crouching in response to an input operation such as a downward slide; (viii) to increase the distance, speed, etc. of a jump when the player's character 100 jumps in response to an input operation such as an upward slide; (ix) to increase the attack power and the number of attacks possible in the air when the player's character 100 receives a tap operation, downward slide operation, etc. while jumping in response to an input operation such as an upward slide to perform an attack operation in the air; (x) to increase the types of items obtained by crafting and the success rate of item generation when the player's character 100 performs a crafting operation to synthesize and strengthen weapons, armor, etc. based on material items.

[0085] The "Experience Points" field indicates the value that increases when the conditions in the "Experience Point Acquisition Conditions" field are satisfied for the skill in the "Skill Name" field, and the amount of experience points required to level up.

[0086] The item "Level" indicates the degree to which the user has developed the skill indicated in the item "Skill Name". For example, the parameter correction content can be made better for the skill "Stamina Value Up" when the level is high than when the level is low. This can motivate the user to make the player's character 100 perform the action indicated in the item "Experience Value Acquisition Condition" in order to increase the level of the skill. As a result, the more the user makes the player's character 100 perform the actions shown in FIG. 6 and the like, the more the parameters of the player's character 100 can be updated, so that the user can be motivated to continue playing the game and become proficient in operating the player's character 100. In addition, some of these skills can be acquired when the level of a certain skill reaches a certain level. That is, when the level of a first skill reaches a certain level (for example, when the level reaches the maximum), the second skill can be acquired.

[0087] The item "experience value acquisition condition" indicates a condition for acquiring experience value for the skill indicated in the item "skill name" and improving the level. For example, an input operation for making the player's character 100 perform an action shown in FIG. 6 or the like may be performed as such a condition. In other words, an input operation for making the player's character 100 perform an action is performed, and the player's character 100 performs an action as a result, so that the player can acquire experience value for each skill. Therefore, the user is motivated to try various actions shown in FIG. 6 or the like one after another. In addition, some skills, such as the skill name "stamina value up", allow the player's character 100 to grow parameters by receiving damage. This can further motivate the user to perform input operations for performing actions (e.g., evasive action, attack action, guard action, etc.) for fighting enemy characters in addition to actions for moving.

[0088] FIG. 16 shows a situation in which the player's character 100 is notified that the player's character 100 has acquired a skill as a result of the player's character 100 taking an action in response to a user's input operation.

[0089] The illustrated example (A) in FIG. 16 shows a side-scrolling action game (which may be an MMORPG) as an example. In the illustrated example (A), a situation is shown in which the player's character 100 is moving as the user continues a sideways sliding operation (drag operation). The user terminal 1 displays a UI part 900 on the touch screen 2. The UI part 900 is an icon that receives an input operation such as a touch operation by the user, and transitions to a screen on which the user can check a list of skills that the player's character 100 has acquired.

[0090] The illustrated example (B) shows a situation in which the user performs a diagonal upward sliding operation (or a flicking operation) as an input operation to make the player's character 100 jump diagonally, and the user is notified that the player's character 100 has acquired a new skill and developed that skill as a result of the player's character 100 jumping.

[0091] The user terminal 1 displays on the touch screen 2 a UI component 902 for a certain period of time (e.g., several seconds) near the player's character 100 to notify the player that the player's character 100 has acquired a new skill. This allows the user to easily recognize that the player's character 100 has acquired a new skill and developed the skill as a result of the player's character 100 performing an action through the user's input operation while gazing at the player's character 100 during gameplay. The user terminal 1 ends the display of the UI component 902 when a certain period of time has elapsed since the UI component 902 was displayed. This allows the user to focus on the player's character 100 again and concentrate on having the player's character 100 perform an action after recognizing that the player has acquired a skill and developed the skill.

[0092] The user terminal 1 displays a UI widget 901 near a UI widget 900 displayed on the touch screen 2. The UI widget 901 is an icon indicating that the user has not yet confirmed some of the skills acquired by the player's character 100 and that the user has not yet confirmed the results of the skill growth. In the illustrated example (B), the UI widget 901 indicates the number of skills that the user has not yet confirmed. The user terminal 1 may continue to display the UI widget 901 until there are no more skills that the user has not yet confirmed. This allows the user to focus on the action that the player's character 100 wants to perform, such as performing an action operation while paying attention to the player's character 100, fighting an enemy character, and then calmly checking the skill list, thereby preventing the user from missing an opportunity to confirm the growth of the player's character 100 by displaying the UI widget 901.

[0093] 17 shows an example of a skill list screen that allows the user to check skills that the player's character 100 can acquire and skills that the player's character 100 has mastered. The user terminal 1 displays the screen shown in FIG. 17 on the touch screen 2 by accepting a touch operation by the user on the UI part 900, for example.

[0094] The illustrated example (A) of FIG. 17 shows a situation in which skills that the player's character 100 has not yet acquired and skills that the player's character 100 has already acquired are displayed on the touch screen 2. As shown in the illustrated example (A), the user terminal 1 displays a standard skill button 910, a special skill button 911, a first skill group 912, and a second skill group 913 on the touch screen 2. The standard skill button 910 and the special skill button 911 are icons for switching the type of skill displayed on the touch screen 2 according to an input operation by the user. In the illustrated example (A), the standard skill button 910 is highlighted compared to the special skill button 911 so that the user can recognize that the standard skill button 910 is enabled.

[0095] When a user performs a touch operation on the special skill button 911, the user terminal 1 switches the type of skill displayed on the touch screen 2 and highlights the special skill button 911 compared to the standard skill button 910 so that the user can recognize that the special skill button 911 is enabled.

[0096] The types of skills displayed by the special skill button 911 include, for example, (i) skills that the player's character 100 can learn and develop without taking an action in response to an input operation, (ii) skills that allow the player to view episodes about the player's character 100, (iii) skills that allow the player to display a log of the player's character 100's conversations in past games, and (iv) skills that allow the character to perform attack actions or recovery actions that can be activated by consuming skill points on the screen during battle, in addition to attack actions such as tapping.

[0097] Here, (i) skills that the player's character 100 can learn and develop without relying on an action in response to an input operation include, for example, skills that the player's character 100 can use by acquiring game media as the user plays the game. For example, assume that the user acquires game media in the game that provides various items, skills, characters, virtual currency in the game, etc. as the user plays the game. The user terminal 1 determines by lottery what to grant to the user from the game media. If the target to be granted to the user from the game media is a skill, the user terminal 1 determines by lottery which skill to grant. During game play, the user is granted the grant target (item, skill, character, virtual currency in the game, etc.) according to the lottery result by satisfying a predetermined condition for providing an item or the like from the game media. Here, the user terminal 1 may grant the game media to the user by, for example, having the player's character 100 perform an attacking action to attack an enemy character and defeat the enemy character.

[0098] The first skill group 912 includes skills classified as grade "1" among the skills that the player's character 100 can learn. The second skill group 913 includes skills classified as grade "2" among the skills that the player's character 100 can learn.

[0099] The user terminal 1 updates the grade of the player's character 100 by satisfying a predetermined condition in accordance with the user's game play. For example, the predetermined condition may be satisfied by the user performing an input operation to cause the player's character 100 to perform an action. For example, the user terminal 1 grants the user a game medium that provides an item or the like by having the player's character 100 perform an action in response to the user's input operation to defeat an enemy character or the like. When the target to be provided to the user from the game medium is a character, the user terminal 1 draws a lottery to determine which of a plurality of characters to provide to the user. When a character that the user has not acquired is provided from the game medium as a result of the lottery, the user is allowed to operate the character, and when a character that the user has already acquired is provided from the game medium, the grade of the character is updated. For example, when a character of grade "1" is already operable by the user and the character is provided from the game medium, the user terminal 1 updates the grade of the character from grade "1" to grade "2" and expands the range of skills that the character can acquire.

[0100] In this way, by making it possible to acquire and grow skills within the range of the character's grade until the character's grade is updated, the user can be encouraged to play the game to update the character's grade. In addition, by updating the character's grade by providing characters and the like from game media acquired by the user as the user plays the game, the user can feel the character's growth the more the user plays the game. For example, if the upper limit number of techniques (combo number) that the player's character 100 can use consecutively during an attack action is updated along with the growth of skills, the user can feel the character's growth even more, and can be encouraged to continue playing the game.

[0101] In the illustrated example (A), compared to the first skill group 912, the second skill group 913 displays that there are skills that the user has not yet acquired, so that the skills can be distinguished from the skills that the user has already acquired. For skills that the user has already acquired, the user terminal 1 displays an indication of the skill level near each skill icon. On the other hand, for skills that the user has not yet acquired, the icons are grayed out, and the contents of the skill cannot be discerned from the icon, thereby motivating the user to acquire these skills.

[0102] The illustrated example (B) shows that the user has not yet confirmed some of the skills that the user has acquired or developed. In the illustrated example (B), the user terminal 1 displays a UI component 915 for notifying the user that there are skills that the user has not confirmed on the touch screen 2, superimposed on the icon of the skill, but the display mode of the UI component 915 is not limited to this. This encourages the user to operate the UI component 915, and can further increase the opportunities for the user to realize the growth of the player's character 100.

[0103] 18 is a flowchart showing a process in which the user terminal 1 updates the experience points of each skill for skill acquisition in accordance with the motion of the player's character 100, and notifies the user that the skill has been acquired or developed. The user terminal 1 executes the following steps by operating according to a program.

[0104] In step S1801, the CPU 3 of the user terminal 1 detects that an event has occurred for the player's character 100. The contents of the event include those shown in the item "experience value acquisition condition" in the illustrated example (B) of FIG.

[0105] For example, the event includes an event in which the content of the action to be performed by the player's character 100 is determined in response to an input operation performed on the touch screen 2 by the user to cause the player's character 100 to perform an action, and the CPU 2 issues an instruction to operate the player's character 100 according to the determined content. The content of the event also includes an event in which the player's character 100 reduces its vitality value, such as being within the range of an attack motion performed by an enemy character or colliding with an obstacle. The content of the event also includes an event in which the player's character 100 hits an enemy character with an attack, inflicts damage on an enemy character, recovers the player's character 100, recovers a character other than the player's character 100, etc., as a result of the player's character 100 performing an action.

[0106] In step S1803, the CPU 3 determines the content of the event whose occurrence was detected in step S1801. For example, if the content of the event is to move the player's character 100 in response to an input operation, the CPU 3 determines the content of the action (for example, an attack action, a collection action, etc.) that the player's character 100 will take in response to the input operation.

[0107] In step S1805, the CPU 3 updates the experience value of each skill in accordance with the content determined in step S1803.

[0108] In step S1807, if the experience points for any skill have reached a level required for leveling up as a result of the processing in step S1805, the CPU 3 sets a flag indicating that the user has not confirmed that the skill has been acquired or developed, and displays a notification to that effect on the touch screen 2 in the manner shown in the illustrated example (B) of Fig. 16. The CPU 3 counts the number of skills for which a flag indicating that the user has not confirmed is set, thereby making it possible to display the number of skills that the user has not confirmed in the UI part 901 in the illustrated example (B) of Fig. 16.

[0109] 19 is a flowchart showing a process in which the user terminal 1 displays a screen showing a list of skills acquired by the player's character 100 on the touch screen 2 in response to an input operation by the user. The user terminal 1 operates according to a program to execute the following steps.

[0110] In step S1901, the CPU 3 of the user terminal 1 detects an input operation by the user for displaying a skill list. For example, by detecting a touch operation on the UI widget 900 shown in FIG. 16, the CPU 3 executes the following steps.

[0111] In step S1903, CPU 3 identifies skills that have been newly acquired or developed by the user and that have not been confirmed by the user, based on the flags set for each skill in step S1807.

[0112] In step S1905, the CPU 3 generates an image to be displayed on the touch screen 2 by arranging a notification icon for the skill that has not been confirmed by the user, in order to prompt the user to confirm the skill.

[0113] In step S1907, the CPU 3 displays the image generated in step S1905 on the touch screen 2. For example, the skill displayed by the UI part 915 in the illustrated example (B) of Fig. 17 indicates a skill that has not yet been confirmed by the user as a newly acquired skill or a skill that has been developed.

[0114] [Description of the second embodiment of the present disclosure] Hereinafter, the second embodiment of the present disclosure will be described with reference to the drawings. For the sake of convenience, the description of the members having the same reference numbers as those already described in the description of the present embodiment will not be repeated. In the second embodiment, the operation for switching characters in a game in which a user organizes multiple characters and progresses while switching the characters to be operated during gameplay will be mainly described.

[0115] 6. Explanation of UI image (operation key) display processing The operation key display process in the game program according to this embodiment will be described with reference to FIGS.

[0116] FIG. 20 is a flowchart showing a display process of a user interface image for allowing a user to change a player character in the second embodiment.

[0117] In step S11 of FIG. 20, the control unit 30 judges whether or not the user's finger or the like has approached the touch screen 2 (an approach operation has been input) based on a signal output from the touch sensing unit 10 to the input operation receiving unit 32. If it is judged that an approach operation has been input (Yes in step S11), in step S12, the control unit 30 detects the position of the contact end point. Then, in step S13, the control unit 30 judges whether or not the contact end point is included within a certain area including the position where the approach operation was detected (contact start point). If it is judged that the contact end point is not included within a certain area including the approach start point, that is, that the contact start point and the contact end point are apart from each other by a certain distance or more (No in step S13), in step S14, the control unit 30 judges that the user is requesting an operation of the player's character 100, and causes the player's character 100 to perform a predetermined action based on a vector (see (D) in FIG. 5) defined by the contact start point and the contact end point. 7 around the contact start point, and may elastically deform the control object 40 based on the contact end point. After that, the process returns to step S11, and the process is repeated.

[0118] On the other hand, if it is determined that the contact end point is included in the certain area including the approach start point (Yes in step S13), in step S16, the control unit 30 determines whether or not the time during which the approach operation continues has exceeded the certain time. That is, here, the control unit 30 determines whether or not the user's input operation is a "long press operation." If it is determined that the user's input operation is a "long press operation" (Yes in step S16), in step S17, the control unit 30 displays a predetermined UI image 60 (see FIG. 21) on the touch screen 2.

[0119] Fig. 21 is a diagram showing an example of a game screen in the flowchart shown in Fig. 20. Fig. 22 is a diagram showing an example of a game screen subsequent to the game screen shown in Fig. 21.

[0120] As shown in FIG. 21, the UI image 60 is composed of a base portion 62, a first operation key 64 (an example of a first operation object), and a second operation key 66 (an example of a second operation object). For example, a substantially circular image may be displayed on the base portion 62, or no image may be displayed. That is, the base portion 62 may be configured as a reference for determining the arrangement relationship of the first operation key 64 and the second operation key 66. The first operation key 64 is composed of first to third icons 64A to 64C. The first icon 64A corresponds to the player's character 100 currently displayed on the touch screen 2 (i.e., selected by the user). The second icon 64B corresponds to the character 120 that can be changed to the player's character 100 by user selection. The third icon 64C corresponds to the character 130 that can be changed to the player's character 100 by user selection and is different from the character 120. The second operation key 66 is an operation key for activating the skill of the currently selected character. The skill activated by inputting the second operation key 66 is, for example, an attack action or recovery action that is activated by consuming a certain amount of skill points as described in the example of Fig. 15. In this way, since it is an action that is activated by consuming skill points, it may have a stronger effect than an attack action or the like that the character performs by tapping or the like.

[0121] The first icon 64A displays information (for example, "in use") indicating the character (own character 100) currently being used. The first icon 64A is an icon corresponding to the own character 100 currently displayed on the touch screen 2, and therefore is preferably displayed in an unselectable state. That is, even if the user performs a release operation on the first icon 64A, no action is executed. The second icon 64B and the third icon 64C display information (for example, the faces of the characters 120 and 130) of the own character 100 and the changeable characters 120 and 130, respectively. The second operation key 66 displays, for example, "skill."

[0122] These operation keys 64, 56 are arranged radially with respect to the base part 62, at a predetermined distance to the left of the contact start point (i.e., the base part 62) where the long press operation was performed. The first operation key 64 (each of the icons 64A to 64C) and the second operation key 66 are fixed in their respective positional relationship with respect to the base part 62, which is the position where the operation input was input. For example, in the left side region of the base part 62, the second operation key 66, the first icon 64A, the second icon 64B, and the third icon 64C are arranged asymmetrically with respect to the left-right direction of the touch screen 2, in this order from the top.

[0123] In the example shown in FIG. 21, it is assumed that the user operates the touch screen 2 with the fingers of the right hand, and the first operation key 64 and the second operation key 66 are arranged in the left region of the base part 62 so as to be easily operated with the fingers of the right hand, but this is not limited to this example. For example, when operating with the fingers of the left hand, these operation keys may be arranged in the right region of the base part 62 by the user's selection operation. In this case, the arrangement relationship of each operation key 64, 66 is fixed. That is, the arrangement of the first operation key 64 (each icon 64A to 64C) and the second operation key 66 may be switchable symmetrically between the case of input operation with the user's right hand and the case of input operation with the user's left hand. In this way, by switching the arrangement of the operation keys 64, 66 symmetrically with respect to the base part 62 depending on whether the user operates the touch screen 2 with the right hand or the left hand, the operability can be further improved.

[0124] Next, in step S18, the control unit 30 judges whether or not a release operation has been input. If it is judged that a release operation has been input (Yes in step S18), in step S19, the control unit 30 judges whether or not the position where the release operation has been input (touch-off position) is included in the area of ​​each operation key 64, 56. If it is judged that the touch-off position is not included in the area of ​​each operation key 64, 56 (No in step S19), in step S20, the control unit 30 judges that the user has not requested an operation corresponding to each operation key 64, 56, and does not display the UI image 60 without performing any action. Then, the process returns to step S11, and the process is repeated.

[0125] On the other hand, when it is determined that the touch-off position is included in the area of ​​each operation key 64, 56 (Yes in step S19), in step S21, the control unit 30 executes an operation corresponding to the selected operation key. For example, as shown in Fig. 22(A), when it is determined that a release operation is input on the third icon 64C, the control unit 30 displays the character 130 corresponding to the second icon 64C on the touch screen 2 instead of the player's character 100, and hides the UI image 60, as shown in Fig. 22(B). After that, the process returns to step S11, and the process is repeated.

[0126] FIG. 23 is a diagram showing an example of a user interface image after the user has changed the player character.

[0127] FIG. 23 shows the UI image 60 when the character displayed on the touch screen 2 is changed from the player's character 100 to another character 130 and then a long press operation is input. In this case, the third icon 64C corresponding to the character 130 currently displayed on the touch screen 2 displays "in use", and the third icon 64C is in an unselectable state. The first icon 64A and the second icon 64B display the faces of the character 130 and the changeable characters 100, 120, respectively. In this way, by displaying the icon corresponding to the currently selected character as an icon for changing the character in an unselectable state, the positional relationship of the icons 64A to 64C can be fixed and displayed.

[0128] FIG. 24 is a diagram showing an example of a game screen when a slide operation is input while the user interface image for changing the player character is displayed.

[0129] 24A and 24B show examples of a screen when a slide (drag) operation is input in a predetermined direction after a long press operation is input (a state in which the UI image 60 is displayed). In step S17, when a drag operation is input in a state where the UI image 60 is displayed by a long press operation, the control unit 30 judges whether or not the drag operation from the contact start point to the contact end point is at or below a certain speed. The speed of the drag operation can be detected, for example, based on the slide amount from the contact start point to the contact end point of the drag operation and the number of frames. If the detected speed of the drag operation is at or below a predetermined threshold, the control unit 30 operates the character 100 in response to the drag operation (moving, jumping, etc.) while moving the UI image 60 following the drag operation. For example, as shown in (A) of FIG. 24, when the user performs a drag operation in the direction of the arrow A from a state where the UI image 60 is displayed by a long press operation, the control unit 30 causes the player's character 100 to execute a predetermined action and moves the UI image 60 based on the direction of the drag operation while keeping the UI image 60 displayed. For example, when the drag direction is diagonally upward, the control unit 30 causes the character 100 to jump while displaying the operation object 40 while elastically deforming it based on the drag direction, as shown in (B) of FIG. 24. At the same time, the control unit 30 moves the UI image 60 in accordance with the drag direction while maintaining the relative positions of the first operation keys 64 (icons 64A to 64C) and the second operation keys 66. This allows the currently displayed character to be operated while maintaining a state in which the character 100 can be changed to another character. At this time, the base portion 62 of the UI image 60 is always located at the contact end point of the drag operation, so that the operation keys 64, 66 cannot be selected.

[0130] On the other hand, when the drag operation is faster than a certain speed, the control unit 30 prevents the UI image 60 from moving in accordance with the drag operation, and allows each of the operation keys 64, 66 to be selected. That is, in this case, the user can select each of the operation keys 64, 66 by performing a release operation on each of the operation keys 64, 66. In this way, the freedom of operability can be improved by switching between the operation of the player character 100 and the operation of each of the operation keys 64, 66 depending on the speed of the drag operation.

[0131] As described above, according to this embodiment, the control unit 30 displays the first operation key 64 (UI image 60) for changing the player's character 100 on the touch screen 2 based on the user's long press operation on any position on the touch screen 2, and the user selects and operates the first operation key 64 to change the player's character 100 displayed on the touch screen 2 to a different character (for example, character 130). This makes it possible to provide the UI image 60 for changing the player's character 100 only when the user performs a long press operation, without affecting the operation area or visible range in the space displayed on the touch screen 2 under normal circumstances.

[0132] Furthermore, since the UI image 60 displays the icons 64A-64C and the second operation key 66 with a fixed positional relationship, the user can memorize the positions of the operation keys 64, 66. This allows the user to memorize the positions of the icons 64A-64C and the operation key 66 for skill activation corresponding to the characters 100, 120, 130, and therefore the user can change characters and activate skills without visually checking the display of the UI image 60.

[0133] 7. A process for automatically switching the character that appears in the game field and is the target of the user's operation, regardless of the user's switching operation.

[0134] As described above, the user can change the character to be operated by performing an input operation on each of the operation keys 64, 66. When the user is progressing through the game by forming a party of characters that can be changed during the game, the user terminal 1 changes the character to be displayed on the touch screen 2 in response to an input operation for changing each character included in the party.

[0135] Here, in the second embodiment, the user terminal 1 can perform processing to automatically switch in accordance with the progress of the game, without relying on an input operation (operation on each operation key 64, etc.) for changing the character to be operated by the user. Specifically, without relying on an input operation for changing the character by the user, the user can select between a first mode (auto-change application mode) in which the character is automatically changed (auto-changed) during a battle with an enemy character, and a second mode (auto-change stop mode) in which the first mode is stopped.

[0136] In the first mode, for example, the parameters of each character to be operated by the user are compared with the parameters of an enemy character to identify one of the characters included in the party formation, and the identified character is displayed on the touch screen 2, thereby changing the character to be operated by the user. Here, a large number of enemy characters may be displayed on the touch screen 2, but the user terminal 1 may set the enemy character to be compared with the parameters of each character as a character that the user operates as a locked-on character to perform an attack action. In the locked-on state, regardless of whether the character 100 is facing the enemy character 200 or not, when the user causes the character 100 to perform an attack action by a tap operation or the like, the character 100 performs an action for an attack action toward the enemy character 200. For example, the user terminal 1 sets the enemy character 200 that is closest to the character 100 as the character that the character 100 has locked on as an attack target.

[0137] In the first mode, the user terminal 1 specifies a character to be displayed on the touch screen 2, for example, (i) specifying a character to be changed based on parameters related to attacks of each character included in a party against an enemy character that is the target of attacks by the character operated by the user. The user terminal 1 specifies, for example, a character with the highest damage efficiency against enemy characters as the character to be displayed on the touch screen 2.

[0138] As described in the first embodiment, the character operated by the user can grow its parameters by performing various actions according to the input operation of the user. When the user terminal 1 specifies a character to fight an enemy character based on attack-related parameters, it can also specify, as the character to be displayed on the touch screen 2, a character that can inflict the highest amount of damage on the enemy character per unit time based on the attack power, the number of combos, etc., by referring to the correction contents of each parameter of the characters organized into a party by the user.

[0139] Furthermore, the user terminal 1 may (ii) specify a character to be displayed on the touch screen 2 depending on the likelihood that the character will survive if the character operated by the user is attacked by an enemy character that is the target of attack. For example, the user terminal 1 specifies, among the characters included in the party formation, a character that will receive the least damage even if attacked by an enemy character.

[0140] Furthermore, the user terminal 1 may (iii) specify a character that is likely to be able to successfully attack the character to be attacked as a character to be displayed on the touch screen 2 based on the parameters of the movement speed of the character to be attacked and the parameters related to the movement of each character organized into a party by the user (movement speed, speed of evasion action, distance of evasion action, jump speed, jump distance, etc.). For example, if the enemy character moves fast, and if the character operated by the user has an attacking means such as a one-handed sword, fist, or axe, it is assumed that a character that can easily follow the movement of the enemy character may be more likely to hit the enemy character with an attack. The user terminal 1 compares the parameters related to the movement of the enemy character with the parameters related to the movement of each character organized into a party, and specifies, for example, a character whose movement speed is equal to or faster than that of the enemy character as a character to be displayed on the touch screen 2.

[0141] 25 is a diagram showing a character that the user may operate in the game program and a data structure of character management information for managing the characters that the user may operate. The user terminal 1 holds data having the data structure shown in FIG. 25 in the main memory 4 or the like, and progresses with the game while appropriately referring to the data.

[0142] As shown in FIG. 25, the character management information includes an item "character identification information," an item "character name," an item "character attributes," an item "user usability," an item "party composition," and an item "grade."

[0143] The item "character identification information" is information for identifying each character that the user can acquire as an object to be operated in the game program.

[0144] The item "character name" indicates the name of each character.

[0145] The item "character attribute" indicates an attribute set for each character. Here, the attribute set for a character includes the type of equipment item that the character can equip. The equipment items include the type of weapon, the type of armor, and the type of accessory that can be associated with the character. The attributes set for each character include other parameters that are set separately from the weapon type and are referred to during attack and defense. For example, there are some characters that have compatibility set for each type, such as a rock-paper-scissors system. In the example of FIG. 25, for example, compatibility is set such that the type "water" is strong against the type "fire", the type "fire" is strong against the type "earth", and the type "earth" is strong against the type "water", and the amount of damage in a battle between characters may be corrected based on these compatibility. In addition, for example, some characters may have attributes that are weak points and attributes that can nullify attacks. For example, for a flying character, attacks of the type "earth" are nullified (the character does not receive damage), while attacks of the type "wind" are considered to be a weakness, and the amount of damage when attacked increases.

[0146] In the first mode, when identifying a character to be changed based on parameters related to attacks of each character included in a party against an enemy character that is the target of attacks by a character operated by a user, the user terminal 1 may identify the character to be changed based on attributes set for these characters and attributes set for the enemy character. For example, the user terminal 1 can identify a character that inflicts the most damage on an enemy character per unit time based on an attack value determined by a base value, a correction value due to equipment, and a correction value due to skills of each character, the maximum combo number when each character attacks, the attributes of each character, and the attributes of the enemy character, among the characters organized in a party.

[0147] The item "User usability" indicates whether the character is available for the user to use in game play or is a character that the user has not yet acquired.

[0148] The item "party composition" indicates whether or not the user has incorporated a character as a character to be organized into a party when playing the game. For example, when a game can be played in a group of three people, the user terminal 1 accepts from the user a designation of at least one and up to three characters to be a party from among the characters that the user can use, and saves the accepted party composition (also called a deck).

[0149] The item "grade" indicates the range of skills that a character can acquire, as described in the first embodiment.

[0150] FIG. 26 shows a user interface image for switching between a first mode, in which the character is automatically changed during a battle with an enemy character without the user having to perform an input operation to change the character, and a second mode, in which the first mode is stopped, and a game screen in which the character is changed by auto-change.

[0151] As shown in the illustrated example (A) of FIG. 26, the user terminal 1 displays a UI image 64E on the touch screen 2 in the user interface image for receiving a change operation from the user as to whether to set the mode to the first mode capable of auto-change or to switch the first mode to the second mode. As described in FIG. 23, when the user terminal 1 receives a long press operation from the user, the UI image 60 including the UI image 64E is displayed on the touch screen 2. In the illustrated example (A), the UI image 64E displays "Auto character change: ON" to indicate that the user has enabled the first mode, and also displays that the first mode can be switched to the second mode by a drag operation or the like on the UI image 64E. As shown in the illustrated example (A), it is desirable to suppress erroneous input by the user by displaying the UI image 64E for indicating whether to enable auto-change at a position different from the UI image 64 for the user to switch the character to be operated and the UI image for activating a skill on the character to be operated. As shown in the illustrated example (A), a UI image for activating a skill on the character being operated, a UI image 64 for switching the character being operated, and a UI image 64E may be arranged to face a base portion 62 that is displayed based on the location where the user performs a long press operation.

[0152] Illustrated example (B) and illustrated example (C) show a situation in which the parameters of each character operated by the user and the enemy character 200 are compared in a state where the auto character change is enabled, and the character operated by the user is changed from the character 130 to the character 100. In illustrated example (B), it is assumed that the character 130 and the enemy character 200 are within a certain distance from each other, and therefore the character 130 is in a state of locking on to the enemy character 200. In this state, the user terminal 1 accepts a tap operation on the touch screen and displays a UI part 260 indicating that the tap operation has been performed. At this time, in response to the occurrence of an event for making the character 130 perform an attack action due to the tap operation, the user terminal 1 compares the parameters of each character organized in the party with the parameters of the enemy character 200, and displays them on the touch screen 2 to specify the character to be operated by the user. In the example illustrated in FIG. (B), it is assumed that the character 100 is specified as the character to be used in battle with the enemy character 200, instead of the character 130. As a result, the user terminal 1 transitions the screen from the state shown in the diagram (B) to the state shown in the diagram (C).

[0153] As shown in the illustrated example (C), the character to be operated by the user is switched from character 130 to character 100. For example, the user terminal 1 displays character 130 as if it is moving outside the screen, and displays character 100 as if it is moving from outside the screen into the screen with an attack determination. As a result, the character 100 that appears on the touch screen 2 due to the character change attacks the enemy character 200 while switching with character 130. The user terminal 1 displays a UI image 262 on the touch screen 2 for a certain period of time together with the character change, which allows the user to recognize that the character to be operated by the user has switched. As a result, the user can easily recognize that the character has been changed by auto-change, regardless of whether the user has performed an operation to change the character, and can easily concentrate on the action of the changed character.

[0154] In addition, when the user changes the character based on the user's operation by operating UI images 64A and 64B, the user is already aware that the character will change, so UI image 262 may not be displayed when the character is changed, but UI image 262 may be displayed when the character is changed by auto-change.

[0155] 27 is a flowchart showing a process of identifying characters that will fight enemy characters among characters organized into a party in the auto-change application mode, and displaying the characters on the touch screen 2 according to the identification result. The user terminal 1 executes the following steps by operating according to a program.

[0156] In step S2701, the CPU 3 of the user terminal 1 detects that the event that has occurred for the character 100 is one that generates an attacking action. For example, when the user performs a tap operation on the touch screen 2, the user terminal 1 determines that the user's input operation is a tap operation, and generates an event for generating an attacking action for the character 100 because the action corresponding to the tap operation is an attacking action (example of FIG. 6).

[0157] In step S2703, CPU 3 compares the parameters of the enemy character that character 100 has locked on to as an attack target with the attack power, attributes, and other parameters of each character in the party that affect the amount of damage, and identifies the character that will inflict the greatest amount of damage per specified time.

[0158] In step S2705, if the character specified in step S2703 is a character currently in battle in the game field (a character currently being operated by the user in response to an input operation), CPU 3 causes the character to perform an attacking action. On the other hand, if the character specified in step S2703 is not a character currently in battle in the game field but a character waiting in the party, CPU 3 performs an effect in which the character specified in step S2703 appears on touch screen 2 instead of the character currently in battle, and switches the character to be operated by the user to the character specified in step S2703.

[0159] The first and second embodiments have been described above. The first and second embodiments may be combined.

[0160] In the description of the first embodiment, it was stated that "here, (i) skills that the player's character 100 can learn and develop without taking an action in response to an input operation include, for example, skills that the player's character 100 can use by acquiring game media as the user plays the game. For example, assume that the user acquires game media during the game that provides various items, skills, characters, in-game virtual currency, etc. as the user plays the game. The user terminal 1 determines by lottery what item to grant to the user from the game media. If the item to be granted to the user from the game media is a skill, the user terminal 1 determines by lottery which skill to grant. During game play, the user is granted the grant item (item, skill, character, in-game virtual currency, etc.) according to the lottery result by satisfying a predetermined condition for providing an item or the like from the game media. Here, the user terminal 1 may grant the game media to the user when the user has the player's character 100 perform an attacking action to attack an enemy character and defeat the enemy character."

[0161] As described in the second embodiment, the user may operate multiple characters, each of which may have its own unique skill. In the above example, when the user is granted new character skills, equipment items, and material items for generating equipment items as the user plays the game, the scope of the grant may be related to the characters in the party.

[0162] Specifically, when the user forms a party and then fights an enemy character in the game field to obtain a game medium, the game terminal 1 may limit the objects to be provided by lottery from the game medium to those related to the characters included in the party, or may increase the proportion of those related to the characters included in the party compared to the proportion of those related to the characters not included in the party. For the user, even if an item, skill, etc. that strengthens a character not included in the party is obtained, it does not lead to strengthening the character actually included in the party. However, by configuring as described above, it is possible to reduce the occurrence of a situation in which the user is prevented from gaining an advantage in the game progress by strengthening the character and from experiencing the growth of the character, thereby reducing interest. For example, when equipment items and material items that are materials for equipment items are provided from the game medium, those that can be equipped by the characters included in the party may be provided preferentially.

[0163] In addition, when a character is provided from the game medium, as described in the first embodiment, if a character already acquired by the user is provided, the grade of the character is updated, and if a character not acquired by the user is provided, the user can make it a new character to be operated, which is thought to increase the interest of the game for the user. Therefore, when a character is provided from the game medium, the character may be provided according to a predetermined provision ratio regardless of which characters are included in the party composition.

[0164] (Modification) In addition to the above-mentioned second embodiment, the following configuration may be used. That is, even if the auto character change is enabled, under certain conditions, character change without the user's input operation for changing the character may not be executed. For example, even if the character specified in step S2703 of FIG. 27 is a character suitable for maximizing the amount of damage to an enemy character, there may be a situation in which the character is attacked and cannot continue the battle when the character's vitality value is low. In addition, if the character is running out of skill points, the number of times that the character can execute a powerful attack by activating a skill is limited.

[0165] Therefore, in step S2703, a character that will fight against an enemy character may be specified based on the remaining vitality value and remaining skill points of the characters to be organized into a party. For example, in the case of forming a party, the characters included in the party are ranked based on the amount of damage inflicted on the enemy character per predetermined time, and if the remaining vitality of the character is less than a certain level, the character with the next highest ranking is given priority, and if the remaining vitality is more than a certain level, the character is specified as the character to be operated by the user.

[0166] (Additional Note 1) The following additional notes are added to the matters described in the above embodiment. (Note 1) According to this embodiment, a game program is provided. The game program is executed on a computer (1) that includes a processor (3), a memory (4), a display unit (7), and an operation unit (2) for receiving input operations from a user. The game program causes the processor to execute the steps of: storing in the memory, for each of a plurality of correction contents, a condition for applying the correction contents (item "parameter correction contents" in the illustrated example (B) of FIG. 15) for correcting the character parameters of the game character operated by the user to the game character (a value of experience points required for leveling up in the item "experience points" in the illustrated example (B) of FIG. 15) and a comparison parameter indicating the status of achievement of the condition (a value that increases when a condition indicated in the item "experience points acquisition condition" in the item "experience points" in the illustrated example (B) of FIG. 15 is satisfied); specifying the content of an event that has occurred for the game character as a result of the user performing an input operation on the operation unit to operate the game character (FIG. 6, step S1803); updating the comparison parameter for the correction contents related to the content of the event in response to the occurrence of the event (step S1805); and, when the comparison parameter for each correction content achieves the condition, applying the correction content corresponding to the condition to the game character, thereby correcting the character parameters of the game character so as to give an advantage in game play (step S1807).

[0167] (Appendix 2) In (Appendix 1), a range of correction contents that can be adapted to a game character among multiple correction contents is set (first skill group 912 and second skill group 913 shown in illustrated example (A) of Figure 17), and the processor is further caused to execute a step of resetting to expand the range of correction contents that can be adapted to a game character by satisfying a predetermined expansion condition as the user plays the game (for example, when a character of grade "1" is provided from the game medium in a state in which the character is operable, the user terminal 1 updates the grade of the character from grade "1" to grade "2" and expands the range of skills that the character can acquire).

[0168] (Appendix 3) In (Appendix 2), the processor is further caused to execute a step of granting to the user, as the user plays the game, a game medium representing the right of the user to acquire an object usable during game play, and the extended condition includes granting a predetermined object to the user from the game medium by receiving an input operation from the user to acquire the object from the game medium (for example, when a character of grade "1" is provided from the game medium in a state in which the character is operable, the user terminal 1 updates the grade of the character from grade "1" to grade "2", and expands the range of skills that the character can acquire).

[0169] (Appendix 4) In any of (Appendix 1) to (Appendix 3), at least one of the multiple correction contents includes a correction of a character parameter for a game character to affect other game characters (such as the "Critical Rate Up" item in the "Skill Name" and the "Parameter Correction Content" item corresponding to "Weapon Type Proficiency" in the illustrated example (B) of FIG. 15).

[0170] (Appendix 5) In (Appendix 4), at least one of the multiple correction contents includes an increase in the number of times a game character can perform consecutive attack actions in response to an input operation for the game character to affect another game character (such as "Maximum combo count +2" in the "Parameter correction content" item corresponding to the "Weapon type proficiency" item in the "Skill name" item in the illustrated example (B) of FIG. 15).

[0171] (Appendix 6) In any of (Appendix 1) to (Appendix 5), at least one of the multiple correction contents includes a content related to a character parameter that decreases when a game character is affected by another game character (such as the item "Parameter Correction Content" corresponding to "Damage Reduction on Guard" in the item "Skill Name" in the illustrated example (B) of Figure 15).

[0172] (Appendix 7) In any of (Appendix 1) to (Appendix 6), in the specifying step, the event that occurs includes having a game character take an action through a user's input operation, and specifying the content of the event includes specifying the content of the action to be taken by the game character (e.g., step S1803, Figure 6, "Deal damage to other characters by attacking" in the item "Experience point acquisition condition" in the illustrated example (B) of Figure 15).

[0173] (Appendix 8) In any of (Appendix 1) to (Appendix 7), the events that occur in the identifying step include events that occur to the game character as a result of the game character being affected by another object (e.g., step S1803, Figure 6, "Character receives damage" in the item "Experience point acquisition condition" in the illustrated example (B) of Figure 15).

[0174] (Supplementary Note 9) In any of (Supplementary Note 1) to (Supplementary Note 8), when the comparison parameters for each correction content satisfy the conditions, a step of displaying a notification indicating that there is a correction content that satisfies the conditions is further executed (UI part 901 in FIG. 16).

[0175] (Appendix 10) In (Appendix 9), the following steps are further executed: displaying on the display unit an interface image (UI component 900 in FIG. 16) which transitions to a list screen (FIG. 17) including a list of correction contents applicable to the game character and a list of correction contents which have been applied to the game character; and displaying the list screen on the display unit in response to a user's input operation on the interface image. In the step of displaying the list screen, the list screen is displayed on the display unit in a manner which allows the user to distinguish between correction contents for which the user has not confirmed that a condition has been met (UI component 915) and correction contents for which the user has confirmed that a condition has been met.

[0176] [Embodiment 3] Next, in the configuration of the above embodiment, a mode in which each character is associated with an attribute called a job (occupation) will be described. In this embodiment, a job for each character is provided by a lottery process. When a job is set for a character (for example, the character "XXX" can be set from the attribute "none" (no particular job setting) to the attribute "magic swordsman" or the like). At this time, even if the character "XXX" was originally unable to equip equipment, equipment related to the job can be equipped. For example, even if the character "XXX" can originally equip the weapon "spear" but cannot equip other types of weapons, when the job becomes "magic swordsman", the weapon "sword" can be equipped. This allows for diversification not only of job skills but also of equippable weapons.

[0177] FIG. 28 is a table showing game media provided by the lottery process. As shown in FIG. 28, the table associates the name of the game media to be provided, the type name of the game media, the rarity of the game media, and the probability of providing the game media. As shown in the example of FIG. 28, the game program provides, as the provided objects, a "job" which is an attribute of each character, and "equipment items" (weapons, armor, etc.) that can be equipped by each character. For example, the job "magic swordsman" for the character "XXX" is provided, and the rarity of the game media is set to "4". The table shown in FIG. 28 is held in the user's terminal or the server.

[0178] Fig. 29 shows an example of a screen displayed on the display 2 of the user's terminal during the lottery process. Example (A) of Fig. 29 is an example of a screen for receiving an input operation from the user to start the lottery. Example (B) of Fig. 29 is an example of a screen for displaying the result of executing the lottery process.

[0179] As shown in example (A), icons (icons 2903, 2904, 2905, 2906) for starting the lottery process and image display sections 2901 and 2902 for presenting the user with an example of game media provided by the lottery process are displayed on touch screen 2 of the user's terminal. When providing a character's job by lottery, for example, the game program displays the name, image, etc. of the character related to the job on image display section 2901. When providing a character's job by lottery, the game program displays, for example, (i) the name of the job, (ii) the type of equipment that can be used for the job, and (iii) a special character action (special skill) that can be used for the job on image display section 2902.

[0180] Icon 2903 is for accepting an operation to execute the lottery process once using virtual currency. Icon 2905 is for accepting an operation to execute the lottery process once by consuming an item other than virtual currency.

[0181] The icon 2904 is for accepting an operation to execute the lottery process multiple times using virtual currency. For example, compared to executing a single lottery using virtual currency, it is possible to execute the lottery process a certain multiple (for example, 10 times).

[0182] Icon 2905 is for accepting an operation to execute the lottery process multiple times by consuming an item other than virtual currency.

[0183] As shown in example (B), the game program displays the results of the lottery process (the provided game media 2910-1 to 2910-11) on the touch screen 2 of the user's terminal. In example (B), in response to an operation on icon 2904, the result of the lottery process for the 11th floor is displayed.

[0184] In example (B), the job of the character "XXX" is granted to the user by a lottery process (game medium 2910-1). In addition, game medium 2910-6 shows that when a job of a character previously acquired by the user is granted to the user by the current lottery process, a job enhancement item that can be used to enhance any character's job has been granted to the user in place of the job. When an operation on icon 2907 is accepted, the game program executes a lottery process.

[0185] FIG. 30 is an example of a screen for displaying skills associated with a character's job.

[0186] As shown in FIG. 30, a job can be assigned to each character by the user. The touch screen 2 displays a list of skills that can be activated by a certain character's job, "magic swordsman." On the touch screen 2, a grade 1 special skill for the job "magic swordsman" is displayed in a skill display area 3012. On the touch screen 2, a grade 2 special skill for the job "magic swordsman" is displayed in a skill display area 3013.

[0187] In the above embodiment, it has been explained that the standard skills and special skills of each character are acquired by having each character perform an action. Here, when a job is set for each character, it is possible for the character to acquire a special skill (one that causes an action to be performed) specific to the job. In order to acquire this special skill specific to the job, a job enhancement item is used, which is provided to the user when the characters' jobs overlap through a lottery process. Regardless of which characters' jobs overlap, a common job enhancement item is given to the user. The user's terminal accepts an operation to consume the job enhancement item from the user, and can increase the grade of the character's job that the user has already acquired (for example, the grade of the job "magic swordsman" can be increased from grade "1" to grade "2" by consuming a job enhancement item).

[0188] Fig. 31 is a flowchart shown in this embodiment. The process shown in Fig. 31 is executed, for example, by either the user's terminal or the server, or by receiving a process for executing a lottery on the user's terminal, executing the lottery process on the server, and displaying the result of the lottery process on the server on the user's terminal.

[0189] In step S3101, the user's terminal accepts an operation to start a lottery from the user via the touch screen 2.

[0190] In step S3103, the user's terminal identifies the game media to be provided by lottery, with reference to the table shown in Fig. 28. When identifying the attributes of a character to be provided as the object to be provided, if the attributes overlap with a job of a character already acquired by the user, the user's terminal determines to provide the user with an item to strengthen the job.

[0191] In step S3105, the user's terminal displays the game content to be awarded to the user as a result of the lottery process.

[0192] As described above, according to the game program of this embodiment, the computer stores in memory information indicating attributes (jobs) that can be associated with one or more characters operated by the user. The game program causes the computer to perform a lottery process in which the attributes (jobs) of the characters are provided. When an attribute (job) that can already be associated with the character is provided as a result of the lottery process (due to a job overlap), the game program causes the computer to perform a process for updating parameters related to the attribute (job) (for example, granting a job enhancement item to the user).

[0193] The game program further causes the processor of the computer to execute the steps of moving the character in response to an input operation by the user on the operation unit (touch screen 2) and updating a first parameter (HP, SP, etc. in the above embodiment) indicating the performance of the character based on the moving of the character. The game program updates the first parameter by moving the character (HP increases, a skill is developed), while performing a process for updating a parameter related to an attribute (job) regardless of the history of moving the character (for example, a job strengthening item is given to the user).

[0194] The game program further causes the computer processor to execute a step of changing the character to the attribute (job) designated by the user in response to a user's input operation for designating one of the attributes (jobs) that can be associated with the character (accepting the user's operation for selecting a job to be set for the character). When the attribute (job) of the character is changed by designating the attribute (job), the game program applies the first parameter (HP, SP, etc.) to all attributes (jobs).

[0195] The game program includes a step of granting a first item (job enhancement item) to a user in response to an attribute (job) that can already be associated with a character being provided by a lottery process, and a step of updating parameters related to the attribute (job) that can be associated with one or more characters (increasing the grade of the job and expanding the range of special skills that can be acquired according to the job) by consuming the first item (job enhancement item).

[0196] In response to an attribute (job) that can already be associated with a character being provided by the lottery process, the game program updates parameters related to the character's attribute (job) (such as increasing the job grade). Such a configuration allows the user to play the game in a more diverse manner.

[0197] The above-mentioned embodiment is merely an example for facilitating understanding of the present invention, and is not intended to limit the present invention. The present invention can be modified or improved without departing from the spirit of the present invention, and it goes without saying that the present invention includes equivalents thereof. [Explanation of symbols]

[0198] 1: user terminal, 2: touch screen, 3: CPU, 4: main memory, 5: auxiliary memory, 6: transmission / reception unit, 7: display unit, 8: input unit, 10: touch sensing unit, 20: display unit, 30: control unit, 32: input operation reception unit, 34: character operation detection unit, 36: object control unit, 38: display control unit, 40: operation object, 42: base unit, 44: tip unit, 46: connection unit, 53: buffer memory, 55: initial touch position coordinates, 60: action table, 80: operation object control program module, 82: input operation reception program module, 84: operation object drawing program module, 90: character control program module, 100: player character (player character, an example of a character object), 200: opponent character

Claims

1. Computer, a selection means for performing a selection process for providing attributes that can be associated with one or more first objects to be operated; a storage means for storing information indicating the attribute provided in accordance with the result of the lottery process in a memory; A program that functions as an update means that can execute a process for updating an attribute that has already been provided in accordance with the result of the lottery process that has already been performed and therefore can be associated with the first object, by providing the attribute again in accordance with the result of a new lottery process that has been performed, so as to grow a parameter related to the provided attribute itself.

2. 2. The program of claim 1, wherein the update means executes the process for updating by again providing an attribute that has already been associated with the first object, thereby granting a second object to a user and consuming the second object.

3. 3. The program of claim 2, wherein the second object is a common object regardless of which attribute the provided attribute is.

4. a selection means for performing a selection process for providing attributes that can be associated with one or more first objects to be operated; a storage means for storing information indicating the attribute provided in accordance with the result of the lottery process in a memory; The system further comprises: an update means for executing a process for updating an attribute that has already been provided in accordance with the result of the lottery process that has already been performed and therefore can be associated with the first object, by providing the attribute again in accordance with the result of a newly performed lottery process, so as to grow a parameter related to the provided attribute itself.

Images