Game device and game device program

Abstract

To prevent variation of a character state from becoming monotonous.SOLUTION: A program of a game device 10 including a processor 1000 allows the processor 1000 to function as an operation execution part 112 for operating a character C of a game according to user's operation, and a state management part 113 for managing a state of the character C. The state management part 113 increases a parameter value for indicating satisfactoriness of the state of the character C at a lapse of time with a first upper-limit value as a limit, and decreases the first upper-limit value at a lapse of time.SELECTED DRAWING: Figure 16

Description

[Technical field]

[0001] The present invention relates to a game device and a program for the game device. [Background technology]

[0002] Conventionally, a technique for managing the state of a character operated by a user in a game has been known. For example, Patent Document 1 exemplifies a technique for managing the physical strength of a character as an example of the state of the character. Specifically, Patent Document 1 exemplifies a technique for managing the state of a character by decreasing a physical strength value indicating the physical strength of the character when the character operated by the user is damaged by an attack from an enemy, and recovering the physical strength value of the character up to a predetermined upper limit when the character performs a predetermined recovery action. [Prior art documents] [Patent documents]

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

[0004] However, in conventional techniques, parameter values ​​such as stamina values ​​indicating the state of a character were changed only under specific circumstances, such as an attack from an enemy against a character operated by a user, execution of a predetermined recovery action by the character, etc. For this reason, in conventional techniques, it was not possible to change the state of a character over time, for example, and the change in the state of the character tended to be monotonous.

[0005] The present invention has been made in consideration of the above-mentioned circumstances, and one of the problems to be solved is to provide a technique that makes it possible to prevent fluctuations in a character's state from becoming monotonous. [Means for solving the problem]

[0006] In order to solve the above problems, a program for a game device according to one embodiment of the present invention is a program for a game device having a processor, the program causing the processor to function as an operation execution unit that causes a game character to operate in response to a user's operation, and a management unit that manages the state of the character, the management unit increasing a parameter value indicating the goodness of the character's state over time up to a first upper limit value, and decreasing the first upper limit value over time. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is an explanatory diagram showing an overview of a game system 1 according to an embodiment of the present invention. [Diagram 2] 1 is a block diagram showing an example of a configuration of a game device 10. FIG. [Diagram 3] FIG. 2 is a diagram illustrating an example of a hardware configuration of a game device 10. [Figure 4] FIG. 2 is an explanatory diagram showing an example of a virtual field screen G1. [Diagram 5] FIG. 13 is an explanatory diagram showing an example of a status confirmation screen G2. [Figure 6] 13 is an explanatory diagram showing an example of an item confirmation screen G3. FIG. [Figure 7] 4 is a flowchart showing an example of the operation of the game device 10. [Figure 8] FIG. 2 is a diagram showing an example of the data configuration of character information Info. [Figure 9] 13 is a flowchart showing an example of a character action process. [Figure 10] 13 is a diagram showing an example of a data configuration of an operation information table TBL1. FIG. [Figure 11] 13 is a diagram showing an example of a data configuration of an item information table TBL2. FIG. [Figure 12] 13 is a diagram showing an example of a data configuration of a possessed item management table TBL3. FIG. [Figure 13]13 is a flowchart illustrating an example of an event process. [Figure 14] FIG. 13 is a diagram showing an example of a data configuration of an abnormal state information table TBL4. [Figure 15] FIG. 13 is a diagram showing an example of a data configuration of an abnormal state management table TBL5. [Figure 16] 13 is a flowchart illustrating an example of a hit point update process. [Figure 17] 13 is a flowchart showing an example of a stamina value update process. [Figure 18] FIG. 11 is an explanatory diagram showing an example of a change in a hit point image PH. [Figure 19] 13 is an explanatory diagram showing an example of a change in a stamina image PS. FIG. [Figure 20] FIG. 11 is an explanatory diagram showing an example of a change in a hit point image PH according to Modification 1 of the present invention. [Figure 21] FIG. 13 is an explanatory diagram showing an example of a change in a hit point image PH according to Modification 3 of the present invention. [Figure 22] FIG. 13 is an explanatory diagram showing an example of a change in a hit point image PH according to Modification 3 of the present invention. [Figure 23] FIG. 13 is an explanatory diagram showing an overview of a game system 1A according to a seventh modified example of the present invention. [Figure 24] FIG. 13 is a block diagram showing an example of a configuration of a server device 50A according to a seventh modified example of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] Hereinafter, the embodiments of the present invention will be described with reference to the drawings. In each drawing, the dimensions and scale of each part are appropriately different from the actual ones. In addition, the embodiments described below are preferred examples of the present invention, and therefore various technically preferable limitations are attached, but the scope of the present invention is not limited to these embodiments unless otherwise specified in the following description to the effect that the present invention is limited.

[0009] [A. Embodiment] Hereinafter, an embodiment of the present invention will be described.

[0010] [1. Game System Overview] 1 is an explanatory diagram for explaining an overview of a game system 1 according to this embodiment. The overview of the game system 1 will be described below with reference to FIG.

[0011] As illustrated in FIG. 1, the game system 1 includes a plurality of game devices 10 capable of executing a predetermined game, a plurality of display devices 30 provided corresponding to the plurality of game devices 10, and a server device 50. In this embodiment, it is assumed that the game device 10 is a home game device as an example. However, any information processing device can be used as the game device 10. For example, the game device 10 may be a commercial game device installed in a store or amusement facility, a mobile device such as a mobile phone or a smartphone, or a terminal-type information device such as a personal computer.

[0012] The game device 10 is capable of communicating with a display device 30 provided corresponding to the game device 10. The game device 10 can display images relating to a predetermined game being executed on the game device 10 on a display unit 31 provided in the display device 30 provided corresponding to the game device 10.

[0013] Furthermore, the game device 10 is capable of communicating with a server device 50 via the network NW. In this embodiment, it is assumed, as an example, that the predetermined game executed on the game device 10 is a so-called online game. Specifically, the server device 50 transmits information about the predetermined game executed on one of the multiple game devices 10 owned by the game system 1 to the other game devices 10. In this way, the server device 50 can share information about the predetermined game executed on each game device 10 among the multiple game devices 10 owned by the game system 1. That is, in this embodiment, a user of one game device 10 and a user of another game device 10 can cooperate with each other to complete a mission in the predetermined game, or can compete against each other in the predetermined game.

[0014] In this embodiment, a case will be described in which the predetermined game executed on the game device 10 is an online game, but the present invention is not limited to this aspect, and the game device 10 may execute the predetermined game without communicating with the server device 50. In other words, the user of each game device 10 may be able to play the predetermined game independently.

[0015] [2. Configuration of the game device] The configuration of the game device 10 will be described below with reference to FIGS.

[0016] FIG. 2 is a functional block diagram showing an example of the configuration of the game device 10. As shown in FIG. As shown in FIG. 2, the game device 10 includes a control unit 110 that controls each unit of the game device 10, a memory unit 120 that stores various information, a communication unit 130 for performing communication between external devices such as the display device 30 and the server device 50, an operation unit 140 for accepting operations by a user of the game device 10, and an information reading unit 150 for reading information from a recording medium such as an optical disc.

[0017] The control unit 110 includes a game control unit 111 , an action execution unit 112 , a state management unit 113 , an operation information acquisition unit 114 , and a display control unit 115 . The game control unit 111 controls the progress of a predetermined game executed in the game device 10 . The action execution unit 112 causes a character operated by the user of the game device 10 to act in a predetermined game. Hereinafter, the character operated by the user of the game device 10 is referred to as "character C." In other words, the character C is an object in the game that is the target of operation by the user of the game device 10. However, the character C may be any object in the game that is used by the user of the game device 10 to progress in the game, and may be, for example, an object that acts autonomously based on a policy specified by the operation of the user of the game device 10. When the user of the game device 10 operates the operation unit 140, the operation information acquisition unit 114 acquires the details of the operation. The display control unit 115 controls the display unit 31 so that information related to a predetermined game executed on the game device 10 is displayed on the display unit 31 .

[0018] The state management unit 113 manages the state of the character C in a given game. Here, the state of character C refers to, for example, one or both of a state regarding the possibility of continuing the game by character C and a state regarding restrictions on the actions of character C in a given game. Among these, the "state regarding the possibility of continuing the game by character C" refers to the state of character C with respect to the possibility of continuing to play a predetermined game by operating character C. In other words, the "state regarding the possibility of continuing the game by character C" refers to the state of character C with respect to the possibility of not ending the game by operating character C to play a predetermined game. For example, the "state regarding the possibility of continuing the game by character C" refers to the physical state of character C, or the mental state of character C, etc. Moreover, the "state regarding restrictions on the movement of character C" refers to the state of character C with respect to the possibility that character C will not be unable to move and that restrictions will not be imposed on the movement of character C in a specific game. In other words, the "state regarding restrictions on the movement of character C" refers to the state of character C with respect to the degree of freedom of movement of character C when a user of the game device 10 moves character C in a specific game. For example, the "state regarding restrictions on the movement of character C" refers to the stamina of character C, or the fatigue state of character C, etc.

[0019] In this embodiment, the state management unit 113 manages, as the state of character C, both a state related to the possibility of continuing the game by character C and a state related to restrictions on the actions of character C. In this embodiment, the physical strength state of the character C is exemplified as the "state regarding the possibility of continuing the game by the character C". That is, in this embodiment, as an example, when the character C has a sufficient physical strength, the possibility of the game being over in a predetermined game is low, and when the character C has no physical strength, the predetermined game is over. In this embodiment, the stamina of character C is exemplified as the "state related to the restriction on the movement of character C" for explanation. That is, in this embodiment, as an example, when character C has a sufficient amount of stamina, the restriction on the movement of character C in a predetermined game is small, and when character C runs out of stamina, character C becomes unable to move in the predetermined game.

[0020] In addition, in this embodiment, it is assumed that there are cases where the manner of change in the state of character C is normal and cases where the manner of change in the state of character C is abnormal. Here, "the manner in which the condition of character C changes is normal" means that the condition of character C is expected to improve over time. More specifically, "the manner in which the condition of character C changes is normal" means, for example, that character C is healthy. In this embodiment, "character C is in a healthy state" is a concept that includes cases where the injury sustained by character C is minor and where the illness suffered by character C is minor. Furthermore, "the manner in which the condition of character C changes is abnormal" means that the condition of character C is less likely to improve over time compared to when character C is healthy. More specifically, "the manner in which the condition of character C changes is abnormal" means, for example, when character C is seriously injured or when character C is seriously ill. Hereinafter, a normal manner in which the state of character C changes may be referred to as a "normal state," and an abnormal manner in which the state of character C changes may be referred to as an "abnormal state."

[0021] As illustrated in FIG. 2, the memory unit 120 stores an action information table TBL1, an item information table TBL2, a possessed item management table TBL3, an abnormal state information table TBL4, an abnormal state management table TBL5, character information Info, and a control program PRG for the game device 10.

[0022] Although details will be described later, the action information table TBL1 stores action information which is information related to actions that the character C can execute in a given game. The item information table TBL2 stores item information that is information related to items that can be used by the user of the game device 10 in a given game. The possessed item management table TBL3 stores possessed item information, which is information related to items possessed by the character C in a predetermined game. The abnormal state information table TBL4 stores abnormal state information which is information related to abnormal states into which the character C may fall in a predetermined game. The abnormal state management table TBL5 stores abnormal state management information, which is information related to the abnormal state in which the character C is currently caught.

[0023] The character information Info is information relating to the character C related to the operation of the user of the game device 10. The control program PRG is a program that controls the game device 10. In this embodiment, the control program PRG includes, for example, an operation system program for controlling each unit of the game device 10, and an application program (game program) for the game device 10 to execute a predetermined game. Among these, the application program may be read from the information reading unit 150 and stored in the storage unit 120 when, for example, a user of the game device 10 starts a predetermined game.

[0024] FIG. 3 is a diagram showing an example of a hardware configuration of the game device 10. As shown in FIG.

[0025] As shown in FIG. 3, the game device 10 includes a processor 1000 that controls each part of the game device 10, a memory 1001 that stores various information, a communication device 1002 for communicating with an external device outside the game device 10, an input operation device 1003 for accepting operations by a user of the game device 10, and a disk device 1004 for reading information from a recording medium.

[0026] The memory 1001 includes, for example, a volatile memory such as a RAM (Random Access Memory) that functions as a working area for the processor 1000, and a non-volatile memory such as an EEPROM (Electrically Erasable Programmable Read-Only Memory) that stores various information such as the control program PRG of the game device 10, and provides the function of the memory unit 120. The processor 1000 is, for example, a CPU (Central Processing Unit), and functions as a control unit 110 by executing a control program PRG stored in a memory 1001 and operating in accordance with the control program PRG. The communication device 1002 is hardware for communicating with an external device that exists outside the game device 10 via one or both of a wired network and a wireless network, and provides the function of the communication unit 130. The input operation device 1003 is, for example, an operation button, and provides a function as the operation unit 140 that accepts operations by the user of the game device 10. The disk device 1004 is, for example, an optical disk device, and provides a function as an information reading unit 150 that reads various information such as a control program PRG recorded on a recording medium such as an optical disk.

