Emma

A borderless matchmaker for online videogames

By Jason McIntosh (jmac@jmac.org), 2013

This document describes Emma, a proposed online service that helps people find other players of online videogames they enjoy.

“Emma” is a working title for this project, chosen because of its affiliation with a famous matchmaker from literature. It also suggests that the project present a personable face to its users, in the manner of Apple’s Siri, which the author appreciates.

Emma’s purpose

Emma offers succor to enthusiasts of online multiplayer videogames in three ways.

First, it assists fans of games with weak online ecologies – for example, always-empty setup lobbies, or ever-fruitless “Quick Match” features – a way to locate and play with other fans of the same games. For good online games that never managed to build up the critical mass necessary to support continual online player-presence – or which, by virtue of age, used to enjoy but have now fallen from this state – this service can offer perhaps the only way to play for people to play these games together at all.

Emma also helps players avoid finding themselves in the ubiquitous but undesirable situation of playing a game with jerks. Because the system rides on an existing social network (Twitter), Emma’s users can make rapid evaluations of suggested co-players based on their revealed online personas outside of gameplay. While not a perfect defense against encountering poor sports or unpleasant personalities in a game, it presents a far better situation than the famously toxic nature of completely unfiltered online play.

Finally, Emma brings to online game-players the ability to voice a desire to play a game, and seek out new fellow-players, without having to necessarily specify which game they wish to play. Typically, a game-player in the mood for some online fun will need to choose a specific game, load it up on their PC or console, and then use that game’s own tools to see if anyone else happens to have the same idea about the same game at the same time. There exists no practical way to check for matches across all the online-capable titles one enjoys. Emma, on the other hand, extends its matchmaking consideration across all the games that one has access to and might wish to play. One in the mood for a game can check for shared interest across their entire game-library at once, in a single action.

What Emma does not do

Emma does not help friends play games that they already know they enjoy and play with one another. These people do not need Emma’s help – at least not with these games! This system focuses only on helping connect players who like certain online games but desire to meet more players of the same games. Typically, these players find themselves unsatisfied with the games’ own matchmaking tools, and therefore effectively unable to play these games at all.

It is also not “a social network for gamers”. Emma uses Twitter as its platform to specifically avoid the necessity of providing its own social network. It simply listens to its lonely users’ preferences in online gameplay, and does its best to introduce potential co-players with one another. What they do after this introduction is made is not Emma’s concern.

How it works in a nutshell

Enthusiasts of online videogames can introduce themselves to Emma through their own Twitter identities, then proceed to share the list of their own multiplayer gaming preferences, including which titles and networks they enjoy (or simply wish to play more of with others), and what times of day they tend to be available.

When one of these players wishes to play a game, they ask Emma to find them some potential fellow-players with compatible game and time preferences. Emma performs all the work of discreetly relaying notifications and messages around its database of potential players, determining who might be available, and letting players evaluate one anothers’ Twitter timelines to help them make fast yes-or-no decisions. If all goes well, Emma uses Twitter to introduce the new co-players to one another as fellow fans of some specific game, and bids the player who made the initial request to set up a new instance of that game. Then it withdraws, its job as matchmaker complete.

How it works in detail

Emma runs as a web-based service with a REST API. Its initial user interfaces will certainly include a web application, and possibly an iOS app.

After a user signs into Emma for the first time with their Twitter account, they can proceed to enter in a bunch of online games they own, and wish Emma to know that they own. For each game, they’ll also specify which platforms and game networks they play it on. Emma has a large and continually-updated database of online-capable videogames based on the public VideoGameGeek database, and players can pick and choose from any game represented therein.

Finally, a user will provide their current time zone, and specify which times of the day they’re more likely to accept a game invitation. That done, their immediate interaction with the system comes to an end. Emma will advise the user to follow Emma’s own account on Twitter, so that it can send direct messages when it needs to, but it otherwise has no immediate news or directives for the user.

When that user (or, indeed, any registered Emma user) later feels like playing a game, they’ll visit Emma – either by the website, or perhaps via a separate app that communicates to Emma’s server through its REST-based API – and hit a big green button indicating that they’re looking for a game. This will put them into LFG Mode. Emma acknowledges this and advises this user to stand by while it looks for potential players.

