Distributing Object State for Networked Games Using Object Views

As game developers, we are continuously challenged to create richer and richer game worlds. Whether we are developing a 16-player multiplayer game, or a 10,000-player persistent world, making richer game worlds efficiently means we must be increasingly intelligent about how we distribute the everchanging state of our game objects. This problem is further complicated by the diversity of the network connection characteristics of each player. In this article, I’ll describe a technique for managing the distribution of object state using an encapsulation mechanism called an object view. Object views provide a means for managing the distribution of object state on a perobject basis that is flexible and transparent to the game object. In order to describe what they are and how they are used, we’ll also peer into the workings of a distributed object system designed for multiplayer games.

Net Profit, Net Loss

A s with many other areas of computing, some of the most significant problems inherent in distributing simulations have to do with resource management. In the case of networking, our primary concerns are with the limitations of the game clients and especially the nasty problem of controlling bandwidth utilization.

For most subscriptionbased massively multiplayer (MMP) games, bandwidth limitations are not based upon physical limits; rather they are based upon band width costs. This means that proper bandwidth management translates into real dollars in a very big and measurable way.

Other techniques, such as those for masking lag and smoothing movement, are also essential for creating great multiplayer games. But for these to be effective, accountability must be had in the underlying implementation for the bandwidth limitation, whether constrained artificially or by the physical medium itself. After all, the bits have to actually arrive at their destination before they can do any good. Proper bandwidth management isn’t just a networking problem, it’s a wholegame problem.

But what does all this accountability have to do with object views? Before we get into the nuts and bolts of object views, let’s talk a little about why we need them.

So Many Objects, So Little Time

At Monolith, we have been using object views as a fundamental construct in the development of our distributed object system. A Distributed-object system is a game system that manages the housekeeping chores related to the distribution of object state. It is the principal user of the relevantset creation mechanisms, which in our implementation are provided by the world representation (see Figure 1). Relevant sets are collections of objects whose state changes need to be distributed immediately (if not sooner) if we are to ensure that a remote client’s view of the simulation matches the actual state of the simulation. The topic of relevantset generation is so large that it warrants its own separate discussion, so I won’t be delving into it very much here.

Figure 1. Major game components involved with object state distribution.

In multiplayer games, we generally associate a connected playerclient with a single, playercharactercentered view of the simulation. Each client only needs to render a limited portion of the game world at any one point in time. Consequently, the state of all the game objects that are relevant to the rendered portion of the simulation must be uptodate.

Direct data management vs.RPC. Distributed-object system implementations for both games and distributed simulations typically manage distribution of object state data rather than simply providing a generalpurpose remote procedure call (RPC)based mechanism. Why? The answer is rooted not only in our fundamental need to make the best possible use of the available bandwidth, but also, as we will see later, in our need to design a system that makes it as simple as possible for us to specify exactly how we want the component parts of our game objects to be distributed.

The responsibilities of a Distributed-object system are conceptually quite simple:

1. Obtain a relevant set of objects for a client.
2. For each object in the relevant set, distribute any state that has changed since the last time that object was distributed to that client.
3. Repeat the preceding steps for each client.

As simple as the system seems conceptually, the devil really is in the details. Even if we are strictly using visibility based relevance determination, the full relevant set for a given client at any instant can be enormous. As an example, consider what happens when you direct your playercharacter to stroll up to the top of a nearby hill. As you crest the hill, the number of visible objects is likely to increase dramatically. Unfortunately, the amount of available bandwidth remains somewhat constant over time, so the distribution of objects in the relevant set must be managed carefully, using prioritization techniques that allow the most important state to be sent immediately and the less important state to be transmitted as soon as possible thereafter.

Multiplayer game objects
.We’ve discussed that a key functionality of the dis tributedobject system is identifying, prioritizing, and selecting game objects from relevant sets, restricting the set of game objects to only those that need to be distributed. But only some of the components from a given object will need to be distributed. What are these components? To answer that, let’s take a look at a simple game object.

Figure 2. A simple game object.

Figure 2 shows the basic component parts of a simple game object that you might find in a generic multiplayer game. The object consists of three major groups of component items:

• Visual and displayrelated items. These are component items related to the visual state of the game object, including movement and position information. They very much need to be distributed. For playercharacter objects, this includes values that may only be displayed on a HUD (headsup display) of the player controlling that character.
  
• Game logic and AIrelated items.These are component items related to the game state of the object. In a purely serverbased simulation, these items would seldom (if ever) be distributed to clients,but could be distributed to a trusted entity, such as another server.
  
• Housekeeping items. These are component items, such as reference counts and pointers to internal structures. They are not distributed.

As our playercharacter roves around within the simulation, it will encounter new game objects, spend a little time hanging around near them, leave the area, and very likely reencounter many of the same game objects sometime later on. Since we only want to be sent updates for the items that have changed since the last time we encountered the object, something will have to remember the state that the object was in the last time we encountered it. To complicate matters, one client may have very different distribution requirements from another client for the same object. This is where object views come in.