Programs and systems

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, players control game characters to progress through the game. In these games, the game characters are given experience points by, for example, making them act in accordance with user input operations and fighting enemy characters. As the game characters grow, they can fight and defeat stronger enemy characters, thereby progressing through the game.

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

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2016-051266 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, which allows the user to 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 a game character gains experience points, its level increases, and each time it reaches a certain level, it acquires skills such as attack spells. However, if the way a game character grows is monotonous, the range of gameplay developments becomes narrow, and it becomes necessary to further increase the interest of the game.

[0007] Some games provide a variety of options for character development during the game, allowing the user to actively intervene in the character development, resulting in a wide variety of game developments. For example, in some role-playing games, the player character is initially assigned a profession such as warrior, wizard, priest, or fighter, and this profession can be changed during the game by changing jobs. For example, by making the skills acquired different depending on the profession, the user can progress through the game in accordance with the character development method they have chosen.

[0008] However, in games that employ such a job change system, the user typically selects the job to which the character will change, but the character often ends up at a low level in the new job. As a result, the user must carefully develop the character after assigning it to a certain job. 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 developments may not be encouraged.

[0009] The present disclosure provides: character The present invention aims to provide a technology that can support more diverse developments by diversifying the parameter update methods, thereby making it possible to further increase the interest of play. [Means for solving the problem]

[0010] According to one embodiment of the present disclosure, a program is provided, the program causing a computer to execute one or more operations on one or more target devices. character Regarding character a lottery means for performing a lottery process in which attributes that can be associated with the user are provided as the subject of the lottery process; a storage means for storing information indicating the attributes provided in accordance with the result of the lottery process in a memory; and a storage means for storing information indicating the attributes that have already been provided in accordance with the result of the lottery process. character The attribute that can be related to the attribute is provided again in accordance with the result of a newly performed lottery process, and the attribute is made to function as an updating means that can execute a process for updating the parameter related to the provided attribute itself so as to grow.

[0011] According to one embodiment of the present disclosure, a system is provided, the system comprising one or more character Regarding character a lottery means for performing a lottery process in which attributes that can be associated with the user are provided as the subject of the lottery process; a storage means for storing information indicating the attributes provided in accordance with the result of the lottery process in a memory; and a storage means for storing information indicating the attributes that have already been provided in accordance with the result of the lottery process. character and an updating means for executing a process for updating the attribute itself so as to grow when the attribute that can be associated with the attribute is again offered in accordance with the result of a newly performed lottery process.

[0012] According to one embodiment of the present disclosure, there is provided a method executed on a computer including a processor and a memory, the method including: a first step of storing, in the memory, information indicating attributes that can be associated with one or more characters to be operated, the characters; a second step of performing a lottery process to provide the attributes of the characters; and a third step of performing a process to update parameters related to the attributes when the attributes that can already be associated with the characters are provided as a result of the lottery process. [Effects of the Invention]

[0013] According to the present disclosure, by diversifying the methods for updating character parameters, it is possible to support a greater variety of developments, thereby further increasing the interest of the gameplay. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 2 is a diagram illustrating a user terminal according to the present embodiment. [Figure 2] FIG. 2 is a diagram illustrating a hardware configuration of a user terminal according to the present embodiment. [Figure 3] FIG. 2 is a functional block diagram of a user terminal according to the present embodiment. [Figure 4] FIG. 10 is a diagram showing an example of a game screen of a game displayed on a touch screen of a user terminal according to this embodiment. [Figure 5] 10A and 10B are diagrams illustrating a process in which an operation detection unit detects a direction in which a player character moves in response to an input operation by a user. [Figure 6] FIG. 10 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 an operation object displayed on a touch screen, and FIG. 1B is a diagram showing a state in which the operation object is elastically deformed. [Figure 8] FIG. 2 is a schematic diagram showing main functional modules implemented in the game program according to the present embodiment. [Figure 9] 10 is a flowchart showing a process for displaying information relating to the state of a player character within an operation object in the present embodiment. [Figure 10] 10(A) and 10(B) are diagrams showing examples of game screens in the flowchart of FIG. [Figure 11]These are examples of screens when a user wants a player character to perform a specified action, where (A) is a diagram showing an example of a screen in which the player character is jumping, (B) is a diagram showing an example of a screen when the input operation for the specified action is successful, and (C) is a diagram showing an example of a screen when the input operation for the action is unsuccessful. [Figure 12] These are examples of screens when a user wants a player character to perform a specified action, where (A) is a diagram showing an example of a screen in which the player character is jumping, (B) is a diagram showing an example of a screen when the input operation for the specified action is successful, and (C) is a diagram showing an example of a screen when the input operation for the action is unsuccessful. [Figure 13] FIG. 10 is a diagram showing a game screen according to a modified example. [Figure 14] FIG. 10 is a diagram showing an operation object according to another modified example. [Figure 15] This figure shows the data structure of the parameters of game characters that can be operated by the user, such as the player's character 100, and a data structure that includes the correspondence between the history of various actions that the game character has performed in response to the user's input operations and the skills that the game character has acquired. [Figure 16] 10 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] 10 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 acquired. [Figure 18] This is a flowchart showing the process in which the user terminal 1 updates the experience points for each skill for skill acquisition in accordance with the action content of the player's character 100, and notifies the user that a skill has been acquired or developed. [Figure 19] 10 is a flowchart showing a process in which the user terminal 1 displays a screen listing skills acquired by the player's character 100 on the touch screen 2 in response to an input operation by the user. [Figure 20]10 is a flowchart showing a display process of a user interface image for 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] FIG. 22 is a diagram showing an example of a game screen subsequent to the game screen shown in FIG. 21. [Figure 23] FIG. 10 is a diagram showing an example of a user interface image after a user has changed the player character. [Figure 24] FIG. 10 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 displayed. [Figure 25] 10 is a diagram showing a character that can be controlled by a user in a game program and a data structure of character management information for managing characters that the user is not allowed to control. FIG. [Figure 26] FIG. 10 shows a user interface image for switching between a first mode, which automatically changes characters during a battle with an enemy character without the user having to perform an input operation to change the character, and a second mode, which stops the first mode, and a game screen in which the character is changed by auto-change. [Figure 27] 10 is a flowchart showing a process of identifying characters that will fight enemy characters from among characters organized into a party in auto-change application mode, and displaying the characters on the touch screen 2 in accordance with the identification results. [Figure 28] 10 is a table showing game media provided by lottery processing. [Figure 29] 10 shows an example of a screen displayed on the display 2 of the user's terminal during the lottery process. [Figure 30] 10 is an example of a screen for displaying skills associated with a character's job. [Figure 31] 1 is a flowchart according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0015] In the following description, a technique will be described that supports diversifying game developments by diversifying updates to game character parameters. First, (a) a configuration in which predetermined information is displayed on a touch screen to assist a user in controlling a game character through input operations of the game character has been described. However, this configuration is not limited to displaying information indicating the game character's actions on a touch screen. Furthermore, while an example of accepting a user's input operations is shown in which input operations are accepted on a touch screen, this is not limiting. The disclosure of the following embodiments may also be applied to cases in which a game character is controlled by input to a game controller or the like. (b) Next, a game program will be described in which various parameters of the character can be enhanced as a result of the character taking an action in response to a user's input operations. (c) In this configuration, each character will be further associated with an attribute called a job (occupation). In this embodiment, the attributes of each character are assigned to the user through a lottery process. Furthermore, when a character changes jobs, the character's parameters, such as stamina and skill points, are retained from before the job change. After the job change, the character can equip equipment items unique to that job and activate skills unique to that job. The game program updates job-associated parameters, such as job-specific skills, as follows. For example, when a job that has already been offered to a user is offered again by lottery, the game program may give the user a material item for growing parameters related to the job, or may grow 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 allowing the character's parameters related to the job itself to grow according to the results of a lottery process. This encourages the user to acquire new jobs one after another through lottery, further supporting diversification of game development. In this way, the game program grows the first parameters representing the character's performance by having the character perform actions such as attacking, dodging, and jumping in response to the user's input operations. The game program assigns the character's job, which is an attribute of the character, to the user through lottery. The game program updates the second parameters (such as job-specific skills) corresponding to the character's job using a method different from the method of growing the first parameters. Specifically, when the game program performs a lottery process to assign a character's job, if the game program determines through lottery that a job already acquired by the user will be offered (i.e., if the job is duplicated), the game program either assigns the user an item for updating the second parameters related to the job, or updates the second parameters related to the job. In a conventional game where a character's job can be updated, parameters are initialized each time the character changes jobs (e.g., returning to level 1). Another conventional game allows a user to change jobs by selecting a job of their choice. Compared to this conventional example, the game program disclosed herein assigns a character's job to the user through a lottery process, eliminating the user's confusion about which job to select. Furthermore, the game program disclosed herein allows the user to enjoy character growth through jobs in addition to the growth of basic parameters. Furthermore, because jobs can be grown by overlapping jobs through a lottery process to acquire jobs, the user is encouraged to acquire jobs one after another through lotteries. This allows the user to diversify the ways in which the character grows, encouraging them to play the game in a more diverse manner, further enhancing the enjoyment of the game.

