JP2014028016A - Game control device and method for controlling game system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To stably execute a synchronous type event by avoiding an increase in a communication load due to communication convergence to a specific terminal device during performing a game introducing the synchronous type event.SOLUTION: A game server determines whether a synchronous type event with a first user satisfies a possible condition in the case where an event further should be performed between a third user and the first user while the synchronous type event is executed between a first user's terminal device and a second user's terminal device. In the case where the condition is satisfied, the game server starts the synchronous type event between the third user's terminal device and the first user's terminal device. Oppositely, in the case where the condition is not satisfied, the game server makes the third user's terminal device start an asynchronous type event with the first user.

Description

  The present invention relates to a game control device and a game system control method.

It is known that a battle game or the like in an online game is based on a synchronous event or an asynchronous event (for example, see Non-Patent Document 1).
In an online game based on a synchronous event, any user who is a participant in the game performs an operation for playing the game, and this operation is reflected in the progress of the game. On the other hand, in an online game based on an asynchronous event, an NPC (non-player character) performs an operation on a character corresponding to the other user, so that even if the other user does not perform an operation, the user only has to perform the operation. The game progresses.

Synchronous events have the advantage that they can be enjoyed while feeling the offense and defense with the other user, for example, because the operation of each user who is a participant is reflected in the progress of the game.
On the other hand, the asynchronous event allows the game to proceed even if the other user does not perform an operation, so that the game can be played at any time that suits the user's convenience without adjusting to the other user's convenience. There are advantages.

  In addition, at present, asynchronous events are often used in games using wireless communication between, for example, mobile phones and smartphones. In the case of an asynchronous event, for example, communication between the server that provides the game and the terminal device of the user who is the player may be performed, and it is not necessary to perform communication with the terminal device of the other user. One of the reasons is that it is light.

“Social Game General Information Magazine Application STYLE Vol.2”, East Press, Inc., April 1, 2011, p.26-p.29

  For example, even in the wireless communication environment as described above, there is a desire to play a game based on a synchronous event. However, for example, in the case of a game in which an event such as a battle is performed between a large number of unspecified users, depending on the content of the game, synchronization events with other users are concentrated on one user. Such a situation may occur. If this happens, the communication load between the terminal device of the one user and the server may increase, and the game may not be able to proceed normally.

  The present invention has been made in view of such circumstances. In playing a game that introduces a synchronous event, the synchronous event is stabilized by avoiding an increase in communication load due to concentration of communication with a specific terminal device. The purpose is to be executed.

  In order to solve the above-described problems, a game control device according to one aspect of the present invention includes a communication unit that communicates with a terminal device, an operation performed on a terminal device of a first user, and a terminal device of another user. The result of controlling the character of the first user and the character of the other user according to the operation performed on the terminal is communicated with the terminal device of the first user and the terminal device of the other user. A synchronous event execution unit that executes a synchronous event to be reflected in common in an event executed on the terminal device of the first user and an event executed on the terminal device of the other user by communication; The character of the first user and the character of the other user in accordance with an automatic process that is an alternative to the operation performed on the terminal device of the first user and an operation performed on the terminal device of another user An asynchronous event execution unit that executes an asynchronous event that reflects a result of controlling the data in an event executed on the terminal device of the other user via communication with the terminal device of the other user; When the synchronous event is being executed between the terminal device of the first user and the terminal device of the second user of the other users, the third user of the other users When a predetermined condition is satisfied in starting an event between the terminal device and the terminal device of the first user, between the terminal device of the first user and the terminal device of the third user. An event control unit that starts the asynchronous event, and when the predetermined condition is not satisfied, an event control unit that starts the asynchronous event with the terminal device of the other user as the terminal device of the third user; Provided.

  In the game control device of the present invention, the event control unit changes from a state where the predetermined condition is not satisfied to a state where the predetermined condition is satisfied after starting the asynchronous event. Depending on the case, the synchronous event may be switched.

  In the game control device of the present invention, the asynchronous event execution unit is simpler than an operation input interface that the synchronous event execution unit executes between the terminal device of the first user and the terminal device of another user. The operation input interface may be executed by a terminal device of another user.

  In the game control device of the present invention, the asynchronous event execution unit uses the character information of the third user and the same character information of the first user as that used in the synchronous event being executed. Then, the asynchronous event execution unit, the synchronous event execution unit, the first user character information read from the storage unit at the timing when the synchronous event is started and the first at the timing when the synchronous event ends Based on the difference from the user's character information, the first user's character information stored in the storage unit is updated at the timing when the synchronous event ends, and the asynchronous event execution unit The character information of the first user read from the storage unit at the start timing is the same as the character information of the first user. Based on the difference between the first user character information at the time when the type event has ended, the asynchronous event may update the character information of the first user stored in the storage unit at the timing ended.

  In the game control device of the present invention, the event control unit may be configured such that the first user is satisfied when the condition that the communication quality of the communication unit with the terminal device of the first user by the communication unit is equal to or higher than a certain level is satisfied. When the synchronous event is executed between the terminal device of the third user and the terminal device of the third user, and the condition is not satisfied because the communication quality is less than a certain level, the terminal device of the other user is The asynchronous event for a three-user terminal device may be executed.

  In the game control device of the present invention, when the event control unit satisfies the condition that the number of terminal devices of the second user when the synchronous event is being executed is equal to or less than a predetermined value. If the synchronous event is executed for the terminal device of the first user and the terminal device of the third user, and the condition is not satisfied because the number of terminal devices of the second user is greater than a certain number In addition, the asynchronous event in which the terminal device of the other user is the terminal device of the third user may be executed.

  In the game control device of the present invention, the event control unit transmits the event application transmitted from the third user terminal device to the first user terminal device in order to apply for an event with the first user. When the operation for accepting the event application is performed, an event acceptance notification transmitted from the terminal device of the first user is received, and when the condition that the event acceptance notification is received is satisfied, When the synchronous event for the terminal device of the first user and the terminal device of the third user is executed and the condition is not satisfied by not receiving the event acceptance notification, the other user's terminal device The asynchronous event using the terminal device as the terminal device of the third user may be executed.

  The game control method as one aspect of the present invention includes a communication unit connected to a terminal device, an operation performed on the terminal device of the first user, and an operation performed on the terminal device of another user. The first user's character and the other user's character are controlled as a result of communication with the first user's terminal device and communication with the other user's terminal device. A synchronous event execution unit for executing a synchronous event to be reflected in common to an event executed on a user terminal device and an event executed on the other user terminal device; and the first user terminal device The result of controlling the character of the first user and the character of the other user according to the automatic processing that is an alternative to the operation performed on the terminal and the operation performed on the terminal device of the other user, A control method of a game system having an asynchronous event execution unit that executes an asynchronous event to be reflected in an event executed on the other user's terminal device via communication with the other user's terminal device When the synchronous event is being executed between the terminal device of the first user and the terminal device of the second user of the other users, the third of the other users When a predetermined condition is satisfied in starting an event between the user terminal device and the first user terminal device, the first user terminal device and the third user terminal device The synchronous event is started, and if the predetermined condition is not satisfied, the asynchronous event is started with the other user terminal device as the third user terminal device. Equipped with a vent control step.

  As described above, according to the present invention, when playing a game that introduces a synchronous event, an increase in communication load due to concentration of communication with a specific terminal device is avoided, and the synchronous event is executed stably. The effect of being able to be obtained.

