I havn't done much server programming.... (like none at all <.<) but I think I know the general idea of how it works. What happens is, all the players' info is stored on the server, so every time the server sends info to the players, it determines who is on screen the same way an offline game would. But I haven't had the chance to work on a project like that yet.. :)

I've had as much experience as SSJMetroid above but i can think of two possibilities you can have the server send all updates to every client in that area (size of the area should be coded into the application) or have the client request the information from the server once again it would only be interested in a certain sized area.

That's the basic idea of it. It's a bit more complicated since you have to take into consideration things like network latency, so things don't just suddenly pop into view, but the basic idea of it is still the same as it is in a single player. Think of how you cull things against your view camera in a single player game...

Really the only difference relevant to this discussion is that you have to send the player information based on what you think will be the game state in the future rather than what you know is the game state right now. You send the user a combined set of all the things you think the player will be able to reasonably see if they pursue all reasonable paths from where they currently are that they can reach within the time it takes you to transmit the data to them. Thanks to lag, there really isn't anything you can do to assure a 100% accurate synchronization between client and server on a MMO's scale, but you can at least do a pretty good job of assuring that things don't just suddenly pop into existence as the player looks at them.

The idea is the same, the scale and the exact approach is different.

In World of Warcraft every player has a "Magic Bubble" (other games probably handle it similarly).

- the server tracks every player's Magic Bubble

- the server only sends you data about other monsters and players inside your Magic Bubble

- Thus, to your client, nothing exists outside the Magic Bubble.

As for seamless world loading:

- the world is divided into grid sections

- your client only loads data (terrain info) for the grid you are in and those adjacent

- when you move, new grid data is loaded and old data is deleted

It actually is a very easy problem! 10,000 is not all that many. All you need to do is measure the distance between them, which is simple. You also only need to do it when someone moves. And, you can subdivide the world (eg. with a quadtree, or just into a grid) so that you can easily ignore large amounts of the 10,000 players.

When Player A starts to be seen by Player B, you just send a description of Player A down to Player B, so Player B knows how to render it, etc.

Probably the easiest way I could think to do this would be to divide the world into nodes. Each node would be as big as the view distance (that you want players to be able to see other players at). As players enter the world they are assigned to the nearest node, as they move the server checks to see if they've moved closer to another node.

When the server software sends the other player updates it can send them out by node. You also would have it send data on adjacent nodes as well so that the client will be prepared if the player is at the edge of a node. This way you might get a couple of extra players in your update (i.e. ones that are outside of your viewable area), but you'd be certain to get everything in your viewable area and would have a reduced amount of calculations to do.