Network processing system and method of video game

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

Describes methods and systems for networking several video games together to form an interactive play multi-system game. The present invention includes a synchronization method referred to herein as a "State Sync. Method". The present invention also includes bandwidth management methods and systems for such networks.

【0002】

[Conventional technology]

Definition of terms The following terms, when used herein, shall have the following meanings.

【0003】

Game Units or Video Game Units-A piece of computing device that runs software used for entertainment purposes, including general purpose computers running video game machines or video game software. However, it is not limited to these.

【0004】

Games-Video game playing experience. Games can be played on a single single game unit or on two or more game units. Multi-system game-A game played on more than one video game unit.

【0005】

State Sync Method-A means of allowing players in a large number of game units to participate in a multiplayer, multisystem game. This method is defined in more detail below.

【0006】

Game State or State-The game state is the value of a parameter that controls the outcome of the game at a given point in time. Examples of game state parameters include the position of objects on and off the screen, character strength, character health, and wealth.

【0007】

State Value-For a given state state_n, the value of state_n defines all game parameters that affect the outcome of the game. State transitions-State transitions occur periodically. The new game state is a function of the current game state and the current input.

【0008】

State Sync-During game play, the game state is changing cyclically. State changes typically occur 30 to 60 times per second. In a large number of game units, if the game state sequences generated on each game unit are the same, it is said that the states are synchronized. State transitions do not have to occur at the same time. Also, not all game units need to stay in a given state for the same amount of time.

【0009】

The term group-group is used to mean a subset of game units that need to be connected together and maintain state synchronization. Game units within the group are said to be participating in multi-system games.

【0010】

System-Any single computer device. This term is used herein synonymously with game unit. Input-This term refers to any event caused by an influence outside the game or group that can affect state transitions or the outcome of the game. This includes, but is not limited to, pressing a button, moving a joystick, or acting other input devices.

【0011】

[Problems to be Solved by the Invention]

Two or more physically independent game units connected by either data communication network or any direct electrical connection are of some kind if players in different geographic locations participate in the same game. Requires a network management system or method. The present invention provides such a system or method.

【0012】

In general, video game programs are based on a series of state transitions. Typically, these transitions are typically made at periodic intervals related to the video frame rate for the game system. Some or all of the state transitions depend on the input value. Many game units that are connected over a network for multi-system games require some form synchronization method. The present invention provides such a method.

【0013】

[Means for solving problems]

According to one aspect of the present invention, there is provided a network processing method and system for a video game that allows two or more players in different positions to engage in a real-time interactive game.

【0014】

According to another aspect of the invention, a synchronization method that synchronizes two or more game units at different positions linked by a network so that the same game state sequence occurs on each game unit. I will provide a.

【0015】

According to yet another aspect of the invention, bandwidth management that monitors available network bandwidth, coordinates matches, and controls player access to network-level hierarchies based on predetermined player criteria. Provide systems and methods.

【0016】

The state synchronization method of the present invention ensures that each game unit maintains state synchronization with any other game unit within the group of networked video game units. This is achieved by ensuring that each game unit in the group operates on the same input stream as any other game unit in the group operates. The bandwidth management methods and systems of the present invention implement methods that regulate user access to available network bandwidth to match network capacity and user expectations.

【0017】

According to another aspect of the invention, the network processing system of the electronic game unit is coupled to one or more game units at each of the plurality of locations and further to the corresponding communication resource. An arcade router that supports two-way information exchange with the one or more game units, and the one or more game units that are combined with the first group of communication resources and at the plurality of positions. A first router that supports two-way information exchange and the first router are combined to control the two-way data exchange, and interactive play by a plurality of game units at different locations among the plurality of locations. It has a first server to support.

【0018】

According to another aspect of the present invention, information exchange between a plurality of game units linked to each other for interactive play is synchronized, and each of the game units is on substantially the same incoming information sequence. Provides a state synchronization system to work with.

【0019】

Yet another aspect of the invention provides a bandwidth manager for multiple game units that can be linked to a network for interactive play. This bandwidth manager provides a means to determine the bandwidth available on each communication resource of the network, a means to determine the player proficiency associated with each game unit requesting access to the network, and to the network. A means of determining the average skill level of all players requesting access to, a means of determining the recommended threshold based on the average skill level and available bandwidth, and if the player's skill level exceeds the recommended threshold. Includes means of granting access to the network to the player.

【0020】

According to yet another aspect of the invention, information exchange between a plurality of game units linked to each other for interactive play is synchronized, and each of the game units has a substantially the same incoming information sequence. Provides a state synchronization method to operate on. This state synchronization method includes means for determining the number of game units participating in the multi-system game, means for determining the input data of each of the game units in the first state, and the first state. Each of the game units transitions to the next state until the input data from each of the other game units in the multi-system game has been transmitted to each of the other games in the multi-system game. This includes means for all game units in the multi-system game to operate on the same set of input data in each state before transitioning to the next state.

【0021】

BEST MODE FOR CARRYING OUT THE INVENTION

1. System overview With reference to FIGS. 1 to 3, first, FIG. 1 shows an example of a video game network according to the present invention. An example of the network of the format shown in FIG. 1 will be referred to as WaveNet below. Figures 2 and 3 show two types of "prototype" systems that link video game units in different locations.

【0022】

With reference to FIG. 1, in the present invention, two or more game units 16 at different positions can be linked to play a real-time interactive game. These game units can also include one or more game units from each of multiple arcade 10 groups. Here, the arcades are indicated by arcades 1,1 to arcades 1, n and arcades n, 1 to arcades n, n. The arcades in Arcade Group 1 are each linked to the first, or Metro Hub 12, through one T-1 line. Here, Metro Hub 12 is shown as a San Francisco (SF) hub. Similarly, Group n's Arcade 10 is linked through a T-1 line to another first or metro hub, referred to here as the Los Angeles (LA) hub. Each arcade contains multiple game units 16, which are operationally coupled to the arcade router (R) 18. It is also possible to add additional arcade groups coupled to additional metro hubs without departing from the present invention.

