JP5731433B2 - Game device, battle control method, and program - Google Patents

Description

  The present invention relates to a game apparatus, a battle control method, and a program that can further enhance the strategy in a game.

Conventionally, video games (software) of various genres have been developed in correspondence with business and home game devices. Among them, role-playing games are very popular and are supported by users of a wide range of ages.
As an example, this role-playing game is a type of game in which a user operates a hero character (player character) to adventure in a virtual space (field, dungeon, etc.) and achieve a predetermined purpose. During the game, the player character fights against the enemy character encountered and wins it to improve the experience value, ability value, etc., and grows up so that it can fight even stronger enemy characters.

  As a prior art of a game device that executes such a role-playing game, a technology of a game device that can be enjoyed by a user as a main character is also disclosed (for example, see Patent Document 1).

JP 2003-062343 (page 3-16, FIG. 7)

  In the conventional role-playing game described above, when a battle is started during the game, the user sequentially instructs the player character. That is, in battle, the player character and the enemy character are generally given an opportunity to attack alternately. In the order of the player character, the user issues a desired command (commands such as attack, defense, and recovery) each time. Select and indicate. Therefore, the user can instruct the player character by appropriately selecting the optimum command at that time while determining the battle situation.

Such a battle style that can sequentially give instructions as desired is simple and very easy to understand, but because it can be handled to some extent according to the situation of the battle, the user will advance the battle without thinking deeply. It was causing evil. In other words, there is a tendency to forcibly advance the battle without developing a strategy according to the enemy character, and there are many users who cannot feel the fun in such a battle.
For this reason, in games such as role-playing games, there has been a demand for the development of technology that makes it more enjoyable for bargaining in battle.

  The present invention has been made to solve such a problem, and an object of the present invention is to provide a game device, a battle control method, and a program that can further improve the strategy in a game.

  A game device according to a first aspect of the present invention is a game device that makes a user's object and another object battle, and includes a setting unit, an acquisition unit, a battle control unit, a reception unit, and a determination unit. Composed.

First, the setting unit assigns a user object (for example, a picture card or a character representing a user, etc.) to each slot in a timetable that defines each slot up to a predetermined number, with a slot required for one battle as one unit. Set according to each.
An acquisition part acquires the time table of the other party which fights. For example, when the user is playing the game alone (in the case of a single player), since it is a CPU battle, the acquisition unit generates a time table on the opponent side according to a predetermined logic or the like, and the time table As the timetable of the other party. In addition, when the user is playing this game so that the user can play against other users (in the case of multiple players), the acquisition unit is sent from another game device via a predetermined communication unit or the like. Get the other party's timetable.
The battle control unit causes the objects to battle each other based on the set user time table and the acquired opponent time table. That is, the objects defined in both time tables are made to battle each other in slot units.
The reception unit receives a priority command (intervention operation) from the user during the battle between the objects.
A determination part determines a user's victory or defeat based on the battle | competition result of the said object made to fight.
Then, the battle control unit applies the priority command received by the receiving unit to the slots in the user's time table so that the objects battle each other.

In this way, a battle between objects is performed on a slot basis along both time tables. That is, the user object performs an attack or the like along a time table set by the user, and the partner object performs an attack or the like along a time table set by another user (or CPU). For this reason, the user can enjoy a series of battles, including whether or not his strategy was effective for the opponent. Moreover, the user can intervene as appropriate when a battle is being performed along both timetables.
As a result, the strategy in the game can be further enhanced.

  A game device according to a second aspect of the present invention is a game device for playing a character that can be used by a user and a character that can be used by an opponent to be used, and a storage unit, a setting unit, an acquisition unit, a battle control unit, and a reception And a determination unit.

First, a memory | storage part memorize | stores the information regarding the some character (monster character etc.) which a user can use.
The setting unit sets a slot required for one battle as a unit, and selects a character selected from the plurality of stored characters and a command to the character in a time table that defines a predetermined number of slots. Set each corresponding to the slot.
An acquisition part acquires the time table of the other party which fights. For example, when the user is playing the game alone (in the case of a single player), since it is a CPU battle, the acquisition unit generates a time table on the opponent side according to a predetermined logic or the like, and the time table As the timetable of the other party. In addition, when the user is playing this game so that the user can play against other users (in the case of multiple players), the acquisition unit is sent from another game device via a predetermined communication unit or the like. Get the other party's timetable.
The battle control unit causes the objects to battle each other based on the set user time table and the acquired opponent time table. That is, the characters defined in both time tables are made to battle each other according to their commands.
The reception unit receives a priority command (intervention operation) from the user during the battle between the characters.
A determination part determines a user's victory or defeat based on the battle | competition result of the said characters made to fight.
And a battle | competition control part gives priority to the priority command received by the reception part over the command set to the slot in a user's time table, and makes characters fight.

In this way, the battle between characters is performed in slot units along both time tables. That is, the user's character performs a commanded attack according to the timetable set by the user, and the opponent's object attacks the commanded according to the timetable set by another user (or CPU). Etc. For this reason, the user can enjoy a series of battles, including whether or not his strategy was effective for the opponent. Moreover, the user can intervene as appropriate when a battle is being performed along both timetables.
As a result, the strategy in the game can be further enhanced.

  The reception unit may receive a priority command from a user directed to a character waiting for a battle.

  The battle control unit may reject the priority command received by the reception unit based on a predetermined condition and allow the characters to battle without changing the user's time table.

  A battle control method according to a third aspect of the present invention includes a setting unit, an acquisition unit, a battle control unit, a reception unit, and a determination unit, and is executed by a game device that battles a user object against another object. A battle control method comprising a setting step, an acquisition step, a battle control step, a reception step, and a determination step.

First, in the setting step, a user object (for example, a picture card or a character representing a user or the like) is assigned to each slot in a time table that defines each slot up to a predetermined number with one slot as a unit. Set according to each.
In the acquisition step, the time table of the opponent side to fight against is acquired. For example, when the user is playing the game alone (in the case of a single player), since it is a CPU battle, the acquisition unit generates a time table on the opponent side according to a predetermined logic or the like, and the time table As the timetable of the other party. In addition, when the user is playing this game so that the user can play against other users (in the case of multiple players), the acquisition unit is sent from another game device via a predetermined communication unit or the like. Get the other party's timetable.
In the battle control step, based on the set user's time table and the acquired opponent's time table, the objects are battled for each slot. That is, the objects defined in both time tables are made to battle each other in slot units.
In the reception step, a priority command (intervention operation) from the user is received during the battle between the objects.
In the determination step, whether the user wins or loses is determined based on the result of the battle between the objects that have been matched.
Then, in the battle control step, the priority command received in the reception step is applied to the slots in the user's time table, and the objects are battled.

In this way, a battle between objects is performed on a slot basis along both time tables. That is, the user object performs an attack or the like along a time table set by the user, and the partner object performs an attack or the like along a time table set by another user (or CPU). For this reason, the user can enjoy a series of battles, including whether or not his strategy was effective for the opponent. Moreover, the user can intervene as appropriate when a battle is being performed along both timetables.
As a result, the strategy in the game can be further enhanced.

  A program according to a fourth aspect of the present invention is configured to cause a computer (including an electronic device) to function as the above game device.

  This program can be recorded on a computer-readable information recording medium such as a compact disk, flexible disk, hard disk, magneto-optical disk, digital video disk, magnetic tape, and semiconductor memory.

  The above program can be distributed and sold via a computer communication network independently of the computer on which the program is executed. The information recording medium can be distributed and sold independently of the computer.

  According to the present invention, strategy in a game can be further improved.

1 is a schematic diagram showing an appearance of a typical portable game machine in which a game device according to the present invention is realized. It is a block diagram which shows the outline | summary structure of a portable game machine. It is a mimetic diagram showing the outline composition of the game device concerning Embodiment 1 of the present invention. It is a schematic diagram for demonstrating an example of a time table. (A)-(c) is a schematic diagram for demonstrating a mode that a monster character etc. are arrange | positioned in a timetable setting area | region. (A)-(d) is a schematic diagram for demonstrating the icon arrange | positioned in a timetable setting area | region. (A), (b) is a schematic diagram for demonstrating the mode of the battle | competition along a timetable. (A), (b) is a schematic diagram for demonstrating an example of a game image. It is a flowchart which shows an example of the time table setting process which concerns on Embodiment 1 of this invention. It is a flowchart which shows an example of the battle | competition control process which concerns on Embodiment 1 of this invention. It is a schematic diagram for demonstrating an example of priority command information. (A)-(d) is a schematic diagram for demonstrating an example of intervention operation. It is a schematic diagram for demonstrating the mode of the battle | competition along priority command information and a time table. It is a flowchart which shows an example of the battle | competition control process which concerns on Embodiment 2 of this invention. It is a schematic diagram which shows schematic structure of the game device which concerns on Embodiment 3 of this invention. It is a schematic diagram for demonstrating an example of a reception time table. It is a flowchart which shows an example of the time table transmission / reception process which concerns on Embodiment 3 of this invention. It is a flowchart which shows an example of the battle | competition control process which concerns on Embodiment 3 of this invention. (A) is a schematic diagram for demonstrating an example of battle | competition history information, (b) is a schematic diagram for demonstrating an example of top winner information, (c) demonstrates an example of receiving top winner information. (D) is a schematic diagram for demonstrating an example of comprehensive winner information. It is a flowchart which shows an example of the time table transmission / reception process which concerns on Embodiment 4 of this invention. It is a flowchart which shows an example of the battle | competition control process which concerns on Embodiment 4 of this invention.

  Embodiments of the present invention will be described below. In the following, for ease of understanding, an embodiment in which the present invention is applied to a portable game machine will be described. However, the present invention is similarly applied to information processing apparatuses such as various computers, PDAs, mobile phones, and smartphones. Can be applied. In other words, the embodiments described below are for illustrative purposes and do not limit the scope of the present invention. Therefore, those skilled in the art can employ embodiments in which each or all of these elements are replaced with equivalent ones, and these embodiments are also included in the scope of the present invention.