It is a figure which shows the structural example of the game system in embodiment of this invention. It is a figure which shows the example of control about the battle event in this embodiment. It is a figure which shows the structural example of the game server and terminal device in this embodiment. It is a figure which shows the structural example of the character information table in this embodiment. It is a figure which shows the structural example of the synchronous event registration table in this embodiment. It is a figure which shows the example of a process sequence which the game server in 1st Embodiment performs. In the game server of 1st Embodiment, it is a figure which shows the example of a process sequence for determining whether the conditions which can perform a synchronous event are satisfy | filled. It is a figure which shows the example of a process sequence for determining whether the game server of 2nd Embodiment satisfy | fills the conditions which can perform a synchronous event. It is a figure which shows the example of a process sequence for determining whether the game server of 3rd Embodiment satisfy | fills the conditions which can perform a synchronous event. It is a figure which shows the example of a process sequence for the game server of 4th Embodiment to switch from an asynchronous type event to a synchronous type event. It is a figure which shows the example of a game screen by the advanced type operation input interface in 5th Embodiment, and the game screen by a simple type operation input interface. It is a figure which shows the example of the information content which the memory | storage part in 5th Embodiment memorize | stores. It is a figure which shows the example of the information content which the application part in 5th Embodiment has. It is a figure which shows one specific example of the update process of the character information in 6th Embodiment.

<First Embodiment>
[Game system configuration example]
FIG. 1 shows a configuration example of the game system in the present embodiment. The game system shown in this figure includes a game server 100 and a plurality of terminal devices 200 (200-1 to 200-3). The game server 100 and the plurality of terminal devices 200 communicate via the network 300.

The game server (game control device) 100 is a server that provides the game of the present embodiment to the terminal device 200 connected via the network 300. The game of the present embodiment is a battle-type game in which, for example, two users battle each other. On this game, a character corresponding to each user plays a battle.
The terminal device 200 is a network terminal owned by a user who is a game participant. A game application corresponding to the game of this embodiment is installed in the terminal device 200. The user of the terminal device 200 can play the game of this embodiment by starting a game application and performing an operation.
The terminal device 200 is a portable wireless terminal such as a mobile phone or a smartphone.

  Moreover, in this figure, as the terminal device 200, the terminal device 200-1 owned by the first user, the terminal device 200-2 owned by the second user, and the terminal device 200-3 owned by the third user, It is shown.

Here, a 1st user is a user who becomes an opponent of a 2nd user or a 3rd user on the game of this embodiment.
The second user is a user who battles with the first user by a battle event (synchronous battle event) as a synchronous event. There may be a plurality of second users. A 3rd user is a user who starts the battle | competition by the battle event (asynchronous battle event) as a synchronous battle event or an asynchronous event between 1st users. There may also be a plurality of third users.

  In the synchronous battle event, the communication unit of the game server 100 communicates with the terminal device 200-1 of the first user and the terminal device 200 of the other user, so that the terminal device of the first user and the terminal device of the other user Communicate between. In addition, in the synchronous event, the character of the first user and the other are determined according to the operation performed on the terminal device 200-1 of the first user and the operation performed on the terminal device 200 of another user. Control the user's character. And the result of this control is reflected in common with the event performed on the terminal device 200-1 of a 1st user, and the event performed on the terminal device 200 of another user.

  In an asynchronous battle event, communication between the terminal device 200-1 of the first user and the terminal device 200 of another user is not performed. In addition, depending on automatic processing that is an alternative to the operation performed on the terminal device 200-1 of the first user and the operation performed on the terminal device of another user that does not communicate with the terminal device 200 of the first user. The first user's character and the other user's character are controlled. Then, the result of this control is reflected in an event executed on the terminal device 200 of another user.

[Game Overview]
In the competitive game of the present embodiment, for example, the user can grow into a special character having a very strong power through a predetermined process in the progress of the game. Other users having other types of characters that are not special characters can challenge the special character.
However, since special characters are very strong, they cannot be defeated by a single standard character battle. In other words, multiple standard characters must cooperate. For this reason, in the game of this embodiment, one special character will perform a battle event with many standard characters.
The first user shown in FIG. 1 is a user having a special character. In addition, the second user and the third user are users having standard characters that perform battle events with the special character of the first user.

In the case of the present embodiment, as understood from the above description, communication with a large number of other user terminal devices 200 concentrates on the first user terminal device 200-1 having a special character. Can occur.
In this case, if a battle event based on a synchronous event is performed each time a terminal device 200 of another user is connected to the terminal device 200-1 of the first user, the terminal device 200-1 of the first user is As a result of communication with the terminal devices 200 of many other users, the traffic is greatly increased, and the communication load associated therewith is also increased. In such a state, for example, there is a possibility that the delay of communication data becomes large and the game cannot proceed normally.

  Therefore, in the present embodiment, in order to ensure that the progress of the game performed between the first user and many other users is always normal, as described below, the terminal device 200- of the first user 1 and an increase in communication load between the game server 100 is avoided.

[Battle event control example]
FIG. 2 shows an example of control for a battle event executed by the game server 100 of the present embodiment.

First, in a state where the terminal device 200-1 of the first user is not executing a battle event with any of the other terminal devices 200, the second user performs an operation for applying for a battle event to the first user. -2. In response to this operation, the terminal device 200-2 of the second user transmits a battle event application for the first user to the game server 100 (step S1).
In the following, the user of the terminal device 200 that has transmitted the battle event application is also referred to as an application user, and the user designated as an opponent by the battle event application is also referred to as an applied user.

  When a battle event application is transmitted by step S1, as above-mentioned, the 1st user's terminal device 200-1 is in the state which is not performing the battle event with any of the other terminal devices 200. In this state, the communication load does not increase due to the execution of the synchronous battle event. Therefore, in this case, the game server 100 causes a synchronous battle event to be executed between the terminal device 200-1 of the first user and the terminal device 200-2 of the second user in response to receiving the battle event application.

At this time, the game server 100 communicates with each of the terminal device 200-1 and the terminal device 200-2. And the character of a 1st user and a 2nd user is controlled according to operation performed with respect to the terminal device 200-1 and the terminal device 200-2. Here, the control of the character includes a process of changing the character information for generating the character according to, for example, the battle result in the battle event.
And the game server 100 reflects this control result on each of the battle event performed on the terminal device 200-1, and the battle event performed on the terminal device 200-2. In this case, the first user character and the second user character in the games on the terminal devices 200-1 and 200-2 are both PCs (player characters).

  Next, it is assumed that the third user performs an operation for applying for a battle event to the first user on the terminal device 200-3 while the synchronous battle event in step S2 is being executed. In response to this operation, the terminal device 200-3 of the third user transmits a battle event application for the first user to the game server 100 (step S3).

When the game server 100 receives the battle event application for the first user in step S3, the terminal device 200-1 of the first user is already executing a synchronous battle event. In this state, for example, depending on the number of second user terminal devices 200 executing a synchronous battle event, the communication load may be considerably increased.
Therefore, the game server 100 in this case determines whether or not a predetermined condition capable of executing the synchronous battle event is satisfied (step S4). An example of this predetermined condition will be described later.

As a result of the condition determination in step S4, when it is determined that the predetermined condition is satisfied, the game server 100 determines that the first user terminal device 200-1, the second user terminal device 200-2, and the third user terminal. A synchronous battle event is executed with the device 200-3 (step S5-1).
At this time, the third user is added to the group of the synchronous event registration table in which the first user and the second user are registered, and an operation signal is transmitted between the terminal devices 200 of the first user, the second user, and the third user. Etc., and a synchronous event is performed among the first user, the second user, and the third user.

  On the other hand, if it is determined as a result of the condition determination in step S4 that the predetermined condition is not satisfied, the game server 100 sends an asynchronous battle event with the first user character to the third user terminal device 200-3. It is executed (step S5-2).

In the case of an asynchronous battle event, the operation performed on the terminal device 200-3 of the third user does not need to be reflected on the terminal device 200-1 of the first user. Communication with the terminal device 200-1 corresponding to the battle event executed on the user terminal device 200-3 is not executed. That is, the terminal device 200-1 of the first user executes only communication corresponding to the synchronous battle event with the terminal device 200-2 of the second user with the game server 100.
In this case, the character of the first user in the game on the terminal device 200-3 of the third user is an NPC (non-player character), and the character of the second user is a PC.

That is, in this embodiment, in the state where the terminal device 200-1 of the first user and the terminal device 200-2 of the second user are executing the synchronous battle event, another user has applied for the battle event. The control is performed as follows.
In the present embodiment, if a predetermined condition for executing a synchronous battle event is satisfied, a synchronous battle event with another user as a new second user is started. On the other hand, if the predetermined condition for executing the synchronous battle event is not satisfied, an asynchronous battle event with another user as the third user is started.
When an asynchronous battle event is executed, communication with the terminal device 200-1 of the first user is not performed, so the communication load of the terminal device 200-1 does not increase. As described above, in the present embodiment, communication with the first user terminal device 200-1 is performed by introducing the asynchronous battle event and executing the asynchronous battle event in parallel in accordance with a predetermined condition. An increase in communication load due to concentration of data can be avoided.

[Game server configuration example]
FIG. 3 shows a configuration example of the game server 100 and the terminal device 200. In this figure, the network 300 is not shown.

First, a configuration example of the game server 100 will be described.
The game server 100 shown in this figure includes a communication unit 101, a synchronous event execution unit 102, an asynchronous event execution unit 103, an event control unit 104, and a storage unit 105.

The communication unit 101 communicates with the terminal device 200 via the network 300.
The synchronous event execution unit 102 executes a synchronous event as a battle event.
Specifically, the synchronous event execution unit 102 organizes the terminal devices 200 operated by the users participating in the synchronous event when the event control unit 104 described later determines that the synchronous event should be executed. At the same time, by sharing information via the network 300, a synchronous event performed in the same game space is controlled.
That is, when the event control unit 104 determines that the synchronous event should be executed, the synchronous event execution unit 102 stores the user who performs the synchronous event in the synchronous event registration table, and the terminal devices 200 To share operation signals.
The synchronous event registration table is information indicating users registered as participants of the synchronous event corresponding to each synchronous event, as will be described later with reference to FIG. This synchronous event registration table is stored in the storage unit 105. Each time a user newly participates in a synchronous event, the newly participating user is newly registered in the synchronous event registration table. The synchronous event execution unit 102 organizes the terminal devices 200 by, for example, sharing an operation signal or the like between the registered user terminal devices 200.

On the other hand, the asynchronous event execution unit 103 executes an asynchronous event as a battle event.
Specifically, the asynchronous event execution unit 103 communicates via the network 300 only between the application user's terminal device and the game server 100 when the event control unit 104 described later determines that an asynchronous event is to be executed. To control asynchronous events. In this case, because the character of the user to be applied is operated as an NPC by the asynchronous event execution unit 103, for example, it is not necessary to perform data communication between the terminal device of the user to be applied and the terminal device of the application user.

  In addition, you may make the game application part 202 of the terminal device 200 mentioned later perform operation of NPC. In this case, when the event control unit 104 determines that the asynchronous event execution unit 103 should execute the asynchronous event, the asynchronous event execution unit 103 displays the character information of the character operated by NPC for the terminal device 200 of the application user. Send. At the same time, the asynchronous event execution unit 103 may transmit only an instruction to execute the asynchronous event to the terminal device 200 of the application user. In this case, it is not necessary to communicate with the game server 100 via the network 300 during the event execution.

When the synchronous event is being executed between the terminal device 200-1 of the first user and the terminal device 200-2 of the second user, the event control unit 104 further performs the terminal device 200-3 of the third user. When starting an event (battle event) between the terminal device 200-1 of the first user and the first user, the following control is performed.
That is, if the predetermined condition is satisfied, the event control unit 104 stores the user ID of the third user in addition to the user ID of the first user and the user ID of the second user in the synchronous event registration table. To do. In response to this, the synchronous event execution unit 102 causes the terminal devices 200 of the first to third users to share operation signals and the like. Thereby, the synchronous event execution part 102 adds a 3rd user to the synchronous event currently performed by the 1st user and the 2nd user, the 1st user's terminal device 200-1, the 2nd user's terminal A synchronous event is executed between the device 200-2 and the terminal device 200-3 of the third user.
On the other hand, when the predetermined condition is not satisfied, the event control unit 104 starts an asynchronous event in which the terminal device 200 of the other user is the terminal device 200-3 of the third user.

  The storage unit 105 stores various information necessary for the game server 100 to provide a game to the terminal device 200. In FIG. 3, a character information table 110 and a synchronous event registration table 120 are shown as such information.

  FIG. 4 shows a structural example of the character information table 110. The character information table 110 shown in this figure shows a table structure example corresponding to one user. The storage unit 105 includes a table having the structure shown in the figure for each user registered as a game user.

The character information table 110 for one user shown in FIG. 4 includes a user ID storage area 111 and a character information storage area 112.
The user ID storage area 111 is an area for storing a user ID for identifying a corresponding user.
The character information storage area 112 is an area for storing character information related to one or more characters possessed by the corresponding user.

  The character information storage area 112 further includes a character ID storage area 112a, a character display data storage area 112b, a hit point storage area 112c, an attack power storage area 112d, a defense power storage area 112e, an experience value storage area 112f, and battle event status information. A storage area 112g is provided.

  The character ID storage area 112a stores a character ID that uniquely identifies the corresponding character.

  The character display data storage area 112b stores character display data for displaying a corresponding character. The game application unit 202 of the terminal device 200 displays a character on the game screen using the character display data.

The hit point storage area 112c stores the value of the hit point set for the corresponding character.
The attack power storage area 112d stores a value indicating the attack power set for the corresponding character.
The defense level storage area 112e stores a value indicating the defense level set for the corresponding character.
The experience value storage area 112f stores experience values set for the corresponding character.

The battle event status information storage area 112g stores battle event status information indicating the current status of the battle event for the corresponding character.
In the case of the example in FIG. 4, the battle event status information of the character with the character ID 00001 indicates that a synchronous battle event is being executed with the character of the second user. Further, the battle event status information of the character with the character ID of “00002” indicates that an asynchronous battle event is being executed with the character of the third user. Further, the battle event status information of the character with the character ID of 00003 indicates that a battle event is on standby.

FIG. 5 shows the synchronous event registration table 120. One record in the synchronous event registration table 120 corresponds to one synchronous event. One record includes a main user ID storage area 122 and a plurality of sub user ID storage areas 123-1 to 123-n with respect to the group ID storage area 121.
The group ID storage area 121 is an area for storing a group ID set corresponding to the corresponding synchronous event.
The main user ID storage area 122 is an area for storing a user ID of a user who has applied for a battle event. By storing the user ID in the main user ID storage area 122, the user indicated by the user ID is registered as the application user.
The sub user ID storage areas 123-1 to 123-n are areas in which user IDs of application users whose battle event applications have been accepted by the application user are stored. By storing the user ID in the sub user ID storage areas 123-1 to 123-n, the user indicated by the user ID is registered as the application user.
By managing the users who participate in the synchronous event in this embodiment in this way, for example, the user characters stored in the sub user ID storage areas 123-1 to 123-n are mutually connected in the synchronous battle event. You can avoid being affected by the attack.

[Configuration example of terminal device]
Next, referring to FIG. 3 again, a configuration example of the terminal device 200 will be described. In FIG. 3, the configuration of only the terminal device 200-1 is shown, but the remaining terminal devices 200-2 and 200-3 may have the same configuration as the terminal device 200-1.

  The terminal device 200 includes a communication unit 201, a game application unit 202, a display unit 203, and an operation unit 204.

  The communication unit 201 communicates with the game server 100 via the network 300.

The game application unit 202 executes a function corresponding to the game of the present embodiment. For example, the game application unit 202 transmits an operation signal corresponding to an operation performed on the game to the game server 100. In addition, the game application unit 202 generates a game screen corresponding to the progress of the game at that time based on the game control information transmitted from the game server 100. The game information includes, for example, a result of controlling the character by the synchronous event execution unit 102 or the asynchronous event execution unit 103 of the game server 100 according to the operation signal. The game application unit 202 causes the display unit 203 to display the generated game screen.
Note that the function of the game application unit 202 is realized by a CPU (Central Processing Unit) in the terminal device 200 executing a game application program. Here, the above-described synchronous battle event and asynchronous battle event are respectively known game application programs executed by the game application unit 202.

The display unit 203 displays a game screen according to the control of the game application unit 202.
The operation unit 204 collectively indicates operators and operation devices of the terminal device 200 that are used to perform operations on the game application unit 202. For example, when a touch panel is provided for the display unit 203 of the terminal device 200, the touch panel is included in the operation unit 204.

[Example of processing procedure]
The flowchart in FIG. 6 shows an example of a processing procedure executed by the game server 500.
The user of the terminal device 200 can perform an operation on the game screen displayed by the game application unit 202, for example, by designating an opponent user and applying for a battle event. In response to this operation, the game application unit 202 transmits a battle event application from the communication unit 201 to the game server 100 via the network 300.

In the game server 100, the event control unit 104 waits for the battle event application transmitted from the terminal device 200 to be received by the communication unit 101 as described above (step S101—NO).
Then, in response to receiving the battle event application (step S101-YES), the event control unit 104 is currently executing the synchronous battle event for the user to be applied who is designated as the opponent by the battle event application. It is determined whether or not (step S102). For this determination, for example, the event control unit 104 may refer to the content of the battle event status stored in the battle event status information storage area 112g in the character information table of the application user.
In addition, the application user designated as an opponent by the battle event application corresponds to the first user in FIG.

  When the user to be applied is executing a synchronous battle event (step S102-YES), the event control unit 104 determines whether or not the application user satisfies a condition for starting a synchronous battle event with the user to be applied. Condition determination is executed (step S103).

As this condition determination, in the first embodiment, it is determined whether or not the condition that the number of terminal apparatuses 200 that are executing a synchronous battle event with the application user's terminal apparatus 200 is equal to or less than a certain condition is satisfied. The communication quality of communication between the terminal device 200 of the user to be applied and the game server 100 correlates with the number of other terminal devices 200 that execute a synchronous battle event with the terminal device 200 of the user to be applied. That is, communication by communication between the terminal device 200 of the user to be applied and the game server 100 in accordance with an increase in the number of other terminal devices 200 that execute a synchronous battle event with the terminal device 200 of the user to be applied. As the load increases, the communication quality deteriorates accordingly. Therefore, a value (that is, a threshold value) used for determination as to whether or not it is below a certain level in step S103 can be determined in advance based on the above correlation.
In the present embodiment, the fact that the number of terminal devices 200 that are executing a synchronous battle event with the terminal device 200 of the user to be applied is below a certain level means that there is still a margin in the communication load of the terminal device 200 of the user to be applied. This means that the communication quality can be kept above a certain level even if a synchronous battle event is further added.

  The flowchart of FIG. 7 shows an example of a processing procedure for condition determination as step S103 in the first embodiment. The event control unit 104 determines whether or not the number of terminal devices 200 of other users (second users) who are currently executing a synchronous battle event with the terminal device 200 of the user to be applied is equal to or less than a certain value. (Step S201). In this determination, the event control unit 104 may refer to the content of the battle event status stored in the battle event status information storage area 112g in the character information table of the application user.

When the number of terminal devices 200 that are executing a synchronous battle event is equal to or less than a certain value (step S201—YES), the event control unit 104 determines that the condition is satisfied (step S202).
On the other hand, when the number of terminal devices 200 that are executing a synchronous battle event is less than a certain number (step S201—NO), the event control unit 104 determines that the condition is not satisfied (step S203).

Returning to FIG.
The event control unit 104 determines whether or not a determination result that the condition is satisfied is obtained by the condition determination in step S103 (step S104).
When a determination result that the condition is satisfied is obtained (step S104-YES), or when the terminal device 200 of the user to be applied is not executing a synchronous battle event (step S102-NO), event control The unit 104 performs the following process to start a synchronous battle event.

  In other words, the event control unit 104 reads the character information of each character used for the synchronous battle event from the character information table 110 corresponding to the application user and the application user (step S105).

  In step S105 in the first embodiment, the event control unit 104 is not used for a synchronous battle event when the terminal device 200 of the applying user is executing a synchronous battle event for the user to be applied. Read the character information of the character. The character that is not used in the synchronous battle event is a character that indicates that the battle event status storage information stored in the battle event status information storage area 112g is waiting.

Next, the event control unit 104 causes the synchronous event execution unit 102 to start a synchronous battle event between the terminal device 200 of the application user and the terminal device 200 of the application user (step S106).
At this time, the synchronous event execution unit 102 inputs the information to the character information storage area 112 of the application user and the character information storage area 112 of the application user read by the event control unit 104 in step S105, It is stored in the event registration table, and operation signals and the like can be shared between the terminal devices 200. Thereafter, the synchronous event execution unit 102 controls the character information of the user to be applied and the character information of the user to be applied according to operations performed on the terminal device 200 of the user to be applied and the terminal device 200 of the user to be applied. Perform synchronous battle event processing.

On the other hand, when the determination result that the condition is not satisfied is obtained (NO in step S104), the event control unit 104 executes the following process to start an asynchronous battle event.
That is, the event control unit 104 reads the character information of each one character used for the synchronous battle event corresponding to the application user and the application user from the character information table 110 (step S107).
Next, the event control unit 104 causes the asynchronous event execution unit 103 to start an asynchronous battle event with the application user on the terminal device 200 of the applying user (step S108). At this time, the asynchronous event execution unit 103 or the event control unit 104 may notify the application user's terminal device 200 that the application user and the asynchronous battle event are being executed. .