[0027] The processor 1000 may be configured to include hardware such as a DSP (Digital Signal Processor) or an FPGA (Field Programmable Gate Array) in addition to or instead of the CPU. In this case, a part or all of the control unit 110 realized by the processor 1000 may be realized by hardware such as a DSP.

[0028] [3. Game Overview] An overview of a predetermined game executed on the game device 10 according to this embodiment will be described with reference to FIGS.

[0029] In this embodiment, a specified game executed on the game device 10 is, for example, a game in which a user of the game device 10 aims to achieve a specified goal set in the specified game by moving a character C within a virtual field Fd. In this embodiment, the "predetermined goal" refers to, for example, defeating a predetermined enemy character CE in a predetermined game, acquiring a predetermined item in a predetermined game, rescuing a predetermined ally character CB in a predetermined game, the play time of a predetermined game by the user of the game device 10 reaching a predetermined time, or the points (e.g., experience points) acquired by the user of the game device 10 in a predetermined game reaching a predetermined value, etc. In other words, the user of the game device 10 aims to achieve the predetermined goal set in the predetermined game by moving the character C in a virtual field Fd related to the predetermined game.

[0030] In this embodiment, when playing a predetermined game, the user of the game device 10 can operate the operation unit 140 to display the virtual field screen G1, the status check screen G2, and the item check screen G3 on the display unit 31. In other words, the display control unit 115 controls the display unit 31 so that the virtual field screen G1, the status check screen G2, or the item check screen G3 is displayed on the display unit 31 according to the user's operation content acquired by the operation information acquisition unit 114. Then, the user of the game device 10 plays the predetermined game while referring to the virtual field screen G1, the status check screen G2, and the item check screen G3.

[0031] Fig. 4 is a diagram showing an example of the virtual field screen G1. As shown in Fig. 4, the virtual field screen G1 is a screen on which a character image Cg showing a character C operated by a user of the game device 10 is displayed in a virtual field Fd related to a predetermined game. The user of the game device 10 can move the character C in the virtual field Fd displayed on the virtual field screen G1 by operating the operation unit 140. In this embodiment, the "movement of character C" refers to a change in the position or posture of the character image Cg representing character C on the virtual field screen G1. Here, the posture of the character image Cg is a concept including the posture of the character C represented as the shape of the image Cg displayed in the virtual field Fd, and the orientation of the character image Cg in the virtual field Fd.

[0032] In this embodiment, time passes in a given game only when the character image Cg is displayed on the virtual field Fd. That is, in this embodiment, time passes in a given game when the display control unit 115 causes the display unit 31 to display the virtual field screen G1 including the character image Cg representing the character C.

[0033] 4, the virtual field screen G1 displays a status display image Pg showing the status of the character C. The status display image Pg includes a hit point image PH showing the physical strength state of the character C, and a stamina image PS showing the stamina of the character C. The details of the hit point image PH and the stamina image PS will be described later. In addition, as illustrated in FIG. 4, in addition to the character image Cg representing the character C, the virtual field screen G1 may display an enemy character image CEg representing an enemy character CE that the character C must defeat, and an ally character image CBg that cooperates with the character C in achieving a specified goal related to a specified game.

[0034] 5 is a diagram showing an example of the status check screen G2. The status check screen G2 is a screen for the user of the game device 10 to check the status of the character C and the like.

[0035] In this embodiment, when the display control unit 115 causes the display unit 31 to display the status check screen G2, the display control unit 115 does not cause the display unit 31 to display the virtual field screen G1 and the item check screen G3. Therefore, in this embodiment, when the display control unit 115 causes the display unit 31 to display the status check screen G2, the passage of time in a predetermined game is stopped. Then, in this embodiment, when the display control unit 115 causes the display unit 31 to display the virtual field screen G1 again after displaying the status check screen G2, the passage of time in the predetermined game is resumed. However, the present invention is not limited to such an embodiment, and the display control unit 115 may simultaneously display the virtual field screen G1 and the status check screen G2 on the display unit 31. For example, the display control unit 115 may display the status check screen G2 superimposed on the virtual field screen G1 on the display unit 31. In this case, even when the display control unit 115 is displaying the status check screen G2 on the display unit 31, time in a predetermined game may elapse.

[0036] As shown in FIG. 5, the status check screen G2 has an abnormal state display area A1, a character state display area A2, an experience value display area A3, and a level display area A4.

[0037] The abnormal state display area A1 displays information about the abnormal state that the character C is in. Specifically, the abnormal state display area A1 displays a character image Cg showing the character C, an abnormal state image BG showing the abnormal state that the character C is in, and an abnormal state name BN which is the name of the abnormal state. In this embodiment, it is assumed that the character C may simultaneously fall into a plurality of abnormal states. For example, Fig. 5 illustrates a case in which the character C simultaneously falls into three abnormal states, namely, a "bruise" on the shoulder, a "laceration" on the hand, and a "laceration" on the knee.

[0038] A hit point image PH and a stamina image PS are displayed in the character status display area A2.

[0039] 5, the hit point image PH represents hit points HP (an example of a "parameter value"), a hit point recovery reference value H1 (an example of a "first upper limit value"), and a hit point recovery upper limit value H2 (an example of a "second upper limit value"). Specifically, in this embodiment, in the hit point image PH, the hit points HP are represented as the length of the diagonal line portion, the hit point recovery reference value H1 is represented as the position of the pointer image PH1, and the hit point recovery upper limit value H2 is represented as the overall length of the hit point image PH.

[0040] Here, the hit point HP is a parameter value indicating the quality of the physical strength state of the character C. That is, in this embodiment, the hit point HP indicates a large value when the physical strength state of the character C is good, and indicates a small value when the physical strength state of the character C is poor. Then, when the hit point HP of the character C reaches a predetermined lower limit, for example, "0", it becomes impossible for the character C to continue the predetermined game (game over). That is, the hit point HP is a value indicating the degree of the possibility of the character C continuing the game.

[0041] Although details will be described later, in this embodiment, hit points HP and hit point recovery reference value H1 satisfy the relationship "HP≦H1", and hit point recovery reference value H1 and hit point recovery upper limit value H2 satisfy the relationship "H1≦H2".

[0042] As shown in Figure 5, the stamina image PS represents a stamina value SP (another example of a "parameter value"), a stamina recovery reference value S1 (another example of a "first upper limit value"), and a stamina recovery upper limit value S2 (another example of a "second upper limit value"). Specifically, in this embodiment, in the stamina image PS, the stamina value SP is represented as the length of the diagonal line portion, the stamina recovery reference value S1 is represented as the position of the pointer image PS1, and the stamina recovery upper limit value S2 is represented as the overall length of the stamina image PS.

[0043] Here, the stamina value SP is a parameter value indicating the goodness of the stamina-related condition of the character C. That is, in this embodiment, the stamina value SP indicates a large value when the character C has a sufficient amount of stamina and is in a good condition, and indicates a small value when the character C has no stamina and is in a poor condition. Then, when the stamina value SP of the character C becomes a predetermined lower limit value, for example, "0", the character C becomes unable to move. That is, the stamina value SP is a value indicating the degree of the restriction on the movement of the character C.

[0044] Although details will be described later, in this embodiment, the stamina value SP and the stamina recovery reference value S1 satisfy the relationship "SP≦S1", and the stamina recovery reference value S1 and the stamina recovery upper limit value S2 satisfy the relationship "S1≦S2".

[0045] In addition, in this embodiment, the display control unit 115 displays the hit point image PH and stamina image PS when the character C is in a normal state as different images from the hit point image PH and stamina image PS when the character C is in an abnormal state. Specifically, the display control unit 115 displays a hit point image PH when the character C is in a normal state and a hit point image PH when the character C is in an abnormal state in which the fluctuation of the physical strength state becomes abnormal, as different images on the display unit 31. For example, when the character C is in a normal state, the display control unit 115 displays the pointer image PH1 in "white" of the hit point image PH, and when the character C is in an abnormal state in which the fluctuation of the physical strength state becomes abnormal, the display control unit 115 displays the pointer image PH1 in "black". Furthermore, the display control unit 115 displays the stamina image PS when the character C is in a normal state and the stamina image PS when the character C is in an abnormal state where the manner of fluctuation in the stamina-related state becomes abnormal, as different images on the display unit 31. For example, the display control unit 115 displays the pointer image PS1 of the stamina image PS in "white" when the character C is in a normal state, and displays the pointer image PS1 in "black" when the character C is in an abnormal state where the manner of fluctuation in the stamina-related state becomes abnormal. In Fig. 5, the abnormal state that the character C falls into is an abnormal state in which the fluctuation of the physical strength state is abnormal, and is not an abnormal state in which the fluctuation of the state related to stamina is abnormal. Therefore, in the example shown in Fig. 5, the display control unit 115 displays the pointer image PH1 in "black" and the pointer image PS1 in "white".

[0046] The experience value display area A3 displays the experience value of the character C. Here, the experience value of the character C refers to the total score given when, for example, the character C defeats an enemy character CE, when the character C rescues a predetermined ally character CB, when the character C clears a mission in a predetermined game, etc.

[0047] The level of character C is displayed in the level display area A4. Here, the level of character C is a value indicating the level of the ability of character C, and is determined, for example, based on the experience points acquired by character C. More specifically, the level of character C increases when, for example, a condition is satisfied that the experience points acquired by character C reach a value corresponding to the level of character C (an example of a "predetermined game condition"). Note that the level of character C may increase when a condition is satisfied that a predetermined goal set in a predetermined game is achieved.

[0048] 6 is a diagram showing an example of an item confirmation screen G3. The item confirmation screen G3 is a screen for allowing the user of the game device 10 to confirm the contents and quantity of items possessed by the character C and to allow the character C to use or consume the items possessed by the character C.

[0049] In this embodiment, when the display control unit 115 causes the display unit 31 to display the item confirmation screen G3, the display control unit 115 does not cause the display unit 31 to display the virtual field screen G1 and the status confirmation screen G2. Therefore, in this embodiment, when the display control unit 115 causes the display unit 31 to display the item confirmation screen G3, the passage of time in a predetermined game is stopped. Then, in this embodiment, when the display control unit 115 causes the display unit 31 to display the virtual field screen G1 again after displaying the item confirmation screen G3, the passage of time in the predetermined game is resumed. However, the present invention is not limited to such an embodiment, and the display control unit 115 may simultaneously display the virtual field screen G1 and the item confirmation screen G3 on the display unit 31. For example, the display control unit 115 may display the item confirmation screen G3 superimposed on the virtual field screen G1 on the display unit 31. In this case, even when the display control unit 115 is displaying the item confirmation screen G3 on the display unit 31, time in a predetermined game may elapse.

[0050] As shown in FIG. 6, the item confirmation screen G3 has an abnormal state display area A1, a possessed item display area A5, and a possessed money display area A6.

[0051] The possessed item display area A5 displays a list of items possessed by the character C. Specifically, the possessed item display area A5 displays an image Ig of each item possessed by the character C, the name In of the item, and the possessed quantity Im of the item by the character C. Character C can use or consume items displayed in the possessed item display area A5. In this embodiment, the use of an item is a concept including the use of the item and the consumption of the item. Here, the use of an item means using the item while possessing it, for example, "equipping a long sword". Furthermore, the consumption of an item means making the item temporarily or permanently unusable as a result of using the item. As an example, the consumption of an item means using the item to make it disappear, for example, "eating bread". As another example, the consumption of an item means using the item to make it in a state where the effect that occurs when using the item does not occur (a state where it is temporarily unusable), for example, "using up all the oxygen in an oxygen tank" and "using up all the power charged in a rechargeable battery".

[0052] The money display area A6 displays the amount of money possessed by the character C. The money possessed by the character C is virtual money owned by the character C. The character C can spend the virtual money in a predetermined game. The character C can purchase various items by spending the money possessed. Furthermore, the character C can receive various services provided within the virtual field Fd, such as accommodation services provided at accommodation facilities within the virtual field Fd or medical services provided at medical facilities within the virtual field Fd, by spending the money possessed.

[0053] [4. Operation of the game device] An example of the operation of the game device 10 when the game device 10 executes a predetermined game will be described with reference to FIGS.

[0054] [4.1. Overview of Game Device Operation] FIG. 7 is a sequence chart showing an example of the operation of the game device 10 when the game device 10 executes a predetermined game.

[0055] 7, when a predetermined game is started in the game device 10, the game control unit 111 first executes an initialization process (S100). Here, the initialization process is a process for initializing a part of the information included in the character information Info.

[0056] 8 is a diagram showing an example of the data configuration of the character information Info. In this embodiment, the character information Info includes the level, experience value, and money of the character C, the position of the character C in the virtual field Fd, an action ID corresponding to the action of the character C, the hit points HP, the hit point recovery reference value H1, and the hit point recovery upper limit value H2 of the character C, the stamina value SP, the stamina recovery reference value S1, and the stamina recovery upper limit value S2 of the character C, the damage amount dm, the end information Fin, and the update date and time TM.

