Resource Guide

Distributing Object State for Networked Games Using Object Views

Using Object Views

At the instant an object view needs to be created, a perfect opportunity exists to make some intelligent decisions. By checking the connection characteristics of the client, the distributed object system can select an object view that is tailored for supporting specific clients. This also means that clients with unique communications requirements could conceivably coexist in the same game environment, sharing the game objects with clients that have completely different communications requirements. This could, for example, allow a client on a handheld device to share the game world with clients connected via a PC or game console.

Multiple object views,movement,and predictive contracts.The game objects in the preceding examples had only one object view bound to them. This was strictly for simplicity. In fact, the ability to divide the distribution responsibilities for an object’s components into multiple object views is a powerful feature. One use of multiple object views is for prioritizing gameobject state related to movement. Because of its visual importance, movementrelated object state is usually distributed at a higher priority than any other object state. When the Distributed-object system creates or selects the object views for a game object, it utilizes a priority associated with each view to determine the initial order in which the object view set will be processed. By giving movementrelated components their own object view and giving movementrelated object views highest priority, movementrelated information for all of the objects in the relevant set can be distributed first.

Object views are also natural places to handle prediction. In addition, managing movement prediction in the object view makes it possible to utilize different predictive contracts for clients with differing connection characteristics. For example, you could utilize a prediction technique for a client on a modem connection that was completely different from one with a broadband connection simply by selecting the appropriate type of object view when one needs to be created.

Name that tuning. Previously I mentioned that one of the reasons that we want our Distributed-object system to manage distribution of our state data was because of our need to design a system that would let us easily specify how we want our game objects to be distributed. Applying distribution attributes to the data is necessary if we are to help tune how object state is distributed at run time. Tuning is a critical responsibility that is shared between the relevantset mechanism and the Distributed-object system.

To try to maintain a steady flow of traffic through the network, a measured allotment of bandwidth is calculated for each cycle. If a cycle exceeds its allotment, that affects the bandwidth allotment for the next cycle. When allotments are exceeded, the relevantset mechanism must trim the set of objects to those that it determines are the most urgent to distribute. If the relevantset mechanism undercompensates (that is, provides an excess of objects to distribute) for the available bandwidth on that cycle, the tuning support mechanisms of the Distributed-object system and object views come into play. This also holds true when bandwidth is being underutilized. In this way, the two systems work together continuously to make optimal use of bandwidth.

The ability to tune how an object’s state is distributed at run time is very important. By providing some specific information about how we want each game object to be distributed, we should be able to tune the system for optimal distribution. Here are some useful attributes that an object view can use for tuning how individual components, or groups of components, are distributed:

• Priority. A distribution priority can be set for each component item to designate which items are more important to distribute. When an object view is faced with needing to reduce the amount of bandwidth being consumed, it can select from the highestpriority items. As long as the object remains in the relevant set, lowerpriority items will eventually be distributed during later cycles.
  
• Reliability.The ability to specify whether or not a component item’s state should be distributed reliably (guaranteed) or if it can be distributed unreliably (not guaranteed), is a significant tuning option. When eligible for distribution, unreliable items will only need to be sent once. Delivery of the state update is never confirmed, so item state will not be present in case of a delivery failure. This attribute can have a great impact on over all bandwidth utilization in times of significant packet loss, but it must be used carefully. It is typically used for items that change very frequently and when a missed update has minimal impact. An object view could also choose to set the reliability attribute conditionally at run time.
  
• Group. Some component items will need to be distributed as a unit with others. The group attribute specifies that on a given cycle, unless all the member items of the group can be distributed, none should be distributed.
  
• Direction. For object views that support bidirectional state updates, the direction attribute can ensure that an object view only works in one direction. For example, the object view for a player object might need to be bidirectional when it connects to the client represented by that object, but unidirectional when distributing state belonging to a “foreign” player representing a different client. This can also be a security consideration on a server, preventing hacked clients from using bidirectional object views illegitimately.
  
• Initialization only. Components such as object IDs that will not change during the lifetime of the object can be tagged with the initializationonly attribute. After the initial distribution, these items will not need to be tracked by the object view, resulting in greater processing efficiency. You should also provide a declarative means of assigning attributes to the distributed components of the game object.

Ideally, this is part of the definition of the game object itself. A custom scripting language capable of defining game objects can build distributionattribute assignments directly into the language itself. UnrealScript, for example, provides a replication statement, where deliveryrelated attributes can be specified for individual items of the class. In our own implementation, these attributes are assigned when the game object is defined using an internal compilation tool that generates source code for both the game object and its object views. Where dragons dwell.Until a reliable transport protocol with predictable delivery is available over the Internet, simulations with timecritical delivery requirements will continue to use unreliable protocols, such as User Datagram Protocol (UDP).

Many complications can arise when object state is distributed using unreliable communications. Ideally, we want to use our limited bandwidth for transmitting only the most recent state of our game objects. Retransmission, due to packet loss, of old packets containing old state is a very poor way to solve the problem. Here too, object views have proved to be a very useful tool. In addition to their componenttracking responsibilities, they can also keep track of the success — or failure — of the delivery of state information to their remote counterparts. How do they do this? I’ll leave the answer as an exercise for a rainyday.

The View,the Proud ...

In this article, I’ve discussed how object views can be utilized as part of a distributed-object system to help encapsulate management of the distribution of object state. We also looked at how they can be used in the implementation of a Distributed-object system. At Monolith, we have found object views to be a very valuable tool in the implementation of our own Distributed-object system. Object views have provided us with an extraordinary amount of flexibility, allowing us to create simpleyet elegant solutions to a variety of the problems we needed to solve.

________________________________________________________

[Back To] Net Profit, Net Loss

join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2002 CMP Media LLC. All rights reserved.
privacy policy | terms of service