next »

[Martin 2BAM]

I am not sure it's an issue.
There is a difference between latency and throughput.

...

Unless you have a lot of simultaneous entities.

"Bullets" seem like a multiple simultaneos entity situation.

Size has influence in network congestion, fragmentation and packet loss.
A realistic MTU for internet UDP packets is around 500-1500 bytes; so a very bareboned 5 int frame (ID, x, y, velocity x, velocity y) will leave you with about 10-40 entities to be updated per frame.
Larger packets could pile up fragments and increase latency. Depending on the route, fragments could easily be discarded dropping the whole packet.

The minimum size guaranteed to not fragment is 576 for IPv4 and 1500 for IPv6, same as ethernet.

[PompiPompi]

Average_software, it won't be a concern since it practice it will never reach 2^32. And I start the count from 0.

BorisTheBrave, "might as well using the address", are you trying to save one unsigned it? Why is it "might as well"?
GUID is an overkill and unnecessary, since the ID is a way to identify a bullet between a client and server, not between all applications in the world.
The client will have his own local ID for the bullets, and the server is the authority on bullet simulation.

nitram_cero, doesn't seem like you were writting amultiplayer game lately. I am sending a packet per bullet and it's fine.
I don't think there are many FPS games that do their entire networking in a single 500 bytes packet.
Edit: And I say it again, what you save by sending a single 500 bytes packet for your entire game is almost worthless compared to the network latency. You don't seem to understand that and seem to have your pride on the line here.

[Martin 2BAM]

Suit yourself.

I won't be getting a lecture on pride from a person that has a banner as signature on how "popular" he is on Indie DB.

[ThemsAllTook]

Let's keep this discussion technical and save personal attacks for another time, please.

[nickgravelyn]

This makes everything easier to generate and deal with IDs since an unsigned int maximum number is 2^32-1.

unsigned int is 2^64-1 on my system, have you considered that?

Isn't that even better?
He assumed 2^32-1 as standard, since that's the lowest for any decent PC (32-bit, I guess). I don't think here he has to consider somebody who is above that limit. He'll simply treat them as if they have 2^32-1.

My concern is that if you refer to say, std::numeric_limits<unsigned>::max(), the numbers could be very different.  If you have a 64 bit server for example, you could end up with a situation where you're passing IDs to 32 bit clients that are too large,

If it's available in your environment, you can bring in stdint.h and use the integer types like uint32_t which have guaranteed sizes. I'd recommend that for any networking code to ensure all clients (and server, if it's not one of the clients) are using the same sizes for data types.

http://www.cplusplus.com/reference/cstdint/

[BorisTheBrave]

BorisTheBrave, "might as well using the address", are you trying to save one unsigned it? Why is it "might as well"?
GUID is an overkill and unnecessary, since the ID is a way to identify a bullet between a client and server, not between all applications in the world.
The client will have his own local ID for the bullets, and the server is the authority on bullet simulation.

I mean, we've spent two pages talking about how to efficiently assign ids, and the pros and cons of wrapping around. The address of the object already fulfils both those criteria, so why write any code? It's not about saving space (which it probably won't).

I said you only need guids if you don't have a central authority.
Some data per bullet per frame seems a huge amount of data, but the same data once per bullet is not a big deal. (most games have a lot of bullets). I presume PompiPompi is doing the latter, with dead reckoning of where the bullets likely are. I think this is where the confusion lies.

Nitram explained how additional packets can lead to latency. I thought it was a pretty good explanation - I know that most commercial engines expend a lot of effort to keep bandwidth down. That said, I don't think 4 bytes is a deal-breaker.

[PompiPompi]

I agree with what you said but not about the address of the object.
What is the "Address of the object"?
I don't hold up the bullet data indefinitely, which means it can be deallocated and it's virtual address can be reused.
Also, virtual addresses has at least 1 GB of address which are not used by the process. (assumnig 32 bits).
You could say that assuming no reusing of address it will run out of memory first anyway, but we do reused virtual addresses.

[BorisTheBrave]

Yes, the addresses get re-used. But they are guaranteed not to be used twice at the same by the different objects. That is exactly necessary amount of re-use.

See e.g. this

[PompiPompi]

Well yea, but the life time of the two objects may overlap on the client even though they don't overlap at the server. It just makes it all more complex to handle..
Instead of just using something that is guaranteed to be unique for any practical purpose.
i.e. assuming nobody is gonna play the game 1000 hours straight.

Edit: Also, whether you send bullets every frame or per instance, it doesn't change the fact that you can send more than one datagram per frame.
This all sound like premature optimizations.

[Xecutor]

If every object in the game gets it's ID from the same counter, you might want to divide this counter into two (or probably more) ranges.
For example range 1..100000 is for more or less persistent objects, or at least objects that live long enough. And 100001..(2^32-1) is for bullets.
When the counter for bullets overlaps (2^32-1) set it to 100001.
When the counter for long living objects reaches 100000... the game should crash with appropriate error message, so you can change this 100000 to 200000 or even 1000000

[PompiPompi]

Sounds pointless...
If the counter overlaps I will just post a message on the screen "Get some sleep"

[saluk]

I want to play a game that has 4 billion active bullets in the sim.