U.S. Pat. No. 7,591,721

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

An embodiment of the present invention will be explained with reference to the accompanying drawings.

FIG. 1is a block diagram illustrating the configuration of a portable game device that is applied to an embodiment of the present invention. As illustrated in the figure, this portable game device includes a game device main body1and a cartridge2. The cartridge2is inserted into a slot of the game device main body1and is individually provided for each game. The video game (hereinafter simply called game) according to this embodiment is implemented by inserting the cartridge2including a predetermined game program into the game device main body1.

The game device main body1includes a CPU (Central Processing Unit)11, a boot ROM (Read Only Memory)12, a work RAM (Random Access Memory)13, a controller14, an LCD (Liquid Crystal Display)15, a speaker16, and a communications port17. The cartridge2has a ROM21and a RAM22. The ROM21and RAM22of the cartridge2are connected to the CPU11of the game device main body1via a connector20.

The respective structural components12to17of the game device main body1and the ROM21and RAM22of the cartridge2are connected to the CPU11, and the CPU11executes programs stored in the boot ROM12and ROM21to control the portable game device. The boot ROM12prestores a boot program for initializing the work RAM13of the game device main body1and a register of the CPU11and the like. The work RAM13is used as a work area when the CPU11executes the program.

The controller14includes a cross key, which functions as a joy stick, and multiple operation keys, and inputs a player's instruction to the CPU11by these key operations. The LCD15displays a game space, a character existing therein and a message necessary for the game progress according to the execution of the game program by the CPU11. The speaker16outputs sound effects and the like based on the circumstance of the game progress according to the game program. The communications port17transmits/receives information to/from another portable game device and or a stationary game device.

In the cartridge2, the ROM21stores a game program for implementing the game according to this embodiment. When the game is interrupted by the player's instruction, the RAM22saves data relating to the game progress stored in the work RAM13in order to restart the game from the interrupting time. The RAM22is backed up by a battery (not shown) and the storage contents are not erased even if power of the game device main body1is interrupted and the cartridge2is detached from the game main body1. In place of the RAM22, a writable/erasable nonvolatile memory such as a flash memory may be used.

The procedure of the game progress will be briefly explained. In the process that progresses the game, some events occur, and the player clears the events to advance the story of the game. The game is advanced as the player operates the player character. The player can arbitrarily select a player character to be used in the game from multiple player characters. At an event occurring time, the player can select two or more player characters that participate in the event, and choose one of the selected player characters as a leader.

FIG. 2is a view schematically illustrating an occurrence of the events in the game according to this embodiment. This game has a possibility that eleven events including event1to event11will occur before the game ends. Each event occurs when a predetermined condition fixed for each event is established. Events1to6are those that are essential for the story of the game, and the story of the game does not progress unless these events are cleared in order. Every time when events1to6are cleared sequentially, the story of the game proceeds to a next stage. When the event6is cleared, an ending image is displayed on a LCD15, thereafter the game ends.

Events7to11are arbitrary events, and even if these events can be neither generated nor cleared, the story of the game can be moved forward. The game can be also finally ended. Events7to9are those that occur at random regardless of the game progress. Event10may occur between events1and2and event11may occur between events3and4.

In order to advance the game as clearing the aforementioned events1to11, the player moves the player characters on the map. One that occurs as an event is a battle between the player characters and the enemy character (in some cases, multiple enemy characters are provided and a leader is fixed) in this embodiment. A screen to be displayed on the LCD15is changed at the time when the player characters are moved on the map during the events1to11and when the events1to11occur.

FIG. 3Ais a view illustrating a screen of a world map displayed on the LCD15. A world map100is formed in such a way that multiple towns (shown by circles) are arranged on a field having a predetermined geographic feature formed. A location where a player character130is displayed on the world map100is a town where the player character is currently present. The player moves the player character between the towns on the world map100. The player character moves between the towns on the world map, so that date virtually set in the game progress is updated.

A local map (not shown) is formed for each town on the world map100. The player operates the controller14to move the player character on the local map. Alternatively, the player character may move on only the world map100and a battle map110to be described later (FIGS. 3B,3C, and4). If a predetermined condition is established while the player character moves on the world map100and the local map, the events1to11occur according to the established condition.

FIGS. 3B and 3Care views each illustrating a battle screen.FIG. 3Billustrates a battle screen that is displayed when the battle is started and during the battle, and FIG.3C illustrates a victory condition display screen that is displayed at first in the battle. The battle between the player characters and the enemy characters is performed on the battle map110.FIGS. 3B and 3Cillustrate screens at the same battle, but they are different from each other in the portion of the battle map110displayed on the LCD15. This will be described later.

In the battle screen at the battle starting time shown inFIG. 3B, an instruction selection window120and an instruction object character window121are displayed in addition to a leader131of the player characters. The instruction selection window120is used to select and input the player's instruction. The contents of the instruction selection window120may be different from the contents shown inFIG. 3B. When there is no player character as an object to which the player can input an instruction, the instruction object character window121is not displayed in some cases. In the victory condition display screen illustrated inFIG. 3C, a message122indicating a condition for a victory and a leader132of the enemy characters are displayed.

FIG. 4is a view explaining movement of a display portion in the battle screen. When the battle is started, the multiple characters including the leader131of the player characters and the leader132of the enemy characters are arranged on the battle map110. In the battle screen at the starting time, an area15bhaving a predetermined size where the leader131of the player characters is placed at the center is displayed as a battle screen at the starting time shown inFIG. 3B. The battle map110displayed in the battle screen at the starting time shown inFIG. 3Bcorresponds to a portion included in an area15bof the battle map110ofFIG. 4.

In the victory condition display screen, since the victory condition is “defeat the enemy leader”, an area15c(having the same size as that of the area15b) where the leader132of the enemy characters is placed at the center is displayed as the victory condition display screen ofFIG. 3C. The battle map110displayed in the victory condition display screen ofFIG. 3Ccorresponds to a portion included in the area15cof the battle map110ofFIG. 4.

InFIG. 3C, since the victory condition is “defeat the enemy leader”, the area15cwhere the leader132of the enemy characters is placed at the center is displayed as the victory condition display screen. In the case of another victory condition, the victory condition display screen is not always decided in this way. For example, if the victory condition is “move to designated point”, an area around the designated point is displayed as the victory condition display screen.

Although not illustrated, in the battle screen where the battle is in progress, the area to be displayed on the LCD15is sequentially changed such that the player can easily recognize the battle progress. In the battle screen at the starting time, the victory condition display screen and the battle screen showing the battle in progress, the reason why the portion to be displayed is thus moved is to balance the size of display and the contents since the display area of the LCD15of the portable game device is limited. In other words, each character is displayed with such a size that the player can recognize the characters in the screen with the limited size without considering the size of the battle map110too much.

In the battle, an operation that the player should not instruct to the player character is defined as a rule in the game. Also, an operation in which the result obtained by instructing the operation should not be a predetermined result is defined as a rule in the game. The rule changes according to the game progress, but when a rule violation occurs, a yellow card or red card is presented to the player character, and a penalty is imposed on the player. The rule and the penalty to be imposed on the player in the case of the rule violation will be specifically described later.

An explanation will next be given of various data to be used in the game according to this embodiment. Variable data, which varies according to the game progress, is stored in the work RAM13of the game main body1. Fixed data, which does not vary according to the game progress, is prestored in the ROM21of the cartridge2. When the game is started from the beginning, initial data of variable data prestored in the ROM21is transferred to the work RAM13. When the game is restarted midway, variable data saved in the RAM22when the game is interrupted is transferred to the work RAM13.

An explanation will be next given of variable data to be stored in the work RAM13. Though there are various kinds of variable data necessary for the game progress, the following will explain data relating to embodiments of the present invention.

FIG. 5Ashows current data that is changed according to the game progress, namely, data indicating under what circumstance the game is advanced. Current data includes general data201and player character-specific data202-1to202-n.

General data201is common data regardless of data by player character, and includes Gil (amount of virtual money that the player possesses in the world of the game) and Item (name of the item that the player possesses), and Item_num (the number of items). When the number of kinds of items that the player possesses is two or more, combinations of Item and Item_num, which correspond to the number of kinds, are provided and registered. The items, which the player can possess, are classified into light items and heavy items according to their values in the game progress, and they are registered as Item data by classified group.

The player character-specific data202-1to202-n include Name (name of the player character), Indiv (player character unique ID), Level (current level of the player character), Exp (Experience value: one that determines a level), HP (Hit Point: amount of residual damage withstanding the attack from the enemy, the battle is impossible when 0), HPMAX (Hit Point MAXimum value), MP (Magic Point: amount of usable magic), MPMAX (Magic Point MAXimum value), Status (there is a case where the battle is impossible), StrAttack (physical attack), StrDefense (physical defense), IntAttack (magic attack), IntDefense (magic defense), Speed (speed that decides an attack order in the battle), Flag_Battle (Flag in Battle), Flag_Prison (Flag in Prison (battle participation impossible) flag), StopBattle (the number of residual battles in prison), Xpos (X-coordinate on the battle map), Zpos (Z-coordinate on the battle map), Redcard (the cumulative number of red cards), Yellowcard (the cumulative number of red cards), and netID (ID of the character in battle that is allocated at the time of participating in the battle).

