next »

[Orz]

I am making a simple bowhunting game where you can walk around and shoot at wild boars.  It is written in C# and uses Lidgren for networking.  I use a client/server model where all updates are done on the server and all rendering on the client.  At the moment, it is playable, but too slow to really be fun.  The bottleneck is in the networking code.

Does anyone have experience doing this before?  What did you change?  I'm looking for places to begin when I start profiling.

[Netsu]

How often do the client and server communicate?

[Orz]

How often do the client and server communicate?

Every frame (60hz max, usually around 30).  I'm going to lower it to 20hz as I've heard that figure floated around.  I suppose I will have to do some interpolation on the client to keep the animation smooth.

Is there any reason to have different update rates on the client and server?  I just send keyboard and mouse input from the client.

[Netsu]

That's a lot and won't really fly in a real-life scenario over the internet. You should only send information when there is new input from a player and have the client compute physics and everything itself. It's called a prediction-correction model.

[Eigen]

Yes, send an event when a key state changes or you press the fire button and so on. I would set it up like this:

• Client sends key events to server and simulates motion and actions locally (immediately)
• Server receives key events and changes player state internally, setting them in motion, turning or stopping them as required. Server also sends these events to all other clients (excluding the origin client)
• Other clients simulate motion and actions for the other players using the information they have
• Occasionally the server sends the current state of all player objects to all clients, syncing the game. All clients overwrite their locally simulated player positions and headings using this new information. This also includes the player object associated with that client. The sync time can be tweaked (around couple hundred ms, maybe?)

You can play around with the sync time depending on how twitchy the movement and gameplay is. Lower values are obviously better as long as it's not a constant stream of packets. It also depends on how many clients you have on each server.

You might also want to use TCP to send key events to server to make sure they get there, use UDP to broadcast these events to other clients from the server (as it has less priority as long as sync happens) and use TCP to send syncronization packets.

Obvious optimizations apply too, so don't send turning and moving events to all clients if they can't possibly see them. Only the weapon firing and other things like that.

[Netsu]

It can be set up in such a way that the sync is only needed to account for computational errors that can accumulate over time, meaning you only really need to do it at most once every few seconds. But that means you need to be certain that the packets you send always reach their destination, and writing an absolutely error-proof prediction-correction system is a pain in the ass.

Regarding TCP vs UDP there are some libraries out there that enhance UDP with functionality that ensures re-sending the packets until they are received, very handy for real-time games, I used ENet for that reason.