Click here to Skip to main content
15,393,377 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
Hello Codeproject,

As you may or may not know I've been developing a game for the past year or so, and I am finally ready to start making it Online.

However, after I had gotten the basics done(Working Server, and Client) I started working on the movement system so that both clients were aware that they both were moving.

This code is basically the following:

> Client 1 Moves.
> Client 1 Sends a packet to the server where it has moved to.
> Server sends the same packet to Client 2.
> Client 2 reads the packet and updates the other client's entity.

After everything was done, and ready I saw the results, and they kinda made me jump. The FPS of the other player seemed to be about 5 if not less, and this is because of the sending of the packets to the server and back to the other client.

Now why is .NET so slow? Because this wasn't me to my friend, this was my computer to my computer to my computer.

Does anyone have any solutions that might help fix this problem? Because I see games such as Minecraft, Team Fortress 2 whom have more complex features, and they don't have any movement lag on a proper server.

With all the regards,

- Deviant
Posted

1 solution

From what you say it is very hard to tell.
If you look at my article: Writing a Multiplayer Game (in WPF)[^] I talk about possible game developments and I did it as server centric (and I think that's what you want to do).

An important thing to note is that if your communication is not like:
Client send data, client receive data, client send data, client receive data.

You will probably need to use the TcpClient.NoDelay set to true.
Such NoDelay is false by default and its purpose is to avoid many small packages to be sent. That is, the first send goes directly, but the second, third, etc will wait either until the tcp buffer is full (usually 4kb) or 200 milliseconds. That justifies having only 5 frames per second.

Also, by this same trait, you should never serialize/write data directly to the tcp/ip stack. If you need more than one write call, then you should use your own buffer and, when you finish, you must copy the entire buffer (write it to the tcpclient/stream) in a single call. This is to avoid the opposite problem if you use tcpdelay to false, a WriteByte call is enough to start sending data.
   
v2
Comments
Deviant Sapphire 26-Dec-13 21:14pm
   
Cheers mate, never heard of that TCP Delay. :)
Paulo Zemek 27-Dec-13 0:37am
   
Thanks for accepting the answer. I did correct the name, it is not "TcpDelay", but "NoDelay" which, in fact, works in the inverse sense (so, a NoDelay of false = TcpDelay as I explained it).

In either case, I hope you are able to figure the problem out, be it with the Tcp/No Delay or because my article is useful.

Good luck with your game!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900