(Appearance of portable game console)
FIG. 1A and FIG. 1B are schematic views showing the external appearance of a typical portable game machine 1 in which the game device according to the embodiment of the present invention is realized. As shown in FIG. 1A, each part of the portable game machine 1 is incorporated in an upper casing JC and a lower casing KC.
For example, the first display unit 18 and the like are incorporated in the upper casing JC, and the second display unit 19 and the touch panel 20 and the like are incorporated in the lower casing KC.

  The portable game machine 1 is a foldable (clamshell type) device, and an upper housing JC and a lower housing KC are pivotally supported via a joint. In other words, the upper casing JC can be opened and closed, and as shown in FIG. 1A, the upper casing JC is opened and used when playing a game. As shown in b), the upper casing JC is closed. As will be described later, the opening and closing of the upper casing JC can be detected, and the transition from the standby state (suspended state) to the normal state and the transition from the normal state to the standby state can be performed.

(Configuration of portable game machine)
FIG. 2 is a block diagram showing a schematic configuration of the portable game machine 1 described above. Hereinafter, a description will be given with reference to FIG.

  The portable game machine 1 includes a processing control unit 10, a connector 11, a cartridge 12, a wireless communication unit 13, a communication controller 14, a sound amplifier 15, a speaker 16, an operation key 17, and a first display. A unit 18, a second display unit 19, a touch panel 20, and an open / close sensor 21 are provided.

  The processing control unit 10 includes a CPU (Central Processing Unit) core 10a, an image processing unit 10b, an audio processing unit 10c, a VRAM (Video Random Access Memory) 10d, a WRAM (Work RAM) 10e, and an LCD (Liquid Crystal). A display) controller 10f and a touch panel controller 10g.

  The CPU core 10a controls the entire portable game machine 1 while exchanging control signals and data with each connected component. Specifically, a program and data stored in a ROM (Read Only Memory) 12a in the cartridge 12 are read out with the cartridge 12 mounted in the connector 11, and predetermined processing is executed.

  The image processing unit 10b performs image processing on data read from the ROM 12a in the cartridge 12 and data processed by the CPU core 10a, and then stores the data in the VRAM 10d.

  The sound processing unit 10c includes a predetermined number of sound source data and the like, and generates sound effects and music data to be generated according to the progress of the game.

The VRAM 10d is a memory that stores display information, and stores data (image data) that has been subjected to image processing by the image processing unit 10b and the like.
The WRAM 10e stores work data and the like necessary when the CPU core 10a executes various processes according to the program.

  The LCD controller 10f controls the first display unit 18 and the second display unit 19 to display a predetermined display image. Specifically, the LCD controller 10 f converts the image data stored in the VRAM 10 d into a display signal at a predetermined synchronization timing, and outputs the display signal to the first display unit 18 and the second display unit 19. For example, the LCD controller 10 f displays the main game image on the first display unit 18 and displays an operation instruction image (setting image or the like) including an icon or the like on the second display unit 19.

  The touch panel controller 10g detects contact (touch) on the touch panel 20 with a touch pen or a user's finger. For example, in the state where an icon or the like is displayed on the second display unit 19, a contact position or the like on the touch panel 20 is detected, and an operation on the corresponding icon or the like is accepted.

  The connector 11 is a terminal that can be detachably connected to the cartridge 12, and transmits / receives predetermined data to / from the cartridge 12 when the cartridge 12 is connected.

The cartridge 12 includes a ROM 12a and a RAM (Random Access Memory) 12b.
The ROM 12a stores a program for realizing the game and image data, sound data, and the like accompanying the game.
The RAM 12b stores various data indicating the progress of the game.
When the portable game machine 1 is turned on with such a cartridge 12 mounted, the program of the ROM 12a is executed by the CPU core 10a, and the game device of this embodiment is realized.

The wireless communication unit 13 is a unit that performs wireless communication with other portable game machines 1 and a predetermined wireless access point, and transmits / receives predetermined data via an antenna (not shown) (not shown). .
The wireless communication unit 13 is assigned a unique MAC (Media Access Control) address.

The communication controller 14 controls the wireless communication unit 13 and mediates wireless communication performed between the process control unit 10 and the process control unit 10 of another portable game machine 1 according to a predetermined protocol.
Further, when the portable game machine 1 connects to the Internet via a nearby wireless access point or the like, it is performed between the processing control unit 10 and the wireless access point or the like according to a protocol compliant with the wireless LAN. Intermediary of wireless communication. For example, the communication controller 14 may perform wireless communication with another portable game machine 1 via a server on the Internet or the like.

The sound amplifier 15 amplifies the audio signal generated by the processing control unit 10 (audio processing unit 10 c) and supplies it to the speaker 16.
The speaker 16 is composed of, for example, a stereo speaker, and outputs predetermined music sound, sound effect, and the like according to the audio signal amplified by the sound amplifier 15.

  The operation key 17 includes a plurality of key switches and the like appropriately arranged on the portable game machine 1 and receives a predetermined instruction input according to a user operation.

The 1st display part 18 and the 2nd display part 19 consist of LCD etc., are controlled by LCD controller 10f, and display a game image etc. suitably.
The second display unit 19 displays an icon or the like for accepting contact (touch operation) with the touch panel 20.

The touch panel 20 is arranged so as to be superimposed on the front surface of the second display unit 19 and accepts an input by contact with a touch pen or a user's finger.
The touch panel 20 includes, for example, a pressure-sensitive touch sensor panel or the like, and detects a touch operation and its position (touch position) by detecting the pressure of a touch pen or the like. In addition, the touch panel 20 may detect contact with a user's finger or the like from a change in capacitance or the like.

  The open / close sensor 21 detects opening / closing of the upper housing JC. That is, it detects that the opened upper casing JC is closed, and detects that the closed upper casing JC is opened.

(Embodiment 1)
FIG. 3 is a block diagram showing a schematic configuration of the game apparatus 100 according to the first embodiment of the present invention, which is realized by the portable game machine 1 described above. As an example, the game apparatus 100 provides a user with a role-playing game in which a player character (main character) proceeds with an adventure together with one buddy monster character.
In this role-playing game, when an enemy monster character or the like is encountered in the middle of an adventure, the partner monster character, based on a series of commands (time table described later) from the player character (more specifically, the user), Play against the character. As an example, the player character can collect monster characters captured in another dimension (different world) in the game as items (monster items). It is characterized by transforming (changing) the desired monster character and playing against enemy monster characters.
Hereinafter, the game apparatus 100 according to the first embodiment of the present invention will be described in detail.

  As shown in FIG. 3, the game apparatus 100 includes a game information storage unit 110, an operation reception unit 120, a setting unit 130, an acquisition unit 140, a battle control unit 150, an image generation unit 160, and a determination unit 170. And is configured.

First, the game information storage unit 110 stores various information necessary for the game.
For example, the game information storage unit 110 stores object information including images of player characters and various monster characters, current position, HP (life value), MP (magic value), experience value, money held, and attributes. To do. The monster characters include a partner monster character, a captured monster character (a monster character that can be transformed), an enemy monster character, and the like.
In addition, the game information storage unit 110 also stores object information such as trees, rocks, water, and buildings that form the game field.

In addition, the game information storage unit 110 stores a time table for instructing a partner monster character for a battle procedure. This time table is a table for determining a series of battle contents commanded to a partner monster character (more specifically, a monster character to be transformed) at the time of a battle with an enemy monster character.
Specifically, the game information storage unit 110 stores a time table TL as shown in FIG. In this time table TL, a combination of a monster character for transforming a partner monster character and a command (command) to be executed by the monster character can be set corresponding to each slot (slots 1 to 6). ing.
The slot indicates one battle period (battle time) as a minimum unit. For this reason, the time table TL can define up to six battles. The number of slots is an example and can be changed as appropriate.

The monster character that can be set in the time table TL is, for example, a monster character (owned monster item) captured in another dimension in the game. The monster character that can be set is not limited to the monster character captured in such another dimension, and can be changed as appropriate.
In other words, in the time table TL, it is possible to set up to a predetermined number of combinations of a monster character that transforms a partner monster character and a command that is executed by the monster character in a monster item owned by the player character. ing.
Then, prior to the start of the battle, the user considers the strength and attributes of the opponent's enemy monster character and the like, and gives an effective monster character and its command to counter this time table TL. To place. In FIG. 4, monster characters and commands are indicated by their names, but this is for ease of explanation. Actually, each identification information (monster ID, command ID, etc.) ) Is stored.
A method for setting the time table TL will be described in detail in the setting unit 130 described later. The game information storage unit 110 also stores various symbols, icons, and the like that are used for display (setting images described later) when the setting unit 130 sets the time table TL.
Note that the above-described WRAM 10e or the like can function as such a game information storage unit 110.

Returning to FIG. 3, the operation reception unit 120 receives an operation input by the user. That is, various operations for proceeding with the game are sequentially accepted.
For example, the operation reception unit 120 receives an operation for appropriately moving (desired action) a player character or the like in the game field. In addition, when an enemy monster character or the like is encountered while moving, the battle starts. Prior to the battle, the operation reception unit 120 sets the monster character or the like in the time table TL described above. An operation for accepting is accepted.
The operation keys 17 and the touch panel 20 described above can function as such an operation receiving unit 120.

Prior to the start of the battle, the setting unit 130 sets a monster character or the like in the time table TL of the game information storage unit 110 described above according to the operation instruction received by the operation receiving unit 120.
In the following, the setting by the setting unit 130 will be described as an example in which the image generation unit 160 described later displays a setting image as shown in FIG. 5A on the second display unit 19 described above. explain.
As shown in FIG. 5A, the setting image includes a time table setting area TSA, a determination button KB, and a monster selection area MSA. The setting unit 130 sets a monster character or the like in the time table setting area TSA (finally the time table TL) in accordance with an operation instruction from the user in a state where such a setting image is displayed.

The time table setting area TSA is divided into six slots ST as an example. One slot ST indicates one battle period. Therefore, a maximum of 6 battle procedures can be set in the time table setting area TSA. That is, such a time table setting area TSA is the basis of the time table TL stored in the game information storage unit 110.
In the monster selection area MSA, a monster symbol MS and a command (command) symbol CS are arranged to be selectable.
As an example, the monster symbol MS indicates a symbol of a monster character captured in another dimension in the game. That is, the monster symbol MS corresponding to the monster item captured by the player character (user) is arranged.
A plurality of command symbols CS are arranged under the monster symbol MS and indicate the contents of techniques (such as attack techniques) that can be used by the monster character. For example, the command symbol CS includes various attack techniques such as lightning, flame, ice (snowstorm), and wind (tornado). The number on the lower right in the command symbol CS represents the amount of use (necessary amount) of the slot ST. It should be noted that such a method of displaying the usage amount is arbitrary and can be changed as appropriate. For example, the usage amount of the slot ST may be displayed with a dice instead of a number.