【0023】

A large number of metro hubs 12, 14, etc. can be connected to the regional center 20 through a T-1 communication line. Similarly, one or more such regional centers 20 can be connected to a super-regional center 22 through one T-1 line, and one or more such regional centers 22 are T. -Can be connected to national center 24 through one line. Communication resources other than the T-1 line, such as preferably T-1 lines or higher capacity optical fibers or other broadband resources, can also be used without departing from the present invention.

【0024】

Each of the metro hubs 12 and centers 20, 22, 24 is similar in that it includes router (R) 30 and server (S) 32. The server 32 performs bandwidth management, as described in more detail below. Generally speaking, each of the servers 32 in the metro hubs 12, 14 will have these Ts between the metro hubs 12, 14 and the various arcades 10 linked to the hub through a T-1 line. -Monitor bandwidth usage on a single line. This will be referred to herein as downstream bandwidth management. In upstream bandwidth management, server 32 monitors bandwidth usage on the T-1 line between the associated router and the next highest level, as shown in Figure 1, and each T-1 line. Control access to the line. This is known as upstream bandwidth management.

【0025】

The array of routers and servers shown in FIG. 1 shows that the players of the individual game units 16 in any arcade can play other games in other game units in other locations, whether in the same arcade or in different arcades. -There is an advantage that it is possible to play against the player in real-time interactive play. These players may be in different arcades under the same metro hub, or may be in positions that are ultimately linked by territorial, super-territorial or national centers via intermediary centers or hubs. Good. The bandwidth management and state synchronization features of the present invention have the advantage of enabling real-time interactive games, which individual players perceive as substantially simultaneous play. To do this, make several players perceive, regardless of their position, essentially as if they were in the same position as the other players or directly adjacent to each other in the arcade. To do.

【0026】

Although the present invention will be described herein with reference to video game units in an arcade, it will be appreciated that the invention is similarly applicable to other types of game units. For example, using the network of the present invention, a home video game, a game played on a single unit through a game controller linked to a normal TV receiver, or a game played on a personal computer (PC). Even so, it is possible to link. Any of these game units can be linked to the network described above with reference to FIG. 1, provided that they have the appropriate hardware and software to perform network-aware processing.

【0027】

A brief reference to Figure 2 shows a type of prior art tournament system called the high score to date system, in which players do not compete interactively with each other. One of these types of systems is The Thacher et It is shown in US Pat. No. 5,083,271 of al. (Tatcher et al.). Here, all players competing in the tournament play their game individually and at the end send their score to the central server. Therefore, in this system, each individual game unit is linked via a modem 26 to the cooperating modem 28 of the central server 29. The central server 29 then receives individual scores from a number of game units 16, one at a time. The game units 16 are interconnected sequentially using the modem 28 in some preselected order, for example by polling the various game unit modems 26 by the server 29. While server 29 is poled for a given game unit 16, information is exchanged between the server and that game unit, and the player scores of other players who have previously participated in the tournament and competed for the game. To allow individual players to compare his score with other scores in games that have been completed so far. Therefore, such systems are usually given the name "highest score update".

【0028】

FIG. 3 shows yet another prior art system, where server 39 simplifies interconnection for interactive games only between two game units 16 each having a modem 26. To do. Server 39 can also include modems (not shown) that communicate with modems 26 of individual game units. The process is a three-step process, as shown by arrows 1, 2 and 3 in Figure 3. In the first step, two modems 26 from two game units 16 address the server simultaneously or sequentially and they are linked. Show the possibility of doing play). In the second step, the server indicates to the first player who made such a request that it is available to play with the second player and sends the second player's telephone number or email address. If interested in engaging with a second player, the first player contacts the second player by using his phone or email address, as shown in step 3, and directly between the two players. Start playing. Server 39 is not involved during the actual play between the two players and only simplifies the task of first finding the opponent's player.

【0029】

The systems shown in Figures 2 and 3 have many limitations. For example, the system in Figure 3 cannot be used to link three or more players for interactive play and can be used to simplify tournament play, as in the system in Figure 2. Can not. On the other hand, the highest score update tournament system shown in Fig. 2 cannot support real-time interactive play between various players, but simply compares the scores and conveys the obtained score information to each player. It just does. II. State sync When using the state synchronization method of the present invention, each system of the group must match the values of each game state as the game unit progresses from the initial state to the final state at the end of the game. The initial state is the state in which the game unit is placed when the multi-system game starts, and is indicated by state_1. The game unit acts on various inputs (eg, user button presses and joystick movements) during state_1 to advance to a new state state_2. Let's call the value of the arbitrary state state_n. Here, n indicates when the state occurs in a series of states constituting the game. The value of state_n is a function of the value of (state_n-1) in the previous state and the value of the input sampled before state_n.

【0030】

In the present invention, in any given state, each system in the group operates against the same input set in which each other system in the group operates in that given state. Includes methods that ensure that certain state transitions occur only if.

【0031】

To do this, each game unit in the group must send all the required input data to all game units in the group to ensure that the state transitions in each game are based on the same input data. ..

【0032】

For example, suppose system 1 samples the following inputs, I (1,1), I (1,2), I (1,3), I (1,4), I (1,5). I (n, m) is the mth sample of the input obtained by the nth system, system 2 is I (2,1), I (2,2), I (2,3), I ( Sample 2,4), and I (2,5). One of the features of the present invention is that if any system in a group of x systems operates on input I (1,1), then all systems in the group will have input I (2,1), i. It also works on (3,1), ... I (x,1), and while each system in the group is in state_n, all inputs I (1, n), I (2, n) ,. .. It concerns how to ensure that it works on I (x, n).

【0033】

According to this feature of the invention, if a game unit has not received all the inputs required for a given state, the game unit will receive all the required data from each game unit in the group. Until then, the state transition must be postponed.

