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#.
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
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.
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.