One of the most engaging ways to match players leverages the social aspect of today's world. By integrating with a social network service (or using your own social network populated by your players), you can give a player the option to invite a friend to play with them.

While this can be a fun experience, it goes without saying that both players must be online at the same time for the game to be played. Often, this means that when a player sends an invite to his or her friend, an email is sent to the friend with information about the invitation. Whenever the friend joins the game room and both players are ready, the fun can begin.

A variation of this technique is to only show available friends (that is, friends who are already online and either in the lobby or in a game room). This way play can begin immediately or as soon as the friend exits the current game.

Perhaps, you don't have a social network to leverage, or perhaps, the player doesn't care who the opponents are. When you want the player to be able to just get in and play a quick game, auto-matching is a great option.

There are more specific ways to automatically match players (for example, automatically match players based on their skills or some other criteria), but in its most basic form, you would need to create a private room for the first player (by private room, I mean a room that isn't listed for any player to join—only the game server knows about it), then wait for a matching player to join that room.

Another common way that players are matched into the same game room is by grouping players together based on their skill level. The way you keep track of a player's skill level can be determined in at least three ways— namely, by asking the user what his or her skill level is, by monitoring them during a single session, or by persisting the player's information across multiple sessions.

The first option is the easiest to implement. A common way in which this is done is by displaying a menu with three or more options asking the player to choose from the options, such as amateur, advanced, and rock star. Based on this selection, you will then try to match other players from the same group.

One possible benefit of this approach is that a new player with no past history with the game (from the point of view of the server) can start playing more advanced players right away. On the other hand, the same feature can be considered to be a downside to the approach as truly advanced players who may only wish to play with equally skilled players might get frustrated by being matched up against poor players who claim to possess a higher skill level than they really qualify for.

The second option is to start everyone at the same level (or randomly assign the first skill level for incoming players). Then, as more games are played, the application can keep track of each player's wins and losses along with other metadata about each player to allow you to bucket each player into a current skill level.

For example, a player may start the game in a beginner's room. After winning two games and losing none, you can then put this player in a advanced room. After the player has played additional two or three games and has two or three more victories under their belt, you can now consider that player to be in the super-advanced level.

The obvious downside to this approach is that it makes the assumption that an individual player will stay logged in long enough to play multiple games. Depending on the type of game you're designing, most players won't even be logged in to finish a single playing session.

However, if your game is a good candidate for this type of approach (where a single game doesn't last longer than a few minutes), then this matching technique works out quite well because you won't need to write any long term persistence logic or need to authenticate users.

Finally, you can keep track of a player's skill level by persisting their information in some form of backend database. In most cases, this will require players to have individual accounts, which will need to be authenticated before the play begins.

Again, in some cases, you might want to use an existing third-party service to authenticate players, and possibly persist information you generate about them in the service itself.

While this can get pretty elaborate and engaging, the basic concept is simple—calculate some sort of score that can be used to deduce a player's skill level and store that information away somewhere in a way that it can be retrieved later. From this point of view, you can possibly implement this persistence by storing the player's current skill level locally using HTML5's local storage API. The main drawback of doing this would be that this data would be stuck in the player's machine, so if the player uses a different machine (or wipes out their local storage data), you won't have access to the data.