Sign in to follow this  
Quasimojo

Data type for object ID's in MMORPG

Recommended Posts

I'm working on a text-based (for now) MMORPG. Well, I should probably call it a SMORPG (Sorta Multiplayer...). Anyway, I'm trying to decide on the best data type to use for ID values for every interactive item in the game, including items, player characters, non-player characters, etc.

My first thought was just to use an unsigned long int. However, as monsters are killed and items are destroyed, over time I can see reaching the upper limit for valid ID values.

Next I considered other games I've played in the past that utilized a separate ID value for each type of object (e.g. Goblin_174598, woolen_cape_6540, etc.). However, that means I would need to use a char[] data type, and I don't know how that might effect performance on object lookups and such.

As I see it, my choices really boil down to huge int values or char arrays. What might I consider as far as pros and cons of each go?

Share this post


Link to post
Share on other sites
Your options are:
16 bits
32 bits
64 bits
128 bits
arbitrary string

That is in order of performance & bandwidth. 128 bits is the size of a GUID (globally unique id), so there is absolutely no reason you'd need to go beyond that into arbitrary strings.

Just typedef the thing or put it into a struct. Start with 32 bits, you'll probably never need to increase it.

EDIT: Think about what you're doing with "Goblin_174598, woolen_cape_6540". You're essentially taking 1 id for the type and 1 id for the instance, but instead of using 1 integer, you're using a string (which is waywaywayway slower). To do something like this, you'd have the type id in the high bits and the instance id in the low bits, so you can still do integer compares.

Share this post


Link to post
Share on other sites
A few things to keep in mind.

Managing unique Ids is a pain in the ass, particularly if they are persistent. If it has to be unique go with a Guid you will save yourself a whole lot of work.

Some Ids are persistent and must never be duplicated while other Ids are temporary and can be reused. For example a player account Id would be persistent but an NPC instance Id can be reused.

Ids have domains and only have to be unique within their domain. For example persistent player account Ids must never collide with each other but there can be an item with the same Id value. Your code should never try to take a player Id and use it as an item Id.

Ids also have scope. For example an Id that is scoped to a client connection can be used to identify different things to different clients.

The fact that ids have domains is very useful when you're dealing with things like resource Ids. I always use string hash ids for resource ids. This may seem dangerous since hash values can collide but because resource Ids are broken up into domains like texture, sound, script, model, shader, etc. the chance of collision is extremely low (I think I've seen one in 10+ years of using them).

A virtual player Id is a good example of a scoped Id. If you use a Guid for your player Id and you don't want to send that Id back and forth between your client and server you can negotiate a virtual Id that is only valid when communicating with that particular client. The Id is scoped to that client. For example when the client connects they send you a 128 bit player Guid (in the real world you probably don't want to send account and player ids to the client, is a security risk). In response the server sends the client a virtual 1 byte player Id. From that point on when that client wants to communicate the player Id to the server is uses the 1 byte virtual Id.

Share this post


Link to post
Share on other sites
Quote:
Original post by CadetUmfer
Your options are:
16 bits
32 bits
64 bits
128 bits
arbitrary string

That is in order of performance & bandwidth. 128 bits is the size of a GUID (globally unique id), so there is absolutely no reason you'd need to go beyond that into arbitrary strings.

Just typedef the thing or put it into a struct. Start with 32 bits, you'll probably never need to increase it.


Quote:
Original post by Scythen
A few things to keep in mind.

Managing unique Ids is a pain in the ass, particularly if they are persistent. If it has to be unique go with a Guid you will save yourself a whole lot of work.


My concern is that over time, with players killing monsters and using items - both of which would re-spawn periodically - the game would exceed the limits of the data type I use. At the same time, minimizing the size of data packets being transferred back and forth with the server is an important factor. Perhaps 16-bytes wouldn't be too much overhead.

Is there a platform-independent way to generate GUID's?

Quote:
Original post by Scythen
Ids also have scope. For example an Id that is scoped to a client connection can be used to identify different things to different clients.


In that scenario, you're still talking about a connection ID plus an object ID, right? I guess a typedef would be the best way to handle that?

Share this post


Link to post
Share on other sites
Quote:
Original post by Quasimojo
My concern is that over time, with players killing monsters and using items - both of which would re-spawn periodically - the game would exceed the limits of the data type I use. At the same time, minimizing the size of data packets being transferred back and forth with the server is an important factor. Perhaps 16-bytes wouldn't be too much overhead.

Quote:
Wikipedia
: The total number of unique keys (2^128 or 3.4*10^38 - in relation there are about 1.33*10^50 atoms on earth) is so large that the probability of the same number being generated twice is extremely small, and certain techniques have been developed to help ensure that numbers are not duplicated.


Dont worry, you will never run out of new unique Ids. If you use a virtual ID system you will probably need to transmit a 1 or 2 byte ID most of the time.

Quote:
Original post by Quasimojo
Is there a platform-independent way to generate GUID's?


Yes, you can create GUIDs on any platform. See the Boost Uuid library.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this