|
A full room of about 120 people attended the “Designing an MMORPG with
Project Darkstar” session with Sun’s engaging and multi-talented Jeffrey Kesselman, who I have the pleasure of knowing from a previous interview.
Kesselman has a long history in the game industry -- after coming to
Sun, he saw how Sun’s core competencies could be used to make life
easier for game developers. Jeff's title is “Chief Instigator” for Project Darkstar,
which reflects not only the culture, but the intrinsic nature of
computer games – they are “instigations”, meant to provoke, to demand a
response, to get in your face and force you to interact. Project
Darkstar is Sun Labs’ open-source Java-based infrastructure software
designed for latency-critical, massively scaled online applications --
such as online games. The idea is to reduce development costs and
radically enhance the technical challenges that have confronted
developers of MMORPGs which, for the uninitiated, stands for “Massively
Multiplayer Online RolePlay Games”.
Sun’s interest is as follows: Computer games rank second only to movies as a source of entertainment in the industrialized world, so the market is vast and growing. Big online games serve millions of subscribers and run on thousands of servers. It costs somewhere from $20-$30 million to create the basics for an MMORPG. By substantially reducing development costs through Project Darkstar, more games will be created – and more of Sun’s servers and services will be needed. “Sun,” explained Kesselman, “is looking for the places where the need for computers is growing faster than Moore’s law. If it’s growing slower, those spaces will need fewer computers than are needed today because computers are growing more powerful. If a space is growing faster than Moore’s law, they will need more computers, and Sun will benefit as a computer company.” The ultimate challenge of MMORPGs is to engage players from a variety of locations on mobile, set-tops, and PCs, reduce investment costs so that all developers can participate in game creation, and create an explosion of niche content through Project Darkstar. Java technology’s interoperability thus serves games well. Through Darkstar, the technical challenges of scaling, load balancing, data consistency, and failure recovery currently in play in creating MMORPGs will be radically reduced or even eliminated. Jeff is currently writing a book, “Writing Massively Multiplayer Online Games with Project Darkstar” (with Dan Templeton, Strategic Liaison Manager, Sun Grid Engine, at Sun) to help game developers improve their lot. For those who, like me, find it challenging to keep the technical terms of MMORPG creation straight, here’s a basic vocabulary, along with their relevance to Project Darkstar: Dupe (duplication) bug: When an object in a game is in two places at once, in effect duplicating itself. A ball may simultaneously be on the floor and on the table. Dupe bugs reflect breakdowns in referential integrity and occur when back-end systems are not transactional. Project Darkstar is built on a transactional event-processing system that helps prevent dupe bugs. Rollback: Current multiplayer online games hold the state of the game in active memory. A rollback is what happens when a game application fails during a game, losing that state and causing players to lose some of their past play, so they are rolled back to an earlier stage of a game or to the very beginning. With Project Darkstar, the entire virtual world persists to permanent storage in a server-side data store, so that your game state isn't lost when a server fails. Disaster: Worse than a mere failure that causes a rollback, a disaster occurs when the entire machine room goes down. Darkstar's database back end saves a historically accurate record of the game so that at most one or two seconds may be lost. Note: Disaster is a term with general application in computer science. Lag, laggy: Any delay after the user takes an action with an input device, such as a mouse or keyboard, before the effect is observed on the screen and/or through in-game sound effects. Zone: A given area of a virtual world, such as the town of Bar or the forest of Foo. A zone is a play space. All players in a zone can potentially interact with everyone in that zone. Those outside of the zone cannot. Often, different zones are placed on different physical computers in the machine room, called zone servers. Shard: One cluster of zone servers that together describe a complete game world. In order to support large numbers of users, game developers today will replicate the entire world in many different shards. When a player starts a new character, they need to select what is called a server, which is really a cluster of servers, on which they will play with that character. Each of these so-called servers is really a shard, and characters on different shards can't play together. Project Darkstar makes possible shardless worlds, in which all players can interact with each other. Project Darkstar aims to eliminate the bad stuff, so no more dupe bugs, rollbacks, disasters or lags – all of which have been known to seriously damage otherwise promising games. At the heart of the Darkstar solution is the SGS (Sun Game Server) coding model which presents a simple single-threaded event-driven programming model to the developer so that their code will never fail due to interactions between code handling different events. The idea is to make server-side game code reliable, scalable, persistent, and fault-tolerant in a transparent manner. The specific architecture of the SGS, in terms of design, is much like a 3-tier enterprise system: Tier 1: Communications Layer Publish/subscribe channels and direct client/server packets Analogous to the “edge tier” Tier 2: Execution Kernel Executes “tasks” in response to “events” Analogous to a Java 2 Platform, Enterprise Edition (J2EE platform app server Tier 3: Object Store Lightening fast, highly scalable access to persistent objects Analogous to the DB tier However, in execution it’s very different: Tier 1: Communication Reliable/unreliable ordered/unordered byte packet transport Pluggable transports Optimized for lowest worst case latency Tier 2: Execution Persistence of objects is ubiquitous and transparent (mostly) Tasks are apparently mono-threaded Objects are very simple, mostly normal Java 2 Platform, Standard Edition (J2SE™ platform) Stateless Optimized for lowest worst case latency Tier 3: Object Store All application state lives here Custom in-memory data-store with secondary storage backup Transactional and fault-tolerant but not relational Deadlock detection for tier 2 Built to scale massively Optimized for lowest worst case latencies Kesselman did a deep dive into the coding model, applying it to real game implementation in DarkMMO, an open source Project Darkstar-based Massive Multiplayer Online engine that he plans to release to the open source community roughly six to eight weeks after JavaOne. He invited developers to take a peek at the code. He closed with a cool DarkMUD demo that was fun to watch that drew on artwork from the commercial game Neverwinter Nights. It was great to see Jeff Kesselman again. Anyone interested in developing online games should watch the session online and pick up the nuanced and refined development path involved in Project Darkstar. See Also: Project Darkstar Project Darkstar Downloads Jeff Kesselman’s Blog Java Game Developer Community 2008 JavaOne Janice J. Heiss |
|
|
