U.S. Pat. No. 8,914,136

DETAILED DESCRIPTION OF THE INVENTION

Then, a best mode for carrying out the present invention will be described with reference to the drawings.

Game Apparatus

FIG. 1is a diagram showing the use of a game apparatus according to the present invention.FIG. 2is a block diagram showing the game apparatus ofFIG. 1.FIG. 3is a diagram showing a game screen of the game apparatus ofFIG. 1.

InFIG. 1, the game apparatus2000is connected with operation input means such as controllers2100,2110, and2120and a keyboard2300, and a display means such as a TV monitor2200.

As shown inFIGS. 1 and 3, the display means2200displays images of objects that move in the virtual space of the game (for example, player characters FC1to FC3and enemy characters EC1to EC4), images of gauges that indicate vitality parameters of the respective characters (for example, gauges FG1to FG3of the player characters FC1to FC3and gauges EG1to EG4of the enemy characters EC1to EC4), a hero gauge HG that indicates an advantage of a player character, an image of a radar LD that shows object layout, etc.

The player characters FC1, FC2, and FC3operate based on input signals of any of the controllers2100,2110, and2120. The player characters FC1, FC2, and FC3may be configured to operate based on the input signals of the controllers2100,2110, and2120, respectively, so that a plurality (three) of players independently operate the player characters FC1, FC2, and FC3.

The player characters FC1, FC2, and FC3operate based on the input signals from the controllers2100,2110, and2120, or based on a predetermined routine. The control is performed by a CPU1000, which will be described later as related withFIG. 2.

In the meantime, the enemy characters EC1to EC4operate based on a predetermined routine. The control is performed by the CPU1000.

The game executed by the CPU1000proceeds with offense and defense between the player characters FC1, FC2, and FC3vs. the enemy characters EC1to EC4.

The player characters FC1to FC3and the enemy characters EC1to EC4are displayed by cooperation of the CPU1000with a system memory1020, a video display processor1030, and a graphic memory1040, which will be described later as related withFIG. 2.

InFIG. 2, the game apparatus2000includes the CPU1000(control means) which controls the entire apparatus, a boot ROM1010which contains a program for starting up the game apparatus2000, and a system memory1020which stores a game control program to be executed by the CPU1000and values and data of/on parameters, damage, and the like to be described later.

The game apparatus2000includes a video processor1030which generates and controls images to be displayed, and a graphic memory1040which stores source images of images to be generated and the images generated. The video processor1030displays the generated images on the display unit2200.

The game apparatus2000includes an audio processor1070which generates sound and an audio memory1080which stores data on the sound to be generated. The audio processor1070generates a digital sound signal based on the data stored in the audio memory1080, and outputs the sound through speakers or a headphone (not shown).

The game apparatus2000includes a CD-ROM drive1090or the like as a storage device for program data etc. A game program and data stored in a recording medium are read by the storage device into the system memory1020, the graphic memory1040, and the audio memory1080.

The game apparatus2000includes a memory interface1130, and can read and write memory cards A and B which players have. This makes it possible to register each user's game score, the status of a suspended game, and the like.

The game apparatus2000is equipped with a modem1150through a communication interface1160. A plurality of game apparatuses2000can execute a network game over a network. The game apparatus2000can also acquire various types of information on a game, including the statistics of game scores, the ranking of players, and various events, from a server (not shown).

The game apparatus2000includes a controller interface1140. The controllers2100,2110,2120, and the like are connected to terminals1to4of the controller interface1140.

[Vitality Parameter Gauge]

Since the vitality parameter gauges FG1to FG3have the same configuration, the gauge FG1will be described as a representative. The gauge FG1shows, for example, a numerical value LPN that indicates a vitality parameter Lp (in the diagram,1000), a bar graph representation LPB of the same, a used weapon AM (in the diagram, machine gun), the number of bullets BN in the weapon (in the diagram, five left out of initial20), a numerical value LN of the level of capability values of the player character FC1including the vitality parameter Lp (in the diagram, Lv1), and a bar graph representation LB of experience points that the player character FC1has acquired in the game.

[Hero Gauge]

The hero gauge HG indicates the accumulation HGP of points that, for example, the player character FC1has acquired when the player character FC1makes a successful attack on any one of the enemy characters EC1to EC4. The accumulated points HGP are displayed in the form of a bar graph HB. Each time the accumulated points HGP reach 100% of a predetermined value (the representation of the bar graph HB reaches a predetermined length), one hero point HP is acquired and the accumulated points are cleared (in the diagram, eight hero points HP out of the upper limit of 12 points have been acquired). The effect of the hero points HP will be described later.

