关于诚信的好处:Designing Massively Multiplayer Online Roleplay Games with Project Darkstar : 2008 JavaOne Conference

Designing Massively Multiplayer Online Roleplay Games with Project Darkstar

A full room of about 120 people attended the “Designing an MMORPG withProject 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 toSun, he saw how Sun’s core competencies could be used to make lifeeasier for game developers. Jeff's title is “Chief Instigator” for Project Darkstar,which reflects not only the culture, but the intrinsic nature ofcomputer games – they are “instigations”, meant to provoke, to demand aresponse, to get in your face and force you to interact. ProjectDarkstar is Sun Labs’ open-source Java-based infrastructure softwaredesigned for latency-critical, massively scaled online applications --such as online games. The idea is to reduce development costs andradically enhance the technical challenges that have confronteddevelopers of MMORPGs which, for the uninitiated, stands for “MassivelyMultiplayer Online RolePlay Games”.

Sun’s interest is asfollows: Computer games rank second only to movies as a source ofentertainment in the industrialized world, so the market is vast andgrowing. Big online games serve millions of subscribers and run onthousands of servers. It costs somewhere from $20-$30 million to createthe basics for an MMORPG. By substantially reducing development coststhrough Project Darkstar, more games will be created – and more ofSun’s servers and services will be needed.

“Sun,” explainedKesselman, “is looking for the places where the need for computers isgrowing faster than Moore’s law. If it’s growing slower, those spaceswill need fewer computers than are needed today because computers aregrowing more powerful. If a space is growing faster than Moore’s law,they will need more computers, and Sun will benefit as a computercompany.”

The ultimate challenge of MMORPGs is to engage playersfrom a variety of locations on mobile, set-tops, and PCs, reduceinvestment costs so that all developers can participate in gamecreation, and create an explosion of niche content through ProjectDarkstar. 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 creatingMMORPGs will be radically reduced or even eliminated. Jeff is currentlywriting a book, “Writing Massively Multiplayer Online Games withProject Darkstar” (with Dan Templeton, Strategic Liaison Manager, SunGrid Engine, at Sun) to help game developers improve their lot.

Forthose who, like me, find it challenging to keep the technical terms ofMMORPG creation straight, here’s a basic vocabulary, along with theirrelevance to Project Darkstar:

Dupe (duplication) bug: When anobject in a game is in two places at once, in effect duplicatingitself. A ball may simultaneously be on the floor and on the table.Dupe bugs reflect breakdowns in referential integrity and occur whenback-end systems are not transactional. Project Darkstar is built on atransactional event-processing system that helps prevent dupe bugs.

Rollback:Current multiplayer online games hold the state of the game in activememory. A rollback is what happens when a game application fails duringa game, losing that state and causing players to lose some of theirpast play, so they are rolled back to an earlier stage of a game or tothe very beginning. With Project Darkstar, the entire virtual worldpersists to permanent storage in a server-side data store, so that yourgame state isn't lost when a server fails.

Disaster: Worse thana mere failure that causes a rollback, a disaster occurs when theentire machine room goes down. Darkstar's database back end saves ahistorically accurate record of the game so that at most one or twoseconds may be lost. Note: Disaster is a term with general applicationin computer science.

Lag, laggy: Any delay after the user takesan action with an input device, such as a mouse or keyboard, before theeffect 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 forestof Foo. A zone is a play space. All players in a zone can potentiallyinteract with everyone in that zone. Those outside of the zone cannot.Often, different zones are placed on different physical computers inthe machine room, called zone servers.

Shard: One cluster ofzone servers that together describe a complete game world. In order tosupport large numbers of users, game developers today will replicatethe entire world in many different shards. When a player starts a newcharacter, they need to select what is called a server, which is reallya cluster of servers, on which they will play with that character. Eachof these so-called servers is really a shard, and characters ondifferent shards can't play together. Project Darkstar makes possibleshardless worlds, in which all players can interact with each other.

ProjectDarkstar aims to eliminate the bad stuff, so no more dupe bugs,rollbacks, disasters or lags – all of which have been known toseriously damage otherwise promising games. At the heart of theDarkstar solution is the SGS (Sun Game Server) coding model whichpresents a simple single-threaded event-driven programming model to thedeveloper so that their code will never fail due to interactionsbetween code handling different events. The idea is to make server-sidegame code reliable, scalable, persistent, and fault-tolerant in atransparent 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

Kesselmandid a deep dive into the coding model, applying it to real gameimplementation in DarkMMO, an open source Project Darkstar-basedMassive Multiplayer Online engine that he plans to release to the opensource community roughly six to eight weeks after JavaOne. He inviteddevelopers 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.

Itwas great to see Jeff Kesselman again. Anyone interested in developingonline games should watch the session online and pick up the nuancedand 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