Designing Multiplayer Game Engines?

mikera asks: "I'm a pretty experienced programmer but I've just embarked on my first (massively?) multiplayer strategy game. To make things even more interesting, I've decided to write it in C# and pick up a new language at the same time. I've chosen a client-server architecture where the server holds the one 'true' state of the world. The only communication from clients would be commands to units, which is simple enough, but the server will have to propagate game state changes (events) to all clients. I would like to ask Slashdot readers if they have solved a problem like this before or can offer some opinions on the best way to implement a solution."

"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."