Among these data, Level, HP, HPMAX, MP, MPMAX, Status, StrAttack, StrDefense, IntAttack, IntDefense, and Speed are characteristic values of the player character that indicate whether the player character has an advantageous position or a disadvantageous position in the battle, and exert a direct influence on the game progress.

Regarding the enemy character, though not illustrated, the same data as that of the player character is prestored in the ROM21and data corresponding to the enemy character that participates in the battle is copied to the work RAM13and used. Data of the enemy character includes Name, Indiv, Level, Exp, HP, HPMAX, MP, MPMAX, Status, StrAttack, StrDefense, IntAttack, IntDefense, Speed, Xpos, and Zpos. The meanings of these data items are the same as those of data corresponding to the player character.

FIG. 5Bis a view illustrating law check data. The law is selected and applied as a rule at each point in the game progress. Although both the rule and the law are regulations relating to the game progress, in this embodiment, the law is applicable as a regulation in the event, and the rule is actually applied as a regulation in the event. Law check data inFIG. 5Bincludes general data211and player character-specific data212-1to212-n.

The general data211includes MenuID (menu ID that is designated in connection with the action of the player character), MenuID_OLD (the latest menu ID that is recorded on MenuID), AbilityID (ability ID when the designated menu is ability), and AbilityID_OLD (the latest ability ID that is recorded on Ability ID).

The player character-specific data212-1to212-n include TermFlag (the flag being active when another character is made impossible to battle by petrifying the other character or HP=0 is established), ItemFlag (the flag being active when an item is stolen from the other character), Status (the flag being active when a status abnormality is provided to the other character), TargetNum (the number of characters as a target for an action), Damage [1]-[k] (damage or recovery value given to the other character by the action), Weapon [1], [2] (kinds of weapons used in the action), CardFlag [1], [2] (the flag being active when a yellow card or red card is received in the battle), and LawID [1], [2] (law unique ID of the law that has been violated (to be described later)).

An explanation will be next given of fixed data stored in the ROM21. A law table is prepared as fixed data. The law table includes two tables, that is, an individual law table illustrated inFIG. 6Aand a staged law table illustrated inFIG. 6B.

In the individual law table illustrated inFIG. 6A, a law unique ID, a rule name, a judgment type, an offset, a red card condition, and a penalty type are stored in association with each other. The law unique ID is an ID for identifying each law. The law name is a name that is given to each law. The judgment type is used to judge whether the action of the character is against the rule. The offset shows a specific action or a result of the action that is against the rule. The red card condition shows a condition when the red card is presented instead of the yellow card to the player character, even at the first rule violation. The penalty type shows the type of the penalty that is imposed on the player in the case of the rule violation.

In the staged law table inFIG. 6B, a staged law ID and a law unique ID for each stage are stored in association with each other. The staged law ID corresponds to the date of each stage. In the case of the first day of first stage1, a law, which includes a staged law ID of “001” and a law unique ID of “008” (namely, damage of 20 or more), is applied as a rule.

An explanation will be next given of the penalty to be given to the player when the rule violation occurs according to the law tables inFIGS. 6A and 6B.FIG. 7is a view showing penalty types and the contents. This figure is not stored in the ROM21as a table, but a game program is created such that the penalty with the contents described inFIG. 7is imposed on the player who violates the rule.

The penalty types include a fine (LOST_GIL), a status down (STAT_DOWN), and a consumption item confiscation (LOST_TREASURE). In any penalty type, the weight of the penalty to be imposed differs depending on whether the yellow card is presented by the rule violation or the red card is presented. In a case that the penalty type is the fine or the consumption item confiscation, the penalty is imposed on the entire player character as an object to be applied. In a case that the penalty type is the status down, the penalty which degrades any one or two kinds of, for example, Level, HP, HPMAX, MP, MPMAX, Status, StrAttack, StrDefense, IntAttack, IntDefense, and Speed, is imposed on the player character that violates the rule.

The following will explain processing to be executed to advance the game in the game according to an embodiment. When processing other than display processing is carried out, there is a case in which processing for displaying an image corresponding to the processing on the LCD15is carried out. However, regarding display processing other than display processing unique to this embodiment, some explanations will be omitted.