[0057] Here, the action ID is an identification number given to each action in order to uniquely identify all the actions that the character C can perform. The amount of damage dm is a value indicating the amount of damage (loss) that character C has received. The end information Fin is information that indicates whether or not a specific game is to be ended. In this embodiment, when the end information Fin indicates "1", it indicates that the specific game is to be ended, and when the end information Fin indicates "0", it indicates that the specific game is not to be ended.

[0058] In the initialization process of step S100, the game control unit 111 sets the action ID to "Null", the damage amount dm to "0", the end information Fin to "0", and the update date and time TM to a value indicating the current time. Here, the action ID being "Null" indicates that the character C is not performing an action.

[0059] In this embodiment, the game control unit 111 does not change any information in the character information Info other than the action ID, the amount of damage dm, the end information Fin, and the update date and time TM during the initialization process. It is assumed that the information in the character information Info other than the action ID, the amount of damage dm, the end information Fin, and the update date and time TM is set to a predetermined value at the start of a specific game, or a value according to the past play history of the specific game by the user of the game device 10.

[0060] Let us return to the explanation of FIG. As shown in FIG. 7, the operation information acquisition unit 114 determines whether or not the user of the game device 10 has operated the operation unit 140 (S102). Then, if the result of the determination in step S102 is positive, the operation information acquisition unit 114 acquires the details of the operation of the operation unit 140 by the user of the game device 10 (S104). On the other hand, if the result of the determination in step S102 is negative, the operation information acquiring section 114 advances the process to step S110.

[0061] Next, the game control unit 111 determines whether or not the operation content acquired by the operation information acquisition unit 114 in step S104 is content that designates an action of the character C (S106). If the result of the determination in step S106 is positive, the action execution unit 112 executes a character action process for causing the character C to act based on the operation content acquired by the operation information acquisition unit 114 in step S104 (S108). The character action process will be described in detail later. On the other hand, if the result of the determination in step S106 is negative, the game control unit 111 advances the process to step S110.

[0062] Next, the game control unit 111 determines whether or not an event has occurred in a predetermined game (S110). Here, an "event" refers to a phenomenon in a game other than the behavior of character C, in which the state of character C, the level of character C, and the contents and quantity of items possessed by character C change. As described above, in this embodiment, the behavior of character C refers to a change in the position or posture of character C (character image Cg) in the virtual field Fd displayed on the virtual field screen G1. For this reason, in this embodiment, as an example, "consumption of an item by character C" executed on the item confirmation screen G3 is classified as an event in a predetermined game, not as an action of character C. However, the present invention is not limited to such an aspect, and "consumption of an item by character C" may be classified as an action of character C. For example, character C may be able to execute an action of consuming an item in a virtual field Fd.

[0063] Next, if the result of the determination in step S110 is positive, the game control unit 111 executes an event process to update various data stored in the storage unit 120 based on the content of the event determined to have occurred in step S110 (S112). Details of the event process will be described later. On the other hand, if the result of the determination in step S110 is negative, the game control unit 111 advances the process to step S120.

[0064] Next, the state management unit 113 executes a state update process to update the state of character C based on some or all of the results of the character action processing in step S108, the results of the event processing in step S112, and the passage of time in a specified game (S120). Details will be described later, but the status update process executed in step S120 includes a hit point update process (S122) that updates hit points HP, hit point recovery reference value H1, and hit point recovery upper limit value H2, and a stamina value update process (S124) that updates stamina value SP, stamina recovery reference value S1, and stamina recovery upper limit value S2.

[0065] Next, the display control unit 115 executes a display control process (S130) to generate display information based on some or all of the result of the character movement processing in step S108, the result of the event processing in step S112, and the result of the status update processing in step S120, and controls the display unit 31 to display an image based on the generated display information.

[0066] Next, the game control unit 111 determines whether or not a game end condition is satisfied (S132). Specifically, in step S132, the game control unit 111 determines whether or not "1" is set to the end information Fin of the character information Info. If the result of the determination in step S132 is positive, the game control unit 111 ends the process shown in FIG. On the other hand, if the result of the determination in step S132 is negative, the game control unit 111 advances the process to step S100.

[0067] In this embodiment, for convenience of explanation, it is assumed that if the result of the determination in step S132 is negative, the initialization process in step S100 is executed every unit time ΔT.

[0068] [4.2. Character movement processing] Next, the character action processing will be described with reference to FIGS. FIG. 9 is a sequence chart showing an example of the operation of the game device 10 when the game device 10 executes the character operation process.

[0069] As shown in FIG. 9, when the character action processing is started, the action execution unit 112 determines, based on the character information Info and the action information stored in the action information table TBL1, whether or not the character C is capable of executing the action (hereinafter referred to as the "specified action") specified by the operation content acquired by the operation information acquisition unit 114 in step S104 (S200).

[0070] 10 is a diagram showing an example of the data configuration of the action information table TBL1. The action information table TBL1 has a plurality of records that correspond one-to-one to all actions that the character C can execute. Each record in the action information table TBL1 stores an action ID and action information. The action information includes an action name, which is the name of the action, a consumed stamina value dSP-A, an action limit stamina value SPth, and a hit point reference value reduction amount dH1-A.

[0071] Here, the consumed stamina value dSP-A is the stamina value SP of the character C that is consumed when the character C performs each action. In this embodiment, the consumed stamina value dSP-A is a non-negative value. The action limiting stamina value SPth is the stamina value SP of the character C that is required for the character C to perform each action without restriction, and is an example of a "predetermined threshold value." In this embodiment, the action limiting stamina value SPth is a non-negative value. If the stamina value SP of the character C stored in the character information Info is smaller than the action limiting stamina value SPth corresponding to the designated action, the character C will be restricted when performing the designated action. Here, "action being restricted" means that the speed of the action will be slowed down (for example, "running speed will be slowed down"), or the effect of the action will be reduced (for example, "damage inflicted on the enemy character CE by attack will be reduced"), etc. The hit point reference value decrement dH1-A is the decrement of the hit point recovery reference value H1 of the character C when the character C performs each action. In this embodiment, the hit point reference value decrement dH1-A is a non-negative value.

[0072] In step S200, if the stamina value SP of character C stored in the character information Info is equal to or greater than the consumed stamina value dSP-A corresponding to the designated action, the action execution unit 112 determines that the designated action can be executed, and conversely, if the stamina value SP of character C stored in the character information Info is less than the consumed stamina value dSP-A corresponding to the designated action, it determines that the designated action cannot be executed.

[0073] As shown in FIG. 9, if the result of the determination in step S200 is positive, the action execution unit 112 determines whether the specified action is an action involving movement of the character C (change in the position of the character image Cg) in the virtual field Fd (S202). On the other hand, if the result of the determination in step S200 is negative, the action execution section 112 ends the character action processing.

[0074] If the result of the determination in step S202 is positive, the action execution unit 112 sets a value (coordinates) indicating the destination position of the character C to the "position" of the character information Info, and also sets an action ID indicating the designated action to the "action ID" of the character information Info (S204). Then, after step S204, the action execution unit 112 ends the character action processing.

[0075] On the other hand, if the result of the determination in step S202 is negative, the action execution unit 112 determines whether or not the specified action is an action for obtaining an item (S206). In this embodiment, the character C can obtain various items in the virtual field Fd. Then, the user of the game device 10 can use the items obtained by the character C in a predetermined game. Such information related to the items that the character C can obtain is managed in the item information table TBL2.

[0076] 11 is a diagram showing an example of the data configuration of the item information table TBL2. The item information table TBL2 has a plurality of records that correspond one-to-one to all items that the character C can obtain. Each record in the item information table TBL2 stores an item ID and item information. The item information includes an item name In, which is the name of the item, a hit point reference value recovery amount uH1-I, a stamina reference value recovery amount uS1-I, and a recovery target abnormal state ID.

[0077] Here, the item ID is an identification number given to each item in order to uniquely identify all types of items available to the character C. The hit point reference value recovery amount uH1-I is the amount of the hit point recovery reference value H1 recovered when the character C consumes an item. In this embodiment, the hit point reference value recovery amount uH1-I is a non-negative value. The stamina reference value recovery amount uS1-I is the amount of the stamina recovery reference value S1 recovered when the character C consumes an item. In this embodiment, the stamina reference value recovery amount uS1-I is a non-negative value. The recovery target abnormal condition ID is an abnormal condition ID associated with the type of abnormal condition that will be recovered from when character C consumes an item. Here, the abnormal condition ID is an identification number given to each abnormal condition in order to uniquely identify all types of abnormal conditions that character C may fall into. If there is no abnormal condition that can be recovered from even if character C consumes an item, the recovery target abnormal condition ID is set to "Null". In addition, if character C can recover character C's hit point recovery reference value H1, recover character C's stamina recovery reference value S1, or recover character C's abnormal condition by consuming an item, then the item will be considered a "specified game element" for improving character C's condition to a good condition.

[0078] 9, if the result of the determination in step S206 is positive, the action execution unit 112 updates the possessed item management table TBL3 (S208). Specifically, in step S208, the action execution unit 112 reflects the item that the character C has come to possess as a result of the designated action (obtaining) in the possessed item information stored in the possessed item management table TBL3.

[0079] 12 is a diagram showing an example of the data configuration of the possessed item management table TBL3. The possessed item management table TBL3 has one or more records that correspond one-to-one to one or more types of items possessed by the character C. Each record in the possessed item management table TBL3 stores possessed item information, such as an item ID corresponding to the type of item possessed by the character C, the item name In of the item, and the possessed quantity Im of the item by the character C.

[0080] As shown in FIG. 9, if the result of the determination in step S206 is negative, the operation execution section 112 advances the process to step S210. Thereafter, the action execution unit 112 sets the action ID indicating the specified action to the "action ID" of the character information Info (S210). Then, after step S210, the action execution unit 112 ends the character action processing.

[0081] [4.3. Event Processing] Next, the event processing will be described with reference to FIGS.

[0082] As described above, an event is a phenomenon occurring in a predetermined game other than the action of the character C. In this embodiment, a case is assumed in which, in a predetermined game, there are events occurring due to the action of the character C, events occurring due to the operation of the operation unit 140 by the user of the game device 10, and events occurring without being caused by either the action of the character C or the operation by the user.

[0083] Specifically, in this embodiment, as an example, a case is assumed in which six events may occur in a specified game: an event in which character C receives damage (hereinafter referred to as "receiving damage"); an event in which character C defeats an enemy and gains experience points (hereinafter referred to as "defeating an enemy"); an event in which character C consumes an item (hereinafter referred to as "item consumption"); an event in which character C's level increases (hereinafter referred to as "level up"); an event in which character C receives accommodation or treatment services at a facility in the virtual field Fd (hereinafter referred to as "accommodation or treatment"); and an event in which the user of the game device 10 instructs the end of the specified game (hereinafter referred to as "game end instruction").

[0084] In this embodiment, the event of "receiving damage" can be classified into events that occur not due to the actions of character C, such as the result of character C being attacked by an enemy character CE, and events that occur due to the actions of character C, such as character C falling off a cliff while moving through the virtual field Fd. In this embodiment, the event of "defeating an enemy" is an event that occurs due to an action of character C, that is, character C attacks enemy character CE. In this embodiment, the event "item consumption" is an event that occurs due to an operation by the user of the game device 10 while the item confirmation screen G3 is being displayed on the display unit 31. In this embodiment, the event "level up" is an event that occurs as a result of the character C attacking and defeating the enemy character CE, and is an event that occurs due to the action of the character C. In this embodiment, the event of "accommodation or treatment" is an event that occurs as a result of an operation by the user of the game device 10, for example, by the user of the game device 10 operating the operation unit 140 to cause the character C to receive services at a facility on the virtual field Fd, such as an accommodation facility or a medical facility. The event "game end instruction" is an event that occurs due to an operation by the user of the game device 10, for example, when the user of the game device 10 operates the operation unit 140 to instruct the end of a predetermined game.

[0085] FIG. 13 is a sequence chart showing an example of the operation of the game device 10 when the game device 10 executes an event process.

[0086] As shown in FIG. 13, the game control unit 111 determines whether or not the event determined to have occurred in step S110 (hereinafter referred to as an "occurring event") is an event of "receiving damage" (S300).

[0087] If the result of the determination in step S300 is positive, the game control unit 111 stores the magnitude of the damage received by the character C in the occurring event as the damage amount dm of the character information Info (S302). For example, if the magnitude of the damage received by the character C in the occurring event is "300", the game control unit 111 sets the damage amount dm of the character information Info to "300". In addition, the game control unit 111 updates the abnormal state management information stored in the abnormal state management table TBL5 based on the content of the damage suffered by the character C due to the occurring event and the abnormal state information stored in the abnormal state information table TBL4 (S304).

[0088] FIG. 14 is a diagram showing an example of the data configuration of the abnormal state information table TBL4. The abnormal state information table TBL4 has a plurality of records that correspond one-to-one to all abnormal states that the character C may fall into. Each record in the abnormal state information table TBL4 stores an abnormal state ID and abnormal state information. The abnormal state information includes an abnormal state name BN, a hit point reference value reduction amount dH1-B, a stamina reference value reduction amount dS1-B, a hit point recovery speed ratio dHP-B, and cause damage information.