【0034】

One of the features of the present invention will be described in relation to the following examples of its operation. This example describes a group of four players (ie, four players playing a game) participating in four physical game units. The present invention is applicable to more game units (more than 4) and fewer game units, and the following is just one set of examples.

【0035】

Example 1 shows a buffer holding four sets of inputs in four computer systems. This buffer is used by each of the four game units. Let's look at the buffer for game unit 1 in this example.

【0036】

[table 1]

<img file="JP2000296273A_D0001.tif" />【0037】

The column labeled "First Input" shows all inputs detected during the first time interval to sample user input. In this case, "input" means that the game unit responds to any activation of a game unit element such as a push button, joystick, etc. by a player, or any action taken or initiated by a player. It means other signals generated. "Nth input" represents all inputs detected during the Nth time interval sampling the user's input. While sampling the inputs in the local system (ie, game unit 1), they are stored in a buffer and then sent to each other system (game unit) in the group. The state transition functionality of a game unit requires input from each system and does not act on that input until a set of inputs is obtained from each system in the group.

【0038】

The following example shows how to use a buffering technique that keeps four separate systems (game units) state-synchronized. System 1 takes its first user inputs and stores them in buffer cells (systems 1, first inputs), i.e., I (1,1), as shown in Example 2. It also sends these inputs to each system in the group.

【0039】

[Table 2]

<img file="JP2000296273A_D0002.tif" />【0040】

When system 1 gets its second set of user inputs, it stores them in cells (system 1, second input). It also transfers these new inputs to each system in the group, as shown in Example 3.

【0041】

[Table 3]

<img file="JP2000296273A_D0003.tif" />【0042】

When System 1 begins receiving user input from other systems in the group, it stores them in the appropriate cells of the buffer. For example, if system 1 receives the first input of system 3, the buffer will be represented in Example 4.

【0043】

[Table 4]

<img file="JP2000296273A_D0004.tif" />【0044】

When System 1 finishes sampling its third input set and subsequently receives its first input set from System 2 and its second input set from System 3, the buffer becomes represented in Example 5.

【0045】

[Table 5]

<img file="JP2000296273A_D0005.tif" />【0046】

Up to this point, no action has been taken on the input that would affect the state of any part of the program, except for the state of the buffer itself. Once the last set of user inputs is reached, the program can run on all inputs I (x, 1). The buffer will temporarily become as shown in Example 6.

【0047】

[Table 6]

<img file="JP2000296273A_D0006.tif" />【0048】

Here, system 1 can act on the entire first input set (first input). It then discards these inputs from the buffer, and the next target to operate is the second set of inputs. Similarly, each of the other systems (game units) in the group acts on the first input set once it has received all the first inputs from all the systems in the group.

【0049】

After System 1 operates on the first input, the buffer becomes as shown in Example 7.

【0050】

[Table 7]

<img file="JP2000296273A_D0007.tif" />【0051】

System 1 does not continue to operate on user input until it has received all of the second input data from all systems. The use of this method ensures that each state transition that occurs in each system transitions from the old state to the new state using the same input set. This guarantees that the value of the new state after the transition will be the same on each machine.

【0052】

Note that each system does not have to run on the input data at the same time, each system only needs to run on the same input data sequence. To summarize the above, the initial state of any game software is called state_1, which is the state of the game unit immediately before the game unit operates on any user input. Furthermore, if the state of the game unit after operating on the input i (x, 1) is called state_2, what must be done to keep everything in sync is as follows.

【0053】

1. In state n, all game units in the group must receive input I (x, n), i.e. all values of x, from all game units.

【0054】

2. Each game unit must operate on the full input set I (x, n) before proceeding to state_n + 1. In short, the above-mentioned state synchronization method is such that, during operation, in a multi-player game or a multi-system game defined as described above, each player linked by the system is in each state of the game. The purpose is to be aware of all actions taken (and in some cases not taken) by you and each other player. In one example of the embodiment, the game state transitions at a rate of 60 hertz. That is, 60 times per second, which is also a typical frame rate for video game units linked to such systems. So, for example, if one or more players are "slow" and take no action over a certain number of states, the absence of this action constitutes an "input" and in a particular multi-system game. Distribute this input to all other game units to which the system links. On the other hand, a given state if one player's input (ie, activities or actions) is delayed due to some delay in the network, such as on a transmission line connecting various parts of the network. If there is no input from one or more players corresponding to, other games will be delayed in transitioning to the next state until all the inputs are received.

【0055】

This is in contrast to, for example, a single or single game unit in which the controller monitors all player inputs and determines the next state. Here, the next state cannot be completely determined until the input from all the players in the multi-system game has been received. In the illustrated embodiment, the software that performs the state synchronization method is located within the CPU or other central control unit of each individual game unit. That is, each game unit linked by the network of the present invention is provided with network processing hardware and software suitable for both linking to the network via the router 18 and performing the above-mentioned state synchronization method. It is equipped. III. Bandwidth management Preface The router 30 may be, for example, a commercially available router in the form available from Sisko or Bay Networks. The server is Hewlett It may be a PC or PC-type computer component commercially available as a server from various manufacturers such as Packard (Hewlett-Packard), Compaq (Compaq), and the like. These hardware servers also run software, often referred to as "server" or "logical server" software as well. This logical server software includes at least three basic elements in the illustrated embodiment, as schematically shown in FIG.

【0056】

The first element of these elements is referred to as a link server 40 (hereinafter, in some cases, a link serve or a similar term). The link server 40 processes all messages received via the router on the T-1 line. These lines originate from the game unit and forward these messages to Bandwidth Manager (BWM) 42 when needed. Bandwidth managers are another element of software or logical servers. The BWM42 sends the game unit's messages to its own opponent server 44 (as defined below) or "upstream link server", that is, a logical link at the next higher level or center such as regional, wide area, or national. -Determine which of the servers 40 should be sent. At the destination, the link server 40 starts the process again.

