MMO theory

Blitz3D Forums/Blitz3D Programming/MMO theory

The forum is locked. These are the original blitzbasic.com forums, kept so they can still be read. No new topics, replies or edits can be made here. To join in, head over to the Blitz3D+ forums.

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.