• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 573
  • Last Modified:

RTS UDP byte[] size for big games?

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.
Thx
0
beavoid
Asked:
beavoid
  • 2
  • 2
1 Solution
 
CEHJCommented:
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 ...?
0
 
beavoidAuthor Commented:
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.
0
 
CEHJCommented:
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)
0
 
mccarlIT Business Systems Analyst / Software DeveloperCommented:
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?
0
 
beavoidAuthor Commented:
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.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now