At this point, Emma gathers up a list of users who have any amount of overlap with this user’s game collection and game-network access, and who are either themselves in LFG Mode, or who have designated possible-playtimes within which the current moment falls. Starting with the former group, Emma selects the first few names from the list and contacts them via Twitter with a message similar to this:

Hello! @someone is LFG (4 games in common). For info and actions: t.co/someURL. Will automatically pass in 2 minutes. To mute: t.co/otherURL.

As the message states, if the user doesn’t wish to play, they can just ignore the message. Otherwise, they can tap the provided URL to see a list of actions, including:

• Show me this person’s Twitter timeline
• Show me which games we have in common
• Yes, I’d be interested in playing a game with this person
• No, I don’t wish to play right now (silently ignore invitation, same as ignoring the tweet altogether)
• No, and please don’t send me invitations from this person ever again
• No, and please don’t send me invitations for some time (mute for 1 day / week / month)

The contacted user can modify a yes response with a list of which games or networks they would consider playing, among the various titles that overlap between their own collection and that of the initiating user. If they don’t make this distinction – the default behavior – then Emma will consider the entire overlap.

Emma makes clear to the responding user that a yes reply does not guarantee that they will play a game now. It just lets Emma know that they would be willing to accept an actual invitation, should one arrive soon.

When Emma receives a yes reply from any single user, it immediately notifies the original user, the one who voiced a desire to play now. Their choices for responding to this response include:

• Show me this person’s Twitter timeline
• Show me which games we have in common
• Yes, I’ll play with this person, and stop looking for more players.
• Yes, I’ll play with this person, but keep looking for more players. (The user may choose this if they specifically wish to play a four-person game, say, and does not want Emma to stop at a single match.)
• No, I don’t want to play with this person right now.
• No, and never offer to pair me with this person again.

As with the earlier communication with the proposed match, the initiating user can take this opportunity to view the games they have in common, and choose from this intersection-list a specific game to play. If they do so, then Emma will immediately modify its list of remaining proposed matches to only those people who list that game as a favorite.

When Emma’s done with its search for matches, either because it’s exhausted its list of potential matches or because the first user asked it to stop, then Emma contacts everyone one last time, sharing the details of which game is to be played, and on what network. To the original user, it shares the network-specific usernames, as applicable, of the other users who’ve agreed to play, and instructs that user that the task of actually setting up the game falls to them. Finally, Emma removes that user’s LFG Mode status – they are no longer looking for a game, after all.

If the specifics of game and network remain ambiguous, due to both multiple-game overlap among the players and to no players electing to narrow this overlap down to a single game, then Emma takes this opportunity to decide a game and network for them. It will choose both at random, based on the titles and locations common to all involved players. Note that this is the default state, not a failure state; Emma does its best to get the people playing a game they all enjoy together, and not force them to make any decisions when not absolutely necessary.

At this point, it’s up to the people attached to these accounts to actually meet online and play together, led by the user who originally went into LFG Mode and put this whole process into motion. If nothing else, all players are guaranteed to have one anothers’ Twitter handles, allowing them to negotiate the game setup there.

Emma’s last task as matchmaker involves sending notifications to all users who responded to the original call with yes but who did not make it onto the final list of players, either because the originating user didn’t want to play with the respondent specifically, or because the user told Emma to stop suggesting more players before the respondent’s name came up. To help prevent hard feelings, Emma will not specify exactly what happened; it will simply tell the respondent that they were “beaten to the table” this time by others. It will go on to suggest that if they find themselves now in the mood for a game themselves, they should feel free to enter LFG Mode and begin the process anew.

If, on the other hand, Emma finds no matches at all for the LFG Mode request – either all potential players declined the invitation, or the database simply contains no overlap with the user’s game and time preferences – then the system lets the user know, but encourages them to remain in LFG Mode. Emma will inform the user should the situation change – say, another user with compatible game-taste themselves enter LFG Mode.

The original user, at this point, can request to exit LFG Mode now, or revisit and do so whenever their own real-life window for starting a new game closes. If Emma doesn’t hear anything from this user within an hour, it will proactively remove LFG Mode from the user, as a timeout.

Challenges Emma faces

Minimizing interface pain

Emma tries to require from users as few decisions as possible between their initial decision to play a game (or consider an invitation to play), and the moment when the game, location, and players have all been decided. The sole mandatory decision-points involve evaluation and approval of new potential co-players based on their public Twitter behavior, as this meets one of Emma’s core design goals of helping to avoid unpleasant online experiences.

However, for the system to work as hoped, Emma does require that players actually do follow through with setting up a proposed game, once it makes its initial introductions and withdraws from the conversation. From the users’ perspective, the context suddenly switches from having a fun, automated “conversation” with a computer program to an expectation to communicate and coordinate directly with other humans.

The author’s hope for the system succeeding to bring players together regardless of this significant context switch involves the fact that the people involved all registered with Emma hoping for precisely this sort of meeting and exchange to occur. Emma should aim to manage users’ expectations such that they view the introduction to other fans of similar games as its primary goal, with the actual play of these games a fortunate follow-on effect. This should make Emma’s departure from the conversation seem less jarring.

Initial seeding and growth

As with any system that is only as good as its userbase, Emma faces an obvious chicken-and-egg problem. It offers no use at all for a single user, limited utility to 100 users, and might only start meeting its potential at 10,000 users or more. The first users of this system would necessarily register knowing that seeing any immediate results would prove unlikely. So long as it knows of only a few registrants, Emma will often need to return empty-handed after any one of them requests a match.

However, as the userbase grows, these same users will gradually begin to receive notifications of potential matches looking for games they enjoy – and they will receive these notifications without the need to perform any further interaction with Emma, after registering. The challenge, then, becomes in continuing to encourage new users to register with the system, even while initial matchmaking results may remain weak.

Offering any definitive solution to this challenge that doesn’t sound rather like a cynical marketing ploy becomes a challenge unto itself. At risk of sounding naive, the author feels that simply making the act of registering for an account fun, while carefully not setting user expectations too high, might do a great deal towards collecting an invaluable, initial wave of users with piqued curiosities and a little time to spare. And once Emma starts to collect even a small amount of user data, it can make registration (and post-registration visits to the app) more interesting by sharing anonymous information such as the current size of the user database, and the number of game-and-time overlaps that the current user shares with other users on the system.

Dependence on outside sources and networks

The system this document proposes makes use of external, privately owned resources with public APIs, including Twitter and VideoGameGeek. This design decision trades control for simplicity, but risks Emma becoming essentially nonfunctional should either system either cease to operate or dramatically alter its policies regarding access from external applications.

To implement Emma would involve become fully cognizant of these risks, and deciding to proceed anyway, considering them a subtle but real element of the project’s total implementation and maintenance cost.

History

Emma is the conceptual successor of Planbeast, a system designed, implemented and launched by the author in 2009, and maintained for the subsequent two years. Planbeast focused specifically on the Xbox game console and the Xbox Live network, and it assisted its users in finding fans of online games they enjoyed, much as Emma proposes to do. However, rather than presenting Emma’s one-button interface for setting up introductions automatically, Planbeast put the onus on players to browse around the and find one another, and then manually suggest future gameplay-times using a scheduling-and-reminder tool it provided (hence that system’s name).

Planbeast found a lot of positive reception from both players and game developers as a concept, but in practice saw very little use. Beyond its most obvious surface limitation of restricting itself to only Xbox Live games, apparently few players wished to take the initiative to directly invite total strangers to play games at times which they had no reason to believe worked for anyone but themselves. Planbeast saw some off-topic use as a game-scheduling assistant for groups of friends, but once the novelty wore off, its effective use even in this regard trickled away completely.

Emma hopes to revive this concept while avoiding these problems by acting a bit more like a matchmaker in the traditional sense of the word. Rather than expect players to find their own potential co-players from a browsable directory, it will proactively match potential co-players together, based on game and time preferences they specify upon registration with the system. This design also removes the question of planning from the mix entirely, offering only to help people meet other players at whatever moment they feel like playing a game.

The author feels that Emma represents the best design for re-embodying the spirit of Planbeast, which failed due to incorrect focus and too much interface pain. Its core idea remains both valid and attractive, and deserves a fresh implementation that builds on the knowledge of both this earlier attempt and the advantages provided by open, external social networks and databases. People need to play more, and Emma wants to help.