User-generated content on Xbox Live

Microsoft European developer account manager Ben Board goes through the potential pitfalls
Publish date:
Social count:
Microsoft European developer account manager Ben Board goes through the potential pitfalls

If you were asked to identify the single most significant advance in console gaming in the last ten years, the defining paradigm shift, what would it be?

There are certainly a number of candidates, but I reckon the winner is when games went online. The benefits of this single advance barely needs elaborating, from features such as multiplayer gaming, leaderboards, voice chat and messaging, together with new business opportunities such as Xbox Live Arcade and Indie Games, Games on Demand, demo and video downloads, and DLC.

Add to that list another in-game feature, in the ascendancy of late: user-generated content.

Developers are realising that by providing players with a way to build levels, paint characters, customise cars, share replays, or send images, they are likely to better keep their interest – and postpone the trade-in. The same applies to the audience who will peruse that library of user content even if they don’t contribute to it.

Keeping your audience engaged is one step towards building your brand.

So we’re always happy to hear when a title is including UGC features. Now, it doesn’t take great insight to understand that within the wide, rolling fields of user creations lurk a few landmines.

Some UGC tools, particularly flexible ones such as Forza Motorsport’s awesome car customisation, provide such powerful routes to self-expression that some of the more... excitable examples are likely to prompt the audience to express themselves with equal vigour; notably in alarm, wrath, or with robust legal action.

Frequenting the flesh-coloured palette in Forza’s bodyshop is just the most obvious way to cause trouble, but your PR or legal departments are going to get sweaty if players are able to breach copyright, child protection or privacy laws with their creations; and if you didn’t protect against malicious users’ intent to subvert platform security, things would get really crispy.

But the fact is all these risks can be mitigated, and your DAM will work with you at concept submission stage to discuss the risks and agree on steps to meet them.

Today I’ll briefly sketch this process.

First up: how do you know if your game feature is even a UGC tool? Well, could your QA team feasibly test every one of its conceivable end products? If not, it is.

When we look at your design we first gauge the risk, and then establish some mitigation steps.

At the basic level, risks increase as you share more widely and store content in more locations. Your Xbox Live Friends are considered to be an audience you can trust – within reason, recognising that your capital-F Friends on Live aren’t necessarily real-life buddies.

In the simplest UGC design you restrict visibility of your shared creations to your XBL Friends, and never store the creations anywhere, even locally.

Sharing something inappropriate with a Friend can be resolved with a personal “Dude, pack it in!”. Worst case, they de-Friend you. That’s often sufficient for Friend-only sharing. Broadening the audience raises the need for a mechanism for UGC consumers to report creators acting irresponsibly.

As the provider, you’ll need to respond to those complaints: offenders could be blacklisted from sharing, from using your title online at all, or, in the most serious cases that would require escalation to us, banned from Live altogether.


So, to storage. If you want to save a local copy – and let’s face it, you probably do – that’s great, but it’s then possible for a determined person to interfere with it before it’s next loaded, and you’ll need to anticipate and deal with that.

Perhaps you want to allow remote players to save your content locally? This is where things start getting interesting.

For a start, you’ll need XLSP to store and share the packages. You’ll need to provide reporting mechanisms for bad content as well as its creators, and remove it (and perhaps them) from your service.

You should strong-sign content packages, and, if the loaded UGC makes use of any disc-based assets, validate that those assets haven’t been meddled with.
The risk graph takes a sharp upward turn if you allow players to download, edit, and re-share content.

You will need to track how content packages are derived from one another and prepare to pull all packages built on a stem later found to be complaint-worthy.

Finally, you may be planning a service where people create content outside the Xbox and enable it to be brought into Live, and shared. If so, you just pressed the big button marked ‘Take Me to Scarytown’. Clear the calendar, boil the kettle, fire up the lawyers, and give us a call – you’re about to get busy.

Whatever UGC feature set you choose, there are a few standard steps you will need to follow. TCR 61 mandates that you observe the content-sharing privilege bits the player (or their mum) might have set on their account. TCR 64 indicates that user-generated content can’t be stored on Live storage; and to comply with TCR 92 you’ll need to run any player-created string through the filter of XStringVerify() before it can be shared.

You should also keep your legal people in the loop as your plans develop, particularly if you’re working on a high-risk flesh-coloured strategy. Lastly, today we don’t support the sale of UGC, nor the sharing of executable code or scripts.

Whatever your UGC thoughts, though, you should maintain a dialogue with your DAM from the off. He can advise on risks and mitigations, opportunities and potholes, and ultimately will be the person to sign off on your plan and help your title reach concept approval.