Mooso - a game with a purpose

The R&D Prototyping team, in association with Radio Labs, recently launched a new public prototype called Mooso. Mooso is a game to play while listening to BBC 6 Music. Sign up at https://www.mooso.fm, then listen to 6 Music and tag the songs that are played. If you match other players’ tags then you score points. You can read more about it on the the BBC Radio Labs blog. In this rather long post we explain some of the development process for Mooso, some of the technology behind it and we look at the problems and choices we had to make.

The evolution of an idea

The core idea for Mooso came out of an ideas session a couple of years ago. We wanted to build a web application for discovering new music that was inspired by games and fun.

Mooso is a Game With A Purpose, a GWAP. GWAPs are a concept first developed by Luis von Ahn of Carnegie Mellon University and the first mainstream example was the ESP Game, which was subsequently licensed by Google as the Google Image Labeler. The principle behind these games is to create enjoyable and fun experiences for people that also do useful work as a by-product of their design. You can play several examples of GWAPs at gwap.com including image-based, text-based and music-based games.

Typically these games match up a number of players over the internet and get them to independently describe some aspect of an image, text or music that is provided, if the players descriptions match then they get points. And those bits of independently entered and matched data can then be collated and used to aid search and navigation of the things that were described. This concept inspired us and we spent some time thinking about how we could use it for music discovery but came to a bit of a dead end. We wanted to build a music-based GWAP as a way of gathering tags and metadata but at the time we didn't have any on-demand music on bbc.co.uk, not even clips, so we couldn’t build a completely analogous game to the Image Labeler. What we do have however is live radio, and the eureka moment came when we realised we could develop a game of this type which ran synchronously with a radio station, using each song played on the radio as the basis for a round in the game.

So we took that idea and developed it, drafting some possible rules and then playing the game on paper to see if it would work - you just need a few people, a radio, a countdown timer and some paper and pens. When the radio starts playing a song everyone starts writing down tags, while keeping them hidden. After two minutes the round ends and you start the scoring. Go round the table in turn, each player reading out their tags, if anyone else wrote down your tag then you and they get a point and then cross it off, otherwise just cross it off. Then when everyone has either matched or not matched all their tags you can total up the scores for that round. Anyway, it was pretty fun to play and the idea looked good. We put together a small team and built a quick Rails prototype over a couple of weeks, this worked OK and we played the game internally a bit but it wasn’t in any way scalable or robust enough to put on the web in public. So the idea was shelved temporarily while other things got developed and time passed.

Then earlier this year we picked the project up again and turned it into a beta-quality prototype for public release.

How it works

Mooso is built in Ruby on Rails, it’s one of the technologies that our team use for prototypes, in this case providing enough robustness and performance combined with speed of development. The main challenge in building the game is the real-time nature of it, which is an interesting trend on the web in itself. We decided to use XMPP/Jabber, a standardised Instant Messaging (IM) protocol, to power the game as it would give us a scalable way to receive real-time submissions from players and send them instant updates as they play. We use the eJabberd Jabber server because it is very stable and we have some experience of using it in the BBC.

As Jabber is an IM protocol we need some way of integrating that into the game’s website. If you’re playing on the website then the pop-up Play page (shown above) communicates to our eJabberd server using a Flash bridge (based on the XIFF Flex library) which allows a direct connection to be made over the standard Jabber ports. If you’re behind a firewall (e.g. if you’re playing at work, which we wouldn’t condone obviously) we provide a Javascript fallback (based on the Stophe library) which connects to the eJabberd BOSH server using HTTP binding or long polling over the standard port 80. Around 8 out of 10 people connect using the Flash bridge. Using Jabber also meant that we can let people play over instant messenger (if they have a Jabber or Google Mail account) with very little extra code - see the Mooso IM help for more detail.

The game is run by a number of Ruby scripts which communicate with each other internally over Jabber as well, using the XMPP4R library. One script manages player communication and the start and end of each round. Another script manages timing information and sends out timer messages, like when there are 30 seconds left in the round. A third script listens for new tracks to be played from the 6 Music hard disk playout system. This is what triggers the start of a new round, although not all tracks that 6 Music plays are played out like this. So live sessions, for instance, do not trigger a new round. And another script handles scoring, which is the first point at which we have any communication between the game and the database - deliberately done in order to de-couple the real-time gameplay from the website serving. Once scoring is done the database and site are updated to reflect the players’ new scores and the round which was just played. This architecture means the game mechanics are modular and should Mooso become very popular we can move processor-intensive functions like scoring onto dedicated hardware.

Playing the game

Fairly obviously, the game requires several people to be playing simultaneously for it to be any fun, which could be a problem. We try to help remedy this situation by generating “ghost” sessions for when there are few players online. We can only do this when a round involves a song that has been played in a previous round. At the end of the round, before scoring, we select several previous sessions for that song when available (where a session is tags from a player during a round) and add them to the pool of real players’ sessions to be matched and scored. There’s a caveat that these ghost sessions can’t be from any of the real players in that round so you can’t end up playing yourself! A player also doesn’t get any post-hoc points if they happen to be one of the ghost sessions as that becomes too complex, so only the current “real” players in a round score any points.

The rules we currently have in place mean that you get a single point if you enter any tags at all in a round, 5 points for every tag you match with other players and 10 points for every artist/band you match. We determine if a tag is an artist by matching it against our MusicBrainz-powered database of artists. Only by people playing the game will we discover if these rules work and we imagine that they may need to evolve over time to fine-tune the game for maximum enjoyment and usefulness. The tag matching is done with a varying threshold. Below a certain number of players you only have to match one other person but as the number of simultaneous players increases that threshold increases so you might have to match 2 or 3 or more players if there are many people playing.

This brings up some interesting questions around what kind of tags we will get from the game. By requiring players to match tags we are, hopefully, validating that those tags are in some way relevant or descriptive to the song. And we also want to avoid people spamming or abusing the game, hence the varying threshold. But by setting this threshold are we penalising those players who have specialist knowledge and enter obscure but valuable tags? Are we just going to get the lowest common denominator tags? We could start banning tags which have been entered too often (i.e. rock and indie) and we could also consider awarding points based on the entropy of each tag - i.e. you get more points for tags that are rarer and potentially more interesting.

It’s also worth thinking about whether this kind of tagging is different to other music sites that use tagging. I guess the motivations for people tagging music on places like last.fm are partly for their own use (which is why you often see the tag “seenlive”) and partly for the community. Mooso is potentially different as it has a particular audience (the 6 Music listeners), the players aren’t entering tags directly for their benefit, and they don’t even necessarily like the song that is being played. But they are, hopefully, having fun. Will these motivations make a difference to the qualities of the tags? We don't know but we hope to investigate.

The tagging data that we do capture from the game is used to create links inside the Mooso site so matching tags and artists are used to create links between tag pages and artist pages on the site creating an interconnecting web of music, songs, tags and bands. Internally we are actually storing all the entered tags, whether they match or not, and we hope to analyse these in more depth at some point. We are also planning to release the dataset of matching tags and artists under the BBC Backstage licence which will allow other people and organisations to benefit from this data.