JP5719470B1 - GAME MANAGEMENT PROGRAM, GAME MANAGEMENT METHOD, AND GAME MANAGEMENT SYSTEM - Google Patents

Abstract

A game management program, a game management method, and a game management system for playing a game synchronously on a plurality of computer terminals having different communication states are provided. A user terminal continuously measures a latency and transmits the latency to a management server. The control unit 21 of the management server 20 acquires and records the latency. In the game start process, the control unit 21 specifies a maximum latency value, determines an offset larger than the maximum value, and notifies each user terminal 10 of the offset. And the control part 21 of the management server 20 starts a game. Further, the user terminal 10 that has received the offset starts the game when the start time has elapsed. Further, the control unit 21 of the management server 20 that has acquired the operation request based on the operation on the user terminal 10 determines the designation step based on the latency, and notifies the user terminal 10 of it. [Selection] Figure 1

Description

The present invention relates to a game management program, a game management method, and a game management system for allowing a plurality of computer terminals with different communication states to progress and play a game while preventing troubles .

  Today, application software such as various online games is provided to users who use computer terminals such as smartphones. By connecting such a computer terminal to another computer terminal via a network such as the Internet, it is possible to enjoy a game battle with players who are separated from each other.

  However, communication delay may occur between a plurality of computer terminals connected via a communication network. Thus, a data processing method in which data is processed almost simultaneously between computer terminals has been studied (for example, see Patent Document 1). The server device described in this document obtains a delay time between computer terminals before starting a game when a computer game is played via a network having a communication delay. Based on this delay time, the time counted by each computer terminal is synchronized. While the game is in progress, the operation data signal is processed after the longest delay time has elapsed among the delay times between the computer terminals measured in advance from the occurrence. As a result, the operation data signal is simultaneously processed in a plurality of computer terminals.

JP 2007-260410 A (first page, FIG. 1)

However, the communication status of the client terminal may change during the game. In this case, it can interfere with the game progress.
The present invention has been made in view of the above-described problems, and an object of the present invention is to provide a game management program, a game management method, and a game management system for causing a game to proceed while preventing troubles in a plurality of computer terminals having different communication states. Is to provide.

(1) A game management system that solves the above-described problems includes a control unit that is connected to a plurality of user terminals, manages game progress, and a storage unit that records a delay time in the user terminals. Then, by the game management program, the control unit continuously acquires the delay time in each user terminal that plays a game in a group and records it in the storage unit, and delays the game progress in the game management system . In order to suppress the influence of the user terminal having a large size, the latest delay time acquired from the user terminal and recorded in the storage unit is compared with the first threshold value for determining the client abnormality, It functions as means for executing a request from the user terminal on condition that the delay time is within the first threshold.
Thereby, even if a communication condition with a user terminal changes, a trouble can be suppressed and a game can be advanced .

  (2) The game management system further stores a threshold value for determining whether or not the request can be executed, corresponding to the game type. And it is preferable to make the said control part function as a means to determine a said 1st threshold value further based on the game classification which plays a game with a game management program. Accordingly, it is possible to respond to the request in consideration of the synchronization status (synchronization strictness) according to the game type.

  (3) In the game management program, the control unit further functions as means for calculating a dispersion state of delay times recorded in the storage unit and determining the first threshold value based on the dispersion state. It is preferable to make it. Thereby, it is possible to efficiently advance the game according to the dispersion state of the delay time.

  (4) In the game management program, the control unit may further function as means for calculating the number of game participants who play a game in a group and determining the first threshold based on the number of game participants. preferable. Thereby, a game progress can be aimed at efficiently according to the number of game participants.

  (5) In the game management program, the control unit further acquires a delay time from a client who wants to participate in the game, records the delay time in the storage unit, and based on the latest delay time recorded in the storage unit Thus, it is preferable to function as a means for determining a group that plays the same game. Thereby, the dispersion | variation in delay time can be suppressed and a game progress can be efficiently synchronized.

According to the present invention, a plurality of computer terminals with different communication states can suppress the trouble and allow the game to proceed .

The system schematic of this embodiment. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of this embodiment. The timing chart of this embodiment. The timing chart of this embodiment. Explanatory drawing of the process sequence of other embodiment. Explanatory drawing of the process sequence of other embodiment. Explanatory drawing of the process sequence of other embodiment.

  Hereinafter, an embodiment of the game management method will be described with reference to FIGS. This embodiment assumes the case where the game content (role play game) which advances synchronously with respect to a some user terminal (client) is provided. This game progress is managed by the number of steps incremented (increased) over time.

As shown in FIG. 1, in this embodiment, a plurality of user terminals 10 and a management server 20 (game management system) connected via a network such as the Internet are used.
The user terminal 10 is a computer terminal (information processing terminal such as a smartphone) used by a user who plays a game. The user terminal 10 includes a communication unit, an input unit, and an output unit (such as a touch panel display). Furthermore, the user terminal 10 includes a control unit (a delay processing unit 11 and a game processing unit 12) including a CPU, a RAM, a ROM, and the like.

  The delay processing unit 11 continuously measures the latency (delay time from requesting data transfer or the like until the result is returned) for the connection state with the management server 20, and transmits it to the management server 20. . In this embodiment, it is assumed that periodic measurement is performed as continuous measurement, but “irregular” or “continuous” can be used as the measurement time interval. Further, the game processing unit 12 holds data relating to latency transmitted to the management server 20.

  The game processing unit 12 functions by an application for playing a game and manages the progress of the game. In addition, the game processing unit 12 transmits a request by a user operation to the management server 20 or executes an event based on an instruction acquired from the management server 20.

The management server 20 is a server computer that provides various game contents to each user terminal 10.
The management server 20 includes a control unit 21 including a CPU, a RAM, a ROM, and the like, a user information storage unit 22, a connection status storage unit 23, and a game information storage unit 24. The control unit 21 functions as a user management unit 211, a delay management unit 212, a game management unit 213, and a progress management unit 214 by executing a management program.

The user management unit 211 executes processing for managing users who use the game.
The delay management unit 212 executes processing for managing the connection status with each user terminal 10. Specifically, latency information is acquired from each user terminal 10 and the connection state is determined. Furthermore, the delay management unit 212 holds data relating to a threshold value for determining the user terminal 10 (client abnormality) having a large latency and an obstacle to the progress of the game.

  The game management unit 213 executes processing for managing game progress in each user terminal 10. In the present embodiment, the game management unit 213 performs a game start for each user terminal 10, acquisition of a request at the user terminal 10, notification of an event that has occurred in the game progress, and the like. Here, the progress of the game is managed based on the elapsed time (number of steps) from the start of the game. Specifically, the game progress of the user terminal 10 and the management server 20 of each client is synchronized based on the number of steps. Moreover, the game management part 213 respond | corresponds as an improper act, when the request inconsistent with the game progress in the management server 20 is acquired from the user terminal 10. FIG.

  The progress management unit 214 executes processing for managing game progress in the management server 20. The progress management unit 214 synchronizes the game progress in the management server 20 and the game progress in each user terminal 10.

  The user information storage unit 22 stores user information regarding users who use the game. This user information is recorded when a user is registered. The user information includes data related to the client ID and attributes.

In the client ID data area, data relating to an identifier for specifying each user is recorded.
In the attribute data area, data relating to the attribute of the user is recorded. This attribute includes, for example, information about the group and skill to which the user belongs, and the items owned by the user.

  In the connection status storage unit 23, connection management information for managing the connection status with the user terminal 10 is recorded. This connection management information is registered when the user terminal 10 is connected to the management server 20. The connection management information includes data relating to the group ID, client ID, latency, and status.

In the group ID area, data relating to an identifier for specifying a group playing a game synchronously is recorded.
In the client ID data area, data relating to an identifier for specifying each user terminal 10 (client) playing a game in this group is recorded.

In the latency data area, data related to the connection status (here, latency) with each client (user terminal 10) is recorded.
Information for determining the validity of the request acquired from each client is recorded in the status data area. In the present embodiment, an abnormal flag is recorded in this data area for a client having a latency greater than the threshold value. A request from the user terminal 10 of the client in which the abnormality flag is recorded is invalidated.

  In the game information storage unit 24, game management information related to the progress of the game is recorded. This game management information is registered when a game is played, and is updated during the game. The game management information includes data relating to the group ID, client ID, game used, and progress.

