I'm building a game engine on the OpenTK framework that needs to support multiple players.

How I have the basic framework established is that there is a Client and a Server. The Server binds and listens on a specified port, and the Clients connect to the Server's IP Address and Port to make a TCP socket. The server then transmits a World object to all clients as they connect.

A World object contains all of the Light objects, Surface objects, Mesh objects and Camera objects. With all of these objects, the World is responsible for rendering the game environment.

My idea is that each Camera object has a Unique ID, a position (X,Y,Z), and 2 angle values representing Zenith and Azimuth. When any of these values changes (only the camera can move at this point. Basics first!) I want to Serialize and send the updated Camera object to the Server, which then transmits this object to all of the Clients. The Client then deserializes the new Camera object, uses its Unique ID and updates the existing Camera object in the World. Since the Camera object consists of only 5 double values (X,Y,Z,Az,Ze) it shouldn't be a lot of data being sent over the network, but my implementation seems to slow down the Game Screen significantly

Is there a better model for Multiplayer network communication? Is there any built in functionality in C# that handles this kind of communication?

Basically, I just need to update all of the other Clients when one Client's Camera changes.

Thanks for any help!

  • 1
    \$\begingroup\$ Are you by any chance using sockets synchronously? Because that's the main source of slowdown when using network, and no protocol changes will help you much in this case. \$\endgroup\$
    – Nevermind
    Apr 13, 2011 at 7:53

3 Answers 3


Sockets aren't the problem. That's just how TCP/IP networking works. Two things could be wrong. How you are using them and what you are sending?

Serializing a class and sending it and de-serializing seems huge for a game. Just send something like CBIXYZCE as in CB for camera begin, I for identifier, x coord, y coord, z coord, and CE for camera end.

When it comes to networking be as terse as possible.

In fact my example may be too big. The camera class should exist on the server and you only pass what changes. Oh and use UDP.

  • 1
    \$\begingroup\$ +1 for the two points I wanted to cover. First, use UDP, second, send the minimal amount of data as necessary! :) \$\endgroup\$
    – James
    Apr 12, 2011 at 19:23
  • \$\begingroup\$ In C# if using the Binary Formatter, the data actually sent should be quite small, that said, I agree, small data transfer is better. \$\endgroup\$
    – Nate
    Apr 12, 2011 at 19:31
  • \$\begingroup\$ UDP... Layer 3 really isn't my realm. I'll give it a go! And yes, I am sending a little bit more data than I was anticipating. Like 800 bytes more... Also, what about sending the map object? it's 2-4 mb, but only needs to be sent across once. How should I handle that? \$\endgroup\$ Apr 12, 2011 at 20:04
  • 4
    \$\begingroup\$ @joe_coolish i'd read more about the tcp vs udp before deciding. I read articles and on forums, from my impression it's the other way around - unless you're developing an online FPS there is no reason to use UDP. I've seen claims about MMO's that moved their infrastructure from udp to tcp and were seeing improvements in performance a a result, sorry that i don't have anything to link though, just saying it as a motivator to read more not to use this or that \$\endgroup\$ Apr 12, 2011 at 20:12
  • \$\begingroup\$ UDP by it's very nature is "unreliable" in that it provides no guarantees the data will arrive at the other end. Under ideal local network conditions it'll work just fine (probably), but on the internet you'll probably experience packet loss. As such, if you just send changes you'll start to have the wrong state at the other end of the network connection. You'll need to either send some sort of resync packet now and again to ensure everything is in sync, or some manual reliable connection stuff (which is what TCP is doing) to ensure no packet loss. You also can't guarantee packet order arrival \$\endgroup\$ Apr 12, 2011 at 21:10

You need consider the strengths and weaknesses of both TCP and UDP connection types. Generally UDP is used to send state data such as player position and actions. TCP is used to send information such as logins, level changes etc. Checkout this simple example of how to create a client server application in minutes using the open source network communication framework networkcomms.net.


Generally speaking, I'm more in favor of using SSL to do the network communications in general. While it may seem unneeded, there have been hacks for some games to use the unencrypted transmission of the packets from the netcode to do some pretty nasty things. SSL would not prevent that completely, but it would add an additional layer of protection to slow it down.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .