UUIDs vs. RNG

[LB]

Minecraft gives every entity a UUID so that references to entities can be saved in a reasonable format.

In C++, is there any reason to use some library to generate UUIDs instead of just using the standard library random classes to generate some random numbers?

[MiiNiPaa]

Sure you can genereate UUID yourself, but make sure that it follows RFC: http://tools.ietf.org/html/rfc4122

You need to make sure that Variant and Version are set to correct values

[LB]

Is there any reason to do that though? Why not just generate two random 64-bit integers?

[MiiNiPaa]

Because de-jure it would not be an UUID and will be just random 128bit number.
There are several ways to generate UUID, and 122 random bits is just one of them. To distinduish between different ways of generating UUID, there are special bits which allows to do that.

[S G H]

what about storing a global integer starting from 0.
Each time you need a unique id, you copy it, then increment it afterwards.
Poof, unique ids, no random number generator overheads and your values can only match after meeting 4 billion entities, and by that time, all the previous entities will have despawned (careful to pets! always check if an ID is already in use).

[TheHardew]

There would be no need to have global variables and copying if entity was a class. Then you could just have one static unsigned for all objects.

[chrisname]

@EssGeEich
I'm not sure that would work for a game like Minecraft. You couldn't, for example, save an object from one game and import it into a different game (serialising and deserialising) . I'm not sure if Minecraft allows that, but if you use UUIDs or random numbers from the start,

@LB
The only reason is conforming with an existing standard, really. You can generate two 64-bit integers or a string of 16 bytes or whatever if you want, and you can put hyphens in it and call it a UUID, but it's not a UUID. It is a universally-unique identifier to the same extent as a UUID is, but it's not a UUID.

(The only difference between that and a (version 4) UUID is that a UUID has the version numbers encoded at the 6th and 8th bytes.)

[LB]

@MiiNiPaa: I meant to ask, is there any reason to call it a UUID and conform to the standard?

@SGH: As chrisname points out, this is not an option because parts of maps can be imported and exported.

@chrisname: Thanks, that's the answer I was looking for. I can totally ignore the UUID standard if I want, I just wont refer to my 'thing' as a UUID.

[MiiNiPaa]

I meant to ask, is there any reason to call it a UUID and conform to the standard?

As with all other standards. So people which would read and use your code would not get strange result when they will assume that your UUID is standard conforming.

As you told, use whatever you want, just do not call it UUID when it is not.

[S G H]

It STILL is an option as long as you constantly check for duplicates.

Side note: You need to check for this kind of problem with UUIDs too.

@TheHardew: A class static member is not much different from a global. It is simply a global inside a class declaration.

[TheHardew]

At least it won't affect anything outside the class. Less problem-prone! And most computers wouldn't handle 2³² - 1 entities, so it'd not duplicate id. Copying entitys between worlds would be easy if there was one variable per world. Id would be created from variable counting entitys from 2nd world. One disadvantage I can think of would be that you wouldn't be able to use the same id after copying.

[LB]

EssGeEich wrote:

It STILL is an option as long as you constantly check for duplicates.

There will be duplicates most of the time, in contrast to almost never. If two players start new worlds and their entity IDs are sequential and starting at zero, there's comparatively a really high chance of collision when you export from one world and import into the other.

Compare that to a one in 2¹²⁸ chance of generating the same random ID twice. IIRC the expected lifetime of the universe is shorter than 2⁶³ seconds...

[Cheraphy]

Heat death is is expected to be 10^1000 years after the big-bang. 2^63 seconds is around 2.9 *10^11 years.

Incidentally, today I learned you'd need a 4096-bit processor to natively express the approximate year of the heat death of the universe in a single POD.

[LB]

I did not recall correctly then.

[chrisname]

The only reason to conform to the standard in your own code which doesn't have to interface with anything that already exists is: it's what people expect. It's a small point by itself, but every thing different to what people expect is something additional they have to consider when reasoning about your program. If you use something else, people will be asking themselves why.

If you code has to interface with other code, then it's even more important to agree upon an existing standard. You can make your own, but it's best to do that only if existing standards aren't sufficient, again because it's what people expect.

But to answer your question directly, no, there's nothing inherently better about using version 4 UUIDs over random 128-bit integers. Like I said, literally the only difference is that the former has the version (0x4) and variant (0xA) encoded (left-shifted by 4 then OR'd) into the 4th and 6th bytes respectively.

[LB]

I had no further doubts or confusion about what was being said; I was just replying to SGH.