The user can arbitrarily select a combination of a monster symbol MS and a command symbol CS from such a monster selection area MSA.
As an example, as illustrated in FIG. 5B, when the touch pen TP is operated by the user and the monster symbol MS1 and the command symbol CS1 thereunder are selected via the touch panel 20, the setting unit 130 An icon IC (IC1) obtained by combining them is arranged in the slot ST in the time table setting area TSA. As an example, the icon ICs are arranged in order from the leftmost slot ST.
Subsequently, as illustrated in FIG. 5C, when the monster symbol MS2 and the command symbol CS2 below the monster symbol MS2 are selected, the setting unit 130 sets the icon IC2 obtained by combining them to the next (right adjacent to the right). ) Place in slot ST. In this case, since the lower right number in the command symbol CS2 is 2 (the usage amount of the slot ST is 2), the icon IC2 has a horizontally long shape using two slots ST.

In addition, when the setting unit 130 arranges such icon ICs in the time table setting area TSA, the relationship between the preceding and following icon ICs, that is, the set of monster characters set in adjacent slots and the instructions thereof are previously stored. When the set permutation matches, the setting unit 130 replaces both icon ICs with another icon IC generated. That is, when the relationship between the monster character selected earlier and the command thereof and the monster character selected later and the command thereof is a predetermined combo skill (combination attack technique), Replace with icon IC.
For example, when the icon IC3 and the icon IC4 as shown in FIG. 6A have a combo technique relationship, the setting unit 130 replaces them with an integrated icon IC5 as shown in FIG. 6B. .
This is because the attack technique (for example, tornado) of the monster character representing the icon IC3 and the attack technique (for example, flame) of the monster character represented by the icon IC4 are defined as combo techniques. Such a combo technique is in a secret state until it is actually used (activated) in the game. That is, when such a combination of a monster character and an attacking technique are used in an actual battle, it is activated as a combo technique and becomes clear to the user.
Therefore, the icon IC5 integrated as shown in FIG. 6B is replaced only when the combo technique has been activated, and is integrated when the combo technique has not been activated (when initially selected). Instead, as shown in FIG. 6A, the icons IC3 and IC4 are arranged as they are.

Depending on the combo technique, the number of slots after integration may increase or decrease from the number of slots before integration (total).
For example, when the icon IC6 and the icon IC7 as shown in FIG. 6C are in a combo technique (already activated), the setting unit 130 integrates them as shown in FIG. 6D. Replace with icon IC8. In this case, the number of slots (2 slots) used by the icon IC8 after integration is smaller than the number of slots (3 slots) used by the icons IC6 and IC7 before integration.
On the other hand, the number of icon IC slots after integration may be greater than the number of icon IC slots before integration.

In this way, the user selects a desired monster character and command, and sequentially arranges corresponding icon ICs in the time table setting area TSA (each slot ST). When the placement of the icon IC in each slot ST is completed and the determination button KB is operated, the setting unit 130 generates a time table TL from the time table setting area TSA and stores it in the game information storage unit 110. To do. That is, each icon IC in the time table setting area TSA is converted into monster character identification information (monster ID) and command identification information (command ID) and set in each slot of the time table TL.
Further, when the determination button KB is operated in a state where there is a vacancy in the slot ST (icon IC is not arranged), the setting unit 130 appropriately assigns a monster character and a command to the vacant slot ST according to predetermined logic or the like. After setting, a time table TL is generated and stored in the game information storage unit 110.
The above-described CPU core 10a, WRAM 10e, and the like can function as such a setting unit 130.

Returning to FIG. 3, the acquisition unit 140 acquires a time table of the opponent side (enemy monster character side) to be played. The time table on the enemy monster character side has the same configuration as the time table TL in FIG. 4 described above.
When the user is playing this game alone (in the case of a single player), since it is a CPU battle, the acquisition unit 140 appropriately generates a time table according to a predetermined logic or the like, and the time The table is acquired as a time table on the enemy monster character side.
On the other hand, when the user is playing this game so as to be able to play against other users (in the case of multiple players), the acquisition unit 140 receives another game device via the wireless communication unit 13 or the like described above. The time table of the enemy monster character sent from 100 is acquired. At this time, the game device 100 is not limited to a direct wireless battle between neighboring game devices 100, and there may be a battle with the remote game device 100 connected via the Internet or the like. Therefore, the acquisition unit 140 acquires the time table on the enemy monster character side from another nearby or remote game device 100 (game device 100 corresponding to the encountered enemy monster character).
The CPU core 10a, the wireless communication unit 13, the communication controller 14, and the like described above can function as such an acquisition unit 140.

The battle control unit 150 controls the battle between monster characters based on the enemy ally and both time tables.
That is, the battle control unit 150 is similar to the time table TL (set by the setting unit 130) stored in the game information storage unit 110 and the time table (time table TL) on the enemy monster character side acquired by the acquisition unit 140. Monster characters are played against each other on the basis of the above.
Specifically, as shown in FIG. 7A, the battle control unit 150, based on the ally time table TL 1 and the enemy time table TL 2, monster characters in the same slot in order from the slot 1. Let's play. For example, in the battle of slot 1, the genie A of the time table TL1 on the ally side and the monster G of the time table TL2 of the enemy side are made to fight against each other (thunder, snowstorm). That is, the genie A is subjected to a lightning attack toward the phantom G, and the monster G is subjected to a snowstorm attack toward the genie A.
Note that the battle control unit 150 determines the first attack or the second attack based on the information of the partner monster character and the information of the enemy monster character, for example. As an example, it is determined based on the magnitude of experience values in both sides and other information (for example, magnitude such as a quickness value), and is maintained during a series of battles (all slots). In addition, how to decide such a first / second attack is arbitrary and can be changed as appropriate. In addition, the first attack and the second attack may be determined for each slot. For example, a random number may be generated each time for each slot, and the first and second attacks may be determined according to the value.
In addition, when performing such an attack, the battle control unit 150 calculates the damage received by the opponent and subtracts it from the opponent's HP (life value) stored in the game information storage unit 110.

Further, as shown in FIG. 7 (b), the battle control unit 150, when an instruction (flame) for two slots is set in the slots 2 and 3 of the timetable TL1 on the ally side, In the battle of slot 2, control is performed so that the attack from the dragon god H of the enemy timetable TL2 is not performed, but the attack from the bird Beast B of the ally timetable TL1 is not performed. And in the battle | competition of slot 3, the birds and beasts B of timetable TL1 and the wind god I of timetable TL2 are made to battle | combine by each command (flame, wind).
That is, in the case of an instruction using a plurality of slots, the instruction is activated in the last slot (the last slot among the plurality of slots).
In addition, the battle control unit 150 activates the combo technique when the combination of the character and the command set in the adjacent slots in the time table has the above-described combo technique relationship (not activated). , Attack the other side. Also in this case, since the combo technique spans a plurality of slots, the combo technique is activated in the last slot (the last slot among the integrated slots).
The above-described CPU core 10a and the like can function as such a battle control unit 150.

Returning to FIG. 3, the image generation unit 160 generates a game image (field image and battle image), a setting image, and the like.
For example, the image generation unit 160 generates a field image as illustrated in FIG. 8A according to each object information stored in the game information storage unit 110, an instruction (operation instruction) received by the operation reception unit 120, and the like. To do. That is, a game image in which a partner monster character or the like is moving according to a user operation is generated.
Further, the image generation unit 160 generates a battle image as shown in FIG. 8B in accordance with each object information stored in the game information storage unit 110, battle control by the battle control unit 150, and the like. That is, the image generation unit 160 sequentially generates a battle state between the monster characters controlled by the battle control unit 150 based on the timetables of the enemy and allies.
Further, the image generation unit 160 generates a setting image for setting a time table before such a battle is started. That is, the image generation unit 160 sets the setting images as shown in FIGS. 5A to 5C described above according to the symbols and icons stored in the game information storage unit 110, the setting status by the setting unit 130, and the like. Is generated.
The image generation unit 160 displays game images (field images and battle images) as shown in FIGS. 8A and 8B on the first display unit 18 described above, while FIG. ) To (c) are displayed on the second display unit 19 described above. That is, the setting image is displayed on the second display unit 19 so that the user can operate it via the touch panel 20 described above.
The image processing unit 10b described above can function as such an image generation unit 160.

Returning to FIG. 3, the determination unit 170 determines the victory or defeat of the user (player character) based on the result of the battle control by the battle control unit 150.
For example, when the HP of any monster character becomes zero in the middle of a battle between enemy monster characters controlled by the battle control unit 150 based on each time table, each win / loss is determined. That is, the player character whose HP value is zero is determined as the loser, and the player character whose HP value remains is determined as the winner.
The determination unit 170 appropriately updates the information stored in the game information storage unit 110 based on such a determination result.
For example, when the ally side wins, the determination unit 170 updates the experience value and possession money of the partner monster character or the like stored in the game information storage unit 110 as appropriate. On the other hand, when the ally side loses, the determination unit 170 performs an update such as halving the money held by the partner monster character or the like. The data update target at the time of winning or losing is arbitrary and can be changed as appropriate.
The CPU core 10a and the like described above can function as such a determination unit 170.

(Game device operation)
Hereinafter, the operation of the game apparatus 100 having such a configuration will be described with reference to the drawings. FIG. 9 is a flowchart illustrating an example of a time table setting process executed by the game device 100 according to the first embodiment of the present invention. FIG. 10 is a flowchart showing an example of a battle control process executed by the game apparatus 100.
First, the time table setting process will be described with reference to FIG. This time table setting process is started when a partner monster character or the like moving in the game field encounters an enemy monster character.

First, the game device 100 displays a setting image for setting a time table (step S201).
Specifically, the image generation unit 160 displays the setting image as shown in FIG. 5A described above on the second display unit 19. That is, a setting image including the time table setting area TSA, the determination button KB, and the monster selection area MSA is displayed so as to be operable via the touch panel 20.