In the group ID area, data relating to an identifier for specifying a group to which each user belongs is recorded.
In the client ID data area, data relating to an identifier for specifying each user terminal 10 playing a game in this group is recorded.

In the use game data area, data relating to an identifier for specifying a game used by this group is recorded.
In the progress data area, data related to the progress of the game is recorded. In the present embodiment, an event (for example, an operation such as object placement) in each client is recorded for the number of steps in which the progress of the game is counted.

Hereinafter, a game management method when the user terminals 10 of the clients A to C play a game as one group using the above system will be described.
(Latency management processing)
First, the latency management process will be described with reference to FIGS. In the latency management process, the latency of each client is managed from the start to the end of the game.

  First, the user terminal 10 periodically performs a latency measurement process (step S1-1). Specifically, the delay processing unit 11 of the user terminal 10 periodically transmits Ping to the management server 20. The management server 20 that has received the Ping returns a response to the Ping. Then, the delay processing unit 11 measures network latency (delay time) based on the required time from Ping transmission to reply. Then, the delay processing unit 11 measures and holds the latency. In FIG. 5, clients A to C transmit Ping for measuring latency at times t11 to t13, respectively.

  Next, the user terminal 10 performs a latency transmission process (step S1-2). Specifically, the delay processing unit 11 of the user terminal 10 transmits latency information to the management server 20. The latency information includes information for identifying the user terminal 10 and information on the latency measured at the user terminal 10. In FIG. 5, clients A to C transmit latency information at times t21 to t23, respectively. Then, the user terminal 10 repeats the processing after the latency measurement processing (step S1-1) at the next measurement timing.

  Next, the control unit 21 of the management server 20 executes a latency acquisition process (step S2-1). Specifically, the delay management unit 212 of the control unit 21 acquires latency information transmitted by the user terminal 10.

  Next, the control unit 21 of the management server 20 executes a latency recording process (step S2-2). Specifically, the delay management unit 212 of the control unit 21 records the latency in the connection status storage unit 23 in association with the client ID of the user terminal 10. When the latency is acquired for the first time, the delay management unit 212 generates connection status management information in which the latency is recorded in association with the group ID and the client ID, and registers the connection status management information in the connection status storage unit 23. On the other hand, when the connection status management information for the user terminal 10 is already registered in the connection status storage unit 23, the delay management unit 212 updates and records the latest latency in the connection status management information.

  Next, the control part 21 of the management server 20 performs the determination process about whether it is a client abnormality (step S2-3). Specifically, the delay management unit 212 of the control unit 21 compares the latency acquired from the user terminal 10 with a threshold value. If the latency is greater than the threshold, it is determined that the client is abnormal.

If it is determined that the client is not abnormal (in the case of “NO” in step S2-3), the control unit 21 of the management server 20 ends the latency management process.
On the other hand, when it is determined that the client is abnormal (“YES” in step S2-3), the control unit 21 of the management server 20 executes a request invalidation process (step S2-4). Specifically, the delay management unit 212 of the control unit 21 records an abnormality flag as the status in the connection status management information of the connection status storage unit 23, and ends the latency management process. While the game is in progress, the game management unit 213 ignores the request from the user terminal 10 in which the abnormality flag is recorded.

