RTS  UDP byte[] size for big games?

Posted on 2013-05-23
Last Modified: 2013-05-24
For my Java RTS,

I am thinking 4096, even, isn't enough room for the visual game state.
If the server keeps the game state, and sends each client valid vision,
if there are up to thousands of units in very large, 6,8 player games, mostly all of the units may be visible in one scene.

This makes the state byte array complicated.
If the byte array needs 16 bytes per unit, - unit number, x pos( 4 bytes, integer), y pos( 4 bytes, integer) unit type (4 bytes, integer)
How should I be sending the game state to each client, every 200 ms - a senderThread?
That means for 1000's of units, the byte[] length must be vast?

Do I send game state messages as single messages, like server replies for each receive?

Previous questions have determined I must keep the game state on the server.
Question by:beavoid
  • 2
  • 2
LVL 86

Expert Comment

ID: 39192024
If the byte array needs 16 bytes per unit, - unit number, x pos( 4 bytes, integer), y pos( 4 bytes, integer) unit type (4 bytes, integer)
So that looks like 12 bytes?

How should I be sending the game state to each client, every 200 ms - a senderThread?
A  udp broadcast?
That means for 1000's of units, the byte[] length must be vast?
Why - it looks like 12 bytes ...?

Author Comment

ID: 39192173
12 bytes for each unit
There are possibly 1000's units.
But UDP messages are best if small. I don't see any other way.
LVL 86

Expert Comment

ID: 39192693
Oh i see. I thought at first that 'unit' meant peer. You probably should be making a trade-off between packet size and the overhead of sending them out. Don't forget that some of the packets will probably get dropped, so the bigger they are, the worse the consequences (potentially)
LVL 35

Accepted Solution

mccarl earned 500 total points
ID: 39193114
Some thoughts...

You generally want to keep your UDP packets small enough so they dont get fragmented, especially if it is easy enough for YOU to fragment the data in the application, which by the looks of the above should be true, ie. you can send the first X number of units data in one packet and then the next X number of units in the second, etc. Why do you do this? Well, if there is any chance of packet loss on the network between your server and the client, then having larger packets that get fragmented by the network (rather than by you) just increase the rate of data loss. If you send a 1000 byte packet into the network and the network splits that up into 2 packets at some point, then if either of those two packets get 'lost' then the entire 1000 bytes gets 'lost'. However, if you split the data up yourself into 2 packets of 500 bytes, and one of them gets 'lost' you only lose that 500 bytes of data, the other 500 bytes gets to client ok.

As for your game state data, I assume that it is 16 bytes, you just didn't explicitly say that the unit number was a 4 byte integer too. However, think about this... if those 4 data items in your game state are all 4 byte integers, that means that you are supporting up to 4294967296 units, that are positioned on a 4294967296 x 4294967296 grid, and can be any of 4294967296 unit types. That's all a bit of overkill I would think. Go with 2 byte integers (which I sure is still plenty sufficient) and you have halved your game state data! Also, does the unit type change multiple times a second (or even at all once the unit is created)? If not, then don't send it in even state update... just saved yourself another 25% bandwidth.

3rd thought... Do you need to send the state of every unit on every update cycle? If a unit hasn't moved, don't send an update for it. That way you still might have 1000's of unit visible, but you might only need to update some percentage of them.

Depending on exactly the dynamics of your game, given what I said in the last paragraph, maybe a lot of the units are moving but MOST of the time they are just moving in one direction. Perhaps then you could ADD a speed vector (ie, x speed and y speed) to your game state, and then you only need to include that unit's state update whenever it starts moving, stops moving or changes direction. That way you COULD have all 1000 units moving on the map but with very minimal state updates.

Last thought... At the start of each UDP packet, you would probably want to include the 'game clock' that all state updates in the packet occur at. This would help if you do end up using a "speed vector" as above, but also can be used as a type of UDP packet sequence number. You do know that UDP packets can arrive out-of-order, yeah?

Author Closing Comment

ID: 39195416
Thanks mcCarl

I think the size needs for a big RTS game are making the old server-collects-and-distributes model better for me.. There is just not enough room in the byte array for massive RTS situations.

Featured Post

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Go is an acronym of golang, is a programming language developed Google in 2007. Go is a new language that is mostly in the C family, with significant input from Pascal/Modula/Oberon family. Hence Go arisen as low-level language with fast compilation…
Performance in games development is paramount: every microsecond counts to be able to do everything in less than 33ms (aiming at 16ms). C# foreach statement is one of the worst performance killers, and here I explain why.
Viewers will learn one way to get user input in Java. Introduce the Scanner object: Declare the variable that stores the user input: An example prompting the user for input: Methods you need to invoke in order to properly get  user input:
Viewers will learn about if statements in Java and their use The if statement: The condition required to create an if statement: Variations of if statements: An example using if statements:

759 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

24 Experts available now in Live!

Get 1:1 Help Now