The game device 100 determines whether or not a touch operation has been performed (step S202). That is, the operation reception unit 120 determines whether or not the touch panel 20 is pressed with a touch pen or the like.
If it is determined that there is no touch operation (step S202; No), the game apparatus 100 continues to repeat the touch operation determination.

On the other hand, when it is determined that there is a touch operation (step S202; Yes), the game device 100 determines whether or not the touch operation is directed to a symbol such as a monster (step S203).
Specifically, the setting unit 130 determines whether or not a touch operation has been performed in the monster selection area MSA as illustrated in FIG. That is, it is determined whether or not an instruction to select each monster symbol MS or each command symbol CS in the monster selection area MSA has been issued.
When determining that the touch operation is directed to a symbol such as a monster (step S203; Yes), the game device 100 generates an icon corresponding to the touch operation and places it in the slot (step S204).
For example, as shown in FIG. 5B described above, when a monster symbol MS1 and a command symbol CS1 below it are selected by a touch operation, the setting unit 130 generates an icon IC1 that combines them. And placed in the slot ST in the time table setting area TSA.
At that time, the image generation unit 160 sequentially generates (updates) setting images according to the touch operation by the user and the arrangement of the icon IC by the setting unit 130. That is, as shown in FIGS. 5B and 5C, the setting images are sequentially updated according to the touch operation by the user and displayed on the second display unit 19.
Although the description is omitted below, the image generation unit 160 generates (changes) such a setting image according to the touch operation by the user or the placement (including integration) of the icon IC by the setting unit 130. ) Continue.

The game device 100 compares the front and rear icons arranged in the slot (step S205).
That is, the setting unit 130 compares the icon IC arranged this time with the icon IC arranged immediately before (previous) in the time table setting area TSA.
For example, as shown in FIG. 6A described above, when the current icon IC4 is arranged subsequent to the icon IC3 arranged last time, the icons IC3 and IC4 before and after are compared.
Note that when the first icon IC is arranged in the time table setting area TSA this time, there is no comparison target, so the processing returns to step S202 as it is.

The game device 100 determines whether or not there is a combo from the icons before and after the comparison (step S206).
That is, the setting unit 130 defines the relationship between the icon ICs before and after the comparison, that is, the relationship between the previously selected monster character and its command and the later selected monster character and its command as a combo technique. To determine if As described above, the combo technique is in a secret state if it has not been used once in an actual battle (if it has not been activated). For this reason, it is determined that it is not defined as a combo technique when it is not activated. That is, it is determined that the combo technique is defined only when it is already activated.
When it is determined that the front and rear icons are not defined as combo techniques (step S206; No), the game device 100 returns the process to step S202 described above.

On the other hand, when it is determined that the front and rear icons are defined as combo techniques (step S206; Yes), the game device 100 integrates the front and rear icons (step S207).
Specifically, when the front and rear icons IC3 and IC4 shown in FIG. 6A are defined as combo techniques (already activated), the setting unit 130 integrates them as shown in FIG. 6B described above. Replace with icon IC5.
Note that when such integration is performed, the number of slots used may increase or decrease. For example, when the preceding and following icons IC6 and IC7 shown in FIG. 6C are defined as combo techniques (already activated), the setting unit 130 integrates as shown in FIG. 6B described above. Replace with the icon IC8. At this time, the number of slots of the integrated icon IC8 (2 slots) is smaller than the number of slots (3 slots) of the icons IC6 and IC7 before integration.
And the game device 100 returns a process to step S202 mentioned above.

When it is determined in step S203 described above that the touch operation is not directed to a symbol such as a monster (step S203; No), the game apparatus 100 is directed to the determination button. It is determined whether or not there is (step S208).
Specifically, the setting unit 130 determines whether or not a touch operation has been performed on the determination button KB as illustrated in FIG. That is, it is determined whether or not the decision button KB for confirming the setting of the time table has been touched.
If it is determined that the touch operation is not directed to the enter button (step S208; No), the game device 100 returns the process to step S202 described above. For example, if it is a touch operation to a position that is not an operation target such as a blank or the like, the process returns to step S202 without performing any process, and the determination of the touch operation is repeated.
Although omitted in this flowchart, if the touch operation is directed toward another operation target, the game apparatus 100 appropriately performs processing according to the touch operation. For example, in the case of a touch operation toward a placed icon IC in the time table setting area TSA, the setting unit 130 appropriately corrects the icon IC, that is, reselects the monster symbol MS and the command symbol CS. Shall.

On the other hand, when it is determined that the touch operation is directed to the enter button (step S208; Yes), the game device 100 generates a time table from each icon (step S209).
That is, the setting unit 130 generates the time table TL as shown in FIG. 4 described above in accordance with each icon IC arranged in the time table setting area TSA and stores it in the game information storage unit 110. That is, each icon IC is converted into monster character identification information (monster ID) and command identification information (command ID) and set in each slot of the time table TL.
Then, the game device 100 ends the time table setting process.

  By such a time table setting process, the user can arbitrarily select a monster character or the like and set it in the time table. That is, in consideration of the strength and attributes of the opponent's enemy monster character and the like, the monster character and its command to counter it are set in the time table. Specifically, the user sets a strategy for the battle with the enemy monster character, and sets the battle procedure according to the strategy in the time table.

  Next, the battle control process will be described with reference to FIG. This battle control process is subsequently started after the time table setting process of FIG. 9 is completed.

  First, the game device 100 reads the time table on the ally side (step S301). That is, the battle control unit 150 reads the time table TL as shown in FIG. 4 (set by the setting unit 130) stored in the game information storage unit 110.

The game device 100 acquires the enemy time table (step S302). That is, the acquisition unit 140 acquires a time table of the opponent side (enemy monster character side) to be played.
For example, when the user is playing this game alone, the acquisition unit 140 appropriately generates a time table according to a predetermined logic or the like, and acquires the time table as a time table on the enemy monster character side.
On the other hand, when the user is playing so as to be able to play against other users, the acquisition unit 140 receives another game device 100 (the game device 100 corresponding to the encountered enemy monster character) via the wireless communication unit 13 or the like. The time table of the enemy monster character sent from) is acquired.

The game apparatus 100 sets an initial value 1 to a variable i for managing the progress of the battle (step S303).
That is, the battle control unit 150 sets 1 to the variable i that manages the current slot in order to match each monster character with each other using each time table of the enemy ally.

Game device 100 reads the data of slot i from each time table (step S304).
That is, the battle control unit 150 reads the data set in the i-th slot from each enemy timetable.
More specifically, for example, if the variable i is 1, the battle control unit 150, as shown in FIG. 7A described above, the monster set in the slot 1 from the timetable TL1 on the ally side. Read the character (genie A) and its command (thunder). Subsequently, the monster character (monster G) set in slot 1 and its command (snowstorm) are read from the enemy time table TL2.
If the variable i is 2, similarly, the battle control unit 150, as shown in FIG. 7B described above, from the timetable TL1 on the ally side, B) and its command (flame) are read out, and then the monster character (Ryujin H) set in slot 2 and its command (fire) are read out from the enemy time table TL2.

The game device 100 transforms the monster character on the first attack side, and performs an attack or the like in accordance with the command (step S305).
For example, the battle control unit 150 first determines the first and second attack from the information of the partner monster character and the information of the enemy monster character. For example, how to decide the first or second attack is decided based on the experience value in both sides and other information (eg, the magnitude of the quickness value), and during this series of battles (all slots) ) To be maintained. In addition, how to decide such a first / second attack is arbitrary and can be changed as appropriate. In addition, the first attack and the second attack may be determined for each slot. For example, a random number may be generated each time for each slot, and the first and second attacks may be determined according to the value.
Then, when the first-attack / second-last attack is determined (or determined), the battle control unit 150 transforms the first monster to the read monster character, and performs an attack or the like in accordance with the read command. For example, as shown in FIG. 7A, in the state where the data in slot 1 is being read, if the first player is the ally (timetable TL1), the battle control unit 150 transforms the partner monster character into the genie A. And let the enemy monster character take a lightning attack.
Also, the battle control unit 150 calculates the damage on the attacking side that has been attacked, and subtracts the value from the HP on the attacking side stored in the game information storage unit 110. In addition, when HP becomes negative by subtraction, it is set to 0 instead of a negative value.
At that time, the image generation unit 160 sequentially generates (updates) battle images according to such transforms and attacks. For example, the battle image as shown in FIG. 8B described above is sequentially updated so that the first player transforms into a monster character, the first player attacks the second player, and the second player receives damage. And displayed on the first display unit 18.
Although description is omitted below, the image generation unit 160 continues to generate (change) such battle images in accordance with the battle control performed by the battle control unit 150.

The game device 100 determines whether or not the HP of the last-attack monster character is greater than 0 (step S306).
That is, the battle control unit 150 determines whether the HP of the monster character on the attacking side that has received the attack or the like has a remaining amount.

If it is determined that the HP of the attacking monster character is greater than 0 (step S306; Yes), the game apparatus 100 transforms the attacking monster character and performs an attack in accordance with the command (step S307). .
In other words, reverse the offense and defense. That is, the battle control unit 150 transforms the next attack side to the read monster character, and performs an attack or the like according to the read command. For example, as shown in FIG. 7 (a), if the enemy side (time table TL2) is the next attack while the data in slot 1 is being read, the enemy monster character is transformed into the monster G, and a snowstorm attack is performed. Show your partner monster character.
Also, the battle control unit 150 calculates the damage of the first player who has been attacked, and subtracts that value from the first player's HP. Here again, if the HP becomes negative due to the subtraction, the HP is set to 0 without setting the negative value.

The game device 100 determines whether the HP of the first monster character is greater than 0 (step S308).
That is, the battle control unit 150 determines whether or not there is a remaining amount in the HP of the first monster character that has received an attack or the like.

  If the game device 100 determines that the HP of the first monster character is greater than 0 (step S308; Yes), the game device 100 adds 1 to the variable i (step S309).

Game device 100 determines whether or not variable i after addition is larger than 6 (step S310). That is, it is determined whether or not the battle up to slot 6 has been completed.
If it is determined that the variable i is 6 or less (step S310; No), the game device 100 returns the process to step S304 described above and repeats the battle of the subsequent slot i. On the other hand, when it is determined that the variable i is larger than 6 (step S310; Yes), the game device 100 returns the process to the above-described step S303 and repeats the battle from the first slot.

In addition, when it is determined that the HP on the side that has been attacked (the second attack side, the first attack side) is 0 in Steps S306 and S308 described above (Steps S306 and S308; No), the game device 100 wins or loses. Determination is made (step S311).
That is, the determination unit 170 determines each victory or loss based on which monster character of the enemy ally has become zero. That is, the player character side with the HP value of zero is determined as the loser, and the player character side with the HP value remaining is determined as the winner.

The game device 100 determines whether or not the victory is on the ally side (step S312).
That is, the determination unit 170 determines whether or not there is a remaining amount on the ally's HP and the enemy's HP becomes zero and the ally determines that the ally is a winner.
If it is determined that the game apparatus 100 is a victory on the ally side (step S312; Yes), the game apparatus 100 increases the experience value and the money held (step S315). That is, the determination unit 170 updates the experience value and the money of the partner monster character or the like stored in the game information storage unit 110 by appropriately increasing the value. The data update target at the time of victory is arbitrary and can be changed as appropriate.

  On the other hand, when it is determined that the ally side is defeated (enemy side victory) (step S312; No), the game device 100 halves the money held (step S316). That is, the determination unit 170 performs an update such as halving the money held by the partner monster character or the like stored in the game information storage unit 110. The data update target at the time of defeat is arbitrary and can be changed as appropriate.

Through such battle control processing, battles between enemy monster characters can be performed along both timetables. That is, the ally monster character performs an attack or the like along a time table set by the user, and the enemy monster character attacks or the like along a time table set by another user (or the CPU core 10a). I do.
For this reason, the user can enjoy a series of battles, including whether or not the strategy he has established is effective for the enemy monster character.

(Embodiment 2)
In the first embodiment, the case where each battle is controlled according to the set timetable has been described. However, the player character (user) may be able to intervene appropriately during the battle.
Hereinafter, the game apparatus 100 according to Embodiment 2 of the present invention will be described, which is capable of giving a new instruction (intervention operation) to a monster character waiting for a battle even after the battle is started. .
The configuration of the game device 100 according to the second embodiment of the present invention is the same as the game device 100 according to the first embodiment shown in FIG. 3 described above.
However, the game information storage unit 110, the operation reception unit 120, the battle control unit 150, and the image generation unit 160 further include the following contents.

The game information storage unit 110 further stores priority command information YC as shown in FIG. The priority command information YC indicates a priority command for a slot (a monster character waiting for a battle) that is not executed on the time table TL. Specifically, the priority command information YC is based on the strategy (that is, the timetable TL) originally set by the user, but the battle is advanced, but the ally side is inferior to the expectation (for example, the remaining HP) If the amount is small, etc.), HP recovery is instructed as a priority command.
Note that the content of the superiority command can be changed as appropriate. For example, it may be contents such as use of a tool, escape (completion of a match), and the like. In FIG. 11, the priority instruction is indicated by its name, but this is for ease of explanation, and in fact, the identification information (command ID, etc.) of the instruction is stored. To do.
The priority command information YC is set based on the intervention operation received during the battle in the operation receiving unit 120 described below.

  The operation reception unit 120 can receive a predetermined operation from the user after the battle is started. That is, the operation reception unit 120 can receive an intervention operation directed to a monster character waiting for a battle on the time table TL. The details of the intervention operation will be described together with the image generation unit 160 below.

When the battle is started, the image generation unit 160 generates a battle operation image that allows an intervention operation to be input. That is, the image generation unit 160 generates a battle operation image in parallel with the generation of the battle image as shown in FIG. The image generation unit 160 displays the generated battle operation image on the second display unit 19 so as to be operable via the touch panel 20.
Specifically, the image generation unit 160 generates a battle-time operation image as shown in FIG. As an example, the battle operation image includes a time table display TH, a plurality of intervention buttons IB, and the like.

The time table display TH represents the contents of the time table on the ally side and the progress of the battle. The content of the time table indicates the battle content (monster character and its command) set in each slot based on the time table TL stored in the game information storage unit 110 with an icon IC. On the other hand, the progress of the battle indicates to which slot the battle is currently progressing by the progress gauge SG. Note that the icon IC reached by the progress gauge SG (the icon IC on the progress gauge SG) is excluded from the intervention operation, and may be changed to a gray display or the like.
Each intervention button IB indicates the content of an intervention operation that can be performed by the user. Each intervention button IB in FIG. 12A indicates the content (classification or the like) of the uppermost layer in the intervention operation, and specific details of the intervention operation are associated with each lower layer. That is, when any intervention button IB is operated, an intervention button IB indicating the content of a specific intervention operation as a lower layer is similarly displayed.
Hereinafter, an intervention operation performed in a state where such a battle operation image is displayed on the second display unit 19 will be specifically described.

  As an example, as illustrated in FIG. 12B, when the user operates the touch pen TP and presses the icon IC3 and the intervention button IB1 (magic), the operation reception unit 120 is connected via the touch panel 20. Accept these interventions. That is, the monster character etc. set to the slot to intervene and the instruction content (classification etc. here) by intervention are accepted. Note that slots that allow intervention are limited to slots that the progress gauge SG has not reached. In other words, the priority command can be instructed only when facing the monster character (icon IC) waiting for the battle. Therefore, when the icon IC that the progress gauge SG has reached is selected, the operation reception unit 120 may skip the operation after making a predetermined error sound.

As described above, since the specific content of the intervention operation is associated with the lower layer of the intervention button IB1, the image generation unit 160 generates an operation image during battle as shown in FIG. . This battle operation image is an image in which the intervention buttons IB11 to IB14 (contents below the intervention button IB1), the return button RB, and the decision button KB are changed without changing the time table display TH. .
As an example, as illustrated in FIG. 12D, when the touch pen TP is operated by the user and the intervention button IB 12 (recovery) and the determination button KB are pressed, the operation reception unit 120 displays the touch panel 20. The intervention operation is accepted. That is, a recovery command to the slot 4 (icon IC3) is received, the slot and the command are set in the priority command information YC as shown in FIG. 11 and stored in the game information storage unit 110.

The battle control unit 150 controls the battle between monster characters based on the timetables of the enemy teammates and the priority command information YC.
For example, when the priority command information YC shown in FIG. 11 described above is set by the intervention operation, the battle control unit 150 is more effective than the command (lightning) in the time table TL1 in the battle of slot 4 shown in FIG. Priority is given to the priority instruction (recovery) of the priority instruction information YC. That is, in the slot 4, monster characters are made to fight against each other based on the time table TL1 (dinosaur D) + priority command (recovery) on the ally side and the time table TL2 (dinosaur J and fire) on the enemy side.
Note that such priority instructions may not always be accepted. That is, even if the priority command information YC is set by the intervention operation described above, the priority command may be rejected at a predetermined rate or the like. For example, the battle control unit 150 rejects the priority command at a predetermined ratio or the like based on the whimsiness value of the partner monster character, a random number, or the like, and performs an attack or the like with the command of the time table TL1.

Hereinafter, an operation of the game apparatus 100 that further performs such contents will be described with reference to the drawings. FIG. 14 is a flowchart illustrating an example of a battle control process executed by the game device 100 according to the second embodiment of the present invention. This battle control process is subsequently started after the time table setting process (FIG. 8) is completed as in the first embodiment.
In the battle control process of FIG. 14, the same reference numerals are assigned to the same processing contents as the battle control process of the first embodiment (FIG. 9).

First, the game device 100 reads the time table on the ally side (step S301), and acquires the time table on the enemy side (step S302).
The game apparatus 100 sets an initial value 1 to a variable i for managing the progress of the battle (step S303).

The game device 100 determines whether priority command information is set (step S401). That is, it is determined whether or not the priority command information YC as shown in FIG. 11 described above is stored in the game information storage unit 110. That is, it is determined whether or not an intervention operation has been performed after the battle is started.
If it is determined that the priority command information is not set (step S401; No), the game device 100 advances the process to step S304 described later.
On the other hand, when it is determined that the priority command information is set (step S401; Yes), the game device 100 reads the priority command information YC from the game information storage unit 110 (step S402).

Game device 100 reads the data of slot i from each time table (step S304).
The game device 100 transforms the monster character on the first attack side, and performs an attack or the like in accordance with the command (step S305).
At this time, when the priority instruction information YC is read in step S402 described above and the friend side is the first player, the priority instruction of the priority instruction information YC is given priority over the instruction of the time table TL1. The details of the processing when the priority instruction is used will be described again after the intervention operation processing described later is described.

The game device 100 determines whether or not the HP of the last-attack monster character is greater than 0 (step S306).
If it is determined that the HP of the attacking monster character is greater than 0 (step S306; Yes), the game apparatus 100 transforms the attacking monster character and performs an attack in accordance with the command (step S307). .
At this time, if the priority instruction information YC is read in the above-described step S402, and the ally side is a late attack, the priority instruction of the priority instruction information YC is given priority over the instruction of the time table TL1. The details of the processing when the priority instruction is used will be described again after the intervention operation processing described later is described.

The game device 100 determines whether the HP of the first monster character is greater than 0 (step S308).
When it is determined that the HP of the first monster character is greater than 0 (step S308; Yes), the game device 100 determines whether or not an intervention operation has been performed (step S403).
That is, in a state where the image generation unit 160 generates the battle operation image as illustrated in FIG. 12A and displays the operation image on the second display unit 19, the operation reception unit 120 receives the operation from the user. Determine whether the operation has been accepted. Each intervention button IB in FIG. 12A indicates the contents (classification, etc.) of the uppermost layer in the intervention operation, and specific intervention operation contents that can be instructed are associated with each lower layer. ing.
If it is determined that no intervention operation has been performed (step S403; No), the game device 100 advances the process to step S309 described later.

On the other hand, when it is determined that an intervention operation has been performed (step S403; Yes), the game device 100 sets priority command information according to the intervention operation (step S404).
For example, as illustrated in FIG. 12B described above, when the touch pen TP is operated by the user and the icon IC3 and the intervention button IB1 (magic) are pressed, the operation reception unit 120 is connected via the touch panel 20. The contents of the instructions (classification in this case) are accepted. At this time, the slots that allow the intervention operation are limited to slots that the progress gauge SG has not reached, and when an icon IC that has reached the progress gauge SG is selected, after a predetermined error sound or the like is generated. The operation reception unit 120 skips the operation.
Further, specific contents of the intervention operation are associated with the lower layer of the intervention button IB1, and the image generation unit 160 generates an operation image at the time of battle as shown in FIG.
Then, as illustrated in FIG. 12D described above, when the touch pen TP is operated by the user and the intervention button IB12 (recovery) and the determination button KB are pressed, the operation reception unit 120 passes through the touch panel 20. And accepting the intervention operation. That is, a recovery command to the slot 4 (icon IC3) is received, the slot and the content of the command are set in the priority command information YC as shown in FIG. 11 and stored in the game information storage unit 110.