[0016] First, the outline of the configuration for displaying the details of the action being performed by the game character on the touch screen 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 gaming method comprising: The game method comprises: (a) displaying an operation object on the touch screen from a start point of the input operation toward 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 predetermined information associated with the detected state of the character object on the touch screen in association with the operation object.

[0018] According to the above method, it is possible to provide the user with intuitive feedback regarding the input operation.

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

[0020] According to the above method, by displaying the status display information on the enlarged portion of the operation object, which is dead space on the touch screen, it is possible to effectively use 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), the character object may be put into a first state by performing a first input operation, and the predetermined action may be executed by performing a second input operation in the first state.

[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 a second input operation may be performed in the first state or the second state to execute the predetermined action.

[0025] According to these methods, even for an action that requires multiple input operations, it is possible to provide the user with feedback in an easy-to-understand manner as to whether the input operations have been successful.

[0026] (6) A program according to an 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 the 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 components having the same reference numerals as those already described in the description of the present embodiment will not be repeated.

[0029] As shown in FIG. 1 , a game program according to an embodiment of the present disclosure is executed on a user terminal 1 equipped with a touch screen 2. By executing the game program, the user terminal 1 provides the user with an environment for playing a game corresponding to the game program. The game program is installed in the user terminal 1, for example, via 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 that is pre-installed in advance, thereby enabling the user to play the game. The user can control 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 1 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 has a hardware configuration including 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, all of which are connected to one another via a bus. The main memory 4 is configured, for example, by a dynamic random access memory (DRAM), and the auxiliary memory 5 is configured, for example, by a hard disk drive (HDD). 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. The main memory 4 also temporarily stores data generated while the CPU 3 is operating according to the game program and data used by the CPU 3. 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 user operations on the display unit 7, which is the touch screen 2, to detect 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 input unit 8 in this embodiment correspond to the touch screen 2 described above. 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 receives 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 with 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 may be 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 the 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 fulfills 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 that the user's finger or the like has approached the touch sensing unit 10 as coordinates in a coordinate system consisting of the horizontal and vertical axes of the surface that constitutes the touch screen 2.

[0035] The input operation receiving unit 32 determines a user operation on the touch screen 2. The input operation receiving unit 32 determines, for example, (1) an "approaching operation," (2) a "releasing 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 operations determined by the input operation receiving unit 32 are not limited to those described above. For example, if 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) using the touch sensing unit 10, and outputs a signal corresponding 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."

[0037] (2) A "release operation" is an operation in which the user stops the state in which they are approaching the touch screen 2. For example, when the user releases their 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 it detects the approach of the user's finger or the like to the touch screen 2 to a state in which it no longer detects the approach, it determines that the state has changed from a "touch-on state" to a "touch-off state."

[0038] (3) A "tap operation" is when a user performs an approach operation by bringing a finger or the like close to the touch screen 2, followed by 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 where an approach operation is not detected (a state where 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 stores the detected coordinates as an "initial touch position." When the coordinates of the initial touch position and the coordinates of the release operation are substantially 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, 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") 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.

[0040] (5) A "drag operation" is an operation in which a user brings a finger or the like close to the touch screen 2 and 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 the 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, the 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 their finger has been released from the touch screen 2, and the input operation receiving unit 32 detects that the user's finger has approached the touch sensing unit 10 as an initial touch position, the character operation detection unit 34 detects the moving direction of the player character based on the coordinates of the initial touch position and the detection result of the touch screen 2. 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 a result of the user terminal 1 executing a game program, and various objects (for example, 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 content 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 content 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, the control object 40 is displayed in accordance with the input operation received by the input operation receiving unit 32, and the player character performs a predetermined action (for example, a movement or a jumping 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 input operations for causing a player character 100 (an example of a character object or player character) operated by a user to perform a predetermined action. The control unit 30 displays the player character 100, which is the player character operated by the user, and an opponent character 200, which is the opponent (enemy) character, on the touch screen 2, and accepts input operations from the user for causing the player character 100 to perform a predetermined action. When the user terminal 1 is placed vertically, the player 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 region when the touch screen 2 is divided into thirds in the vertical direction), so that the field of view in the horizontal direction is slightly wider, for example. A cross section of the ground (the dotted pattern part in FIG. 4), for example, 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 a control object 40, which will be described later. The user can operate the player's character 100 by operating 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 edges 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 the process in which the character operation detection unit 34 detects the direction in which the player's character 100 is to move in response to a user's input operation. The character operation detection unit 34 sets the position (initial touch position) where the user presses the touch screen 2 by bringing a finger or the like close to the touch sensing unit 10 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 to move 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] State (A) in Fig. 5 shows a state in which the user's finger has been released from the touch screen 2 and is now approaching 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 is approaching the touch screen 2, and the fact that the user's finger has not been detected 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, for example, as a ring buffer.

[0050] In the example of state (A), the position where the user presses the touch screen 2 is shown as a 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, moving 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 determines that the user's operation on the touch screen 2 is a drag operation by referring to the value held in the buffer memory 53.

[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 of memory areas fp

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

[0053] 5 shows the result of detection by the character operation detection unit 34 of an input operation that specifies the direction in which the user moves the player's character 100 in each of the 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 move.

[0055] In state (C), character operation detection unit 34 detects that the user has performed a drag operation from coordinates 51B (coordinates (x9, y9)) to coordinates 51C (coordinates (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 coordinates 51A and 51C, starting from coordinates 51A of the initial touch position, as the direction in which player character 100 should move.

[0056] 2. Example of your character's movements FIG. 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 contains predetermined actions to be performed 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, the control unit 30 causes the player's character 100 to perform an attack action (for example, swinging the sword it is holding) regardless of the state of the player's character 100 (i.e., whether it is on the ground or not). Example 2: When the user performs a horizontal slide operation (here, the direction along the left-right direction (horizontal direction) of the touch screen 2 is defined as 0 degrees, and the side above the horizontal direction is defined as positive and the side below is defined as 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 has landed 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 between the start point and end point of the drag operation (slide amount) 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 the same upward sliding operation as in Example 3 and the player's character 100 has not yet landed on the ground, the control unit 30 causes the player's character 100 to execute a jumping action after the player's character 100 has landed on the ground. That is, in this case, the player's character 100 repeats the jumping action. 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 called 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 slide operation similar to that in 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 perform 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 called 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 triangle 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 action table 60 and causes the player's character 100 to jump (an example of a first state). When the control unit 30 receives a downward sliding operation (an example of a second input operation) from the user while the player's character 100 is jumping, the control unit 30 refers to the action table 60 and causes the player's character 100 to perform a kabutowari. Furthermore, when a diagonal sliding operation is received, the control unit 30 refers to the action table 60 based on the diagonal upward sliding operation and causes the player's character 100 to jump (a first state) and then move on the ground (an example of a second state). Then, when the control unit 30 receives a predetermined input operation (e.g., a downward sliding operation) while the player's character 100 is jumping or moving on the ground, the control unit 30 refers to the action table 60 and causes the player's character 100 to perform a predetermined action (kabutowari if the player's character is in the jumping state, or crouching if the player's character is in the moving state).

[0059] 3. Basic configuration of operation objects A control object 40 (see FIG. 4 ) according to this embodiment is displayed on the touch screen 2 when a user's approach operation to the touch screen 2 is detected. The control 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 control object 40 has an initial shape when contacted with a finger, formed to have a circular base 42 around a reference position associated with a contact start point, which is the position of contact on the touch screen 2 (e.g., initial touch position coordinates 51A in FIG. 5 ). Note that the reference position does not have to be the coordinates where the finger first touches the touch screen 2, but may be, for example, the coordinates where the finger touched the touch screen 2 several frames after the frame where the finger first touched the touch screen 2. 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 remains in contact with the touch screen 2), the control object 40 undergoes elastic deformation as if being pulled by the user's finger, as shown in FIG. 7B . At this time, the control 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 manner, the control object 40 is formed so as to elastically extend in the direction of the drag operation input from the contact start point toward the contact end point. Furthermore, if the user further moves their finger or the like on the touch screen 2 while maintaining the contact end point, the tip portion 44 also moves further in response, and the extension direction of the control object 40 also changes. When the user's drag operation ends (i.e., when the user's finger is released from the contact end point on the touch screen 2), the elastically deformed control object 40 gradually shrinks toward the contact start point according to its restoring force, and is displayed so as to restore to its initial shape shown in FIG. 7A, and is then hidden after a certain period of time has passed. In FIG. 7A, the base 42 is formed in a circular shape with the contact start 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 control object 40 may be displayed corresponding to a predetermined position (reference position) associated with the contact start point. Also, instead of deforming the control object 40 (base 42) formed at the contact start point in response to a drag operation, another object constituting a part of the control 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 these 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 an input operation by the user via 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 an input operation by the user via the touch screen 2, thereby operating 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 functions as the input operation reception unit 32 shown in FIG. 3, and the operation object drawing PM 84 functions as the object control unit 36 ​​and the display control unit 38. The character control PM 90 functions as the character operation detection unit 34.

[0061] When an input operation (e.g., an approach operation) is performed on the touch screen 2 by a user's finger or the like, the input operation reception PM 82 receives the input operation and stores information related to 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 PM 90 acquires the input operation information from the input operation reception PM 82 (step S2). Then, the character control PM 90 acquires information related to the state of the player's character 100 (e.g., whether the player's character 100 has landed on the ground, whether the player's character 100 is in contact with an obstacle such as a wall, etc.) based on the in-game situation (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), and does not include abnormal states of the character's status (e.g., poison or petrification).

[0062] Next, the character control PM90 controls the player's character 100 by referring to the action table 60 of FIG. 6 based on the input operation information acquired in step S2 and information about 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 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 arrow C) as shown in FIG. 10A based on example 2 of the action table 60 from this 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 player's character 100 has received the attack.

[0063] Next, the operation object drawing PM 84 in the operation object control PM 80 acquires input operation information from the input operation acceptance PM 82 and character state information from the character control PM 90 (step S5). The operation object drawing PM 84 then 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 lateral slide operation is performed as in example 2 of FIG. 6, the operation object drawing PM 84 acquires lateral slide operation information from the input operation acceptance PM 82 and displays the operation object 40 so that it extends from the initial touch position coordinates (contact start point) to the current touch position coordinates (contact end point), i.e., in the direction of arrow C', as shown in FIG. 10(A). At the same time, the operation object drawing PM 84 displays information (e.g., text information) corresponding to the state of the player's 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 PM 90. For example, when the user performs a lateral slide operation in the direction of arrow C with the player's character 100 on the ground, "Run" is displayed within the base 42 of the control object 40 (see FIG. 10A). Note that if the slide amount of the lateral slide operation is equal to or less than a predetermined value, "Walk" may be displayed within the base 42 instead of "Run." Also, when the user performs an upward slide operation or a diagonally 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 arrow D, which is the direction of the drag operation, and the control object 40 is stretched in the direction of arrow D', and "Jump" is displayed within the base 42 of the control object 40. When the processing of step S6 is completed, the process returns to step S1, and the processing 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 be fixed. That is, as shown in FIGS. 10A and 10B, when the text information is written horizontally, the text information is displayed in an orientation that is approximately parallel to the bottom edge of the display unit, regardless of the angle of the tip 44 of the operation object 40 relative to the base 42. For example, even when a drag operation is input downward from the contact start point or when an input operation is input in which 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 an orientation that is easy for the user to view, ensuring good visibility.

[0065] Figure 11 shows examples of game screens when a user tries to have their own character 100 perform a helmet-splitting action, where (A) shows an example of a screen in which the user's own character 100 is jumping, (B) shows an example of a screen when the helmet-splitting input operation is successful, and (C) shows an example of a screen when the helmet-splitting input operation is unsuccessful. As shown in Example 5 of the action table 60 in Fig. 6, 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)). 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 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] If the input operation for the helmet split is successful, i.e., if a downward slide operation is input in the jump state, 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") within the base 42 of the control object 40, as shown in FIG. 11B. On the other hand, if the input operation for the helmet split fails, for example, if the downward angle of the drag operation is insufficient, the control unit 30 does not cause the player's character 100 to execute the helmet split, and displays information about the player's character 100's current state (e.g., "Jump") within the base 42 of the control object 40, as shown in FIG. 11C. In this case, the user can easily recognize that the downward angle of the drag operation was insufficient by looking at the "Jump" display. In this way, by displaying text information within the base 42, the user can be provided with easy-to-understand feedback about the success or failure of an input operation, such as a helmet split, even for an action that requires multiple input operations.

[0067] Figure 12, like Figure 11, shows examples of game screens when the user wants their own character 100 to perform a helmet-splitting action, where (A) shows an example of a screen in which the user's own character 100 is jumping, (B) shows an example of a screen in which the helmet-splitting input operation is successful, and (C) shows an example of a screen in which the helmet-splitting input operation is unsuccessful. As in the case of FIG. 11 , if the input operation for 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 control object 40, as shown in FIG. 12(B). On the other hand, if the input operation for the helmet split is unsuccessful, for example, if 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, the control unit 30 does not cause the player's character 100 to execute the helmet split and displays information about the state of the player's character 100 at that time (e.g., "Run") in the base 42, as shown in FIG. 12(C). In this case, by looking at the display "Run," the user can easily recognize that the input operation 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 perform a predetermined action while displaying the control object 40 on the touch screen 2 from the contact start point to the contact end point based on the user's input operation. The control unit 30 then 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 control object 40 on the touch screen 2. This makes it possible to provide the user with intuitive feedback on the input operation.

[0069] 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 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 small screen such as that of a smartphone.

[0070] In the above embodiment, as shown in Figures 10 to 12, text information relating 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 this is not limiting. As shown in Figure 13, information relating 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 relating to the player's character 100 may be displayed so as to be attached to 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 about 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 better their parameters will be.

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

[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 that the game character has performed in response to input operations by the user and skills that the game character has acquired. The user terminal 1 stores data with the data structure shown in FIG. 15 in the main memory 4 or the like, and progresses through the game while referring to the data as appropriate.

[0076] 15 shows the 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, the parameters of a character named "H") includes an item "grade," an item "item name," an item "basic value," an item "correction value due to equipment," an item "correction value due to skill," and an item "correction value due to title."

[0077] The "grade" item indicates the range of skills that the player's character can acquire. In this embodiment, the grade is set to "2" as an example. The "grade" item is updated when the user fulfills a predetermined condition, such as obtaining a predetermined game content, 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 "HP (hit points)," "Skill Points (SP)," "Attack Value," and "Defense Value." "HP (hit points)" indicates the value of the player's character's stamina. For example, if the "HP" runs out, the game may be over and the game play may end. "Skill Points (SP)" is a parameter 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 (such as a long press operation). "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 "basic value" item indicates the value of the parameter of the player's character 100 itself, without any correction from equipment items, etc. The "correction value due to equipment" 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 "correction value due to skill" item indicates the correction amount of the parameter due to the skill that the player's character 100 has acquired (details of the skill will be described later). The "correction value due to title" item indicates the correction amount according to the title object that the user acquires 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 in the game such as "increasing the upper limit of the stamina value" occur).

[0080] The illustrated example (B) in 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 a 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 "parameter correction content" may, for example, be (i) a correction to the stamina 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 increase the upper limit of the number of consecutive attacks that can be performed (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 (for example, 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, or (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) when the player's character 100 is made to crouch and guard in response to an input operation such as a downward slide, the amount of damage received from an enemy character's attack when guarding is reduced; (viii) when the player's character 100 jumps in response to an input operation such as an upward slide, the distance, speed, etc. of the jump is increased; (ix) when the player's character 100 receives a tap operation, a downward slide operation, etc. while jumping in response to an input operation such as an upward slide and performs an attack operation in the air, the attack power and the number of attacks that can be performed in the air are increased; (x) when the player's character 100 performs a crafting operation to synthesize and strengthen weapons, armor, etc. using material items, the type of items obtained by the crafting and the success rate of item generation are increased;

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

[0086] The "Level" item indicates the degree to which the user has improved the skill indicated in the "Skill Name" item. For example, for the skill "Stamina Up," the parameter correction content can be made better when the skill level is high than when the level is low. This can motivate the user to have the player's character 100 perform the actions indicated in the "Experience Point Acquisition Condition" item in order to level up the skill. As a result, the more the user has the player's character 100 perform the actions shown in FIG. 6, etc., the more the user can update the player's character 100's parameters, which can motivate the user to continue playing the game and become proficient in operating the player's character 100. Furthermore, some of these skills can be acquired by reaching a certain level. In other words, when the level of a first skill reaches a certain level (e.g., reaches the maximum level), the player can acquire a second skill.

[0087] The "Experience Point Acquisition Condition" item indicates the condition for acquiring experience points for the skill indicated in the "Skill Name" item and improving the level. For example, one such condition may involve performing an input operation to have the player's character 100 perform an action as shown in FIG. 6 or the like. In other words, an input operation to have the player's character 100 perform an action causes the player's character 100 to perform the action, thereby acquiring experience points for each skill. This motivates the user to try out various actions shown in FIG. 6 or the like one after another. Some skills, such as the skill named "Stamina Value Increase," allow the player's character 100 to grow in parameters as the player's character 100 receives damage. This can further motivate the user to perform input operations for performing actions (e.g., evasive actions, attack actions, and guard actions) for combating enemy characters, in addition to actions for movement.

[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, as an example, a side-scrolling action game (which may be an MMORPG). The illustrated example (A) shows a situation 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 component 900 on the touch screen 2. The UI component 900 is an icon that accepts 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 slide operation (or a flick 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 or 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, while gazing at the player's character 100 during gameplay, that the player's character 100 has acquired a new skill and that the skill has been improved as a result of the player's character 100 performing an action through the user's input operation. The user terminal 1 stops displaying the UI component 902 when a certain period of time has elapsed since the display of the UI component 902. This allows the user, after recognizing that the player's character 100 has acquired a skill and improved the skill, to once again focus on the player's character 100 and concentrate on having the player's character 100 perform an action.

[0092] The user terminal 1 displays a UI component 901 near a UI component 900 displayed on the touch screen 2. The UI component 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 development. In the illustrated example (B), the UI component 901 indicates the number of skills that the user has not yet confirmed. The user terminal 1 may continue to display the UI component 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 focusing on the player's character 100, fighting an enemy character, and then calmly checking the list of skills. By displaying the UI component 901 while the user is concentrating on the action that the player's character 100 wants to perform, the user can be prevented from missing an opportunity to confirm the development of the player's character 100.

[0093] 17 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 acquired. The user terminal 1, for example, receives a touch operation by the user on the UI component 900, thereby displaying the screen shown in FIG. 17 on the touch screen 2.

[0094] Illustrated example (A) in 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 mastered are displayed on the touch screen 2. As shown in 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 in response to an input operation by the user. In 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 touches 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 any action in response to input operations, (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 or recovery actions that can be activated by consuming skill points on the screen during battle, separate from attack actions such as tap operations.

[0097] Here, (i) skills that the player's character 100 can acquire and develop without performing 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, suppose 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 which 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, by satisfying a predetermined condition for providing an item or the like from the game media, the user is granted the grant item (item, skill, character, in-game virtual currency, etc.) according to the lottery results. Here, the user terminal 1 may grant the game media to the user when the user causes the player's character 100 to perform an attacking action to attack an enemy character and defeat the enemy character, for example.

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

[0099] The user terminal 1 updates the grade of the player's character 100 by satisfying a predetermined condition as the user plays the game. For example, the predetermined condition may be satisfied by the user performing an input operation to have the player's character 100 perform an action. For example, the user terminal 1 grants the user game content 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, such as defeating an enemy character. When the object to be granted to the user from the game content is a character, the user terminal 1 performs a lottery to determine which of multiple characters will be provided to the user. If, as a result of the lottery, a character that the user has not acquired is provided from the game content, the user is allowed to control that character. If a character that the user has already acquired is provided from the game content, the grade of that character is updated. For example, when the user is already able to control a character of grade "1" and that character is provided from the game content, the user terminal 1 updates the grade of that character from grade "1" to grade "2" and expands the range of skills that the character can acquire.

[0100] In this way, by allowing the user to acquire and develop 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. Furthermore, by updating the character's grade by providing characters, etc. 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 of the number of techniques (combo number) that the player's character 100 can consecutively perform during an attack operation is updated as the skill grows, the user can feel the character's growth even more and 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 skills that the user has not yet acquired so that they can be distinguished from 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 or the content of the skill cannot be determined from the icon, thereby motivating the user to acquire these skills.

[0102] The illustrated example (B) shows that the user has acquired or developed skills that have not yet been confirmed by the user. In the illustrated example (B), the user terminal 1 displays a UI component 915 on the touch screen 2 superimposed on the skill icon to notify the user that there are skills that the user has not yet confirmed, but the display manner of the UI component 915 is not limited to this. This encourages the user to operate the UI component 915, thereby increasing the opportunities for the user to further realize the growth of their own 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 behavior of the player's character 100, and notifies the user that the skill has been acquired or developed. The user terminal 1 operates according to a program to execute the following steps.

[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 conditions" in the illustrated example (B) of FIG.

[0105] For example, the event includes an event in which, in response to a user's input operation on the touch screen 2 to cause the player's character 100 to perform an action, the content of the action to be performed by the player's character 100 is determined, and the CPU 2 issues an instruction to move the player's character 100 in accordance with 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 when the player's character 100 is positioned within the range of an attack motion performed by an enemy character or when the player's character 100 collides 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, or recovers a character other than the player's character 100, as a result of the player's character 100 performing an action.

[0106] In step S1803, 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 cause the player's character 100 to act in response to an input operation, 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 determination made 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 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 component 901 in example (B) of Fig. 16.

[0109] 19 is a flowchart showing a process in which the user terminal 1 displays a screen listing the 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, the CPU 3 identifies skills that the user has newly acquired or developed that have not yet 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 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 skills displayed by the UI component 915 in the illustrated example (B) of Fig. 17 indicate skills that have not yet been confirmed by the user as newly acquired skills or skills that have been developed.

[0114] [Description of the second embodiment of the present disclosure] A second embodiment of the present disclosure will be described below with reference to the drawings. For the sake of convenience, the description of components having the same reference numbers as those already described in the description of this embodiment will not be repeated. In the second embodiment, the description will mainly focus on the operation for switching characters in a game in which a user organizes multiple characters and progresses by switching between the characters to be controlled during gameplay.

[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 the display processing of a user interface image for the user to change the player character in the second embodiment.

[0117] In step S11 of FIG. 20, the control unit 30 determines whether a user's finger or the like has approached the touch screen 2 (whether an approaching 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 determined that an approaching operation has been input (Yes in step S11), the control unit 30 detects the position of the contact end point in step S12. Then, in step S13, the control unit 30 determines whether the contact end point is included in a certain area including the position where the approaching operation was detected (contact start point). If it is determined that the contact end point is not included in the certain area including the approach start point, that is, if it is determined that the contact start point and the contact end point are separated by a certain distance or more (No in step S13), the control unit 30 determines in step S14 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 defined by the contact start point and the contact end point (see (D) of FIG. 5). 7 around the contact start point, and elastically deforms the control object 40 based on the contact end point. Then, 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), then in step S16, the control unit 30 determines whether the duration of the approach operation has exceeded a certain period of time. That is, here, the control unit 30 determines whether 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), then 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 thereon. That is, the base portion 62 may be configured as a reference for determining the relative positions 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 a character 120 that can be changed from the player's character 100 by user selection. The third icon 64C corresponds to a character 130 that can be changed from 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 a 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 explained in the example of Fig. 15. As such, 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 (e.g., "In Use") indicating the character currently being used (player's character 100). The first icon 64A is an icon corresponding to the player's character 100 currently displayed on the touch screen 2, and therefore is preferably displayed in an unselectable state. In other words, 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 (e.g., the faces of the characters 120 and 130) of the player's 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 from the base portion 62 at a predetermined distance to the left of the contact start point (i.e., the base portion 62) where the long press operation was performed. The first operation key 64 (icons 64A to 64C) and the second operation key 66 have a fixed positional relationship with respect to the base portion 62, which is the position where the operation input was made. For example, in the left region of the base portion 62, the second operation key 66, the first icon 64A, the second icon 64B, and the third icon 64C are arranged from top to bottom in this order so as to be asymmetrical with respect to the left-right direction of the touch screen 2.

[0123] In the example shown in FIG. 21 , it is assumed that the user operates the touch screen 2 with the fingers of his right hand, and the first operation key 64 and the second operation key 66 are arranged in the left region of the base unit 62 to facilitate operation with the fingers of the right hand. However, this is not limiting. For example, when operating with the fingers of the left hand, these operation keys may be arranged in the right region of the base unit 62 by a user's selection operation. In this case, the relative arrangement of the operation keys 64, 66 is fixed. That is, the arrangement of the first operation key 64 (each of the icons 64A to 64C) and the second operation key 66 may be switched symmetrically between when the user operates the touch screen 2 with his right hand and when the user operates the touch screen 2 with his left hand. In this way, by switching the arrangement of the operation keys 64, 66 symmetrically with respect to the base unit 62 depending on whether the user operates the touch screen 2 with his right hand or his left hand, operability can be further improved.

[0124] Subsequently, in step S18, the control unit 30 determines whether or not a release operation has been input. If it is determined that a release operation has been input (Yes in step S18), then in step S19, the control unit 30 determines 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 determined that the touch-off position is not included in the area of ​​each operation key 64, 56 (No in step S19), then in step S20, the control unit 30 determines 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. Thereafter, the process returns to step S11, and the process is repeated.

[0125] On the other hand, if 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 the operation corresponding to the selected operation key. For example, as shown in (A) of Fig. 22, if it is determined that a release operation has been 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 (B) of Fig. 22. Thereafter, 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 a long press operation is input after the character displayed on the touch screen 2 has been changed from the player's character 100 to another character 130. 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] (A) and (B) of FIG. 24 show an example of a screen when a slide (drag) operation is input in a predetermined direction after a long press operation has been input (a state in which the UI image 60 is displayed). In step S17, when a drag operation is input with the UI image 60 displayed by a long press operation, the control unit 30 determines whether the drag operation from the contact start point to the contact end point is moving at a certain speed or less. The speed of the drag operation can be detected, for example, based on the slide distance 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 equal to or less than a predetermined threshold, the control unit 30 moves the UI image 60 in accordance with the drag operation and controls the character 100 in accordance with the drag operation (moving, jumping, etc.). For example, as shown in FIG. 24A, when the user performs a drag operation in the direction of arrow A while the UI image 60 is displayed by a long press operation, the control unit 30 causes the player's character 100 to perform 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, if the drag direction is diagonally upward, the control object 40 is elastically deformed and displayed based on the drag direction, and the character 100 jumps, as shown in FIG. 24B. 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 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 operation key 64, 66 to be selected. That is, in this case, the user can select each operation key 64, 66 by performing a release operation on each operation key 64, 66. In this way, by switching between operating the player's character 100 and operating each operation key 64, 66 depending on the speed of the drag operation, the degree of freedom in operability can be improved.

[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 when the user selects and operates the first operation key 64, the player's character 100 displayed on the touch screen 2 is changed 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 within the space displayed on the touch screen 2 under normal circumstances.

[0132] Furthermore, since the UI image 60 displays the icons 64A to 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 to 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 to automatically switch the characters that appear on the game field and are controlled by the user, without the user having to perform any switching operations.

[0134] As described above, the user can change the character to be operated by performing input operations on 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 characters to be displayed on the touch screen 2 in accordance with input operations 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.) by the user to change the character to be operated. Specifically, 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, without relying on an input operation by the user to change the character.

[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, although a large number of enemy characters may be displayed on the touch screen 2, the user terminal 1 may set the enemy character to be compared with the parameters of each character to be the character that the character to be operated by the user has locked on to perform an attack action. In the locked-on state, 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 the attack action toward the enemy character 200, regardless of whether the character 100 is facing 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 to as the 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) based on parameters related to attacks of each character included in the 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, the character that has the best damage efficiency against the enemy character 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 in response to input operations by the user. When specifying a character to fight an enemy character based on attack-related parameters, the user terminal 1 can also refer to the correction details of each parameter of the characters organized into a party by the user, and specify the character that can inflict the greatest amount of damage on the enemy character per unit time based on the level of attack power, number of combos, etc., as the character to be displayed on the touch screen 2.

[0139] Furthermore, (ii) the user terminal 1 may 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, from 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, as a character to be displayed on the touch screen 2, a character that is likely to successfully attack the character to be attacked, based on parameters of the movement speed of the character to be attacked and parameters related to the movement of each character organized by the user in a party (such as movement speed, speed of evasion, distance of evasion, speed of jump, and distance of jump). For example, if the enemy character has a fast movement speed, and 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 keep up with the movement of the enemy character may be more likely to land an attack. The user terminal 1 compares the parameters related to the movement of the enemy character with parameters related to the movement of each character organized in a party, and specifies, for example, a character whose movement speed is equal to or faster than the enemy character, as a character to be displayed on the touch screen 2.

[0141] 25 is a diagram showing the data structure of character management information for managing characters that can be operated by a user in a game program and characters that the user can operate. The user terminal 1 stores data with the data structure shown in FIG. 25 in the main memory 4 or the like, and progresses the game while referring to the data as appropriate.

[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 availability," 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 controlled in the game program.

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

[0145] The "Character Attributes" field indicates the attributes assigned to each character. Here, the attributes assigned to a character include the types of equipment items that the character can equip. Equipment items include the types of weapons, armor, and accessories that can be associated with the character. The attributes assigned to each character include parameters that are set separately from the weapon type and are referenced during attack and defense. For example, there are cases where compatibility is set for each type, such as a rock-paper-scissors system. In the example of Figure 25, for example, compatibility is set such that the type "Water" is strong against the type "Fire," which is strong against the type "Earth," and which is strong against the type "Water." Based on this compatibility, the amount of damage in battles between characters may be adjusted. Furthermore, for example, some characters may be assigned attributes that are weaknesses or that can nullify attacks. For example, a flying character is nullified (i.e., does not receive damage) by attacks of the type "Earth," but is weak to attacks of the type "Wind," increasing the amount of damage when attacked.

[0146] In the first mode, when user terminal 1 identifies 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, 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, user terminal 1 can identify the character that inflicts the most damage to an enemy character per unit time, based on the attack value determined by each character's basic value, equipment correction value, and skill correction value, the maximum combo number when each character attacks, the attributes of each character, and the attributes of the enemy character, among the characters organized into a party.

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

[0148] The item "Party composition" indicates whether or not a character is incorporated as a character to be organized into a party when the user plays the game. For example, when a game can be progressed in a group of three people, the user terminal 1 accepts from the user the designation of at least one and up to three characters to be included in the 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 explained 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 a user interface image for receiving a change operation from the user to select a first mode in which auto-change is possible or to switch from the first mode to a 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 indicates that the user has enabled the first mode by displaying "Auto Character Change: ON," and also indicates that the first mode can be switched to the second mode by performing a drag operation or the like on the UI image 64E. As shown in the illustrated example (A), it is desirable to prevent erroneous input by the user by displaying the UI image 64E indicating whether to enable auto-change in a different position from the UI image 64 for the user to switch the character to be controlled and the UI image for activating a skill on the character to be controlled. As shown in the illustrated example (A), a UI image for activating a skill on the character being controlled, a UI image 64 for switching the character being controlled, 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 examples (B) and (C) show a situation in which, with auto-character change enabled, the parameters of each character operated by the user are compared with the enemy character 200, and the character operated by the user is changed from character 130 to character 100. In illustrated example (B), character 130 and enemy character 200 are within a certain distance from each other, so character 130 is locked on to enemy character 200. In this state, user terminal 1 receives a tap operation on the touch screen and displays a UI component 260 indicating that the tap operation has been performed. In response to the tap operation, an event for causing character 130 to perform an attack action is generated. The user terminal 1 compares the parameters of each character organized into the party with the parameters of enemy character 200, and displays the parameters on the touch screen 2 to identify the character to be operated by the user. In the example illustrated in (B), character 100 is identified as the character to be used in battle with enemy character 200, instead of character 130. As a result, the user terminal 1 transitions the screen from the state shown in the illustrated example (B) to the state shown in the illustrated example (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 off-screen, and character 100 as if it is moving from off-screen into the screen accompanied by an attack determination. As a result, character 100, which appears on the touch screen 2 as a result of the character change, attacks enemy character 200 while switching places 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, to make the user aware that the character to be operated by the user has changed. This makes it easier for the user to recognize that the character has been changed by auto-change, regardless of whether the user has performed an operation to change the character, and makes it easier for the user to concentrate on the actions 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 for identifying characters that will fight enemy characters among characters organized into a party in the auto-change application mode, and displaying the characters according to the identification results on the touch screen 2. The user terminal 1 operates according to a program to execute the following steps.

[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 will cause an attack action to occur. 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 since the action corresponding to the tap operation is an attack action (the example of FIG. 6), the CPU 3 causes an event for causing the character 100 to cause an attack action to occur.

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

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

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

[0160] Here, in the description of the first embodiment, it was written that "Here, (i) skills that the player's character 100 can acquire and develop without taking an action in response to an input operation include, for example, skills that the player's character 100 can use when the player acquires game media as the user plays the game. For example, suppose that the user obtains game media in 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 this 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, by satisfying predetermined conditions for providing an item, etc. from the game media, the user is granted the grant object (item, skill, character, in-game virtual currency, etc.) in accordance with the lottery results. 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, etc."

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

[0162] Specifically, when a user forms a party and acquires game media by battling enemy characters in the game field, game device 1 may limit the items awarded by lottery from the game media to those related to characters included in the party, or may increase the rate at which items related to characters included in the party are awarded compared to the rate at which items related to characters not included in the party are awarded. Even if a user acquires an item, skill, or the like that strengthens a character not included in the party, it does not strengthen the character actually included in the party. However, by configuring as described above, it is possible to reduce the occurrence of situations in which the user is deprived of opportunities to gain an advantage in game progression by strengthening their character or to experience the character's growth, thereby reducing interest. For example, when equipment items and material items that are materials for equipment items are awarded from the game media, priority may be given to items that can be equipped by characters included in the party.

[0163] Furthermore, when a character is provided from the game medium, as described in the first embodiment, if a character that the user has already acquired is provided, the grade of that character is updated, and if a character that the user has not acquired is provided, the user can make it a new character to operate, 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 example of the second embodiment described above, the following configuration may be adopted. That is, even if auto-character change is enabled, character change without user input operations for changing characters may not be performed under certain conditions. For example, even if the character identified in step S2703 of FIG. 27 is a character suitable for maximizing the amount of damage to an enemy character, if the character's stamina is low, there may be situations in which the character is likely to be attacked and unable to continue the battle. Furthermore, if a character is running low on skill points, the number of times it can perform powerful attacks by activating skills is limited.

[0165] Therefore, in step S2703, the characters that will fight the enemy character may be identified based on the remaining stamina and skill points of the characters to be organized into the party. For example, in 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 stamina of the character is less than a certain level, the next-ranked character is given priority. If the remaining stamina of the character is more than a certain level, the character in question is identified as the character to be operated by the user.

[0166] (Additional Note 1) The following additional notes are provided regarding the above-described embodiment. (Supplementary 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 user input operations. The game program causes the processor to execute the following steps: storing in memory, for each of a plurality of correction details (the value of experience points required for leveling up in the item "Experience points" in the example (B) of FIG. 15) for applying the correction details (the item "Parameter correction details" in the example (B) of FIG. 15) to correct the character parameters of the game character operated by the user, to the game character; a comparison parameter indicating the status of achievement of the condition (a value that increases when the condition indicated in the item "Experience points acquisition conditions" in the item "Experience points" in the example (B) of FIG. 15 is satisfied); identifying 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 (step S1803 of FIG. 6); updating the comparison parameter for the correction details 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 detail achieves the condition, applying the correction details corresponding to the condition to the game character, thereby correcting the character parameters of the game character to provide 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 is set among multiple correction contents (first skill group 912 and second skill group 913 shown in the 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 where 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 made to execute a step of granting the user, as the user plays the game, a game medium representing the right for the user to acquire an object that can be used 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 while 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 correction of character parameters that allow a game character to affect other game characters (in the illustrated example (B) of Figure 15, the "Critical Rate Up" item in the "Skill Name" category and the "Parameter Correction Content" item corresponding to "Weapon Type Proficiency" etc.).

[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 (e.g., in the illustrated example (B) of Figure 15, "Maximum combo number +2" in the item "Parameter correction content" corresponding to "Weapon type proficiency" in the item "Skill name").

[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 the game character is affected by another game character (e.g., in the illustrated example (B) of Figure 15, the item "Content of parameter correction" corresponding to "Damage reduction when guarding" in the item "Skill name").

[0172] (Appendix 7) In any of (Appendix 1) to (Appendix 6), in the specifying step, the event that occurs includes having a game character perform an action through a user's input operation, and specifying the content of the event includes specifying the content of the action to be performed by the game character (e.g., step S1803, "Deal damage to other characters by attacking" in the item "Experience point acquisition condition" in the illustrated example (B) of Figure 6 and 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, Figure 15, example (B) in the item "Conditions for acquiring experience points" in "Character receives damage").

[0174] (Appendix 9) In any of (Appendix 1) to (Appendix 8), when the comparison parameters for each correction content satisfy the conditions, a step of notifying the user via the display unit that there is a correction content that satisfies the conditions is further executed (UI component 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) that transitions to a list screen (FIG. 17) including a list of correction contents that can be applied to the game character and a list of correction contents that 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 that allows the user to distinguish between correction contents for which the user has not yet confirmed that the conditions have been met (UI component 915) and correction contents for which the conditions have been confirmed.

[0176] [Embodiment 3] Next, we will explain how, in the configuration of the above embodiment, each character is associated with an attribute called a job (occupation). In this embodiment, the job of each character is provided by a lottery process. When a job is assigned to a character (for example, character "XXX" can be changed from an attribute of "none" (no particular job assigned) to an attribute such as "magic swordsman"). At this time, even if character "XXX" was originally unable to equip equipment, equipment related to the job becomes available. For example, even if character "XXX" was originally able to equip the weapon "spear" but not other types of weapons, if character "XXX" acquires the job "magic swordsman," he or she will be able to equip the weapon "sword." This allows for a greater variety in not only job skills but also equipable weapons.

[0177] FIG. 28 is a table showing game media dispensed by the lottery process. As shown in FIG. 28, the table associates the name of the game media to be dispensed, the type of game media, the rarity of the game media, and the dispense probability of the game media. As shown in the example of FIG. 28, the game program dispenses, as dispensed objects, a "job" that 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 character "XXX" is dispensed, and the rarity of the game media is set to "4." The table shown in FIG. 28 is stored on a user's terminal or a server.

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

[0179] As shown in example (A), touch screen 2 of the user's terminal displays icons (icons 2903, 2904, 2905, 2906) for starting the lottery process, and image display sections 2901 and 2902 for presenting the user with examples of game media provided by the lottery process. When a character's job is provided 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 a character's job is provided by lottery, the game program displays, for example, (i) the name of the job, (ii) the type of equipment that can be used for that job, and (iii) special character actions (special skills) that can be used for that 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] 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 number of times (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), the results of the lottery process for the 11th floor are displayed in response to an operation on icon 2904.

[0184] In example (B), the job of character "XXX" is assigned to the user through a lottery process (game medium 2910-1). Furthermore, game medium 2910-6 indicates that if a job of a character previously acquired by the user is assigned to the user through this lottery process, a job enhancement item that can be used to enhance any character's job has been assigned to the user instead of that 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, each character can be assigned a job. Touch screen 2 displays a list of skills that can be activated by a certain character's job, "Magic Swordsman." On touch screen 2, a grade 1 special skill for the job "Magic Swordsman" is displayed in skill display area 3012. On touch screen 2, a grade 2 special skill for the job "Magic Swordsman" is displayed in skill display area 3013.

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

[0188] Fig. 31 is a flowchart shown in this embodiment. The process shown in Fig. 31 is executed, for example, on either the user's terminal or the server, or the server executes the lottery process in response to a process for executing the lottery on the user's terminal, and displays 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 device identifies the game content to be donated by lottery, with reference to the table shown in Fig. 28. When the user's device identifies that the attributes of a character are to be donated as the object to be donated, if the attributes overlap with a job of a character already acquired by the user, the user's device determines to provide the user with an item to strengthen the job.

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

[0192] As described above, the game program of this embodiment causes a computer to store in memory, for one or more characters operated by a user, information indicating attributes (jobs) that can be associated with the characters. 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 to update parameters related to the attribute (job) (for example, granting a job enhancement item to the user).

[0193] The game program further causes the computer processor to execute the steps of moving the character in response to a user's input operation on the operation unit (touch screen 2) and updating a first parameter (HP, SP, etc. in the above embodiment) indicating the character's performance based on the character's movement. The game program updates the first parameter by moving the character (HP increases, skills are developed), while also performing processing to update parameters related to the attribute (job) regardless of the character's movement history (for example, granting a job enhancement item 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 (by accepting the user's operation for selecting a job to be set for the character). When the character's attribute (job) is changed by designating the attribute (job), the game program applies the first parameter (HP, SP, etc.) to any attribute (job).

[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 by consuming the first item (job enhancement item) (increasing the grade of the job and widening the range of special skills that can be acquired according to the job).

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

[0197] The above-described embodiments are merely examples for facilitating understanding of the present invention, and are not intended to limit the present invention. The present invention can be modified and improved without departing from the spirit thereof, 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: Transmitter / receiver, 7: Display, 8: Input unit, 10: Touch sensing unit, 20: Display, 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, 44: Tip, 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 lottery means for performing a lottery process in which attributes that can be associated with one or more characters to be operated are provided as the objects of the lottery; a storage means for storing information indicating the attribute provided in accordance with the result of the lottery process in a memory; The program functions as an update means that can execute a process to update the parameters related to the provided attribute itself so as to grow, by providing again an attribute that has already been provided in accordance with the result of the lottery process that has already been carried out and can be associated with the character, in accordance with the result of the lottery process that is newly carried out.

2. a lottery means for performing a lottery process in which attributes that can be associated with one or more characters to be operated are provided as the objects of the lottery; a storage means for storing information indicating the attribute provided in accordance with the result of the lottery process in a memory; The system is provided with an update means that enables execution of a process for updating an attribute that has already been provided in accordance with the result of the lottery process that has already been carried out and that can be associated with the character, by providing the attribute again in accordance with the result of a new lottery process, so as to grow parameters related to the provided attribute itself.

Images