Seriously, it's not that big a deal. Moving from one node to another is an instant operation on the server, and it just means that when you next do the distance checks during the updates, you'll be looping through a slightly different subset than before. The subset will still be small and you still only need to send updates to a small number of people. If you remember who you sent updates to last time, you can send a 'no longer visible' update to anybody on the previous list who's not on the current list. And that's it, really.

Of course, you started off asking how "online games" do it, and then went on to say that you only have a 366MHz system to do it with... well, you can't expect to easily emulate professional games when you have only 10% of the processor power available. But I still don't think it's as difficult as you believe.

As superpig said, these places have some serious hardware, and growing games like World of Warcraft are constantly upgrading to keep pace with additional players. Each "server" is undoubtedly comprised of many, many machines acting as a server cluster.

I'm just taking a wild stab here, but I'm guessing managing internet bandwidth is a lot bigger of a problem than processing all of the different stuff in the game world.

You don't update on every move. Internet latency is 250ms, add 10% buffer zone to the area of interest, factor in player's movement speed, and you'll end up with needing to recalculate every 1-15 seconds.

Real-time here doesn't mean milliseconds, and you'll need to compensate for latency anyway, probably providing state synchronization for several seconds in the past.

So updating AOI once every 10 seconds for a reasonable range is probably enough. Note that once you establish interest subscriptions, finding out when someone moves out of range is very cheap - just check for subscriptions to a given object.

By far the most costly process of this will likely be serialization - but since not everything changes on every step, or you send only delta states, you can cache plenty of state information, making sending new information to a plater a relatively cheap process.

Quote:And I have a server where only 366 MHz, 128 RAM (a part of server)

With all due respect - MMOs do not run on pre-historic hardware.

If you're thinking about 10k users (WoW does 3-5k per server, distributed over several machines), you might need to invest into a bit stronger hardware.

The typical load per machine is usually in the hundreds range.

What you will want to do to save bandwidth is to use some sort of server-side client manager that is like a scene manager on the client side.

AKA smap, speed tree, ect...

So what you will do is create a very big array for your world, and devide that world up into cells, so lets say you world is 100000m (meters) long by 100000m wide, and you want cells that are 20 meters big.

so you would go 100000/40 then you would get how many cells wide and long.

Then after that you would make an array that size, after that you would have the client send you an update packet on its position then you would take its position and then find the cell that he is contained in.

so it would be like this:

|o|o| | | | | |
---------------
|x|0| | | | | |
---------------
|0|0| | | | | |

Where "x" would equal your character, then you would get the cells around him that are marked with "o" and load everything in those cells, just make sure when you do it to make it as memory effective and cpu effective as possible, and watch for memory leaks, because you will be allocating and deleteing alot of memory.

BTW, thats just one method, there are many many many other methods.