JP7708922B2 - Program, computer system and game device - Google Patents

Description

The present invention relates to a program for causing a computer system to execute a game in which a player character fights an enemy character.

One type of game in which a player character fights against an enemy character is one in which the game is played using friendly NPCs (non-playable characters) who side with the player character.

For example, in Patent Document 1, while growth control (a type of control that advances a character's abilities) is used to improve the abilities of friendly NPCs depending on game performance, the player can also select and set friendly NPCs owned by the player as the basis for a lottery. The higher the degree of progress of the friendly NPC that is the basis for the lottery, the rarer the prize that can be won in the lottery is controlled, creating a new appeal for the game.

JP 2017-176522 A

However, there was room for new ideas about how to include friendly NPCs in a game, and what kind of friendly NPCs to include. In addition, games can become boring, so new ideas are always required in the field of electronic games.

The present invention was conceived with the aim of providing technology that can bring new interest to friendly NPCs.

A first aspect of the present invention for solving the above-mentioned problems is a program for causing a computer system to execute a game in which a player character fights an enemy character, the program comprising:
A movement control means (e.g., the game management unit 210 and flight control unit 230 in FIG. 14 and step S98 in FIG. 25 ) for controlling the movement of a stored object in which an NPC (non-playable character: for example, the sub-character 5 in FIG. 3 ) is stored, based on a predetermined action operation of the player, which moves the stored object by throwing, hitting, firing, or an action of the player character similar thereto, until a given end condition is satisfied;
an NPC appearance control means for controlling the appearance of an NPC stored in a stored object that satisfies the termination condition (for example, the game management unit 210 and the sub-character appearance control unit 240 in FIG. 14, step S124 in FIG. 25);
an NPC automatic control means for automatically controlling an NPC made to appear by the NPC appearance control means so as to perform a given action toward the enemy character (for example, the game management unit 210 and the sub-character automatic control unit 250 in FIG. 14, step S124 in FIG. 25);
It is a program for causing the computer system to function as the

According to the first invention, a storage object that stores an NPC can be moved within the game space. Then, the NPC that was supposedly stored in the storage object that has been moved can be made to appear, and the enemy character can be made to perform a given action to progress through the game. This technology creates a new and previously unseen interest in friendly NPCs.

The second invention is the program of the first invention, which further causes the computer system to function as a storage setting means (e.g., the game management unit 210 and storage setting unit 224 in FIG. 14, steps S12 and S91 in FIG. 24) for setting a stored object by storing an NPC selected from a plurality of NPCs in a given object based on a selection operation by the player, and the NPC automatic control means changes the behavior control settings related to the automatic control based on the NPC stored in the stored object.

According to the second invention, the player can set the stored object by his/her own selection operation. Since the behavior of the stored NPC changes depending on the NPC, the game can be made more interesting than a configuration in which the player cannot set the stored object.

The third invention is the program of the second invention, in which the storage setting means selects multiple NPCs to store, and the NPC automatic control means changes the behavior control settings based on the combination of NPCs stored in the storage object.

According to the third invention, it is possible to change the behavior control settings depending on which NPCs are combined and stored.

The fourth invention is the program of the first invention, further causing the computer system to function as a storage setting means for setting an object to store a given NPC by selecting the object from among a plurality of objects based on a selection operation by the player, and the NPC automatic control means changes the behavior control setting related to the automatic control based on the object selected as the stored object.

According to the fourth aspect of the invention, the player can select an object to store an NPC and set the stored object. Then, the behavior control settings of the NPC after it appears can be changed by the object that stored the NPC.

The fifth invention is a setting program of any one of the first to fourth inventions, which further causes the computer system to function as a storage setting means for setting the stored object by selecting an NPC to be stored and an object to be stored from among a plurality of NPCs and a plurality of objects based on a selection operation by the player, and the NPC automatic control means changes the behavior control setting related to the automatic control based on a combination of the object selected as the stored object and the stored NPC.

According to the fifth invention, the player can set a stored object by combining an NPC with an object that stores the NPC based on the player's own selection operation. After an NPC appears, the behavior control settings are changed based on the combination of the NPC and the object that stored it, so it is interesting to consider how to set the stored object.

The sixth invention is a program according to any one of the first to fifth inventions, further causing the computer system to function as a player character setting means (e.g., the game management unit 210, player character setting unit 222 in FIG. 14, step S10 in FIG. 24) that selects and sets a character to be the player character from among a plurality of characters based on the operation of the player, and the NPC automatic control means changes the behavior control settings related to the automatic control based on the player character set by the player character setting means.

According to the sixth aspect of the invention, even if the NPC is the same, its behavior after it appears will change depending on the player character. This allows the player to enjoy the tactical element of deciding which character to select as the player character, creating a new level of interest.

The seventh invention is a program according to any one of the first to sixth inventions, further causing the computer system to function as an item setting means (e.g., the game management unit 210, item setting unit 226 in FIG. 14, steps S60 to S62 in FIG. 26) that associates a given item with the stored object and/or the NPC stored in the stored object based on the player's operation input, and the NPC automatic control means changes the behavior control setting related to the automatic control based on the item when the item is associated with the stored object and/or the NPC stored in the stored object.

According to the seventh invention, by associating an item with a stored object or NPC, the behavior of the NPC after it appears will change accordingly. This allows the player to enjoy the tactical element of thinking about which item to associate, creating a new interest.

The eighth invention is a program according to any one of the first to seventh inventions, in which the NPC automatic control means determines whether or not to change the behavior control settings related to the automatic control, or the degree of change, based on whether or not the stored object moved by the movement control means has come into contact with the enemy character.

According to the eighth invention, the behavior control settings of the NPC that appears from the moved stored object change depending on whether the moved stored object comes into contact with an enemy character. This makes the game progress more diverse and increases the interest of the game. In particular, when the action operation includes an operation for setting the initial conditions of the movement (e.g., the direction of movement, the force of movement, etc.), whether the moved stored object can successfully hit the enemy character changes the subsequent game situation, and a shooting game-like element is added, further increasing the interest of the game.

The ninth invention is a program according to any one of the first to eighth inventions, in which the NPC automatic control means changes the behavior control settings related to the automatic control based on the relative positional relationship between the position of the NPC that has appeared by the NPC appearance control means and the position of the enemy character.

According to the ninth invention, the behavior control settings of the NPC change based on the relative positional relationship between the NPC and the enemy character after the appearance of the NPC. This makes the NPC's behavior more diverse, further increasing the interest of the game. Note that the relative positional relationship can be defined, for example, using whether the NPC and the enemy character are in contact with each other, whether they are in close proximity to each other (the same as whether the enemy character is within a distance range from the NPC that satisfies a predetermined proximity condition), whether the NPC is within or outside the attackable range, relative direction, relative distance, relative altitude, etc.

A tenth invention is a program according to any one of the first to ninth inventions, in which the NPC automatic control means changes the behavior control settings related to the automatic control based on any of the type of enemy character, the part of the enemy character that comes into contact, and the terrain of the place of contact when the stored object moved by the movement control means comes into contact with the enemy character.

According to the tenth aspect of the invention, when a stored object comes into contact with an enemy character, the behavior control settings related to automatic control can be changed based on the type of enemy character, the part of the enemy character that comes into contact, the terrain of the place of contact, and the like. This makes it possible to diversify the behavior of NPCs after they appear, and to make the game more interesting.

An eleventh invention is a program according to any one of the second to tenth inventions, in which the behavior control settings include settings related to the content of the behavior.

According to the eleventh invention, the content of the NPC's actions can be changed by changing the action control settings.

A twelfth aspect of the present invention is the program of the eleventh aspect, in which the settings regarding the content of the action include settings regarding the content of an attack on the enemy character.

According to the twelfth invention, it is possible to change the type of attack that an NPC will make against an enemy character.

A thirteenth invention is a program according to any one of the second to twelfth inventions, in which the behavior control setting includes setting a time limit during which the NPC can act after appearing by the NPC appearance control means, and the NPC automatic control means automatically controls the NPC that has appeared by the NPC appearance control means until the time limit has elapsed.

According to the thirteenth invention, the time period in which an NPC can act after its appearance can be changed.

The fourteenth invention is a program of any one of the second to thirteenth inventions for causing the computer system to further function as a means for displaying the behavior control setting information (e.g., the behavior control setting information prediction display 34 in FIG. 6, the game management unit 210 in FIG. 14, the prediction display control unit 236, step S102 in FIG. 25).

According to the fourteenth invention, it is possible to provide the player with information on behavior control settings. For example, if the information on behavior control settings is displayed during the process of setting a stored object by the storage setting means, the player can know what actions the NPC can take with the current settings of the stored object, and thus has the opportunity to set the NPC to take the action he or she desires. This not only increases the interest of the game, but also improves usability.

A fifteenth invention is a program according to any one of the first to fourteenth inventions, in which the termination condition includes at least that the stored object moved by the movement control means has come into contact with the enemy character, the NPC appearance control means makes the NPC appear when the stored object moved by the movement control means has come into contact with the enemy character, and the NPC automatic control means starts automatic control of the NPC from the appearance position determined by the NPC appearance control means.

According to the fifteenth invention, when the stored object comes into contact with an enemy character, an NPC is made to appear, and automatic control of the NPC can be started from the appearance position. In other words, when the stored object is aimed at a specific part of the enemy character and hits it, the NPC will attack from the point of impact, adding a new interest that mixes shooting elements and tactical elements.

The sixteenth invention is a program of any one of the first to fifteenth inventions for causing the computer system to further function as viewpoint switching means (e.g., the game management unit 210, viewpoint switching control unit 262 in FIG. 14, step S102 in FIG. 25) capable of switching to a viewpoint based on an automatically controlled NPC based on a viewpoint switching operation by the player that switches the viewpoint of the game screen during automatic control by the NPC automatic control means.

According to the sixteenth aspect of the invention, it is possible to know the behavior of an NPC even in a situation where the NPC is outside the field of view of the player character or behind an obstacle.

A seventeenth aspect of the present invention is a computer system for executing a game in which a player character and an enemy character fight, comprising: a movement control means for controlling the movement of a stored object in which an NPC (non-playable character) is stored, based on a predetermined action operation of a player for moving the stored object by throwing, hitting, firing, or an action of the player character equivalent thereto, until a given end condition is satisfied; an NPC appearance control means for controlling the appearance of an NPC stored in the stored object from the stored object which satisfies the end condition;
The computer system includes an NPC automatic control means for automatically controlling an NPC made to appear by the NPC appearance control means so that the NPC makes a given action toward the enemy character.

According to the seventeenth aspect of the invention, a computer system that achieves the same effect as the first aspect of the invention can be realized.

The eighteenth invention is the computer system described in claim 17, which is the server system in a game system in which the server system communicates with user terminals used by players to realize the competitive game.

The nineteenth invention is a game device for executing a game in which a player character and an enemy character battle each other, comprising: a movement control means for controlling the movement of a stored object in which an NPC (non-playable character) is stored, based on a predetermined action operation of the player, which moves the object by throwing, hitting, firing, or an action of the player character similar thereto, until a given end condition is satisfied; an NPC appearance control means for controlling the appearance of an NPC stored in the stored object from the stored object that satisfies the end condition; and an NPC automatic control means for automatically controlling the NPC that has appeared by the NPC appearance control means to perform a given action toward the enemy character.

The 18th and 19th inventions also provide the same effects as the first invention.

FIG. 1 is a diagram showing an example of the configuration of a game system according to a first embodiment. A front view showing an example of the configuration of a user terminal. FIG. 1 is a diagram for explaining a preparation operation for playing a game. FIG. 4 is a diagram showing an example of a displayed game screen. FIG. 13 is a schematic diagram illustrating an attack using a sub-character. FIG. 13 is a diagram showing an example of a predictive display. FIG. 11 is a diagram showing an example of changing flight control settings. FIG. 13 is a diagram showing another example of changing the flight control settings. FIG. 11 is a diagram showing an example of changing a behavior control setting. FIG. 13 is a diagram showing another example of changing the behavior control setting. 13A and 13B are diagrams showing examples of changes to behavior control settings based on combinations of sub-characters and stored objects. 13A and 13B are diagrams showing a comparative example of changing behavior control settings based on the relative positional relationship between the appearance position of a sub-character and that of an enemy character. 11A and 11B are diagrams for explaining the addition of viewpoints and viewpoint switching of a game screen. FIG. 2 is a functional block diagram showing an example of the functional configuration of the server system according to the first embodiment. 5A and 5B are diagrams showing examples of programs and data stored in a server storage unit of the first embodiment. FIG. 13 is a diagram showing an example of the data configuration of sub-character initial setting data. FIG. 4 is a diagram showing an example of the data structure of stored object initial setting data. FIG. 13 is a diagram showing an example of the data configuration of flight control setting change pattern definition data. FIG. 4 is a diagram showing an example of the data configuration of behavior control setting change pattern definition data. FIG. 4 is a diagram showing an example of a data configuration of user management data. FIG. 4 is a diagram showing an example of the data structure of play data. FIG. 13 is a diagram showing an example of the data configuration of set stored object management data. FIG. 4 is a functional block diagram showing an example of a functional configuration of a user terminal according to the first embodiment. 6 is a flowchart illustrating a process flow in the server system. 25 is a flowchart continuing from FIG. 24 . 11 is a flowchart illustrating the flow of a storage setting process. FIG. 11 is a functional block diagram showing an example of the functional configuration of a user terminal according to the second embodiment. FIG. 11 is a diagram showing an example of programs and data stored in a server storage unit of the second embodiment. FIG. 13 is a diagram showing a modified example of the configuration of a user terminal (part 1). FIG. 2 shows a modified example of the configuration of a user terminal.

The following describes examples of embodiments of the present invention, but it goes without saying that the forms to which the present invention can be applied are not limited to the following embodiments.

First Embodiment
1 is a diagram showing an example of the configuration of a game system according to this embodiment. The game system 1000 according to this embodiment is a computer system including a server system 1100 and a plurality of user terminals 1500 (1500a, 1500b, ...) that are capable of mutual data communication by connecting to a communication line 9, and is a content providing system that provides game content (also called game applications).

The communication line 9 refers to a communication path that allows data communication. In other words, the communication line 9 includes a dedicated line (dedicated cable) for direct connection, a LAN (Local Area Network) such as Ethernet (registered trademark), a telephone communication network, a cable network, the Internet, and other communication networks, and the communication method can be either wired or wireless.

The server system 1100 has a main unit 1101, a keyboard 1106, a touch panel 1108, and storage 1140, and the main unit 1101 is equipped with a control board 1150.

The control board 1150 is equipped with various microprocessors such as a CPU (Central Processing Unit) 1151, a GPU (Graphics Processing Unit), and a DSP (Digital Signal Processor), various IC memories 1152 such as a VRAM, RAM, and ROM, and a communication device 1153. Note that a part or all of the control board 1150 may be realized by an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a SoC (System on a Chip).

The server system 1100 realizes, by the control board 1150 performing calculations based on predetermined programs and data, 1) a user management function related to user registration, etc., 2) a game management function that provides the data necessary for registered users, players 2 (2a, 2b, ...), to play the game on user terminals 1500 (1500a, 1500b, ...), and manages the execution control of the game on user terminals 1500 (1500a, 1500b, ...), and 3) an online shopping function that sells various items that can be used in the game to users online. In other words, the game in this embodiment is realized as a kind of client-server type online game.