[0089] Here, the abnormal state ID is an identification number given to each abnormal state in order to uniquely identify all types of abnormal states into which the character C may fall. The hit point reference value decrement dH1-B is the decrement of the hit point recovery reference value H1 of the character C per unit time ΔT when the character C falls into an abnormal state. That is, in this embodiment, when the character C falls into an abnormal state, the hit point recovery reference value H1 is decremented by the hit point reference value decrement dH1-B per unit time ΔT. Note that in this embodiment, the hit point reference value decrement dH1-B is a non-negative value. The stamina reference value decrease amount dS1-B is the amount of decrease in the stamina recovery reference value S1 of character C per unit time ΔT when character C falls into an abnormal state. That is, in this embodiment, when character C falls into an abnormal state, the stamina recovery reference value S1 decreases by the stamina reference value decrease amount dS1-B per unit time ΔT. Note that in this embodiment, the stamina reference value decrease amount dS1-B is a non-negative value. The hit point recovery speed ratio dHP-B is the ratio of the recovery speed of the hit points HP per unit time ΔT when the character C falls into an abnormal state to the recovery speed of the hit points HP per unit time ΔT when the character C is in a normal state. In this embodiment, the hit point recovery speed ratio dHP-B is a real value that satisfies "0≦dHP-B≦1". In this embodiment, when the character C is in a normal state, the hit points HP of the character C recover by a hit point recovery amount uHP-T per unit time ΔT (uHP-T is a real number that satisfies uHP-T>0), as will be described in detail later. Therefore, when the character C changes from a normal state to an abnormal state, the recovery amount of the hit points HP of the character C per unit time ΔT changes (decreases) from "uHP-T" to "uHP-T*dHP-B".

[0090] The cause damage information is information that indicates the type of damage (an example of "predetermined damage") that causes each abnormal state. For example, the cause damage information has a plurality of elements corresponding to the combination of each of a plurality of abnormal states and each of a plurality of types of damage, and each element indicates "1" when the damage corresponding to the element causes the abnormal state corresponding to the element, and indicates "0" when the damage corresponding to the element does not cause the abnormal state corresponding to the element. In the example shown in FIG. 14, the element corresponding to the damage "attack by sword" and the abnormal state "laceration" is "1", so when character C receives the damage "attack by sword", the character C will fall into the abnormal state "laceration". Also, in the example shown in FIG. 14, the element corresponding to the damage "ingestion of poison" and the abnormal state "fracture" is "0", so even if character C receives the damage "ingestion of poison", the character C will not fall into the abnormal state "fracture". Note that there may be types of damage that do not result in an abnormal state even if the damage is received, such as "bare-handed attack" damage exemplified in FIG. In addition, in this embodiment, it is assumed that the causal damage information indicates whether or not each abnormal state will occur due to each damage using a binary value of ``1'' or ``0'', but the present invention is not limited to this form, and the causal damage information may also represent the probability of each abnormal state occurring due to each damage using a real value between ``0'' and ``1'', inclusive.

[0091] 15 is a diagram showing an example of the data configuration of the abnormal condition management table TBL5. The abnormal condition management table TBL5 has one or more records that correspond one-to-one to one or more types of abnormal conditions into which the character C falls. Each record in the abnormal condition management table TBL5 stores, as abnormal condition management information, an abnormal condition ID corresponding to the type of abnormal condition into which the character C falls, an abnormal condition name BN of the abnormal condition, and the quantity of the abnormal condition into which the character C falls (abnormal condition quantity BM).

[0092] In step S304, the game control unit 111 first refers to the cause damage information in the abnormal state information table TBL4 to identify an abnormal state ID corresponding to an abnormal state caused by damage received by the character C in the occurring event. Next, if the abnormal state management table TBL5 does not contain a record in which the abnormal state ID identified by referring to the abnormal state information table TBL4 is recorded, the game control unit 111 adds a record in which the abnormal state ID is recorded to the abnormal state management table TBL5, and records, for example, "1" in the abnormal state quantity BM of the record. On the other hand, if the abnormal state management table TBL5 contains a record in which the abnormal state ID identified by referring to the abnormal state information table TBL4 is recorded, the game control unit 111 adds, for example, "1" to the abnormal state quantity BM of the record. In addition, if multiple abnormal conditions occur to character C due to damage received by character C in the occurring event, a value according to the number of abnormal conditions that have occurred can be added to the abnormal condition quantity BM. After executing step S304, the game control unit 111 ends the event processing.

[0093] As shown in FIG. 13, if the result of the determination in step S300 is negative, the game control unit 111 determines whether the occurring event is an event of "defeating an enemy" (S310).

[0094] If the result of the determination in step S310 is positive, the game control unit 111 adds the points (experience points) acquired by defeating the enemy character CE in the occurring event to the experience points of the character information Info (S312), and the process proceeds to step S330. On the other hand, if the result of the determination in step S310 is negative, the game control unit 111 determines whether the occurring event is an "item consumption" event (S320).

[0095] If the result of the determination in step S320 is positive, the game control unit 111 updates the possessed item management table TBL3 according to the type and quantity of the item consumed in the occurring event (S322). Specifically, in step S322, the game control unit 111 identifies a record in the possessed item management table TBL3 in which an item ID corresponding to the item consumed in the occurring event is recorded, and subtracts the quantity of the item consumed in the occurring event from the possessed quantity Im of that record.

[0096] Furthermore, the game control unit 111 updates the abnormal state management table TBL5 in accordance with the type and number of items consumed in the occurring event (S324), and advances the process to step S330. Specifically, in step S324, the game control unit 111 first refers to the item information table TBL2 and identifies a record in which an item ID corresponding to an item consumed in the occurring event is recorded. Next, the game control unit 111 judges whether or not an abnormal state ID identical to the recovery target abnormal state ID recorded in the record identified by referring to the item information table TBL2 is recorded in the abnormal state management table TBL5. If the result of the judgment is positive, the game control unit 111 subtracts the abnormal state quantity BM of the record in which the abnormal state ID identical to the recovery target abnormal state ID is recorded in the abnormal state management table TBL5 according to the type and quantity of the item consumed in the occurring event. On the other hand, if the result of the judgment is negative, the game control unit 111 ends the processing of step S324 without updating the abnormal state management table TBL5. In this way, when the character C falls into an abnormal state, the user of the game device 10 can restore the character C to a normal state by consuming an item that can restore the character C from the abnormal state.

[0097] As shown in FIG. 13, if the result of the determination in step S320 is negative, or if the processing in step S312 or S324 ends, the game control unit 111 determines whether the occurring event is a "level up" event (S330).

[0098] If the result of the determination in step S330 is positive, the game control unit 111 adds, for example, "1" to the level of the character information Info (S332), and ends the event processing. On the other hand, if the result of the determination in step S330 is negative, the game control unit 111 determines whether the occurring event is an "accommodation or treatment" event (S340).

[0099] If the result of the judgment in step S340 is positive, the game control unit 111 subtracts an amount equivalent to the fee for character C receiving accommodation or medical treatment services at a facility within the virtual field Fd (another example of a ``specified game element'') from the money held by the character information Info (S342).

[0100] In addition, the game control unit 111 updates the abnormal state management table TBL5 so that a part or all of the abnormal states of the character C become normal states in response to the character C receiving lodging or medical treatment services at a facility in the virtual field Fd (S344). Specifically, in step S344, the game control unit 111 subtracts a predetermined number from the abnormal state quantity BM of each record in the abnormal state management table TBL5, for example.

[0101] If the result of the determination in step S340 is negative, the game control unit 111 determines whether the occurring event is an event called a "game end instruction" (S350). Then, if the result of the determination in step S350 is positive, the game control unit 111 sets the end information Fin of the character information Info to "1", which is a value indicating that the predetermined game is ending (S352), and ends the event processing. On the other hand, if the result of the determination in step S350 is negative, the game control unit 111 ends the event processing.

[0102] [4.4. Hit point update process] Next, the hit point update process of the state update process will be described with reference to FIG.

[0103] FIG. 16 is a sequence chart showing an example of the operation of the game device 10 when the game device 10 executes the hit point update process among the state update processes. As shown in FIG. 16, the hit point update process includes a hit point recovery upper limit setting process, which sets the hit point recovery upper limit H2 to a value corresponding to the level of character C, a hit point recovery reference value setting process, which sets the hit point recovery reference value H1 to a value corresponding to the consumption of items, the passage of time, etc., and a hit point setting process, which sets hit points HP to a value corresponding to the presence or absence of damage, the passage of time, etc.

[0104] As shown in FIG. 16, in the hit point update process, the state management section 113 first executes a hit point recovery upper limit setting process (S400).

[0105] In the hit point recovery upper limit setting process, the state management unit 113 first determines whether or not the character C has leveled up (S402). That is, in step S402, the state management unit 113 determines whether or not the result of the determination in step S110 is positive and the result of the determination in step S330 is positive.

[0106] If the result of the determination in step S402 is affirmative, the state management unit 113 increases the hit point recovery upper limit value H2 by the hit point upper limit value increase amount ΔH2u, sets the increased hit point recovery upper limit value H2 in the character information Info (S404), and then ends the hit point recovery upper limit value setting process. Here, the hit point upper limit value increase amount ΔH2u is, for example, a non-negative value determined according to the level of the character C. On the other hand, if the result of the determination in step S402 is negative, the state management unit 113 ends the hit point recovery upper limit value setting process without changing the hit point recovery upper limit value H2.

[0107] As shown in FIG. 16, after ending the hit point recovery upper limit value setting process in step S400, the state management unit 113 executes a hit point recovery reference value setting process (S420).

[0108] In the hit point recovery reference value setting process, the state management unit 113 first determines whether the hit point recovery reference value H1 and the hit point recovery upper limit value H2 satisfy the relationship of "H1 < H2" (S422).

[0109] If the result of the determination in step S422 is affirmative, the state management unit 113 determines whether there has been a phenomenon of recovering the hit point recovery reference value H1 after the initialization process (S424). Specifically, in step S424, the state management unit 113 determines whether there has been an event of recovering the hit point recovery reference value H1 or an operation of the character C that recovers the hit point recovery reference value H1 after the initialization process in step S100. In this embodiment, when the character C consumes an item having a hit point reference value recovery amount uH1-I greater than "0" or when the character C receives a service related to lodging or medical treatment, the hit point recovery reference value H1 is recovered. Therefore, when the result of the determination in step S320 is positive and the hit point reference value recovery amount uH1-I of the item consumed by the character C is greater than "0", or when the result of the determination in step S340 is positive and the character C receives a service related to lodging or medical treatment, the state management unit 113 determines that a phenomenon that recovers the hit point recovery reference value H1 has occurred.

[0110] If the result of the judgment in step S424 is positive, the status management unit 113 increases the hit point recovery reference value H1 by the hit point reference value recovery amount ΔH1u, sets the increased hit point recovery reference value H1 in the character information Info (S426), and then terminates the hit point recovery reference value setting process. Specifically, in step S426, the state management unit 113 adds the hit point recovery amount ΔH1u to the hit point recovery reference value H1 stored in the character information Info, thereby increasing the hit point recovery reference value H1 stored in the character information Info up to the hit point recovery upper limit value H2. Here, the hit point recovery amount ΔH1u is the hit point recovery amount uH1-I of the item consumed in the event that occurred, or the recovery amount of the hit point recovery reference value H1 resulting from lodging or treatment.

[0111] As shown in FIG. 16, if the result of the judgment in step S422 is negative, the status management unit 113 judges whether the period during which the hit point recovery reference value H1 and the hit point recovery upper limit value H2 satisfy the relationship "H1=H2" is longer than a predetermined time (S428).

[0112] Furthermore, if the result of the determination in step S424 is negative, or if the result of the determination in step S428 is positive, the state management unit 113 determines whether or not the character C is present on the virtual field Fd (S430). Specifically, in step S430, the state management unit 113 determines whether or not the virtual field screen G1 is displayed on the display unit 31.

[0113] If the result of the judgment in step S430 is positive, the status management unit 113 reduces the hit point recovery reference value H1 by the hit point reference value reduction amount ΔH1d, sets the reduced hit point recovery reference value H1 in the character information Info (S432), and then terminates the hit point recovery reference value setting process. Specifically, in step S432, the status management unit 113 subtracts the hit point reference value reduction amount ΔH1d from the hit point recovery reference value H1 stored in the character information Info, thereby reducing the hit point recovery reference value H1 stored in the character information Info, for example, to a lower limit value of "0". In this embodiment, the hit point recovery reference value H1 decreases over time even when the character C is in a normal state and does not perform an action that has a hit point reference value decrease amount dH1-A greater than "0". For this reason, in this embodiment, the state management unit 113 calculates the hit point reference value decrease amount ΔH1d as a value obtained by adding the hit point reference value decrease amount dH1-A corresponding to the action of the character C, the hit point reference value decrease amount dH1-B corresponding to the abnormal state in which the character C is in, and the hit point reference value decrease amount dH1-T, which is the decrease amount of the hit point recovery reference value H1 per unit time ΔT (dH1-T is a real number that satisfies dH1-T>0). However, the present invention is not limited to such an embodiment, and the hit point reference value decrease amount ΔH1d may include at least the hit point reference value decrease amount dH1-T.