(Process at game start)
Next, the game start process will be described with reference to FIGS. This process is executed when a game start request is received from the user terminal 10 (at the start of the game).

  Here, first, the control unit 21 of the management server 20 executes processing for specifying the maximum latency value (step S3-1). Specifically, the game management unit 213 of the control unit 21 acquires connection status management information in which the same group ID is recorded from the connection status storage unit 23, and specifies the latency of the user terminals 10 belonging to the same group. . In this case, the latency in which the abnormality flag is recorded is ignored. Then, the game management unit 213 identifies the maximum value among the identified latencies. In the present embodiment, it is assumed that the latencies of the clients A to C are “50 ms”, “30 ms”, and “200 ms”, respectively. In this case, the maximum latency value is “200 ms”.

  Next, the control unit 21 of the management server 20 executes an offset determination process that is larger than the maximum value (step S3-2). Specifically, the game management unit 213 of the control unit 21 specifies an offset (latency time) that is larger than the maximum latency value. Here, a value obtained by multiplying the maximum value by a predetermined value (for example, 1.5) is determined as the offset. Specifically, “300 ms (= 200 * 1.5)” is calculated as an offset with respect to the maximum value (200 ms). Note that the calculation of the offset is not limited to the above-described constant multiple as long as it is a calculation method previously stored in the game management unit 213.

  Next, the control unit 21 of the management server 20 executes an offset notification process (step S3-3). Specifically, the game management unit 213 of the control unit 21 transmits start time information to the user terminal 10. This start time information includes information on the determined offset.

  Next, the control part 21 of the management server 20 performs a game start process (step S3-4). Specifically, the progress management unit 214 of the control unit 21 starts a game in the management server 20 after the offset has elapsed. In FIG. 5, the game is started at time t40 after the offset has elapsed. Then, the progress management unit 214 advances the game by incrementing the number of steps every predetermined time.

  On the other hand, the user terminal 10 that has received the offset executes a start standby process (step S4-1). Specifically, the game processing unit 12 of the user terminal 10 calculates the game start time by subtracting the latency held by the delay processing unit 11 from the offset acquired from the management server 20. For example, in the clients A to C, 250 ms [= 300-50], 270 ms [= 300-30], and 100 ms [= 300-200] are the start times, respectively. Then, the game processing unit 12 waits for this start time.

  And when start time passes, the user terminal 10 performs a game start process (step S4-2). Specifically, the game processing unit 12 of the user terminal 10 starts a game. In FIG. 5, at time t40 after the offset has elapsed, the clients A to C start the game. And the game process part 12 of each user terminal 10 advances a game by incrementing a step number for every fixed time.

(Request handling process)
Next, the request handling process will be described with reference to FIG. Here, it is assumed that a request is acquired from the user terminal 10 of the client A.

  First, the user terminal 10 executes an operation request process (step S5-1). Specifically, the game processing unit 12 of the user terminal 10 specifies an event based on an operation by the user. Here, the arrangement of an object is assumed as an event. In this case, the game processing unit 12 of the client A calculates the number of steps in consideration of the latency in the client A. Here, the value (server step number) obtained by adding the value obtained by dividing the latency by the step unit time to the step number (local step number) at the time of operation in the client A is calculated. Then, the game processing unit 12 transmits an object arrangement request to the management server 20. This request includes data relating to the type of object, the position of arrangement, and the number of server steps. In FIG. 6, the client A transmits a request for object placement at time t51.

  Next, the user terminal 10 performs a time difference disguise process up to the event (step S5-2). Specifically, the game processing unit 12 of the user terminal 10 outputs an animation or the like indicating that an event is being prepared (object preparation is being prepared).

  The control unit 21 of the management server 20 that acquired the request executes an operation detection process (step S6-1). Specifically, the game management unit 213 of the control unit 21 acquires a request for an operation (arrangement of objects) from the user terminal 10 of the client A.

  Next, the control unit 21 of the management server 20 executes processing for specifying the maximum latency value (step S6-2). Specifically, the game management unit 213 of the control unit 21 acquires the connection status management information in which the same group ID is recorded in the connection status storage unit 23, and specifies the maximum value of the latency.

  Next, the control unit 21 of the management server 20 executes a designation step determination process based on the latency (step S6-3). Specifically, the game management unit 213 of the control unit 21 calculates an event execution time obtained by adding a margin to the maximum latency value. Then, the game management unit 213 divides the event execution time by the step unit time, and calculates the number of steps for arranging the objects.

  Next, the control unit 21 of the management server 20 executes a notification process of a designation step (step S6-4). Specifically, the game management unit 213 of the control unit 21 sends an event notification to the user terminals 10 of the clients A to C. This event notification includes data on the event content (arrangement of objects in the client A) and the specified number of steps. In FIG. 6, the management server 20 notifies an event implementation designation step at time t60.

  Next, the control unit 21 of the management server 20 executes an event standby process (step S6-5). Specifically, the progress management unit 214 of the control unit 21 waits for an event until a designated step is reached.

  Next, the control part 21 of the management server 20 performs an event implementation process (step S6-6). Specifically, the progress management unit 214 of the control unit 21 records an event (arrangement of objects) in the game information storage unit 24 during the game progress of the management server 20 in the designation step. In FIG. 6, the progress management unit 214 performs object placement at time t70.

  The user terminal 10 that has received the event notification executes an event standby process (step S5-3). Specifically, the game processing unit 12 of the user terminal 10 waits for an event until the designation step is performed from the management server 20.

  Next, the user terminal 10 executes an event execution process (step S5-4). Specifically, when the designation step arrives, the game processing unit 12 of the user terminal 10 ends the disguise and performs object placement.

  Also, in the user terminals 10 of the client B and the client C, the event standby process (step S7-1) and the event execution process (step S7-2) are executed as in steps S5-3 and S5-4. In FIG. 6, at time t70, the clients A to C perform object arrangement.