Although the server system 1100 is described as a single unit, it may be configured with multiple blade servers each sharing a function, connected to each other via an internal bus for data communication. Alternatively, multiple independent servers installed in remote locations may be configured to communicate data via communication line 9 so that they function as a whole as the server system 1100.

The user terminal 1500 (1500a, 1500b, ...) is a computer system used individually by the player 2 (2a, 2b, ...) for game play, and is an electronic device (electronic device) that can access the server system 1100 via the communication line 9 to play online games, and functionally is a game device. The user terminal 1500 in this embodiment is a device known as a smartphone, but it may also be a portable game device, a game controller, a personal computer, a tablet computer, a wearable computer, a home game device, an arcade game device, etc.

FIG. 2 is a front view showing an example of the configuration of a user terminal 1500 according to this embodiment.
The user terminal 1500 includes a directional input key 1502, a button switch 1504, a touch panel 1506 that functions as an image display device and a contact position input device, a speaker 1510, an internal battery 1509, a microphone 1512, an image sensor unit 1520, a control board 1550, and a memory card reader 1542 that can read and write data from a memory card 1540 that is a computer-readable storage medium. In addition, a power button, a volume control button, etc. that are not shown are provided. In addition, an IC card reader that can contactlessly read and write data from an IC card type credit card or prepaid card that can be used to pay for game play may be provided.

The control board 1550 is equipped with a CPU 1551 and various microprocessors such as a GPU and a DSP, various IC memories 1552 such as a VRAM, a RAM and a ROM, a wireless communication module 1553 for wireless communication with a mobile phone base station or a wireless LAN base station connected to the communication line 9, an interface circuit 1557, etc.

The interface circuit 1557 includes a driver circuit for the touch panel 1506, a circuit for receiving signals from the directional input keys 1502 and button switches 1504, an output amplifier circuit for outputting audio signals to the speaker 1510, an input signal generation circuit for generating audio signals collected by the microphone 1512, a circuit for inputting image data of an image captured by the image sensor unit 1520, and a signal input/output circuit for the memory card reader 1542.

These elements mounted on the control board 1550 are electrically connected via a bus circuit or the like, and are connected so that data can be read and written and signals can be sent and received. Note that part or all of the control board 1550 may be configured using an ASIC, FPGA, or SoC. The control board 1550 stores programs and various data for realizing the functions of the user terminal of the game of this embodiment in IC memory 1552.

In this embodiment, the user terminal 1500 is configured to download the client program and various setting data from the server system 1100, but it may also be configured to read them from a storage medium such as a memory card 1540 obtained separately.

[Game Description]
This embodiment is an online game, a competitive game in which the player controls a player character, who is the main character (meaning the playable character that is primarily controlled), and uses a sub-character, who is an allied NPC, to battle enemy characters in the game space.

Figure 3 is a diagram for explaining the preparation operations for playing the game of this embodiment. First, as a premise of the game, the player 2 can own the main characters 3 (3a, 3b, ...), the sub-characters 5 (5a, 5b, ...), and the stored objects 7 (7a, 7b, ...) as game media. "Owning" here means having the right to use the game media within the game.

The main character 3 is a candidate for the player character who exists in the game space as a representative of the player 2. It can also be considered a candidate for the avatar character.

Sub-character 5 is an NPC (non-playable character: a character automatically controlled by a computer) who is an ally of the player character.

The storage object 7 is an object that can store the sub-character 5. When we say "storage," we mean virtual storage in the game, and in this embodiment, the storage object 7 is an object that can virtually shrink and store the sub-character 5 in the game, and can be opened again after storage. The form of the storage object 7 is expressed as a bottle, capsule, box, bag, etc.

There are multiple types of main characters 3 (3a, 3b, ...), sub-characters 5 (5a, 5b, ...), and stored objects 7 (7a, 7b, ...) prepared in advance, and the player 2 acquires and owns one or more of them prior to playing the game. For example, they may be granted in advance in the initial settings, or may be purchased through online shopping. They may also be acquired when an acquisition situation arises as the game progresses.

To play the game, Player 2 performs several preparatory operations.
The preparation operation in this embodiment includes an operation of selecting a game space (same as the game space) to play in, and an operation of selecting a player character 4 from among the main characters 3 (3a, 3b, ...) owned by the player 2. It also includes an operation of setting a combination of a storage object 7 to be used and a sub-character 5 to be stored therein.

When a stored object 7 and a sub-character 5 are combined, the sub-character 5 is treated as being stored in the stored object 7. This is called a set stored object 8. The set stored object 8 is treated as being owned or possessed by the player character 4 (main character 3a in the example of Figure 3). For example, it is treated as being carried around in a pocket or bag. In other words, the player 2 can combine the stored object 7 with a main character 3 (3a, 3b, ...) that he or she owns.

When a stored object 7 and a sub-character 5 are combined, the stored object 7 and sub-character 5 used are treated as "uncombinable", and overlapping combinations are no longer possible. However, depending on the type of stored object 7, it may be possible to store multiple sub-characters 5 at the same time, in which case the stored object 7 will not be treated as uncombinable until the storage limit is reached.

When game play begins, a game screen W4 as shown in FIG. 4 is displayed on the user terminal 1500. In this embodiment, the game screen W4 is based on an image of the game space constructed in a virtual three-dimensional space, taken from diagonally above and behind the player character 4 being used (a so-called third-person perspective image). Of course, depending on the flavor of the game, the first-person perspective image of the player character 4 may also be used as the base.

The player 2 controls the player character 4 to move through the game space and fight against an enemy character 6 when it encounters it. In this embodiment, the enemy character 6 is an NPC, but in a fighting game in which players fight each other, the enemy character 6 is the opponent player's player character or a sub-character.

Attacks on the enemy character 6 can be made in two ways: by the player character 4, or by using a sub-character 5.

Figure 5 is a schematic diagram of an attack using a sub-character 5. Note that objects that appear in the game can be moved by flying, rolling, running, gliding, etc., by throwing, hitting, firing, casting spells, activating skills, or other actions of the player character 4 that are similar to these, but in the following explanation, movement by "flying" will be explained as a representative example. Of course, other movements are also possible.

An attack using a sub-character 5 is realized when a) the player character 4 throws the set stored object 8, causing it to fly, b) hitting an enemy character 6 or a background object in the game space, c) causing a stored sub-character 5 to appear there, and d) the sub-character 5 that appears performs an attacking action.

Specifically, as shown in FIG. 5(1), player 2 first performs a predetermined pre-flight operation. In the pre-flight operation, a set stored object list 10 in which set stored objects 8 are displayed so that they can be selected is displayed on the game screen W4 (see FIG. 4). Player 2 selects a set stored object 8 to throw from the list. In the example of FIG. 5(1), a set stored object 8a is selected.

When an action operation is performed, as shown in FIG. 5 (2), the player character 4 throws the selected set stored object 8. In this embodiment, the action used for the set stored object 8 is "throwing," but if the player character 4 is a robot or the like, the action used may be "firing" (or "ejecting" or "releasing") the set stored object 8.

The "action operation" referred to here includes not only operations that can be detected by ON/OFF, such as operating a specific button switch or touching a specific operation icon, but also operations that are determined as input detection based on the amount of detection detected in relation to the operational input, such as a flick operation using one or more fingers on a touch panel, a slide operation, or shaking the user terminal 1500 or a game controller.

The throwing direction is the front direction of the player character 4. A throwing direction marker 12 (a dashed circle in the center of the screen in the example of FIG. 4) is displayed in front on the game screen W4 (see FIG. 4), so the player can adjust the position and posture of the player character 4 so that the marker faces the direction in which the player wants to throw (throwing direction). In addition, a throwing force input bar 14 is displayed on the game screen W4, so the player touches the bar to input the throwing force.

Note that the throwing direction and throwing force are not limited to this. For example, they may be input by a swipe operation on the touch panel 1506. That is, the swipe direction may be regarded as the throwing direction, and the swap distance and speed may be regarded as the input of the throwing force. In addition, in a configuration in which an acceleration sensor is mounted on the user terminal 1500 or a game controller unit that can be separated from the terminal, the throwing force may be input by holding the user terminal 1500 or the game controller unit in the hand and shaking it.

When the throwing direction and throwing force are input, the initial conditions for the throw are considered to have been determined, and the flight path (flight trajectory) along which the thrown configured stored object 8 will fly and the destination it will reach are determined. The flight path and destination can be determined by physical calculations or pseudo-physical calculations, by selecting from among multiple types of flight paths prepared in advance, and so on.

When the throwing force is input, the direction and force specifications for throwing are determined, and as shown in FIG. 6, a predicted trajectory 30 of the thrown set stored object 8 and a predicted flight destination 32 are displayed as a predicted display object on the game screen and notified to the player. In this embodiment, the sub-character 5 that appears is automatically controlled to attack the nearest enemy character 6 among the enemy characters 6 within the attackable range. Therefore, the predicted flight destination 32 essentially doubles as a predicted display of the enemy character 6 that will be attacked when the appearance of the sub-character 5 stored in the set stored object 8 that is to be flown is controlled.

The "predicted trajectory" referred to here may include a flight path and error range that are set based on specifications such as the initial conditions related to the throw at that time. Similarly, the "predicted destination" may include a flight destination and error range that are set based on specifications at that time.

The player 2 looks at this prediction display and considers whether the ball will fly along the course and to the desired location. The player can then adjust the throwing direction and force by changing the direction in which the player character 4 faces or by re-touching the throwing force input bar 14.

If the predicted trajectory 30 and predicted flight destination 32 are as desired, the player 2 inputs a specified action operation to cause the player character 4 to throw the selected set stored object 8.

The thrown configured storage object 8 is then released by the player character 4 and its movement is controlled so that it flies along the flight path toward the destination until a given flight end condition is met.

The "flight end condition" is a condition that must be met to end the movement of the set stored object 8, and can be set as appropriate. In this embodiment, the flight end condition is contact with the set stored object 8 or another object. Therefore, the thrown set stored object 8 will eventually hit an enemy character 6, a background object, or another object, causing it to stop flying, and will be placed in the position where it stopped, or a display will be given of the stored object being destroyed.

When a given release condition is met for a set stored object 8, as shown in FIG. 5 (3), the sub-character 5 stored in the set stored object is released and appears in the game space, and begins acting as the sub-character 5.

The "release condition" can be set as appropriate, but in this embodiment, it includes at least the satisfaction of the flight end condition, but it can also be set as appropriate as an AND or OR condition with the elapsed time from the start of flight reaching a predetermined time, approaching an enemy character 6, being attacked by an enemy character 6, etc.

The sub-character 5 that appears after being released from the set storage object 8 is an NPC, and is therefore automatically controlled by the computer. The example in FIG. 5 shows an example of an attack on an enemy character 6, but it is also possible to enable automatic action control other than attack, such as control to defend an ally, control to restore the vitality value of an ally, or control to interfere with the actions of the enemy character 6, and it is also possible to select and execute these with priority depending on the type of sub-character 5. Alternatively, the player 2 can select from a number of automatic actions and set them.

Note that the configured stored object 8 that has satisfied the release conditions cannot be reused in the current game play, but can be reused in the next game play. Also, it may become reusable after a predetermined time has elapsed since its use during the same game play.

Now, in order to create new interest or increase interest in a fighting game using a sub-character 5, in this embodiment, at least one of the control settings related to the flight of the configured stored object 8 (hereafter referred to as "flight control settings") and the control settings related to the behavior of the stored sub-character 5 after it appears (hereafter referred to as "behavior control settings") can be changed depending on at least the combination of the sub-character 5 and the stored object 7.

"Flight control settings" are the setting values of parameters related to movement control after the configured stored object 8 is thrown or launched. For example, they can include a weight equivalent parameter value, flight path type, possible flight distance (equivalent to range), flight height, flight speed, error in the flight path and flight destination, the number of bounces allowed due to contact with other objects, whether or not the object will adhere to the first other object it comes into contact with, etc. Of course, parameters other than these can also be appropriately set as control parameters related to flight. When changing the flight control settings, at least one of the flight control settings is changed.

The flight path type can be thought of as a flight path determination pattern. For example, it is possible to set physical calculations (or pseudo-physical calculations), linear motion, automatic tracking flight of a locked-on enemy character 6, etc. Furthermore, for each of these, it is also possible to add detailed types such as flight with automatic obstacle avoidance a specified number of times, flight with permission to pass through obstacles (virtual penetration), etc.

"Action control settings" are the setting values of parameters related to the action control of the sub-character 5. For example, they can include durability (a value that is subtracted when damage is received and becomes unable to act when it reaches "0"), attack power, defense power, movement power, recovery power, search range, action type, restrictions on movement (for example, types of terrain that can be moved over, and conversely, types of terrain that cannot be moved over), weight equivalent parameter value, etc. Of course, parameters other than these can also be appropriately set as control parameters related to actions. And when changing the flight control settings, at least one of the action control settings is changed.

The "action type" referred to here is a pattern of what action the sub-character 5 will take after appearing. Multiple types of the same action type can be set depending on the content. For example, even if classified as the same attack action, it is possible to set a) "search attack" in which the sub-character 5 takes a search action and attacks the enemy character 6 it finds, b) "defense" in which the sub-character 5 attacks an enemy character that has entered an attackable range without moving much from its position, c) "ally escort" in which the sub-character 5 follows an ally and attacks an approaching enemy character 6, and d) "support" in which the sub-character 5 gives priority to attacking an enemy character 6 that is attacking an ally. Of course, action types other than attack, such as "rescue" in which the sub-character 5 recovers the stamina of an ally, can also be set as appropriate.

In addition, in this embodiment, factors that change the flight control settings and behavior control settings can include at least one of the degree of progress of the stored object 7 and the degree of progress of the sub-character 5.

The "degree of progress" referred to here is the so-called degree of growth of the stored object 7 and the sub-character 5. Depending on the game rules and the character settings of the sub-character 5 in the game world, it can be synonymous with growth, strengthening, evolution, improvement, repair, etc. In this embodiment, it is collectively referred to as "growth."

In other words, when a sub-character 5 and a stored object 7 are used in a game play, experience points are granted and accumulated according to the performance of that game play, and the game rules state that the sub-character 5 and the stored object 7 grow and improve their abilities according to the accumulated experience points. The degree of growth is represented as the stored object level and the character level, respectively, and even if the sub-character 5 and the stored object 7 are of the same type, the flight control settings and behavior control settings will be different if the character level of the combined sub-character 5 and the stored object level of the combined stored object 7 are different.

Furthermore, in this embodiment, the flight control settings and behavior control settings can be changed based on the type of player character 4 used, the effects of the items used for the sub-character 5 (sub-character items), and the items used for the storage object 7 (storage object items).

Now let's give some examples of specific changes to flight control settings and behavior control settings.

FIG. 7 is a diagram showing an example of changing the flight control settings.
FIG. 7(1) is a diagram showing an example of the possible flight distance, flight height, and flight path of a set stored object 8 when a sub-character 5a and a stored object 7a are combined.

Figure 7 (2) shows an example in which stored object 7a has been replaced with stored object 7c in the combination of Figure 7 (1), resulting in a relatively longer flight distance (corresponding to range).

Stored object 7c is set in the game as being "lighter" (has a smaller weight equivalent parameter value) than stored object 7a. If player 2 wants sub-character 5a to appear farther away, he or she can achieve this by combining stored object 7c, which is "lighter" than stored object 7a.

Figure 7 (3) shows an example in which the flying distance is relatively increased by replacing sub-character 5a with sub-character 5b in the combination of Figure 7 (1).

Sub-character 5b is set in the game as being "lighter" than sub-character 5a. Even if the only unused stored object that player 2 has is stored object 7a, if player 2 wants to have a sub-character appear farther away, this can be achieved by combining stored object 7a with sub-character 5b, which is "lighter" than sub-character 5a.

Figure 7 (4) shows an example in which the combination of Figure 7 (1) is kept the same, but by using a sub-character item 21 that improves flight performance, the flight distance is relatively increased and the type of flight path is changed so that the enemy character 6 that has been locked on by a lock-on operation (operation to specify the flight target) is tracked during the throwing operation. Note that the method of the lock-on operation is not particularly limited. For example, the player may select one of the enemy characters 6 that exist within a specified range around the throwing direction marker 12 of the player character 4. Note that the enemy character 6 that has been set as the flight target is identifiable by the lock-on marker 19 displayed on the game screen.

The effect of the sub-character item 21 set (or "associated" or "used") to the sub-character 5a in FIG. 7(4) is a game setting of "weight reduction" or "extension of flight distance." Even in the case of a combination of sub-character 5a and stored object 7a, the use of the item reduces or adjusts the weight equivalent parameter value of at least one of the stored object 7 or sub-character 5, and variable flight control is performed based on the value after the reduction adjustment, thereby extending the flight distance.

FIG. 8 is a diagram showing another example of changing the flight control settings.
8(1) and 8(2) show an example in which the combined sub-character 5 and stored object 7 are the same type, but the latter has a higher stored object level than the former. Also, the flying distance is extended and the flying control settings are changed so that the flying error 20 is smaller for the latter.

In other words, since the combination of the stored object 7 in FIG. 8 (2) and the sub-character 5 stored therein satisfies a given reduction condition (in this case, for example, the degree of progress of the stored object 7a has reached a predetermined reference value "Lv. 5"), the weight equivalent parameter value of at least one of the stored object 7 or the sub-character 5 is reduced and adjusted, and variable flight control is performed based on the value after the reduction adjustment, resulting in an increase in the possible flight distance.

The "error" referred to here corresponds to the variation in the possible flight range and flight destination. Specifically, this is achieved by giving random fluctuations within an error range of 20 to the flight path and flight destination determined by the throwing direction and throwing force.

When the type of flight path is set to "automatic tracking flight toward locked-on enemy character 6," the "error" referred to here is synonymous with the "hit rate" for the flight target. Also, even if a lock-on operation is not performed, the destination target is decided and a throwing operation is performed, so it can also be said to be the "hit rate" of whether or not the bullet will land on the flight target.

It would be advantageous to prepare an item that has a specific "hit rate improvement" effect, so that when Player 2 uses this item, it can reduce errors (equivalent to improving hit rate).

Figure 8 (3) shows an example in which the flight control settings are changed when a stored object item 22w that increases the flight altitude (height) of the stored object 7 is set and used in the combination of Figure 8 (2).
In this example, it is possible to increase the throwing height, so that the set stored object 8 can be thrown over the obstacle 24 to the other side.

In Figure 8 (4), the types of combined sub-character 5 and stored object 7 are the same as in Figure 8 (1), but the main character 3b, which has a higher throwing ability than the main character 3a, is selected as the player character 4, and this shows an example in which the throwable height is improved while the error 20 remains the same.

FIG. 9 is a diagram showing an example of changing the behavior control setting.
Comparing Figures 9 (1) and 9 (2), the combination of sub-character 5 and stored object 7 combined as the set stored object 8 to be thrown is the same, but the degree of growth of the sub-character 5 is different, and the behavior control settings have been changed so that the search range 26 of the latter is expanded and attack power is also increased compared to the former.

Comparing Figure 9 (2) and Figure 9 (3), the growth rate of the sub-character 5 and the stored object 7 is the same, but the types of stored objects 7 that are combined are different. The behavior control settings have been changed so that the attack power of the stored object 7h in Figure 9 (3) is greater than that of the stored object 7a in Figure 9 (2).

FIG. 10 is a diagram showing another example of changing the behavior control setting.
One of the behavior control settings is a setting of restrictions on movement, such as whether or not the character can move over an obstacle 24. As shown in Fig. 10 (1), the settings of restrictions on the movement of a sub-character 5a (a character without arms) include an obstacle 24. Therefore, in order to attack an enemy character 6, the sub-character 5a needs to move around the obstacle 24.

On the other hand, as shown in FIG. 10 (2), the restrictions on the movement of sub-character 5b (a character with arms) do not include obstacles 24. Therefore, to attack an enemy character 6, sub-character 5b can climb over obstacles 24 and begin attacking in a shorter time than sub-character 5a.

As shown in FIG. 10(3), even if the combination of sub-character 5 and stored object 7 is the same as in FIG. 10(1), by using an item, it is possible to give sub-character 5a the same abilities as sub-character 5b. For example, when a stored object item 22r having a ladder-like effect is used and set on stored object 7, the behavior control settings are changed so that obstacles 24 are not included in the settings of restrictions on the movement of sub-character 5a, and sub-character 5a can overcome obstacles 24 and begin attacking in a short time, just like sub-character 5b in FIG. 10(2).

In addition, it is preferable to represent the stored object items 22 (22w, 22r) in the game as items that are attached to the stored object 7. For example, they can be represented as straps, covers, holders, stickers, replacement caps, cap covers, etc. that are attached to the stored object 7.

FIG. 11 is a diagram showing an example of changing the behavior control setting based on the combination of the sub-character 5 and the stored object 7. In FIG.
Usually, when the sub-character 5 locally attacks the enemy character 6, it is determined randomly which part of the enemy character 6 to attack. As a result, all parts of the enemy character 6 are attacked evenly.