The game device 100 adds 1 to the variable i (step S309), and determines whether or not the variable i after the addition is larger than 6 (step S310).
If it is determined that the variable i is 6 or less (step S310; No), the game device 100 returns the process to step S304 described above and repeats the battle of the subsequent slot i. On the other hand, when it is determined that the variable i is larger than 6 (step S310; Yes), the game device 100 returns the process to the above-described step S303 and repeats the battle from the first slot.

When priority command information is set in step S404 described above, the battle control unit 150 determines that a battle between monster characters is prioritized during an attack on the ally side in any of steps S305 and S307 described above. Control with instruction information.
For example, when the priority command information YC shown in FIG. 11 described above is set, the battle control unit 150 has priority command over the command (thunder) in the time table TL1 in the battle of slot 4 shown in FIG. The priority instruction (recovery) of information YC is given priority. That is, in the slot 4, monster characters are made to fight against each other based on the time table TL1 (dinosaur D) + priority command (recovery) on the ally side and the time table TL2 (dinosaur J and fire) on the enemy side.
Also, as described above, such priority instructions may not necessarily be accepted. That is, even if the priority command information YC is set by the intervention operation described above, the priority command may be rejected at a predetermined rate or the like. For example, the battle control unit 150 rejects the priority command at a predetermined ratio or the like based on the whimsiness value of the partner monster character, a random number, or the like, and performs an attack with the command of the time table TL1.

In addition, when it is determined that the HP on the side that has been attacked (the second attack side, the first attack side) is 0 in Steps S306 and S308 described above (Steps S306 and S308; No), the game device 100 wins or loses. Determination is made (step S311).
The game device 100 determines whether or not the victory is on the ally side (step S312), and if it is determined that the victory is on the ally side (step S312; Yes), the experience value or the money is increased (step S315). .
On the other hand, when it is determined that the ally side is defeated (enemy side victory) (step S312; No), the game device 100 halves the money held (step S316).

  Such a battle control process allows the user to intervene as appropriate when a battle is being performed along the time table of the enemy teammate. For example, when a battle is advanced according to the strategy that the user originally set (that is, the time table TL), but the strategy appears behind the scenes, the intervention operation is performed to the monster character that is waiting for the battle. To give priority instructions. Therefore, the user does not look at the state of the battle casually, but observes the battle with a sense of tension so that the intervention operation can be performed at any time according to the situation of the battle.

In the second embodiment, the case where the priority instruction by the intervention operation is executed by replacing the slot (specified slot) has been described. However, the priority instruction is separately executed (invoked) while the contents of the slot remain unchanged. You may do it.
For example, intervention operations can be performed at any time until the end of the battle (except in the case where the MP required for the intervention operation is insufficient or the magic that makes the intervention operation impossible is applied). It may be activated while moving from the end of the slot to the next slot in the timetable on the ally side.
Specifically, as shown in FIG. 12B described above, the selection of the icon IC (IC3) is unnecessary, and the priority command by the intervention operation performed before the progress gauge SG proceeds to the next slot is the current command. Fired while moving from the end of a slot to the next slot. For example, when the priority command YC in FIG. 13 described above is set by an intervention operation during execution of the slot 4, the battle control unit 150 finishes the battle of the slot 4 and moves to the slot 5 before the priority command information YC is prioritized. Command (recover) is executed.
In the second embodiment, the case where the priority instruction is rejected at a predetermined ratio or the like has been described. However, the priority instruction is always executed, and the content set in the time table is changed. You may make it reject at a predetermined ratio.

(Embodiment 3)
In the first and second embodiments, the battle in the role-playing game has been described. However, the battle may be performed with another user (other game device) regardless of the progress of the game.
In the following, the embodiment of the present invention is characterized in that, regardless of the progress of the game, each other's time tables are exchanged (transmitted / received) using wireless communication so that a battle with an unknown opponent can be performed. 3 will be described with reference to FIG.

As shown in FIG. 15, the game apparatus 500 includes a game information storage unit 110, an operation reception unit 120, a setting unit 130, a communication unit 540, a battle control unit 150, an image generation unit 160, and a determination unit 170. And is configured.
That is, each configuration excluding the communication unit 540 is the same as that of the game device 100 of FIG. 3 described above, and is given the same reference number.
Note that the game information storage unit 110, the battle control unit 150, and the determination unit 170 further perform the contents described below.

For example, the communication unit 540 communicates with other game devices 500 in the vicinity while the game is paused, and transmits and receives time tables to and from each other.
Specifically, when the role-playing game that was being played enters a standby state (for example, when the screen is closed while the power is turned on and enters a suspended state), the communication unit 540 plays another game device 500 (the same role-playing game). Wireless communication with the game apparatus 500) in which the game is in a standby state is sequentially attempted. For example, the communication unit 540 sequentially transmits a response request including identification information (such as a unique device number) of the game apparatus 500 and identification information (such as a game ID) of the role playing game at every predetermined timing. The other game device 500 that has received this response request compares the game ID and the like, and returns response information if the same role-playing game is in a standby state or the like.
Through such exchange, communication between the game apparatuses 500 becomes possible, and the communication unit 540 reads the time table TL as shown in FIG. 4 described above from the game information storage unit 100 and transmits it to the other game apparatus 500. . Also, the time table sent from the other game device 500 is received and stored in the game information storage unit 100.
The wireless communication unit 13 and the communication controller 14 described above can function as such a communication unit 540.

The game information storage unit 110 further stores a reception time table JTL as shown in FIG.
That is, the game information storage unit 110 stores the time table received by the communication unit 540 from the other game device 500 in addition to the reception time table JTL. When the upper limit number of time tables that can be stored in the reception time table JTL is exceeded, the newly received time table may be discarded without being stored, or may be deleted from the old time table, The latest time table may be stored.
Further, as will be described later, when battle control is performed by the battle control unit 150, data such as HP of the enemy monster character corresponding to the reception time table JTL is equivalent to data such as HP of the partner monster character. It is generated appropriately. That is, it is anticipated that the game progress (the level of the partner monster character, etc.) will be greatly different from other game devices 500, and that it is possible to make a battle that depends only on the timetable. The battle control unit 150 generates data such as HP on the enemy side to be equivalent to that on the ally side.
Further, the time table used for the battle control by the battle control unit 150 is deleted from the reception time table JTL by the determination unit 170, as will be described later.

If the battle control unit 150 receives a time table sent from another game device 500 when returning from the suspended state (if the reception time table JTL is stored in the game information storage unit 110), Based on the received time table and the own time table, the battle between enemy monster characters is controlled.
That is, the battle control unit 150 matches monster characters based on the time table TL and the reception time table JTL (one time table) stored in the game information storage unit 110. Prior to the start of the battle, data such as HP of the enemy monster character corresponding to the reception time table JTL is appropriately generated so as to correspond to data such as HP of the partner monster character, and stored in the game information storage unit 110. To do.
Specific battle control is performed in the same manner as in FIGS. 7A and 7B described above. That is, the battle control unit 150 battles monster characters in the same slot in order from the slot 1. And the battle | competition control part 150 calculates the damage received on the other side at the time of the attack from one side, and subtracts from HP of the other party memorize | stored in the game information storage part 110, etc.

The determination unit 170 determines the victory or defeat of the enemy ally based on the result of the battle control by the battle control unit 150.
For example, when the HP of any monster character becomes zero during the battle between enemy monster characters controlled by the battle control unit 150 based on the time table TL and the reception time table JTL, Judge the victory or defeat. That is, the player character whose HP value is zero is determined as the loser, and the player character whose HP value remains is determined as the winner.
The determination unit 170 appropriately updates the information stored in the game information storage unit 110 based on such a determination result.
For example, when the teammate wins, the determination unit 170 appropriately increases the value of a medal or the like held by the partner monster character or the like. On the other hand, when the ally side is defeated, the determination unit 170 deletes one of the cheapest items possessed by the partner monster character or the like from the tool. The data update target at the time of winning or losing is arbitrary and can be changed as appropriate. For example, one monster character on the loser side may be randomly handed (copied) to the winner side.
Further, the determination unit 170 deletes the reception time table JTL (one time table) used for the battle control from the game information storage unit 110.

Hereinafter, the operation of the game apparatus 500 having such a configuration will be described with reference to the drawings. FIG. 17 is a flowchart showing an example of a time table transmission / reception process executed by the game device 500 according to the third embodiment of the present invention. FIG. 18 is a flowchart showing an example of a battle control process executed by the game apparatus 500.
First, the time table transmission / reception process will be described with reference to FIG. As an example, the time table transmission / reception process includes the time table setting process as shown in FIG. 9 described above, and the game information storage unit 110 stores the time table TL. And started when the upper casing JC) is closed.

  First, the game device 500 shifts to a standby state (step S501). For example, the game device 500 that has been executing the role-playing game shifts to a suspended state when the screen is closed while the power is on. That is, when the above-described open / close sensor 21 detects that the upper housing JC is closed, the state shifts to the suspended state.

  The game device 500 transmits a response request including a game ID and the like (step S502). That is, the communication unit 540 transmits a response request including the game ID of the role playing game to the vicinity in order to attempt wireless communication with another game device 500.

The game device 500 determines whether or not there is a response (step S503). That is, if another game device 500 exists in the vicinity and the same role-playing game is in a standby state or the like, such other game device 500 returns response information.
Therefore, the communication unit 540 determines whether response information has been received.
If it is determined that there is no response (step S503; No), the game device 500 advances the process to step S506 described later.

On the other hand, when it is determined that there is a response (step S503; Yes), the game device 500 transmits and receives a time table (step S504).
That is, the communication unit 540 reads the time table TL as shown in FIG. 4 described above from the game information storage unit 100, transmits the time table TL to the other game device 500, and the time table sent from the other game device 500. Receive.

