Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm writing a FPS XNA game. It gonna be multiplayer so I came up with following:

  1. I'm making two different assemblies — one for the game logic and the second 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 at first connects to the server and then the game begins.
  3. I'm completly decided to use 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 and update&draw them on each frame.

Next, I want to get the answer to the question:

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 (only, no graphics). The reason why I am not using the standart Game class is when I call Game.Run() the white window appears and I cant figure out how to get rid of it.
  2. Use somehow the original XNA's Game class, which is already has the GameComponent collection and Update event (60 times per second, just what I need).

UPDATE:

I got more questions:

First, what socket mode should I use? TCP or UDP? And how to actually let the client know that this packet is meant to be processed after that one?

Second, if I is going to use exacly GameComponent class for the game objects which is stored and processed on the server, how to make them to be drawn on the client? Inherit them (while they are combined to an assembly)? Something else?

share|improve this question
add comment

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.