<Second Embodiment>
[Overview]
Next, the second embodiment will be described.
In the second embodiment, the contents of the conditions in the condition determination processing as step S103 in FIG. 6 are different from those in the first embodiment.
In the second embodiment, the condition under which the application user can start a synchronous battle event with the application user is that the communication quality of communication between the terminal device 200 of the application user and the communication unit 101 of the game server 100 is constant. That's it.

An example of the index as communication quality here is traffic between the terminal device 200 of the user to be applied and the communication unit 101 of the game server 100. For example, if the traffic exceeds a certain level, the packet delay time also increases, and it becomes difficult to execute a synchronous battle event normally.
Further, the index as communication quality may be a packet error rate, a bit error rate, or the like. Or the CPU usage rate etc. which the game server 100 allocates for communication with the terminal device 200 of a user to be applied may be sufficient. A combination of these indices may be used as the communication quality of the present embodiment.

[Example of processing procedure]
The flowchart of FIG. 8 shows an example of a processing procedure for condition determination as step S103 of FIG. 6 in the second embodiment. In this figure, the same steps as those in FIG. 7 are denoted by the same reference numerals. FIG. 8 shows processing when traffic between the terminal device 200 of the user to be applied and the communication unit 101 of the game server 100 is adopted as an index of communication quality.

In the game server 100, the communication unit 101 measures, for example, communication traffic with the terminal device 200 of the application user. The event control unit 104 acquires the traffic measurement result from the communication unit 101 (step S201A).
Next, the event control unit 104 determines whether or not the acquired traffic is greater than or equal to a certain level (step S201B). This determination corresponds to determining whether or not the communication quality is a certain level or higher.
When the traffic is above a certain level (step S201B-YES), the event control unit 104 determines that a condition that allows the applying user to start a synchronous battle event with the user to be applied is satisfied (step S202). On the other hand, when the traffic is less than a certain level (step S201B-NO), the event control unit 104 determines that a condition that allows the applying user to start a synchronized battle event with the user to be applied is not satisfied (step S201B-NO). S203).

  Thus, by performing the condition determination as step S103 based on the communication quality of communication between the terminal device 200 of the user to be applied and the communication unit 101 of the game server 100, a normal operation for the synchronous battle event is ensured. It becomes possible. Further, based on the communication quality itself, the condition determination can be performed with high accuracy. In addition, by making the condition determination based on the communication quality itself, normal operation for the synchronous battle event can be performed in response to a situation where the communication quality deteriorates due to factors other than the communication load due to the execution of the synchronous battle event. Can be secured.

<Third Embodiment>
[Overview]
Subsequently, a third embodiment will be described.
In the third embodiment, the contents of the conditions in the condition determination processing as step S103 in FIG. 6 are different from those in the first embodiment and the second embodiment.
In the third embodiment, the condition in the condition determination process in step S103 in FIG. 6 is that the user to be applied for has applied for a battle event.
That is, in the third embodiment, if the user to be applied receives a battle event application from the application user, a synchronous battle event is started. On the other hand, if the application user does not accept a battle event application from the application user, an asynchronous battle event is started.

[Example of processing procedure]
With reference to the flowchart of FIG. 9, the example of the process sequence for condition determination as step S103 in 3rd Embodiment is demonstrated.
In the third embodiment, in response to receiving a battle event application from the application user's terminal device 200, the event control unit 104 has applied for a battle event to the application user's terminal device 200. This notification is transmitted (step S201C).

In response to receiving a notification that a battle event application has been made, the game application unit 202 in the terminal device 200 of the user to be applied displays a message notifying the user that a battle event application has been made on the game screen. To do. The user to be applied who saw this display performs either an operation for accepting the battle event application or an operation for rejecting the acceptance of the battle event application on the game screen.
For example, if it is determined that the communication load does not increase so that the operation of the game becomes unstable even if the number of synchronous battle events is still increased, the user to be applied performs an operation of accepting a battle event application.

  On the other hand, if the user to be applied is more likely to execute a synchronous battle event and the communication load becomes large and the operation of the game becomes unstable, the user to be applied performs an operation to reject acceptance of the battle event application. In addition, the user to be applied can perform an operation of rejecting acceptance of the battle event application even when he / she does not want to perform any more synchronous battle events for reasons other than the communication load. Thus, in the third embodiment, the user's own intention can be reflected in the condition for executing the asynchronous battle event.

The game application unit 202 of the terminal device 200 of the user to be applied transmits a battle event reception notification indicating that a battle event has been received to the game server 100 in response to an operation for receiving a battle event application.
In addition, the game application unit 202 of the terminal device 200 of the application user receives a battle event refusal notification indicating that the battle event has been accepted in response to an operation for permitting acceptance of the battle event application. Send to.

In the game server 100, the event control unit 104 determines whether or not the battle event application has been accepted by the user to be applied after transmitting the notification that the battle event application has been performed in step S201C (step S201D).
When receiving the battle event reception notification, the event control unit 104 determines that the battle event application has been received by the user to be applied (step S201D-YES). In this case, the event control unit 104 determines that a condition that allows the applying user to start a synchronous battle event with the user to be applied is satisfied (step S202).

  On the other hand, when the battle event rejection notification is received, the event control unit 104 determines that the battle event application has not been received by the user to be applied (step S201D-NO). In this case, the event control unit 104 determines that a condition that allows the applying user to start a synchronous battle event with the application user is not satisfied (step S203).

<Fourth Embodiment>
[Overview]
Subsequently, a fourth embodiment will be described.
In the fourth embodiment, after starting the asynchronous battle event, the event control unit 104 of the game server 100 starts from the state in which a predetermined condition for executing the synchronous battle event is not satisfied. Control is performed so as to switch to a synchronous event in accordance with a change to a state in which the above condition is satisfied.
Thereby, since the user who played with the asynchronous battle event can play with a synchronous battle event from the middle, it can respond to the user's desire to play with a synchronous battle event as much as possible.

[Example of processing procedure]
The flowchart of FIG. 10 shows an example of a processing procedure executed by the event control unit 104 for switching from an asynchronous battle event to a synchronous battle event.
After starting the asynchronous battle event on the terminal device 200 of the application user in step S108 of FIG. 6, the event control unit 104 can execute the synchronous battle event with the user to be applied by the terminal device 200 of the application user. It is determined whether or not the condition is satisfied (step S301). In addition, the event control unit 104 determines whether or not a determination result that the condition is satisfied is obtained by the condition determination in step S301 (step S302). Note that the condition determination in step S301 may be the same process as in step S103.

The start of the asynchronous battle event means that the condition is not satisfied in step S104 at the stage where the application user has applied for the battle event. After the asynchronous battle event is started, if the condition is not satisfied, the event control unit 104 determines that the determination result that the condition is satisfied is not obtained. (Step S302-NO), the condition determination is repeatedly executed by returning to Step S301.
Then, after the start of the asynchronous battle event, when the condition is not satisfied and the condition is satisfied, a determination result that the condition is satisfied is obtained (YES in step S302).
In this case, the event control unit 104 executes control to stop the asynchronous battle event that the asynchronous event execution unit 103 has executed on the application user terminal device 200 so far (step S303).
Next, the event control part 104 acquires the character information of the content when stopped by step S303 as the character information used in the asynchronous battle event that has been executed so far (step S304).
Next, the event control unit 104 delivers the character information acquired in step S304 to the synchronous event execution unit 102. In addition, the synchronous event execution unit 102 performs control so as to start a synchronous battle event between the application user terminal device 200 and the application user terminal device 200 (step S305). Thereby, it becomes possible to transfer to the synchronous battle event by taking over the character information in the asynchronous battle event previously performed.

<Fifth Embodiment>
[Overview]
Next, a fifth embodiment will be described.
In the fifth embodiment, the asynchronous event execution unit 103 is executed by the synchronous event execution unit 102 between the terminal device 200 of the application user (first user) and the terminal device 200 of the application user (other users). An operation input interface simpler than the operation input interface to be executed is executed on the terminal device 200 of the application user.
That is, the synchronous event execution unit 102 provides the terminal device 200 with a battle event of an advanced operation input interface capable of performing an advanced operation. On the other hand, the asynchronous event execution unit 103 provides the terminal device 200 with a battle event of a simple operation input interface that allows simple operation.

FIG. 11A shows an example of a game screen 400A displayed on the display unit 203 of the application user's terminal device 200 when a synchronous battle event is being executed.
For example, the game screen 400A is displayed by causing the game application unit 202 of the application user's terminal device 200 to execute the game control information generated by the synchronous event execution unit 102 in accordance with the advanced operation input interface program. It is realized by.
For example, a plurality of buttons BT are arranged on the game screen 400A shown in FIG. The application user can advance the battle event while performing advanced operations using these buttons BT.

  In addition, although illustration is abbreviate | omitted, the game screen which can perform operation equivalent to Fig.11 (a) is displayed also in the terminal device 200 of an application user. The game screen displayed on the terminal device 200 of the user to be applied is also the game control information generated by the synchronous event execution unit 102 according to the program of the advanced operation input interface. This is realized by causing the application unit 202 to execute.

FIG.11 (b) has shown the example of the game screen 400B displayed on the display part 203 of the application user's terminal device 200, when an asynchronous battle event is performed.
The display of the game screen 400B is realized, for example, when the asynchronous event execution unit 103 causes the game application unit 202 of the terminal device 200 of the application user to execute a program for a simple operation input interface.

  In the game screen 400B shown in FIG. 11B, a smaller number of buttons BT are arranged than in the game screen 400A in FIG. That is, the operation input interface of the game screen 400B is simpler than the game screen 400A.

[Example of information content corresponding to the fifth embodiment]
FIG. 12 shows an example of information stored in the storage unit 105 corresponding to the fifth embodiment. In the storage unit 105 in this figure, in addition to the character information table 110 and the synchronous event registration table 120, an advanced operation input interface program 130 and a simplified operation input interface program 140 are shown.

The advanced operation input interface program 130 is a program for realizing an advanced operation input interface as shown as the game screen 400A in FIG.
The synchronous event execution unit 102 causes the game application unit 202 of the terminal device 200 to execute the advanced operation input interface program 130. Accordingly, the game screen 400A of FIG. 11A is displayed on the display unit 203 of the terminal device 200, and the user can perform an operation on the game screen 400A. At this time, the game application unit 202 displays the game screen 400 </ b> A on the display unit 203 using the advanced operation input interface correspondence information in the execution environment of the advanced operation input interface program 130. As a result, the user can operate with the advanced operation input interface.

The simplified operation input interface program 140 is a program for realizing a simple operation input interface as shown as the game screen 400B in FIG.
The asynchronous event execution unit 103 causes the game application unit 202 of the terminal device 200 to execute the simplified operation input interface program 140. Accordingly, the game screen 400B of FIG. 11B is displayed on the display unit 203 of the terminal device 200, and the user can perform an operation on the game screen 400B. At this time, the game application unit 202 displays on the game screen 400B display unit 203 using the simplified operation input interface correspondence information in the execution environment of the simplified operation input interface program 140. As a result, the user can operate with the simplified operation input interface.

  Also, the application unit 202 of the terminal device 200 corresponding to the fifth embodiment includes advanced operation input interface correspondence information 210 and simplified operation input interface correspondence information 220 as shown in FIG.

The advanced operation input interface correspondence information 210 is information that the application unit 202 of the terminal device 200 uses when executing the advanced operation input interface program 130.
The advanced operation input interface correspondence information 210 stores information corresponding to each button displayed on the game screen 400A. One record in the advanced operation input interface correspondence information 210 is information corresponding to one button, and includes a button ID storage area 211, a button display information storage area 212, and a process ID storage area 213.

The button ID storage area 211 is an area for storing a button ID for uniquely identifying the corresponding button BT among the buttons BT displayed on the game screen 400A.
The button display information storage area 212 stores button display information that is information related to the display of the corresponding button BT. The button display information storage area 212 includes, for example, image data as an object of the corresponding button BT, information on a display position on the game screen 400A, and the like. The application unit 202 displays the button BT on the game screen 400A using this button display information.
The corresponding process ID storage area 213 stores a process ID that uniquely identifies a process to be executed by the application unit 202 when an operation is performed on the corresponding button BT.

The simplified operation input interface correspondence information 220 is information used by the application unit 202 of the terminal device 200 when the application unit 202 executes the simplified operation input interface program 140.
The simplified operation input interface correspondence information 220 stores information corresponding to each button displayed on the game screen 400B. One record in the simplified operation input interface correspondence information 220 is information corresponding to one button, and includes a button ID storage area 221, a button display information storage area 222, and a process ID storage area 223. The definition contents of the button ID storage area 221, the button display information storage area 222, and the process ID storage area 223 are the button ID storage area 211, the button display information storage area 212, and the advanced operation input interface correspondence information 210, respectively. Since it is based on the process ID storage area 213, a description thereof is omitted here.

In the case of an asynchronous battle event, the application user's character is NPC. Some users think that the same advanced operation as in the case of a synchronous battle event is rather troublesome to play against an NPC.
Therefore, by using a simple operation input interface for the asynchronous battle event as in the fifth embodiment, the application user plays the battle event with a simple operation when the opponent is an asynchronous battle event of NPC. be able to.

  In addition, by using a simple operation input interface in an asynchronous battle event, traffic between the terminal device 200 executing the asynchronous battle event and the game server 100 can be suppressed. Thereby, the communication load of the game server 100 is reduced, and it can be expected that the communication quality of the communication executed by the game server 100 for, for example, a synchronous battle event is maintained in a good state.

  In the fifth embodiment, for example, when starting an asynchronous battle event, the application user can use an advanced operation input interface as shown in FIG. 11A and a simplified type as shown in FIG. Any one of the operation input interfaces may be selected.

<Sixth Embodiment>
Next, a sixth embodiment will be described.
In the sixth embodiment, the asynchronous event execution unit 103 uses the application user (third user) character information and the same user (first user) used in the synchronous battle event being executed. The asynchronous event is started using the character information.
That is, in the first embodiment, when starting an asynchronous battle event, the character information of the user to be applied that is not used in the synchronous battle event being executed at that time is used for the asynchronous battle event. . That is, in the first embodiment, the character information of the user to be applied used in the synchronous battle event being executed is not used in the asynchronous battle event.

  On the other hand, in the sixth embodiment, the character information of the user to be applied used in the synchronous battle event being executed is also used in the asynchronous battle event. Thereby, for example, even if the application user has only one character, this application user and two or more application users can perform a battle event without any problem.

  However, when common character information is used in the synchronous battle event and the asynchronous battle event as described above, it is necessary to manage the character information so that the result of each battle event is appropriately reflected.