The game device 500 stores the received time table in the game information storage unit 100 (step S505).
That is, the communication unit 540 stores the time table sent from the other game device 500 in addition to the reception time table JTL as shown in FIG. When the upper limit number of time tables that can be stored in the reception time table JTL is exceeded, the newly received time table may be discarded without being stored, or may be deleted from the old time table, The latest time table may be stored.

Game device 500 determines whether or not the standby state has ended (step S506). For example, it is determined whether or not the screen of the suspended game device 500 has been opened. That is, it is determined whether or not the opening / closing sensor 21 described above detects the opening of the upper housing JC.
If it is determined that the standby state has not ended (step S506; No), the game device 500 returns the process to step S502 and repeatedly executes the processes of steps S502 to S506 described above.

On the other hand, when it is determined that the standby state has ended (step S506; Yes), the game device 500 shifts to a normal state (step S507).
When the game apparatus 500 shifts to the normal state, the number of timetables received from other game apparatuses 500 may be displayed.

  By such a time table transmission / reception process, the time table can be automatically transmitted / received to / from other users (other game apparatuses 500) that have met at the place where they are out.

Next, the battle control process will be described with reference to FIG. This battle control process is subsequently started after the time table transmission / reception process of FIG. 17 is completed. If no time table is received in the time table transmission / reception process, the process is not started. In addition, when a plurality of time tables are received, the received time table may be arbitrarily selected by displaying a selection screen or the like prior to the start of the battle control process.
Further, in the battle control process of FIG. 18, the same reference numerals are assigned to the same processing content as the battle control process (FIG. 9) of the first embodiment described above.

  First, the game device 500 reads the time table on the ally side (step S301). That is, the battle control unit 150 reads the time table TL stored in the standby state from the game information storage unit 110.

  The game device 500 reads the enemy time table (step S601). That is, the battle control unit 150 reads the reception time table JTL (one time table) as shown in FIG. 16 described above from the game information storage unit 110.

  The game device 500 generates data such as the enemy's HP (step S602). That is, the battle control unit 150 generates data such as HP of the enemy monster character corresponding to the reception time table JTL so as to correspond to data such as HP of the partner monster character. That is, data such as HP on the enemy side is generated with a value close to data such as HP of the partner monster character so that the battle between the enemy and the team is settled mainly based on each other's time table.

The game device 500 sets an initial value 1 to a variable i for managing the progress of the battle (step S303), and reads the data of the slot i from each time table (step S304).
The game device 500 transforms the first monster character and performs an attack or the like in accordance with the command (step S305).
The game device 500 determines whether the HP of the monster character on the back attack side is greater than 0 (step S306).
If it is determined that the HP of the monster character on the attacking side is greater than 0 (step S306; Yes), the game apparatus 500 transforms the monster character on the attacking side and performs an attack or the like in accordance with the command (step S307). .

The game device 500 determines whether or not the HP of the first monster character is greater than 0 (step S308).
If the game device 500 determines that the HP of the first monster character is greater than 0 (step S308; Yes), the game device 500 adds 1 to the variable i (step S309), and whether or not the variable i after the addition is greater than 6 Is determined (step S310).
If it is determined that the variable i is 6 or less (step S310; No), the game device 500 returns the process to the above-described step S304 and repeats the battle of the subsequent slot i. On the other hand, when it is determined that the variable i is greater than 6 (step S310; Yes), the game device 500 returns the process to step S303 described above and repeats the battle from the first slot.

In addition, when it is determined that the HP of the attacked side (the second attack side, the first attack side) is 0 in Steps S306 and S308 described above (Steps S306 and S308; No), the game device 500 wins or loses. Determination is made (step S311).
The game device 500 determines whether or not the victory is on the ally side (step S312), and if it is determined that the victory is on the ally side (step S312; Yes), as an example, the value of the medal or the like is appropriately increased (step S312). Step S603).
On the other hand, when it is determined that the ally is defeated (enemy side victory) (step S312; No), the game apparatus 500, as an example, has one of the cheapest tools possessed by a partner monster character or the like. Are deleted (step S604).
The data update target at the time of winning or losing is arbitrary and can be changed as appropriate.

  The game device 500 deletes the used enemy time table (step S605). That is, the determination unit 170 deletes the reception time table JTL (one time table) used for the battle control from the game information storage unit 110.

  Through such battle control processing, it is possible to exchange each other's timetables and battle against unknown opponents regardless of the progress of the game.

In the third embodiment, the case where the game devices 500 existing in the vicinity transmit and receive the time table has been described. However, the transmission and reception of such a time table is not limited to the game devices 500 existing in the vicinity and is appropriately changed. Is possible. For example, arbitrary game devices 500 may be able to transmit and receive time tables regardless of the distance via a server (game server or the like) on the Internet.
In this case, for example, while the game is paused, the communication unit 540 accesses the game server through an access point present in the vicinity, and transmits / receives a time table to / from another game device 500 via the game server. .

(Embodiment 4)
In the third embodiment, the case where only the time table is transmitted / received to / from another game apparatus 500 using wireless communication has been described. However, other information may be transmitted / received. For example, a history of battles (matches performed regardless of the progress of the game) based on a time table transmitted / received using wireless communication is accumulated, and information on the top winners obtained from the history (higher winner information) ) May be transmitted and received together with the time table.
Hereinafter, a game apparatus 500 according to Embodiment 4 of the present invention, which further transmits and receives higher-rank winner information, will be described.
The configuration of the game apparatus 500 according to Embodiment 4 of the present invention is the same as that of the game apparatus 500 of Embodiment 3 shown in FIG. 15 described above.
However, the game information storage unit 110, the communication unit 540, and the determination unit 170 further include the following contents.

The game information storage unit 110 further stores match history information LG, higher-rank winner information HC, received higher-rank winner information JHC, and overall higher-rank winner information SHC as shown in FIGS.
The battle history information LG shown in FIG. 19A shows a history of battles performed regardless of the progress of the game. That is, while the role-playing game that was being played is in the standby state, the history of battles performed using the time table transmitted / received to / from other nearby game devices 500 is sequentially accumulated.
Specifically, as shown in FIG. 19A, the history including the date and time, the name of the player character (name of the enemy player character that played the battle), and the winner is displayed by the determination unit 170 as will be described later. It is stored in addition to the information LG.

