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

UDP in a FPS

8 posts in this topic

Hi.

Im creating a multiplayer FPS. The multiplayer allready works but it uses TCP/IP. I want to move to UDP but theres one thing i want to understand first. Firstly il briefly explain how my current simple protocal works. (Its most likely very naive. I dont realy have any experience with network programming).

the first 2 bytes in every message indicates the length of the message. the next byte indicates the message type and the rest of the bytes is the actual message. dead simple.
so for example if the client sends its position and direction to the server (wich is 5 32 bit floats. 3 for position and 2 for rotation) the integer value of the first 2 bytes together would be (2 + 1 + 5*4) = 23. the next byte (wich is the message type indicator) would be 2 (message type 2 means its a position and direction update from client to server) and the remaining 20 bytes would be the 5 floating point values.

Another example would be the server sending the position and direction of another client to a client. Its similar to the above example except that the message also includes a byte that contains a client ID. So the integer value of the first 2 bytes together would be (2 + 1 + 1 + 5*4) = 24. the next byte (wich is the message type indicator) would be 3 (message type 3 means its a position and direction update from server to client). the next byte would be the ID of client wich position and direction is being updated and the remaining 20 bytes would be the 5 floating point values.

The logic behind using UDP (as i understand it) is that if data (like the data in the above examples) gets lost its better to just wait for the next update than it is to resend the lost data since by the time its resent it will most likely be outdated but how do i know if a message got damaged by data lost? lets take my last example. its a message that consists of 24 bytes. Lets say one of those bytes goes missing. It will still read 24 bytes. Meaning that its going to read the first byte of the next next message...

How do you get around this? is there a way to find out if bytes goes missing so i can discard the whole message? Or should redesign my protocal?

Thnx in Advance!
0

Share this post


Link to post
Share on other sites
Hello Wilhelm,

With UDP, what you send is what you get; but you might get it out of order or not at all. At the layer we're working at, you won't be seeing any damaged packets. I think you can disable checksumming to allow damaged packets but luckily it's not disabled by default.
1

Share this post


Link to post
Share on other sites
<P>Thnx I didnt know UDP works like that. i thought it was also just one continious stream of data. Didnt know you got split into packets and each packet gets checksummed. <BR><BR>I have one more question then. using udp for updating position and rotation is fine but what about shooting? if one client shoots his gun and the packet containing that information gets lost that would be bad seeing as the "shoot" data would only be sent once. Should i use a TCP/IP connection alongside my UDP connection for data that may not get lost.</P>
0

Share this post


Link to post
Share on other sites
[quote name='Wilhelm van Huyssteen' timestamp='1312449197' post='4844412']
<P>Thnx I didnt know UDP works like that. i thought it was also just one continious stream of data. Didnt know you got split into packets and each packet gets checksummed. <BR><BR>I have one more question then. using udp for updating position and rotation is fine but what about shooting? if one client shoots his gun and the packet containing that information gets lost that would be bad seeing as the "shoot" data would only be sent once. Should i use a TCP/IP connection alongside my UDP connection for data that may not get lost.</P>
[/quote]


You could use this library: [url="http://enet.bespin.org/"]http://enet.bespin.org/[/url]

It implements reliable UDP communications so you don't have to. There are python bindings (pyenet) too.
0

Share this post


Link to post
Share on other sites
[quote name='Wilhelm van Huyssteen' timestamp='1312449197' post='4844412']so for example if the client sends its position and direction to the server ....
I have one more question then. using udp for updating position and rotation is fine but what about shooting? if one client shoots his gun and the packet containing that information gets lost that would be bad seeing as the "shoot" data would only be sent once.
Should i use a TCP/IP connection alongside my UDP connection for data that may not get lost.[/quote]You can use TCP alongside for must-be-reliable data, or you can use a reliable-UDP wrapper library for this data.

However, backing up for a moment, your design sounds very fragile for an FPS -- ideally shooting wouldn't need to be a reliable message at all, and the client should not be sending their position to the server (it should be the other way around). Some links on other designs below.

Quake3:
[url="http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking"]http://trac.bookofho...uake3Networking[/url]
Source:
[url="http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking"]http://developer.val...ayer_Networking[/url]
Unreal:
[url="http://udn.epicgames.com/Three/NetworkingOverview.html"]http://udn.epicgames...ngOverview.html[/url]
[url="http://web.archive.org/web/*/http://unreal.epicgames.com/Network.htm"]http://web.archive.o...com/Network.htm[/url]
Gaffer:
[url="http://www.gafferongames.com/game-physics/networked-physics/"]http://www.gafferong...worked-physics/[/url]
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1312463329' post='4844457']
You can use TCP alongside for must-be-reliable data, or you can use a reliable-UDP wrapper library for this data.
[/quote]

From the Gaffer On Games website that you linked to in your post, in his [url="http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/"]UPD vs. TCP article.[/url]


[quote[font="Arial"]][color="#111111"][b][size="2"]Wait? Why can’t I use [i]both[/i] UDP and TCP?[/size][/b][/color][/font][color="#111111"][font="Arial"][size="2"]For realtime game data like player input and state, only the most recent data is relevant, but for other types of data, say perhaps a sequence of commands sent from one machine to another, reliability and ordering can be very important.

The temptation then is to use UDP for player input and state, and TCP for the reliable ordered data. If you’re sharp you’ve probably even worked out that you may have multiple “streams” of reliable ordered commands, maybe one about level loading, and another about AI. Perhaps you think to yourself, “Well, I’d really not want AI commands to stall out if a packet is lost containing a level loading command – they are completely unrelated!”. You are right, so you may be tempted to create one TCP socket for each stream of commands.

On the surface, this seems like a great idea. The problem is that since TCP and UDP are both built on top of IP, the underlying packets sent by each protocol will affect each other. Exactly how they affect each other is quite complicated and relates to how TCP performs reliability and flow control, but fundamentally you should remember that TCP tends to [i]induce[/i] packet loss in UDP packets. For more information, read [url="http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM"]this paper[/url] on the subject.[/quote]

But I totally agree that the current setup sounds broken: it sounds trivial for a hacker to send false packets and teleport, etc. wherever they want. Reading all the Gaffer's networking articles is probably your best bet.

[/size][/font][/color]
2

Share this post


Link to post
Share on other sites
Thnx for the replies. I will read through those articles and improve my desighn. For the time being though (just to get the game up and running) I will use TCP alongside UDP for data that should be reliable data.
0

Share this post


Link to post
Share on other sites
There is also reliable udp to look into ;)
There are some simple technical reasons why UDP is preferable to TCP, my argument would be based on the IP carrier's collision avoidance mechanism.
Imagine a network as a busy highway, and now imagine a TCP packet with its typical MTU window of around 1500 bytes, and a UDP packet with its typical MTU window of about 500 bytes, as being a greyhound bus, and a volkswagen beetle, the only two kinds of vehicles on the road.
Guess who has to wait longer to fit into a suitable gap in the traffic?
0

Share this post


Link to post
Share on other sites
You cant really use TCP for reliable data in First Person Shooters. There are different types of data that are reliable which if sent over TCP would cause your game to be unplayable. Simply put, FPS must be over UDP, anything else will cause problems.

There is no reason to use TCP when there are simple alternatives, like ENet, which support both reliable and unreliable data sending over UDP.
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