However, as shown in FIG. 11, it is possible to give priority to attack parts based on the combination of the sub-character 5 and the stored object 7. In other words, it is possible to give a bias to the probability, weight, and priority of selecting a part as an attack target. That is, in the example of FIG. 11(1), when the sub-character 5a is combined with the stored object 7j, the attack weight for each part of the enemy character 6 is usually "head 1: torso 1: arms 1: legs 1", but this is changed to a head-biased attack weight. In the example of FIG. 11(2), the same sub-character 5a is combined with the stored object 7k, but the attack is changed to prioritize the arms and legs. The example of the setting of the priority of the selection of attack parts and the setting of the tendency to be selected are not limited to the example of FIG. 11 and can be set appropriately. Furthermore, the parts are not limited to the example of FIG. 11 and can be set appropriately according to the design of the enemy character 6.

In addition, in this embodiment, the behavior control settings of the sub-character 5 can be changed based on the relative positional relationship between the appearance position and the position of the enemy character 6.

Figure 12 shows a comparative example of changing the behavior control setting based on the relative positional relationship between the appearance position and the enemy character. Figure 12 (1) shows a case where the relative positional relationship does not satisfy the specified distance condition. In other words, the set stored object 8 that the player character 4 has flown comes into contact with another object (in this case, the ground object) at a location away from the enemy character 6, and the flight end condition is satisfied. The stored sub-character 5 appears at a location away from the enemy character 6. In this case, the sub-character 5 is automatically controlled to search for the enemy and move toward the nearest enemy character 6, and perform a first type of attack behavior (in the example of Figure 12 (1), a body slam) on the first designated part of the enemy character 6 (in the example of Figure 12 (1)), which is the torso.

Figure 12 (2) shows a case where the relative positional relationship satisfies a predetermined distance condition. That is, the set stored object 8 that the player character 4 has flown comes into contact with the enemy character 6, and the flight end condition is met. The set stored object 8 is shown as being broken when it hits the enemy character 6 and opened. In this case, the stored sub-character 5 appears at the position where the set stored object 8 hit it. It is shown as being attached to the enemy character 6. Then, the sub-character 5 is automatically controlled to perform a second type of attack action (a kick in the example of Figure 12 (2)) on a second designated part of the enemy character 6 (the part that the set stored object 8 has contacted: the head in the example of Figure 12 (2)). Then, the behavior control setting is also changed so that the attacking power of the sub-character 5 is improved compared to the case of Figure 12 (1).

By changing the behavior control settings based on this relative positional relationship, it becomes possible to advance the subsequent developments more advantageously depending on whether or not the set stored object 8 hits the enemy character 6, compared to when it fails to hit. In other words, it adds an element of a shooting game, making the game even more interesting.

The elements that define the relative positional relationship are not limited to the relative distance or the presence or absence of contact between the two. The direction of the appearance position as seen from the enemy character 6 can also be used as a defining element.

In this way, by making it necessary to combine a sub-character 5 with a stored object 7 in order for it to be usable in the game, and by changing the flight control settings and action control settings depending on the combination, it creates far more variety in the game situation than simply selecting the sub-character 5 to be used in the game, choosing a deck, and having it appear in the game at the desired timing, and it increases the element of tactical thinking about how to combine the sub-characters 5 and stored objects 7 at hand to overcome the game, creating new interest.

Furthermore, the flight control settings and behavior control settings can be changed by selecting the main character 3 as the player character 4 and by using items, so it becomes possible to control the appearance of the sub-character 5 in the game space by throwing the configured stored object 8, and to realize a wider variety of abilities and types of behavior of the sub-character 5 after it appears.

In addition, in this embodiment, the preparation of the configured stored object 8 can be performed even during gameplay, so players are not limited to the decks they organized before playing the game, and can flexibly play tactics according to the current battle situation, which adds an unprecedented level of fun to the game.

Note that since the set stored object 8 is flown, the destination of the set stored object 8 may be beyond an obstacle that cannot be seen by the player character 4. In such a case, the game image from a viewpoint based on the player character 4 (a virtual camera placed in the game space) does not show the state of the sub-character 5 that appears at the destination. Therefore, in this embodiment, each time a sub-character 5 appears, a viewpoint based on that sub-character is added, allowing the player to switch the viewpoint on the game screen.

FIG. 13 is a diagram for explaining the addition of a viewpoint and viewpoint switching of the game screen.
A player viewpoint virtual camera 41 is always set as a viewpoint based on the player character 4. When a sub-character 5 appears, a sub-character viewpoint virtual camera 42 is newly set as a viewpoint based on the sub-character 5. The sub-character viewpoint virtual camera 42 may be a third-person viewpoint or a first-person viewpoint (the viewpoint of the sub-character 5).

When a virtual camera is added, a viewpoint switching operation icon 15 (15a, 15b) is displayed to switch between each virtual camera as the viewpoint of the game screen. In the example of FIG. 13, the first viewpoint switching operation icon 15a corresponds to the player viewpoint virtual camera 41, and the second viewpoint switching operation icon 15b corresponds to the sub-character viewpoint virtual camera 42.

The viewpoint of game screen W5 defaults to the player's viewpoint virtual camera 41, but when the second viewpoint switching operation icon 15b is operated during play, the viewpoint is switched to the sub-character's viewpoint virtual camera 42, and the touch panel 1506 displays the game screen W6 with the sub-character's viewpoint virtual camera 42 as the viewpoint. When the player's viewpoint virtual camera 41 is operated, the viewpoint is switched again, and the touch panel 1506 displays the game screen W5.

In this way, the player can arbitrarily select the viewpoint associated with the sub-character 5 that has appeared and switch to the viewpoint of the game screen, making it possible to see the state of the sub-character 5 that is in a place that cannot be seen from the viewpoint of the player character 4.

[Explanation of Functional Configuration]
14 is a functional block diagram showing an example of a functional configuration of a server system 1100 according to this embodiment. The server system 1100 according to this embodiment includes an operation input unit 100s, a server processing unit 200s, a sound output unit 390s, an image display unit 392s, a communication unit 394s, and a server storage unit 500s.

The operation input unit 100s is a means for inputting various operations for managing the server. This corresponds to the keyboard 1106 in FIG. 1.

The server processing unit 200s is realized by electronic components such as a microprocessor such as a CPU or GPU, an ASIC, and an IC memory, and controls the input and output of data between each functional unit including the operation input unit 100s and the server storage unit 500s. It performs various types of arithmetic processing based on predetermined programs and data, operation input signals from the operation input unit 100s, data received from the user terminal 1500, etc., and comprehensively controls the operation of the server system 1100.

The server processing unit 200s of this embodiment includes a user management unit 202, an online shopping management unit 204, a game management unit 210, a timing unit 288s, a sound generation unit 290s, an image generation unit 292s, and a communication control unit 294s. Of course, other functional units may also be included as appropriate.

The user management unit 202 performs processing related to user registration procedures and manages the data of each user linked to a user account. In this embodiment, the user management unit 202 has the following functions: 1) assigning unique user accounts to registered users; 2) registration information management for registering and managing personal information for each user account; 3) ledger management of electronic payment media consumed for payment of billing elements (in this embodiment, online shopping and play fees, etc.); 4) play history management for managing login and logout history for playing games, and 5) management of game save data. Of course, management functions for other data linked to accounts other than these may also be included as appropriate.

The online shopping management unit 204 is responsible for controlling online shopping, and can be realized by appropriately utilizing known online shopping technology. In this embodiment, the player can purchase the main character 3, sub-characters 5, stored objects 7, items, etc. through online shopping. Items for sale in online shopping can also be set as appropriate in addition to these.

The game management unit 210 performs various processes related to the management of game execution. Since the game of this embodiment is a client-server type online game, the game management unit 210 of this embodiment controls the provision of data necessary for game play while communicating with the user terminal 1500. The game management unit 210 of this embodiment has a preparation setting unit 220, a flight control unit 230, a predictive display control unit 236, a sub-character appearance control unit 240, a sub-character automatic control unit 250, a progress control unit 260, and a viewpoint switching control unit 262. Of course, other functional units may also be included as appropriate.

The preparation setting unit 220 performs various settings related to preparation for game play based on the player's operations. Specifically, the preparation setting unit 220 has a player character setting unit 222, a storage setting unit 224, and an item setting unit 226.

The player character setting unit 222 selects and sets a character to be the player character 4 from among a number of characters based on the player's operation.

The storage setting unit 224 sets a stored object by selecting an NPC to store and an object to store from among a plurality of NPCs and a plurality of objects based on the player's selection operation. If the stored object can store a plurality of sub-characters 5, the storage setting unit 224 can select a plurality of NPCs to store. More specifically, the storage setting unit 224 sets an association between the sub-characters 5 and the stored object 7, and creates a set stored object 8.

The item setting unit 226 associates a given item with a stored object and/or an NPC stored in the stored object based on the player's operational input. More specifically, the item setting unit 226 performs usage settings for a sub-character item 21 (see FIG. 7) for the sub-character 5 and a stored object item 22 (see FIG. 8) for the stored object 7.

In addition to the above-mentioned functions, the preparation setting unit 220 can also set a game space to be used for gameplay from among multiple game spaces (also called game stages) based on the player's operational input.

The flight control unit 230 controls the flight of the stored object in which the NPC is stored, based on the player's action operation, until a given flight end condition is met. More specifically, the flight control unit 230 changes the flight control settings based on the combination of the stored object 7 and the sub-character 5 combined as the set stored object 8, and controls the movement of the set stored object 8 based on the changed flight control settings.

For example, the flight control unit 230 changes the flight control settings of the set stored object 8 to be thrown. Then, based on the changed flight settings, it determines the flight destination and the flight path to get there based on the specifications related to the throw at that time (such as the throwing direction and throwing force in this embodiment). These are the predicted flight destination and are the basis for determining the predicted trajectory. Then, it determines the flight destination and flight path based on the specifications at the time the action operation is performed, and controls the movement of the set stored object 8 so that it moves toward the flight destination along the determined flight path.

The predicted display control unit 236 controls the display of a predicted display showing the predicted trajectory 30 of flight control and/or the predicted flight destination 32. The display control of the predicted flight destination 32 also serves as a predicted display of the enemy character 6 that will be attacked when a sub-character 5 appears.

The sub-character appearance control unit 240 controls the appearance of an NPC stored in a stored object that has satisfied the flight end condition. For example, the sub-character appearance control unit 240 controls the release and appearance of sub-character 5.

The sub-character automatic control unit 250 automatically controls the NPC that has been made to appear by the sub-character appearance control unit 240 so that it performs a given action toward the enemy character. However, automatic control is only possible until the time limit set for the NPC has elapsed. For example, it automatically controls the action of sub-character 5.

Then, the sub-character automatic control unit 250 changes the behavior control settings related to the automatic control based on the NPCs and stored objects that make up the set stored object. For example, it changes the behavior control settings based on the sub-characters 5 and stored objects 7 that make up the set stored object 8.

More specifically, the sub-character automatic control unit 250 can change the behavior control settings related to automatic control based on at least one of the following: a) the NPC stored in the stored object, b) if there are multiple stored NPCs, a combination of those NPCs, c) the object selected as the stored object, and d) a combination of the object selected as the stored object and the stored NPC.

The sub-character automatic control unit 250 can also change the behavior control settings based on e) the character designated as the player character, and f) the item if one is associated with a stored object and/or an NPC stored in the stored object.

The sub-character automatic control unit 250 can also determine whether or not to change the behavior control settings related to automatic control, or the extent of the change, based on whether or not the flown stored object has come into contact with an enemy character.

The sub-character automatic control unit 250 can also change the behavior control settings related to automatic control based on the relative positional relationship between the position of the appeared NPC and the position of the enemy character.

The progress control unit 260 changes the parameter values of stored objects through progress control, such as improving the capabilities, strengthening, and leveling up of the stored objects. It can also change the parameter values of NPCs through progress control, such as improving the capabilities, strengthening, and leveling up of the NPCs.

The viewpoint switching control unit 262 can switch the viewpoint to that of an automatically controlled NPC based on a viewpoint switching operation by the player that switches the viewpoint of the game screen during automatic control by the sub-character automatic control unit 250. For example, the viewpoint switching control unit 262 displays a viewpoint switching operation icon 15 (see FIG. 13) and controls switching of the viewpoint of the game screen in response to an operation on that operation icon.

The timing unit 288s uses the system clock to measure the current date and time, time limit, etc.

The sound generation unit 290s is realized by executing an IC or software that generates or decodes audio data, and generates or decodes audio data such as operation sounds and background music related to system management and game play of the server system 1100. Then, audio signals related to system management are output to the sound output unit 390s.

