Darkstar

Darkstar

Darkstar is a Sun research project on massively parallel online games

The objective (not yet demonstrated!) is to supply a framework for massively parallel online games that scale into the tens or hundreds of thousands of simultaneous users

Open source, free implementationSun would like to sell the servers and

server sites to run these games

What it is Not

We’ve been talking about game protocols so far. Protocols are responsible for exchanging state change information between hosts. But this says nothing about how the information is maintained on a host once it arrives

For example, a DIS ESPDU might send information about an M1A2 tank moving to another host. But that host is responsible for maintaining information about that entity once it arrives, which is completely outside the domain of DIS

What it is Not

Software on a host is often also responsible for doing graphics. Darkstar is silent about this as well. Likewise game scripting and other classic game engine tasks

You could combine Darkstar with Delta3D and DIS or HLA

What it Does

Darkstar is responsible for keeping track of game state on a central server (or server cluster) It is very strongly tied to a server-based model for games, vs. a peer-to-peer model in which state is distributed across many hosts

Darkstar is an “application server” for games that maintains game state in a centralized repository. It is intended to be low-latency and highly scalable

Conventional Server Architecture

Classically designers scale MMOGs on the server side by dividing up the game space into regions, and assign a server to each region

S1

S2

S3

S4

Convetional Architectures

This is sometimes called “sharding”. Each server maintains the state information for that region. There are some problems with this

• What if everyone decides to move into one square?

• It takes a lot of server resources--you need to provision regions with servers even if no one is there at the time

• Harder to interact with someone not in your server region

Used in Second Life, many others

Darkstar

Darkstar takes a somewhat different approach. • Persistent object state is kept in a centralized database. • User transactions come in from clients; the server

retrieves persistent (managed) objects from the store, performs operations on them, then if changed writes them back

• Can also have server-side tasks that operate on persistent objects (dead reckoning, periodic tasks, etc.)

• Server operations are transaction oriented; if they fail, or take too long, the transaction can be rolled back

Server operations are given a limited amount of time to perform an operation; if this time is exceeded, the operation fails and is rolled back

Darkstar

This means that • We can scale the number of servers by simply

adding more, so long as we can read and write from our data store quickly enough

• Don’t need shards• Data sharing is achieved via the common persistent

store• Game logic is the same as a single nodeWriting a high performance data store and persistent

object system is critical to success. This has not been demonstrated yet. But SQL databases have exhibited very high transaction rates, so it may be possible

Darkstar Model

Client

Client

Client

Server(s)PersistentObjectStore

Server(s)

Darkstar

Darkstar is not a complete server-side solution. It’s a framework for writing one

Example: client updates tank position. Sends request to server, server retrieves persistent tank object and locks it. Performs update and writes data back to persistent store

If another client tries to modify the tank state during this process, the lock will prevent concurrent changes

Concurreny is solved by making object modification guaranteed to be sequential

Complete game can shut down in a power failure, then be restarted in the same state

Applications

Project Wonderland: Sun social virtual world project using X3D for graphics

Project Snowman: snowball throwing game