Therefore, in the sixth embodiment, the character information of the user to be applied is managed as follows.
The synchronous event execution unit 102 reads the character information of the user to be applied from the character information storage area 112 of the character information table 110 stored in the storage unit 105 at the timing when the synchronous battle event is started, and temporarily stores the character information. Generate and hold this. The temporarily stored character information is character information that the synchronous event execution unit 102 temporarily holds as working data. That is, the synchronous event execution unit 102 executes character information change corresponding to the progress of the battle during the synchronous battle event for the temporarily stored character information. Then, the synchronous event execution unit 102 executes a process of updating the character information in the character information storage area 112 based on the temporarily stored character information in response to the end of the synchronous battle event.

  Similarly, the asynchronous event execution unit 103 reads out the character information of the user to be applied from the storage unit 105 at the timing when the asynchronous battle event is started, generates temporary storage character information, and holds this. The asynchronous event execution unit 103 changes the character information corresponding to the progress of the battle during the asynchronous battle event on the temporarily stored character information. Then, in response to the end of the asynchronous battle event, a process of updating the character information in the character information storage area is executed based on the temporarily stored character information.

  That is, the synchronous event execution unit 102 compares the character information of the user to be applied read from the storage unit 105 at the timing when the synchronous battle event is started and the character information of the user to be applied at the timing when the synchronous battle event is ended. Generate the difference. Then, based on the obtained difference, the synchronous event execution unit 102 updates the character information of the user to be applied stored in the storage unit 105 at the timing when the synchronous battle event ends.

  In addition, the asynchronous event execution unit 103 compares the character information of the user to be applied read from the storage unit 105 at the timing when the asynchronous battle event is started and the character information of the user to be applied at the timing when the asynchronous battle event is ended. Find the difference. And the asynchronous event execution part 103 updates the character information of the application user memorize | stored in the memory | storage part 105 in the timing which this asynchronous event ended based on the calculated | required difference.

  As a result, even if the same user's character is used in the synchronous battle event and the asynchronous battle event, the character information changed according to the respective results of the synchronous battle event and the asynchronous battle event. Content is integrated. Then, by reflecting this integrated content in the character information stored in the storage unit 105, the character information can be managed appropriately.

  FIG. 14 shows a specific example of the application user character information update executed by the synchronous event execution unit 102 and the asynchronous event execution unit 103 in the sixth embodiment. In this figure, for the sake of simplicity of illustration and explanation, the hit points stored in the hit point storage area 112c and the experience value storage area 112f among the information stored in the character information storage area 112 are stored. Only experience values are shown. In the description of the drawing, the hit point storage area 112c and the experience value storage area 112f are described as character information 112A (112A-1 to 112A-7).

First, at time t1, the synchronous event execution unit 102 starts a synchronous event. In response to the start of the synchronous battle event, the synchronous event execution unit 102 reads character information corresponding to the application user from the storage unit 105.
At this time, as shown as character information 112A-1, the value of the hit point stored in the storage unit 105 is “120”, and the value of the experience value is “100”. Therefore, as shown as the character information 112A-2, the value of the hit point read by the synchronous event execution unit 102 at time t1 is “120”, the value of the experience value is “100”, and is stored in the storage unit 105. It is the same as what I had.

  Then, after time t1, the synchronous event execution unit 102 executes a synchronous battle event. At this time, every time a battle is performed in the synchronous battle event, for example, the synchronous event execution unit 102 changes the value of each information in the character information according to the result of the battle.

  In addition, at time t2 when a certain time has elapsed from time t1, the asynchronous event execution unit 103 starts an asynchronous battle event. In response to the start of the asynchronous event execution unit 103, the asynchronous event execution unit 103 reads character information corresponding to the application user from the storage unit 105. From time t1 to time t2, the application user's character information stored in the storage unit 105 is not changed. Therefore, as shown as character information 112A-5, the value of the hit point read by the asynchronous event execution unit 103 at time t2 is “120”, and the value of the experience value is “100”.

  Then, after time t2, the asynchronous event execution unit 103 executes an asynchronous battle event. At this time, the asynchronous event execution unit 103 changes the value of each information in the character information, for example, every time a battle is performed in the asynchronous battle event, according to the result of the battle.

Then, at a time t3 when a certain time has elapsed from the time t2, the synchronous event execution unit 102 ends the synchronous battle event. At the timing when this synchronous battle event ends, as shown as character information 112A-3, the value of the hit point is changed from “120” to “80”, and the value of the experience value is changed from “100” to “110”. Has been changed.
In this case, the difference between the character information read from the storage unit 105 at the start timing of the synchronous battle event and the character information at the timing when the synchronous battle event ends is as follows. That is, the difference in hit points is “−40 (= 80−120)”, and the difference in experience values is “10 (= 110−100)”.

As described above, at the time t3 when the synchronous battle event ends, the synchronous event execution unit 102 updates the character information stored in the storage unit 105 as follows.
That is, since the hit point difference in this case is “−40”, the synchronous event execution unit 102 adds “−40” to the “120” hit point indicated in the character information 112A-1. As a result, “80” is obtained. The synchronous event execution unit 102 updates the hit points stored in the hit point storage area 112c as indicated by the character information 112A-4 based on the value “80” thus obtained.
In this case, since the difference between the experience values is “10”, the synchronous event execution unit 102 adds “10” to the hit point “100” shown as the character information 112A-1 to obtain “10”. 110 ". The synchronous event execution unit 102 updates the experience value stored in the experience value storage area 112f as indicated by the character information 112A-4 with the value of “100” thus obtained.

In addition, at time t4 when a certain time has elapsed from time t3, the asynchronous event execution unit 103 ends the asynchronous battle event. At the timing when this asynchronous battle event ends, the value of the hit point is changed from “120” to “90” and the value of the experience value is changed from “100” to “130” as shown as character information 112A-6. has been changed.
In this case, the difference between the hit points between the start timing of the synchronous battle event and the timing when the synchronous battle event ends is “−30”, and the difference between the experience values is “30”.

In this case, the asynchronous event execution unit 103 adds the difference “−30” to the “80” hit point in the character information 112A-4 stored in the storage unit 105 at the time t4. Find “50”. The asynchronous event execution unit 103 updates the hit points stored in the hit point storage area 112c as shown in the character information 112A-7 with the value of “50” thus obtained.
Also, the asynchronous event execution unit 103 obtains a value of “140” by adding “30” as a difference to the “110” hit point indicated in the character information 112A-4. The asynchronous event execution unit 103 updates the experience value stored in the experience value storage area 112f as shown in the character information 112A-7 by the value of “140” obtained in this way.

As understood from the description so far, the hit points and experience values of the user to be applied shown in FIG. 14G are the hit points and experience value changes due to the synchronous battle event, and hit points due to the asynchronous battle event. And changes in experience values.
In other words, in the sixth embodiment, a common character is used for the synchronous battle event and the asynchronous battle event, but the character information changed by each of the synchronous battle event and the asynchronous battle event is displayed. Can be integrated. And the character information of the memory | storage part 105 is updated so that this integrated result is shown. Thereby, even in an environment where the same character is used corresponding to the user to be applied for in the synchronous battle event and the asynchronous battle event, the character information can be managed appropriately.