【0057】

Bandwidth Manager (BWM) 42 is a logical server that performs heuristics to determine player access or "promotion" for each tier level in the network system shown in Figure 1. Therefore, the play request from the game 16 in the arcade 10 is first processed by the router 30 at its corresponding metro hubs 12, 14, etc., and the corresponding link server 40 of the metro hub server 32 has the appropriate information. Should be relayed to the relevant bandwidth manager 42 to determine whether the request should be processed by the Metro Hub's Competitive Server 44 or forwarded to the Link Server 40 at Regional Level 20 to repeat this process. ..

【0058】

The match server (compserve) 44 essentially "matches" the requests coming from different game units, and which of these requests is suitable for linking for interactive play. Make a judgment. Various criteria such as game formats are available, allowing only games of similar or compatible formats to be linked for interactive games. For example, in order to be linked, two or more players must require play in the same "world", such as the same race track in a racing game. In the illustrated embodiment, the compserver44 can also refer to the player's skill level to bring the player's skill level closer to the overall or broader range of the player's skill level. As described in more detail below, skill levels determine the assignment of networks to hierarchical levels. The battle server 44 also considers the world of demand. That is, for example, in a road racing game, only all players requesting a race on the same track can be linked to interactive play. A player's request to play in a different "world", such as on a different track, must wait until an additional player's request to play in the same "world" is also received by the same match server. In addition, in the illustrated embodiment, the comp server44 notifies individual games when there is a "mismatch" request from another player waiting to play, and the system is interactive in a multi-system game. It is also possible to invite others to join a multi-game match, up to the number of players linked in the game.

【0059】

Here, the term "server suite" means a set of logical servers (as described above) contained within a particular hardware server 32. Here, when referring to a parent server or a "child" server, it indicates a position on the network hierarchy in FIG. 1, and the parent is assumed to be at a higher level than the child. When we refer to a "local" logical server, we mean a logical server located in the same server suite.

【0060】

Bandwidth Manager (BWM) is a network feature described earlier with reference to Figure 1, implemented by Server 32 for multiplayer, multigame units, and multilevel battles. To do.

【0061】

BWM's primary job is to monitor available network bandwidth and coordinate and track multi-level competitive services. If there is sufficient inbound and outbound bandwidth and the player has the appropriate skill level, BWM guarantees the player access to the next level in the WeveNet hierarchy.

【0062】

BWM has two tasks. The first is the upstream variety (USBWM), which is responsible for monitoring bandwidth on the connection between one level of server in the hierarchy and the next higher level. One BWM of this type is placed for each level. If all "recommended" criteria are met, the "match request" (and therefore the player) is forwarded ("recommended") to the next level parent server suite in the hierarchy, where the "recommended" process is renewed. Start. If neither level meets the "recommended" criteria, the server at that level retains the message for final tuning.

【0063】

Another type of BWM is the downstream variety (DSBWM), which is found only at the metro level. This BWM is responsible for bandwidth monitoring between the metro-level server suite and the arcade. To do this with high accuracy, each arcade is assigned a separate BWM. Therefore, DSBWM is the initial link between the arcade and other servers. That is, all messages from the game unit to the server pass through the DSBWM. Non-competition service message) is sent untouched to a metro-level link server. Competitive service messages are treated separately. The same discovery method used in USBWM is used to determine whether to give the player access to the network WaveNet. When granting access, a message is sent to USBWM and further processing is performed. If not granted, delete the message. This is the case when it is determined that sufficient bandwidth to support network play is currently unavailable for more players. The game will continue to send requests once every second until it expires or such bandwidth becomes available.

【0064】

There is actually only one type of BWM. Even if the DSBWM is located in the metro hub, it can be considered logically located in the arcade. Under this example, it also becomes a USBWM, managing the connection from the arcade to the Metro Server Suite. Bandwidth usage and access rights (recommended) are treated in the same way. The difference is in the number of BWMs and how to process and send messages. In the following description, when referring to the BWM service, it is meant to be common to both varieties. Note the differences if necessary. Design nomenclature BWM is a logical server for the network WaveNet. The logical server provides the services of the network WaveNet. The game is considered a client. The client is always the controlling agent in this paradigm and is responsible for invoking the service request. However, the server can also send a notification without being requested to trigger a request from the client. The hardware running by the server is called the host.

【0065】

BWM runs in the background, closes all open file descriptors, resets the file creation mask, disconnects from its parent process group, and disconnects from the controlling terminal.

【0066】

Message and data flow views are centered around BWM. When discussing messages, one should consider BWM (for example, inbound is in the direction of BWM). When describing the message flow of a server, the end point of communication is indicated as either a game unit or a server. There can be many levels of service between endpoints (ie, the flow via NSS and LinkServer), but for simplicity and clarity, the levels may be ignored.

【0067】

[Table 8]

<img file="JP2000296273A_D0008.tif" />【0068】

Network bandwidth management concept BWM is responsible for tracking inbound and outbound upstream bandwidth currently in use over a network connection to a parent server suite (USBWM) or arcade (DSBWM). Recall that DSBWM is logically located in an arcade. Both server suite and game unit traffic use this network connection.

【0069】

When the BWM receives the match request, it first checks the current upstream bandwidth utilization. If bandwidth is available and the player has access rights (see the "Player Access Rights and Recommended Findings" chapter below), BWM reserves and acquires bandwidth for this player. Start the process.

【0070】

USBWM-If the player does not have available bandwidth (the bandwidth is being used to the maximum or the player does not have sufficient skill level), USBWM sends a message to the local match server.

【0071】

DSBWM-If the player does not have available bandwidth, DSBWM simply deletes the message. If you don't have enough bandwidth available to support your match, there's nothing more you can do. The game unit will continue to send match requests once per second until the time runs out or the band becomes available.

【0072】

For the rest of this chapter, we will assume that there is enough bandwidth to assist the match on demand. In that case, BWM needs two pieces of external information to do the job. That is, the game format for determining the bandwidth requirement of the game unit, and the maximum number of players that can be played. The game unit bandwidth requirement (GBR) is the maximum amount of bandwidth a game unit must acquire. It is assumed that the bandwidth required by the game unit is symmetric with respect to the inbound and outbound channels. At the time BWM receives the match request, it has no a priori knowledge of the number of players likely to participate in the match. Therefore, it must be assumed that the maximum number of matches will be played and the maximum amount of bandwidth will be secured. For example, if a game has a match limit of 8 players, BWM reserves 1 outbound GBR for each player and 7 corresponding inbound GBRs for the other 7 players. Create player state, reserve bandwidth, recalculate utilization, and send player requests to the appropriate server suite. No bandwidth is reserved for subsequent match requests from game units.

【0073】

The BWM must also re-adjust its use after forming, adjusting and closing the match. Once closed, there are a fixed number of players in the match. Since we assumed the worst (ie, the maximum number of players possible), we may have secured more bandwidth than we actually needed at the time of the first match request. The infrastructure that manages bandwidth regulation is the callback chain for BWM_ADJUST messages. Immediately after broadcasting COMP_CLOSED, the selected match server returns a BWM_ADJUST message to each game unit via all BWMs responsible for player recommendations. This message encapsulates the IP (Internet Protocol, or other protocol if applicable) addresses of all game units involved in the match. One inbound GBR reclaims for each game unit (player) previously recommended by BWM (ie, BWM has the state of that player). This is necessary to make the initial assumptions for inbound traffic from the maximum number of opponents. The player with the lower skill level (see Player Access Rights and Recommended Discovery Methods) does not generate inbound traffic on the upstream line. Match-related states are created in BWM to ensure that the system corrects only once per match. After correction, adjust the usage rate, and if there is a child BWM, relay the BWM_ADJUST message to the downstream side. A BWM_ADJUST message is sent to each player in the match. In the rare case of lost BWM_ADJUST messages, this is not catastrophic. What happens is that bandwidth usage is not adjusted downwards and only accidentally remains high or overused. This "overuse" is conservative Since it is side), the system is safe. That is, it is within the limit. If this anomaly occurs, the COMP_OVER_ACK callback sequence or "garbage collection" will handle it.

【0074】

Once the match is over, the game unit sends either COMP_OVER or COMP_CONTINUE. The BWM and comp server use this message (ie, the ACK from the message) to wipe out any conditions related to the player and the match. BWM must correct the total bandwidth (both inbound and outbound) allocated to the match as part of its cleanup. Each game in a match sends one of these messages. If the same BWM recommends more than one player in a match, the BWM will receive a number of requests for correction. All corrections to the match will be made upon receipt of the first COMP_OVER_ACK or COMP_CONTINUE_ACK. Subsequent messages are simply relayed downstream.

【0075】

The GBR value is a per-game-type tunnel that is located within each game section in the server suite configuration file. Synchronous is called bandwidth_consumed, for example, in the 8-player game example described above, it has a unit of k bits / second.

【0076】

[Table 9]

<img file="JP2000296273A_D0009.tif" />【0077】

Player access rights and recommended discovery methods The BWM is responsible for determining if a player is "good" enough to give him access to a higher level of competition. Access rights are based on the player's skill level as they relate to the current average skill level and current bandwidth usage. The skill level of the player is determined by the game unit and encapsulated in the match request message. The current bandwidth usage is either inbound or outbound upstream bandwidth usage, whichever is greater (the system is always connected to both, so choose the worse).

【0078】

Bandwidth can be considered as a commodity, and in that respect it can be considered valuable. This capacity value is directly related to the usable amount. When fully usable (ie, the network is idle), it is relatively "cheap" to get and anyone has the opportunity to consume it. Conversely, if the network is heavily used, the remaining bandwidth will be "expensive" and difficult to obtain. This consumer market currency unit is skill level. The idea is to recommend the best player who is currently demanding a match.

【0079】

Not all bandwidth (100%) will be available to the player. Servers, routers, etc. secure a certain percentage of it for use as overhead. This percentage is called the Overhead Reserved Percentage (ORP) and is tunable through the server suite configuration file. Once the ORP is reached, BWM withholds all recommendations until sufficient bandwidth is available.

【0080】

The skill level of the player is contained within a variable, and the skill range is 0 to 255. 0 is completely incompetent and 255 is the highest skill level. Set the threshold to separate the mediocre proficiency player from the proficient player. This thresh hold is called an expert player thresh hold (SPT: Skilled Player Threshold). SPT is used to regulate the small amount of bandwidth reserved for highly proficient players. The reserved bandwidth is managed by the Skilled-player Reserved Percentage (SRP), and is the bandwidth from SRP to ORP. Once the player's skill level exceeds the SPT, the player will always have access to the reserved bandwidth. In this way, we ensure that the best players are given the best recommendation opportunities. SPT and SRP can be tuned through the server suite configuration file. See Figure 4.

【0081】

Two different metrics are used in determining player recommendations. The difference is related to the amount of bandwidth currently in use. If the bandwidth in use is less than the Free Access Percentage (FAP) or Free Promotion Threshold (FPT), grant access to him or her and recommend it, regardless of the player's skill level. To do. This allows you to "prime the pump" (pump the player into the network) and keep them playing at the recommended level. It goes without saying that this is not only fun to play through the network, but also profitable for the network operator. The FAP can be tuned through the server suite configuration file. Its value should be set low enough to ensure that it does not allow unskilled players or the average player to over-allow the network.

【0082】

