U.S. Pat. No. 8,089,484

DESCRIPTION OF THE NON-LIMITING EXAMPLE EMBODIMENTS

A configuration and an operation of a video game device according to an example embodiment of the present invention will now be described.

FIG. 1shows an external view of a video game device10according to the example embodiment of the present invention. Referring toFIG. 1, the video game device10includes a first LCD (Liquid Crystal Display)11and a second LCD12. A housing13includes an upper housing13aaccommodating the first LCD11, and a lower housing13baccommodating the second LCD12. The first LCD11and the second LCD12both have a resolution of 256.times.192 dots. While LCDs are used in the present embodiment, the display device may be of any other suitable type, e.g., an EL (Electro Luminescence) display device. Moreover, the resolution of the first LCD11and the second LCD12is not limited to the particular resolution used herein.

The upper housing13aincludes sound slits18aand18btherein for allowing the sound from a pair of speakers (30aand30binFIG. 2) to be described later to pass therethrough.

The lower housing13bincludes a set of input devices, including a cross-shaped switch14a, a start switch14b, a select switch14c, an A button14d, a B button14e, an X button14f, a Y button14g, an L button14L and an R button14R. Another input device is a touch panel15attached on the screen of the second LCD12. The lower housing13bincludes a power switch19and slots for accommodating a memory card17and a stylus16.

The touch panel15may be any of various types of touch-sensitive panels, including a resistive film touch panel, an optical (infrared) touch panel and a capacitance-coupling touch panel. The touch panel15is capable of outputting position data corresponding to the contact point on the surface thereof, at which it is being touched with the stylus16. While it is assumed herein that the player uses the stylus16to operate the touch panel15, it is understood that the touch panel15may be operated with a pen (stylus pen) or a fingertip instead of the stylus16. In the present embodiment, the touch panel15has a resolution (detection precision) of 256×192 dots, which is equal to the resolution of the second LCD12. Note however that it is not necessary that the resolution of the touch panel15is equal to that of the second LCD12.

The memory card17is a storage medium storing a video game program, and is received by the slot in the lower housing13b.

Referring now toFIG. 2, an internal configuration of the video game device10will be described.

Referring toFIG. 2, a CPU core21is mounted on an electronic circuit board20accommodated in the housing13. The CPU core21is connected to a connector23, an input/output interface circuit (referred to simply as an “I/F circuit”)25, a first GPU (Graphics Processing Unit)26, a second GPU27, a RAM24and an LCD controller31, via a bus22. The connector23can receive the memory card17. The memory card17includes therein a ROM17astoring a video game program, and a RAM17brewritably storing backup data. The video game program stored in the ROM17aof the memory card17is loaded to the RAM24, and the loaded video game program is executed by the CPU core21. In addition to the video game program, the RAM24also stores temporary data produced while the CPU core21is running the video game program, and other data for producing game images. The I/F circuit25is connected to the touch panel15, a right speaker30a, a left speaker30b, and a control switch section14ofFIG. 1including the cross-shaped switch14a, the A button14d, etc. The right speaker30aand the left speaker30bare placed behind the sound slits18aand18b, respectively.

A first VRAM (Video RAM)28is connected to the first GPU26, and a second VRAM29is connected to the second GPU27. In response to an instruction from the CPU core21, the first GPU26produces a first game image and renders it on the first VRAM28, based on data stored in the RAM24for producing game images. Similarly, the second GPU27produces a second game image and renders it on the second VRAM29in response to an instruction from the CPU core21. The first VRAM28and the second VRAM29are connected to the LCD controller31.

The LCD controller31includes a register32. The register32stores a value of 0 or 1 in response to an instruction from the CPU core21. When the value stored in the register32is 0, the LCD controller31outputs the first game image rendered on the first VRAM28to the first LCD11and outputs the second game image rendered on the second VRAM29to the second LCD12. When the value stored in the register32is 1, the LCD controller31outputs the first game image rendered on the first VRAM28to the second LCD12and outputs the second game image rendered on the second VRAM29to the first LCD11.

The configuration of the video game device10described above is merely an example, and the present invention is applicable to any computer system having at least one display device. The video game program of example embodiments of the present invention may be supplied to the computer system via a wired or wireless communications line, instead of via an external storage medium such as the memory card17. Alternatively, the video game program may be pre-stored in a non-volatile storage device inside the computer system.

