Project Darkstar Game Architecture

How Project Darkstar Works

August 30, 2007 - Each node in a Project Darkstar Server cluster runs a copy of the game logic code on top of the Project Darkstar stack, which is presented to the game server as a set of services:

• Tasking Service: schedules tasks and runs them
• Data Service: controls the persistent state of the game
• Channel and Session Service: establishes and manages communication between games or between players

With the Project Darkstar model, tasks are always performed in a transaction. This allows the concurrency control to be made transparent to the game programmer. When a task requires access to an object that is currently locked by another task, the transaction in which the task is wrapped simply aborts and is re-scheduled to be run (slightly) later. The transactional nature of the tasks also ensures that there is a serial order that can be established between tasks that are causally related.

Scaling is possible on a single node through the use of multiple threads, which are controlled by the Tasking Service. Additional scaling is made possible by allowing multiple nodes (which may be either an actual machine or a virtualized machine) to cooperatively run the same game. This is enabled by the Data Service and the Channel Service, which insure that any task run in the Darkstar environment can be run on any machine and still have the same result. While the multi-node capability is not part of the current open source release of Project Darkstar Server, the technology is proven and Sun intends to offer it in subsequent releases.

All game objects that exist longer than a single task need to be created and kept in the data store. Tasks must read any of these objects during the task to ensure that they are working with the most recent state of the object. The data store is backed by a database; in the current implementation Project Darkstar Server uses the Berkeley Database, both for its performance and because it is available as open source software. However, the interface between the Data Service and the database allows other databases, such as Postgres or SQL, to be used as well.

Communication between the server and clients uses the Session Service, which provides a low-latency direct communication between the game client and the game server. Sessions are established when a client logs in to a game, and are maintained until the client logs out. Communication between clients and other clients is accomplished through the Channel Service, which provides a publish/ subscribe style communication mechanism. Clients join a channel, and any member of a channel receives all of the communications sent on that channel. Both Sessions and channels are an abstraction over the basic communication mechanisms provided by the underlying operating system, allowing a channel to be moved from one machine to another without impacting users.

Project Darkstar Server is written in Java, and the use of Java makes it possible to load code at run-time and integrate it into a process seamlessly through “late-binding” (similar to a classic Dynamically Linked Library or DLL but much more flexible). This facility has enabled the Project Darkstar team to create an architecture that is pluggable on many levels without having to resort to multiple processes and IPC. In addition, the pervasive use of Java technology can help developers create games that are truly client-agnostic, so they can broaden the market for their games.

Providing Load Balancing on the Fly

The use of the data store, combined with the portability of channels, means that any task can be run on any machine without changing the effect of the task. This in turn means that load can be transferred from one machine to another, and capacity can be increased or reduced on the fly by simply adding more machines to the set of nodes that are running the game.

In addition, there are meta-services within the Project Darkstar Server infrastructure that will dynamically move tasks to ensure locality of data access and communication.

The base service of Project Darkstar Server can be enhanced by third parties. New services can be introduced that participate in the work done by tasks. These services can interact with the transactional mechanisms and observe the overall system using the meta-services. For example, it would be possible to add access to a fully relational database that could keep track of game statistics, allow queries of those statistics, and expand the management of the game without requiring that information be stored in the data store, which can then be optimized for the kinds of access needed by games.