The player character FC1can make an attack by targeting at any one of the enemy characters EC1to EC4(which is carried out by an input signal based on an operation such as pressing a predetermined button on the controller). When the targeting is completed, there appears a target set indication TS which indicates which object is aimed at (in the diagram, the indication appears on the gauge EG1of the enemy character EC1).

The attack is carried out by an input signal based on an operation such as pressing a predetermined button on the controller, whereby shooting or the like is performed on the enemy character (for example, EC1).

[Damage]

When the player characters FC1to FC3attack the enemy characters EC1to EC4, the vitality parameters of the enemy characters EC1to EC4are damaged. When the player characters FG1to FG3are attacked by the enemy characters EC1to EC4, the vitality parameters of the player characters FG1to FG3are damaged.

The rules for damage are common to all the characters FC1to FC3and EC1to EC4. The following are the basic rules.

[Basic Rules for Damage]

(1) When there is no damage, the vitality parameter Lp is 100% of the upper limit setting of the character. As shown inFIG. 15(a), the bar graph representation LPB has a length that indicates 100% of the upper limit of the vitality parameter Lp. If the vitality parameter of the character falls to 0% of the upper limit, the character becomes an inoperative state (uncontrollable).
(2) Damages include ineffective damage (scratch damage) and effective damage (fixed damage). Whether a character-on-character attack results in scratch damage or fixed damage is basically determined based on an attack power parameter (degree of direct hit) of the weapon that is used for the attack.
(3) When an attack results in scratch damage, the amount of ineffective damage Ds based on the scratch damage is stored into the memory1020. The state where the amount of ineffective damage Ds is stored in the memory1020will hereinafter be referred to as there being scratch damage. As shown inFIG. 15(b), when there is scratch damage, the value of Ds is displayed in different color to indicate that there is as much scratch damage as Ds, without changing the length of the entire bar graph LPB.
(4) When an attack results in fixed damage, the vitality parameter Lp of the attacked character is decreased by the amount of effective damage Df based on the fixed damage. As shown inFIG. 15(c), when there is fixed damage, the values of Lp and Df are displayed in different colors to indicate that there is as much fixed damage as Df, without changing the length of the entire bar graph LPB.
(5) As shown inFIG. 15(d), when there are both scratch damage and fixed damage, the bar graph LPB shows the vitality parameter Lp, the amount of ineffective damage Ds, and the amount of effective damage Df in different colors in a predetermined layout, for example, in order from the left to indicate that there are both scratch damage and fixed damage.
(6) If there is fixed damage (FIG. 16(a)) and an attack results in new scratch damage, the amount of ineffective damage Ds based on the scratch damage is stored into the memory1020. As shown inFIG. 16(b), the vitality parameter Lp, the amount of ineffective damage Ds, and the amount of effective damage Df are displayed in different colors in order from the left to indicate that there are both scratch damage and fixed damage.
(7) If there is scratch damage (FIG. 17(a)) and an attack results in new fixed damage (FIG. 17(b)), the vitality parameter Lp of the attacked character is decreased by the total amount of damage (Df+Ds) including the amount of ineffective damage Ds stored in the memory1020and the effective damage Df. That is, the amount of damage (Df+Ds) is handled the same as the amount of a effective damage.

As shown inFIG. 17(c), the vitality parameter Lp and the amount of damage (Df+Ds) are displayed in different colors in order from the left. The part of the amount of ineffective damage Ds is converted into the same color as that of the amount of effective damage Df to indicate that there is the amount of effective damage (Df+Ds). Rendering the part of the amount of ineffective damage Ds in the bar graph LPB in the same color as with the amount of effective damage makes to be thought the scratch damage is converted into the fixed damage.

