Jump to content
  • Advertisement
Sign in to follow this  
zgintasz

What should I know about making a multiplayer work on 3G?

This topic is 920 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I'm making a multiplayer synchronisation for my game and I have a goal to make players be able to play on 3G. It's a platformer shooter. I'm currently planning to send a partial update(players pos + velocity) and a full snapshot every few seconds right now. I heard 3G has some latency issues.  What should I know about it before making? Should I avoid TCP and use UDP only or no?

I'm hoping someone with more experience could tell something useful.

And by the way, should I even be aiming to support 3G? Is it still widely used? Didn't HSPA/HSDPA took it over?

Edited by zgintasz

Share this post


Link to post
Share on other sites
Advertisement
HSDPA isn't THAT much lower latency than "regular 3G" -- depending on where in the world you are, somewhat.

In addition to latency problems for mobile connections, you also have intermittency problems (packets may stop flowing and then come back, sometimes in a storm -- especially when on a train or bus.)

You also have volume problems -- games that send and receive lots of data may cost players a lot of money in metered data charges.

I'm assuming you already know about the other challenges of mobile development (battery drain, overheating, latency of finger detection, etc.)


So, that being said, I'd recommend using UDP. I'd recommend making the send rate low (5-10 packets per second) and get as much smarts as you can into those packets. It's totally OK to send input/command/info data for many simulation steps in a single packet. Make sure there's a single network packet that contains all the updates/messages regarding all the other players, rather than trying to split that into multiple packets. As long as that's solved, the actual size of the packet isn't as important -- 500 bytes or 1000 bytes will not have different latency (although of course 500 bytes will cost the player half as much as 1000 bytes :-)

Finally, the round-trip-time may be as much as 500 milliseconds. You may want to tune your game and/or design the control scheme to work around that.

Share this post


Link to post
Share on other sites

So you are saying, that partial updates ain't really needed and I could just send full snapshots?

Also, would it matter if I send let's say 20 packets(100 bytes each) per second or 40 packets (50 bytes each) per second?

By the way, 5-10 seems really too low for multiplayer platformer shooter, I was thinking about 20 packets per second.

Also, is the latency big for receiving a packet, sending a packet or both?

Edited by zgintasz

Share this post


Link to post
Share on other sites


Also, is the latency big for receiving a packet, sending a packet or both?

Both. There's really not much point sending more than 2 packets/second when latency is up around the 500ms mark.

 

There is a reason that most twitch-based multiplayer games on mobile require Wifi connections to play.

Share this post


Link to post
Share on other sites

There's really not much point sending more than 2 packets/second when latency is up around the 500ms mark.


Well, yes, there is, because you can avoid some latency by pipelining the updates.

The point is more one of relative gains: When the transmission latency is 200 milliseconds, the additional difference between 10 packets a second (100 ms additional latency) and 40 packets per second (25 ms additional latency) is quite small, but the 4x packet rate (and data plan consumption) hurts! Edited by hplus0603

Share this post


Link to post
Share on other sites

Do I really have to use UDP only and implement reliability myself? Kryonet uses separate ports for UDP and TCP. So if TCP packet gets lost, then congestion won't affect UDP packets and they won't get stuck while waiting. So could I just send unimportant packets through UDP and important packets through TCP?

Share this post


Link to post
Share on other sites


Kryonet uses separate ports for UDP and TCP. So if TCP packet gets lost, then congestion won't affect UDP packets and they won't get stuck while waiting. So could I just send unimportant packets through UDP and important packets through TCP?

They are both traveling over the same underlying wireless network, so dropped packets are going to affect both pretty much equally.

 

The advantage of UDP is that dropped packets don't cause the connection to back up (provided you don't in fact need the previous packets). To benefit from this, you'd want to send state updates over UDP (since you only need the most recent state), and any transactional commands over TCP (since those must arrive, and must arrive in order).

Share this post


Link to post
Share on other sites
UDP ports and TCP ports are independent. Even if you have traffic to TCP port 1234 drop packets, that won't affect traffic to UDP port 1234 (and vice versa.)

You *can* use both UDP and TCP. It can totally work. In general, once you get down to optimization and building networking specialized for your game, you'll find that you actually want slightly different semantics than TCP (for example, ordering may not be as important as exactly-once delivery.)
Exactly how much this matters to you, only you can decide.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!