The higher-rank winner information HC shown in FIG. 19B is a list of enemy player characters that have won the teammates in order of winning percentage. In other words, the winning percentage superiors tabulated from the battle history information LG are arranged up to a predetermined number (up to third place as an example). It should be noted that the tallying method of the top winner information HC and the number of top winners are arbitrary and can be changed as appropriate.
Specifically, as shown in FIG. 19B, information including the date and time, the name of the player character (the name of the player character on the opponent's opponent), the winning percentage, and the total number of battles is obtained by the determination unit 170 as will be described later. , Generated based on the battle history information LG.
Further, the higher-rank winner information HC is transmitted to another game apparatus 500 together with the time table by the communication unit 540 as will be described later.

The received higher-rank winner information JHC shown in FIG. 19C is obtained by storing higher-rank winner information received from other game devices 500.
Specifically, as will be described later, higher-rank winner information (similar to higher-rank winner information HC) received by the communication unit 540 from another game device 500 is added to the received higher-rank winner information JHC and stored. When new higher-rank winner information is sent from the same other game device 500, the new higher-rank winner information may be overwritten on the old higher-rank winner information and added to the received higher-rank winner information JHC. .

The overall higher-rank winner information SHC shown in FIG. 19D is a list of higher-rank winners comprehensively obtained from the higher-rank winner information HC and the received higher-rank winner information JHC. That is, even a player character who is not directly fighting, the strength is indirectly estimated from the received higher-rank winner information JHC corresponding to the player character in the higher-rank winner information HC. Therefore, the top winners determined comprehensively from these are arranged up to a predetermined number (up to fifth place as an example). It should be noted that such a total upper winner information SHC counting method and the number of upper winners are arbitrary and can be changed as appropriate.
Specifically, the overall higher-rank winner information SHC as shown in FIG. 19C is generated based on the higher-rank winner information HC and the received higher-rank winner information JHC by the determination unit 170 as described later.

Similarly to the third embodiment, the communication unit 540 sequentially attempts wireless communication with other game devices 500 when the role-playing game being played is in a standby state. As an example, when response information is returned from another game device 500 that has received a response request, communication between the game devices 500 becomes possible. As described above, the communication unit 540 may access a game server on the Internet through an access point present in the vicinity, and communicate with another game device 500 via the game server.
Then, the communication unit 540 reads out the time table TL as shown in FIG. 4 described above and the higher-rank winner information HC as shown in FIG. 19B from the game information storage unit 100 to obtain another game device. Sent to 500. At the time of transmission, the player character name set for the role playing game is also transmitted.
In addition, the communication unit 540 receives the time table and higher-rank winner information sent from the other game devices 500 and stores them in the game information storage unit 100.
That is, the communication unit 540 stores the received time table in addition to the reception time table JTL as shown in FIG. 16 described above, as in the third embodiment. Further, the communication unit 540 stores the received higher-rank winner information in addition to the received higher-rank winner information JHC as shown in FIG. 19C described above. When new higher-rank winner information is sent from the same other game device 500, the new higher-rank winner information may be overwritten on the old higher-rank winner information and added to the received higher-rank winner information JHC. .

  The determination unit 170 determines the victory or defeat of the enemy ally based on the result of the battle control by the battle control unit 150, as in the third embodiment. Based on the determination result, information (medal etc.) stored in the game information storage unit 110 is appropriately updated. Further, the reception time table JTL (one time table) used for the battle control is deleted from the game information storage unit 110.

Further, the determination unit 170 updates the battle history information based on the determination result. That is, the determination unit 170 stores the current history (date and time, player character name, and winner) based on the determination result in addition to the battle history information LG as shown in FIG.
In addition, when the determination unit 170 updates the battle history information, the higher-rank winner information is also updated (recreated). That is, the determination unit 170 recalculates the winning percentage superiors from the updated match history information LG, and recreates the superior winner information HC.
Further, when the determination unit 170 updates the upper winner information, the determination unit 170 also updates the overall upper winner information. That is, the determination unit 170 recreates the overall upper winner information SHC based on the updated upper winner information HC and the received upper winner information JHC. That is, even a player character who is not directly fighting, the strength is indirectly estimated from the received higher-rank winner information JHC corresponding to the player character in the higher-rank winner information HC. Therefore, the determination unit 170 calculates up to a predetermined number of higher-ranked winners comprehensively determined from these, and creates total higher-rank winner information SHC.

Hereinafter, an operation of the game apparatus 500 that further performs such contents will be described with reference to the drawings. FIG. 20 is a flowchart illustrating an example of a time table transmission / reception process executed by the game device 500 according to the fourth embodiment of the present invention. FIG. 21 is a flowchart illustrating an example of a battle control process executed by the game apparatus 500.
First, the time table transmission / reception process will be described with reference to FIG. In the time table transmission / reception process, as in the third embodiment, the time table setting process as shown in FIG. 9 described above is performed, and the time table TL is stored in the game information storage unit 110. Triggered when the screen is closed with it on.
In the time table transmission / reception process of FIG. 20, the same reference numerals are assigned to the same processing contents as the time table transmission / reception process (FIG. 17) of the third embodiment described above.

First, the game device 500 shifts to a standby state, for example, when the screen is closed while the power is on (step S501).
The game device 500 transmits a response request including a game ID and the like (step S502), and determines whether or not there is a response (step S503).
If it is determined that there is no response (step S503; No), the game device 500 advances the process to step S506 described later.

On the other hand, when it is determined that there is a response (step S503; Yes), the game device 500 transmits and receives a time table and higher-rank winner information (step S701).
That is, the communication unit 540 reads the time table TL as shown in FIG. 4 described above and the top winner information HC as shown in FIG. Sent to 500. At the time of transmission, the player character name set for the role playing game is also transmitted.
In addition, the communication unit 540 receives the time table and higher-rank winner information sent from the other game devices 500.

The game device 500 stores the received time table and higher-rank winner information in the game information storage unit 100 (step S702).
That is, the communication unit 540 stores the time table sent from the other game device 500 in addition to the reception time table JTL as shown in FIG. In addition, the received higher-rank winner information is added to the received higher-rank winner information JHC as shown in FIG. When new higher-rank winner information is sent from the same other game device 500, the new higher-rank winner information may be overwritten on the old higher-rank winner information and added to the received higher-rank winner information JHC. .

The game device 500 determines whether or not the standby state has ended, for example, when the screen of the game device 500 is opened (step S506).
If it is determined that the standby state has not ended (step S506; No), the game device 500 returns the process to step S502 and repeatedly executes the processes of steps S502 to S506 described above.
On the other hand, when it is determined that the standby state has ended (step S506; Yes), the game device 500 shifts to a normal state (step S507).

  Through such a time table transmission / reception process, the time table and higher-rank winner information can be automatically transmitted / received to / from other users (other game devices 500) that have met at a place where they are out.

Next, the battle control process will be described with reference to FIG. This battle control process is subsequently started after the time table transmission / reception process of FIG. 20 is completed. If no time table is received in the time table transmission / reception process, the process is not started. In addition, when a plurality of time tables are received, the received time table may be arbitrarily selected by displaying a selection screen or the like prior to the start of the battle control process.
Further, in the battle control process of FIG. 21, the same reference numerals are assigned to the same processing contents as the battle control process of the third embodiment (FIG. 18) described above.

First, the game device 500 reads the time table on the ally side (step S301) and reads the time table on the enemy side (step S601).
The game device 500 generates data such as the enemy's HP (step S602).

The game device 500 sets an initial value 1 to a variable i for managing the progress of the battle (step S303), and reads the data of the slot i from each time table (step S304).
The game device 500 transforms the first monster character and performs an attack or the like in accordance with the command (step S305).
The game device 500 determines whether the HP of the monster character on the back attack side is greater than 0 (step S306).
If it is determined that the HP of the monster character on the attacking side is greater than 0 (step S306; Yes), the game apparatus 500 transforms the monster character on the attacking side and performs an attack or the like in accordance with the command (step S307). .

The game device 500 determines whether or not the HP of the first monster character is greater than 0 (step S308).
If the game device 500 determines that the HP of the first monster character is greater than 0 (step S308; Yes), the game device 500 adds 1 to the variable i (step S309), and whether or not the variable i after the addition is greater than 6 Is determined (step S310).
If it is determined that the variable i is 6 or less (step S310; No), the game device 500 returns the process to the above-described step S304 and repeats the battle of the subsequent slot i. On the other hand, when it is determined that the variable i is greater than 6 (step S310; Yes), the game device 500 returns the process to step S303 described above and repeats the battle from the first slot.

In addition, when it is determined that the HP of the attacked side (the second attack side, the first attack side) is 0 in Steps S306 and S308 described above (Steps S306 and S308; No), the game device 500 wins or loses. Determination is made (step S311).
The game device 500 determines whether or not the victory is on the ally side (step S312), and if it is determined that the victory is on the ally side (step S312; Yes), as an example, the value of the medal or the like is appropriately increased (step S312). Step S603).
On the other hand, when it is determined that the ally is defeated (enemy side victory) (step S312; No), the game apparatus 500, as an example, has one of the cheapest tools possessed by a partner monster character or the like. Are deleted (step S604).
The game device 500 deletes the used enemy time table (step S605).

The game device 500 updates the battle history information and the like (step S801). That is, the determination unit 170 stores the current history (date and time, player character name, and winner) based on the determination result in addition to the battle history information LG as shown in FIG.
In addition, when the determination unit 170 updates the battle history information, the higher-rank winner information is also updated (recreated). That is, the determination unit 170 recalculates the winning percentage superiors from the updated match history information LG, and recreates the superior winner information HC.

The game device 500 generates and displays general upper information (step S802). That is, the determination unit 170 recreates the overall upper winner information SHC based on the updated upper winner information HC and the received upper winner information JHC. That is, even a player character who is not directly fighting, the strength is indirectly estimated from the received higher-rank winner information JHC corresponding to the player character in the higher-rank winner information HC. Therefore, the determination unit 170 calculates up to a predetermined number of higher-ranked winners comprehensively determined from these, and creates total higher-rank winner information SHC.
Then, the game device 500 generates a predetermined notification image from the overall higher-rank winner information SHC and displays it on the first display unit 18 or the like to notify the user of the higher-rank winner.

  Through such battle control processing, regardless of the progress of the game, each other's timetable and higher-ranking winner information are exchanged, and a battle with an unknown enemy is performed, and player characters that are not directly fighting are included. It is possible to notify the user of the overall superior winner.

(Other embodiments)
In each of the above embodiments, the case where a time table using slots is used has been described. However, the contents of this time table can be changed as appropriate. For example, the time table which numbered the action of the monster character may be sufficient. That is, the time table can be appropriately changed according to the amount of memory used, the amount of communication, etc., as long as it defines the order of actions of monster characters and the like.

  Moreover, although said each embodiment demonstrated the case where monster characters were made to fight along both timetables, what is made to fight is not restricted to such a monster character, It can change suitably. For example, in addition to this, objects such as a picture card (a card or the like) or an avatar representing a user or the like may be matched.

Further, in the above-described embodiment, the case where the game devices 100 and 500 compete with other game devices 100 and 500 (or CPU) has been described as an example. However, the present invention is a so-called social game (Social). Applicable to (Game) as appropriate.
For example, it can also be realized by a game application executed based on an operating environment such as an API (Application Programming Interface) that operates on a web browser in a social networking service (SNS).

  As described above, according to the present invention, it is an object to provide a game device, a battle control method, and a program that can further improve the strategy in a game.

DESCRIPTION OF SYMBOLS 1 Portable game machine 10 Processing control part 11 Connector 12 Cartridge 13 Wireless communication part 14 Communication controller 15 Sound amplifier 16 Speaker 17 Operation key 18 1st display part 19 2nd display part 20 Touch panel 21 Open / close sensor 100,500 Game device DESCRIPTION OF SYMBOLS 110 Game information memory | storage part 120 Operation reception part 130 Setting part 140 Acquisition part 150 Battle control part 160 Image generation part 170 Determination part 540 Communication part

Claims (5)

A game device that matches a user object with another object,
A setting unit for setting a user object corresponding to each slot in a time table that defines each slot up to a predetermined number, with a slot required for one battle as one unit,
An acquisition unit that acquires a timetable of the opponent side to play against,
Based on the set user's time table and the acquired opponent's time table, a battle control unit that battles the objects for each slot,
A reception unit that receives a priority command from the user during the battle between the objects,
A determination unit that determines a user's victory or defeat based on a result of a battle between the objects that have been played,
The battle control unit applies the priority command received by the receiving unit to a slot in the user's time table, so that the objects battle each other.
A game device characterized by that. A game device that battles a character that can be used by a user and a character that can be used by an opponent
A storage unit for storing information on a plurality of characters that can be used by a user;
A slot required for one battle is defined as one unit, and a character selected from the plurality of stored characters and a command to the character are associated with each slot in a time table that defines each slot up to a predetermined number. A setting part to be set respectively,
An acquisition unit that acquires a timetable of the opponent side to play against,
Based on the set user's time table and the acquired opponent's time table, a battle control unit that battles the characters for each slot,
A reception unit that receives a priority command from the user during the battle between the characters,
A determination unit that determines a user's victory or defeat based on a battle result between the characters that have been played,
The battle control unit gives priority to the priority command received by the reception unit over the command set in the slot in the user's time table, and battles the characters.
A game device characterized by that. The game device according to claim 2,
The reception unit receives a priority command from a user directed to a character waiting for a battle,
A game device characterized by that. The game device according to claim 2 or 3,
The battle control unit rejects the priority command received by the reception unit based on a predetermined condition, and allows the characters to battle without changing the user's time table.
A game device characterized by that. A computer that matches the user's object against other objects,
A setting unit for setting a user object corresponding to each slot in a time table that defines each slot up to a predetermined number, with a slot required for one battle as one unit,
An acquisition unit that acquires the timetable of the opponent to fight against,
Based on the set user's time table and the acquired opponent's time table, a battle control unit that battles the objects for each slot,
A reception unit that receives a priority command from the user during the battle between the objects,
Based on the result of the battle between the objects that have been played against each other, function as a determination unit that determines a user's victory or defeat,
The battle control unit applies the priority command received by the receiving unit to a slot in the user's time table, so that the objects battle each other.
A program characterized by functioning as follows.

Images