(8) When there is scratch damage, the amount of ineffective damage Ds stored in the memory1020is updated to one decreased by a predetermined amount as the time elapses. Here, the differently-colored part of the bar graph LPB resulting from the amount of ineffective damage Ds is restored to the normal vitality parameter Lp over time, whereby the vitality parameter LP can be presented to the player as if automatically recovering little by little. Even if the amount of ineffective damage Ds resulting from the occurrence of scratch damage reaches 100% of the vitality parameter Lp (all the Lp part of the bar graph LPB is in the color of Ds), the character will not become the inoperative state (uncontrollable) since the vitality parameter Lp is not 0% of the upper limit.
(9) The situation of there being fixed damage is where there is a predetermined time delay between when the fixed damage occurs and when the decrease of the vitality parameter Lp is fixed. Here, the delayed state is expressed by decreasing the length of the amount of effective damage Df (for the sake of convenience, Df+Ds will also be denoted as Df) displayed on the bar graph LPB over time. When the representation of the amount of effective damage Df on the bar graph LPB disappears, which means the disappearance of the delay, the decrease of the vitality parameter Lp is fixed. If the decrease-fixed vitality parameter Lp falls to 0% of the upper limit, the character becomes inoperable (uncontrollable). Since there is provided a delay before the decrease is fixed, it is possible for the player to make an operation such as pressing a predetermined button on the controller to input an input signal for restoring the vitality parameter Lp before fixed. Alternatively, the decrease of the vitality parameter Lp may be fixed simultaneously with the occurrence of fixed damage without providing a delay. In such a case, it is not possible for the player to prevent the character from becoming inoperable (uncontrollable) when fixed damage occurs and the vitality parameter Lp falls to 0% of the upper limit. This can create a sense of tension for the player.

As described above, it provides scratch damage which will not make the character inoperable (uncontrollable) and allows automatic recovery even if the vitality parameter Lp falls to 0% of the upper limit, and fixed damage which does not allow automatic recovery of the vitality parameter Lp. In addition, if a predetermined condition is satisfied, scratch damage is displayed to the player as if converted into fixed damage. Thus, the progress of the game diversifies.

(10) Aside from scratch damage and fixed damage, the damages to decrease the vitality parameter Lp include a scratch disabling attribute given by a predetermined attack.

(11) There is progressive damage processing of increasing scratch damage over time to decrease the vitality parameter Lp little by little.

Then, applications of the foregoing basic rules and other rules of the game will be described as related to an embodiment of the game control program according to the present invention.

[Game Control Program]

FIG. 4is a flowchart showing offense and defense processing according to the embodiment of the game control program to be executed by the game apparatus ofFIG. 1.FIG. 5is a flowchart showing the damage setting processing in the processing ofFIG. 4.FIG. 6is a flowchart showing the fixed damage setting processing in the processing ofFIG. 5.FIG. 7is a flowchart showing the scratch damage setting processing in the processing ofFIG. 5.FIG. 8is a flowchart showing the scratch disabling attribute processing in the processing ofFIG. 5.FIG. 9is a flowchart showing the damage progression and recovery processing in the processing ofFIG. 4.FIG. 10is a flowchart showing the fixed damage processing in the processing ofFIG. 9.FIG. 11is a flowchart showing the progressive damage processing in the processing ofFIG. 9.FIG. 12is a flowchart showing the scratch recovery processing in the processing ofFIG. 9.FIG. 13is a flowchart showing the hero gauge processing in the processing ofFIG. 4.FIG. 14is a flowchart showing the item-based damage recovery processing in the processing ofFIG. 9.

InFIG. 4, offense and defense between the virtual player characters FC1to FC3vs. enemy characters EC1to EC4in the game are performed by CPU1000, which is a control means, being executed the following steps.

Step S401: Initially, the CPU1000determines whether there is any offense and defense-related input signal (one that causes a character action such as a move, attack, and guard) from the operation input means2100,2110,2120, and2300. If there is an offense and defense-related input signal (hereinafter, referred to simply as an input signal), the CPU1000proceeds to step S402. If there is no input signal, the CPU1000proceeds to step S408.

If there is an input signal, the CPU1000processes that causes damage or the like will be performed since the player is making some kind of offense and defense-related operation. If there is no input signal, which is considered to be a standby state, the CPU1000suspends the processing of offense and defense in the game and the processing related to increase or decrease the vitality parameter. That gives time composure to the players.

Step S402: The CPU1000operates the player characters FC1to FC3based on the input signal or based on a predetermined routine of the game control program. The CPU1000then proceeds to step S403.

Step S403: The CPU1000operates the enemy characters EC1to EC4based on a predetermined routine of the game control program. The CPU1000then proceeds to step S404.

Step S404: The CPU1000performs damage setting processing for the case where an attack results in new damage, and it proceeds to step S405.