In addition, in response to the start of the synchronous battle event or the asynchronous battle event, for example, the user terminal device 200 related to the application user may be notified that the application user has started the battle event. Good. This notification can be made for a user who is registered as having a friendship with the application user, for example. The friend who has received the notification can also apply for a battle event as an application user in order to support the application user.
Further, this notification may be made to the application user when, for example, the application user does not activate the game application on the terminal device 200 and the asynchronous battle event is started.

  Moreover, although the example in the case where a synchronous type event and an asynchronous type event are battle events was shown in the above description, the synchronous type event and the asynchronous type event may be other than the battle event. As an example, avatars between users may communicate with each other.

  Further, for example, the terminal device 200 is provided with functional units corresponding to the synchronous event execution unit 102, the asynchronous event execution unit 103, and the event control unit 104. In addition, for example, the terminal device 200 that has received the battle event application may be configured to control the synchronous event and the asynchronous event. In such a configuration, for example, a synchronous event based on P2P can be executed between the terminal devices 200.

  In the description so far, the terminal device 200 is a wireless terminal device such as a mobile phone or a smartphone. That is, the game in the embodiment involves wireless communication. The present invention is effective in the case of wireless communication, but can also be applied to an environment in which the game server 100 and the terminal device 200 communicate with each other by wire, for example.

  3 is recorded on a computer-readable recording medium, and the program recorded on the recording medium is read into the computer system and executed, thereby executing the synchronization with the synchronous event. Control related to type events may be performed. Here, the “computer system” includes an OS and hardware such as peripheral devices.

Further, the “computer system” includes a homepage providing environment (or display environment) if a WWW system is used.
The “computer-readable recording medium” refers to a storage device such as a flexible medium, a magneto-optical disk, a portable medium such as a ROM and a CD-ROM, and a hard disk incorporated in a computer system. Further, the “computer-readable recording medium” refers to a volatile memory (RAM) in a computer system that becomes a server or a client when a program is transmitted via a network such as the Internet or a communication line such as a telephone line. In addition, those holding programs for a certain period of time are also included. The program may be a program for realizing a part of the functions described above, and may be a program capable of realizing the functions described above in combination with a program already recorded in a computer system.

  The embodiment of the present invention has been described in detail with reference to the drawings. However, the specific configuration is not limited to this embodiment, and includes designs and the like that do not depart from the gist of the present invention.

DESCRIPTION OF SYMBOLS 100 Game server 101 Communication part 102 Synchronous event execution part 103 Asynchronous event execution part 104 Event control part 105 Memory | storage part 110 Character information table 120 Advanced operation input interface program 130 Simplified operation input interface program 200 Terminal apparatus 201 Communication part 202 Game application unit 203 Display unit 204 Operation unit 300 Network 500 Game server

Claims (8)

A communication unit that communicates with the terminal device;
The result of controlling the character of the first user and the character of the other user according to the operation performed on the terminal device of the first user and the operation performed on the terminal device of the other user, The event executed on the terminal device of the first user and the terminal device of the other user are executed by the communication with the terminal device of the first user and the communication with the terminal device of the other user. A synchronous event execution unit that executes a synchronous event to be reflected in common with the event,
The character of the first user and the character of the other user according to automatic processing that is an alternative to the operation performed on the terminal device of the first user and the operation performed on the terminal device of another user An asynchronous event execution unit that executes an asynchronous event to reflect the result of controlling the event executed on the terminal device of the other user via communication with the terminal device of the other user;
When the synchronous event is being executed between the terminal device of the first user and the terminal device of the second user of the other users, the terminal of the third user of the other users is further executed In the event of starting an event between a device and the terminal device of the first user, if a predetermined condition is satisfied, the terminal device of the first user and the terminal device of the third user A game control comprising: an event control unit that starts a synchronous event and starts the asynchronous event with the other user terminal device as the third user terminal device when a predetermined condition is not satisfied apparatus. The event control unit
The game according to claim 1, wherein after the asynchronous event is started, the event is switched to the synchronous event in accordance with a change from a state where the predetermined condition is not satisfied to a state where the predetermined condition is satisfied. Control device. The asynchronous event execution unit
2. The operation input interface that is simpler than the operation input interface that the synchronous event execution unit executes in the terminal device of the first user and the terminal device of another user is executed in the terminal device of another user. 3. The game control device according to 2. The asynchronous event execution unit
Using the third user's character information and the same first user's character information as used in the ongoing synchronous event to initiate an asynchronous event;
The synchronous event execution unit is based on a difference between character information of the first user read from the storage unit at a timing when the synchronous event is started and character information of the first user at a timing when the synchronous event is completed. Updating the character information of the first user stored in the storage unit at the timing when the synchronous event ends,
The asynchronous event execution unit is based on a difference between the character information of the first user read from the storage unit at the timing when the asynchronous event is started and the character information of the first user at the timing when the asynchronous event is completed. The game control device according to any one of claims 1 to 3, wherein the character information of the first user stored in the storage unit is updated at a timing when the asynchronous event ends. The event control unit
When the condition that the communication quality with the terminal device of the first user by the communication unit is a certain level or more is satisfied, the communication between the terminal device of the first user and the terminal device of the third user is performed. A synchronous event is executed, and when the condition is not satisfied because the communication quality is less than a certain level, the asynchronous event is executed with the terminal device of the other user as the terminal device of the third user. The game control device according to any one of 1 to 4. The event control unit
The terminal device of the first user and the terminal of the third user when the condition that the number of the terminal devices of the second user when the synchronous event is being executed is equal to or less than a certain value is satisfied. When the synchronous event for the device is executed and the condition is not satisfied because the number of the terminal devices of the second user is greater than a certain value, the terminal device of the other user is changed to the terminal of the third user. The game control device according to claim 1, wherein the asynchronous event as a device is executed. The event control unit
The event application transmitted from the terminal device of the third user in order to apply for an event with the first user is transmitted to the terminal device of the first user, and the operation for accepting the event application is performed. Receive event acceptance notification sent from one user's terminal device,
When the condition that the event reception notification is received is satisfied, the synchronous event for the first user terminal device and the third user terminal device is executed, and the event reception notification is performed. 5. When the condition is not satisfied due to not being received, the asynchronous event is executed with the terminal device of the other user as the terminal device of the third user. 6. Game control device. A communication unit for communicating with the terminal device;
The result of controlling the character of the first user and the character of the other user according to the operation performed on the terminal device of the first user and the operation performed on the terminal device of the other user, The event executed on the terminal device of the first user and the terminal device of the other user are executed by the communication with the terminal device of the first user and the communication with the terminal device of the other user. A synchronous event execution unit that executes a synchronous event to be reflected in common with the event,
The character of the first user and the character of the other user according to automatic processing that is an alternative to the operation performed on the terminal device of the first user and the operation performed on the terminal device of another user An asynchronous event execution unit that executes an asynchronous event for reflecting the result of controlling the event to an event executed on the terminal device of the other user via communication with the terminal device of the other user. A game system control method comprising:
When the synchronous event is being executed between the terminal device of the first user and the terminal device of the second user of the other users, the terminal of the third user of the other users is further executed In the event of starting an event between a device and the terminal device of the first user, if a predetermined condition is satisfied, the terminal device of the first user and the terminal device of the third user A game system comprising an event control step of starting a synchronous event and starting the asynchronous event using the other user terminal device as the third user terminal device when a predetermined condition is not satisfied. Control method.

Images