According to the above embodiment, the following effects can be obtained.
(1) In the embodiment described above, the user terminal 10 executes the latency measurement process (step S1-1) and the latency transmission process (step S1-2). The control unit 21 of the management server 20 executes a latency acquisition process (step S2-1) and a latency recording process (step S2-2). Thereby, in the management server 20, the delay condition in each client can be grasped. In particular, since this process is periodically executed, it is possible to cope with a change in the communication status between the server and the client.

  (2) In the embodiment described above, the progress management unit 214 executes processing for managing game progress in the management server 20. The progress management unit 214 synchronizes the game progress in the management server 20 and the game progress in each user terminal 10. Moreover, the game management part 213 respond | corresponds as an improper act, when the request inconsistent with the game progress in the management server 20 is acquired from the user terminal 10. FIG. Thereby, since the game progress is managed in the management server 20, the illegal act in each client can be monitored. Furthermore, even if a communication failure with the user terminal 10 occurs, the game can be continued when the failure is restored.

  (3) In the above embodiment, when it is determined that the client is abnormal (“YES” in step S2-3), the control unit 21 of the management server 20 executes a request invalidation process (step S2-4). Thereby, it is possible to suppress the influence of a client having a large delay in the progress of the game.

  (4) In the above embodiment, the control unit 21 of the management server 20 specifies the maximum latency value identification process (step S3-1), the offset determination process larger than the maximum value (step S3-2), and the offset notification process. (Step S3-3) is executed. Thereby, even a client with a large delay can start the game at the same time. Then, in the user terminal 10 and the management server 20 of each client, the game progress can be synchronized.

  (5) In the above embodiment, the user terminal 10 executes an operation request process (step S5-1). In this case, the game processing unit 12 of the user terminal 10 calculates the number of steps in consideration of the latency in the client A. Thereby, the number of steps in the game progress of the management server 20 can be specified and a request can be made.

  Further, the user terminal 10 performs a disguise process of the time difference until the event (step S5-2). As a result, it is possible to secure time from the operation (object placement operation) on the client to the event execution (object placement).

  (6) In the above embodiment, the control unit 21 of the management server 20 determines the maximum latency value (step S6-2), the designation step determination process based on the latency (step S6-3), and the designation step. A notification process (step S6-4) is executed. As a result, even when a group having a game includes a client with a large delay, an event can be executed at the same time.

In addition, you may change the said embodiment as follows.
In the above embodiment, the control unit 21 of the management server 20 executes the designation step determination process based on the latency (step S6-3). Here, when the latency is large, a request regarding an operation in a subsequent step in another user terminal 10 may arrive first on the management server 20. The designated step may be determined in consideration of this situation.

