MMO theory
Blitz3D Forums/Blitz3D Programming/MMO theory
| ||
| I just realised I don't know much about massivley multiplayer network architecture. Anyone care to shed some light on the subject of how you handle the networking for something like this at it's most eficient mark? |
| ||
| That's quite a question you're asking there, I wouldn't mind talking over some of the finer details with you... but if you want answers on the forum, it might be wise to make your question a little more specific... There's a great deal of factors involved affecting your protocol, method of data storage, etc. for example security, bandwith cost, size of target playercount, geographical player density ingame, geographical player density in real life, game type, specific specs and capabilities and the list goes on. If I where to write a conclusive reply now I guess I'd be typing for a few days. :P |
| ||
| We'll chat in IRC later! |
| ||
| Well I'll have a shout in here. I would use a divide and conquor approach. Basically for a truely huge network like this to function, the key is to have territories. Each territory has it's own server. The player, when he crosses a territory actually joins another server. This is the server-load problem minimised. Now you have geographic location. Since the server is so fast, each territorial server will simply take people from another geographic location and "mirror" them in this territory. Hence the servers in japan mirror the servers in england. This is the latency problem solved. Now for this to work, you don't need specialised client code. You need standard client code much like what you see in BlitzPlay or Quake. UDP, nice and fast with a reliable packet every so often to keep things sane. But the server is another story. It should operate on two levels: mirroring it's own territory in another country, and shifting players out of it's own territory while accepting players into it's own territory. When either of these actions occur it will begin broadcasting to it's closest mirrored neighbor - for example england to france. France's mirror will pick up on this and broadcast to germany and so on until the player is in the same territory across the world. This will usually happen within 20ms if we're lucky - since servers are on pretty fat pipes. If there's anything you don't understand about what I proposed here, just reply. |
| ||
| How about the mirroring, everything but that seems to be common sense just from playing a few MMO titles. |
| ||
| Interesting idea Rob. Of course, you have to be rich enough to pay for a lot of servers :-) My (currently free) MMO just uses BlitzPlay, and it works fine so far. I should be able to handle quite large amounts of players on only a modest server. What I do is split my game world into Areas. A player in one Area doesn't "know" about players in any other. This keeps bandwidth usage way down. Also I don't worry about perfect synchronisation - so long as something is "about right" it's fine. And I handle as much on the client side as possible. The result - it's currently possible to have 2 players with no lag to speak of over a single 56k connection. And that's with a server which only does 128k upstream and 512k downstream. I haven't had enough players to REALLY strain the thing but I think it should be able to handle a couple of thousand at once without being too slow. In fact the game would slow to a crawl rendering and updating all the players long before the network side of things became annoyingly slow. |
| ||
| For those who may be interested, Jay Lee did a pretty good right-up on Relational Database Guidelines for MMOGs in September. I haven't checked to see if he's written any more works on MMOG theory. Heres the link: http://www.gamasutra.com/resource_guide/20030916/lee_pfv.htm |
| ||
| I have been pondering a Network Architecture concept that would use multple client PC's as Game World Hosts. The goal is to simulate one massive virtual server without the need for a large server farm. At the moment I'm not sure this concept is even feasible, hell, I'm probably waay out in left field with this one:), but, its worth getting feedback on it wether good, bad, indifferent. So here it goes... The Concept Visualize the Game World as a large 1000x1000 Grid (ignore scale for now). This server architecture would be built on a 4 Tier Server Hieararchy: Host -> Master -> Domain -> World. Host Server would manage one square of the game world (upto 16 - 32 players). This server behaves similar to a Multiplayer Arena Server essentially providing communication between players within the area, periodically updating the Master Server of Player/Game world state. Master Servers would manage 100 Host Servers within 10x10 area of the Game World. Masters Servers would be responsible for mirroring, updating, and establishing communication between host and their neighbors. All world events are communicated up to the Domain Server. The Domain Servers would manage 100 Master Servers within area. Domain Servers would provide the same functionality to Master Servers as they do to Host Servers. All world events are communicated up to the World Server. The World Server would manage 100 Domain Servers. The world Server would provide the same functionality to Domains as they do to Master Servers. The world server also issue broadcast to update Servers and Clients. The PROS No need for massive server farm. Load balancing. The CONS The game worlds persistence would be only as reliable as the number of players in the game world. No players - no game world:( |
| ||
| On the other hand, no player - no game world needed. I think that's quite an interesting idea. Also pretty much infinitely scalable. However, I think it'd require your players to have quite beefy connections to handle being servers? Even if only for a small segment of the world. You'd also have to find a way to transfer server-duties when a player left or moved to a different segment of the world. Finally, there'd be more of a security problem - it would be much easier for people to cheat if their PC was acting as a server. |
| ||
| Rottbott, Thanks for the feedback. However, I think it'd require your players to have quite beefy connections to handle being servers? Even if only for a small segment of the world. Yes. Connection speed will determine wether or not a Client PC can participate as a Server. You'd also have to find a way to transfer server-duties when a player left or moved to a different segment of the world. This will be managed by the Tier Server above. For example, Masters Server supervise Host Servers, Domain Server supervise Master Servers, etc. Finally, there'd be more of a security problem - it would be much easier for people to cheat if their PC was acting as a server. Security is a top priority. Although this server functionality is suppose to be transparent to the player, safeguards and detection will have to be in place regardless if the PC is acting as a server. |
| ||
| OK, sounds like you have most of the potential problems worked out. It would certainly be a cheap way to run a huge game - you'd only really need to pay for one server (World server), and not even an especially super-fast one either. Perhaps one of us bedroom programmers could even run a successful MMORPG without having to pay huge server costs. I like the idea. About security: I was thinking more along the lines of people being able to use packet sniffers to work out your packet formats, and then make artificial packets which would allow them to cheat. Of course that problem is always present, but I think it would be worse if the person's PC was acting as a server. Also, wouldn't you get sudden jumps when a server-player left unexpectedly and the server had to be quickly changed to another player? How long do you think it would take to do the switch? I'm thinking at least a second or two, maybe even longer if a lot of game data has to be sent. |
| ||
| *Update* I've been using BPlay for 2 days, already I have most of a game I started 2 days ago done. Great lib surreal! |
   |