Once the FAP is reached, use the second recommended metric. Each time a player is granted access, the skill level of that player is added to the currently recommended skill level list for all players. Next, calculate the average skill level (ASL) and create a line graph. One end of this line is fixed to the FAP and the other changes from 0 to SPT along a fixed SRPX-value (see Figure 5). The changing end point Y value is the ASL just calculated. Equipped with this information, the slope of the line is calculated by the following formula.

【0083】

[Number 4]

<img file="JP2000296273A_D0010.tif" />【0084】

Once the slope and current bandwidth usage are obtained, BWM can compare the player's skill level with the current average skill level. If x is the percentage of bandwidth currently in use, then y is the recommended physiotherapist (PT).

【0085】

[Number 5]

<img file="JP2000296273A_D0011.tif" />【0086】

Once y is calculated, all that is needed to determine a player's access rights is a simple comparison. If the player's skill level is above the PT line, give the player access for recommendations.

【0087】

USBWM-If the player is located below the PT line, forward the request to the local match server for coordination. DSBWM-If the player's proficiency is below the line, DSBWM simply deletes the message. Players are only inadequately skilled at current bandwidth usage. The game will continue to send match requests once every second until the player runs out of bandwidth or the bandwidth becomes available to the player due to ASL reduction.

【0088】

Adjust the available bandwidth and average skill level when players complete their match (or when garbage collection wipes out old entries). The player's skill level value is time-delayed manner decremented from the current skill list. This is done by placing the player's skill entry on the skill level list. After a short amount of time, reincorporate the values in the list into the ASL values. This method manages the continuing player better by temporarily keeping the ASL higher than it really is. Continuing players with improved skill levels after a match will have more opportunities to gain bandwidth next time.

【0089】

Figures 5-7 show three examples of recommended discovery methods. The shaded area represents the recommended area. Figure 5 shows an example where the bandwidth consumed is less than FAP and therefore BWM recommends all players. Figures 6 and 7 show two examples, one with 60% of the bandwidth in use and the other with the current average skill level (ASL). In Figure 6, the ASL is fairly low, and therefore the skill level (PT) required for recommendations is also correspondingly low. Figure 7 shows an example where ASL has reached the upper limit of SPT. Under the same bandwidth of 60%, the skill level (PT) required for recommendation in Figure 7 is much higher.

【0090】

