Rich Presence in XNA Game Studio 3.0

A neat feature of Xbox LIVE is how you can go into your friends list and see what everyone is currently doing. The details page for one of my friends might show something like this:

Microsoft Cat Simulator 2008
Kitty Herding Mode
Level 3, Score 15
Online - Joinable

Where does this text come from?

  • The first line is automatically set to the name of the game they are playing
  • The last line is automatically filled with system defined status information
  • The middle two lines are controlled by the game itself

Traditional Xbox games define their presence using a somewhat complicated tool called XLAST. If you were lucky enough to win the Dream-Build-Play competition last year, you will more recently have been unlucky enough to have to use that tool to create presence strings for publishing your game on XBLA.

Outside the few people with XBLA contracts, our 2.0 framework did not support rich presence. Games made with it would always just show:

XNA Creators Club
Using XNA Game Studio
Online - Joinable

We wanted to improve this for 3.0. But here's the problem: presence text can be viewed by anyone on LIVE! Xbox has a parental controls system, which can limit what games your kids are able to play, but you don't have to be running the game at all to view its presence information. So even if a game is rated 'R', the presence must still be 'E' rated.

If we allowed Game Studio titles to specify arbitrary presence strings, there would be no way to prevent naughty developers putting something naughty in here, which would be upsetting to parents, ratings boards, and other such people that it is not cool to upset.

Our solution was a compromise. When you run a game as a Creator (either from Game Studio, or deploying a .ccgame, or during peer review) its presence now shows up like this:

XNA Creators Club
<your choice of presence mode here>
Online - Joinable

The third line is controlled by you, but only as a choice from a fixed list of options. Since there is no way to enter arbitrary text, this ensures the presence will always stay clean.

Here's how you set the presence mode:

    Gamer.SignedInGamers[playerIndex].Presence.PresenceMode = GamerPresenceMode.WaitingInLobby;

There are 59 different modes to choose from, including things like "Practice Mode", "Difficulty: Easy", "At Menu", and "Found Secret". Some of these modes also include an integer parameter value:

    Gamer.SignedInGamers[playerIndex].Presence.PresenceMode = GamerPresenceMode.Score;
    Gamer.SignedInGamers[playerIndex].Presence.PresenceValue = currentScore;

This is of course optional. If you don't set any presence data, the third line will be blank.

If you choose to release your work as an Xbox LIVE Community Game, its presence will show up a little differently once end users are playing it. After a game has made it through the peer review process, we can be confident the game name is not obscene, so we automatically use that as the second line of presence. Thus the Community version of my game might show this presence state:

Community Game

Shawns Cat Simulator

Score: 23

Online - Joinable

Comments (7)

  1. Pon says:

    But shouldn’t "naughty" messages be picked up during peer review?

  2. ShawnHargreaves says:

    > But shouldn’t "naughty" messages be picked up during peer review?

    Ideally yes. But peer review doesn’t give an absolute guarantee that everything was caught, just a high probability.

    So this comes down to a balance between probability versus how bad it would be if something slipped through the net.

    When looking at games in general, this balancing landed on the side of us being able to ship Community games, on the grounds that peer review is likely to catch most offenses, and if it doesn’t, well, the games are still unrated even after peer review, so restricted child accounts can not play them in any case, and we can always take them down if something really nasty is discovered after the event.

    For presence, the balance was a little different. The probability of a nasty presence string being missed in the review is much higher, since these are not so directly visible (the reviewer would have to be watching their state on a second Xbox at the same time as playing the game) plus the consequences of that are much worse since presence is visible to everyone, not only the accounts that have permission to view unrated content. The ratings boards would (quite rightly) be very upset with us if we allowed  unrated content to show up on a machine that was set to only display ESRB ‘E’ material!

    The game name was yet another case, because although this can show up even to restricted accounts, the name is much more visible than the presence strings during review and on Marketplace, so we felt the risk of anything bad making it through there was vanishingly small.

  3. SharedProphet says:

    Seems like there should be a way to implement different "rating levels" for the text… so that only these options are visible to restricted accounts, but a custom string could be visible on accounts which can view any content.

  4. BenS1 says:

    It sounds like a nice feature but user defined strings would be much better.

    Why not subject Rich Presence strings to explicit community review too. Developers could submit their strings to a website, which would then be reviewed by other Community Games Developers (Just as the games themselves are). If a string passes the review then a corresponding authorisation token would be generated for that string. The developer could then call some function like:

       Guide.SetRichPresence("this is the string", authkey);

    (If the authkey doesn’t match the string then it will fail).

    Of course this would mean that the string have to have fixed content, so you couldn’t do the following:

       Guide.SetRichPresence(gamer1.GamerTag + " has just shot " + gamer2.GamerTag, authkey);

    But it would still be pretty flexible.

    Of course, you could still have the predefined strings that you have today for people that don’t want to go through the authorisation process.

  5. Pigyman says:

    Actually, predefined presences is a brilliant solution.  Because, for some odd reason, you cannot view your own presence.  So during peer review, it is impossible to check the presences by yourself.  Plus, there are 59 presets, they can be combined using the ‘|’ operator, and there’s  status for every situation. (There’s even a "CornflowerBlue"!)

  6. Is this in GS 4.0 still the same?

    I ask because I have two creator memberships and with one of those I started an new Indie Game (full version) and with the other account I tried to read out the Presence information of the first gamer. But I only received an empty string ("") for the Presence state/string of the first gamer.


  7. ShawnHargreaves says:

    Yes, this works the same in XNA 4.0.

Skip to main content