[0114] Furthermore, if the result of the determination in step S428 or S430 is negative, the state management unit 113 ends the hit point recovery reference value setting process.

[0115] In this embodiment, the state management unit 113 performs the process of step S430 in the hit point recovery reference value setting process, but the present invention is not limited to such an aspect, and the state management unit 113 may not execute the process of step S430 in the hit point recovery reference value setting process. For example, when the virtual field screen G1 and the status check screen G2 are displayed simultaneously on the display unit 31, and it is considered that time has passed in a predetermined game even while the status check screen G2 is being displayed, if the result of the determination in step S424 is negative or the result of the determination in step S428 is positive, the process of step S432 may be executed without going through the process of step S430.

[0116] In addition, in this embodiment, the hit point reference value decrement dH1-T is not taken into consideration when increasing the hit point recovery reference value H1 in step S426, but the present invention is not limited to such an embodiment, and the hit point reference value decrement dH1-T may be taken into consideration when increasing the hit point recovery reference value H1 in step S426. In this case, the hit point reference value recovery amount ΔH1u is a value obtained by subtracting the hit point reference value decrement dH1-T from the hit point reference value recovery amount uH1-I of the item consumed in the occurring event, or the recovery amount of the hit point recovery reference value H1 resulting from lodging or treatment.

[0117] As shown in FIG. 16, after the hit point recovery reference value setting process in step S420 ends, the state management unit 113 executes a hit point setting process (S440).

[0118] In the hit point setting process, the state management unit 113 first determines whether or not the character C is present on the virtual field Fd (S442).

[0119] If the result of the determination in step S442 is positive, the state management unit 113 determines whether or not the character C has received damage since the initialization process (S444). Specifically, in step S444, the state management unit 113 determines whether or not the result of the determination in step S300 is positive, or whether or not the damage amount dm stored in the character information Info is greater than "0".

[0120] If the result of the determination in step S444 is positive, the state management section 113 determines whether or not the hit points HP and the hit point recovery reference value H1 satisfy the relationship "HP≦H1" (S446).

[0121] If the result of the determination in step S446 is positive, the state management unit 113 determines whether or not the motion of the character C has stopped since the initialization process (S448). Specifically, in step S448, the state management unit 113 determines whether or not the result of the determination in step S106 is negative, or whether or not "Null" is set in the motion ID of the character information Info. In this embodiment, the condition that the action of character C stops is an example of a "predetermined action condition."

[0122] If the result of the determination in step S448 is positive, the state management unit 113 determines whether or not the character C is in an abnormal state that makes the hit points HP of the character C unrecoverable (S450). Specifically, in step S450, the state management unit 113 determines whether or not the abnormal states in which the character C is in include an abnormal state in which the hit point recovery speed ratio dHP-B is "0", based on the abnormal state information stored in the abnormal state information table TBL4 and the abnormal state management information stored in the abnormal state management table TBL5.

[0123] If the result of the judgment in step S450 is positive, the status management unit 113 increases the hit points HP by the hit point recovery amount ΔHPu, sets the increased hit points HP in the character information Info (S452), and then terminates the hit point setting process. Specifically, in step S452, the status management unit 113 adds the hit point recovery amount ΔHPu to the hit points HP stored in the character information Info, thereby increasing the hit points HP stored in the character information Info up to the hit point recovery reference value H1. In this embodiment, the state management unit 113 calculates the hit point recovery amount ΔHPu as a value obtained by multiplying the hit point recovery amount uHP-T, which is the recovery amount of hit points HP per unit time ΔT, by the hit point recovery speed ratio dHP-B. However, when the character C falls into multiple abnormal states, the state management unit 113 may calculate the hit point recovery amount ΔHPu as a value obtained by multiplying, for example, the minimum hit point recovery speed ratio dHP-B among the multiple hit point recovery speed ratios dHP-B corresponding to the multiple abnormal states by the hit point recovery amount uHP-T. In addition, the state management unit 113 may calculate the hit point recovery amount ΔHPu as a value obtained by multiplying, for example, the hit point recovery amount uHP-T by the hit point recovery speed ratio dHP-B and a coefficient that is set to increase according to the level of the character C.

[0124] Then, if the result of the determination in step S444 is negative, or if the result of the determination in step S446 is negative, status management unit 113 reduces the hit points HP by the hit point reduction amount ΔHPd, sets the reduced hit points HP in character information Info (S456), and then terminates the hit point setting process. Specifically, in step S456, state management unit 113 subtracts the hit point reduction amount ΔHPd from the hit points HP stored in character information Info, thereby reducing the hit points HP stored in character information Info, with the lower limit being "0." Note that, in step S456, when the hit points HP become "0," state management unit 113 sets end information Fin to "1." Here, the hit point reduction amount ΔHPd is a value obtained by subtracting the hit point recovery reference value H1 from the damage amount dm or the hit point HP stored in the character information Info. That is, when the character C receives damage, the state management unit 113 reduces the hit point HP by the damage amount dm. Also, when the hit point HP exceeds the hit point recovery reference value H1, the state management unit 113 reduces the hit point HP by "HP-H1" so that the hit point HP and the hit point recovery reference value H1 maintain the relationship "HP≦H1". In other words, the state management unit 113 determines the reduction amount of the hit point HP in step S456 (hit point reduction amount ΔHPd) according to the reduction amount of the hit point recovery reference value H1 in step S432 (hit point reference value reduction amount ΔH1d). For example, if the hit points HP and the hit point recovery reference value H1 are equal before the hit point recovery reference value setting process is executed in step S420, and if the hit point recovery reference value H1 is reduced by a hit point reference value reduction amount ΔH1d in the hit point recovery reference value setting process, the hit point reduction amount ΔHPd will be equal to the hit point reference value reduction amount ΔH1d.

[0125] If the result of the determination in step S442, S448, or S450 is negative, the state management unit 113 ends the hit point setting process. In this embodiment, the state management unit 113 performs the processing of step S442 in the hit point setting process, but the present invention is not limited to such an aspect, and the state management unit 113 may execute the processing of step S444 in the hit point setting process without performing the processing of step S442.

[0126] [4.5. Stamina value update process] Next, the stamina value update process, which is part of the status update process, will be described with reference to FIG.

[0127] FIG. 17 is a sequence chart showing an example of the operation of the game device 10 when the game device 10 executes the stamina value update process among the state update processes. As shown in Figure 17, the stamina value update process includes a stamina recovery upper limit value setting process, which sets the stamina recovery upper limit value S2 to a value corresponding to the level of character C, a stamina recovery reference value setting process, which sets the stamina recovery reference value S1 to a value corresponding to the consumption of items, the passage of time, etc., and a stamina value setting process, which sets the stamina value SP to a value corresponding to whether or not character C is moving, the passage of time, etc.

[0128] As shown in FIG. 17, in the stamina value update process, the state management unit 113 first executes a stamina recovery upper limit value setting process (S500).

[0129] In the stamina recovery upper limit setting process, the state management unit 113 first determines whether or not the character C has leveled up (S502). If the result of the determination in step S502 is positive, the state management unit 113 increases the stamina recovery upper limit S2 by the stamina upper limit increase amount ΔS2u, sets the increased stamina recovery upper limit S2 in the character information Info (S504), and ends the stamina recovery upper limit setting process. Here, the stamina upper limit increase amount ΔS2u is, for example, a non-negative value determined according to the level of the character C. On the other hand, when the result of the determination in step S502 is negative, the state management unit 113 ends the stamina recovery upper limit value setting process without changing the stamina recovery upper limit value S2.

[0130] As shown in FIG. 17, after the end of the stamina recovery upper limit value setting process in step S500, the state management unit 113 executes a stamina recovery reference value setting process (S520).

[0131] In the stamina recovery reference value setting process, the state management unit 113 first determines whether or not the stamina recovery reference value S1 and the stamina recovery upper limit value S2 satisfy the relationship "S1 < S2" (S522).

[0132] When the result of the determination in step S522 is affirmative, the state management unit 113 determines whether or not there is a phenomenon of recovering the stamina recovery reference value S1 after the initialization process (S524). In the present embodiment, when the character C consumes an item having a stamina reference value recovery amount uS1-I greater than "0", or when receiving a service related to accommodation or treatment, the stamina recovery reference value S1 is recovered. Therefore, when the result of the determination in step S320 is affirmative and the stamina reference value recovery amount uS1-I of the item consumed by the character C is greater than "0", or when the result of the determination in step S340 is affirmative and the character C has received a service related to accommodation or treatment, the state management unit 113 determines that there is a phenomenon of recovering the stamina recovery reference value S1.

[0133] Then, when the result of the determination in step S524 is affirmative, the state management unit 113 increases the stamina recovery reference value S1 by the stamina reference value recovery amount ΔS1u, sets the increased stamina recovery reference value S1 in the character information Info (S526), and then ends the stamina recovery reference value setting process. Specifically, in step S526, the state management unit 113 adds the stamina reference value recovery amount ΔS1u to the stamina recovery reference value S1 stored in the character information Info, thereby increasing the stamina recovery reference value S1 stored in the character information Info up to the stamina recovery upper limit value S2. Here, the stamina reference value recovery amount ΔS1u is the stamina reference value recovery amount uS1-I of the item consumed in the generated event, or the recovery amount of the stamina recovery reference value S1 resulting from lodging or treatment.

[0134] As shown in FIG. 17, if the result of the judgment in step S522 is negative, the status management unit 113 judges whether the period during which the stamina recovery reference value S1 and the stamina recovery upper limit value S2 satisfy the relationship "S1=S2" is longer than a predetermined time (S528). Furthermore, if the result of the determination in step S524 is negative, or if the result of the determination in step S528 is positive, the state management unit 113 determines whether or not the character C is present on the virtual field Fd (S530).

[0135] If the result of the judgment in step S530 is positive, the status management unit 113 reduces the stamina recovery reference value S1 by the stamina reference value reduction amount ΔS1d, sets the stamina recovery reference value S1 after the reduction in the character information Info (S532), and then terminates the stamina recovery reference value setting process. Specifically, in step S532, the state management unit 113 subtracts the stamina reference value decrease amount ΔS1d from the stamina recovery reference value S1 stored in the character information Info, thereby decreasing the stamina recovery reference value S1 stored in the character information Info, with a lower limit value of, for example, "0." However, the lower limit value of the stamina recovery reference value S1 may be a value greater than "0." In this embodiment, the stamina recovery reference value S1 decreases over time even when the character C is in a normal state. For this reason, in this embodiment, the state management unit 113 calculates the stamina reference value decrease amount ΔS1d as the sum of the stamina reference value decrease amount dS1-B corresponding to the abnormal state in which the character C is in, and the stamina reference value decrease amount dS1-T, which is the decrease amount of the stamina recovery reference value S1 per unit time ΔT (dS1-T is a real number that satisfies dS1-T>0). However, the present invention is not limited to this aspect, and the stamina reference value decrease amount ΔS1d only needs to include at least the stamina reference value decrease amount dS1-T.

[0136] Furthermore, if the result of the determination in step S528 or S530 is negative, the state management unit 113 ends the stamina recovery reference value setting process.

[0137] In this embodiment, the status management unit 113 performs the processing of step S530 in the stamina recovery reference value setting process, but the present invention is not limited to such an aspect, and the status management unit 113 does not have to execute the processing of step S530 in the stamina recovery reference value setting process.

[0138] In addition, in this embodiment, the stamina reference value decrement dS1-T is not taken into consideration when increasing the stamina recovery reference value S1 in step S526, but the present invention is not limited to such an embodiment, and the stamina reference value decrement dS1-T may be taken into consideration when increasing the stamina recovery reference value S1 in step S526. In this case, the stamina reference value recovery amount ΔS1u is the value obtained by subtracting the stamina reference value decrement dS1-T from the stamina reference value recovery amount uS1-I of the item consumed in the event that occurred, or the recovery amount of the stamina recovery reference value S1 resulting from lodging or treatment.

[0139] As shown in FIG. 17, after the stamina recovery reference value setting process in step S520 is completed, the state management unit 113 executes a stamina value setting process (S540).

[0140] In the stamina value setting process, the state management unit 113 first determines whether or not the character C is present on the virtual field Fd (S542).

[0141] If the result of the determination in step S542 is positive, the state management unit 113 determines whether or not the character C has performed a predetermined action with a consumed stamina value dSP-A equal to or greater than a predetermined reference value since the initialization process (S544). Here, the predetermined reference value is a positive real number. For example, if the predetermined reference value is set to "1", in the example shown in FIG. 10, the actions "running" and "attacking with a sword" correspond to "predetermined actions". Specifically, in step S544, the status management unit 113 determines whether the action ID of the character information Info is set to either an action ID corresponding to an action in which the consumed stamina value dSP-A is less than a predetermined reference value, or “Null,” which indicates that the character C is not performing an action. In this embodiment, the condition that a predetermined operation is not being performed is an example of a "predetermined operating condition."

[0142] If the result of the determination in step S544 is positive, the state management unit 113 determines whether or not the stamina value SP and the stamina recovery reference value S1 satisfy the relationship "SP≦S1" (S546).

