11
\$\begingroup\$

How do I create unique game IDs which are also user friendly -- so that one user can easily give that game ID to someone else for joining the game.

I am creating my game in Silverlight with C#.

\$\endgroup\$
3
  • 3
    \$\begingroup\$ This is less of an answer, so ill comment. I used a 2 key system. I generated a unique key (UUID) which i store internally. Much like this : 39d7e998-e654-4f8b-9e4b-0e61fe9eaf65. After i make a unique ID, the player's friends can find his profile by searching for his nickname and using the first 4 letters.The chances of there being 2 'microdude:39d7' is pretty slim. If i see collisions, i can make it the first 5 or 6. Making his unique key 39d7e. This is obviously public (the characters) so that his friends can add him directly, and helps for specifying when making games over IM or chat. \$\endgroup\$ Dec 10, 2010 at 8:09
  • \$\begingroup\$ How long do the keys need to stay valid? This would influence how unique they need to be and whether you can reuse old keys or not. \$\endgroup\$
    – Tim Holt
    Dec 10, 2010 at 16:22
  • \$\begingroup\$ @Tim the keys could be valid for at most 2 hrs. \$\endgroup\$ Dec 10, 2010 at 18:36

4 Answers 4

6
\$\begingroup\$

If you have an authoritative source, that problem is easy (which I'm assuming if the user is putting in an ID to connect to a game then that is getting redirected using some central server). Just use an algorithm like http://www.safepasswd.com/ does to make UIDs which are basically dictionary words + small numbers. If the number of servers is relatively small you could even do a naive algorithm that just picks something random until it isn't currently in use.

If you want your clients to be the source of the UIDs, you're going to have to throw away the user friendly portion of those IDs. But it's easier to do on the coding side since you'd just be using System.Guid.NewGuid().ToString(). That is for all intents and purposes guaranteed to be unique 100% of the time. source

Then again, GUIDs are a little overkill. It would be easier to remember IPs or usernames b

\$\endgroup\$
1
  • \$\begingroup\$ good, I think I should go with usernames, atleast they will not be duplicate, and they are even user friendly. thanks :) \$\endgroup\$ Dec 10, 2010 at 18:59
3
\$\begingroup\$

One approach would be to use a dictionary, and select words based on a numbering scheme. Perhaps use a unique 32-bit integer to identify each user and for each of the 16-bit words, index a dictionary (array of words). This way, you can represent their id using actual words and each identifier would be unique.

Another approach would be to implement something similar to what Steam uses: allow users to login with an id they chose themselves, and later let them specify any display id they want. For instance, their login id could be their email and their display name could be their first name. In this way the user can share their unique identifier but also be identified by a name of their choosing.

\$\endgroup\$
1
  • \$\begingroup\$ thank you for your suggestion, I will now use usernames as unique key as suggested by @Tetrad. \$\endgroup\$ Dec 10, 2010 at 19:16
3
\$\begingroup\$

FuzzYspo0N's answer in the comments is a very good one. Basically this problem boils down to making game IDs unique enough to avoid collisions, without making them arbitrarily complex. Standard 128-bit GUIDs get their uniqueness by using local information (like your MAC and other factors) to make the likelihood of a collision between machines very small, then add a random and time based factor to make the likelihood of a collision within that machine very small.

You can follow the same strategy to generate your own IDs. Start with something memorable to the user but relatively unique (if the user has a global username that's a good start, or the machine name/IP), and add other factors until you've generated something unique. By picking something local like machine name, you restrict the set of potential collisions enough that you can start to query if there are any. For example, once you've restricted it to just that user, or just that machine, you know exactly where you need to go to check whether or not that UID is already in use.

For example if I know my username is unique system wide, then MrCranky:1 is a valid UID. If I can check whether MrCranky:1 is already in use (by some other method), then I can just keep trying numbers until I find a unique one.

By using some other factor (like randomness or time), I can increase the likelihood that I pick an unused ID first time. E.g. If you know you can't feasibly create more than one session a second, then using MrCranky:122730 (the current time, to the second) will get me a unique ID that's relatively memorable to the user.

As long as you have some piece of relatively unique information (doesn't have to be perfect, just mostly unique), you can use that as a starting block, and that means the truly unique portion (an integer code of some kind) can be much much shorter, and thus the UID is more memorable.

\$\endgroup\$
1
  • \$\begingroup\$ thank you for your suggestion, I will now use usernames as unique key as suggested by @Tetrad. \$\endgroup\$ Dec 10, 2010 at 19:00
0
\$\begingroup\$

You could use a player's email address as a unique identifier. I'm sure they can remember that :)

\$\endgroup\$
1
  • \$\begingroup\$ thank you for your suggestion, I will now use usernames as unique key as suggested by @Tetrad. \$\endgroup\$ Dec 10, 2010 at 19:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .