• 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
BurdenJohn

UDP in gaming, what do you do when a datagram is lost?

5 posts in this topic

Let's say you want to make a real-time game, perhaps a 2D topdown game.

Things you would do in the game to keep it simple are:

 

- Connect to the server

- Move the player with the keys

- Possibly press space bar to attack

- Send a chat message

 

But what would happen if a datagram from any of these situations get lost?

What would you do?

 

[b]1.[/b] Connecting to the server .

If you send a UDP datagram to the server, the server would take your IP and port and then create a player

based on an ID it gives you, this it how it identifies you every time it receives a datagram from you.

 

But what if upon "connection" (not actually a connection, just a udp datagram that says 'make me a part of your server'), this initial datagram gets lost. Is it right to say that you would just resend it if after a certain period of time you did not receive a reply back from the server?

 

[b]2.[/b] Moving the player/attacking

If at any time we move the player/press a movement key/attack key, we would send a keystroke

to the server telling it what key we pressed/released.

The server would then relay this to all the other clients.

 

But what if this keystroke datagram gets lost? Either upon client->server or server->clients.

Because keystrokes are happening all the time, is it efficient to just resend it all the time?

Or would we just ignore the fact that it got lost along the way because there's a chance that if you press a key again it will most likely make it the next time?

 

[b]3.[/b] Sending a chat message

This would be something that MUST reach the server.

If it got lost along the way, after a certain period of time if we did not receive a reply from the other side/receiving end, do we re-send it?

 

Is it okay to just keep resending datagrams if we know after a certain period of time it did not reach?

And also, what about [b]confirming[/b] if a datagram got successfully sent?

 

If client sends a chat message to the server, and the server receives it, should the server send a reply back to the client to confirm that it received it? What would happen if that [b]reply got lost[/b], what then?

 

0

Share this post


Link to post
Share on other sites

If you're sending "real time data" then as time passes the data changes so you just send a stream of packets and if one goes missing the "first" thing you do is ... nothing.

You just use the latest packet of data and call it good.

As you get into more advanced "lag hiding" you will likely add some interpolation, once you do that you would want to take into account the additional time that has elapsed if you miss a packet.

Send out packets at a nominal fixed rate and put a counter in the packets so you'll know if and how many packets you have missed.

 

If you need to know the data got there, then use TCP.

 

You can use multiple UDP & TCP ports if you need/want to (don't go crazy).

Edited by Shannon Barber
0

Share this post


Link to post
Share on other sites

The Quake3 UDP model constantly sent deltas/differences from the client's last known state to the current game state. The client responds by telling the server which state it's currently up to.
If any data gets lost, everything keeps working fine. The only issue is that both the client and the server need to keep around many frames of old game states (as old as the oldest acknowledgement) so that these deltas can be constructed and applied.

e.g. some traffic could look like:
Client -> I'm at state 6
Server -> Here's delta for 6->8
Server -> Here's delta for 6->7 [ARRIVED OUT OF ORDER - ignored by client, is already at state #8]
Client -> I'm at state 8 [DROPPED - server still thinks client is at 6]
Server -> Here's delta for 6->9 [no problem, client can update from 6 to 9 still, even though it's at 8 currently]
Client -> I'm at state 9
Server -> Here's delta for 9->10 [DROPPED - client experiences a small bit of lag]
Server -> Here's delta for 10->11
Client -> I'm at state 11

1

Share this post


Link to post
Share on other sites

Lots of such solutions exist, but you will build a good solution more quickly if you realize that it is really more a matter of latency than lost data.

 

Ideally, every update is absolute and not one in a string of dependent delta's.  This way, if 1/2 of your packets are lost, the game continues to work fine but updates are roughly half as fast.

 

For player movement, this is often sufficient.

 

But what if you lose unique events like shots fired or attacks made?

 

These require some sort of ACK and possible re-send, or perhaps even duplication.  But even in this case, if your server receive a message essentially saying "I shot Joe seven seconds ago," what should you do with it? You should ignore it. Game-play is better served by a spurious "miss" than by a seemingly random "hit."

 

Many architectures exist for handling these, but lets say you have just these two things to consider: movement and "events" (shots, attacks, etc.).

 

You can perhaps send movements (actual absolution position, rotation, etc.) on some regular schedule (NOT just when they change in the client, but every 1/30th of a second, for e.g.).  If you are worried about a chatty protocol, add an ACK mechanism and stop sending once an [un-changing] position is acked.

 

Then, you can send "events" as soon as they happen and then every [n] ms thereafter until ACKED by the recipient.  [n] would be something you could compute from your percieved latency on the connection.

 

So, for example:

 

* Every 1/30 second you sent a position update, and you just rely on the receiver to get them

* You monitor acks on acked communication and determine the round-trip-time (rtt) is 20ms

* An event (such as a shot) occurs, so you send E + {data about E},  and you starta  timer to go off in [rtt] ms (20 ms)

 

When the timer goes off, you check to see if you got an ACK for E, and if not, you send it again.

 

If other events occur, you append them to the list of events to be sent when the timer goes off.

 

Eventually the events will all be acked and your event list will be empty, or you will decide it is too late (perhaps 1-2 seconds).

 

In general, a good test is to write yourself a proxy that randomly discards 1/2 of your packets and make your game play well using that.  In practice, the internet is very reliable where UDP is concerned, since most routers will prioritize UDP over TCP packets, yet most packet loss is due to congestion and that congestion is almost always TCP traffic.

0

Share this post


Link to post
Share on other sites
In general, you want to structure your netcode in a series of layers:

1) The connection layer, which takes care of ensuring that the client sees the server, and the server sees the client. This may also gather connection statistics (round trip time, etc)
2) The framing layer, which allows you to send multiple messages in the same single network packet.
3) The messaging layer, which takes care of delivering different kinds of messages with different reliability (best-effort, discard-earlier, always-delivered, always-in-order-delivered)
4) The entity layer, which is where specific messages get routed to specific in-game objects/entities/smurfs. This could also have knowledge about things like prediction, latency correction, etc.

Even if you use TCP, there is some work to do in 1), typically to keep the simulation ticks between client and server roughly in sync, and to detect whether the connection has "stalled out."

In 2) you typically end up with some kind of serialization, or type-size-data triplets, on the wire.

In 3) is where you use different mechanisms to achieve the different levels of reliability needed for your game, although on top of TCP, everything will be in order, so that'll be a no-op. It's important that the layer that knows about entity needs (4) chooses the right option. Chat messages should probably be "always delivered once" but not necessarily in order; state updates are typically "discard earlier" and re-sent on a round-robin basis, rather than sent with any specific kind of reliability. All you need there is to make sure that a re-ordered packet doesn't overwrite newer receive state with older.

The rest of your question has to be answered in the context of the particular game and simulation you're implementing, because which specific solution you choose depends on which specific feel you want in your game.
0

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