Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (739)
Games in Android Showcase (224)
games submitted by our members
Games in WIP (820)
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 1935 times)
0 Members and 1 Guest are viewing this topic.
Offline knot

Senior Newbie




Java games rock!


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

Hi.

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:
http://kurve.knot.be/kurvetest.zip
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:
http://kurve.knot.be/kurve.jpg

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.

HTH,
Dr. A>
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 
Ecumene (48 views)
2017-09-30 02:57:34

theagentd (72 views)
2017-09-26 18:23:31

cybrmynd (182 views)
2017-08-02 12:28:51

cybrmynd (180 views)
2017-08-02 12:19:43

cybrmynd (187 views)
2017-08-02 12:18:09

Sralse (193 views)
2017-07-25 17:13:48

Archive (744 views)
2017-04-27 17:45:51

buddyBro (876 views)
2017-04-05 03:38:00

CopyableCougar4 (1423 views)
2017-03-24 15:39:42

theagentd (1316 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org 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‑gaming.org
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!