Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (767)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (854)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  online snake game: packet overhead?  (Read 2025 times)
0 Members and 1 Guest are viewing this topic.
Offline knot

Senior Newbie

Java games rock!

« Posted 2005-02-07 20:33:37 »


Im am currently writing some test code for a multiplayer snake game. (achtung die kurve - clone).
I am using TCP Sockets atm.

Current situation:

new game round:
I send a short[] array from the server to the clients with their initial random x and y positions. > 2 short per player

running game:
I send left/right pressed/released byte from clients to server. Every 30ms, the server updates the player positions, and sends the x and y offset of each player to its previous position. in a byte[] array. > 1 byte per player

I am using socket.setTcpNoDelay(true); so +/- 33 tcp packets are sent each second, holding a byte[] array of maximum length 6. (max 6 players).

But I read in TCP vs UDP that the TCP overhead is 40bytes?

(40+6)*33 = 1.5 kb/sec sent to each player makes 9kb/sec upload bandwith on the server?
Those 9kb only hold around 1.2kb of data.

How should I reduce the overhead?
Will UDP help? Or do a need to change the way I communicate between client and server.

If I send the player movement keys to all the clients, and let them calculate the new positions every 30 ms, it will be much better ofcourse. But then the server and each individual client won't be synchronized.

The code is available for download here:
Offline crystalsquid

Junior Devvie

... Boing ...

« Reply #1 - Posted 2005-02-10 08:14:55 »

Basically you want to re-think your networking.
There is little point sending 33 messages per second.
Your snakes move straight on unless a turn message is sent - and the snake can only turn at specified points (I would be very surprised if the snake could make a turn every 33ms), so at most you only need one message sent for each possible turn point, only if the snake actually turns. If no turn occurs, the snake will just move forwards.

When you send a turn message to the server, you should state where the turn occured. Given the snakes position in the world, the clients should be able to work out how long ago the turn occurred and apply the change as though it happened 'in the past' for these snakes. Remember that it can easily take 200ms for the other clients to receive the message from you.

The server only ever needs to send the 'turn' positions, and occasionally (oce every 5 seconds?) an x,y position & length to the clients. Use these to re-sync the worlds on the client, and then just use 'turn' messages when they occur. YOu should get the traffic down to a few hundred bytes per second, if that.
Offline knot

Senior Newbie

Java games rock!

« Reply #2 - Posted 2005-02-10 10:23:25 »

Thx for reply.

Well it's not exactly like the regular snake game. It can move to any direction. Maybe this screenshot might clarify:

So a snake can have 3 states: turning to the left, turning to the right, of moving straight forward. I could send to client when the state of a snake changes, you are right.

But I can't figure out how to make the client know how many xx ms the action had taken place in the past. I could send a timestamp from the server. But it is not guaranteed that the time on the client and server is synchronized? And then there is the problem of displaying the action as if it were xx ms in the past.  :-/

This to say I allready thought of sending snake changes, but had no idea how to implement, so I took the easy way and sent the startpositions and offsets every xx ms.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline dranonymous

Junior Devvie

Hoping to become a Java Titan someday!

« Reply #3 - Posted 2005-02-10 12:10:59 »

Some thoughts came to mind -

- Only send states as suggested.  Send when they start a turn and when they stop.

- If the movement speed is constant, then you don't need constant updates.  The clients can keep drawing straight or turning until a new state comes in.

- I don't think there's any way around using some type of time stamp.

- If you make your key sampling for state changes run at about 15 hz and your graphics around 30 fps, you should have enough of a window for things to look and react smoothly.

Dr. A>
Pages: [1]
  ignore  |  Print  

EgonOlsen (1232 views)
2018-06-10 19:43:48

EgonOlsen (1101 views)
2018-06-10 19:43:44

EgonOlsen (842 views)
2018-06-10 19:43:20

DesertCoockie (1251 views)
2018-05-13 18:23:11

nelsongames (1100 views)
2018-04-24 18:15:36

nelsongames (1329 views)
2018-04-24 18:14:32

ivj94 (2068 views)
2018-03-24 14:47:39

ivj94 (1223 views)
2018-03-24 14:46:31

ivj94 (2147 views)
2018-03-24 14:43:53

Solater (787 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!