The sound output unit 390s emits an audio signal. In the example of FIG. 1, this corresponds to a speaker (not shown) provided in the main device 1101 or the touch panel 1108.

The image generation unit 292s can generate images related to system management of the server system 1100, game images (or data for displaying game images on the user terminal 1500), etc. Then, the images related to system management can be output to the image display unit 392s.

The image display unit 392s displays various images for system management based on the image signal input from the image generation unit 292s. For example, this can be realized by an image display device such as a flat panel display, a cathode ray tube (CRT), a projector, or a head-mounted display. In the example of FIG. 1, this corresponds to the touch panel 1108.

The communication control unit 294s executes data processing related to data communication and realizes data exchange with external devices via the communication unit 394s.

The communication unit 394s connects to the communication line 9 to realize communication. For example, it is realized by a wireless communication device, a modem, a TA (terminal adapter), a jack for a wired communication cable, a control circuit, etc. In the example of Figure 1, it corresponds to the communication device 1153.

The server storage unit 500s stores programs and various data for implementing various functions for the server processing unit 200s to comprehensively control the server system 1100. It is also used as a working area for the server processing unit 200s, and temporarily stores the results of calculations executed by the server processing unit 200s according to various programs. This function is implemented, for example, by IC memory such as RAM or ROM, magnetic disks such as hard disks, optical disks such as CD-ROMs or DVDs, online storage, etc. In the example of Figure 1, this corresponds to storage media such as the IC memory 1152 and hard disk mounted on the main unit 1101, and the storage 1140.

FIG. 15 is a diagram showing examples of programs and data stored in the server storage unit 500s in this embodiment. The server storage unit 500s in this embodiment stores a server program 501, a distribution game client program 502, sales management data 509, game space initial setting data 510, enemy character initial setting data 512, item initial setting data 516, main character initial setting data 518, sub-character initial setting data 520, stored object initial setting data 540, flight control setting change pattern definition data 570, and behavior control setting change pattern definition data 580.

The server storage unit 500s also stores user management data 600, play data 700, and current date and time 800 as data that is generated and managed sequentially in relation to the game. The server storage unit 500s can also store other programs and data (such as timers, counters, and various flags) as appropriate.

The server program 501 is a program that is read and executed by the server processing unit 200s to realize the functions of the user management unit 202, the online shopping management unit 204, and the game management unit 210 (see Figure 14).

The distribution game client program 502 is the original game client program provided to the user terminal 1500.

The sales management data 509 stores data for defining and managing items for sale through online shopping. For example, it stores items that can be purchased, the number in stock, and the corresponding charged amount (which in this embodiment corresponds to the amount debited from the payment medium) in association with each other.

Game space initial setting data 510 is prepared for each game space, and stores various initial setting data related to that game space. One game space initial setting data 510 includes a game space ID, map data, setting data for the type of terrain at each position in the map, enemy character appearance settings, storage object assignment conditions, sub-character assignment conditions, item assignment conditions, etc.

The stored object granting conditions, sub-character granting conditions, and item granting conditions define the conditions that must be met to grant a new stored object, a new sub-character, or a new item to the player in the game space.

Enemy character initial setting data 512 is prepared for each type of enemy character, and stores various initial setting data related to that enemy character. For example, one piece of enemy character initial setting data 512 includes an enemy character type, ability parameter values, and action type data that defines the action type. Of course, other data than these may also be included as appropriate.

Item initial setting data 516 is prepared for each item, and stores various initial setting data related to the item. For example, one item initial setting data 516 stores the item type and definition data of the action and effect. If the item is a stored object item 22 (see FIG. 8), the target of the action and effect is mainly the flight control setting. The data defines which parameter of the flight control setting is the target of the action and effect, and the degree of change in value due to the action and effect. Note that it is possible to include not only flight control settings, but also behavior control settings. Similarly, if the item is a sub-character item 21 (see FIG. 7), it is mainly the behavior control setting, but it is also possible to include flight control settings.

Main character initial setting data 518 is prepared for each type of main character 3 (see FIG. 3), and stores various initial setting data related to that main character. For example, one main character initial setting data 518 stores information such as the character type and the character's initial ability parameter values. Of course, it also includes various data required to display and operate the character on the game screen (for example, character model data, motion data, texture data, etc.).

Sub-character initial setting data 520 is prepared for each type of sub-character 5 (see FIG. 3), and stores various initial setting data related to the sub-character. For example, as shown in FIG. 16, one sub-character initial setting data 520 includes sub-character type 521, sub-character attributes 522, initial character growth level 523, initial character experience value 524, and initial action control setting 530. Of course, it also includes various data required for displaying and operating the character on the game screen (for example, character model data, motion data, texture data, etc.).

The initial action control settings 530 include, for example, an initial ability parameter value list 531, initial movement restrictions 532, initial weight equivalent parameter values 533, and initial action type definition data 534. Of course, other data may also be included as appropriate.

The initial action type definition data 534 is data regarding the initial settings of the automatic control of the character, and includes an initial action type 535, an initial attack content 536, and an initial action time limit 539. Of course, other data may also be included as appropriate.

The initial action type 535 indicates the type of action or action pattern that the sub-character can perform in the initial setting state. For example, reconnaissance attack, defense, ally escort, etc. are set. The sub-character is then automatically controlled according to an algorithm that corresponds to the action type that has been set.

The initial attack content 536 defines the type of attack that will be performed in the action indicated by the initial action type 535. For example, it includes the initial attack part weighting 537 and the initial attack type 538. Of course, other data can also be included as appropriate.

The initial attack area weighting 537 defines the proportion, weighting, and weighting of each part of the enemy character 6 that is to be given priority as an attack target. The higher the weighting, the more the sub-character will be automatically controlled to attack that part with priority.

The initial attack type 538 defines the attack method. For example, it is possible to set "standard attack priority" which prioritizes standard attacks that are primarily used as a standard attack method for the sub-character, "special attack priority" which prioritizes more powerful special attacks that have stricter usage counts and conditions than standard attacks, close-range attack priority, long-range attack priority, etc.

The initial action time limit 539 defines the initial setting of the time limit for automatic control of the sub-character. In this embodiment, it is the time measured from when the sub-character appears until when it becomes unable to act, that is, the movement time. Of course, it can also be a time limit with a different meaning. For example, it can be the movement time per action (for example, if it is a turn-based game and the rules state that one character can take one action per turn, this corresponds to one turn).

Returning to FIG. 15, stored object initial setting data 540 is prepared for each type of stored object, and stores various initial setting data related to the stored object. For example, as shown in FIG. 17, one stored object initial setting data 540 includes a stored object type 541, a stored object attribute 542, an initial stored object level 543, an initial stored object experience value 544, and an initial flight control setting 550. Of course, other data than these can also be included as appropriate.

The initial flight control settings 550 include an initial maximum number of storable objects 553, an initial number of objects that can be thrown simultaneously 554, an initial release condition 555, an initial possible flight distance 560, an initial flight altitude 561, an initial flight path type 562, an initial error 563, an initial bounce setting 564, an initial adhesion setting 565, and an initial weight equivalent parameter value 566. Of course, other data than these can also be included as appropriate.

Returning to FIG. 15, flight control setting change pattern definition data 570 is prepared for each flight control setting change pattern, and stores various definition data related to that change pattern. For example, as shown in FIG. 18, one flight control setting change pattern definition data 570 includes change implementation requirements 571 and change content data 573.

The change implementation requirements 571 define the requirements for selecting and applying the change pattern definition data. In this embodiment, they are described using AND or OR of multiple conditions. The type of condition used for the description can be set as appropriate. In this embodiment, the change implementation requirements 571 are described by combining one or more of the game space ID condition 571a, player character type condition 571b, stored object type condition 571c, stored object attribute condition 571d, stored object level condition 571e, sub-character type condition 571f, sub-character attribute condition 571g, and sub-character level condition 571h. Note that the setting for each of these conditions may include "none".

Change content data 573 is prepared for each change that will be made when the change pattern definition data is applied, and the flight control setting item to be changed and the change content are stored in association with each other.

Returning to FIG. 15, behavior control setting change pattern definition data 580 is prepared for each behavior control setting change pattern, and stores various definition data related to that change pattern. For example, as shown in FIG. 19, one behavior control setting change pattern definition data 580 includes change implementation requirements 581 and change content data 583.

The change implementation requirement 581 defines the requirements for selecting and applying the change pattern definition data. In this embodiment, it is described by AND or OR of multiple conditions. The type of condition used for the description can be set appropriately. In this embodiment, the change implementation requirement 581 is described by combining one or more of the following: game space ID condition 581a, player character type condition 581b, stored object type condition 581c, stored object attribute condition 581d, stored object level condition 581e, sub-character type condition 581f, sub-character attribute condition 581g, sub-character level condition 581h, enemy character contact presence/absence condition 581j, enemy character relative position condition 581k, enemy character type condition 581m, collision part condition 581n, and appearance terrain type condition 581p. Note that the setting of each of these conditions may include "none".

The sub-character type condition 581f can set the type of sub-character 5 to single or multiple. The case where a single type is set can be used when the change pattern is to be applied when the change pattern applies regardless of the number of sub-characters 5 stored in the storage object 7. The case where multiple types are set can be used when the change pattern is to be applied when the combination of sub-characters 5 stored in the storage object 7 applies.

The enemy character contact condition 581j is a condition regarding the presence or absence of a history of whether or not the flying set stored object 8 has come into contact with an enemy character 6 before the flight end condition is met.

The enemy character relative position condition 581k defines a condition regarding the relative positional relationship with the enemy character 6. The relative positional relationship describing the condition can be set as appropriate, and the condition can be described with a single or multiple relative positional relationships. For example, the following can be used to describe the enemy character 6: proximity, which is a state in which contact or a melee attack is possible with the enemy character 6 as the reference point, the enemy character 6 is within the attackable range, the enemy character 6 is outside the attackable range, the enemy character 6 is beyond an obstacle, the relative direction range, the relative distance range, etc.

The enemy character type condition 581m is a condition regarding the type of enemy character 6 with which the configured stored object 8 (the stored object 7 that stores the sub-character 5) flies and collides.

The collision part condition 581n is a condition regarding the part of the enemy character 6 that the set stored object 8 flies and collides with.

The appearance terrain type condition 581p is a condition regarding the type of terrain at the position where the configured storage object 8 flies and collides, or at the position where the sub-character 5 appears.

Change content data 583 is prepared for each change that will be made when the change pattern definition data is applied, and the behavior control setting item to be changed is stored in association with the change content.

Therefore, by appropriately setting the change implementation requirements 581 and the change content data 583, it is possible to change the behavior and abilities of the sub-character 5 after it appears in various ways. For example, even if the same sub-character 5 appears when the set stored object 8 collides with an enemy character 6 of type A and when the sub-character 5 appears when it collides with an enemy character 6 of type B, the pattern of automatic behavior control after it appears and its attacking ability can be made different. Also, even if it collides with the same enemy character 6, the pattern of automatic behavior control after it appears and its attacking ability can be made different depending on which part of the enemy character 6 the stored object 7 collides with.

By describing the change implementation requirements 581 and the change content data 583 in an appropriate combination, it becomes possible to change the behavior control settings in various ways under various conditions.
For example, the following behavior control settings can be made.
1) By including the enemy character contact condition 581j of "contact present" in the change implementation requirements 581, it is possible to set whether or not to change the behavior control setting related to the automatic control so that the change pattern can be applied when the set stored object 8 hits the enemy character 6. Then, the degree of change can be set by the change content of the change content data 583.

2) In the change content data 583, if a skill parameter value (corresponding to the initial skill parameter value list 531 in FIG. 17) is set in the behavior control setting item to be changed, it becomes possible to change a specific skill of the sub-character 5 if the change implementation requirements 581 are met.

3) In the change content data 583, if movement restrictions (corresponding to the initial movement restrictions 532 in FIG. 17) are set as the behavior control setting items to be changed, it becomes possible to remove or increase the movement restrictions if the change implementation requirements 581 are met.

4) In the change content data 583, if a weight equivalent parameter value (corresponding to the initial weight equivalent parameter value 533 in FIG. 17) is set in the behavior control setting item to be changed, when the change implementation requirements 581 are met, the sub-character 5 can be made lighter, and the flying distance of the set stored object 8 of the sub-character can be extended.

