Unique ID generation

Started by
6 comments, last by Metron 21 years ago
Hi, I''ve been browsing around (means I googled a lot) but I cannot find any useful information on Unique ID generation. What I need is a unique ID that is generated into a ulong64. I''ve tried to use the approach that is taken for online shops, where they use the date and the time to generate the ID. Unfortunately this doesn''t work for me since I *could* generate several thousand IDs and they would all be the same. If anyone has some info on this topic or a link to a site on this topic, please share it Kind regards, Metron
----------------------------------------http://www.sidema.be----------------------------------------
Advertisement
unfortunately I only know of 128 bit unique ids, called GUIDs (globally unique identifiers) or UUIDs (i forget) ... which by the way are 2 names for the EXACT SAME THING ... this is what microsoft and COM uses for all classid''s etc ... so if you have any way you can afford 128 bits, then you should search on COM, or GUID, etc ... by the way, there are already programs for generating these, which are readily available.

I know microsoft has an activeX control called guidgen and also a program of the same name which uses the control and comes with visual studio.
Hi,

it would be possible to use 128 bit IDs but this would mean a huge changement within my current engine.

I''m using those IDs to identify objects and sectors within my 3D engine.

Well... I keep looking...

Thanks anyways,
Metron
----------------------------------------http://www.sidema.be----------------------------------------
Note ... in what SCOPE do they have to be unique ... just during one run? Just on one computer? Or do they have to be totally uniique accross multiple runs, and generated from different computers?

The reason I ask because if they only have to be unique on each machine (or if every machine can ask one master machine to do all the generating) then this is possible ... as long as you make sure you are not going to run into any wrap around problems ...

in fact ... it can even be trivial ... I have a GameObjectDatabase library which I made, which is a singleton ... and which supports loading saved objects and generating new ones ... they all have unique 32 bit ids ... and all I do to handle the situation is this ... the manage knows the LOWEST_ID, and the HIGHEST_ID ... and it just increments by 1 when it makes an object ... this ONLY works if loading a saved file sets the LOWEST and HIGHEST values, AND if it resets everything to the old state ...

Many variations can be used to satisfy various needs (say you want a more even distrobution accross the available range ... or you want the next number to be unpredictable from people trying to hack or fake things) ...
Hi,

they have to be unique when they get created in the editor. I suppose that it would be pure (un-)luck if on two seperate computers, two guys working with my editor would create a sector in the same instance (day/month/year/hour/minute/second/millisecond).

Means : They have to be unique on multiple runs on multiple computers... but only when they are created within the editor. In game, the IDs are those generated *by* the editor.

Kind regards,
Metron
----------------------------------------http://www.sidema.be----------------------------------------
OK, a way to try and guarantee ids from different computers are not equal is to use the unique 48 bit MAC address in your system ... but since you only have 64 bits, and want to use time ... this would be tough ... here''s another option ... Do you have a central server? a website which can run php and mysql or something similar?

If so, when they install the editor, they can go to your website and ask it to "Get a free editor key", which will generate a key on a web page for them to enter into their editor, and store it in your database so you won''t ever give the same id to a different editor ... this ID can be as small as 16 bits ... which would allow 65,536 editors to be used (24 bits would allow over 16 million editors if you worry about eventually becoming REALLY popular). So if you use 24 bits for a key, then you have 40 bits left for a time format ... which hopefully can give you sufficient resolution, without rollover.

One way to do this, is to decide, what is the most number of items they will ever need to create / register in a certain span of time, for example maybe 256 in one minute, or second ... then you can use that many bits for a simple count, and the leftover bits for simple calender time ... such as

24 bits - key
32 bits - date and time
8 bit - count
(vary the exact sizes to suit your real world needs)

this only works if you can fit an appropriately accurate time stamp in the available number of bits ...

here is a fairly naive possibility (there are much better out there)
year - 6 bits (64 year program life ... oh no)
month - 4 bits
day - 5 bits
== 15 bits for date
hour - 5 bits
minute - 6 bits
second - 6 bits
== 17 bits for time

it fits exactly ... and it REALLY REALLY ugly and nasty to work with ... but it proves it is at least possible.
Hi,

Dunno if this may help, although it does generate a GUID - 128bits...maybe you could strip some of the numbers from the string?

GUID guid = {0};
LPCSTR pstrGUID = NULL;
WCHAR wszGUID[80];

::CoCreateGuid(&guid);
::StringFromGUID2(guid, wszGUID, sizeof(wszGUID)/sizeof(WCHAR));
pstrGUID = W2CA(wszGUID);

Regards,
Steve

If it isn't working, take a bath, have a think and try again...

Just keep a counter (in a static) and increment it every time you get an ID out of the function...

This topic is closed to new replies.

Advertisement