What is the best way to code the XNA gameserver for an FPS game?

Question

I'm writing an FPS XNA game. It is going to be multiplayer, so I came up with the following:

1. I'm making two different assemblies — one for the game logic, and one for drawing it and the game irrelevant stuff (like rocket trails).
2. The type of the connection is client-server (not peer-to-peer), so every client connects to the server, and then the game begins.
3. I have decided to use the XNA.Framework.Game class, for the clients to run their game in window (or fullscreen), and the GameComponent/DrawableGameComponent classes, to store the game objects, update, and draw them on each frame.

---

What should I do on the server side? I got few options:

1. Create my own Game class on the server, which will process all the game logic, without graphics. I am not using the standard Game class because, when I call Game.Run(), the white window appears and I cant figure out how to get rid of it.
2. Somehow, use the original XNA Game class, which already has the GameComponent collection and Update event (60 times per second, just what I need).

---

I have additional questions:

First, what socket mode should I use? TCP or UDP? How do I actually let the client know the order in which packets are meant to be processed?

Second, if I am going to use the exact GameComponent class for the game objects, which are stored and processed on the server, how do I get them to draw on the client side? Should I inherit them, while they are combined in an assembly), or something else?

Answer 1

I'm not qualified to answer your XNA-network specific questions. However, I can recommend you this great article about TCP/UPD for games which is not XNA specific.

I'll summarize below as best as I could in the context of your question.

In short:

Timing is crucial in an FPS game, you want packets to be sent across as fast as possible. Use UDP, it gives you more control over individual packets and is much faster than TCP on average which exposes networking interface as streams rather than packets.

Long explanation:

TCP guarantees order/arrival of packets, but abstracts away the logic to break up your data into packets. However, this introduces latency if you attempt to send small amounts of data, it may get clumped up by TCP into 1 packet of "reasonable" size and then sent. Also for packet loss, TCP simply wait/re-send the data, this will block execution of the game and cause lag. Therefore, you need control over individual packets and should use UDP which is more low level; it gives you control over processing each packet and lets you handle what size of packet/packet loss/ordering yourself (more work for you of course).

One way to deal with ordering of course is to time-stamped the packets you send and do appropriate checking on both sides. For more info, you can refer to the rest of his series at bottom above comments of this article about Networked Phyiscs. He wrote a series on how to handle networked games with UDP including how to implement virtual connections which you'll be interested in.

Now, his articles are not framework specific and talk about fundamental concepts which you probably should be familiar with. However, I'm sure that there exist some game specific networking frameworks to aid you (do some googling perhaps?). Perhaps someone else will give you some recommendations.