5) In the change content data 583, if the action type (corresponding to the initial action type definition data 534 in FIG. 17) is set as the action control setting item to be changed, the content of the automatic action of the sub-character 5, particularly the content of the attack action, can be changed if the change implementation requirements 581 are met.

Of course, the change implementation requirement 581 can contain a single condition. For example, if only the stored object type condition 581c is included, it is possible to set it so that a specific change is always applied when a specific stored object 7 is used.

Returning to FIG. 15, user management data 600 is prepared for each registered user and stores various data linked to an account, which is unique identification information. In this embodiment, as shown in FIG. 20, for example, one piece of user management data 600 includes a unique user account 601, payment medium ledger data 602, play history data 603, and game save data 610. Of course, data other than these may also be included as appropriate.

The payment medium ledger data 602 is a so-called ledger that stores information on the amount of replenishment/consumption of a payment medium for electronic payment (e.g., virtual currency, in-game currency, specific items, specific parameter values such as stamina, etc.) linked to the user, the reason for replenishment/consumption, and the date and time of change. It can be read as billing history data or billing history information.

The play history data 603 is data that describes when the game was played, what the playing results were, etc., and is stored in chronological order of the gameplay, and is automatically updated at the time of login/logout.

The game save data 610 stores various data describing the results of play up until the previous time the game was played and the state of game progress. For example, it includes owned main character save data 612, owned stored object save data 614, owned sub-character save data 616, and owned item data 618. Of course, data other than these may also be included as appropriate.

Returning to FIG. 15, play data 700 is prepared for each game play executed on the user terminal 1500, and stores various information related to the display of the game screen, such as various data describing the game progress status and control data for each character. As shown in FIG. 21, one piece of play data 700 includes, for example, a play start date and time 701, a player account 702 which is the user account of the user who is the player, user terminal access information 703 for accessing the player's user terminal 1500, a used game space ID 704, player character control data 705, enemy character control data 706, set stored object management data 710, predicted display control data 740, appeared sub-character automatic control data 750, and virtual camera control data 752. Of course, other data than these may also be included as appropriate.

The player character control data 705 and enemy character control data 706 are prepared for each player character 4 and enemy character 6, respectively, and store various data describing the latest state of the character in the game space (e.g., position coordinates, posture, ability parameter values, motion control data for the character model, etc.).

The set stored object management data 710 is created each time the player sets a combination of a sub-character and a stored object, that is, for each set stored object, and various data related to the set stored object is stored.

As shown in FIG. 22, for example, one set stored object management data 710 includes a unique stored object ID 711, a latest flight control setting 712, an applicable stored object item ID 714, stored character management data 720, a throw vector 728, flight destination coordinates 730, flight path data 731, a flight speed vector 732, position coordinates 734, a contact flag 736, and a release flag 738. Of course, other data than these can also be included as appropriate.

The type of data included in the latest flight control settings 712 is the same as that included in the initial flight control settings 550 (see FIG. 13). When the latest flight control settings 712 are initially set, the initial flight control settings 550 (see FIG. 17) for the stored object are copied, but are changed depending on the combination with the sub-character 5, etc.

The applicable storage object item ID 714 is the item ID of the storage object item 22 (e.g., see FIG. 8) associated with the storage object.

The stored character management data 720 is created for each sub-character combined with the configured stored object, and stores various data related to the sub-character. One stored character management data 720 includes, for example, a stored character ID 721, a latest behavior control setting 722, an applicable sub-character item ID 723, and an appearance date and time 724.

The type of data included in the latest behavior control settings 722 is the same as that of the initial behavior control settings 530 (see FIG. 12). When the latest behavior control settings 722 are initially set, the initial behavior control settings 530 (see FIG. 16) for the sub-character are copied, but are changed depending on the combination with the stored object 7, etc.

The applicable sub-character item ID 723 is the item ID of the sub-character item 21 (see, for example, FIG. 7) associated with the sub-character.

The throw vector 728 stores the initial condition for throwing the set stored object 8. In this embodiment, it is a vector based on the throw direction and throw force. In this embodiment, the throw direction is updated successively to match the forward direction of the player character 4 (the direction of the throw direction marker 12; see FIG. 4). The throw force is set to a predetermined initial value, but when a touch operation on the throw force input bar 14 (see FIG. 4), i.e., an input operation of the throw force, is detected, it is updated to a throw force corresponding to the touched position.

The destination coordinates 730 store the position coordinates in the game space of the destination. However, if the flight path type of the set stored object 8 is set to a type that causes the object to fly in pursuit of an enemy character 6 that is set (locked on) as the flight target, the destination coordinates 730 stores the position coordinates of the enemy character 6 that is the flight target, or a pointer that stores those position coordinates.

The flight path data 731 is a function indicating the path along which the set stored object 8 will fly, or a list of coordinate values of passing points. It is created when the set stored object 8 starts to be thrown, and the object is controlled to move along the path of the data. The path may be determined by physical calculations or pseudo-physical calculations, or a function such as a predefined pseudo-parabola may be applied.

The contact flag 736 indicates whether the configured stored object 8 of the management data has come into contact with an enemy character 6. The initial value when flight control begins is "0 (no contact)" and is automatically changed to "1 (contact)" upon contact with an enemy character 6.

The release flag 738 is set to "1" when a sub-character 5 is stored in the set stored object 8, and is changed to "0" when the release conditions included in the latest flight control settings 712 (initial release conditions 555 (see FIG. 17) are either copied or changed) are satisfied and the stored sub-character 5 is released and appears in the game space.

The already-appeared sub-character automatic control data 750 is created when the sub-character 5 is released from the already-set storage object 8 and appears in the game space. It stores various data describing the latest state of the sub-character (e.g., position coordinates, posture, ability parameter values, character model motion control data, remaining movement time (remaining time of action limit), etc.).

Virtual camera control data 752 is prepared for each virtual camera, and stores various parameter values that describe the latest state of that virtual camera. One piece of virtual camera control data 752 stores data such as a unique virtual camera ID, a corresponding character ID that indicates which character's viewpoint the virtual camera is set as, position coordinates and attitude in the game space, and the angle of view. In this embodiment, the player viewpoint virtual camera 41 (see FIG. 13) is created at the beginning of the game, but each time a sub-character 5 appears in the game space, data is created for the sub-character viewpoint virtual camera 42 that is associated with that sub-character.

FIG. 23 is a functional block diagram showing an example of the functional configuration of a user terminal 1500 in this embodiment. The user terminal 1500 in this embodiment includes an operation input unit 100, a device processing unit 200, a sound output unit 390, an image display unit 392, a communication unit 394, and a device storage unit 500.

The operation input unit 100 outputs operation input signals corresponding to various operation inputs made by the player to the device processing unit 200. For example, this can be realized by a push switch, joystick, touch pad, track ball, acceleration sensor, gyro, CCD module, etc. Examples of this include the directional input keys 1502, button switches 1504, and touch panel 1506 in Figure 2.

The device processing unit 200 is realized by electronic components such as a microprocessor such as a CPU or GPU, and an IC memory, and controls data input/output between each functional unit including the operation input unit 100 and the device storage unit 500. It controls the operation of the user terminal 1500 by executing various calculation processes based on predetermined programs and data, operation input signals from the operation input unit 100, and various data received from the server system 1100. This corresponds to the control board 1550 in Figure 2. The device processing unit 200 in this embodiment includes a user terminal calculation unit 280, a timer unit 288, a sound generation unit 290, and a communication control unit 294.

The user terminal calculation unit 280 includes an operation signal transmission control unit 281 and a game screen display control unit 282.

The operation signal transmission control unit 281 executes processing to transmit various data and requests to the server system 1100 in response to operations performed on the operation input unit 100.

The game screen display control unit 282 performs control for displaying a game screen based on various data received from the server system 1100. In this embodiment, the game space image (e.g., a 3DCG image, etc.) is configured to be generated by the server system 1100, but it is also possible to configure the game space image to be generated by the user terminal 1500. In that case, the game screen display control unit 282 will include control of objects arranged in a virtual three-dimensional space for generating the 3DCG, for example.

The sound generation unit 290 is realized by, for example, a digital signal processor (DSP), a processor such as a voice synthesis IC, an audio codec capable of playing audio files, etc., and generates sound signals for game-related sound effects, background music, and various operation sounds based on the processing results by the game screen display control unit 282, and outputs them to the sound output unit 390.

The sound output unit 390 is realized by a device that outputs sound effects, background music, etc. based on the sound signal input from the sound generation unit 290. This corresponds to the speaker 1510 in FIG. 2.

The image display unit 392 displays various game images based on image signals input from the game screen display control unit 282. For example, this can be realized by an image display device such as a flat panel display, a cathode ray tube (CRT), a projector, or a head-mounted display. In this embodiment, this corresponds to the touch panel 1506 in FIG. 2.

The communication control unit 294 executes data processing related to data communication, and realizes data exchange with an external device via the communication unit 394. The communication unit 394 realizes communication by connecting to the communication line 9. For example, this is realized by a wireless communication device, a modem, a TA (terminal adapter), a jack and a control circuit of a wired communication cable, etc., and corresponds to the wireless communication module 1553 in FIG. 2.

The terminal storage unit 500 stores various data and programs for implementing various functions for the terminal processing unit 200 to comprehensively control the user terminal 1500. It is also used as a working area for the terminal processing unit 200, and temporarily stores the results of calculations executed by the terminal processing unit 200 according to various programs and input data input from the operation input unit 100. These functions are implemented, for example, by IC memory such as RAM or ROM, magnetic disks such as hard disks, and optical disks such as CD-ROM or DVD. This corresponds to the IC memory 1552 and memory card 1540 mounted on the control board 1550 in Figure 2.

In this embodiment, the terminal storage unit 500 stores a game client program 504. Of course, other programs and data can also be stored as appropriate.

The game client program 504 is application software that the device processing unit 200 reads and executes to realize the functions of the user device computing unit 280. In this embodiment, it is a copy of the distribution game client program 502 (see FIG. 15) provided by the server system 1100.

The game client program 504 may be a dedicated client program depending on the technical method used to realize the online game, or may be configured with a web browser program and a plug-in that realizes interactive image display.

[Operation Description]
Next, a description will be given of the flow of processing in the server system 1100. The flow of processing described here is realized by the server processing unit 200s executing the server program 501.

24 and 25 are flowcharts for explaining the flow of processing in the server system 1100 relating to one game play.
The server system 1100 accepts the selection of the game space to be used and the selection of the main character 3 to be used as the player character 4 (step S10). For example, as for the game space to be used, the game spaces defined by the game space initial setting data 510 are presented in a selectable manner on the user terminal 1500, and a selection operation as to which one to play in is accepted. As for the player character 4, a list of the main characters 3 owned by the player is presented in a selectable manner, and a selection operation is accepted.

Next, the server system 1100 sets the set stored objects 8 that are to be possessed by the player character 4 from the start of game play (step S12).
Specifically, a predetermined number of already-set storage objects 8 can be set, and a storage setting process is executed for each of them.

FIG. 26 is a flowchart illustrating the flow of the storage setting process.
In this process, the server system 1100 first accepts the selection of the sub-characters 5 and stored objects 7 to be combined (step S50). Specifically, the user terminal 1500 extracts unused sub-characters 5 and stored objects 7 (those without set stored object management data 710: see FIG. 22) from among the sub-characters 5 and stored objects 7 owned by the player and presents them as selectable. At this time, if the initial upper limit number 553 (see FIG. 17) of the selected stored object 7 is multiple, multiple selections of sub-characters 5 to be combined with this upper limit can be accepted. This results in the primary setting of the set stored object 8, and new set stored object management data 710 is created in the play data 700 (see FIG. 21).

Next, the server system 1100 initializes the latest flight control setting 712 and the latest action control setting 722 according to the combination of the sub-character 5 and the stored object 7 (step S52; see FIG. 22).
Specifically, the initial flight control setting 550 (see FIG. 17) of the selected stored object 7 is copied into the latest flight control setting 712, and the initial behavior control setting 530 (see FIG. 16) of the selected sub-character 5 is copied into the latest behavior control setting 722 and initialized.