When power of the game device main body1is turned on, an initial screen for selecting whether the game is started from the beginning or restarted midway is displayed on the LCD15. The player operates the controller14according to the initial screen to select whether the game is started from the beginning or restarted midway. When the game is started from the beginning, initial data is loaded on the work RAM13from the ROM21and processing of the game is started. When the game is restarted, saved data is loaded on the work RAM13from the RAM22and processing of the game is started.

FIG. 8is a flowchart illustrating processing of a main routine in the game according to this embodiment. When the processing of the main routine is started, the CPU11determines whether a player's instruction is input from the controller14(step S101). Before the player's instruction is input from the controller14, processing in step S101is repeated to wait for inputting of an instruction from the player.

When the player's instruction is input, the CPU11determines whether the input instruction is a final instruction (step S102). When the input instruction is not the final instruction, the CPU11determines whether the input instruction is a movement instruction to the player character (step S103). When the input instruction is not the movement instruction, the CPU11performs processing according to the contents of the instruction (step S104) and the processing flow proceeds to step S108.

When the input instruction is the movement instruction, the CPU11moves the player character on the map (world map100or a local map) (step S105). The CPU11determines whether the player character has moved on the world map100(step S106). When the player character has moved on the world map100, the CPU11updates a date in the game, and makes the setting of the law set in the staged law table ofFIG. 6Bto be associated with the updated date in the current stage (step S107). After that, and also when not on the world map, the processing flow proceeds to step S108.

In step S108, the CPU11determines whether an event occurrence condition has been established. When the event occurrence condition has been established, the CPU11causes the event whose occurrence condition has been established to occur and executes event processing that shifts to processing relating to the event (step S109). The details on the event processing will be described later. When the event is ended in the event processing, the CPU11determines whether the ended event is any one of events1to5(step S110).

When the ended event is any one of events1to5, the CPU11changes the setting of the game stage to a next stage (step S111). Then, the processing flow goes back to step S101. When the event occurrence condition is not established in step S108or the ended event is not any one of events1to5in step110, the processing flow goes back to step S101directly.

When the instruction input in step S102is the end instruction, the CPU11performs save processing for saving variable data stored in the work RAM13to the RAM22of the cartridge2(step S112). When the save processing is ended, the processing in this flowchart is ended.

The following will specifically explain the event processing in step S109.FIG. 9is a flowchart illustrating the event processing. The event herein is the battle between the player characters and the enemy characters as mentioned above. When the event processing is started, the CPU11receives a player's instruction input from the controller14in connection with the selection of the player characters that participate in the battle (step S201).

When receiving the instruction about the selection of the player character, the CPU11places the selected player character and the enemy character that participates in the battle on the battle map110, and performs processing for displaying them on the LCD15(step S202). The battle screen displayed here is the same as the battle screen at the battle starting time where the leader of the player characters is displayed at the center as illustrated inFIG. 3B. When this screen is once displayed, the CPU11performs victory condition display processing for displaying the victory condition display screen as illustrated in, for example,FIG. 3Con the LCD15(step S203).

FIG. 10is a flowchart illustrating the victory condition display processing in step S203. In the victory condition display processing, the CPU11checks which victory condition is set in this battle (step S301). As a settable victory condition, there are provided five conditions, “defeat the enemy leader”, “defeat all”, “withstand for a fixed turn”, “break the designated object”, and “move to the designated point.” The CPU11executes any one of condition1display processing to condition5display processing in steps S302to S306according to the check result of the victory condition.

The condition1display processing will be explained. In a case where the condition1display processing is performed, the leader of the enemy characters is also placed on the battle map110. The screen first displayed on the LCD15uses the area15bas the display area where the leader131of the player characters is placed at the center as illustrated inFIG. 4. The screen using the area15bas the display area where the leader131of the player characters is placed at the center is displayed on the LCD15, and a message screen “victory condition defeat the enemy leader” is added and displayed thereon.

In the condition2display processing to the condition5display processing, similar to the leader131of the enemy characters in the condition1display processing, an object to be displayed at the center of the screen is fixed. One that is displayed at the center of the screen is the leader of the enemy characters in the condition2display processing, the leader of the player characters in the condition3display processing, the designated object in the condition4display processing, and the designated point in the condition5display processing, respectively.

In any of the condition1display processing to the condition5display processing, an image including the battle map110other than the unit relating to the victory condition is toned down and displayed. Regarding the victory condition, the unit that is not toned down is the leader of the enemy characters in the condition1display processing, all enemy characters in the condition2display processing, all player characters in the condition3display processing, the designated object in the condition4display processing, and the designated point in the condition5display processing, respectively.

