Question

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?

Answer 1

First of all, your game logic should be on the server.. Not only does that prevent cheating, but it also garantees consistency, especially over random operations. The clients should only be sending their inputs to the server

I’d recommend your keep the server’s window visible to make it a debug console, you’ll need it, to know what your server is doing exactly.

For a FPS, UDP is recommended. You’ll be sending a lot of data and you don’t really care if your packets are all received or ordered. While the packets are not garanteed to arrive ordered, you don’t really have to worry about it. Most of the time, they will arrive in order anyway. Let’s say you send 60 frames per second to your clients and one of your packet arrives in the wrong order: Your client will have erroneous information for 1/60th of a second, which is barely visible.

Finally, you should send a serialized representation of your game state multiple times per second to your clients. They should be able to retrieve that information and draw it the same way as your server. You could even serialize your gamecomponent and send it if you think that’s appropriate. It’s really up to you to decide.

Hope this helps!