Next, the server system 1100 changes the initialized latest flight control settings 712 and latest behavior control settings 722 based on the flight control setting change pattern definition data 570 (see FIG. 18) and the behavior control setting change pattern definition data 580 (see FIG. 19) (step S54).
When the storage setting process is executed in step S12, the initial conditions for the flight of the set stored object 8 to be set remain unset. Therefore, among the behavior control setting change pattern definition data 580 (see FIG. 19), the change patterns including the enemy character contact condition 581j and the enemy character relative position condition 581k are not applied at this stage.

Then, the server system 1100 causes the user terminal 1500 to display a message informing the player of how the latest flight control settings 712 and latest behavior control settings 722 are set (step S56). By looking at this notification display, the player can determine whether the combination he or she is creating this time is appropriate.

If the player is not satisfied with the displayed notification, he or she can use an item to adjust the parameter values related to the combination.
That is, when the user terminal 1500 detects an operation to use an item having an effect of changing either the flight control setting or the behavior control setting (NO in step S58 -> YES in step S60), the server system 1100 associates the used item with the destination (storage object 7, sub-character 5) (step S62). Then, based on the effect of the used item, the latest flight control setting 712 or the latest behavior control setting 722 is changed (step S64), and the process returns to step S56. If an operation to change the combination of the sub-character 5 and the stored object 7 is detected (YES in step S66), the process returns to step S52.

Then, when input of a specified storage setting completion operation is detected on the user terminal 1500 (YES in step S58), the server system 1100 ends the storage setting process.

Returning to FIG. 24, next, the server system 1100 starts controlling the progress of game play (step S70). That is, background objects are arranged in the virtual three-dimensional space to form a game space, and the player character 4 and enemy character 6 are arranged. Then, the player character 4 is moved in response to the operation input of the player character 4, and automatic control of the enemy character 6 is started. In addition, controls that are basically required for progress control of a fighting game are also started as appropriate.

After the game play has started, if an operation to acquire a specific sub-character 5 or stored object 7 (e.g., purchasing via online shopping) is performed on the user terminal 1500 (YES in step S72), the server system 1100 executes the process to acquire the stored object 7 (step S74).

Furthermore, if the game progress satisfies the conditions for granting a stored object or a sub-character in the game space indicated by the used game space ID 704 (see the game space initial setting data 510 in FIG. 15) after game play has started (YES in step S76), the server system 1100 grants the player a new sub-character 5 or a stored object 7 according to the conditions that have been satisfied (step S78).

In this way, according to this embodiment, the player has the opportunity to obtain materials to use the sub-character 5 even during gameplay. In conventional fighting games in which sub-characters can be used, only sub-characters that have been prepared in advance can be used in gameplay. As a result, some players may find that their anticipated strategy or tactics are off the mark early in the game, and they are unable to progress in the game, so they may simply abandon gameplay or reset. However, in this embodiment, there is a degree of freedom in making the next move depending on the state of the battle, creating the fun of trying to turn the tide during gameplay.

Now, if a predetermined operation to start storage settings is input on the user terminal after game play has started (YES in step S90), the server system 1100 executes the storage settings process (step S91).

Then, when input of a predetermined pre-flight operation is detected on the user terminal 1500 during game play (YES in step S92), the server system 1100 starts control to adjust the direction of the throw vector 728 (see FIG. 22) so that it is sequentially aligned with the forward direction of the player character 4 (step S93).

Next, the server system 1100 displays the set stored object list 10 (see FIG. 4) on the user terminal 1500 and accepts the selection of the set stored object 8 to be thrown (step S94). At this time, if the number of simultaneous throwable objects (a copy of the initial simultaneous throwable object number 554 in FIG. 17 or a value changed later) in the latest flight control setting 712 of the selected set stored object 8 is multiple, multiple selections are accepted.

Next, the server system 1100 displays the throwing force input bar 14 (see FIG. 4) on the user terminal 1500 and starts sequentially adjusting the size of the throwing vector 728 in response to touch operations on the bar (step S96).

Moving on to FIG. 25, the server system 1100 starts sequentially adjusting the flight path and flight destination according to the latest throw specifications (step S98). Specifically, it provisionally determines the flight destination coordinates 730 and flight path data 731 based on the latest throw vector 728 and the flight path type in the latest behavior control setting 722 (see initial flight path type 562 in FIG. 17) (see FIG. 22). Then, it repeats this process every time the throw vector 728 is updated, and updates the flight destination coordinates 730 and flight path data 731.

Then, the server system 1100 updates the latest flight control settings 712 and the latest behavior control settings 722 (see FIG. 22) (step S100). That is, a step equivalent to step S54 of the storage setting process is performed again here, and a change pattern including enemy character contact presence/absence condition 581j and enemy character relative position condition 581k from the behavior control setting change pattern definition data 580 (see FIG. 19) is applied.

Then, the server system 1100 starts displaying various predictions, such as the predicted trajectory 30, the predicted flight destination 32, and the predicted behavior control setting information display 34, on the game screen (step S102; see FIG. 6).
The predicted flight destination 32 is expressed by a specified object, with the flight destination coordinates 730 at the center, and the range according to the initial error (a copy or modified value of the initial error 563 in FIG. 17) included in the latest flight control setting 712 .
The predicted trajectory 30 is expressed by setting an object that connects the player character 4 to flight destination coordinates 730 via a path indicated by flight path data 731 .

The behavior control setting information predictive display 34 displays the contents of the latest behavior control settings 722 (see FIG. 22). These may be displayed as text or as predetermined icons. It is preferable to automatically scroll as appropriate depending on the amount of displayed content.
Of course, these predictions are displayed again each time the destination coordinates 730 and flight path data 731 are updated.

Then, the server system 1100 starts accepting throwing-related operational inputs in a format based on the predictive display (step S104).

Specifically, as a guide display for correcting the throwing direction, scales are displayed along the top, bottom, left, and right of the game screen, centered on the displayed predicted flight destination 32 and predicted trajectory 30 (see FIG. 4), and when a specified direction change operation is detected, a guide display can be displayed in which the throwing direction is changed by one scale in the direction of the operation.

Similarly, the throwing force input bar 14 (see FIG. 4) can display a marker indicating the current throwing force position for correction, and scales in both strong and weak directions as guide displays for correction. Then, when a specified force change operation is detected, the throwing force is changed by one scale in the operated direction.

Regarding the lock-on marker 19 (see FIG. 7), other markers indicating that other flight target candidates are selection candidates may be displayed around the current lock-on marker 19, and when a specified target change operation is detected, the flight target candidate setting may be switched to an enemy character 6 with another marker attached that is closer to the direction of the operation.

If the predicted flight destination 32 and predicted trajectory 30 do not match the intended flight destination or flight path, the player 2 can adjust the throwing direction or throwing force by, for example, changing the front direction of the player character 4 (NO in step S110). Then, if the predicted display is as intended, the player inputs a specified action operation to cause the player character 4 to throw the selected set stored object 8.

When the server system 1100 detects input of a predetermined action operation at the user terminal 1500 (YES in step S110), it causes the set stored object 8 selected and accepted in step S94 to appear in the game space and starts controlling the flight display (step S112). Flight control continues until each of them satisfies a flight end condition. In this embodiment, the flight end condition is that the flying set stored object 8 comes into contact with an enemy character 6 or another object. The flight-controlled set stored object 8 is judged for contact with the enemy character 6 one by one, and upon contact, the contact flag 736 is changed to "1".

In addition, in steps S92 to S104, a specified flight cancellation operation can be accepted as appropriate.

Next, if there is a set stored object 8 that satisfies the flight end condition and whose release condition (the same as or changed to the initial release condition 555 in FIG. 17) is satisfied (YES in step S120), the server system 1100 updates the latest behavior control setting 722 of the sub-character 5 stored in that set stored object 8 (step S122).

Then, the sub-character 5 stored in the set stored object 8 is made to appear in the game space, and automatic control of the sub-character 5 is started based on the latest action control setting 722 of the sub-character 5 (step S124).
Accordingly, when automatic control begins, the server system 1100 creates already-appeared sub-character automatic control data 750 in the play data 700 (see FIG. 21), stores various data describing the latest situation under automatic control here, and updates it accordingly.

A sub-character 5 for which automatic control has been initiated is able to act and is automatically controlled until the action time limit (movement time) is reached, or a sub-character 5 that has already appeared will take damage when attacked by an enemy character 6, and the damage taken will reach a durability value, which is one of the ability parameter values. Regarding the determination based on the action time limit (movement time), the current date and time 800 is copied to the appearance date and time 724 of the stored character management data 720 (see FIG. 22) as the sub-character appears, and thereafter, the determination is made based on the time elapsed/time difference from this appearance date and time 724 to the current date and time 800.

In addition, when a new sub-character 5 appears, the server system 1100 additionally sets a sub-character viewpoint virtual camera 42 (see FIG. 13) corresponding to that sub-character, displays a viewpoint switching operation icon 15 on the game screen, and enables the reception of viewpoint switching operations (step S126).

Then, when an operation on a viewpoint switching operation icon 15 (15a, 15b) is detected during game play (YES in step S130), the server system 1100 executes a viewpoint switching process (step S132). That is, the display is switched so that the game screen shows an image of the game space with the viewpoint of the virtual camera corresponding to the operated viewpoint switching operation icon 15.

The server system 1100 repeatedly executes steps S72 to S140 until the game end condition is satisfied (NO in step S140).
If the game end condition is met (YES in step S140), progress control of the sub-character 5 and the stored object 7 is performed (step S142). Specifically, experience points are given to the sub-character 5 and the stored object 7 of the thrown set stored object 8, and the sub-character level and the stored object level are changed according to the accumulated experience points. Note that progress control may be limited to either the sub-character 5 or the stored object 7. Furthermore, the target of progress may be limited to the thrown set stored object 8 and the set stored object 8 that satisfies the release condition.

Next, the server system 1100 awards the player a bonus according to his/her performance (step S144). For example, the bonus may be a main character 3, a sub-character 5, a stored object 7, or an item. It may also be possible to open up a new game space for play.

Then, the server system 1100 updates the play history (step S146) and ends the series of processes.

As described above, this embodiment can provide a technology that adds new excitement to a competitive video game that uses sub-characters, which are NPCs that side with the main character controlled by the player.

That is, the player sets the set stored object 8 by storing the sub-character 5 in the storage object 7, and then issues an instruction to have the set stored object 8 thrown from the player character 4. The sub-character 5 is then controlled to appear at the throwing destination, and the sub-character 5 that appears is controlled to engage in combat with the enemy character 6, realizing a new style of fighting game.

The flight control settings for controlling the movement of the thrown configured stored object 8 and the behavior control settings for automatic control of the sub-character 5 released and appearing from the configured stored object 8 are changed according to the combination of the sub-character 5 and the stored object 7. This allows the player to enjoy thinking about tactics such as which sub-character 5 to combine with which stored object 7 and how to use them in which situation.

Moreover, the flight control settings and behavior control settings change depending on the main character 3 as the player character 4, the type of game space being played in, the use of items, and so on. In particular, the sub-characters 5 have a variety of different abilities and ways of attacking enemy characters 6, so tactical thinking becomes even more profound, making this a game with excellent replay value that never gets boring.

Second Embodiment
Next, a second embodiment to which the present invention is applied will be described. This embodiment is basically realized in the same way as the first embodiment, but differs in that the processing entity for game management is the user terminal 1500. Hereinafter, differences from the first embodiment will be mainly described, and components similar to those in the first embodiment will be given the same reference numerals and descriptions thereof will be omitted.

The game system 1000 of this embodiment is realized in the same manner as the first embodiment.
Furthermore, the game management unit 210 is omitted from the functional configuration of the server system 1100 of this embodiment.

Figure 27 is a functional block diagram showing an example of the functional configuration of the user terminal 1500B in this embodiment. The user terminal 1500B in this embodiment omits the user terminal calculation unit 280, and instead has a game management unit 210 and an image generation unit 292. The user terminal 1500B is a device that can be called a game device.

The image generation unit 292 generates data for displaying the game screen on the image display unit 392 and outputs an image signal to the image display unit 392.

In other words, in this embodiment, the user terminal 1500B executes its own calculations related to game management, controls the progress of the game, generates images for the game screen, and controls audio playback. However, online shopping, logging in/logging out as a registered user, and management of play history are performed in the same manner as in the first embodiment. However, this does not apply when the user terminal 1500 functions as a stand-alone game machine, that is, when a competitive game is realized as a non-online game.