When the victory condition display screen is displayed on the LCD15by any one of the condition display processing in steps S302to S306, the CPU11waits for a passage of a fixed time since the display of the victory condition display screen (step S307). After passing the fixed time since the display of the victory condition display screen, the CPU11returns the screen displayed on the LCD15to the original screen (screen displayed in step S202) (step S308). Then, the victory condition display processing is ended.

When the victory condition display processing is ended and the processing flow goes back to the event processing inFIG. 9, the CPU11places a judge character on the battle map110, and displays the battle screen including the judge character on the LCD15(step S204). The judge character is a non-player character that is used to present the yellow card or red card to the player character that breaks the rule. When the display of the judge character is ended, the CPU11executes battle processing for actually carrying out the battle between the player characters and the enemy characters (step S205). A portion, which is displayed as the battle screen in the battle map110, is changed according to the battle progress by the battle processing.

FIG. 11is a flowchart illustrating the battle processing in step S205. In the battle processing, the CPU11performs initialization processing for initializing general data211and CardFlag and LawID of the player character-specific data212-1to212-n of the law check data (step S401).

The CPU11determines a character that will act according to Speed data among current data of the player character that participates in the battle and current data of the enemy character (step S402). When the acting character is determined, the CPU11performs each action initialization processing for initializing player character-specific data212-1to212-n of law check data (note that CardFlag and LawID are excluded) (step S403).

The CPU11determines whether the acting character determined in step S402is the player character or the enemy character (step S404). When the acting character is the player character, the CPU11receives an instruction of the action to the player character input from the controller14(step S405). Then, the processing flow proceeds to step S407.

When the acting character is an enemy character, the CPU11determines an action that the enemy character should perform according to data relating to the enemy character. In this case, it is not determined whether an action of the enemy character is against the rule (step S406). When the action of the enemy character is determined, the processing flow proceeds to step S407.

In step S407, the CPU11causes the acting player character or the enemy character determined in step S402to carry out the action instructed in step S405or the action determined in step S406. The CPU11determines whether there is an unprocessed character among the characters as the targets in connection with the action of the character in step S407(step S408).

When there is an unprocessed character, the CPU11causes the character as the unprocessed target to perform an action subjected to an influence by the action of the character in step S407. This action includes not only such a passive action that is subjected to damage but also an active action that launches a counterattack against the character that launched an attack (step S409). After that, the processing flow goes back to step S408again. When there is no unprocessed character in step S408, the CPU11performs action result record processing for recording the action of the character in step S407and the action result (step S410).

FIG. 12is a flowchart specifically illustrating the action result record processing in step S410. In the action result record processing, the CPU11backs up the latest action of the character. More specifically, the CPU11copies data of MenuID included in the entire data211of law check data onto MenuID_OLD, and copies data of AbilityID onto AbilityID_OLD (step S501).

The CPU11records the action of the character in step S407. More specifically, the CPU11records an action menu on the MenuID, and an A ability ID on the AbilityID (in a case where the A ability is selected). In a case where an active action, such as “fight,” is not instructed or decided, but rather an instruction or decision that prevents the character from acting, such as “wait,” occurs, the CPU11clears data of the MenuID and AbilityID (step S502).

The CPU11records a category of the weapon that is used by the character in the action in step S407. More specifically, when the action that uses the weapon such as “fight” is recorded on the MenuID, the category of the weapon, which the character has, is recorded on Weapon[2]. When A ability is recorded on the AbilityID, the CPU11checks the essential weapon in the A ability and records the category on the Weapon[2] (step S503).

The CPU11further records the result of the actions in steps S407and S409. More specifically, when even one enemy character is petrified or HP=0 is established as the result of the action, the CPU11turns on TermFlag of player character-specific data212-1to212-n in connection with the character that has performed the relevant action. When the character that has performed the relevant action steals an item from the enemy character, the CPU11turns on ItermFlag of player character-specific data212-1to212-n in connection with the character that has performed the relevant action. When a status change occurs in the character that has performed the relevant action or has been subjected to the action, the CPU11records this fact on Status of the player character-specific data212-1to212-n about the character whose status has been changed. The CPU11records the number of characters as targets due to the relevant action on TargetNum of the player character-specific data212-1to212-n about the character that has performed the relevant action. The CPU11records damage given to the other character by the relevant action or a recovery value on Damage[1] to [k] of the player character-specific data212-1to212-n about the character that has performed the relevant action (step S504). Then, the action result record processing is ended.

When the action result record processing is ended and the processing flow goes back to the battle processing inFIG. 11, the CPU11performs penalty check processing for checking whether a penalty is imposed on the player when the violation of the rule set in step S107occurs by the action of the character in stepS407and the action result (step S411).

FIG. 13is a flowchart illustrating the penalty check processing in step S411. In the penalty check processing, the CPU11checks whether there are player characters that are not yet processing objects to be subjected to the penalty check among the player characters, which are selected by the player in step S201and which have participated in the battle (step S601).

When there are characters that are not yet processing objects, the CPU11checks whether HP of the player character as the processing object is 0 with reference to the player character-specific data212-1to212-n in connection with any one of the player characters that are not yet processing objects (step S602). When HP is not 0, the CPU11determines whether the relevant player character is petrified (step S603).

When HP of the player character as a processing object is 0 or the player character as a processing object is petrified, processing that is performed to the relevant character is ended and the processing flow goes back to step S601. When the player character as a processing object is not petrified, the CPU11checks the determination type of the law set as a rule in step S107(step S604).

When the determination type of the law is Category, the CPU11determines whether data of MenuID of the entire data211is offset data of the law set as a rule in step S107(step S605). When data of MenuID is not offset data, the processing flow goes back to step S601directly. When data of MenuID is offset data, the CPU11performs card processing to be described later (step S606). After completing the card processing, the processing flow goes back to step S601.

When the determination type of the law is Ability, the CPU11determines whether data of AbilityID of the entire data211is offset data of the law set as a rule in step S107(step S607). When data of AbilityID is not offset data, the processing flow goes back to step S601directly. When data of AbilityID is offset data, the CPU11performs card processing to be described later (step S608). After completing the card processing, the processing flow goes back to step S601.

When the determination type of the law is Arm, the CPU11determines whether data of either Weapon [1] or [2] included in the player character-specific data212-1to212-n as processing objects is offset data of the law set as a rule in step S107(step S609). When neither Weapon [1] nor [2] is offset data, the processing flow goes back to step S601directly. When data of either Weapon [1] or [2] is offset data, the CPU11performs card processing to be described later (step S610). After completing the card processing, the processing flow goes back to step S601.

When the determination type of the law is Damage, the CPU11determines whether a value, which is shown by data of any one of Damage [1] to [k] included in the player character-specific data212-1to212-n as processing objects, is more than offset data of the law set as a rule in step S107(step S611). When the value, which is shown by data of any one of Damage [1] to [k], is not more than offset data of the law, the processing flow goes back to step S601directly. When the value, which is shown by data of any one of Damage [1] to [k], is more than offset data of the law, the CPU11performs card processing to be described later (step S612). After completing the card processing, the processing flow goes back to step S601.

In step S601, when it is determined that there is no player character that is subjected to processing, the penalty check processing ends.

FIG. 14is a flowchart illustrating card processing performed in step S606, S608, S610, or S612. In the card processing, the CPU11determines whether the red card condition of the law set as a rule in step S107is STONE_TERM (step S701). When the red card condition is STONE_TERM, the CPU11determines whether TermFlag included in the player character-specific data212-1to212-n as processing objects is turned on (step S702).

When TermFlag is turned on, the CPU11sets a flag, which indicates the red card, to either CardFlag [1] or [2], whichever is empty, included in the character-specific data212-1to212-n of the relevant player character, and thereby records that the red card is presented to the relevant player character because of the rule violation. The CPU11adds a RedCard value included in current data about the relevant character by one, and thereby updates the cumulative number of red cards (step S703). Then, the processing flow proceeds to step S707.

When the red card condition is not STONE_TERM or TermFlag is not turned on, the CPU11sets a flag, which indicates the yellow card, to CardFlag [1] included in the character-specific data212-1to212-n of the relevant player character, or sets a flag, which indicates the yellow card, to CardFlag [2] when the flag is already set to CardFlag[1], and thereby records that the yellow card is presented to the relevant player character because of the rule violation. The CPU11increases a Yellow Card value included in current data about the relevant character by one, and thereby updates the cumulative number of yellow cards (step S704).

The CPU11performs yellow card display processing in which the judge character presents the yellow card to the player character (step S705). The CPU11checks whether both CardFlags [1] and [2] are turned on, and thereby determines whether a second yellow card is presented (step S706). When only the first yellow card is presented, the card processing ends and the processing flow goes back to penalty check processing inFIG. 13. When the second yellow card is presented, with the result that the red card is presented, the processing flow proceeds to step S707.

The CPU11performs red card display processing in which the judge character presents the red card to the player character (step S707). The CPU11performs processing for causing the player character to which the red card is presented to leave the battle map110(step S708). Then, the card processing is ended and the processing flow goes back to penalty check processing inFIG. 13.