The flow of the game process to be performed by the video game device10will now be described. While the example embodiments of the present invention is herein applied to a role-playing game, it may also be applicable to other genres of video games, such as simulation games.

There are a plurality of player characters (those that the player can control) in the game world, and the player can choose four of the player characters, for example, to form a party. The player can control the party to take down enemy characters in the game world.

The player characters and enemy characters in the game world are each assigned a predetermined attribute, selected from “fire”, “wood”, “earth”, “wind” and “water”. These attributes are defined so that each attribute is weak to one of the other attributes but is strong against another one of the other attributes. For example, a character of the “fire” attribute may be weak to a character of the “water” attribute but strong against a character of the “wood” attribute. If the player can form a party while taking into consideration the attributes of enemy characters that the party will likely to encounter in due course of time, it will affect the game in favor of the player. For example, when the party is traveling through a forest, it is expected that the party will encounter enemy characters mostly of the wood attribute. Therefore, the party can travel through the forest more easily if the party includes characters of the fire attribute, who are strong against enemy characters of the wood attribute.

The game proceeds in the traveling mode and in the battle mode alternated with each other. In the traveling mode, the player can control the party to move the party around to an intended destination in the game field. While the party is traveling across the game field, an enemy-encountering event occurs at random, triggering the battle mode. When the enemy character is taken down, the battle mode ends and the process returns to the traveling mode.

FIG. 3shows an exemplary game screen in the traveling mode. An attribute status barometer image is displayed on the first LCD11. The attribute status barometer image shows, for each attribute, whether the attribute is currently being active and, if the attribute is not being active, the amount of time needed before the attribute will next become active (which may be an approximate representation of the time).

In the present embodiment, the attribute status barometer image includes a “fire” planet40a, a “wood” planet40b, an “earth” planet40c, a “wind” planet40dand a “water” planet40e, which are attribute symbols representing the five attributes of “fire”, “wood”, “earth”, “wind” and “water”, respectively. There is provided an animation of these planets moving in concentric orbital motion around the center of the display screen of the first LCD11. Each arrow in the figure represents the moving direction of a planet. The planets travel at an equal velocity but have different orbital periods. The orbital periods of the “fire” planet40a, the “wood” planet40b, the “earth” planet40c, the “wind” planet40dand the “water” planet40eare 10 minutes, 20 minutes, 40 minutes, 80 minutes and 120 minutes, respectively.

Referring toFIG. 3, drawn in the background of the attribute status barometer image are the orbit of each attribute symbol, the arrow representing the moving direction thereof, and boundary lines separating the active zone of each attribute from others. The orbit of each attribute symbol and the arrow representing the moving direction thereof are optional. The boundary lines are also not necessary if the active zones of different attributes are displayed in different colors. While an attribute symbol is moving through its active zone, the status of the attribute represented by the attribute symbol becomes active. For example, in the example shown inFIG. 3, the “wood” planet40bis moving through the “wood” active zone, and therefore the status of the “wood” attribute is active. Similarly, the “water” planet40eis moving through the “water” active zone, and therefore the status of the “water” attribute is active. The other (“fire”, “earth”, “wind”) planets are moving outside their active zones, and are therefore inactive. The attribute being active affects the attribute (“space attribute”) of a particular space in the game world (at least around the player characters and enemy characters facing each other). For example, while the “wind” attribute is active, the space attribute is “wind”. In the example shown inFIG. 3, the “wood” attribute and the “water” attribute are active, whereby the space attribute is “wood/water”. The space attribute affects the ability parameters of characters of the same attribute. For example, where the space attribute is “wood/water”, the attack power of each player character whose attribute is “wood” or “water” is temporarily doubled.

Displayed on the second LCD12are the field of the game world and the party traveling across the field. The party is made up of four characters, i.e., a first character41a, a second character41b, a third character41c, and a fourth character41d. Assume that the attribute of the first character41ais “fire”. The player can operate the cross-shaped switch14ato move the party around to an intended destination.

If the party encounters an enemy character in the state ofFIG. 3, the mode of operation transitions from the traveling mode to the battle mode, and a game image as shown inFIG. 4is displayed. Note that the attribute status barometer image on the first LCD11is generally the same as that shown inFIG. 3since hardly any time has passed sinceFIG. 3.