[0143] If the result of the judgment in step S546 is positive, the status management unit 113 increases the stamina value SP by the stamina value recovery amount ΔSPu, sets the increased stamina value SP in the character information Info (S548), and then terminates the stamina value setting process. Specifically, in step S548, the status management unit 113 adds the stamina value recovery amount ΔSPu to the stamina value SP stored in the character information Info, thereby increasing the stamina value SP stored in the character information Info up to the stamina recovery reference value S1. In this embodiment, the state management unit 113 sets the stamina value recovery amount ΔSPu to the stamina value recovery amount uSP-T, which is the recovery amount of the stamina value SP per unit time ΔT. However, the state management unit 113 may calculate the stamina value recovery amount ΔSPu as a value obtained by multiplying the stamina value recovery amount uSP-T by a coefficient that is set to increase according to the level of the character C.

[0144] Then, if the result of the judgment in step S544 is negative, or if the result of the judgment in step S546 is negative, the status management unit 113 reduces the stamina value SP by the stamina value reduction amount ΔSPd, sets the stamina value SP after the reduction in the character information Info (S552), and then terminates the stamina value setting process. Specifically, in step S552, the status management unit 113 subtracts the stamina value reduction amount ΔSPd from the stamina value SP stored in the character information Info, thereby reducing the stamina value SP stored in the character information Info, with "0" as the lower limit value. Here, the stamina value reduction amount ΔSPd is the consumed stamina value dSP-A of the action corresponding to the action ID stored in the character information Info, or the value obtained by subtracting the stamina recovery reference value S1 from the stamina value SP. That is, when the character C performs an action, the state management unit 113 reduces the stamina value SP of the character C by the consumed stamina value dSP-A consumed with the action. In addition, when the stamina value SP exceeds the stamina recovery reference value S1, the state management unit 113 reduces the stamina value SP by "SP-S1" so that the stamina value SP and the stamina recovery reference value S1 maintain the relationship "SP≦S1". In other words, the state management unit 113 determines the reduction amount of the stamina value SP in step S552 (stamina value reduction amount ΔSPd) according to the reduction amount of the stamina recovery reference value S1 in step S532 (stamina reference value reduction amount ΔS1d).

[0145] Furthermore, if the result of the determination in step S542 is negative, the state management unit 113 ends the stamina value setting process. In this embodiment, the state management unit 113 performs the processing of step S542 in the stamina value setting process, but the present invention is not limited to such an aspect, and the state management unit 113 may execute the processing of step S544 in the stamina value setting process without performing the processing of step S542.

[0146] [5. Examples of changes in character status] An example of the change in the state of character C will be described with reference to FIGS.