The request handling process in this case will be described with reference to FIG.
In this case, similarly to steps S6-1 and S6-2, the control unit 21 of the management server 20 executes an operation detection process (step S8-1) and a maximum latency specifying process (step S8-2). To do.

  Next, the control part 21 of the management server 20 performs the determination process about whether there exists inversion of the back-and-front step (step S8-3). Specifically, the game management unit 213 of the control unit 21 confirms whether there is a request for a subsequent step that has arrived first, based on the number of steps included in the request. When the number of steps included in the first arrival request is larger than the number of steps included in the later arrival request, it is determined that there is an inversion of the preceding and following steps.

  When it is determined that there is no reversal of the preceding and following steps (in the case of “NO” in step S8-3), the control unit 21 of the management server 20 performs the designation step determination process based on the latency, similarly to step S6-3. Execute (step S8-4).

  On the other hand, when it is determined that there is a reversal of the preceding and following steps (in the case of “YES” in step S8-3), the control unit 21 of the management server 20 executes a designation step determination process based on the first arrival request (step S8). -5). Specifically, the game management unit 213 of the control unit 21 designates a step after the designation step in the first arrival request. Here, the event execution time is calculated by adding a margin to the maximum latency value. Then, the game management unit 213 divides the event execution time by the step unit time, and calculates the number of steps for executing the event (object placement). Here, the game management unit 213 checks whether or not the calculated number of steps is larger than the designated step in the first-arrival request. If it is smaller than the designated step in the first-arrival request, the game management unit 213 specifies the number of steps obtained by adding the maximum number of latency and the number of steps corresponding to the margin to the designated step in the first-arrival request. .

  Next, the control part 21 of the management server 20 performs the notification process (step S8-6) of a designation | designated step-event implementation process (step S8-8) similarly to step S6-4-S6-6.

  As a result, even when a request for the number of subsequent steps arrives first due to a difference in latency, it is possible to cope with the arrival order of the requests. In the case of dealing with a late arrival request, if there is a problem in the progress of the game, the late arrival request can be ignored.

  In the above embodiment, connection management information for managing the connection status with the user terminal 10 is recorded. In the connection management information, data relating to the group ID, client ID, latency, and status is recorded. Then, the game start time and the designated step are determined using the maximum value of the latency of each client. The latency used for synchronization is not limited to the maximum value. For example, a latency history may be recorded for each client, and an average value of latency over a predetermined period may be used. In this case, synchronization is performed using the maximum average value.

  Also, a value that suppresses the fluctuation range to a certain value or less may be calculated. In this case, a value that statistically includes the latency is used based on the latency history. For example, a deviation value obtained by adding a standard deviation to the average latency value is used. Synchronization is performed using the maximum deviation value.

  In the above embodiment, the user terminal 10 executes a latency measurement process (Step S1-1). And the user terminal 10 performs a latency transmission process (step S1-2). Instead, the management server 20 may measure the latency. In this case, the delay management unit 212 of the control unit 21 transmits Ping to the user terminal 10 of each client, and measures latency. And the delay management part 212 transmits each latency with respect to the user terminal 10 of each client.

-In the said embodiment, a latency measurement process is performed by transmitting Ping regularly (step S1-1). The timing of latency measurement is not limited to this. Here, the latency measurement interval may be changed depending on the game type. In this case, the delay management unit 212 retains timing information that records the latency measurement interval corresponding to the game type. Then, the delay management unit 212 identifies a latency measurement interval corresponding to the game type to be used, and executes a latency measurement process using the latency measurement interval. Depending on the game type, the significance of synchronization in the game progression varies. For example, there are games that require strict synchronization and other games that require less synchronization. Therefore, it is possible to respond to the request in consideration of the synchronization situation (synchronization strictness) according to the game type.
Furthermore, the latency measurement interval may be changed according to the game screen. In this case, the latency measurement interval is recorded in association with the number of steps of the game progress.

  Further, the latency measurement interval may be changed according to the dispersion state of the latency. In this case, the latency history of the user terminals 10 belonging to the same group is specified in the delay management unit 212, and the latency distribution is calculated. When the latency change is small (when the change width is equal to or smaller than the reference value), the latency measurement interval is increased. On the other hand, when the latency change is large (when the change width exceeds the reference value), the latency measurement interval is reduced. Thereby, according to the dispersion | distribution state of latency, a game progress can be aimed at in consideration of the balance of the processing burden and accuracy of latency evaluation.

  Further, the latency measurement interval may be changed depending on the number of participants in the group. In this case, the delay management unit 212 retains timing information that records the latency measurement interval corresponding to the number of participants. Then, the delay management unit 212 identifies a latency measurement interval corresponding to the game type to be used, and executes a latency measurement process using the latency measurement interval. Thereby, a game progress can be aimed at efficiently according to the number of game participants.