The second LCD12shows the player characters41ato41dfacing an enemy character42. Characters, including the player characters41ato41dand the enemy character42, are each assigned an “agility” parameter, and a character with high “agility” is first given an opportunity to take an action in the battle mode. When any of the player characters41ato41dis given an opportunity to take an action, a command list is displayed with which the player can issue an instruction to the player character. When the player selects a command from the command list, there is provided an animation of the player character taking an action according to the selected command. In the example shown inFIG. 4, a command list for giving an instruction to the first player character41ais displayed. While the attribute of the first player character41ais “fire”, the attribute status barometer image indicates that the “fire” planet40ais located outside the “fire” active zone and the status of the “fire” attribute is thus being inactive. The attribute status barometer image also indicates that the “fire” planet40awill soon enter the “fire” active zone. In view of this, the player can wait for some tens of seconds, for example, to thereby let the “fire” planet40aenter the “fire” active zone before touching on “fight” with the stylus16. Then, the player successively issues instructions to the remaining player characters41bto41d. Since the attribute status barometer image indicates that it will take some time for the “earth” planet40cto enter the “earth” active zone, it may be more effective for the player to instruct any player character of the “earth” attribute to, instead of attacking the enemy character42, cast a spell to restore hit points to other player characters or to defend other player characters. Alternatively, the player may reform the party by replacing the player character of the “earth” attribute with another player character of the “water” attribute.

Note that the movement of the planets40ato40emay be temporarily halted (i.e., the time in the game world stops temporarily) while a command list is being displayed. Even then, the planets40ato40eare moved during each battle animation. In such a case, the player can leave the player characters41ato41dstanding in the game field in the traveling mode until an intended planet becomes active. Then, after the intended planet becomes active, the player can start moving the party so that the party can enter the battle mode while an intended attribute is being active.

FIG. 5shows an exemplary game screen at a point in time when an attack by the first player character41ahits the enemy character42. While the first player character41acan normally inflict 48 damage points on the enemy character42, the first player character41ainflicts 48×2=96 damage points on the enemy character42because the “fire” attribute is being active and therefore the attack power of the first player character41aof the “fire” attribute is being doubled. The calculation of damage points also takes into account the attribute of the enemy character with respect to the attribute of the player character as described above. For example, a character of the “fire” attribute can give a character of the “wood” attribute a damage that is twice as much as a normal damage. Therefore, if the attribute of the enemy character42is “wood”, and if the first player character41asuccessfully attacks the enemy character42while the space attribute includes “fire”, the damage points will be 48×2×2=192. On the other hand, a character of the “fire” attribute can give a character of the “water” attribute a damage that is only ½ a normal damage. Therefore, if the attribute of the enemy character42is “water”, and if the first player character41asuccessfully attacks the enemy character42while the space attribute includes “fire”, the damage points will be 48×2/2=48.

The operation of the video game device10will now be described in detail.

FIG. 6shows an exemplary memory map of the RAM24. The RAM24stores a video game program50, character image data51, planet image data52, background image data53, operation data54, planet data55, character data56and a space attribute57.

The video game program50is loaded from the ROM17aof the memory card17to the RAM24, and the loaded video game program is executed by the CPU core21.

The character image data51are image data of player characters and enemy characters. The planet image data52are image data of the planets included in the attribute status barometer image. The background image data53are image data of the background of the attribute status barometer image, and the background of the game field in the traveling mode, etc. The operation data54is data representing an input operation by the player, and is periodically obtained based on the output signals from the control switch section14and the touch panel15. The planet data55are data regarding the planets, and each planet data55includes the attribute of the planet, the orbital period thereof, the position thereof, and the active flag thereof as shown inFIG. 6. The active flag indicates whether or not the status of the planet is being active. The character data56are data regarding player characters and enemy characters. Referring toFIG. 6, each character data56represents the attribute of the character and other ability parameters thereof, including HP (hit points) representing the number of damage points that can be taken by the character, the magic points (“MP”) representing how many spells that can be cast by the character, the agility, and the attack power. The types of ability parameters are not limited to those shown above. The character data56may include other ability parameters such as special skills of the character, the number of times the character can attack enemy consecutively, etc. The space attribute57is constantly updated based on the statuses of the attributes “fire”, “wood”, “earth”, “wind” and “water”.

