Network: slow client update

Networking & Multiplayer
#1

I have a platform type game, and i’ve been trying to get multiplayer working. I succeeded, BUT, the client doesnt update fast enough so everyone just teleports as they move, even on a LAN.

What i am doing is:

Client:
Thread 1:

  • gathers players pos (thats all at the moment, i would hope to add more, but its too slow as it is)
  • Stores values in Object array, serializes, and sends

Thread 2:

  • handles game

Server:
Thread 1:

  • Waits for players to connect
  • Starts new Thread to handle client

Thread 2:

  • reads players data, deserializes data, stores player(X’s) data into static array full of everyone elses data so it can be serialized and shipped off.

I was reading through the forums, and someone mentioned that sending objects is slow, so that might be the reason. But if i cant send objects how am i to send data for say 8 players to the client?

#2

just create your own format for the player’s position for the client to send. Just, for example:

0,45,100|1,100,60|2,30,20

That’s basically the player data stored in a triplet format separated by a | character. Format is:

playerID,X,Y

So just send a string like that to the server and parse it with StringTokenizer or regex.

#3

I use a NIO ByteBuffer in SharpShooter Arena. There are methods for reading/writing bytes, shorts, floats etc., so you can create a custom packet quite quickly. Manual packet creation scores over serialisation in that no structural information about the object is transmitted. This can save precious bytes when sending position updates at a high rate over a 56k modem connection. It’s so easy to exceed the maximum throughput with multiple users.

Of course this does use NIO. Using NIO also reduced the number of threads and avoided having to synchronise all over the place. There are bugs in it, although keeping my usage as simple as possible avoided any problems in my case.

My solution was to open a UDP port for listening. Each time a packet arrives, the sender IP address:port identifies the remote client. The first byte of each packet identifies the packet type. This is followed by the payload in one of a range of fixed data formats. Sending consists of assembling the packet, addressing it to the client address:port & off it goes. The sending operation may block or lose packets if you send faster than the local connection can transmit.

UDP is great for streaming position updates. You can get problems when transmitting state (e.g. player X killed), since packet loss can occur. A higher level reliable transfer protocol is then required.

Alan

#4

[quote]UDP is great for streaming position updates. You can get problems when transmitting state (e.g. player X killed), since packet loss can occur. A higher level reliable transfer protocol is then required.
[/quote]
Did you use a additional TCP socket for that in Sharpshooter?