In the above embodiment, when it is determined that the client is abnormal (in the case of “YES” in Step S2-3), the control unit 21 of the management server 20 executes a request invalidation process (Step S2-4). The threshold value for determining the client abnormality may be changeable. In this case, the threshold value may be changed depending on the game type. In this case, the game management unit 213 holds threshold information in which a threshold is recorded in association with the game type. And the game management part 213 specifies the threshold value corresponding to the game type to utilize, and performs a request invalidation process using this threshold value. Depending on the game type, the significance of synchronization in the game progress differs, but the request can be handled in consideration of the synchronization status (synchronization strictness) according to the game type.
Furthermore, the threshold value may be changed according to the game screen. In this case, a threshold value is recorded in association with the number of game progress steps.

  Further, the threshold value may be changed according to the latency distribution state. In this case, the latency history of the user terminals 10 belonging to the same group is specified in the game management unit 213, and the latency distribution is calculated. When the latency change is small (when the change width is equal to or smaller than the reference value), the threshold value is increased. On the other hand, when the latency change is large (when the change width exceeds the reference value), the threshold value is decreased. Thus, the progress of the game can be promoted by changing the allowable range of the latency in accordance with the latency distribution state.

  Further, the threshold value may be changed according to the number of game participants in the group. In this case, the game management unit 213 stores timing information in which a threshold is recorded in correspondence with the number of participants. And the game management part 213 specifies the threshold value corresponding to the game type to utilize, and performs a request invalidation process using this threshold value. In this case, when the number of participants in the game is large, the threshold value is increased to widen the allowable range. Thereby, a game progress can be aimed at efficiently according to the number of game participants.

  In the above embodiment, the user terminal 10 executes a game start process (step S4-2). Here, in the user terminal 10 of each client participating in the game, the game is started at the same time and the number of steps of the game progress is synchronized. Here, the number of steps may be synchronized during the progress of the game. In this case, the management server 20 executes midway adjustment processing. In this case, the game management unit 213 stores data related to a threshold value (number of delay steps) for determining whether synchronization is necessary.

The midway adjustment process will be described with reference to FIG.
Here, first, the user terminal 10 periodically performs a transmission process for the number of steps (step S9-1). Specifically, the game processing unit 12 of the user terminal 10 periodically transmits the current number of steps to the management server 20.

  In this case, the control unit 21 of the management server 20 executes a step number acquisition process (step S9-2). Specifically, the game management unit 213 of the control unit 21 periodically acquires the current number of steps from the user terminal 10 of each client.

  Next, the control unit 21 of the management server 20 executes a step number correction process based on the latency (step S9-3). Specifically, the game management unit 213 of the control unit 21 acquires the latency in the user terminal 10 that has acquired the current number of steps from the connection status storage unit 23. Next, the game management unit 213 calculates a value (delay step number) obtained by adding a value obtained by dividing the latency by the step unit time. Then, the game management unit 213 calculates the local step number obtained by adding the delay step number to the current step number.

  Next, the control part 21 of the management server 20 performs the determination process about whether a difference is more than a threshold value (step S9-4). Specifically, the game management unit 213 of the control unit 21 calculates the difference between the server step number when the current step number acquired from the user terminal 10 is acquired and the local step number. Then, the game management unit 213 compares the difference with a threshold value.

When it determines with a difference being smaller than a threshold value (in the case of "NO" in step S9-4), the control part 21 of the management server 20 complete | finishes a midway adjustment process.
On the other hand, when it is determined that the difference is equal to or greater than the threshold value (in the case of “YES” in step S9-4), the control unit 21 of the management server 20 executes a correction process for the current number of steps based on the latency (step S9-5). ). Specifically, the game management unit 213 of the control unit 21 calculates a correction step number obtained by adding the delay step number to the current server step number.

  Next, the control unit 21 of the management server 20 executes a synchronization instruction process (step S9-6). Specifically, the game management unit 213 of the control unit 21 transmits a synchronization instruction to the user terminal 10 that has acquired the number of steps. This synchronization instruction includes data relating to the number of correction steps.

  And the user terminal 10 which acquired the synchronous instruction | indication performs a synchronous process (step S9-7). Specifically, the game processing unit 12 of the user terminal 10 skips the game progress up to the number of correction steps acquired from the management server 20. Thereby, even when the game progress in the management server 20 and the game progress in a client have a gap, both can be synchronized.

  In the above embodiment, it is assumed that the user terminals 10 of the clients A to C play a game as one group. Here, a group may be generated in consideration of latency. Here, a grouping process is performed to form a group in which clients whose latency is within a predetermined range are grouped.