The flow of the process of the CPU core21according to the video game program50will now be described with reference to the flow charts ofFIGS. 7 to 9.

The process of the CPU core21is generally classified into the space attribute process and the character process. The space attribute process is a process primarily for displaying the attribute status barometer image. The character process is a process for handling the travel of player characters in the traveling mode and battles between player characters and enemy characters in the battle mode. In the present embodiment, the space attribute process and the character process are performed by the CPU core21in parallel to each other. Note however that the present invention is not limited thereto, and the programming method is not limited to any particular method as long as the effects of the present invention are realized.

Referring first toFIG. 7, the details of the space attribute process will be described.

After the video game program50starts, the CPU core21displays the attribute status barometer image in its initial state on the first LCD11in step S10ofFIG. 7. In the initial state, the planets are placed in their initial positions.

In step S12, the CPU core21determines the amount of time elapsed from the start of the video game program50.

In step S14, the CPU core21calculates the current position of each planet based on the elapsed time determined in step S12and the orbital period of the planet, and updates the positions of the planets40ato40estored in the RAM24based on the calculation results.

In step S16, the CPU core21determines whether or not the position of each of the planets40ato40eis within the corresponding active zone, and updates the active flags of the planets40ato40estored in the RAM24based on the determination results.

In step S18, the CPU core21refers to the attribute of each planet whose active flag is ON (i.e., each planet that is being active) to update the space attribute57stored in the RAM24.

In step S20, the CPU core21produces the attribute status barometer image using the planet image data52and the background image data53, based on the positions of the planets40ato40estored in the RAM24. The produced attribute status barometer image is stored in the first VRAM28as image data. Then, at a predetermined point in time, the attribute status barometer image is supplied to the first LCD11through the LCD controller31, and is displayed on screen of the first LCD11.

After step S20, the process returns to step S12to repeat the loop from steps S12to S20.

With the space attribute process as described above, the space attribute57stored in the RAM24is updated in real time.

Referring now toFIG. 8, the details of the character process will be described. Also in the character process, the game image is periodically produced and displayed on the second LCD12, as in the space attribute process. However, for the sake of simplicity, the game image producing process is omitted in the flow chart ofFIG. 8(and in the flow chart ofFIG. 9showing a part of the process ofFIG. 8).

As the video game program50is started, a game starts first in the traveling mode, and the CPU core21obtains the operation data54in step S30ofFIG. 8.

In step S32, the CPU core21updates the positions of the player characters41ato41dstored in the RAM24according to the operation data54obtained in step S30.

In the traveling mode, the CPU core21produces a game image based on the updated positions of the player characters using the character image data51and the background image data53, wherein the game image represents the player characters41ato41dtraveling across the game field as shown inFIG. 3. The produced game image is displayed on the second LCD12.

In step S34, the CPU core21determines whether or not the party has encountered the enemy character42. If so, the process proceeds to step S36to transition from the traveling mode to the battle mode. Otherwise, the process returns to step S30.

In step S36, the CPU core21selects the first character to take an action based on the agility levels of the characters involved, including the player characters41ato41dand the enemy character42.

In step S38, the CPU core21determines whether or not the character selected in step S36is a player character. If so, the process proceeds to step S40, and the process proceeds to step S42otherwise.

In step S40, the CPU core21prompts the player to input an instruction to the player character as shown inFIG. 4.

In step S42, the CPU core21performs an attack process. The details of the attack process will be described later.

In step S44, the CPU core21determines whether or not the battle has ended. If so, the process proceeds to step S30to transition from the battle mode back to the traveling mode. Otherwise, the process returns to step S36to select the next character to take an action.

Even during the character process, the space attribute process is being performed in parallel. Therefore, whether in the traveling mode or in the battle mode, the space attribute57is constantly updated based on the movement of the planets40ato40e. As described above, the movement of the planets40ato40emay be temporarily halted while a command list is being displayed. In such a case, the movement of the planets40ato40eneeds to be halted temporarily in step S40.

Referring now to the flow chart ofFIG. 9, the details of the attack process in step S38ofFIG. 8will be described.

First, in step S50, the CPU core21refers to data stored in the RAM24to determine whether or not the attribute of the attacking character (a player character or an enemy character) is included in the space attribute57. If so, the process proceeds to step S52, and the process proceeds to step S54otherwise.

