Some games perform interest filtering by partitioning the game world into disjoint regions or cells and noting that an object's area-of-interest can usually be described by the cell in which they currently reside or a subset of cells nearby. Several architectures proposed for Distributed Virtual Reality (VR) environments (notably, DIVE[19], High Level Architecture (HLA) [22]) utilize IP-Multicast to realize area-of-interset filtering; each cell is assigned to a multicast group and objects describe their area-of-interest by subscribing to the relevant groups. The SimMUD game [12] implements area-of-interest filtering similarly using a Distributed Hash Table (DHT); each cell is assigned to the node in the DHT that it's name or ID hashes to. Second-Life [10], a commercial game, also employs cells to partition the game world and assigns a single cell to each node in a server cluster. Butterfly.net [2], a cell-based distributed game architecture, assigns multiple cells to each server, weighting each cell by its popularity.
This approach has several drawbacks. First, it does not take into account interests other than those specified by location; i.e., a player may be interested in receiving some information about the other players on his team. Second, the region-granularity must be specified in advance by the game developer in order to partition the world. The granularity of the partitioning critically affects scalability. If it is too coarse, players may end up receiving many useless updates. On other hand, if the granularity is too fine, players may need to specify interest in a large number of cells. In fact, a fixed granularity may not be appropriate to all players. For example, a player in an aircraft may see much larger portions of the game than one in tank. Finally, due to the irregular shape and popularity of regions in the game world, a great deal of hand-tuning of the mapping of game-world to regions might be necessary to achieve good load-balancing and efficient mapping of area-of-interests onto regions. Butterfly.net addresses load-balancing by dynamically changing the cell to server assignments. However, Butterfly.net must operate on a fast LAN to enable this dynamic reassignment and the number of cells in the game must be proportional to the skew in the popularity of different regions in order to effectively balance load.
A final problem that exists for several of these architectures is that they often tie the execution of objects (such as player think functions) with the node that is responsible for the region in which the object resides. Hence, if an object moves between different regions frequently, it will migrate between different nodes often, which may be disruptive to client gameplay. For example, in a fast moving game like Quake II, movement between any reasonably sized regions would be quite frequent. Migrating clients between servers often, even in a centralized cluster, could incur intolerable overhead during migration.