Step S405: The CPU1000performs damage progression and recovery processing of making existing damage progress or making a recovery, and it proceeds to step S406. Here, the progress of damage refers to the vitality parameter varying with a lapse of time after the occurrence of the damage.

Step S406: The CPU1000performs processing related to the hero gauge HG, and it proceeds to step S407.

Step S407: The CPU1000performs processing related to the hero points HP, and it simply ends processing.

Step S408: If it is determined at step S401that there is no input signal, the CPU1000determines whether or not processing of loading (reloading) a player character's weapon is in progress. If the reloading processing is in progress, the CPU1000proceeds to step S402without entering the standby state even if there is no input signal. If reloading processing is not in progress, the CPU1000ends the offense and defense processing.

The damage setting processing (step S404) ofFIG. 4is performed by the CPU1000executing the following steps. As shown inFIG. 5, the CPU1000handles all the player characters and enemy characters appearing in the offense and defense scene as a group of a total number imax of characters, assigns number i to each character, and sets damage in turn.

Step S501: Initially, the CPU1000sets the number i to zero in order to focus on the first character.

Step S502: The CPU1000determines whether or not an attack on the i-th character hits successfully. If the attack hits successfully, the CPU1000proceeds to step S503. If the attack fails, the CPU1000proceeds to step S507since there is no damage.

Step S503: The CPU1000refers to the degree of direct hit and determines which damage occurs, fixed damage, scratch damage, or damage of the scratch disabling attribute. If fixed damage occurs, the CPU1000proceeds to step S504. If scratch damage, the CPU1000proceeds to step S505. If the scratch disabling attribute, the CPU1000proceeds to step S506.

When a player character makes an attack on an enemy character, the degree of direct hit may be increased by an operation such as pressing a predetermined button continuously. This can increase the gaming flexibility.

Step S504: The CPU1000performs fixed damage setting processing to cause fixed damage, and proceeds to step S507.

Step S505: The CPU1000performs scratch damage setting processing to cause scratch damage, and it proceeds to step S507.

Step S506: The CPU1000performs scratch disabling attribute processing, and it proceeds to step S507.

Step S507: The CPU1000increments the character number i by “+1”, and it proceeds to step S508.

Step S508: The CPU1000determines whether or not the character number i reaches imax, that is, whether or not all the characters appearing in the offense and defense scene have been referred to. If all the characters have not been referred to yet, the CPU1000returns to step S503. If all the characters have been referred to, the CPU1000just ends processing.

InFIG. 6, the fixed damage setting processing (step S504) ofFIG. 5is performed by the CPU1000executing the following steps.

Step S601: Initially, the CPU1000determines whether or not the damaged character is in a hero mode. The hero mode is an advantage given to a player character that has acquired a hero point(s), in exchange for consuming one hero point. The hero mode is thus not available for enemy characters and is prepared to provide a pleasant play condition for players.

In addition, the hero mode is not automatically activated in the presence of a hero point but is operated by the player's choice. The player can thus select the game play condition by himself/herself, and higher gaming flexibility can be obtained.

If it is in the hero mode, the CPU1000proceeds to step S607. If it is not in the hero mode, the CPU1000proceeds to step S602.

Step S602: The CPU1000determines whether or not there is existing scratch damage. If there is scratch damage, the CPU1000proceeds to step S603. If there is no scratch damage, the CPU1000jumps to step S604.

Step S603: The CPU1000adds the amount of ineffective damage Ds to the amount of effective damage Df. That is, the CPU1000determines Df (new)=Df (old)+Ds, and it proceeds to step S604. In similar expressions in the following description, the same parameters on both sides of an equal sign will be assumed so that the left parameter is the new one and the right parameter the previous one.

Adding the amount of ineffective damage Ds to the amount of effective damage Df has the effect of providing qualitative variations for damage and allowing a wide range of tactics.

For example, even the amount of ineffective damage Ds of 100% the vitality parameter Lp does not lead to inoperability (uncontrollability). Any fixed damage in such a state, regardless of the magnitude, can decrease the vitality parameter Lp by the total of the amount of ineffective damage Ds and the amount of effective damage Df, eventually making the character inoperable (uncontrollable).

Step S604: The CPU1000decreases the vitality parameter Lp by the amount of effective damage Df resulting from the fixed damage. It should be noted that Lp=0 if the remaining vitality parameter Lp is short.

That is,
Lp=Lp−DfifLp>Df; andLp=0 ifLp≦Df.