In step S52, the CPU core21temporarily doubles the attack power of the attacking character, which is stored in the RAM24.

In step S54, the CPU core21provides an animation of the attacking character attacking the target character.

In step S56, the CPU core21calculates the damage points to be inflicted on the target character while taking into consideration the attack power of the attacking character, and also taking into consideration the attribute of the attacking character with respect to the attribute of the target character. If the attack power of the attacking character has been temporarily doubled in step S52, the damage points to be inflicted on the target character is twice as many as the normal damage points.

In step S58, the CPU core21subtracts the damage points calculated in step S56from the HP of the target character stored in the RAM24, and exits the attack process.

As described above, in the present embodiment, the space attribute, which affects the attack power of each character, changes in real time. This enriches the strategic aspect of the present video game in the battle mode. The player can look at the attribute status barometer image to perceive the amount of time needed before an attribute will next become active, based on which the player can make a strategic decision, e.g., a decision to remain still in view of the space attribute being about to switch to an intended attribute. This enriches the strategic aspect of the present video game.

While an attribute status barometer image as shown inFIG. 3is used in the present embodiment, the present invention is not limited to this, but may use any other suitable image as long as the image can indicate the status of each attribute (active or inactive) and can also generally indicate the amount of time needed before each inactive attribute will next become active. Three variations of the attribute status barometer image will be shown below.

The attribute status barometer image ofFIG. 10differs from that ofFIG. 3in that there is only one common active zone for the planets40ato40e. With this attribute status barometer image, similar effects to those described above will be obtained. However, it may be more preferred to provide an active zone for each planet at a different position as in the embodiment above, which can enhance the playability of the video game, as the player will be then prevented from too easily determining, at a glance, which attribute is currently being active and about when an inactive attribute will become active.

The attribute status barometer image ofFIG. 11includes, instead of the planets40ato40e, bars each associated with one attribute, wherein the top of each bar moves up and down between minimum and maximum values. For example, the “fire” attribute is being active while the top of the “fire” bar is located within the “fire” active zone. In the example shown inFIG. 11, the “wood” and “wind” attributes are being active, and the space attribute is therefore “wood/wind”. The speed of bar movement may be the same for all the attributes or may be different from one attribute to another.

The attribute status barometer image ofFIG. 12includes symbols each associated with one attribute, wherein the color of each attribute symbol changes through six steps, from the lightest color to the darkest color. A symbol in the darkest color means that the associated attribute is being active. After an attribute finishes being active, the color for that attribute changes to the lightest color. Then, the color again starts darkening gradually over time.

While the example embodiments of the present invention are herein applied to a role-playing game, it may also be applicable to other genres of video games, such as simulation games.

While the planets have different orbital periods in the present embodiment, the present invention is not limited thereto, and the planets may all have the same orbital period. Note however that the order in which different attributes become active will then be fixed, whereby the pattern in which the space attribute changes will be monotonous as compared with the present embodiment.

The velocity of each planet may be constant or may be varied over time. The velocity may be increased or decreased in response to an event occurring in the game world (e.g., a player character casting a predetermined spell).

While the space attribute can include a plurality of attributes if they are being active in the present embodiment, the present invention is not limited thereto. For example, one of a plurality of attributes being active may be selected to be the space attribute based on a predetermined criterion (e.g., the attribute that has become active at the latest point in time).

Where barometer images for different attributes are moving independently in the attribute status barometer image (e.g., where different planets are moving with different orbital periods), there may be a point in time at which the barometer images are positionally aligned together (e.g., the planets may be all lined up). A special event may occur in the game when such an alignment happens. For example, an event may happen where player and enemy characters are both damaged, which may enhance the playability of the video game. Moreover, there may be a magic spell that has an effect of advancing a particular barometer image by a predetermined distance (e.g., a magic spell by which a planet traveling along its orbit at a constant velocity is advanced by a predetermined distance). Then, the player may be able to intentionally align the positions of the barometer images (e.g., to intentionally line up all the planets). A special event (e.g., giving an extra damage to an enemy character) may occur upon such intentional alignment, which may further enhance the playability of the video game.

While the example embodiments of the invention have been described in detail, the foregoing description is in all aspects illustrative and not restrictive. It is understood that numerous other modifications and variations can be devised without departing from the scope of the invention.