Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have to design a Pong game for Android. There are multiple mobiles and a game server. Application is installed in mobile. Mobile 1 (M1) can see the movement of bat and ball of mobile 2 (M2) an vice-versa.

Suppose if M1 hits the ball, all the movements of the ball and bat of M1 can be seen on M2's screen and vice-versa. Now I want to know which protocol I should use and why?

Edited: how can a server take the initiative to send a message? What are the different methods to do this: i.e. "push", other,...

share|improve this question
Is this really just a rephrasing/clarification of your other question? You should probably just edit that one if so. – Josh Petrie Apr 12 '11 at 16:50
@James spectators, obviously... – Zaky German Apr 12 '11 at 17:25
@James i see, i was just being a smartass anyway, not sure how fun it would be to spectate over a pong game :) Might be a nice practice for a programmer though... – Zaky German Apr 12 '11 at 17:45
@GameBuilder that's latency, measured in milliseconds. It's how long it takes to receive acknowledgement of a sent packet. It's also known as lag. – octal9 Apr 13 '11 at 16:47
@GameBuilder You will have to make your game lag tolerant. Pong seems like a game that will literally be impossible to place nicely at over 300 ping. You have to allow each client have a delay of .3 seconds to 3 seconds for the opponents move, meaning fast games like pong where the ball could move back and forth multiple times per second wont work at all, or in order to make them work you will have to delay the game while the opponent receives the information and reacts to it, and resends it back. – AttackingHobo Apr 13 '11 at 19:41

I'd recommend the User Datagram Protocol -- have each client send user inputs to your server, have your server calculate the results of all inputs and respond that result to each client.

**Pseudo Code for UDP Client/Server**
// public
int sendSequenceID= 0;
int receiveSequenceID = 0;

// send data
var data = new { id = sendSequenceID, DeltaX = changeInXCoord, DeltaY = changeinYCoord };

//receive data
var receivedData = null;
if( > receivedSequenceID) // ignore packets out of order
    receivedSequenceID =;
    // process received data
share|improve this answer

TCP and UDP would be the two choices for this and you will want to go with UDP.

As for the Why part of your question, TCP is a 'guaranteed delivery' system, but its slow. For video games and where up to date information is a priority over ensuring the data gets there, UDP fits the bill. You will generally want to have an incremented Packet ID so you can ignore outdated packets to take care of them showing up in the wrong order, but this will suit your needs.

EDIT: A bit more information on the incremented packet IDs. With TCP, you are not only guaranteed that the data is sent, but that it is sent in the right order. It will not try to send a new piece of data along the same TCP connection until the current one has been confirmed to be sent.

UDP does not guarantee delivery order. So if you have an incrementing ID in the packet data and you keep track of that value, you will know that incoming data with an ID lower than what you have already processed is old data. In that way you can safely ignore that packet and just wait for the next one.

Hope this helps.

share|improve this answer
HTTP is just an extra set of protocols over TCP. You would use it for web based games where real time isnt really a factor... even with HTML 5 and web sockets coming down the pipe though, ya may not need to use HTTP for much more than delivery of a client at the end of the day.. – James Apr 12 '11 at 19:05
@GameBuilder see my edit for a pseudo code example of using UDP to ignore out of order packets. – Nate Apr 13 '11 at 16:15
Matchmaking requires guaranteed communication (Find Partner, Partner Found, Begin Match, etc) which TCP can do (UDP can as well, just takes a bit more work). Any sort of real time interactive game where actions over a second matter (like the position of the ball and paddles) need to be as real time as possible, which is what UDP is good for and TCP sucks at. So TCP for where real-time to the second doesnt matter (match making) and UDP when it does (Game play). – James Apr 13 '11 at 22:21
Yes, sorry. A Push Notification simply means that the server is pushing the notification to a client.. So Client 1 would tell the server it wants a game, it would have a list of people who want to be notified by Push when someone is around to play and then the server would send a notification of 'Person available' or something like that. – James Apr 13 '11 at 23:53
While you do not want to delay sending packets, as you want them to send as often as they need to. Packaging multiple available updates of information together and sending them at once is the best way. it will take more time to send the position of a paddle then a ball then another paddle then it will to send all three of those pieces of information at once for instance. The smaller the size of the data to send the more small parts you can pack together and still send nice (4096byte) packets and the like. – James Apr 14 '11 at 0:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.