There are five BWM tunables related to the recommended discovery method. (See Table 5- BWM Synchronous for more information on tunables.

【0091】

[Table 10]

<img file="JP2000296273A_D0012.tif" />【0092】

In other game formats, the system can incorporate a normalization mechanism to take into account skill levels. This is because different game formats may have different skill level patterns. Static or dynamic corrections may also be required. However, the bandwidth used remains the same because all game units compete for the same bandwidth. Message type analysis In addition to common server management messages, BWM handles the following four message types: COMP_REQ, COMP_OVER, COM_CONTINUE, COMP_OVER_ACK, and BWM_ADJUST.

【0093】

[Table 11]

<img file="JP2000296273A_D0013.tif" />【0094】

BWM receives COMP_REQ from each game every second until CompServer closes the match. The first thing BWM does with a request is an increment of the message hop counter. The hop counter implies the distance of the message from the game. The server leverages this information to infer where they are located in the hierarchy.

【0095】

BWM then looks at its internal state table to see if it has already given the player access to the next level. If granted, clear the request for recommendation. If the user selects a world of play, BWM will attach its own IP address and port number to the message. Attaching the address ensures that the BWM_ADJUST callback will occur near the match and that you can adjust the bandwidth usage (see the BWM_ADJUST chapter for more information).

【0096】

USBWM-Next, transfer COMP_REQ to the next level server suite (LINKServer). DSBWM-Next, forward COMP_REQ to the local level USBWM for further recommendations.

【0097】

If the state does not exist, check the message to see if it is a new match or an already adjusted match by looking at the match id and cid values. If the cid is 0, the game is requesting a new match. Otherwise, the value of cid is that of an already adjusted local match, sending the message to the local CompServer for processing.

【0098】

For a new match, BWM then decides if the player should be considered as a recommendation. The chapters "Network Bandwidth Management Overview" and "Player Access Rights and Recommended Discovery Methods" provide detailed explanations of recommended criteria. Assuming a player qualifies for the recommendation, BWM creates a state for that player's request and adjusts the current average skill level and bandwidth usage. If the user has selected a world of play, BWM will attach its own IP address and port number to the message.

【0099】

USBWM-Next, transfer COMP_REQ to the next level server suite (LinkServer). DSBWM-Next, forward COMP_REQ to your local USBWM for further recommendations.

【0100】

Conversely, if the recommended criteria are not met and there is no next level in the hierarchy, the BWM will be dormant. That is, the recommended logic is disabled. Does not create a state for the player.

【0101】

USBWM-Transfer COMP_REQ to a local match server for tuning. Delete the DSBWM-COMP_REQ message.

【0102】

See Figure 8-10 for the COMP_REQ flowchart.

【0103】

[Table 12]

<img file="JP2000296273A_D0014.tif" />【0104】

If the player chooses not to continue, the game will generate a COMP_OVER message at the end of the network match. If the player decides to continue, the game sends a COMP_CONTINUE message instead. The content of both messages is the same, only the action fields in the header are different. Messages are sent from the game every second until the game finally receives an ACK. The ACK is either COMP_OVER_ACK or COMP_CONTINUE_ACK, depending on which action was requested.

【0105】

The first thing BWM does with a request is an increment of the message hop counter. The hop counter implies the distance of the message from the game. The server uses this information to infer where they are located in the hierarchy.

【0106】

BWM then looks at its internal state table to see if it has already given the player access to the next level. If so, BWM will attach its own IP address and port number to the message. By attaching the address, ACK is automatically passed to BWM on the return trip.

【0107】

USBWM-Next, transfer COMP_OVER / COMP_CONTINUE to the next level server suite (LinkServer). DSBWM-Next, transfer COMP_OVER / COMP_CONTINUE to the local level USBWM.

【0108】

Note that the COMP_OVER / COMP_CONTINUE message does not remove the state related to the player's access rights. This is done when an ACK is received.

【0109】

If the player has no state, it means that the match was local or that state has already been wiped out by a previous ACK. In either case, pass the message to the local CompServer for further processing.

【0110】

FIG. 11 is a flowchart of COMP_OVER and COMP_CONTINUE message processing.

【0111】

[Table 13]

<img file="JP2000296273A_D0015.tif" />【0112】

CompServer first generates COMP_OVER_ACK or COMP_CONTINUE_ACK in response to COMP_OVER or COMP_CONTINUE, respectively. Recall that when the COMP_OVER message percolates to CompServer, BWM pre-attached its address and port to this message.

【0113】

The ACK message has two purposes. First, BWM uses this message to begin clearing any state it creates on behalf of the player. Second, the game treats this message as an indication that the server has completed processing with the player and the game is now freed and available for another WaveNet match.

【0114】

When the BWM receives an ACK message, it checks to see if there is a status for the match. If so, clear all bandwidth allocated to the match and remove the match state entry. This method makes bandwidth more readily available.

【0115】

Next, a check is made to see if the player has already been recommended. If recommended, remove the game state entry. If you haven't finished correcting the bandwidth allocated to the game, do this as well. Finally adjust the ASL.

【0116】

Then pass the message to the initiator. In this way, ACKs are automatically returned one after another through all recommended levels, so that the states associated with creating a match are properly discarded at each level. This design is very clean and very extensible.

【0117】

If the same BWM recommends more than one player in a match, the BWM will receive multiple requests to correct for that same match. All corrections to the match will be made once upon receipt of the first ACK. Subsequent messages are simply relayed downstream.

【0118】

FIG. 12 is a flowchart of COMP_OVER_ACK and COMP_CONTINUE_ACK message processing.

【0119】

[Table 14]

<img file="JP2000296273A_D0016.tif" />【0120】

CompServer raises a BWM_ADJUST message immediately after closing the match. This is used to adjust the bandwidth reserved when the player first created the state as part of the recommended process. See the chapter "Overview of Network Bandwidth Management" for a description of the message and its effects. FIG. 13 is a flowchart showing BWM_ADJUST message processing. Message flow analysis The flow charts or charts of the three messages in Figures 14-16, 17 and 18 show a detailed analysis of the messages involved in adjusting and clearing the match. The first flowchart, Figure 14-16, shows an example of two game units coordinating a match. Includes all message types and match states related to the start of a match. The state is more applicable to CompServer. 17 and 18 show the messages sent when the match is complete. This figure contains an example of how BWM and CompServer handle previously lost messages.

【0121】

Referring to FIG. 15, in the upper right corner, the game unit sends a match request every second. At reference number 1201, if the recommended criteria are met, a state is created, bandwidth is reserved, and a player is recommended. In the example shown in Fig. 14-16, the battle state is initially idle until the battle request is received. The game unit first sends a match request, without specifying a requested world, and locates information about the match it has. Returns a COMP status message until the player selects a world, as shown in 1202. At this point, the battle status is put on hold. That is, when the first COMP request with the selected world is received, a match is created and the state is changed to hold, but the COMP status message is still returned.

【0122】

At reference number 1203, a second player in another game unit joins a match in the same world selected by the first player. Here, the match enters the staging state, initializes the stage waiting timer, and returns a COMP start message to all games in the match. In this state, the COMP start message responds to each match request. Once each BWM or status wait timing has passed, the status is changed to closed, the closure wait timer is initialized, and a COMP_CLOSE message is returned to all the games in the match. At this point, the COMP_CLOSE message responds to a new match request. BWM_ADJUST occurs after closing a match. The battle state becomes active after the closing waiting timer ends. Reference number 1204 indicates disconnection if the message is lost, and the game unit resubmits the match request.

【0123】

Referring to FIG. 17, at 1301, the player is granted access and the player is passed to the USB WM. At 1302, USBWM tracks recommendations and passes COMP_OVER messages to the next level. At reference number 1303, CompServer initiates COMP_OVER approval once the data is stable. In 1304, competition teardown goes back through all recommended levels (cascade back) to ensure proper cleanup.

【0124】

In FIG. 18, reference number 1401 indicates disconnection when the COMP_OVER_ACK message is lost. The game unit sends the COMP_OVER message again. At 1402, receive another COMP_OVER message from an unconfirmed or unknown match. Produce a COMP_OVER_ACK answer in exactly the same way. BWM tunable [0125]

[Table 15]

<img file="JP2000296273A_D0017.tif" />【0126】

Summary of outstanding features of BWM The network connection between games, routers, servers, etc. shall be 1.5 Mbit / s T-1 lines.

【0127】

Stateful. BWM must track the player who previously granted access. Keep this information in the dynamic access rights table. This table contains the following elements: Game IP address and port number, player skill level, bandwidth consumed by the player's game, entry epoch (creation time), entry last access time, and pointer to a match entry.

【0128】

USBWM is symmetric with respect to the hierarchy level. This suggests that USBWM performs the same function regardless of where it is located in the hierarchy. DSBWM is specific to the metro level. There is a separate DSBWM that manages each arcade that communicates with the Metro Server Suite. To do this, DSBWM reads the appropriate files and activates the server for each unique domain (arcade). This is done when the server is called.

【0129】

DSBWM will always contact the local USBWM (route) whenever it gives access to the player, otherwise it will delete the message due to insufficient resources available.

【0130】

Use the same binary number for both upstream and downstream BWM. The user must provide a "switch" and indicate direction when calling the server. -d specifies DSBWM and -u specifies USBWM.

【0131】

Monitor both inbound and outbound bandwidth usage. When BWM compares bandwidth usage, this implies a comparison with the larger of the inbound and outbound values. The system is always connected to both, so choose the worst case.

【0132】

Skill level and available bandwidth are the components used to determine a player's access rights. When granting access, recommend players to the next level in the hierarchy. The recommended discovery method is tuned so that you can adjust the threshold without having to recompile your code. The discovery method is dynamic in nature and varies based on the set of players currently consuming bandwidth.

【0133】

USBWM is one of several servers that are allowed to derive messages to different levels in the hierarchy as part of their recommended logic. This is very easy to do. As a result of the recommendation, the match request is passed to the parent server suite (LinkServer) at the next level within the hierarchy level (assuming there is the next level). This interface allows the system to be easily scaled to any depth.

【0134】

BWM stays dormant at startup for a fixed amount of time (for example, 5 minutes by default). This is to grant access rights and settle the network to a known state before bandwidth is consumed.

【0135】

It is also possible to disable the recommendation logic and effectively stop the player's recommendations. This is done by a command sent by the WaveNet server tool. The dormancy time can be adjusted with this tool.

【0136】

USBWM requests the IP address and port number of the parent LinkServer. These values are obtained from the local server suite configuration file. Create the following new sections and tokens.

【0137】

[Table 16]

<img file="JP2000296273A_D0018.tif" />【0138】

Each BWM has a separate configuration file section. This allows for better tuning granularity. The USBWM section is called [USBWM] and the DSBWM section is called [DSBWM]. Configuration files for levels higher than the metro level do not have a DSBWM entry.

【0139】

It provides a periodic "garbage collection service" to wipe out old server states and any bandwidth entries reserved. Obsolete entries can occur due to network / server failures. Check the "timer" at the end of each message, and if it is "popped", call the "garbage collection service". Set the timer to the value of BWM_COLLECT_GARBAGE seconds. After BWM_AGE_OLD seconds, the entry is considered out of date. These values are not tuneable in the embodiments described herein.

【0140】

Garbage collection can also be triggered by sending a SERVER_COLLECT_GARB message to BWM. Perform periodic consistency checks to verify average skill level (ASL) and bandwidth utilization. To do this, all players and competitive states are compared to the dynamic values used to maintain ASL and bandwidth usage. BWM_COLLECT_GARBAGE Holds a timer that is similar in concept to the timer. In the embodiments described herein, this value is not tunable. IV. Architecture WaveNet server commonality All servers correspond to a set of Common Server Management Messages (CSMMs). BWM follows this requirement. CSMM messages control the internal functionality of BWM. The operation types are as follows.

【0141】

1. Server verbosity level (SERVER_VERBOSE) [LOG_CRIT (0)-LOG_DEBUG (7)] 2. Allow BWM to exit on error (SERVER_EXIT_YES) or disallow (SERVER_EXIT_NO) 3. Core file generation (or no generation) at exit (SERVER_EXIT_YES / SERVER_ERR_CORE) 4. Reload the server configuration file (SERVER_HUP), reinitialize the BWM state 5. Receive ping message / Ack (SERVER_PING) 6. Kill BWM and generate core file (SERVER_FORCE_CORE) 7. BWM Specific-Forced Garbage Collection (SERVER_COLLECT_GARB) WaveNet Control Protocol Header (WNCP) All messages passing between game units (multiple game units), NSS and servers are encapsulated in packets preceded by a common header. Message headers and data are packed (aligned byte by byte) and passed in network byte order. The WaveNet server message header has the following structure.

【0142】

[Table 17]

<img file="JP2000296273A_D0019.tif" />【0143】

All incoming messages from the game to the server include the game type and game version immediately after the WNCP header. Many servers need to distinguish between game types and therefore must adhere to this requirement. All messages from the game unit to the server begin in the following format:

【0144】

[Table 18]

<img file="JP2000296273A_D0020.tif" />【0145】

Although various modifications and alternative embodiments are possible in the present invention, specific embodiments have been shown and described here as an example. However, it will be understood that it is not intended to limit the invention to the particular embodiments disclosed. Conversely, the invention is intended to include all modifications, equivalents and alternatives that fall under the spirit and scope of the invention as set forth in the appended claims.

[Simple explanation of drawings]

[Figure 1]

It is a figure which shows the network processing system of the video game by this invention. [Figure 2]

It is a simplified diagram which shows the operation of the tournament system of the highest score update type so far of the prior art.

[Fig. 3]

FIG. 5 is a simplified block diagram of an interactive play operation between only two players at different positions in a prior art system.

[Fig. 4]

It is a simplified schematic diagram of the configuration of the logical server of this invention.

[Fig. 5]

It is the schematic which shows the example of the band management by this invention.

[Fig. 6]

It is the schematic which shows the example of the band management by this invention.

[Fig. 7]

It is the schematic which shows the example of the band management by this invention.

[Fig. 8]

It is a flowchart which shows various features of bandwidth management of this invention.

[Fig. 9]

It is a flowchart which shows various features of bandwidth management of this invention.

[Fig. 10]

It is a flowchart which shows various features of bandwidth management of this invention.

[Fig. 11]

It is a flowchart which shows various features of bandwidth management of this invention.

[Fig. 12]

It is a flowchart which shows various features of bandwidth management of this invention.

[Fig. 13]

It is a flowchart which shows various features of bandwidth management of this invention.

[Fig. 14]

It is a flowchart which shows still another feature of bandwidth management by this invention.

[Fig. 15]

It is a flowchart which shows still another feature of bandwidth management by this invention.

[Fig. 16]

It is a flowchart which shows still another feature of bandwidth management by this invention.

[Fig. 17]

It is a flowchart which shows still another feature of bandwidth management by this invention.

[Fig. 18]

It is a flowchart which shows still another feature of bandwidth management by this invention.

[Explanation of symbols]

10 multiple arcades 12 Metro Hub 16 game units 18 Arcade Router 20 regional centers 22 Wide area center 24 National Center 26 modem 28 Modem 29 Central server 30 router 32 server 39 server 40 link server 42 Bandwidth Manager 44 Battle server