Figure 28 is a diagram showing examples of programs and data stored in the terminal storage unit 500 of the user terminal 1500B of this embodiment. The terminal storage unit 500 of this embodiment stores a game program 505. The game program 505 is a program for causing the terminal processing unit 200 to realize the functions of the game management unit 210. The original may be stored in the server system 1100 as a game program for distribution and downloaded as necessary.

In addition, the terminal storage unit 500 of this embodiment stores game space initial setting data 510, enemy character initial setting data 512, item initial setting data 516, main character initial setting data 518, sub-character initial setting data 520, stored object initial setting data 540, flight control setting change pattern definition data 570, and behavior control setting change pattern definition data 580 as the game management unit 210 is processed by the user terminal 1500B. The originals of these are stored in the server system 1100 of this embodiment, and may be configured to be downloaded as necessary. In addition, play data 700 is stored as data that is created and updated sequentially.

The process flow executed by the user terminal 1500 in this embodiment is basically the same as that executed by the server system 1100 in the first embodiment (see Figures 24 to 25), and in accordance with the game management unit 210 being executed by the user terminal 1500B, the execution subject of each step should be appropriately replaced with the user terminal 1500B.

When the user terminal 1500B executes a process that requires referring to or changing the user management data 600, it appropriately requests the server system 1100 to provide or verify the necessary data, or to carry out the process itself.
If the user terminal 1500 is to function as a standalone game machine, that is, if the competitive game is to be realized as a non-online game, then in a configuration in which the user management data 600 is also managed by the user terminal 1500, the user management data 600 can also be stored in the terminal memory unit 500.

This embodiment provides the same effects as the first embodiment.

[Modifications]
Although the embodiment to which the present invention is applied has been described above, the forms to which the present invention can be applied are not limited to the above-described forms, and constituent elements can be added, omitted, or modified as appropriate.

[Modification 1]
For example, in the above embodiment, an example was given of an online game being realized in a client-server type computer system, but it may also be realized in a computer system in which a plurality of user terminals 1500 (or user terminals 1500B), which can be considered as game devices, are connected in a peer-to-peer manner. In this case, one of the user terminals 1500 is made to function as the server system 1100 of the first embodiment. Alternatively, the functions of the game management unit 210 may be shared among the plurality of user terminals 1500.

[Modification 2]
Furthermore, in the above embodiment, the game genre is a fighting game, but the present invention can be similarly applied to any game in which a sub-character 5 is used.

[Modification 3]
Furthermore, the changes to the flight control settings and behavior control settings are not limited to those that are advantageous to the player as exemplified above, but it is also possible to set settings that are disadvantageous to the player.

[Modification 4]
In the above embodiment, the change in the behavior pattern of the sub-character 5 is realized by changing the initial parameter values related to behavior control based on, for example, the behavior control setting change pattern definition data 580 (see FIG. 19), but this is not limited to this. For example, it may be realized by preparing a plurality of patterns of the initial behavior type definition data 534 (see FIG. 16) in advance and specifying which of these patterns is to be applied in the behavior control setting change pattern definition data 580.

[Modification 5]
The hardware configuration of the user terminals 1500 and 1500B is not limited to that in the above embodiment.
For example, a game device 1400 having a configuration as shown in FIG. 29 may be used as a user terminal 1500C.

The game device 1400 is a computer that is classified as a portable game device or a home game device, designed with portability and ease of use in mind. The game device 1400 includes a main unit 1401 and at least one detachable game controller 1460 (right game controller 1460R, left game controller 1460L).

The main device 1401 includes a touch panel 1406 that functions as an image display device and a touch position input device, a connector 1407, an internal battery 1409, a speaker 1410, and a control board 1450. In addition, a power button, a volume control button, etc. are provided as appropriate.

The connectors 1407 are provided at the left and right ends of the main unit 1401 corresponding to the right game controller 1460R and the left game controller 1460L. They are connected to the connectors of the right game controller 1460R and the left game controller 1460L to realize communication between the game controllers and the main unit 1401.

The control board 1450 is equipped with various processors such as a CPU (Central Processing Unit) 1451, a GPU (Graphics Processing Unit), and a DSP (Digital Signal Processor), various IC memories 1452 such as VRAM, RAM, and ROM, a communication module 1453 for wireless communication with mobile phone base stations, wireless LAN base stations, and other devices having short-range wireless devices, and an interface circuit 1457.

The interface circuit 1457 includes a driver circuit for the touch panel 1406, a circuit for transmitting and receiving signals to and from the right game controller 1460R and the left game controller 1460L via the connector 1407, and an output amplifier circuit for outputting audio signals to the speaker 1410.

These elements mounted on the control board 1450 are electrically connected via a bus circuit or the like, and are connected so that data can be read and written and signals can be sent and received. Note that part or all of the control board 1450 may be configured using an ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), or SoC (System on a Chip).

The control board 1450 stores programs and various data in the IC memory 1452, and the control board 1450 performs calculations based on these to implement various functions for executing the game of the present invention.

The right game controller 1460R and the left game controller 1460L are designed to be held by the player in the right and left hands, respectively. The right game controller 1460R and the left game controller 1460L each include a joystick 1461, multiple push switches 1462 that serve as operation buttons, a vibrator 1463 that is a vibration generating device, a speaker 1464, a connector 1467, a controller control board 1470, and a built-in battery (not shown).

The controller control board 1470 includes a controller control IC 1471, which corresponds to a processor that controls the game controller, a communication module 1473, a three-axis acceleration sensor 1475, a three-axis gyro sensor 1476, and an interface circuit 1477.

Of course, other elements, such as an image sensor module, can also be included as appropriate. Alternatively, some elements can be made to share the functions of other elements, thereby allowing those other elements to be omitted. For example, a configuration in which the 3-axis acceleration sensor 1475 and the 3-axis gyro sensor 1476 are realized by a single sensor, or a configuration in which the controller control IC 1471 and the interface circuit 1477 are integrated can also be used.

The communication module 1473 realizes wireless communication with the communication module 1453 of the main body device 1401.

As shown in Fig. 30, the three-axis acceleration sensor 1475 of the right game controller 1460R forms a right-handed local coordinate system (Xr, Yr, Zr). Specifically, the right direction when facing the front of the right game controller 1460R (the right side in Fig. 25) is the positive direction of the Xr axis, the upper longitudinal direction of the controller (the upper side in Fig. 25) is the positive direction of the Yr axis, and the normal direction to the front of the controller, i.e., the front side of the controller (the near side in Fig. 25), is the positive direction of the Zr axis.

The three-axis gyro sensor 1476 of the right game controller 1460R forms local coordinates (Xr, Yr, Zr) of the right hand system, and is configured to detect the angular velocity around each axis of the three-axis acceleration sensor 1475 of the right game controller 1460R.

An attachment 1468 can be attached to the left end of the right game controller 1460R so as to cover the connector 1467. The right game controller 1460R is held by placing the right side of the controller against the thumb and ball of the right hand and wrapping the index finger through little finger around the attachment 1468 of the controller. In other words, the controller is held in one hand with the back side opposite the front side facing the palm.

Similarly, the three-axis acceleration sensor 1475 of the left game controller 1460L forms a left-handed local coordinate system (Xl, Yl, Zl). Specifically, the left direction when facing the left game controller 1460L (left side in FIG. 30) is the positive direction of the Xl axis, the upper longitudinal direction of the controller (upper side in FIG. 30) is the positive direction of the Yl axis, and the normal direction to the front of the controller, i.e., the front side of the controller (near side in FIG. 30), is the positive direction of the Zl axis.

The three-axis gyro sensor 1476 of the left game controller 1460L forms local coordinates (Xl, Yl, Zl) of the left hand system, and is configured to detect angular velocity around each axis of the three-axis acceleration sensor 1475 of the left game controller 1460L.

An attachment 1468 can be attached to the left end of the left game controller 1460L so as to cover the connector 1467. The left game controller 1460L is held by placing the left side of the controller against the thumb and ball of the left hand and wrapping the index finger through little finger around the attachment 1468 of the controller. In other words, the controller is held in one hand with the back side opposite the front side facing the palm.

In a configuration that employs a user terminal 1500C (game device 1400), the start flight operation in the above embodiment can be realized by detecting acceleration or angular velocity exceeding a predetermined reference value that is recognized as an arm swing with the left game controller 1460L or the right game controller 1460R. In addition, the maximum value of the acceleration or angular velocity at that time can be used instead of inputting the throwing force into the throwing force input bar 14 (see FIG. 4).

2...Player 4...Player character 5...Sub-character (NPC)
6: enemy character 7: stored object 8: set stored object 10: set stored object list 21: item for sub-character 22: item for stored object 30: predicted trajectory 32: predicted flight destination 34: predicted display of action control setting information 41: player viewpoint virtual camera 42: sub-character viewpoint virtual camera 200s: server processing unit 210: game management unit 220: preparation setting unit 222: player character setting unit 224: storage setting unit 226: item setting unit 230: flight control unit 236: predicted display control unit 240: sub-character appearance control unit 250: sub-character automatic control unit 260: progress control unit 262: viewpoint switching control unit 500s: server memory unit 501: server program 520: sub-character initial setting data 530: initial action control setting 534: initial action type definition data 535: initial action type 536: initial attack content 537...Initial attack part weighting 538...Initial attack type 539...Initial action time limit 540...Stored object initial setting data 550...Initial flight control setting 570...Flight control setting change pattern definition data 571...Change implementation requirement 573...Change content data 580...Action control setting change pattern definition data 581...Change implementation requirement 581j...Enemy character contact presence/absence condition 581k...Enemy character relative position condition 583...Change content data 700...Play data 710...Set stored object management data 712...Latest flight control setting 714...Applied stored object item ID
720: stored character management data 721: stored character ID
722...Latest action control setting 723...Applicable sub-character item ID
724: Appearance date and time 728: Throwing vector 730: Flight destination coordinates 731: Flight path data 740: Predicted display control data 750: Appeared sub-character automatic control data 752: Virtual camera control data 1000: Game system 1100: Server system 1500: User terminal W4, W5, W6: Game screen

Claims (7)

A program for causing a computer system to execute a game in which a player character fights an enemy character,
NPC appearance control means for controlling the appearance of NPCs (non-playable characters) based on a predetermined operation by a player , the NPC appearance control means performing control for making two or more NPCs appear ;
an NPC automatic control means for automatically controlling the NPCs that have appeared by the NPC appearance control means;
a viewpoint switching means for switching a viewpoint of a game screen between a viewpoint based on said player character and a viewpoint based on each of NPCs made to appear by said NPC appearance control means;
A program for causing the computer system to function as the the NPC appearance control means performs control to make a plurality of NPCs appear based on a single action operation by the player;
The program according to claim 1. the NPC appearance control means performs control to cause an NPC to appear every time the player performs the predetermined operation, thereby performing control to cause two or more NPCs to appear;
The program according to claim 1. an appearing NPC setting means for selecting and setting an NPC to be appeared by said NPC appearance control means from among a plurality of NPCs based on a selection operation of said player;
The program according to any one of claims 1 to 3, for causing the computer system to further function as a A computer system for executing a game in which a player character fights an enemy character,
NPC appearance control means for controlling the appearance of NPCs (non-playable characters) based on a predetermined operation by a player , the NPC appearance control means performing control for making two or more NPCs appear ;
an NPC automatic control means for automatically controlling an NPC that has appeared by the NPC appearance control means;
a viewpoint switching means for switching a viewpoint of a game screen between a viewpoint based on the player character and a viewpoint based on each of the NPCs that have appeared by the NPC appearance control means;
A computer system comprising: 6. The computer system according to claim 5, wherein the server system is in a game system in which a user terminal used by a player and a server system communicate with each other to realize the competitive game. A game device for executing a game in which a player character fights an enemy character,
An NPC appearance control means for controlling the appearance of an NPC (non-playable character) based on a predetermined operation of a player , the NPC appearance control means performing control for making two or more NPCs appear ;
an NPC automatic control means for automatically controlling an NPC that has appeared by the NPC appearance control means;
a viewpoint switching means for switching a viewpoint of a game screen between a viewpoint based on the player character and a viewpoint based on each of the NPCs that have appeared by the NPC appearance control means;
A game device comprising: