1. Darkstar

2. 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 implementation Sun would like to sell the servers and server sites to run these games

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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 node Writing 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

10. Darkstar Model Client Server(s) Persistent Object Store Server(s)

11. 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

12. Applications Project Wonderland: Sun social virtual world project using X3D for graphics Project Snowman: snowball throwing game