Gamasutra: The Art & Business of Making Gamesspacer
1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond
View All     RSS
August 17, 2018
arrowPress Releases
August 17, 2018
Games Press
View All     RSS
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond

March 22, 2001 Article Start Previous Page 3 of 4 Next

RTS3 Multiplayer: Goals

RTS3 is the codename for Ensemble's next-generation strategy game. The RTS3 design builds on the successful formula used in the Age of Empires series games, and calls for a number of new features and multiplayer requirements.

  • Builds on the feature set of Age of Empires 1 and 2. Design requirements such as internet play, large diverse maps, and thousands of controllable units are a given.
  • 3D -- RTS3 is a fully 3D game, with interpolated animation and non-faceted unit position and rotation.
  • More players -- possible support for more than eight players.
  • TCP/IP support -- 56k TCP/IP internet connection is our primary target.
  • Home network support -- Support end-user home network configurations including firewalls and NAT setups.

With RTS3, we made the decision early on to go with the same underlying network model as Age of Empires 1 and 2 -- the synchronous simulation -- because the RTS3 design played to the strengths of this architecture in the same ways. With AOE/AOK, we relied on DirectPlay for transport and session management services, but for RTS3 we decided to create a core network library, using only the most basic socket routines as our foundation and building from there.

The move to a fully 3D world meant that we had to be more sensitive to issues of frame-rate and overall simulation smoothness in multiplayer. However, it also meant that our simulation update times and frame-rate would be even more prone to variation, and that we would be devoting more time overall to rendering. In the Genie engine, unit rotations were faceted and animations were frame-rate locked -- with BANG! we allowed for arbitrary unit rotation and smooth animation which meant that the game would be visually much more sensitive to the effects of latency and see-sawing update rates.

Coming out of development on Age of Kings, we wanted to address those critical areas where more up-front design and tool-set work would give the biggest payoff in terms of debugging time. We also realized how important the iterative play-testing process was to the design of our games, and so bringing the multiplayer game online as early as possible was high priority.

RTS3 Communications Architecture

Figure 6. RTS3's strongly object-oriented network architecture.

An OO approach. RTS3's network architecture is strongly object oriented (see Figure 6). The requirements of supporting multiple network configurations really played to the strengths of OO design in abstracting out the specifics of platform, protocol, and topology behind a set of common objects and systems.

The protocol specific and topology specific versions of the network objects have as little code as possible. The bulk of the functionality for these objects has been isolated in the higher-level parent objects. To implement a new protocol, we extend only those network objects that need to have protocol specific code (such as client and session, which need to do some things different based on the protocol). None of the other objects in the system (such as Channels, TimeSync, etc.) need change because they interface with client and session only through their high level abstract interfaces.

We also employ the use of aggregation to implement multi-dimensional derivation (such as with channels, that have an ordered/non-ordered axis of derivation, as well as a peer/repeater axis of derivation) behind a single generic interface. Virtual methods are also used for non-intensive notifications, rather than using callback functions.

Peer topology. The Genie engine supported a peer-to-peer network topology, in which all clients in the session connect to all the other clients in a star configuration. With RTS3 we have continued the use this topology because of its inherent benefits when applied to the synchronous simulation model.

The peer topology implies a star configuration of connected clients in a session (Figure 7). That is, all clients connect to all other clients. This is the setup that Age 1 and 2 utilized.

Figure 7. A "star" configuration of peer-to-peer clients in a session.

Peer-to-peer strengths:

  • Reduced latency due to the direct client-client nature of the system, rather than a client-server-client roundtrip for messages.
  • No central point of failure -- if a client (even the host) disconnects from the session, the game can continue.

Peer-to-peer weaknesses:

  • More active connections in the system (Summation n=0 to k-1 (n)) -- means more potential failure points and latency potential.
  • Impossible to support some NAT configurations with this approach.

Net.lib. Our goal when designing the RTS3 communications architecture was to create a system that was tailored for strategy games, but at the same time we wanted to build something that could be used for in-house tools and extended to support our future games. To meet this goal, we created a layered architecture that supports game-level objects such as a client and a session, but also supports lower level transport objects such as a link or a network address.

Figure 8. The four service layers of the network model.

RTS3 is built upon our next-generation BANG! engine, which uses a modular architecture with component libraries such as sound, rendering, and networking. The network subsystem fits in here as a component that links with the BANG! engine (as well as various in-house tools). Our network model is divided up into four service layers that look almost, but not entirely, unlike the OSI Network Model, if you applied it to games (see Figure 8).

Socks, Level 1

The first level, Socks, provides the fundamental socket level C API, and is abstracted to provide a common set of low level network routines on a variety of operating systems. The interface resembles that of Berkley sockets. The Socks level is primarily used by the higher levels of the network library, and not really intended to be used by the application code.

Link, Level 2

Level 2, the Link Level, offers transport layer services. The objects in this level, such as the Link, Listener, NetworkAddress, and Packet represent the useful elements needed to establish a connection and send some messages across it (see Figure 9).

  • Packet: This is our fundamental message structure -- an extensible object that automatically manages its own serialization/de-serialization (via pure virtual methods) when sent across a link object.
  • Link: a connection between two network endpoints. This can also be a loopback link, in which case the endpoints both reside on the same machine. Send and receive methods on a link know how to operate with Packets and also with void* data buffers.
  • Listener: a link generator. This object listens for incoming connections, and spawns a link when a connection is established.
  • Data stream: this is an arbitrary meter-able data stream across a given link -- used to implement file transfer, for example.
  • Net Address: a protocol independent network addressing object
  • Ping: a simple ping class. Reports on the network latency present in a given link.
  • Figure 9. The Link level.

Multiplayer, Level 3

The multiplayer level is the highest level of objects and routines available in the net.lib API. This is the layer that RTS3 interfaces with as it collects lower level objects, such as links, into more useful concepts/objects such as clients and sessions.

The most interesting objects in the BANG! network library are probably those that live at the multiplayer level. Here, the API presents a set of objects that the game level interacts with, and yet we maintain a game-independent approach in the implementation.

  • Client: this is the most basic abstraction of a network endpoint. This can be configured as a remote client (link) or local client (loopback link). Clients are not created directly, but are instead spawned by a session object.
  • Session: this is the object responsible for the creation, connection negotiation, collection and management of clients. The session contains all the other multiplayer-level objects. To use this object, the application simply calls host() or join(), giving it either a local address, or remote address respectively and the session handles the rest. These responsibilities include automatically creating/deleting clients, notification of session events, and the dispatch of traffic to the appropriate objects.
  • Channel and Ordered Channel: this object represents a virtual message conduit. Messages sent across a channel will be automatically separated out and received on the corresponding channel object on remote clients. An ordered channel works with the TimeSync object to guarantee that the ordering of messages received on that channel will be identical on all clients.
  • Shared Data: Represents a collection of data shared across all clients. You extend this object to create specific instances that contain your own data types, and then use the built in methods to enable the automatic and synchronous updating of these data elements across the network.
  • Time Sync: Manages the smooth progression of synchronized network time across all clients in a session.

Game Communications, Level 4

The communications level is the RTS3 side of things. This is the main collection of systems through which the game interfaces with the network library, and it actually lives within the game code itself. The communications layer provides a plethora of useful utility functions for the creation and management of multiplayer-level network objects and attempts to boil down the game's multiplayer needs into a small easy to use interface.

Article Start Previous Page 3 of 4 Next

Related Jobs

Game Closure
Game Closure — Mountain View, California, United States

Senior Game Engineer (HTML5)
Boss Fight Entertainment
Boss Fight Entertainment — Allen, Texas, United States

Senior Server Engineer
Baidu USA
Baidu USA — Sunnyvale , California, United States

3D Tools Software Engineer
Defiant Studios
Defiant Studios — New York, New York, United States

Lead Engine Programmer

Loading Comments

loader image