As shown inFIG. 15(c), when there is fixed damage, the CPU1000displays the values of Lp and Df in different colors to indicate that there is fixed damage, without changing the length of the entire bar graph LPB.

Then, the CPU1000proceeds to step S605.

Step S605: The CPU1000initializes a fixed damage decrease delay timer ΔTf to zero. The representation of the amount of effective damage Df on the bar graph LPB decreases over time in response to the fixed damage decrease delay timer ΔTf. When the representation of the amount of effective damage Df on the bar graph LPB disappears, the decrease of the vitality parameter Lp as much as the amount of effective damage Df is fixed.

Then, the CPU1000proceeds to step S606.

Step S606: The CPU1000starts the fixed damage decrease delay timer, and it just ends processing.

Step S607: The CPU1000performs the scratch damage setting processing, and it ends processing after that. The scratch damage setting processing will be described in detail as related toFIG. 7.

The scratch damage setting processing (steps S505and S607) ofFIG. 5is performed, as shown inFIG. 7, by the CPU1000executing the following steps.

Step S701: Initially, the CPU1000stores the amount of ineffective damage Ds based on the scratch damage into the memory1020.

As shown inFIG. 15(b), when there is scratch damage, the value of Ds is displayed in different color to indicate that there is as much scratch damage as Ds, without changing the length of the entire bar graph LPB.

Then, the CPU1000proceeds to step S702.

Step S702: The CPU1000determines whether or not the scratch damage is progressive damage. Progressive damage is scratch damage caused by a weapon that is set to be effective over time, such as a tranquilizer gun. Progressive damage increases in response to a progressive timer ΔTg.

If the scratch damage is progressive damage, the CPU1000proceeds to step S703. If the scratch damage is not progressive damage, the CPU1000proceeds to step S705.

Step S703: The CPU1000initializes the progressive timer ΔTg to zero, and it proceeds to step S704.

Step S704: The CPU1000starts the progressive timer ΔTg, and simply ends processing.

Step S705: The CPU1000initializes a scratch damage recovery timer ΔTs to zero. The amount of ineffective damage Ds decreases over time in response to the scratch damage recovery timer ΔTs.

Then, the CPU1000proceeds to step S706.

Step S706: The CPU1000starts the scratch damage recovery timer ΔTs, and it simply ends processing.

The scratch disabling attribute processing (step S506) ofFIG. 5is performed, as shown inFIG. 8, by the CPU1000executing the following steps.

Step S801: When there is damage Lv of the scratch disabling attribute, the CPU1000decreases the vitality parameter Lp by a predetermined amount. However, if the remaining vitality parameter Lp is short, it sets Lp=0.

That is,
Lp=Lp−LvifLp>Lv; andLp=0 ifLp≦Lv.

Subsequently, the CPU1000just ends processing.

The damage progression and recovery processing (step S406) ofFIG. 4is performed, as shown inFIG. 9, by the CPU1000executing the following steps.

Step S901: Initially, the CPU1000performs fixed damage processing of decreasing the display length of fixed damage, and proceeds to step S902.

The fixed damage processing will be described in detail as related toFIG. 10.

Step S902: The CPU1000performs progressive damage processing of increasing progressive damage, and it proceeds to step S903.

The progressive damage processing will be described in detail as related toFIG. 11.

Step S903: The CPU1000performs scratch recovery processing of making scratch damage recover, and it proceeds to step S904.

The scratch recovery processing will be described in detail as related toFIG. 12.

Step S904: The CPU1000performs item-based damage recovery processing, and it just ends processing.

The item-based damage recovery processing will be described in detail as related toFIG. 14.

The fixed damage processing (step S901) ofFIG. 9is performed, as shown inFIG. 10, by the CPU1000executing the following steps.

Step S1001: The CPU1000changes the representation of the amount of effective damage Df on the bar graph LPB so that the representation decreases in length as much as the fixed damage decrease delay timer ΔTf, multiplied by a predetermined coefficient p (equivalent to the rate of decrease).

That is,
Df=Df−ΔTf*p; andDf=0 ifDf≦ΔTf.

Step S1002: The CPU1000determines whether or not the amount of effective damage Df falls to or below zero. If Df>0, the CPU1000simply ends processing. If Df≦0, the CPU1000proceeds to step S1003.

Step S1003: The CPU1000stops the fixed damage decrease delay timer ΔTf, and it just ends processing.

