Hypotical question about networking.

Hi,

Don't kill me for this question, I just have to ask.

If I would have a dual xeon server on 100mbps network connection (at a network center, not 100mbps to my cable modem but real 100mbps network connectivity)

Then if I want to make a world where 1000 players could log in and walk around in an environment like for example MySIMS on the Wii (so just a terrain with some houses)


I would let the gameserver only send data (location/orientation of player + eventually his chat text if he speaks) of players within 50meters of the player, so there may be 1000 players in the world, but maybe only 5 visible for each player.

Would such a server then be capable of calculating/holding/managing all data for the position of 1000 players ? Or is that aimed too high for unity ?

I must say I won't yse physics, because I do know that those bang on your cpu.




Ad second question. I suppose the FPS controller is using physics heavily ?

 

I think the answer to your first question is maybe. I'm not an MMO architecture expert, but if we consider that what you're doing is not dissimilar to posting and requesting from a webserver, 1000 connections on a decent server isn't impossible. I suppose you would need the server to be diligent in working out who can see each other, and making sure that all the 3D data (like meshes and textures) are located on the client. The biggest problem is probably whether Unity could accept that many incoming peer connections (I always thought about 32 was the max)

If you're not making a face paced FPS, I'd consider a loosely coupled architecture where we just keep asking the server to keep us updated. It's a non-authoritative approach in that you just tell the server where you are and it works out the rest, tells you what you should see, and your client works out the delta between what the server says and what you have on screen.

I'd start by considering the following and working out the obvious problems:
1. On the server, have an array of all the connected players positions that is updated regularly from each of the clients (if the clients don't move, the don't bother the server etc)
2. For each connected player, work out who is entering and exiting their visible radius and trigger the relevant instantiate and destroy functions for their subscribers
3. For each of the active 'other' players in the clients radius, update their position at a reasonable rate (maybe using some kind of simplistic prediction if the wait-for-update timeout is reached) - I can't say whether Unity's Network Sync would be suitable for so many objects.

So something like this:
1 Client: Server, I'm new here, find a position for me and create me
2 Server: OK, I'll put you here, and 5 other people happen to be nearby, I'll tell them about you
3 Client: Server, this is my new position, tell me who I can see.
4 Server: You can see these people, moving in this direction etc
5 Client: OK, thats different to my local list, I'll destroy the orphans, instantiate the new avatars, and update the position of the others
6 Client repeats from step 3 (happens a few times per second, ideally)

This is totally off the top of my head and very simplistic (although I implemented something similar to this a while back and it worked great - there were lots of other things to consider though, like actions, avatar look n feel - the little things are the killer).
There are some good articles that solve this design issue and maybe Lars or Larus at UT could offer some advice.

Hope this is useful