• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
lerno

UDP protocol to minimize latency?

12 posts in this topic

Hmm, interesting, but can you give us more details on how the tests were ran?

- How did you dealt with package loss in the UDP case?

- How did you test the latency?

- If I got it right, you tested in your phone 3G connection, but did you monitor how the network was varying? You could just had got an unlucky peak with TCP.

 

I am saying this because I found the results very odd, there is no sorcery in a TCP implementation with UDP (at least not that I am aware of), you just can use a better retransmit protocol (If TCP loses the first package of a 100 package window, he will ask for the retransmition of the 100 packages) and you can use the information you receive right away (instead of waiting for retransmition, if you can interpolate the lost package, such as movement, you don't even have to ask for a retransmition).

 

Thanks for the time to share the result, hope to hear more from the methods.

0

Share this post


Link to post
Share on other sites

enet works nicely for me... the reliability is an optional flag so it's not required to be used

0

Share this post


Link to post
Share on other sites

- This was just a simple ping test, so UDP packet loss (in either direction) was simply logged as that.

 

- I set up echo servers for both UDP and TCP. Running a client on the same computer but targeting the wifi router's external IP showed consistent < 5 ms, so anything above that I ascribe to either the phone itself or the 3G connection.

 

- I just tried it again before writing the post. Same behaviour and same times (although admittedly, I only got to a latency of about 1800 ms with TCP this time)

 

(I hope it's clear that when I'm talking about my TCP results, I'm talking about actual TCP, and not some reliable UDP)

0

Share this post


Link to post
Share on other sites

In regards to enet, the question is what I actually would gain by using it, especially with the servers using java - which doesn't seem to have a full-fledged enet port.

 

It would seem like I'd be better of trying to implement my own library by copying off some suitable proven protocol.

0

Share this post


Link to post
Share on other sites

I remember reading about one of those early Lucasart space combat games (X-wing vs Tie-fighter?), that they used an extremely simple scheme - basically sending the packet n together with packet n + 1, so that only on two consequent packet losses would there actually be a packet loss.

One challenge with this method is that when you lose packets, it's typically in clusters. That's not to say you won't ever lose just one, but if you're going to miss some packets they're more likely to be lost in clusters. Of course, this depends on how frequently you're sending them, too.

0

Share this post


Link to post
Share on other sites

 

I remember reading about one of those early Lucasart space combat games (X-wing vs Tie-fighter?), that they used an extremely simple scheme - basically sending the packet n together with packet n + 1, so that only on two consequent packet losses would there actually be a packet loss.

One challenge with this method is that when you lose packets, it's typically in clusters. That's not to say you won't ever lose just one, but if you're going to miss some packets they're more likely to be lost in clusters. Of course, this depends on how frequently you're sending them, too.

 

I'm likely to end up sending data 5-10 times a second (mainly ping packets) if I use this method. How long can I expect the duration to be?

0

Share this post


Link to post
Share on other sites

Just want to put this out there, I am developing a client-server 2D TCP networked game, I tried connecting to my game server (hosted at my home) on my laptop though my phones WiFi hotspot (I was further out in the country at the time aswell). That version's build had liquid animation that was compressed -> It ended up running pretty well and latency was within 200ms and this is a game that is not developed for internet through the phone.

 

It would be pointless to use UDP if your going to just reimplement TCP. If some packets can be dropped and/or you want a custom error detection design other than the way TCP handles it then UDP would make more sense, otherwise in my opinion TCP saves time and is optimized well.

1

Share this post


Link to post
Share on other sites

I'm likely to end up sending data 5-10 times a second (mainly ping packets) if I use this method. How long can I expect the duration to be?

To be honest, I'm not sure what some realistic numbers are. A lot of it depends on the network. hplus might know better.

0

Share this post


Link to post
Share on other sites

I agree: It depends on the network! It's probably better to design robust re-connection mechanics. If you can't get a message through for a second, that may start to severely impact gameplay, and sometimes when some IP address changes route through the Internet, it may take a minute to come back.

2

Share this post


Link to post
Share on other sites

Just want to put this out there, I am developing a client-server 2D TCP networked game, I tried connecting to my game server (hosted at my home) on my laptop though my phones WiFi hotspot (I was further out in the country at the time aswell). That version's build had liquid animation that was compressed -> It ended up running pretty well and latency was within 200ms and this is a game that is not developed for internet through the phone.

 

It would be pointless to use UDP if your going to just reimplement TCP. If some packets can be dropped and/or you want a custom error detection design other than the way TCP handles it then UDP would make more sense, otherwise in my opinion TCP saves time and is optimized well.

 

Well, for my gameplay I think the lag in TCP when moving is sufficiently annoying to detract from the gameplay. Opportunities in my case for predictively animating responses is minimal, so I'm willing to try anything that can reduce the latency.

 

I agree that it's meaningless to implement reliable UDP for a game like this. However, given that my packets are typically on the order of a few tens of bytes, I have more opportunities with UDP. More specifically I can keep resending the all the non-acked data until I receive an ack for them. That way I don't need any ack-timeouts (which is what TCP and many "reliable UDP"-solutions are using).

0

Share this post


Link to post
Share on other sites

I prefer not having ordering at the protocol  layer at all and let individual systems send requests again if they need extra reliability.  Reliable, ordered messaging over unreliable networks just ain't going to happen,and trying to force a square peg into a round hole doesn't work.   I've seen more brittle, unmanageable code because dev's try to create architectures that rely on ordered messaging. 

 

Be wary of larger messages crossing packet boundaries, which is an issue with udp.  

 

As for serialization, I'm firmly convinced that bit level protocols should be a thing of the past.   There is very little to gain from operating at that level, if at all.  I've been using protocol buffers with good success.  They are sparse(no schema data in the message), performant, and cross platform. 

0

Share this post


Link to post
Share on other sites

If you don't have some way to support reliable-in-order where it's really needed, then each dev will try to build it alone in each application system, which is a much worse place to put it than in the network layer proper.

1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0