The progressive damage processing (step S902) ofFIG. 9is performed, as shown inFIG. 11, by the CPU1000executing the following steps.

Step S1101: Initially, the CPU1000increases the amount of ineffective damage Ds as much as the progressive timer ΔTg, multiplied by a predetermined coefficient q (equivalent to the rate of progressive increase).

That is,
Ds=Ds+ΔTg*q.

As shown inFIG. 15(b), when there is scratch damage Ds, the value of Ds is displayed in different color without changing the length of the entire bar graph LPB in order to indicate that there is as much scratch damage as Ds.

Step S1102: The CPU1000determines whether or not the amount of ineffective damage Ds reaches 100% of the vitality parameter Lp. If Lp>Ds, the CPU1000simply ends processing. If Lp≦Ds, the CPU1000proceeds to step S1103.

Step S1103: The CPU1000stops the progressive timer ΔTg, and it just ends processing.

The scratch recovery processing (step S903) ofFIG. 9is performed, as shown inFIG. 12, by the CPU1000executing the following steps.

Step S1201: Initially, the CPU1000decreases the amount of ineffective damage Ds as much as the scratch recovery timer ΔTs, multiplied by a predetermined coefficient r (equivalent to the rate of recovery).

That is,
Ds=Ds−ΔTs*r.

Step S1202: The CPU1000determines whether or not the scratch damage falls to or below zero. If the scratch damage is greater than zero, the CPU1000simply ends processing. If the scratch damage is smaller than or equal to zero, the CPU1000proceeds to step S1203.

Step S1203: The CPU1000stops the scratch recovery timer ΔTs, and it just ends processing.

The hero gauge processing (step S407) ofFIG. 4is performed, as shown inFIG. 13, by the CPU1000executing the following steps.

Step S1301: Initially, the CPU1000determines whether or not an attack of any one of the player characters hits successfully on any one of the enemy characters. If the attack hits successfully, the CPU1000proceeds to step S1302. If not, the CPU1000simply ends processing.

Step S1302: The CPU1000increases the accumulated points HGP of the player character by an amount corresponding to the damage that the successful attack gives to the enemy character.

That is, HGP=HGP+D*α, where D is the damage (Ds or Df) given to the enemy, and α is a coefficient.

Step S1303: The CPU1000determines whether or not the accumulated points reach 100% of a predetermined value (HGPmax). If the accumulated points reach 100%, the CPU1000proceeds to step S1304. If the accumulated points do not reach 100%, the CPU1000simply ends processing.

Step S1304: The CPU1000increases the hero points HP by “+1” and simply ends processing. That is, HP=HP+1.

The item-based damage recovery processing (step S904) ofFIG. 9is performed, as shown inFIG. 14, by the CPU1000executing the following steps. The item-based damage recovery processing in the game is performed when a player makes an operation to use an item (such as medicine) effective for damage recovery on any one of the player characters.

Step S1401: The CPU1000increases the vitality parameter Lp by the amount of damage recovery Li (Lp=Lp+Li), and it proceeds to step S1402.

Step S1402: The CPU1000determined whether or not the vitality parameter Lp exceeds a predetermined maximum value Lpmax (Lp>Lpmax). If Lp>Lpmax, the CPU1000proceeds to step S1403. If Lp≦Lpmax, the CPU1000jumps to step S1405.

Step S1403: The CPU1000sets a value by subtracting (Lp−Ds) from Lpmax, that is, Ds=Lpmax−(Lp−Ds). The CPU1000then proceeds to step S1404.

Step S1404: The CPU1000sets the vitality parameter Lp to the maximum value Lpmax (Lp=Lpmax), and it just ends processing.

Step S1405: The CPU1000determines whether or not the display length of the bar graph LPB, which indicates the sum of the vitality parameter Lp and the fixed damage Df, exceeds a length Tmax that indicates 100% of the upper limit of Lp (the display length of (Lp+Df)>Tmax). If the display length of (Lp+Df)>Tmax, the CPU1000proceeds to step S1406. If the display length of (Lp+Df)≦Tmax, the CPU1000simply ends processing.

Step S1406: The CPU1000decreases the length of the representation of the fixed damage Df so that the length of the bar graph LPB will not exceed the length that indicates 100% of the upper limit of Lp. That is, the CPU1000sets the display length of (Lp+Df)=Tmax, and it just ends processing.