0
\$\begingroup\$

This question already has an answer here:

I'm tying to dive into multiplayer game programming.

The game is quite simple, it's a 2D scroller mobile game, the player need to touch the screen in order to move 1 step and it could contain up to 4 players at max. 1 of the player could create a room for other players to join.

I was thinking that I would use TCP for this and will only send packets when 1 of the player trigger an event like moving or exiting the game. Is my approach is correct? Since from what I've read, many games are created in UDP instead of TCP.

In case of UDP, what is sent between the clients and the server? The position of each entity in the game at a fix time interval?

I'm really new multiplayer programming. I'd appreciate if someone would share their story.

Thank you.

\$\endgroup\$

marked as duplicate by Philipp, Engineer, Anko, Seth Battin, Tom 'Blue' Piddock Oct 6 '15 at 13:20

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • \$\begingroup\$ If your game is time-sensitive, you will have a very, very hard time getting it to work on mobile networks. Mobile data connections are designed for high throughput once the connection is established (for streaming video or music), not for low latency (which you need for gaming). There's a reason you don't see Street Fighter style games played via network on mobile devices. \$\endgroup\$ – Almo Sep 15 '15 at 15:11
1
\$\begingroup\$

UDP packets are not guaranteed to arrive. Use them for things like position updates, where it doesn't matter if some of them are missed. They don't necessarily arrive in the order that you sent them.

TCP packets are guaranteed to arrive, no matter how many retries this may take. They always arrive in the correct order, too.

For such a small game, you could get away with using TCP. It sounds as if the packets will be small, so the noticeable difference shouldn't be huge.

Also bear in mind that TCP will almost certainly be more efficient than your system of guaranteeing packet delivery, since it has been designed carefully by professionals.

The packets that are sent depend on your game. For what you're making, I imagine that it'll consist of: player joining, player movement, world data etc. Bear in mind that out of these three examples, two have to be delivered every time (and TCP does this for you).

\$\endgroup\$
1
\$\begingroup\$

Lolums explained the differences well, so I'll just add that if you're game is turn based, you'll need to have all players see each others moves, so missing packets of information is not allowed and TCP should be used. Alternately if your game uses realtime gameplay, you need to ensure that all players have the latest information so waiting for a late packet with outdated information is unacceptable. you'll want to use UDP in that scenario and throw away older packets that may come out of order. for example, if you get 2 packets of position information for the same player, but the older one comes later due to some network latency somewhere you need to know to ignore it in favor of the newer information.

\$\endgroup\$

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