This is the solution for the scalable dynamic world problem. The amount of processing power required to make such a large world, cannot be made available through the use of a single machine running up a server process. Only multiple server machines can handle such a load without compromising the overall responsiveness of the simulation.

The question is; if we run separate server processes... what does each one run exactly ?

On a dedicated server -- that is a host that is not doing world rendering but only game play simulation -- we can roughly subdivide an RTS game on 6 major areas that feed on processor cycles :

- AI Players Strategical Status and Goals Evaluation

- Game Resources And Infrastructure Management

- Unit Path Finding

- Unit Tactical Motion/Targeting Logic

- World Rendering Support State

- Other System Resources Management

Of all these probably the most time consuming task is the unit path finding, followed by motion/targeting logic. This is because a game of this type has an interesting property if we compare it to say, a typical first person shooter; the largest variable that has impact on scalability is not the number of players, but the number of units.

If we use a single machine, this means we either reduce the unit capability list to a bare minimum, or we cap the number of units the system can handle at a given time by either a forced limit, or better yet game play restrictions designed to contain the expansion of any single player forces. On the other hand if we use multiple servers we can share the heavy work load resulting from the fine grain tactical control over thousands of units at each game cycle and still be able to keep the frame rate up.

The network architecture of the multi-servers scheme is a cluster of mandatory servers that share the world simulation and clients that connect to one or more of these servers. No pier-to-pier communication is ever done between clients.

How to maintain game play integrity on a simulation that is running on distinct machines ? Well, we can arrange things so that for each unit there is a specific mandatory server that basically owns a master simulation, these mandatory servers could group the units by zones or geographic locations.

We can see that the interaction between units on the same server is easy, but what if they belong to different servers ? One solution, is the communication of interaction events between servers, by sending the parameters of each other units simulation and keeping state by maintain proxy objects of foreign units on each mandatory server so that each host has cached copies of other simulations, synchronization would be done by means of state update if the mandatory server changes the simulation parameters. To increase performance, we could enter the field of prediction but that is probably only a good thing between client and server and not necessarily between mandatory servers.

Other interesting features that could add to the multi-server paradigm are balancing servers, in which the load could pass from server to server on the fly as to avoid any single machine overload, and other one would be mirror servers to add redundancy into the system so that if one machine crashes, its state could be salvaged and not lost forever. This could be enhanced also by having auto backups, that is full state streaming into disk from time to time to recover from any catastrophic disaster. How to load and restore this data into a running and evolving world would be a game play issue though.

-Rui Ferreira

mail to: t5rui@hotmail.com

RTS

Scalable World

Open Game Play

Multiple Servers

Main