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

How do I judge how much data I can regularly send to players?

10 posts in this topic

Hey,
 
I've been programming a prototype for an online game lately and I've been fretting about sending too much data, but I've never really been sure of how much is 'safe' to send regularly.
 
I've read from an old post in this forum that a general guideline for how much data to include in a packet is 1300 bytes, but how do I know how much I can send per second to my clients to remain safe?  Of course, it depends on the client's Internet speed, but what guidelines can I go by to determine how much data I can afford to send per second?  How do online game programmers usually go about this?
 
Any advice would be appreciated.  Thank you!
0

Share this post


Link to post
Share on other sites

I would assume it's about sending the least amount without sacrificing the gameplay. How much you send should be fairly easily tweaked in whatever you setup. This way you can test what works best.

1

Share this post


Link to post
Share on other sites
It's generally better to send only what you need, and then actually send that.

If the recipient cannot keep up, detect this, and drop them from the game, rather than trying to cram a size 10 body into a size 2 dress. Nobody will like that outcome!

This means that your game design will exclude some number of players "from the bottom" in network connectivity. You're already excluding some number of players with whatever OS, graphics, CPU, RAM, language, and other choices you're making in the game design, so networking really is no different. Find a level that you can comfortably support with your development resources, and stick to that.

Regarding how much you can, and should, send, that varies very much based on what kind of game it is, what kind of demographics you're targeting, and other context. For action games targeting North America, I'd suggest that more than 32 kB/s is starting to push it. For comparison, I don't know what the console tech cert requirements are these days -- it used to be 8 kB/s, but that was the previous generation, and infrastructure may have improved since then.
2

Share this post


Link to post
Share on other sites

Thank you for the thorough responses!

 

I've been measuring how much data the clients get on average per second, and it usually sticks around 220 bytes at the moment, give or take.

 

It's not a finished game (or near finished), though...it's a MOBA game (like Dota 2, League of Legends, and so on) and right now all I have implemented is the players, who weren't moving or casting spells at the time, and the creeps, 15 per team per wave, which run down lanes and target and attack each other.

 

All that's really being sent during the test is messages for the health of creeps that have taken damage since the last message was sent, and messages for when creeps are changing targets.

 

On a side note, I'm actually not sure if this way of measuring it is even legitimate, though...it seems like I'm only recording the actual amount of data I put in the message when I make the averages, but I read this post and the second paragraph seems to say that messages regularly contain extra bytes of data inside them – if I understand correctly, 112 bytes for IPv4 or 132 bytes for IPv6.  Does that apply to Lidgren messages?

0

Share this post


Link to post
Share on other sites
The overhead of a single UDP datagram is 28 bytes, plus whatever link layer overhead (Ethernet, ATM, etc.)
The overhead of a single TCP packet (trying to fill the send window) is 40 bytes plus link layer.
Lidgren actually adds its own framing, too, if I understand it correctly. I don't know how much.

When it comes to DotA-type games, I believe those are typically implemented as deterministic simulations (like Warcraft or Starcraft or Age of Empires) so the only data you need to send is the commands for each player for each command tick. This is a tiny amount of data.
2

Share this post


Link to post
Share on other sites

The overhead of a single UDP datagram is 28 bytes, plus whatever link layer overhead (Ethernet, ATM, etc.)
The overhead of a single TCP packet (trying to fill the send window) is 40 bytes plus link layer.

 

Sorry if this is kinda offtopic but i have a question. Overheads seem to be very large and nearly always larger than packages i send to or receive from clients.

As a client should i collect all data i want to send into a string and send it at the end of my frame? Because I just sent input changes and stuff right away, yet. Same question for servers.

Or won't things i send be splitted into lots of packages anyways?

Edited by Ichi
0

Share this post


Link to post
Share on other sites

Or won't things i send be splitted into lots of packages anyways?


TCP may buffer some data you send, and coalesce into a bigger packet. However, most games turn this behavior off using TCP_NODELAY (turning off Nagle's algorithm.)
UDP will not buffer anything, but send one datagram per call to sendto().

You absolutely want to buffer everything you want to send in the game. It is typical that games send data on a fixed schedule -- say, 20 times a second. All messages generated are queued, and put into a single packet and sent whenever that timer expires. This means that messages also need timing information -- which tick was this message generated at?

The actual tick rate used varies by game genre and preference.
1

Share this post


Link to post
Share on other sites

Thank you for your response.

 

Tickspeeds are not constant most of the times and i could just lie to the server and tell him i lag to make my actions happen earlier than they happen even if it are only milliseconds. I think I might get the idea but i don't get how to acually code it.

0

Share this post


Link to post
Share on other sites

Tickspeeds are not constant most of the times


My advice is to make them so :-) Make the simulation tick speed constant, and the networking tick speed constant. Rendering can still be free-running and can use interpolation to render faster than simulation.

Here's the canonical game loop for fixed tick speeds: http://www.mindcontrol.org/~hplus/graphics/game_loop.html
0

Share this post


Link to post
Share on other sites

Might also be worth mentioning (if you havent already looked into it)  to see how much you can compress the data (retaining its completeness, accuracy etc..)

 

Sending partial data between intervals of full 'sync' data being sent can sometimes work.

 

Depends on your game mechanics and gameflow whether you can improve anything.

 

Sometimes (1300 byte block... ) even a zip type or even a RLE can be done  (with added program complexity....)

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