There are several ways to make scalable communication. Applying the right technique depends on the game’s rules. But with respect to scalability, there are two major cases. First, if there are a constant number of point-to-point interactions independent of the number of threads, the game would be scalable. Second, if there are effects that have a collective nature, such as gravity between objects—potentially n² point-to-point operations—the game is not likely to scale. (We consider this to be worst.) There are a variety of techniques to improve the scalability of such n² point-to-point operations. In selecting the right technique, you should also take into account that the serial computation of these effects can be more efficient (linear time) than the scalable point-to-point computation.

As an example, a real physics computation is rigid body physics. There are two cases. Each rigid body may lie within one or a few domains. In this case, it is scalable because the physics will be computed by each thread on bodies within its domain. If, however, the rigid body spans all domains substantially, an advanced technique must be used. In this case, you could consider the computations done in molecular dynamics (MD), which have similar characteristics. MD computations have been implemented in an extremely scalable manner in the NAMD application (http://en.wikipedia.org/wiki/NAMD), which won a Gordon Bell award for scalability. It is not likely that you will need that much scalability, so be selective in using these techniques.

In the example, in order to illustrate why object-to-object physics interaction alone can be hard, we used the gravity challenge, potentially n² communications. Our example code illustrates two implementation moves.

The first move is to split the physics into two phases, as described earlier in terms of SI and SF. In the first phase, compute all the interactions:

In the second phase, transfer the next state into the current state so that the next frame can repeat.

In the second phase, we implemented a fast algorithm that does neither all-to-all synchronization nor only point-to-point. It uses something loosely based on the n-body Barnes-Hutt computation. It is inside the pStar->Update method for stars and is not shown in the code (though it is in the downloadable complete version of the code).