Designing Multiplayer Game Engines?
"Lag is not really critical, but I still want things to be responsive and it must scale up well with the
number of clients. The size of the map data, the complexity of the
objects and bandwidth constraints rule out sending the complete game
state, so only incremental updates will work. The situation is further
complicated by the need to limit updates to just the areas of the map
that are visible to a given player/team - this is clearly necessary to prevent client-side hacks such as gaining full map
knowledge.
I understand the theory well enough, but I'm interested in practical
advice on how to implement a solid architecture. What should the
object model look like? How do I propagate events that are only
partly within a client's field of view? Are there any novel features
in C# that might make my life easier? How can I make the networking code
as transparent as possible so I don't have to write SendUpdate()
after every assignment?"
Your comments, insights, hints and flames are eagerly awaited."
I'm not at liberty to say how I know this but this is what I know of Everquest (the most popural MMORPG):
.... reseting crashed NT servers.... yes, that's right. full time server reset people...
They used NT and C (Asm too?) to develop Everquest and they are paying for it dearly.
Everquest has had up to 80,000 simultaneos users which were distributed over 200 NT servers.
These servers are in two locations and they have two FULL TIME employees who walk around all day -- their sole job
In addition, they've had nightmare situations with patching and keeping these systems up to date.
And another thing I know is that their next game (forget the name) they have started nearly from scratch and are developing on a UNIX derivative (may be linux... not sure) mainly because the costs of running the game on NT are too great...
learn from experience...