U2NhbGluZyBpbiBHYW1lcyAmIFZpcnR1YWwgV29ybGRzICAg

"Online games and virtual worlds have familiar scaling requirements, but don’t be fooled: everything you know is wrong." Jim Waldo, Sun Microsystems Laboratories

* The computational environment for online games or virtual worlds is close to the exact inverse of that found in most markets serviced by the high-tech industry.
* The need for a heavyweight client is, in part, an outcome of the evolution of these games.
* Latency is the enemy of fun—and therefore the enemy of online games and virtual worlds.
* The game server is used both to discourage cheating (by making it much more difficult) and to detect cheating (by seeing patterns of divergence between the game state reported by the client and the game state held by the server). Peer-to-peer technologies might seem a natural fit for the first role of the game server, but this second role means that few if any games or worlds trust their peers enough to avoid the server component.
* Using multiple servers is a basic mechanism for scaling the server component of a game to the levels that are being seen in the online world today.
* Having multiple servers means that part of building the game is deciding how to partition the load over these servers.  The first technique is to exploit the geography of the game or world. The second technique is known as sharding.
* While shards allow scale, they do so at the price of player interaction.
* The problem is that the culture that has grown up around games and virtual worlds is not one that understands or is overly familiar with the programming techniques that are required to exploit the parallelism inherent in these systems.

* It is for these reasons that we started Project Darkstar (http://www.projectdarkstar.com), a research effort attempting to build a server-side infrastructure that will exploit the multithreaded, multicore chips being produced and scaled over a large group of machines, while presenting the programmer with the illusion that he or she is developing in a single-threaded, single-machine environment.
*The model is a simple event-based one in which input from the client is received by the server, which then sets off a task in response to that event.
* This mechanism for concurrency control does require that all tasks access all of their data through the Darkstar data service. Our current implementation uses the Berkeley Database. we believe that we can keep the penalty for accessing through a data service small by caching data in intelligent ways. We also believe that by using the inherent parallelism in these games, we can increase the overall performance of the game as the number of players increases, even if there is a small penalty for individual data access.
* We found that additional machines lowered the capacity of the overall system. We are working on removing the choke points so that adding equipment actually adds capacity.