Solved

RTS  UDP byte[] size for big games?

Posted on 2013-05-23
5
558 Views
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.
Thx
0
Comment
Question by:beavoid
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
5 Comments
 
LVL 86

Expert Comment

by:CEHJ
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 ...?
0
 

Author Comment

by:beavoid
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.
0
 
LVL 86

Expert Comment

by:CEHJ
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)
0
 
LVL 36

Accepted Solution

by:
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?
0
 

Author Closing Comment

by:beavoid
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.
0

Featured Post

[Webinar] Learn How Hackers Steal Your Credentials

Do You Know How Hackers Steal Your Credentials? Join us and Skyport Systems to learn how hackers steal your credentials and why Active Directory must be secure to stop them. Thursday, July 13, 2017 10:00 A.M. PDT

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Are you developing a Java application and want to create Excel Spreadsheets? You have come to the right place, this article will describe how you can create Excel Spreadsheets from a Java Application. For the purposes of this article, I will be u…
Java Flight Recorder and Java Mission Control together create a complete tool chain to continuously collect low level and detailed runtime information enabling after-the-fact incident analysis. Java Flight Recorder is a profiling and event collectio…
This tutorial covers a practical example of lazy loading technique and early loading technique in a Singleton Design Pattern.
This tutorial will introduce the viewer to VisualVM for the Java platform application. This video explains an example program and covers the Overview, Monitor, and Heap Dump tabs.

728 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