[0147] [5.1. Example of changes in character's physical strength] FIG. 18 is a diagram showing changes in the hit point image PH, which indicates the physical strength state of the character C, from time T0 to T8. In this figure, it is assumed that the interval between each of times T0 to T8 is unit time ΔT. Also, in this figure, it is assumed that at time T0, character C is in a normal state, and character C's hit points HP and hit point recovery reference value H1 have recovered to the point where they match the hit point recovery upper limit value H2. Also, in this figure, it is assumed that the "predetermined time" in step S428 is unit time ΔT.

[0148] In FIG. 18, it is assumed that character C receives damage between times T0 and T1. Therefore, character C's hit points HP are reduced by the hit point reduction amount ΔHPd (=damage amount dm) between times T0 and T1 (see step S456). On the other hand, the elapsed time from time T0 to time T1 at which the relationship "H1=H2" is satisfied is less than a predetermined time. Therefore, character C's hit point recovery reference value H1 does not change between times T0 and T1 (see step S428).

[0149] 18, it is assumed that there are no events or actions of character C between times T1 and T2 and between times T2 and T3. Therefore, between times T1 and T2 and between times T2 and T3, character C's hit points HP are recovered by hit point recovery amount ΔHPu (=uHP-T) (see step S452), and character C's hit point recovery reference value H1 is reduced by hit point reference value reduction amount ΔH1d (=dH1-T) (see step S432).

[0150] 18, it is assumed that at time T3, the hit points HP and the hit point recovery reference value H1 become equal, and between times T3 and T4, there are no events and no actions of character C. Therefore, between times T3 and T4, the hit point recovery reference value H1 of character C decreases by the hit point reference value decrease amount ΔH1d (=dH1-T) (see step S432), and the hit points HP of character C also decrease by the hit point decrease amount ΔHPd (=ΔH1d) in accordance with the decrease in the hit point recovery reference value H1 (see step S456).

[0151] In Fig. 18, it is assumed that character C consumes an item capable of recovering hit point recovery reference value H1 between times T4 and T5. Therefore, between times T4 and T5, character C's hit point recovery reference value H1 recovers by hit point reference value recovery amount ΔH1u (=uH1-I) (see step S426), and becomes equal to, for example, hit point recovery upper limit value H2. Also, between times T4 and T5, character C's hit points HP recover by hit point recovery amount ΔHPu (=uHP-T) (see step S452).

[0152] In Fig. 18, it is assumed that character C levels up between times T5 and T6. Therefore, between times T5 and T6, character C's hit point recovery upper limit H2 increases by the hit point upper limit increase amount ΔH2u (see step S404). Note that between times T5 and T6, character C's hit point recovery reference value H1 does not change (see step S428), and character C's hit points HP increase by the hit point recovery amount ΔHPu (=uHP-T) (see step S452).

[0153] 18, it is assumed that character C receives damage between times T6 and T7 and falls into an abnormal state in which the hit point recovery speed ratio dHP-B of character C is "0." Therefore, between times T6 and T7, character C's hit points HP decrease by the hit point decrease amount ΔHPd (= amount of damage dm) (see step S456), character C's hit point recovery reference value H1 decreases by the hit point reference value decrease amount ΔH1d (= dH1-T) (see step S432), and the pointer image PH1 changes from white to black.

[0154] 18, it is assumed that there is no event and no action of character C between times T7 and T8, and character C does not recover from the abnormal state. Therefore, between times T7 and T8, character C's hit points HP do not recover (see step S450), and character C's hit point recovery reference value H1 decreases by the hit point reference value decrease amount ΔH1d (=dH1-T+dH1-B) (see step S432).

[0155] [5.2. Example of character stamina fluctuation] FIG. 19 is a diagram showing changes in the stamina image PS indicating the stamina of the character C from time T0 to T8. In this diagram, it is assumed that the interval between each time T0 to T8 is unit time ΔT. Also, in this diagram, it is assumed that at time T0, character C is in a normal state, and that character C's stamina value SP and stamina recovery reference value S1 have recovered to the point where they match the stamina recovery upper limit value S2. Also, in this diagram, it is assumed that the "predetermined time" in step S528 is unit time ΔT.

[0156] In FIG. 19, it is assumed that character C executes the action of "running" between times T0 and T1. Therefore, character C's stamina value SP decreases by the stamina value decrease amount ΔSPd (=consumed stamina value dSP-A) between times T0 and T1 (see step S552). On the other hand, the elapsed time from time T0 to time T1, when the relationship "S1=S2" is satisfied, is less than a predetermined time. Therefore, character C's stamina recovery reference value S1 does not change between times T0 and T1 (see step S528).

[0157] 19, it is assumed that there are no events or actions of character C between times T1 and T2 and between times T2 and T3. Therefore, between times T1 and T2 and between times T2 and T3, character C's stamina value SP recovers by the stamina value recovery amount ΔSPu (=uSP-T) (see step S548), and character C's stamina recovery reference value S1 decreases by the stamina reference value decrease amount ΔS1d (=dS1-T) (see step S532).

[0158] In Figure 19, it is assumed that at time T3, the stamina value SP and the stamina recovery reference value S1 become equal, and between times T3 and T4, there are no events or actions of character C. Therefore, between times T3 and T4, the stamina recovery reference value S1 of character C decreases by the stamina reference value decrease amount ΔS1d (= dS1 - T) (see step S532), and the stamina value SP of character C also decreases by the stamina value decrease amount ΔSPd (= ΔS1d) in accordance with the decrease in the stamina recovery reference value S1 (see step S552).

[0159] In FIG. 19, it is assumed that character C consumes an item capable of recovering stamina recovery reference value S1 between times T4 and T5. Therefore, between times T4 and T5, character C's stamina recovery reference value S1 recovers by stamina reference value recovery amount ΔS1u (=uS1-I) (see step S526), ​​and becomes equal to, for example, stamina recovery upper limit value S2. Also, between times T4 and T5, character C's stamina value SP recovers by stamina value recovery amount ΔSPu (=uSP-T) (see step S548).

[0160] In Figure 19, it is assumed that character C levels up between times T5 and T6. Therefore, between times T5 and T6, character C's stamina recovery upper limit S2 increases by the stamina upper limit increase amount ΔS2u (see step S504). Note that between times T5 and T6, character C's stamina recovery reference value S1 does not change (see step S528), and character C's stamina value SP recovers by the stamina value recovery amount ΔSPu (=uSP-T) (see step S548).

[0161] 19, it is assumed that character C executes the action of "running" between times T6 and T7, receives damage, and falls into an abnormal state. Therefore, between times T6 and T7, character C's stamina value SP decreases by the stamina value decrease amount ΔSPd (=consumed stamina value dSP-A) (see step S552), character C's stamina recovery reference value S1 decreases by the stamina reference value decrease amount ΔS1d (=dS1-T) (see step S532), and the pointer image PS1 changes from white to black.

[0162] 19, it is assumed that there is no event or action of character C between times T7 and T8, and character C does not recover from the abnormal state. Therefore, between times T7 and T8, character C's stamina value SP recovers by the stamina value recovery amount ΔSPu (=uSP-T) (see step S548), but character C's stamina recovery reference value S1 decreases by the stamina reference value decrease amount ΔS1d (=dS1-T+dS1-B) (see step S532).

[0163] [6. Conclusion of the embodiment] As described above, according to this embodiment, the hit points HP and the hit point recovery reference value H1 change over time. Therefore, according to this embodiment, compared to a case where either the hit points HP or the hit point recovery reference value H1 does not change over time, the change in the state of the character C is prevented from becoming monotonous, and the possibility that a certain game becomes monotonous can be reduced. Furthermore, according to this embodiment, the stamina value SP and the stamina recovery reference value S1 change over time. Therefore, according to this embodiment, the change in the state of the character C is prevented from becoming monotonous, compared to a case where either the stamina value SP or the stamina recovery reference value S1 does not change over time, and this makes it possible to reduce the possibility that a given game becomes monotonous.

[0164] Furthermore, according to this embodiment, two types of upper limits are set as upper limits for hit points HP: a hit point recovery reference value H1 and a hit point recovery upper limit value H2. This makes it possible to prevent the fluctuations in the status of character C from becoming monotonous, compared to a case in which only one of the hit point recovery reference value H1 or the hit point recovery upper limit value H2 is set as the upper limit for hit points HP. Furthermore, according to this embodiment, two types of upper limits are set for the stamina value SP: the stamina recovery reference value S1 and the stamina recovery upper limit value S2. This makes it possible to prevent the fluctuations in the status of character C from becoming monotonous, compared to a case in which the upper limit for the stamina value SP is set to only one of the stamina recovery reference value S1 or the stamina recovery upper limit value S2.

[0165] Furthermore, according to this embodiment, multiple values ​​representing the physical strength state of character C, such as hit points HP, hit point recovery reference value H1, and hit point recovery upper limit value H2, are displayed by a single hit point image PH, which enables the user of the game device 10 to easily and quickly grasp the physical strength state of character C, compared to a case in which multiple values ​​representing the physical strength state of character C are displayed by multiple images. Furthermore, according to this embodiment, multiple values ​​representing the stamina of character C, such as the stamina value SP, stamina recovery reference value S1, and stamina recovery upper limit value S2, are displayed by a single stamina image PS, which enables the user of the game device 10 to easily and quickly grasp the stamina of character C, compared to a case in which multiple values ​​representing the stamina of character C are displayed by multiple images.

[0166] Furthermore, according to this embodiment, the state of character C changes due to the consumption of items and the level-up of character C, etc., so that the change in the state of character C can be prevented from becoming monotonous.

[0167] Furthermore, according to this embodiment, the manner in which character C's status changes has a "normal state" and an "abnormal state," and therefore, compared to a case in which character C's status changes have only one type, it is possible to prevent the changes in character C's status from becoming monotonous.

[0168] [B. Modifications] Each of the above embodiments may be modified in various ways. Specific modified embodiments are exemplified below. Two or more embodiments arbitrarily selected from the following examples may be appropriately combined within a range that does not contradict each other. In the modified examples exemplified below, the elements whose actions and functions are equivalent to those of the embodiment will be appropriately omitted by using the symbols referenced in the above explanation.

[0169] [Variation 1] In the above-described embodiment, the hit points HP and the hit point recovery reference value H1 satisfy the relationship "HP≦H1", but the present invention is not limited to such an aspect, and the hit points HP and the hit point recovery reference value H1 may have the relationship "HP>H1" in a certain situation.

[0170] For example, in the hit point setting process according to the embodiment described above, in step S456, the status management unit 113 reduces the hit points HP to a value equal to or less than the hit point recovery reference value H1 so as to maintain the relationship "HP≦H1" between the hit points HP and the hit point recovery reference value H1 (see FIG. 16). In contrast, in the hit point setting process of this modified example, when the hit point recovery reference value H1 decreases in the hit point recovery reference value setting process, the hit points HP and the hit point recovery reference value H1 are allowed to have the relationship "HP>H1". More specifically, in the hit point setting process according to this modification, the state management unit 113 does not execute the process according to step S446. In addition, in the hit point setting process according to this modification, the state management unit 113 determines the hit point reduction amount ΔHPd based only on the damage amount dm in step S456, without considering the hit point reference value reduction amount ΔH1d calculated in step S432. That is, in this modification, the reduction of the hit point recovery reference value H1 in the hit point recovery reference value setting process does not affect the update of the hit points HP in the hit point setting process. Therefore, in this modification, even if the hit point recovery reference value H1 is reduced in the hit point recovery reference value setting process, the value of the hit points HP does not change in the hit point setting process.

[0171] In the hit point setting process according to this modification, the state management unit 113 can increase the hit points HP up to the hit point recovery reference value H1. In other words, when the hit points HP are increased by the hit point recovery amount ΔHPu in step S452, the state management unit 113 according to this modification maintains the relationship "HP≦H1". Therefore, when the hit points HP and the hit point recovery reference value H1 have the relationship "HP>H1" before the execution of the hit point setting process, the state management unit 113 according to this modification does not increase the hit points HP in step S452 of the hit point setting process.

[0172] 20 is a diagram showing an example of a change in the hit point image PH according to this modified example. In this diagram, it is assumed that the hit point recovery reference value H1 decreases by the hit point reference value decrease amount ΔH1d over time between times T0 and T3. 20, from time T0 to time T1, the hit points HP and the hit point recovery reference value H1 have a relationship of "HP≦H1." Therefore, the state management unit 113 according to this modified example increases the hit points HP by the hit point recovery amount ΔHPu as time passes. On the other hand, from time T1 to T3, the hit points HP and the hit point recovery reference value H1 have a relationship of "HP>H1." However, in this modified example, the decrease in the hit point recovery reference value H1 does not affect the update of the hit points HP. Therefore, the state management unit 113 according to this modified example does not change the hit points HP from time T1 to T3, and maintains the state in which the hit points HP exceed the hit point recovery reference value H1, while decreasing the hit point recovery reference value H1 by the hit point reference value decrease amount ΔH1d at a time.

[0173] [Variation 2] In the above-described embodiment and variant examples, the stamina value SP and the stamina recovery reference value S1 satisfy the relationship "SP≦S1", but the present invention is not limited to such an aspect, and the stamina value SP and the stamina recovery reference value S1 may have the relationship "SP>S1" in a certain situation.

[0174] For example, in the stamina value setting process of this modified example, when the stamina recovery reference value S1 decreases in the stamina recovery reference value setting process, the stamina value SP and the stamina recovery reference value S1 may be allowed to have a relationship of "SP>S1". More specifically, in the stamina value setting process according to this modified example, the state management unit 113 does not execute the process according to step S546. In addition, in the stamina value setting process according to this modified example, in step S552, the state management unit 113 determines the stamina value decrease amount ΔSPd based only on the consumed stamina value dSP-A, without taking into account the stamina reference value decrease amount ΔS1d calculated in step S532. In other words, in this modified example, the decrease in the stamina recovery reference value S1 in the stamina recovery reference value setting process does not affect the update of the stamina value SP in the stamina value setting process. Therefore, in this modified example, even if the stamina recovery reference value S1 decreases in the stamina recovery reference value setting process, the value of the stamina value SP does not change in the stamina value setting process.

[0175] In the stamina value setting process according to this modified example, the status management unit 113 can increase the stamina value SP up to the stamina recovery reference value S1. In other words, when the status management unit 113 according to this modified example increases the stamina value SP by the stamina value recovery amount ΔSPu in step S548, the status management unit 113 according to this modified example maintains the relationship "SP≦S1." Therefore, if the stamina value SP and the stamina recovery reference value S1 have the relationship "SP>S1" before the stamina value setting process is executed, the status management unit 113 according to this modified example does not increase the stamina value SP in step S548 of the stamina value setting process.

[0176] [Variation 3] In the above-described embodiment and variant examples, an increase in the hit point recovery reference value H1 in the hit point recovery reference value setting process does not affect the update of hit points HP in the hit point setting process, but the present invention is not limited to such an aspect, and hit points HP may be increased in the hit point setting process based on an increase in the hit point recovery reference value H1 in the hit point recovery reference value setting process. It should be noted that this modified example assumes a case in which the hit points HP and the hit point recovery reference value H1 are allowed to have the relationship "HP>H1", as in the above-mentioned modified example 1.

[0177] For example, in the case where the hit points HP and the hit point recovery reference value H1 have a relationship of "HP>H1" and the hit point recovery reference value H1 is increased by the hit point recovery reference value setting process, if the increased hit point recovery reference value H1 exceeds the hit points HP, the state management unit 113 according to this modified example may increase the hit points HP in the hit point setting process so that the hit points HP become equal to the hit point recovery reference value H1 (first aspect). In other words, the state management unit 113 according to the first aspect of this modified example sets the hit point recovery amount ΔHPu to a value obtained by subtracting the hit points HP from the hit point recovery reference value H1 in S452 of the hit point setting process.

[0178] 21 is a diagram showing an example of a change in the hit point image PH in the first mode of this modified example. In this figure, it is assumed that the hit point recovery reference value H1 recovers by the hit point reference value recovery amount ΔH1u between times T0 and T2. In the example shown in FIG. 21, the hit points HP and the hit point recovery reference value H1 maintain the relationship "HP>H1" from time T0 to T1. Therefore, the state management unit 113 according to this modification does not change the hit points HP from time T0 to T1. In contrast, the hit points HP and the hit point recovery reference value H1 change to the relationship "HP≦H1" from time T1 to T2. Therefore, the state management unit 113 according to this modification increases the hit points HP so that the hit points HP become equal to the hit point recovery reference value H1 from time T1 to T2. In other words, the state management unit 113 according to this modification sets the hit point recovery amount ΔHPu to "H1-HP" from time T1 to T2, and then increases the hit points HP by the hit point recovery amount ΔHPu.

[0179] Also, for example, in the case where the hit points HP and the hit point recovery reference value H1 have a relationship of "HP>H1" and the hit point recovery reference value H1 is increased by the hit point reference value recovery amount ΔH1u in the hit point setting process, the state management unit 113 according to this modified example may also increase the hit points HP by the hit point reference value recovery amount ΔH1u in the hit point setting process (second aspect). In other words, the state management unit 113 according to the second aspect of this modified example sets the hit point recovery amount ΔHPu to a value equal to the hit point reference value recovery amount ΔH1u in S452 of the hit point setting process.

[0180] 22 is a diagram showing an example of a change in the hit point image PH in the second mode of this modified example. In this diagram, it is assumed that the hit point recovery reference value H1 recovers by the hit point reference value recovery amount ΔH1u between times T0 and T1. In the example shown in Fig. 22, from time T0 to T1, the hit points HP and the hit point recovery reference value H1 maintain the relationship of "HP>H1". Then, from time T0 to T1, the hit point recovery reference value H1 increases by the hit point reference value recovery amount ΔH1u. Therefore, the state management unit 113 according to this modification sets the increase amount of the hit points HP (hit point recovery amount ΔHPu) to a value equal to the hit point reference value recovery amount ΔH1u from time T0 to T1, and then increases the hit points HP by the hit point recovery amount ΔHPu.

[0181] [Variation 4] In the above-described embodiment and variant examples, an increase in the stamina recovery reference value S1 in the stamina recovery reference value setting process does not affect the updating of the stamina value SP in the stamina value setting process, but the present invention is not limited to such an aspect, and the stamina value SP may be increased in the stamina value setting process based on an increase in the stamina recovery reference value S1 in the stamina recovery reference value setting process. It should be noted that this modified example assumes a case in which the stamina value SP and the stamina recovery reference value S1 are allowed to have the relationship "SP>S1", as in the above-mentioned modified example 2.

[0182] For example, in the case where the stamina value SP and the stamina recovery reference value S1 have a relationship of "SP>S1" and increasing the stamina recovery reference value S1 through the stamina recovery reference value setting process causes the increased stamina recovery reference value S1 to exceed the stamina value SP, the state management unit 113 in this modified example may increase the stamina value SP in the stamina value setting process so that the stamina value SP becomes equal to the stamina recovery reference value S1. In other words, in S548 of the stamina value setting process, the state management unit 113 in this modified example sets the stamina value recovery amount ΔSPu to a value obtained by subtracting the stamina value SP from the stamina recovery reference value S1.

[0183] Also, for example, when the stamina value SP and the stamina recovery reference value S1 have a relationship of "SP>S1" and the stamina recovery reference value S1 is increased by the stamina reference value recovery amount ΔS1u in the stamina recovery reference value setting process, the status management unit 113 in this modified example may also increase the stamina value SP by the stamina reference value recovery amount ΔS1u in the stamina value setting process. In other words, the status management unit 113 in this modified example sets the stamina value recovery amount ΔSPu to a value equal to the stamina reference value recovery amount ΔS1u in S548 of the stamina value setting process.

[0184] [Variation 5] In the above-described embodiment and modified examples, the processing of steps S100 to S132 shown in FIG. 7, which is the processing for executing a predetermined game, is repeated every unit time ΔT, but the present invention is not limited to such an aspect, and the processing cycle for the processing for executing a predetermined game may vary.

[0185] [Variation 6] In the above-described embodiment and variant examples, the processing for executing a specific game shown in FIG. 7 is executed in the following order: initialization processing → character movement processing → event processing → hit point update processing → stamina value update processing. However, the present invention is not limited to such an embodiment, and the order in which these processes are executed is arbitrary. In the above-described embodiment and modified example, two or more of the initialization process, character movement process, event process, hit point update process, and stamina value update process are not executed in parallel, but the present invention is not limited to such an embodiment, and two or more of these processes may be executed in parallel. In this case, the processing cycles of the initialization process, character movement process, event process, hit point update process, and stamina value update process may be different from each other.

[0186] [Variation 7] In the above-described embodiment and modified examples, the predetermined game is executed on the game device 10, but the present invention is not limited to such an aspect, and the predetermined game may be executed on a component other than the game device 10. 23 is an explanatory diagram showing an overview of a game system 1A according to this modified example. The game system 1A includes a plurality of terminal devices 70, a plurality of display devices 30 provided corresponding to the plurality of terminal devices 70, and a server device 50A. The server device 50A can execute a predetermined game and can communicate with each of the terminal devices 70 via a network NW. FIG. 24 is a functional block diagram showing an example of the configuration of the server device 50A according to this modification. As shown in FIG. 24, the server device 50A includes a control unit 110A, a storage unit 120, and a communication unit 130. The control unit 110A is configured similarly to the control unit 110 shown in FIG. 2, except that the control unit 110A includes a display information generation unit 116 instead of the display control unit 115. The display information generation unit 116 generates display information related to a predetermined game, and supplies the generated display information to the terminal device 70 via the communication unit 130. The terminal device 70 controls the display unit 31 so that an image based on the display information supplied from the server device 50A is displayed on the display unit 31 of the display device 30.

[0187] [C. Notes] From the above description, the present invention can be understood, for example, as follows: In order to facilitate understanding of each aspect, reference symbols in the drawings are conveniently written in parentheses below, but this is not intended to limit the present invention to the illustrated aspects.

[0188] [Appendix 1] A program for a game device according to one embodiment of the present invention is a program for a game device having a processor, the program causing the processor to function as an operation execution unit that causes a game character to operate in response to a user's operation and a management unit that manages the state of the character, the management unit increasing a parameter value indicating the goodness of the character's state over time up to a first upper limit value, and decreasing the first upper limit value over time.

[0189] According to this embodiment, the parameter value indicating the goodness of the character's condition is increased over time, and the first upper limit value, which is the upper limit value for the recovery of the parameter value, is decreased over time. Therefore, it is possible to reduce the possibility that the change in the character's condition becomes monotonous, compared to a case where the parameter value or the first upper limit value does not change over time.

[0190] In the above embodiment, the "character" refers to a game element that is the target of a user's operation. However, the "character" may be any game element that the user uses to progress through the game, and may be, for example, a game element that operates autonomously based on a policy specified by the user's operation. "A character's state" refers to, for example, a state regarding the character's ability to continue playing the game, or a state regarding limitations on the character's actions. Here, "a character's state regarding the character's ability to continue playing the game" refers to, for example, a character's physical state, or a character's mental state. Also, "a character's state regarding limitations on its actions" refers to, for example, a character's stamina, or a character's fatigue state. In the above embodiment, the "parameter value indicating the good condition of the character" is, for example, a value indicating the degree of possibility of the character continuing the game, a value indicating the degree of restriction on the character's actions, or a value indicating the degree of ease of the character's progress in the game. Here, the "value indicating the degree of possibility of the character continuing the game" is, for example, a stamina value (hit points) indicating the remaining stamina of the character, or a value indicating the remaining mental margin of the character. Also, the "value indicating the degree of restriction on the character's actions" is, for example, a value indicating the remaining stamina (endurance) of the character. Furthermore, "a value indicating the degree of ease with which a character can progress through the game" is, for example, a value indicating the character's survival ability, combat ability, or the difficulty of the character being detected by an enemy, etc. In other words, "a character being in good condition" is a concept that includes, for example, a high possibility of the character continuing the game, few restrictions on the character's actions, and the ease of progressing through the game with the character.

[0191] [Appendix 2] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendix 1, characterized in that the management unit increases the first upper limit value up to a second upper limit value when the character consumes a predetermined game element. According to this embodiment, for example, compared to a case in which the first upper limit value does not increase, it is possible to reduce the possibility that the change in the character's state will become monotonous.

[0192] In the above embodiment, the "predetermined game element" is a game element for improving the character's condition to a good condition, such as an item for improving the character's condition, or points consumed when using a special ability for improving the character's condition, or a fee for using a facility used in improving the character's condition. Here, the "item for improving the character's condition" is, for example, food, drink, medicine, etc. Furthermore, the "special ability for improving the character's condition" is, for example, the ability to use magic or the ability to perform medical procedures, etc. Furthermore, the "facility used in improving the character's condition" is, for example, accommodation facilities, medical facilities, etc. In addition, in the above aspect, "consuming a game element" means rendering the game element temporarily or permanently unusable as a result of using the game element, and may include concepts such as, for example, causing the game element to disappear by using the game element, and rendering the game element in a state in which the effect that occurs when using the game element does not occur as a result of using the game element.

[0193] [Appendix 3] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendix 1 or 2, characterized in that the management unit reduces the first upper limit value over time, up to a value smaller than the parameter value. According to this embodiment, it is possible to prevent the parameter value from decreasing over time, thereby preventing the difficulty level of the game provided by the game device from becoming higher than necessary.

[0194] [Appendix 4] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendix 3, characterized in that the management unit increases the parameter value over time when the first upper limit value exceeds the parameter value, and stops the increase of the parameter value over time when the first upper limit value falls below the parameter value. According to this aspect, the behavior of the parameter value is changed depending on the magnitude relationship between the parameter value and the first upper limit value, so it is possible to reduce the possibility that the fluctuation in the character's state will become monotonous.

[0195] [Appendix 5] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendices 1 to 4, characterized in that, when the movement of the character satisfies a predetermined movement condition, the management unit increases the parameter value over time, up to the first upper limit value. According to this aspect, it is possible to reduce the likelihood that fluctuations in the character's state will become monotonous, compared to, for example, a case in which a parameter value increases regardless of whether the character's action satisfies a specified action condition.

[0196] In the above embodiment, the "predetermined motion condition" is, for example, a condition that the motion is stopped, or a condition that the motion is a gentle and calm motion, not a strenuous motion that consumes a lot of physical strength, such as sprinting or fighting, etc. In other words, in the above embodiment, "the motion of the character satisfies the predetermined motion condition" means that the motion of the character is not a motion that hinders the improvement of the character's condition.

[0197] [Appendix 6] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendix 2, characterized in that the second upper limit value increases when a predetermined game condition is satisfied in the game played by the user. According to this embodiment, for example, compared to a case in which the second upper limit value is not increased, it is possible to reduce the possibility that the change in the character's state will become monotonous.

[0198] In the above embodiment, the "predetermined game condition" is, for example, a condition for achieving a predetermined goal in the game. Here, the "predetermined goal related to the game" is, for example, a user controlling a character in the game to defeat a predetermined enemy, a character controlled by the user acquiring a predetermined skill, a character controlled by the user acquiring a predetermined item, a user playing the game for a predetermined time, or a user acquiring a predetermined score in the game.

[0199] [Appendix 7] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendices 1 to 6, characterized in that the management unit reduces the parameter value in accordance with damage suffered by the character in the game. According to this aspect, it is possible to reduce the likelihood that fluctuations in the character's state will become monotonous, compared to a case in which the parameter value does not decrease regardless of whether the character receives damage, for example.

[0200] In the above embodiment, "damage" refers to, for example, damage caused by an attack from an enemy, damage caused by an accident, or damage caused by an illness.

[0201] [Appendix 8] A game device program according to another aspect of the present invention is a game device program as described in Appendix 7, characterized in that when the parameter value reaches a predetermined lower limit value, the user is unable to continue playing the game. According to this aspect, in order to continue the game, the user is required to play the game while taking into account fluctuations in the parameter values, thereby making the game more interesting compared to, for example, a case in which the game is continued regardless of fluctuations in the parameter values.

[0202] [Appendix 9] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendices 1 to 6, characterized in that the management unit decreases the parameter value when the action execution unit causes the character to perform a predetermined action. According to this embodiment, for example, compared to a case where the parameter value does not decrease regardless of the type of action of the character, it is possible to reduce the possibility that the fluctuation in the character's state will become monotonous.

[0203] In the above embodiment, the "predetermined movement" is, for example, a strenuous movement that consumes a lot of physical strength, such as sprinting (running) or fighting (attacking).

[0204] [Appendix 10] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendix 9, characterized in that the character becomes inoperable when the parameter value reaches a predetermined lower limit value. According to this aspect, in order to prevent the character from becoming unable to move, the user is required to play the game while taking into consideration fluctuations in parameter values, making the game more interesting than, for example, a case in which the character is able to move freely regardless of fluctuations in parameter values.

[0205] [Appendix 11] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendix 9 or 10, characterized in that the character's specified action is restricted when the parameter value falls below a specified threshold value. According to this aspect, in order to prevent the character's movements from being restricted, the user is required to play the game while taking into consideration fluctuations in parameter values, making the game more interesting than, for example, a case in which the character is able to move freely regardless of fluctuations in parameter values.

[0206] [Appendix 12] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendices 1 to 11, characterized in that the character enters an abnormal state when the character receives a specified damage, and the management unit limits the increase in the parameter value over time when the character is in the abnormal state. According to this aspect, when a character is in an abnormal state, the increase in the parameter value is limited, making it possible to reduce the likelihood that the character's state will fluctuate monotonically, compared to, for example, a case in which the parameter value increases over time regardless of whether the character is in an abnormal state or not.

[0207] In the above embodiment, it is assumed that the state of the character is distinguished between, for example, an "abnormal state" and a "normal state". Here, an "abnormal state" refers to an abnormal state in which the state of the character changes, for example, a state in which the character is seriously injured or ill, and the state of the character is not expected to improve over time. In addition, a "normal state" refers to an abnormal state in which the state of the character changes, for example, a state in which the character is healthy and not seriously injured or ill, and the state of the character is expected to improve over time. In the above embodiment, the "predetermined damage" refers to serious damage, such as damage caused by an enemy attack, damage caused by an accident, or damage caused by an illness.

[0208] [Appendix 13] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendices 1 to 12, characterized in that the character enters an abnormal state when the character suffers a predetermined damage, and the management unit increases the amount of decrease per unit time of the first upper limit value when the character is in the abnormal state, compared to when the character is not in the abnormal state. According to this aspect, when the character is in an abnormal state, the rate at which the first upper limit value decreases increases, making it possible to reduce the likelihood that the fluctuations in the character's state will become monotonous, compared to, for example, a case in which the rate at which the first upper limit value decreases is constant regardless of whether the character is in an abnormal state or not.

[0209] [Appendix 14] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendix 12 or 13, comprising a display control unit that causes a character image representing the character and a status display image indicating the status of the character to be displayed on a display unit, and the display control unit displays the status display image when the character is in an abnormal state and the status display image when the character is not in an abnormal state as different images. According to this aspect, the user can grasp whether the character is in an abnormal state or not, and therefore the user can easily understand the character's state even when the fluctuations in the character's state become complex.

[0210] [Appendix 15] A program for a game device according to another aspect of the present invention is a program for a game device as described in Appendix 2 or 6, characterized in that when the first upper limit value is increased to the second upper limit value, the management unit stops the decrease of the first upper limit value over time for a predetermined period of time. According to this aspect, the game can be progressed advantageously at the specified time when the decrease in the first upper limit value over time stops, making the game more interesting than, for example, a case in which the first upper limit value is constantly decreasing.

[0211] [Appendix 16] A game device program according to another aspect of the present invention is a game device program as described in Appendices 1 to 15, characterized in that the management unit determines the amount of increase in the parameter value per unit time based on the satisfaction status of predetermined game conditions in the game played by the user. According to this aspect, the rate at which the parameter value increases over time varies based on the satisfaction of certain game conditions, making it possible to reduce the likelihood of the character's state changing monotonously, compared to, for example, a case in which the rate at which the parameter value increases is constant.

[0212] [Appendix 17] A game device according to one embodiment of the present invention comprises an operation execution unit that causes a game character to act in response to a user's operation, and a management unit that manages the state of the character, wherein the management unit increases a parameter value indicating the goodness of the character's state over time up to a first upper limit value, and decreases the first upper limit value over time. According to this embodiment, for example, it is possible to reduce the possibility that the change in the character's state will become monotonous, compared to a case in which the parameter value or the first upper limit value does not change over time.

[0213] [Appendix 18] A game device according to another aspect of the present invention is a program for a game device having a processor, which causes the processor to function as an operation execution unit that causes a game character to operate in response to a user's operation and as a management unit that manages the state of the character, and which is characterized in that, when a parameter value indicating the goodness of the character's state is smaller than a first upper limit value that is the upper limit of the parameter value, the management unit increases the parameter value over time up to a limit of the first upper limit value and decreases the first upper limit value over time. According to this embodiment, for example, it is possible to reduce the possibility that the change in the character's state will become monotonous, compared to a case in which the parameter value or the first upper limit value does not change over time. [Explanation of symbols]

[0214] 1...game system, 10...game device, 30...display device, 50...server device, 110...control unit, 111...game control unit, 112...action execution unit, 113...status management unit, 114...operation information acquisition unit, 115...display control unit, 120...memory unit, 130...communication unit, 140...operation unit, 150...information reading unit, 1000...processor.

Claims

1. A program for a game device having a processor, The processor, an action execution unit that causes a game character to act in response to a user's operation; A management unit for managing the state of the character; and make it work. The management unit increasing a parameter value indicating the goodness of the character's condition over time up to a first upper limit value; The first upper limit value is decreased over time. A program for a game device.

2. The management unit When the character consumes a predetermined game element, The first upper limit value is increased up to a second upper limit value.

2. The game device program according to claim 1.

3. The management unit The first upper limit value is decreased over time up to a value smaller than the parameter value.

3. The game device according to claim 1, wherein the game device executes a program for executing the game device.

4. The management unit When the first upper limit value is greater than the parameter value, increasing the parameter value over time; When the first upper limit value is lower than the parameter value, Stopping the increase in the parameter value over time.

4. The game device program according to claim 3.

5. The management unit When the action of the character satisfies a predetermined action condition, The parameter value is increased over time up to the first upper limit value.

5. The game device program according to claim 1, wherein the program is a program for executing a game on a computer.

6. The second upper limit value is When a predetermined game condition is satisfied in the game played by the user, the bonus point increases.

3. The game device program according to claim 2.

7. The management unit decreasing the parameter value in accordance with damage sustained by the character in the game; 7. The game device program according to claim 1, wherein the game device program includes: a game program for playing a game on a computer;

8. When the parameter value reaches a predetermined lower limit, the user is prevented from continuing the game.

8. The game device program according to claim 7.

9. The management unit When the action execution unit causes the character to perform a predetermined action, the parameter value is decreased.

7. The game device program according to claim 1, wherein the game device program includes: a game program for playing a game on a computer;

10. The character is: When the parameter value reaches a predetermined lower limit, the device becomes inoperable.

10. The game device program according to claim 9.

11. The character is: When the parameter value becomes equal to or less than a predetermined threshold, the predetermined operation is restricted.

11. The game device program according to claim 9 or 10.

12. The character is: When the character receives a certain amount of damage, it enters an abnormal state. The management unit When the character is in an abnormal state, limiting the increase in the parameter value over time.

12. The game device program according to claim 1, wherein the program is a program for executing a game on a computer.

13. The character is: When the character receives a certain amount of damage, it enters an abnormal state. The management unit If the character is in an abnormal state, Compared to when the character is not in an abnormal state, increasing the amount of decrease per unit time of the first upper limit value; 13. A program for a game device according to claim 1.

14. a display control unit that causes a character image showing the character and a status display image showing a status of the character to be displayed on a display unit; Equipped with The display control unit is the state display image when the character is in an abnormal state; The state display image when the character is not in an abnormal state. As different pictures display, 14. A program for a game device according to claim 12 or 13.

15. The management unit When the first upper limit value is increased to the second upper limit value, The decrease of the first upper limit value over time is stopped for a predetermined period of time.

7. A program for a game device according to claim 2 or 6.

16. The management unit Based on the satisfaction status of a predetermined game condition in the game played by the user, determining an increase in the parameter value per unit time; 16. A program for a game device according to claim 1.

17. an action execution unit that causes a game character to act in response to a user's operation; A management unit for managing the state of the character; Equipped with The management unit increasing a parameter value indicating the goodness of the character's condition over time up to a first upper limit value; The first upper limit value is decreased over time. A game device comprising:

Images