Hrm, I'll have to investigate this quadtree you speak of. Right now, for ease of use and quick implementation, I have everyone stored as a "Player" object in an arraylist. Methinks thats a bad idea.

Thanks for the post :)

If you want to stick with your basic array right now you could maintain a list of information about visible players in the server's player structures.

for example, a list of structures such as:

struct visibility_struct
{
int player_handle;
bool is_dirty;
}

When a server does it's proximity check for each player:

1. It sets all of the is_dirty bits to true.
2. It searches for all players that are in range
3. If it finds a player in range, it checks to see if a visibility_struct exists for that player in the list.
4. If the player's visivility_struct exists in the list, set it's is_dirty flag to false, else, add a new visibility structure (with the is_dirty bit set to false) and send a player visible message to the client.
5. repeat steps 3 - 4 until no more players are found.
6. remove from the list any structures that have an is_dirty flag set to true, and send a message to the client informing him to stop displaying that player.

This way will use more memory on the server than maintaining 2 octrees, but will use less cpu as it does not have to cast a volume through the octree twice a frame.

a maximum memory usage of:
(sizeof(int) + sizeof(bool) + sizeof(visibility_struct*)) * (playercount*playercount)

Will grow exponentially. If you have 100 players within range of each other, the tables will take up a total of 90k of memory, but if you have 1000 players in range of each other, it will take up a total of 9 megs of memory. Rarely will you have this many players within range of each other, so the memory impact may be minimal.. it all depends on whether your game would be CPU bound or memory bound.