4
\$\begingroup\$

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,...

\$\endgroup\$
13
  • 1
    \$\begingroup\$ Is this really just a rephrasing/clarification of your other question? You should probably just edit that one if so. \$\endgroup\$
    – user1430
    Commented Apr 12, 2011 at 16:50
  • 2
    \$\begingroup\$ @James spectators, obviously... \$\endgroup\$
    – Zaky German
    Commented Apr 12, 2011 at 17:25
  • 2
    \$\begingroup\$ @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... \$\endgroup\$
    – Zaky German
    Commented Apr 12, 2011 at 17:45
  • 3
    \$\begingroup\$ @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. \$\endgroup\$
    – octal9
    Commented Apr 13, 2011 at 16:47
  • 2
    \$\begingroup\$ @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. \$\endgroup\$
    – AttackingHobo
    Commented Apr 13, 2011 at 19:41

2 Answers 2

Reset to default
5
\$\begingroup\$

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 };
udpSocket.Send(data);
sendSequenceID++;

//receive data
var receivedData = null;
udpSocket.Receive(receivedData);
if(receivedData.id > receivedSequenceID) // ignore packets out of order
{
    receivedSequenceID = receivedData.id;
    // process received data
}
\$\endgroup\$
4
\$\begingroup\$

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.

\$\endgroup\$
23
  • 2
    \$\begingroup\$ 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.. \$\endgroup\$
    – James
    Commented Apr 12, 2011 at 19:05
  • 2
    \$\begingroup\$ 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). \$\endgroup\$
    – James
    Commented Apr 13, 2011 at 22:21
  • 2
    \$\begingroup\$ Is there some reason you would want to? I can not think of any particularly useful application to do it. \$\endgroup\$
    – James
    Commented Apr 20, 2011 at 18:56
  • 2
    \$\begingroup\$ This is not a forum. If you have questions, just ask a new question. Comments aren't for a long back and forth. \$\endgroup\$
    – Tetrad
    Commented Apr 21, 2011 at 16:43
  • 2
    \$\begingroup\$ I am sorry man but while there may be some good information here Tetrad is correct, the original question has been answered and this is not the chat rooms. Please ask a full new question if you need more answers as no one is likely to read this far for all of the information. \$\endgroup\$
    – James
    Commented Apr 28, 2011 at 16:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .