Slashdot Mirror
Building Scaleable Middleware for MMORPGs
CowboyRobot writes "ACM Queue has an article exploring the challenges of developing a reliable platform for an MMORPG, specifically looking at Wish by Mutable Realms. From the article: 'A common scalability problem for distributed multiplayer games relates to managing distributed sets of objects... A player may not be a member of more than one guild, or a guild may have at most one level-5 mage (magician). In computing terms, implementing such behavior boils down to performing membership tests on sets of distributed objects.'"
Surely this is a classic example of the Manager pattern. You have a bunch of objects [Avatar] (all alike, at least programmatically
The trade-off in terms of scalability is in frequency versus computation. If the operation is commonplace (such as moving around), then a distributed system has a problem. If the operation is not commonplace (such as joining a guild!) then it's painless to use the 'choke' of a manager class to resolve any issues.
Even in the commonplace situation, I would have thought it useful to use overseer-objects whose job it is to remove the extra (unnecessary) information from the problem before trying to solve it... There's no need to care about the avatar in sector (-1000,-1000) if we're currently in sector (0,0)...
It's a cliche, but the rule is 'divide and conquer'. Screaming and leaping is a satisfactory, but usually fatal approach to problem solving, unless you're Kzin.
Simon
Physicists get Hadrons!
I've tried a few MMORPGs and have found them all to be lacking in the same key area: one's control over one's character is not real-time. This is a generic description of a problem which surfaces in many ways in MMORPGs, most notably in the combat system. I haven't found one yet that allows real-time combat; it's always "click on the guy you want to fight and press the 'attack' button", then sit back and watch. Typically can do things like cast a spell or use a buff or otherwise make strategic changes to the way that your character is fighting, but you can't aim, run around, swing at the monster, etc, as you can with first person games.
...
The game that comes closest to the combat system I would want is Jedi Academy, in which the multiplayer mode works just like the first-person real-time perspective of the single player game. You do have to aim, you do have to run around and avoid shots, you do have to swing your light saber yourself. I find this to be infinitely more enjoyable than the MUD-like "you hit the spider for 10 points, it hit you for 5 points" back-and-forth that is common on all of the MMORPGs that I have played.
One gets the feeling in playing these MMORPGs that your client view of the world only loosely approximates what is happening on the server. You can make your character run from here to there and find that other people are "sliding" by or popping in and out as you get only sporadic notification from the server of what's really happening. It all gives a very disconnected feel that I really find unappealing about MMORPGs.
There must be some kind of scaleability limitation though because Jedi Academy only supports about 30 players or so at a time in an area that is far smaller than a play area in an MMORPG. I think that if someone could design an MMORPG that played like an FPS, but had all of the depth and breadth of one of these not-so-real-time MMORPGs, it would be ideal.
As an aside, has anyone beta tested Worlds of Warcraft? It like an excellent execution of the MMORPG genre, but I have yet to read any comments from beta testers on whether or not the fighting is real-time or "faked" like other MMORPGs is
They say:
Wish is the first Ultra Massive Multiplayer Online Role Playing Game (UMMORPG(TM)). "Ultra" means that Wish supports more than 10,000 simultanous players in a single, seamless world, without any zones or "shards".
In EQ you can have an effect on other characters in your zone (say a hundred people) but you can talk with all the other people on your server (thousands, maybe tens of thousands of people). This is a limitation, but in practical terms it works OK. I don't actually need to interact with more than a few people at a time.
Read Epic the first RPG novel.
You make major one major, major sacrifice for so many simultaenously players in Wish. Movement is point and click. It feels like you're playing a strategy game rather than living in a real world. Those of you complaining that you can't joust and dodge in today's MMOs will hate the stilted movement mechanism of Wish, where the path you take is left to a pathing routine.
"At ZeroC we used Java because some of our development staff had little prior C++ experience..."
"...however, a few of us had previously built a commercial object request broker..."
"...designing and implementing middleware is difficult and costly, even with many years of experience. If you are looking for middleware, chances are that you will be better off buying it than building it."
Frankly, I'd feel rather uncomfortable using ICE 1.0 as middleware for my new MMORPG. Yes they could succeed and do a nice job, but that rarely happens especially in the world of MMOs where nearly all games are released way too early in beta form.
The RP in MMPORG means Role Playing ala Dungeons and Dragons. Thus, the focus is on character development, not first person shooter style twitch. RPGs are based on a dice game, and is really about mathematics. The people with powerful characters are the ones who can do math, not the once with a cable modem in the same town as the server.
* P4 2.0GHz; P4 2.8GHz recommended (or Athlon equivalent).
* 512MB RAM; 1GB recommended.
* 64MB DX 9.0 Video Card (GeForce 3/4 Ti; ATI 8500+); 128 MB GeForce FX or Radeon 9600+ recommended.
* 16bit Sound Card; 24bit recommended.
* 8 GB free disk space; 7200+ RPM recommended.
* Connection to the Internet; 33 Kbps modem minimum; broadband recommended.
In the Portland, Ore area and like card games? Check out: http://groups.yahoo.com/group/portlandgames/
and here's the solution:
- Don't buy the game (it's cheaper that way)
- Don't play the game (you can't get spammed/cheated if you're not a player)
- Don't install the game (you'll save lots of resources this way)
- Dont' wait for it to come out (you can spend the time with your loved ones or go on a hike)
Shalom
one's control over one's character is not real-time.
If you've attended GDC then you may have played ZonaBattle, a real-time mechanized battlecar demo game for the Terazona MMOG system. Disclaimer: I work for Shanda Zona, the developer of this MMOG architecture, and my views may not represent those of the company, etcetera.
The purpose of the ZonaBattle technology demo is to illustrate that MMOGs do not have rely on sluggish, pseudo-turn-based gameplay. Using the right architecture produces excellent results.
ZonaBattle is not as fluid as some FPS games, but it is peppy and, unlike peer-based FPS games with~64-138 players, Terazona's client-server design enables you to scale the playfield to several tens of thousands of players and those players will experience no increased lag or message bottleneck.
Of course, you can also use Terazona to build "classic" seamless MMOGs. Terazona games do not have to have zones or "shards" and feature a heuristic, autoconfiguring grid system for game servers with dynamic region ownership, environmental simulation, and load balancing. You want more performance to support more players or more complex environment? Just slap in a few more commodity servers, or racks. The game will integrate them automatically and immediately begin dispersing Players and Entities among them.
Players can also exchange state with other local or non-local Entities using various bandwidth- and set-based configurable channels. This is not as easy as it might first appear.
Finally, the entire Server-side system is Java-based, for maximum flexibility and cross-platform support.
Da Blog
I came across this quote:
At ZeroC we used Java because some of our development staff had little prior C++ experience.
and immediately though of that Dilbert strip (sorry, no link) mocking the "if all you have is a hammer, every problem looks like a nail" saying. That strip was particularly memmorable to me because the last panel featured a porcupine saying "we must stick them with quills! it's the only way!"
I browse Slashdot at +3, Funny
I really think computing power is less significant than the overall game development design when it comes to MMORPGs. After design, bandwidth becomes a factor, and only then is computing power a factor. The only exception I can think of would be requiring power for encryption/decryption.
The notion of parsing datasets for something like guild membership is really trivial. If you want to design a solid MMORPG, it's going to come down to how the world, objects and players are represented.
I continue to be in awe of the capabilities of games like Everquest and SWG. SOE has really created a very robust MMORPG technology -- it's hard for any other game developer to really say they have anything comparable when they can't demonstrate superior performance under the same conditions due to no other MMORPG having anywhere near the quantity of simultaneous players (as Everquest).
IMO, the client side of EQ is pretty straightforward. What makes the game special is the server side and how they manage to manipulate so many players and objects in real time. People complain that too many objects/players per "zone" can lag things down, and that is true, but I have yet to see a better implementation than Everquest. SWG has done away with the concept of "zones" to some degree, but basically, they seem to have implemented some client-side intelligence to indicate at which point additional graphics and information on objects in the distance should be loaded or reported. There are still "zones" in all these games. Some of them implement noticeable loading lags, and others don't.
My outside impression of the technical layout of Everquest is something like this... and I'd love anyone with more info/insight to correct me or elaborate further. I ASSume their system is made up of racks of servers, running Solaris I think. The have some low-level, propietary engine that manages the objects in the world, probably to a back-end database like Oracle. The reason for zones in EQ is that when you enter a new zone, you may actually be switching from one physical server to another. Not only do they have different servers for different shards/worlds, but different servers for different zones. When I see a system message such as, "North Karana, Velketors and Plane of Mischief going down for a brief update", I think that perhaps that's one server they're rebooting, which runs those particular zones. I suspect they stagger high-traffic zones with low-traffic zones on servers, and occasionally when the X number of zones managed by a single server have an unusually high amount of traffic/visitors, you get lag.
What's interesting about MMORPG game design is the balance between handling as much client-side as possible without creating security issues. If the server keeps track of players, NPCs and objects, it's much more difficult for someone to hack, or at least, logs are available to identify issues. The more client-side processing done, the more likely the game can be inappropriately manipulated.
When you take into account the amount of real-time data that goes back and forth, EQ (and SWG) are quite impressive. I don't think database/dataset issues are really the problem as being able to efficiently encapsulate, protect and send/receive the large amounts of data in the real-time world.
You lost me at the "java-based" though
And oh yeah, only the Servers run Java only. The Client-side API is language-agnostic and platform-agnostic. So you can write Clients in C++ or Java and compile them to Win32, XBox, PS2, GameCube. The Servers don't care which Client belongs to which platform.
The analogy I like to use is NTSC. In the early days of TV without NTSC you had no guarantee that your GE TVs would be able to pick up Motorola format broadcasts. TVs competed within closed markets and featured lock-in. Creating a common broadcast standard enabled all TVs to pick up all broadcasts. TVs could compete on quality anf fucntionality, and broadcasters could compete using content. Using a platform-agnostic MMOG Middleware lets you enjoy economies of scale because your Servers communicate with all kinds of Clients. Client experiences vary, of course, according to display resolution and frame rate ability.
Da Blog
You can find a PDF version of the full article (exactly as printed in the magazine) here.
Cheers,
Michi.