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.'"
The issue here is you are looking at MMORPGS. RPGs are traditionally turn based combat. I haven't seen many successful RPGs that required one to actually swing or fire their weapon manually.
There are two massively multiplayer games that feature realtime combat
* Planetside, which is an MMOFPS with RPG characteristics (levelling, improving your character by gaining extra implant slots and additional simultaneous skill sets)
* Neocron, which is an MMORPG/FPS (I may be wrong on this one, it was a while ago and I only played the offline trainer, which was supposed to simulate online play)
One of the biggest issues is lag; to reduce lag, which would get horrendous when there are many people in close promixity doing things, the client-side visual representation and simulation, and the server side simulation are never in sync with each other. The server is the final arbiter, but the client tries to the best of it's ability and available information to provide a visual representation of what is going on.
Planetside (and I assume Neocron) solves the lag issue by moving combat resolution for attacks to the attacker's client, and trusting the client's integrity. As a result, you can easily die 3-4 seconds after running behind cover; likewise you can run through an intersection, be in the clear on your end, yet be shot and killed 5 seconds later as someone sees you go through the gap 3 seconds earlier and shoots you.
- MaineCoon
Hunt your preferred prey at Aliens vs Predator MUD. Join the war at avpmud.com port 4000
Dunno, but I've been playing this Eve Online stuff and it seems pretty realtime to me. And it supports 7500 people at the same time with no lag... And I must say it's pretty fun to play too, if you like space rpg's ;)
Veni, Vidi, Velcro!
Avatar doesn't mean any particular "agent of god" powers in this message. He's using Avatar as the generic word for "the persona that a player plays as".
Looks like some people out there need to review what design patterns are.
from first result:
how does the game world map get distributed amongst the grid servers
/. angle - we support MySQL for persistence, among others. In fact, any RDBMS with JDBC should work. We also support Entity creation, modification, bandwidth optimization using an XML-based schema editor (written in Java, of course). So game programmers don't have to fiddle forever making lots of structs and trying to optimize dirty bitmasks for message delta optimization. This lets you get past the tedious stuff quickly and get to the game logic.
Dynamic ownership, distributed object-view model. Very similar to the system described in Queue. You would never maintain a complete unitary in-memory representation of a world - that sucks up too server juice.
I come from a CORBA background as well - what you see with all this kind of MMOG Middleware (Butterfly, Quazal, There.com, BigWorld) is a classic example of evolutionary convergent adaptation.
I forgot to add a standard
Da Blog
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 can find a PDF version of the full article (exactly as printed in the magazine) here.
Cheers,
Michi.
World War 2 Online has sort-of beat that. It's a MMOG FPS, in essence.
Basically, there is a 64 unit "visibility limit". You're only ever told about 64 units max (and sometimes, due to oddities, less) player entities around you, prioritized among several criteria (distance, threat, minimum friend/foe allocations), etc.
It works fairly well, and the structure of the game is such that you have dozens of 30-60 player battles going on at all times, and can move anywhere around the map as you choose, realtime, either by slogging it on foot, driving, flying, or steering your ship. You can also jump from place to place but leave your equipment behind.
Best estimates put the peak server load at about 3-4000 players, with 500-1000 during the low tide, but the game runs 24/7 on a single arena.
The developers aren't swimming in money, but they're in the black and have recently turned up the data update rates to make it more smooth, so there's evidently some room in the budget for bits.
Disclaimer: I'm a day one player, from June 6 2001 on, aka Krenn, of the 1/16 Panzerdivision "Windhund".