The grouping process will be described with reference to FIG.
Here, first, the control unit 21 of the management server 20 executes a latency acquisition process for the applicant who wants to participate (step S10-1). Specifically, the game management unit 213 of the control unit 21 acquires the latency of a client who wants to participate in the game from the user terminal 10.

  Next, the control unit 21 of the management server 20 executes group creation processing with a client having a close latency (step S10-2). Specifically, the game management unit 213 of the control unit 21 specifies a client whose acquired latency is included in a predetermined range. Then, the game management unit 213 registers the identified client in the game information storage unit 24 as a group.

Next, the control unit 21 of the management server 20 executes a game start process shown in FIG. 3 (step S10-3).
As a result, a game can be played by a client with a small difference in latency, so that the game progress can be easily synchronized.

  Here, group creation may be performed in consideration of user attributes (game skill, level, etc.). In this case, the control unit 21 of the management server 20 specifies a common user (group candidate) based on the attribute recorded in the user information storage unit 22. Then, the control unit 21 of the management server 20 executes grouping processing for the group candidate users, and creates a group with a client having a close latency.

  DESCRIPTION OF SYMBOLS 10 ... User terminal, 11 ... Delay processing part, 12 ... Game processing part, 20 ... Management server, 21 ... Control part, 211 ... User management part, 212 ... Delay management part, 213 ... Game management part, 214 ... Progress management part 22 ... User information storage unit, 23 ... Connection status storage unit, 24 ... Game information storage unit.

Claims (7)

A control unit connected to a plurality of user terminals and managing the progress of the game;
A game management system using a game management system including a storage unit for recording a delay time in the user terminal,
The control unit
The delay time in each user terminal that plays a game in a group is continuously acquired and recorded in the storage unit,
In order to suppress the influence of the user terminal having a large delay on the game progress in the game management system, the latest delay time acquired from the user terminal and recorded in the storage unit and the client abnormality are determined. Comparing with a first threshold for
A game management program that functions as means for executing a request from the user terminal on condition that the delay time is within the first threshold. The game management system stores a threshold value for determining whether or not to execute a request corresponding to the game type,
The game management program according to claim 1, further causing the control unit to function as means for determining the first threshold value based on a game type in which a game is played. The control unit further calculates a dispersion state of the delay time recorded in the storage unit,
The game management program according to claim 1, wherein the game management program is caused to function as means for determining the first threshold value based on the distribution state. The control unit further calculates the number of game participants who perform a game in a group,
The game management program according to any one of claims 1 to 3, wherein the game management program is caused to function as means for determining the first threshold based on the number of participants in the game. The control unit further acquires a delay time from a client who wants to participate in the game, records it in the storage unit,
The game management program according to any one of claims 1 to 4, wherein the game management program causes a group to determine a group to play the same game based on the latest delay time recorded in the storage unit. A control unit connected to a plurality of user terminals and managing the progress of the game;
A method for managing a game using a game management system including a storage unit for recording a delay time in the user terminal,
The control unit is
The delay time in each user terminal that plays a game in a group is continuously acquired and recorded in the storage unit,
In order to suppress the influence of the user terminal having a large delay on the game progress in the game management system, the latest delay time acquired from the user terminal and recorded in the storage unit and the client abnormality are determined. Comparing with a first threshold for
A game management method comprising: executing a request from the user terminal on condition that the delay time is within the first threshold value. A control unit connected to a plurality of user terminals and managing the progress of the game;
A game management system comprising a storage unit for recording a delay time in the user terminal,
The control unit is
The delay time in each user terminal that plays a game in a group is continuously acquired and recorded in the storage unit,
In order to suppress the influence of the user terminal having a large delay on the game progress in the game management system, the latest delay time acquired from the user terminal and recorded in the storage unit and the client abnormality are determined. Comparing with a first threshold for
A game management system, wherein a request from the user terminal is executed on condition that the delay time is within the first threshold.

Images