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
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
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
a relevant set of objects for a client.
each object in the relevant set, distribute any state that has changed
since the last time that object was distributed to that client.
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:
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.
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.
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.