When the penalty check processing is ended and the processing flow goes back to the battle processing inFIG. 11, the CPU11determines whether a battle processing end condition is established (step S412). The battle processing end condition includes a stop condition for a predetermined reason in addition to a victory condition and a defeat condition. When the battle processing end condition is not established, the processing flow goes back to the processing in step S402. When the battle processing end condition is established, the battle processing ends.

When the battle processing is ended and the processing flow goes back to the event processing inFIG. 9, the CPU11performs penalty processing for imposing a penalty on the player according to the passage of battle processing and the result thereof (step S206).

FIG. 15is a flowchart illustrating the penalty processing in step S206. In the penalty processing, the CPU11determines whether there are player characters that are not yet processing objects to be subjected to the penalty check among the player characters that have participated in the battle (step S801).

When there are player characters that are not yet processing objects, the CPU11checks whether there is a rule violation where no processing is performed in connection with any one of the player characters that are not yet processing objects (step S802). When there is no rule violation where no processing is performed, the processing flow goes back to the step801. The CPU11determines whether there is any further player character that is not yet a processing object. When there is a rule violation where no processing is performed, the CPU11detects the penalty type of the law corresponding to the rule set in step S107(step S803). The CPU11determines whether there is a rule violation in which the red card is presented with reference to CardFlag[1], [2] in connection with the player characters as processing objects (step S804).

When there is a rule violation where the red card is presented, the CPU11imposes a penalty defined for the red card in connection with the penalty type detected in step S803. When the penalty type is STAT_DOWN, the CPU11decreases two kinds of statuses (for example, HP and MP) in connection with the player character as a processing object (namely, the player character that is against the rule) (step S805).

The CPU11calculates the number of battle stop times where the relevant player character cannot participate in the battle because of the red card (step S806). The number of battle stop times can be obtained by an equation, for example, ((the cumulative number of yellow cards)+(the cumulative number of red cards)×2)×0.2+1. The CPU11sets the calculated number of battle stops to data of StopBattle about the relevant player character (step S807). Then, the penalty processing is ended.

Even though there is a violation of rule, when no rule violation deserving the red card occurs, the CPU11imposes a penalty defined for the yellow card about the penalty type detected in step S803. When the penalty type is STAT_DOWN, the CPU11decreases one kind of status in connection with the player character as a processing object (namely, the player character that is against the rule) (step S808). Then, the penalty processing is ended.

When the battle processing is ended and the processing flow goes back to the event processing inFIG. 9, the CPU11performs a predetermined end processing (step S207). This ends the event processing, and the processing flow returns to the aforementioned main routine inFIG. 8.

As explained above, in the game according to this embodiment, the stage of the game is updated by the end of the event and the player character moves on the world map100to update a virtual date, and thereby the rule set in the battle is changed. Since the rule changes sequentially according to the degree of the game progress according to this embodiment, a novel change occurs in the game progress to make it possible to continue to hold the player's interest in the game.

When there is a rule violation, a penalty is imposed on the player. The multiple kinds of penalties are prepared in advance and the penalty to be imposed changes according to the set rule. This causes a novel change in the game progress and makes it possible to maintain the player's interest in the game. When there is a rule violation, the yellow card or red card is presented to the player character by the degree (contents or the number of times). The weight of the penalty to be imposed on the player changes depending on which card is presented. When the red card is presented, the number of battle stop times is changed by the cumulative number of yellow cards or red cards. This also causes a novel change in the flow on the game progress.

When multiple player characters are selected as the player characters participating in the battle, there is a case that a penalty is imposed on only the player character that breaks the rule (case in which the penalty type is status down). When the penalty type is a fine or a consumption item confiscation, the penalty is imposed as a whole (namely, the penalty is imposed to the player). Various kinds of penalties are imposed and various influences occur in the game progress.

The rule violation is caused not only by the instruction to the player character provided by the player but also the result of the action instructed by the player. Since the latter includes an uncertain element in which it is uncertain that the rule violation occurs unless the player character is caused to perform an action, the change caused in the game progress varies.

The present invention is not limited to the aforementioned embodiment and various modifications and applications may be possible. The following will explain some modifications of the aforementioned embodiment that are applicable to the present invention.

In the aforementioned embodiment, there was a case in which the action of the player character instructed from the controller14by the player was against the rule and a case in which the result of the action was against the rule. Even in a case that the action instructed by the player was against the rule, the player character was caused to perform the action instructed by the player. In contrast to this, the presentation of the yellow or red card and the record of the rule violation may be performed at the time when the action instructed by the player is against the rule. The player character may not be caused to perform the action instructed by the player.

In the aforementioned embodiment, the stage of the game was updated when the events1to5were ended, and the visual date in the game was updated when the player character moved on the world map100. The law set as the rule changed as the stage of the game and the date advanced based on the staged law table inFIG. 6B. The number of rules set at the same time was only one. However, the present invention is not limited to this.

The change in the degree of the game progress, which exerts an influence on the change in the rule, may be based on a change in, for example, an experience value of the player character instead of the change in the stage due to the end of the event and the date due to the movement of the player character on the world map100. Moreover, the multiple laws are simultaneously set as a rule, and thereby the multiple rules may be simultaneously applied in the battle. In order that the multiple laws are simultaneously set as a rule, the number of laws set as a rule is increased as the degree of the game progress advances, and the number of rules to be simultaneously applied to the battle may be increased.

The multiple laws are classified into groups and the group of laws set as rules may be decided according to the degree of the game progress. In this case, when the group including the multiple laws is set as a rule, each law belonging to the relevant group is applied as a rule of the battle. In other words, there are multiple rules to be simultaneously applied to the battle.

In the aforementioned embodiment, when there was the rule violation, three consequences, namely, the fine, the status down and the consumption item confiscation were defined as a penalty imposed on the player. However, the penalties to be imposed were not limited to these. For example, the limitation of the kinds of weapons that can be used when the player character performs physical attack by the instruction from the player (for example, prohibition against taking up a bow and arrow and the like) and the limitation of the kinds of magic that can be used (for example, prohibition against working recovery magic and the like) can be applied as penalties. Such a penalty that a predetermined status abnormality is set in the player character may be applied. Instead of the status down of the player character, the status up of the enemy character may be applied as a penalty.

In the aforementioned embodiment, the weight of the penalty imposed on the player when the rule violation occurred was changed by depending on whether only the yellow card was presented because of the rule violation or the red card was also presented. However, the weight of the penalty imposed on the player can be changed by another method. For example, in a case where the status down is set as a penalty, the degree of status down may be changed. Not only the law applied as the rule but also the weight of penalty can be changed according to the degree of the game progress.

The penalty weight may be changed according to the cumulative number of yellow cards and the cumulative number of red cards recorded on the player character-specific data202-1to202-n of current data. For example, a violation historical index is obtained similar to the number of battle stop times obtained in step S806, and the degree of penalty imposed on the player may be increased more with an increase in the violation historical index. This further causes a novel change in the game progress to make it possible to continue holding the player's interest in the game. The degree of penalty imposed on the player may be changed by the total of the cumulative number of yellow cards and the cumulative number of red cards regarding all player characters instead of the cumulative number of player character-specific yellow cards and the cumulative number of player character-specific red cards.

In the aforementioned embodiment, the player character performed the action that was against the rule by the player's instruction, but the enemy character was controlled not to perform the action that was against the rule. In contrast to this, the enemy character may perform the action that is against the rule. When the enemy character performs the action that is against the rule, the yellow card or red card may be presented to the enemy character to impose the same penalty as presented to the player character. The action that is against the rule may be made different between the player character and the enemy character.

In the aforementioned embodiment, the portable game device including the game device main body1and the cartridge2was used as a game device serving as a platform where the game of the present invention was executed. However, the game of the present invention may be executed using a stationary game device and a general-purpose computer such as a personal computer as a platform. The game of the present invention may be executed using other electronic equipment as a platform, which can function as a computer apparatus such as a cellular phone.

In the aforementioned embodiment, the program data for executing the game of the present invention was stored in the ROM21of the cartridge2and distributed. However, the program data may be stored in a storage medium such as a CD-ROM, a DVD-ROM and the like, and distributed. The program data for executing the game of the present invention may be stored in a fixed disk device, which a server apparatus existing in the Internet has. The server apparatus converts the program data stored in the fixed disc apparatus to a signal and superimposes the signal on a carrier wave, and distributes it to the game main body1via the Internet. The program distributed from the server apparatus can be stored in a flash memory and the like provided in the game main body1or the cartridge2.

Although the invention has been described with reference to several exemplary embodiments, it is understood that the words that have been used are words of description and illustration, rather than words of limitation. Changes may be made within the purview of appended claims, as presently stated and as amended, without departing from the scope and spirit of the invention in its aspects. Although the invention has been described with reference to particular means, materials and embodiments, the invention is not intended to be limited to the particulars disclosed; rather, the invention extends to all functionally equivalent structures, methods, and uses such as are within the scope of the appended claims.