Technical Certification Requirements - March 2009 (v1.5i)
Released: 2009-03-23
For questions about Xbox 360 TCRs, send e-mail to Xbox 360 Certification Information at 360cert@xbox.com.
Disclaimer: The requirements detailed in the TCRs are subject to change. Furthermore, additional requirements may be stipulated or existing TCRs may be retired in future releases. Please refer to only the most current supported releases of the TCRs.
- Base Requirements (BAS)
- Multi-Disc Games (MDG)
- Video and Graphics (VID)
- Avatar (AVT)
- Audio (AUD)
- User Interface (UI)
- Peripherals (PER)
- Voice Peripherals (VOP)
- Text Input Devices (TID)
- Video Camera Peripheral (VCP)
- Storage (STR)
- Game Clips (GC)
- Content Packages (CP)
- Xbox LIVE Content (LC)
- Gamer Profiles (GP)
- Statistics and Achievements (SA)
- Multiplayer Sessions (MPS)
- Communication, Messaging, Text, Voice (CMTV)
- Network (NET)
- Xbox LIVE Server Platform (XLSP)
- System Link (SL)
- Advertised Feature Requirements (AFR)
- Game Demos (DEM)
- Xbox LIVE Arcade (XLA)
Base Requirements (BAS)
The following requirements apply to general coding quality standards, security, restricted-access system components, game behavior, and acceptable library usage.
TCR # 001 | BAS Game Stability |
---|---|
Requirement | On a functional console, the game must not enter an extended unresponsive state, cause unintentional loss of player data, crash, or cause an unintended reboot of the machine. |
Intent | Console game players expect that console games just work. Games that crash or hang or lose player progress reflect poorly on the Xbox 360 experience. |
TCR # 002 | BAS Basic Console Support |
---|---|
Requirement | Games must be playable on the most basic retail console configuration. |
Remarks |
A game may provide additional functionality and optimizations—faster loading, career modes, saved game progress, and in-game saved pictures, for instance—when additional components are available. Games must not depend on the presence of a storage device, such as a hard drive or a memory unit, to be playable. |
Exemption | Xbox LIVE Arcade games are allowed to require a profile for gameplay. Primetime titles use the hard drive. |
Intent | The Xbox 360 program provides choices to console purchasers, including the choice to purchase entry-level systems. Consumers expect that games on Xbox 360 will work regardless of what components are attached to the console. |
TCR # 003 | BAS Initial Interactive State |
---|---|
Requirement | Games must enter an interactive state that accepts player input within 20 seconds after the initial start-up sequence. If an animation or cinematic shown during the start-up sequence runs longer than 20 seconds, it must be skippable using the START button. |
Remarks |
Initial interactive state refers to the first display of graphics or text in which both the game is identified and player input is recognized. Legally or contractually required license animations or cinematics of up to five seconds each are not considered part of the initial loading time and are exempt from this requirement. Buttons other than the START button, such as the A button, may also skip animations and cinematics. Animations and cinematics under 20 seconds may also be skippable. Error messages are not considered an initial interactive screen, even if player inputs are accepted, because they prevent the game from reaching the initial interactive screen without user input. |
Intent | The Xbox 360 experience is designed around the principle: "insert the game and play." Lengthy load times and non-interactive experiences detract from this central philosophy. |
TCR # 005 | BAS Console Restart |
---|---|
Requirement | Games must not eject the game disc, require the player to eject the game disc, or require the player to restart the console. |
Remarks |
Multi-disc games are allowed to require the player to eject a game disc to continue gameplay. See the Multi-Disc Games (MDG) section for more information. |
Intent | The Xbox 360 experience is designed to allow players to enjoy games without having to repeatedly interact with the console. |
TCR # 006 | BAS Non-Interactive Pause |
---|---|
Requirement | Games must not pause without game-representative on-screen graphics. When the pause time is greater than five seconds, the game must indicate the reason and provide on-screen animation. |
Remarks |
An on-screen display consisting of a single color or band of colors does not meet the requirement of on-screen graphics. For on-screen animations, a single color background is allowed. It is not required for an on-screen animation to show actual rate or remaining time. This requirement does not apply to player-initiated pause states. |
Intent | Console game players expect that console games just work. Games that are perceived to crash or hang or lose player progress reflect poorly on the Xbox 360 experience. |
TCR # 007 | BAS Load Times |
---|---|
Requirement | Games that take longer than 15 seconds to load must employ methods to engage the player. Overall load times must not exceed 60 seconds. |
Remarks |
Load times refer to game loading activity that takes place after the player has reached the initial interactive state. Methods to engage the player may consist of tutorial videos, character animations, level or map descriptions, rotating hints and tips, scrolling text, and other activities that are pertinent to gameplay. Progress indicators are not a sufficient method to meet this requirement. |
Intent | The Xbox 360 experience is designed around the principle: "insert the game and play." Lengthy load times and non-interactive experiences detract from this central philosophy. |
TCR # 008 | BAS XDK Version |
---|---|
Requirement | All XDK libraries linked with a game must belong to the same XDK release. All XDK libraries must be approved for release with the title. |
Remarks |
The most recent and approved library update, or QFE, for an XDK version is considered to be part of a specific XDK release. |
Intent | Approved XDK libraries undergo extensive integrity testing as a family unit. Security and integrity cannot be guaranteed across library versions. |
TCR # 009 | BAS C Runtime Library |
---|---|
Requirement | Game executables must be linked with the approved LIBCMT or LIBCPMT library that is included in the XDK. |
Remarks |
The Xbox 360 CRT includes console security features not available in generic implementations of the C runtime. |
Intent | The Microsoft approved XDK C/C++ run-time libraries contain security and integrity features that protect the console. |
TCR # 011 | BAS Personal Information |
---|---|
Requirement | Games must not request, store, or transmit any player's personal information, including, but not limited to:
|
Remarks |
Player account credentials include Windows Live ID, password, secret question, secret answer, Xbox LIVE pass code, and so on. |
Intent | Protect private consumer information. |
TCR # 012 | BAS Hardware Access |
---|---|
Requirement | Games must use only approved XDK title library functions to access console hardware components. Games must not use undocumented CPU or GPU registers or undocumented microcode instructions. |
Remarks |
Approved APIs can be found in the XDK documentation. The XDK library insulates game developers from minor hardware changes over the life of the console. Games must not directly access the Ethernet controller, system ROM, USB controllers, video camera, video encoder, storage, network, or other console hardware. Games are permitted to use XDK-documented assembly language and microcode instructions for accessing the CPU and GPU. |
Intent | The approved public title library functions insulate titles from hardware and firmware revisions over the life of the console, allowing titles to run on all current and future consoles. |
TCR # 013 | BAS Memory/Clock Speed |
---|---|
Requirement | Games must not change the clock speed of the memory or of any processor. |
Intent | Adjusting the clock speed of memory or processors may damage the Xbox 360 console. |
TCR # 014 | BAS Debug Output |
---|---|
Requirement | Games must not output debug information via the network, on-screen messages, or a file on any storage device. |
Remarks |
Games must not use OutputDebugString() in retail builds. |
Intent | Output of game debug and/or testing information in any medium can jeopardize the security of the platform, and risk customer privacy. Consumers expect that the game console will not store or transmit hidden data that is not otherwise relevant to the gameplay experience. |
TCR # 015 | BAS Sign-in Changes |
---|---|
Requirement | Games must properly detect and handle player profiles signing in or out in all areas of the game. |
Remarks |
Players may sign in or out at any time via the Xbox Guide. The console issues an XN_SYS_SIGNINCHANGED system notification when this occurs. In addition, games may consult the XUserGetSigninState() API. It is sufficient to return to the main menu if the game cannot update its game state to match the new sign-in state. Players may also be signed out of Xbox LIVE because of a duplicate sign-in. Single-player modes that do not rely on Xbox LIVE services can generally ignore Xbox LIVE sign-in changes. |
Intent | The Xbox Guide allows players to sign in and out of player profiles at all times. Game state should always be associated with the correct profile. |
Multi-Disc Games (MDG)
The following requirements apply to games that use more than one disc and require disc swapping during gameplay.
TCR # 016 | MDG Disc Swapping |
---|---|
Requirement | Games must not require the player to swap the disc during system link or Xbox LIVE session-based multiplayer gameplay. |
Intent | Swapping a game disc during multiplayer game play could adversely disrupt the experience of other players. |
TCR # 017 | MDG Disc Identification |
---|---|
Requirement | Games must clearly identify which disc must be inserted to continue gameplay. |
Remarks |
Games specify the disc by providing descriptive text identifying the requested disc to the console. The console tells the player, using the description the game provides to the console, which disc to insert. |
Intent | Make the disc swapping experience as easy as possible for the player. |
Video and Graphics (VID)
The following requirements apply to game usage of video and graphics.
TCR # 018 | VID Widescreen Display |
---|---|
Requirement | When the player has selected widescreen mode, the game must use a 16:9 aspect ratio to render graphics. There must be no distortion of graphics content and cinematics between widescreen and non-widescreen modes. |
Remarks |
In non-widescreen modes, games may use a 4:3 aspect ratio or a 16:9 aspect ratio. 16:9 frame buffers are automatically letterboxed on 4:3 displays. When measured on-screen, game content (characters, buildings, vehicles, for example) should have the same width to height ratio in both widescreen and non-widescreen modes. Game text fonts and UI elements are not required to be rendered in a 16:9 aspect ratio. |
Intent | The Xbox 360 console is designed for a high-definition gaming experience. High definition includes a 16:9 aspect ratio. |
TCR # 022 | VID System UI Framerate |
---|---|
Requirement | Games must ensure that system UI can be rendered at least every 66 milliseconds in all areas of the game for any display mode. |
Remarks |
One way of meeting the requirement is calling IDirect3DDevice9::Present() at least once every 66 milliseconds (15 times per second). Another way of meeting this requirement during load screens is by using the IDirect3DDevice9::Suspend() and IDirect3DDevice9::Resume() APIs. |
Intent | The Xbox 360 console is designed to provide real-time system notifications to the player, and the Xbox Guide may also be activated at any time. In order for the platform to remain responsive when activating the Xbox Guide or displaying notifications, the game will need to yield the graphics processor periodically. |
TCR # 117 | VID Video Mode Support |
---|---|
Requirement | Games must support all video output packs, modes, and resolutions. Games must not have dependencies on any video output packs, modes, or resolutions. |
Remarks |
Games should not assume that the video output packs, modes, and resolutions currently available are the only ones that the platform will ever support. For example, VGA mode could be updated in the future to support other resolutions, or additional video packs could be added. |
Exemption | PAL 50 is not required. |
Intent | Players expect any Xbox 360 titles to be compatible with any video output pack, video resolution, or video mode supported by the console now and in the future. |
Avatar (AVT)
The following requirements apply to games that support avatars.
TCR # 137 | AVT Avatar Change Notification |
---|---|
Requirement | When an avatar is changed, games must reload the changes prior to rendering the avatar. |
Remarks |
The console receives an XN_SYS_AVATARCHANGED system notification when an avatar is changed. |
Intent | A player who changes his or her avatar expects to see those avatar changes reflected in the title. |
Audio (AUD)
The following requirements apply to game usage of audio.
TCR # 024 | AUD Background Music |
---|---|
Requirement | Games must not play their own background music if the player has enabled music playback in the Xbox Guide or Xbox Dashboard. |
Remarks |
Generally, background music is anything that would normally be connected to a game's background music volume setting. Games may use the XACT tool and/or XAudio2 APIs to meet this requirement. Music playback in the Xbox Guide and Xbox Dashboard are not enabled by default and must be enabled by the player. |
Exemption | Games that contain non-interactive FMV sequences where it is not possible to separate the background music from the remainder of the game's audio, such as movie sequences shown during title startup, are allowed to use the XMPOverrideBackgroundMusic() API during such sequences. |
Intent | The Xbox 360 console is designed to allow player customization of the gameplay experience. Players expect to hear the music they have selected regardless of whether they are navigating in the Xbox Dashboard or playing a game. |
User Interface (UI)
The following requirements apply to the in-game user interface.
TCR # 028 | UI Official Naming Standards |
---|---|
Requirement | Games must use the naming standards defined in the latest release of the terminology list. Games must not specifically refer to components of the video game system or components of peripherals that are not listed in the terminology list. |
Intent | Using standard terminology provides consistency from game to game. Once players learn a standard term, they expect that the term will mean the same thing in the next game they play. |
TCR # 029 | UI Error Messaging |
---|---|
Requirement | When an error prevents a game from performing a task dictated by the player or expected under normal gameplay, the game must display a user-friendly message that addresses the error. The game must transparently handle software errors that are not relevant to gameplay. |
Remarks |
Examples of descriptions that are not user-friendly include technical information, such as error codes, module names, network addresses, and debug traces. For example:
In situations in which the player must take action as a result of the error, the message must include information or instructions that help the player correct the problem. |
Intent | Game players want to play games, not debug game errors. Support costs are reduced for the game publisher and Microsoft when error messages are user-friendly to players. |
TCR # 030 | UI Confirmation of Destructive Actions |
---|---|
Requirement | Games must obtain positive confirmation of player intent before performing actions that will result in loss of player data or game state. Confirmation must consist of both of the following: (1) an on-screen message indicating the consequence of the impending action, and (2) the actions the player must take to confirm or cancel the action. |
Remarks |
Destructive actions include, but are not limited to, deleting and overwriting saved games, exiting game sessions, and loading saved games in mid-play. Auto-saving does not require a confirmation of destructive actions message. |
Intent | Prevent unintentional or accidental loss of player data or game state, which can represent hours or days of accomplishment. Loss of that data can be devastating to players. |
Peripherals (PER)
The following requirements apply to the controller and other input peripherals.
TCR # 031 | PER Device Types |
---|---|
Requirement | Games must not restrict input based on device subtypes. |
Intent | Players expect that the default gamepad will work with any game. Players also expect that non-default gamepads will work with any game, provided those gamepads give access to the same set of controls. |
TCR # 033 | PER Controller Selection |
---|---|
Requirement | Players must be able to start the game from the initial interactive screen or attract mode with any supported controller recognized by the console. Once the game is started, the player must not be required to switch controllers to play the game. |
Remarks |
In multiplayer games, the same principle applies to each player. Each player must be able to connect any supported controller and join the multiplayer session. |
Intent | Players expect to be able to pick up any controller and start playing, without having to swap controllers once they have started a game. |
TCR # 034 | PER Controller Discovery |
---|---|
Requirement | In any area in which a player can begin using a controller, the game must respond within one second to the controller being connected or disconnected and update the UI appropriately. The game must not disrupt gameplay as a result of a newly connected controller. |
Intent | Players expect the game to automatically and transparently notice that a peripheral is connected or disconnected. |
Voice Peripherals (VOP)
The following requirements apply to games that use a voice peripheral.
TCR # 041 | VOP Voice Input Detection |
---|---|
Requirement | Games must recognize the availability of a voice peripheral and enable its functionality without disrupting gameplay. |
Remarks |
Voice may become available when the player connects a headset to a controller or connects a controller with a headset already attached. |
Intent | Players expect the game to automatically and transparently notice that a peripheral is connected or disconnected. |
Text Input Devices (TID)
The following requirements apply to games that support use of a virtual keyboard, USB keyboard, or other text input device in the game.
TCR # 043 | TID Keyboard Support |
---|---|
Requirement | Games that support a virtual keyboard must also accept input from a physical text input device (TID). |
Remarks |
Games that use XShowKeyboardUI() automatically meet this requirement. Games that implement their own virtual keyboard may detect text input using XInputGetKeystroke() with the XINPUT_FLAG_KEYBOARD flag. |
Intent | The console supports input from USB keyboards and other text input devices. Players who see a virtual keyboard in a game context expect that they can use any supported keyboard to enter text. |
Video Camera Peripheral (VCP)
The following requirements apply to games that use the video camera peripheral.
TCR # 125 | VCP Preview Display |
---|---|
Requirement | When using the video camera to send video to other players, games must display a preview of the outgoing video. |
Remarks |
Titles may provide gamers the option to disable the self-preview, but the preview feature must be on by default. See the SetLocalPreviewRect() and RenderLocalPreview() in the XDK documentation for additional details. Recommended minimum preview sizes:
|
Intent | Inform the sender that their image is being broadcasted. |
Storage (STR)
The following requirements apply to games that store content on a storage device.
TCR # 045 | STR MU Support |
---|---|
Requirement | Saved games must fit on an empty, formatted, 64-MB memory unit. |
Remarks |
Because 12 MB on the memory unit is reserved for system use, the amount of space available to a game on an empty, formatted MU is 52 MB. |
Intent | The smallest memory unit ever produced for Xbox 360 is 64 MB. A player should not have to purchase a larger MU in order to save a game. |
TCR # 046 | STR Storage Access and Management |
---|---|
Requirement | Games may only access content from storage devices using approved XDK storage APIs. |
Remarks |
Approved APIs can be found in the XDK documentation. |
Intent | The Xbox 360 console supports multiple storage devices through a device abstraction layer. This allows future devices to be supported in titles that have already shipped. |
TCR # 047 | STR Storage Write Warning |
---|---|
Requirement | Games must display a message during storage writes for the following conditions and the respective amount of time:
|
Remarks |
The standard and short messages can be found in the terminology list. Data frequently accessed during gameplay may be stored on the hard drive cache to avoid disrupting gameplay with warning messages. Storage access times of less than 500 ms are exempt from this TCR only if no access to the same storage device occurs within the subsequent three seconds. Games may substitute the required message with a notification option (such as an icon or graphic) as long as that option had been communicated to the player within the current play session, and has been associated to the appropriate required message. This alternate notification must abide by the display times listed in this TCR. |
Exemption | Writes to the hard drive cache for any duration do not require a message. However, BAS Non-Interactive Pause still applies if the write lasts longer than five seconds. |
Intent | Player data can represent hours or days of accomplishment. Players expect to be informed when their actions may result in the loss or corruption of their data. |
TCR # 049 | STR Game Content Persistence |
---|---|
Requirement | Games must gracefully handle all cases in which stored game content is no longer accessible or available. Games must also gracefully handle all cases in which the console reports the content as invalid or unreadable. |
Remarks |
Stored game content includes any type of cached content, saved games, game specific settings, Xbox LIVE content, content packages, persistent data, game clips, and publisher common data. The console will report content as unreadable or invalid in cases in which content is damaged, corrupt, or missing. Games may display a message or display the content as damaged when the system reports the content as invalid or unreadable. Games must consider the TCR "UI Confirmation of Destructive Actions" and not delete invalid or damaged content without first receiving confirmation from the user. |
Intent | On the Xbox 360 console, there is no guarantee of an always-connected storage device. Players expect games to handle situations where game content is inaccessible for any reason, without becoming unstable or crashing. |
TCR # 050 | STR Game Data Storage |
---|---|
Requirement | Games must provide an option that allows the player to select any available storage device for saving game data. If no device is selected, the game must notify the player that no game data will be saved. The notification must occur before any potential data loss. |
Remarks |
Players select a storage device from the Xbox Guide device selector UI. The device selector allows the player to only select storage devices that have free space greater than or equal to the number of bytes the game specifies. See the XShowDeviceSelectorUI() function for details. Game data includes game saves, rosters, snapshots, and so on. Games may automatically load previous saved game data or select the available storage device when only one storage device is present. Games are not required to provide access to the device selector when only one device is present. Note: If only one valid storage device is available to the player, by default the device selector UI will not be displayed when using the XShowDeviceSelectorUI() function. |
Exemption | Games that do not support saves or only store data in the player's profile using the XUserWriteProfileSetting() function are exempt from this requirement. |
Intent | Players want to be able to save data to any connected storage device. Players also want to know when their game progress/state is not going to be saved. |
TCR # 051 | STR Game Data Storage Device Change |
---|---|
Requirement | Games must notify the player if the in-use storage device is unavailable. |
Remarks |
Games may choose to wait to display a message until an interactive state is reached or until the next time the game attempts to access the storage device. For example, if the storage device is removed during a cinematic, the game may wait until after the cinematic finishes before displaying the message to the player. If the storage device is removed during gameplay, the game may wait until the next save attempt before displaying the message to the player. One or more of the following are acceptable actions that games may take when notifying the player:
|
Intent | Players want to know when their game progess/state is not going to be saved. |
TCR # 052 | STR Static Content Caching |
---|---|
Requirement | Games that cache static content to improve performance must save that content into the game's assigned cache partition. |
Remarks |
Static content refers to content stored on the hard drive that will not be modified as a result of gameplay. Games are not allowed to cache content on MUs or other areas of the hard drive. |
Intent | The cache partition is the fastest part of the hard disk, and it is specifically reserved by the system for caching game content. Using the cache partition prevents games from filling up the users' storage area with content that users cannot manage. |
TCR # 118 | STR Game Save Dependencies |
---|---|
Requirement | Game save progress must be associated with a gamer profile and must not have any dependencies on shared content. |
Remarks |
Progress saved while in a game mode such as campaign, season, career, and so on, is considered game save progress and must be associated with a gamer profile. Data can be saved in association with a gamer profile either by passing a non-NULL UserIndex to XContentCreate or by using the XUserWriteProfileSetting function. A game's shared content, such as shared unlocks, offline statistics, and so on, is not required to have an association with a gamer profile. |
Intent | Players expect their profile to be the hub for all of their saved game data. Shared game content is intended to be shared with all users of the console. |
Game Clips (GC)
The following requirements apply to games that support attachments to leaderboard entries on Xbox LIVE.
TCR # 054 | GC Interactive Game Session Recording |
---|---|
Requirement | Games must not upload text chat, voice chat, or video chat recorded in an interactive game session as a gameclip. |
Remarks |
Games are allowed to upload game replay data and game state as part of a game clip. |
Intent | Microsoft policy does not permit the recording of chat. |
TCR # 055 | GC Game Clip Download |
---|---|
Requirement | Games must not automatically or silently download game clips. Game clips must only be downloaded individually through player-initiated action. |
Intent | Online storage API calls require significant server bandwidth. These calls must be limited to allow other games and players to interact successfully with the LIVE service. Players expect to be able to control when their console downloads and stores content. |
Content Packages (CP)
The following requirements apply to games that support content packages.
Content packages are additional game content delivered to the console separately from the original retail game media. This delivery may be made through Xbox LIVE Marketplace, add-on discs, peer-to-peer exchange, or on removable storage media.
TCR # 059 | CP Dependencies on Other Content Packages |
---|---|
Requirement | Content packages must not have dependencies on other content packages. A player must not be required to download additional content packages in order to use a content package. |
Remarks |
It is allowable for one content package to use some or all of the features of another content package. However, there should never be a dependency between the packages. |
Intent | Players expect content packages to be fully contained experiences. If players remove content packages, they should still have an enjoyable experience with any remaining content packages. |
TCR # 060 | CP Content Package Element Transfer |
---|---|
Requirement | A game must not move or copy any element of a content package to alternate storage locations. |
Intent | Content packages are stored in a way that allows the player to manage the content effectively. Content packages that are moved to non-standard locations cannot be appropriately managed by the system. |
TCR # 132 | CP In-Game Offer and Price Descriptions |
---|---|
Requirement | Games that offer items for sale within the game must display the item price in points, the item name, and the item description. |
Remarks |
Items for sale include those items for which the game calls XMarketplaceConsumeAssets and XShowMarketplaceDownloadItemsUI. Games obtain offer price, name, and description from XMarketplaceCreateOfferEnumerator. The price for previously purchased non-consumable offers may be indicated as "already purchased" in the game's UI. |
Intent | To ensure consistency across the Xbox 360 platform, Microsoft policy requires that price, name, and description be clearly communicated to the user prior to any financial transaction taking place. |
TCR # 133 | CP Microsoft Points Display |
---|---|
Requirement | For games that display references to Microsoft Points, the initial reference must include the term "Microsoft® Points". Subsequent usage must be "Microsoft Points", "Points", or the Points logo. |
Remarks |
For details on how to use the Microsoft Points terminology and logo in your game, please refer to Using Microsoft Points in Your Game. Localized versions of "Microsoft® Points" terminology can be found in the terminology list. |
Intent | Provide branding consistency around the use of Microsoft Points across the platform. |
Xbox LIVE Content (LC)
The following requirements apply to games that support Xbox LIVE content.
Xbox LIVE content is content that is transferred to the client Xbox 360 storage area through game interactions and functionalities other than Xbox LIVE downloadable content mechanisms and updates. This content may include player-created content, publisher-provided game updates, game adjustments for server-based games, and so on. It may be provided to the client through the game-specific client-server mechanism or through use of Xbox LIVE technology, such as the Xbox LIVE server platform or the title-managed storage mechanism.
TCR # 061 | LC Content Sharing Privileges |
---|---|
Requirement | Games must not receive any player-created content if the player-created content viewing flag is turned off. |
Remarks |
Player-created content refers to content that a player can create or modify in a game. This includes content such as game snapshots, graphics, maps, voice messages and annotations, video messages, images captured from the camera, and so on. Video chat, text chat, and voice chat are not considered player-created content. Player-editable strings and text tags are not considered player-created content but must be verified per CMTV Player Text String Verification. Games must call the XUserCheckPrivilege() function with the XPRIVILEGE_USER_CREATED_CONTENT flag to detect the setting. |
Intent | Maintain integrity of the privilege system. Players who turn off the player-created content viewing flag do not expect to see player-created content. |
TCR # 062 | LC Per-Player Storage Reads and Writes |
---|---|
Requirement | Within a single game session, a game is permitted one read and write per file using the online storage APIs at the start and the end of a game session for each player. If a game session exceeds five minutes in duration, the game is permitted an additional read-write at each subsequent five-minute interval. |
Remarks |
The "start and end of a game session for each player" refers to when a player enters and exits a game session. The relevant storage read and write APIs are XStorageDownloadToMemory() and XStorageUploadFromMemory(). |
Intent | Online storage API calls require significant server bandwidth. These calls must be limited to allow other games and players to interact successfully with the LIVE service. |
TCR # 063 | LC Storage Read Limits for Per-Title Title Managed Storage |
---|---|
Requirement | The game must not read the same content from per-title title managed storage more than once per hour. |
Remarks |
The relevant storage read API is XStorageDownloadToMemory(). |
Intent | Online storage function calls require significant server bandwidth. These calls must be limited to allow other games and players to interact successfully with the LIVE service. |
TCR # 064 | LC Transmission of Player-Created Content |
---|---|
Requirement | Games must not store player-created content on Xbox LIVE or transmit player-created content to Xbox LIVE outside of the functionality provided by the Xbox LIVE content sharing services. |
Remarks |
Player-created content refers to content that a player can create/modify in a game. This includes content such as game snapshots, graphics, maps, voice messages and annotations, video messages, images captured from the camera, and so on. Player-editable strings and text tags are not considered player-created content but must be verified per CMTV Player Text String Verification. |
Exemption | XLSP titles may transmit content outside of the Xbox LIVE content sharing services but must support content privilege settings for player-created content and communication. Games use XUserCheckPrivilege() and the following constants to check privileges related to this TCR:
|
Intent | Xbox LIVE provides means to control player-created content efficiently and according to the player's privilege settings. Using other means would affect the integrity of the platform. |
TCR # 065 | LC Point-to-Point Content Transmission |
---|---|
Requirement | Games that transmit saved content must not modify the content during transfer, and must transfer the content in its entirety. |
Remarks |
This requirement ensures that content signatures are consistent. Games transfer content using XContentOpenPackage and XContentCreatePackage. An example of a point-to-point transmission scenario is content being transferred from one Xbox 360 console to another Xbox 360 console. |
Intent | Saved content is signed so that invalid content can be revoked. Permitting the game to modify or truncate saved content can impede efforts to prevent the spread of problematic content. |
Gamer Profiles (GP)
The following requirements apply to rich presence, gamercards, and gamer profiles.
TCR # 067 | GP Gamer Preference Inversion Setting |
---|---|
Requirement | Regardless of the game's terminology, games must use the Vertical Look (Y-axis) gamer preference setting as the default when first defining the player's game-specific Vertical Look setting. |
Remarks |
When the Y axis preference is set to "normal," moving the stick forward causes the view to tilt up, while moving the stick backward causes the view to tilt down. When the Y axis preference is set to "inverted," the opposite is true; moving the stick forward causes the current view to tilt down, while moving the stick backward causes the view to tilt up. The term "normal" should not be based on the game's default setting, but rather on the guidelines listed above. |
Intent | The preference settings provide consistency from game to game. Players expect that console games will use the preference settings as the default settings. |
TCR # 068 | GP Gamer Profile Settings Usage |
---|---|
Requirement | Games must not store or transmit gamer card settings. Games must not transmit gamer preferences. Games must not store gamertags or gamer profile names. |
Remarks |
For example, a game must not send a player's motto to other players in a multiplayer game. Examples of gamer card settings include Xbox LIVE Gamer Zone, gamer picture, gamerscore, motto, and so on. Examples of gamer preferences include Game Difficulty, Y-Axis Inversion, Transmission, and so on. Games are allowed to query for and transmit gamertags and gamer profile names as well as display them in the game's UI. |
Exemption | Games may share title custom information. Title custom information is denoted by title-specific settings of type XPROFILE_TITLE_SPECIFIC1, XPROFILE_TITLE_SPECIFIC2, XPROFILE_TITLE_SPECIFIC3. |
Intent | Gamer profile data is stored on the LIVE service and is often modified by players. The LIVE service is the ultimate authority on the correct gamer profile information. |
TCR # 069 | GP No Sharing of Achievements |
---|---|
Requirement | Games must not award achievements to profiles that have not directly earned the achievement. |
Remarks |
A game must only award an achievement to a profile that has accomplished all tasks and progress necessary to reach the achievement. For example, an achievement must not be awarded to a profile based on progress made by a different profile; this includes any progress made and stored with another player's game save. Games determine the profile associated with the game save using the XContentGetCreator() function. Game saves may not be transferred between players by default. Games can override this behavior by setting the XCONTENTFLAG_ALLOWPROFILE_TRANSFER flag to create game saves that can be transferred between players. However, games that choose to allow transferring of saves between profiles must make sure sharing of achievements is not possible. |
Intent | The value of the achievement systems rests in accurately representing what a player has truly accomplished while playing games on the console. |
TCR # 070 | GP Rich Presence |
---|---|
Requirement | In active gameplay, games must update presence information. Presence information must accurately reflect the player's state. |
Remarks |
For example, inactive players must not have the presence information of an active player. Games can use a default rich presence such as "idle" for profiles not in active gameplay. Games use the XUserSetContext() and XUserSetProperty() APIs to fulfill this requirement. |
Intent | Players expect presence information to be updated in real time, so that they may make informed decisions about important gameplay scenarios, such as sending game invitations. |
TCR # 071 | GP Gamer Card Access |
---|---|
Requirement | Games must provide the player the option to access another player's gamer card wherever gamertags are enumerated. |
Remarks |
Examples of where this requirement will apply include leaderboards, session lobbies, and post-game statistics. Games use the XShowGamerCardUI() function to satisfy this requirement. |
Exemption | Gamer card access is not required in local and system link multiplayer game sessions. |
Intent | Providing access to gamer cards in game lobbies and other areas where gamertags are listed gives players the ability to quickly find information about other players, provide feedback, and so on. |
Statistics and Achievements (SA)
The following requirements apply to game statistics and achievements.
TCR # 073 | SA Achievements |
---|---|
Requirement | Games must provide a way for a player to earn all game-defined achievements and update the player's profile. |
Remarks |
Games update the profile using the XUserWriteAchievements() function. Games are required by XLAST (Xbox and LIVE Authoring Submission Tool) to provide at least five achievements with associated values. Achievements may be distributed in offline and/or online gameplay. |
Intent | Players expect to be able to obtain all the achievements in the game. |
TCR # 078 | SA Non-Session Stats Request Limits |
---|---|
Requirement | The game must not call stats read APIs outside of an interactive gaming session without direct user input related to statistics. |
Remarks |
An interactive game session is defined as gameplay that includes interaction with other Xbox LIVE players or includes functionality that interacts with the Xbox LIVE service to upload statistics. |
Intent | Online statistics API calls require significant server bandwidth. These calls must be limited to allow other games and players to interact successfully with the LIVE service. |
TCR # 136 | SA Session Stats Read and Write Limits |
---|---|
Requirement | Games are permitted one read and one write from the stats service during a single interactive game session for each player. If a game session exceeds five minutes in duration, the game is permitted an additional read and/or write at each subsequent five-minute interval. |
Remarks |
The relevant stats read APIs are:
The relevant stats write APIs are:
This TCR does not apply to user-initiated stats reads that happen outside of a game session. |
Intent | Online statistics API calls require significant server bandwidth. These calls must be limited to allow other games and players to interact successfully with the LIVE service. |
Multiplayer Sessions (MPS)
The following requirements apply to games that provide multiplayer game sessions on Xbox LIVE.
Xbox LIVE offers a consistent and simple way to find multiplayer gaming sessions and fine-tune the parameters used to find those sessions.
TCR # 082 | MPS Private Sessions |
---|---|
Requirement | If a game supports player-created or player-hosted sessions, the game must provide the player the ability to create or host the session with all private slots. |
Remarks |
Private sessions are sessions with all private slots. Private sessions are not available in matchmaking queries and therefore do not allow players to join via the matchmaking service. Private sessions are also not joinable via the Xbox Guide without an invite. It is acceptable for any player in a private session to invite another player into that session. Games create private sessions by calling XSessionCreate() with dwMaxPublicSlots set to 0. Games will not meet this requirement by simply creating a game session with a password. This requirement applies only to non-ranked (player match) sessions. Games may prevent spectators from joining private sessions. A game can give the host the option to set a custom mix of private and public slots (a hybrid game). However, this session is not considered a private session due to the presence of public slots. |
Intent | The LIVE service is founded on the principle of multiplayer gameplay with friends. Sessions with all private slots allow players to invite their friends to play. |
TCR # 083 | MPS Updating Session State |
---|---|
Requirement | The host of a session-based game must update the session state within one second using the approved APIs whenever a player joins or leaves the session, or whenever slots are reassigned between public and private designations. |
Intent | Players expect game session information to be up to date, so that they may join an open session of their choosing. By keeping the data on the LIVE service fresh, players are less likely to attempt to join a game that is full or that does not otherwise match their expectations. |
TCR # 084 | MPS Interoperability |
---|---|
Requirement | Xbox LIVE multiplayer games within the same console region and those that support cross-region play must maintain interoperability with other consoles regardless of audio modes, video modes, or language settings. |
Remarks |
The side effects of disparate audio and video settings must be transparent to the player. The player expects to be able to play with anyone who has the same game. The framerate type and capabilities of TVs and audio receivers should not be a consideration in setting up a match. |
Intent | Players expect that the console configuration should not impact their ability to play online with others. |
TCR # 086 | MPS No Multiplayer |
---|---|
Requirement | Games must not allow multiplayer play when the multiplayer privilege is turned off. |
Remarks |
The system automatically prevents establishing sessions between consoles when the multiplayer privilege is turned off. In cases in which a game connects to a non-Xbox LIVE game server, the game must enforce this requirement. Games check multiplayer privilege by calling the XUserCheckPrivilege() function with the XPRIVILEGE_MULTIPLAYER_SESSIONS flag. |
Exemption | This requirement does not apply to system link (console-to-console) game modes. |
Intent | Maintain the integrity of the privilege system. Players who turn off multiplayer play expect the game to behave accordingly. |
TCR # 087 | MPS Multiple Players on the Same Console |
---|---|
Requirement | Multiple players on the same console must always join game sessions together. If the players cannot join together, the game must display a message explaining why they cannot join. |
Remarks |
Games must not require idle profiles—profiles not participating in the game—to join a game session. Examples of when players may not be able to join together include:
|
Intent | Players on the same console expect to play together. |
TCR # 088 | MPS Supported Gamertag Characters |
---|---|
Requirement | Games must correctly display all 15 characters of any gamertag. Gamertags consist of ASCII characters a–z, A–Z, 0–9, (, ), and " " (ASCII character 0x20). |
Remarks |
While a gamertag cannot be created with parentheses, a guest's gamertag may include parentheses. The system truncates guest gamertags as necessary. |
Intent | A gamertag is a player's identity on the Xbox LIVE service. Players expect their tags to be correct across all games and to be able to use gamertags to find friends. |
TCR # 115 | MPS Game Invitations |
---|---|
Requirement | Games must allow players to send game invitations for game sessions. Games must also allow players to join sessions. |
Remarks |
To meet this requirement, games must:
This requirement applies to both same-title and cross-title invitations and joins. It is not necessary to allow a player to join the game session if the session is full. |
Intent | The Xbox LIVE service is designed to provide an easy, consistent way for players to join multiplayer game sessions and invite other players. |
TCR # 124 | MPS Guest Support |
---|---|
Requirement | Games that support multiplayer play on Xbox LIVE with more than one player per console must allow guests to play. |
Remarks |
Games support guest sign-in by calling XShowSigninUI() with Xbox LIVE profiles. |
Intent | The concept of guests is influential in new consumers choosing to join the LIVE service. |
TCR # 138 | MPS Xbox LIVE Party Invitations |
---|---|
Requirement | In multiplayer lobbies, games must provide the player the option to send game invitations to members of their Xbox LIVE Party session if there is a party session active, or to friends if there is no party session active. |
Remarks |
When a player is in an Xbox LIVE Party session with at least one other player, games may meet the requirement by providing an option labeled "Invite Xbox LIVE Party" and calling XPartySendGameInvites(). When a player is not in an Xbox LIVE Party session, or if the player is the only member of their party session, games may meet the requirement by providing an option labeled "Invite Friends" and either invoking XShowFriendsUI() or calling XInviteSend() for friends. |
Exemption | Through May 31, 2009, the Xbox LIVE Party TCRs will only be enforced against titles supporting Xbox LIVE Party. Submissions entering certification for the first time on or after June 1, 2009 are required to adhere to Xbox LIVE Party TCRs. |
Intent | The Xbox LIVE Party system allows players to stay together across games and game sessions in order to enjoy the experience of playing together. Having easy access to send party invitations in the multiplayer lobby facilitates this experience. |
TCR # 139 | MPS Xbox LIVE Party Community Sessions |
---|---|
Requirement | Games must have an option within the main menu, or within a multiplayer menu, that provides an Xbox LIVE party member the ability to locate sessions containing members of the same Xbox LIVE Party session. |
Remarks |
Games meet this requirement by providing access to the Guide's Xbox LIVE Party sessions section. Games launch the Guide's Xbox LIVE Party sessions section by calling XShowCommunitySessionsUI. Games can also meet this requirement by providing in-game UI that displays a list members of the user's Xbox Live Party session who are playing the same title, with the option to join any multiplayer sessions that are available. |
Exemption | Through May 31, 2009, the Xbox LIVE Party TCRs will only be enforced against titles supporting Xbox LIVE Party. Submissions entering certification for the first time on or after June 1, 2009 are required to adhere to Xbox LIVE Party TCRs. |
Intent | The Xbox LIVE Party system allows players to stay connected together across different game sessions and games. Providing players a consistent, easy way to find party members through the main menu or multiplayer menu facilitates this experience. |
TCR # 140 | MPS Quick Match |
---|---|
Requirement | Games must have a quick match option for multiplayer game sessions. The quick match option must allow the player to enter the game session using a sequence of default button presses. |
Remarks |
Quick match allows the player to quickly join a game session without having to select any settings prior to entering gameplay. Refer to the Xbox 360 terminology database for required naming conventions. |
Intent | The Xbox LIVE service is designed to help players who want to quickly and easily enter a multiplayer match. |
TCR # 141 | MPS Matchmaking |
---|---|
Requirement | Games must support an option that allows a player to join an Xbox LIVE game session. The game must notify the Xbox LIVE service by setting the appropriate session context. |
Remarks |
Games may choose to offer either ranked or player matches, or both. Games notify the Xbox LIVE service about a ranked session by setting the session context to X_CONTEXT_GAME_TYPE_RANKED. Games notify the Xbox LIVE service about a standard session by setting the session context to X_CONTEXT_GAME_TYPE_STANDARD. |
Intent | The Xbox LIVE session context and properties provide an easy, consistent way for players in multiplayer games to find other gamers with similiar preferences to play with. |
Communication, Messaging, Text, Voice (CMTV)
The following requirements apply to games using communication, messaging, text, voice, photos, and/or video streaming from the video camera. Games support in-game voice communication by using XHV.
TCR # 089 | CMTV Supporting Voice |
---|---|
Requirement | All Xbox LIVE multiplayer games must support voice chat, at a minimum, between one player on one console and another player on a second console. |
Intent | Voice chat is an integral part of the Xbox LIVE experience. Players expect voice chat in all titles that support LIVE multiplayer. |
TCR # 090 | CMTV Muting Support |
---|---|
Requirement | Games must prevent muted players from communicating on Xbox LIVE. The player that mutes:
The muted player:
|
Remarks |
Games determine a player's mute status by checking XUserMuteListQuery(). "Seeing" the player refers to use of the video camera to transmit a player's image or representation between consoles. Seeing does not refer to the display of a player's game-created avatar or character. This TCR applies to all forms of communication, including voice, video, and text chat. An example of real-time text communication is in-game text chat. |
Intent | Allow players to control access to communication with them. Maintains the integrity of the muting system. |
TCR # 091 | CMTV Communication in the Clear |
---|---|
Requirement | Voice, video, and text chat among players must be transmitted in the clear (unencrypted) using the VDP network protocol. The unencrypted portion of VDP packets must contain only voice, video, or text chat data. |
Remarks |
Communication stored in a message or attachment is not required to be transmitted in the clear. |
Intent | Microsoft policy does not permit the transmission of encrypted voice, video, or text chat. |
TCR # 092 | CMTV Player Text String Verification |
---|---|
Requirement | Any player-entered text visible to another player on Xbox LIVE must be verified using the Xbox LIVE service before being transmitted. Text that is rejected by the Xbox LIVE service must not be displayed |
Remarks |
This requirement applies to any player-entered string that can be exposed to other players on Xbox LIVE. It includes session names, content descriptions, text messages, tags, team names, mottos, comments, and so on. Games may decide to not send the text, blank it out, or use generic text if the text was rejected by the Xbox LIVE service. Games verify the text by using XStringVerify(). |
Exemption | It is not required to use the Xbox LIVE service to verify real-time text communication. An example of real-time text communication is in-game text chat. |
Intent | Protect players from inappropriate language. |
TCR # 093 | CMTV No Communication |
---|---|
Requirement | Games must not transmit text chat, voice chat, or video chat when the communication privilege is turned off. |
Remarks |
In cases in which multiple players are signed in on one console, games must respect the most restrictive communications settings among all users. This includes situations in which the most restrictive settings are set for a gamer that is "idle" in a session (that is, signed in to the console but not actively participating in the session). Games that use XHV meet the voice communication requirement of this TCR by registering remote users playing on Xbox LIVE as remote talkers in the XHV API. XHV enforces a player's individual voice restrictions through the headset; however, XHV will enforce the most restrictive communication among all players on the same console through the speakers. The game may choose to notify active players that the restrictive privileges are set for an idle player signed in to the console. |
Intent | Maintain the integrity of the privilege system. |
TCR # 094 | CMTV Friends-Only Communication |
---|---|
Requirement | Games must only allow communication between friends when the friends-only communication privilege is on. |
Remarks |
In cases in which multiple players are signed in on one console, games must respect the most restrictive communications settings among all users. This includes situations in which the most restrictive settings are set for a gamer that is "idle" in a session (that is, signed in to the console but not actively participating in the session). Games that use XHV meet the voice communication requirement of this TCR by registering remote users playing on Xbox LIVE as remote talkers in the XHV API. XHV enforces a player's individual voice restrictions through the headset; however, XHV will enforce the most restrictive communication among all players on the same console through the speakers. The game may choose to notify active players that the restrictive privileges are set for an idle player signed in to the console. It is acceptable for games to be more restrictive and not allow any communication when the friends-only communication privilege is turned on. |
Intent | Maintain the integrity of the privilege system. |
Network (NET)
The following requirements indicate how Xbox LIVE multiplayer games should behave based on network characteristics.
TCR # 095 | NET Connection Status Notifications |
---|---|
Requirement | Games must properly detect and handle loss of network connectivity in all areas of the game. |
Remarks |
Consoles can lose connectivity to Xbox LIVE and other connected consoles at any time for a variety of reasons. The console issues an XN_LIVE_CONNECTIONCHANGED notification when Xbox LIVE connectivity status changes. Games should not interrupt gameplay unless loss of connectivity directly affects the player. Note that loss of connection to Xbox LIVE does not necessarily imply that the console has lost connections to other consoles. |
Intent | Network connectivity can drop for many reasons. Players expect games to automatically and gracefully handle loss of connectivity. |
TCR # 096 | NET Console-to-Console Network Performance |
---|---|
Requirement | Peer-to-peer gameplay between two different consoles must not be disconnected as long as the following performance conditions are maintained:
|
Remarks |
These conditions apply on an individual basis with only one condition applicable at any one time. |
Intent | Some players' network connections have poor connectivity characteristics. Players desire that games are robust in the face of poor connectivity. |
TCR # 097 | NET Console-to-Datacenter-Hosted Server Network Performance |
---|---|
Requirement | Console-to-datacenter-hosted gameplay must not be disconnected as long as the following performance conditions are maintained:
|
Remarks |
These conditions apply on an individual basis with only one condition applicable at any one time. |
Intent | Some players' network connections have poor connectivity characteristics. Players desire that games are robust in the face of poor connectivity. |
TCR # 098 | NET NAT Type Interoperability |
---|---|
Requirement | Games must not prevent players from playing on Xbox LIVE because of NAT type. |
Remarks |
A game may restrict, based on NAT type, whether a player can join a session and whether they are allowed to host a session. However, the game must not completely prevent players from playing online. |
Intent | Players expect to be able to play games over the LIVE service, regardless of their network configuration. |
Xbox LIVE Server Platform (XLSP)
The following requirements apply to Xbox LIVE games that support the use of title servers and game servers.
TCR # 099 | XLSP Server Connectivity Loss |
---|---|
Requirement | If a game cannot establish a connection to the required non–Xbox LIVE game server, the game must display the appropriate message specified in the Terminology List. |
Remarks |
Because issues other than connection and authentication problems can cause a player to become disconnected from the non–Xbox LIVE game server and still remain connected to Xbox LIVE, games are required to inform the player of the specific connectivity loss. |
Intent | In the event of connectivity issues, provide players with the knowledge of whom to contact to resolve the issue. |
TCR # 100 | XLSP Client Caching of Connection Information |
---|---|
Requirement | The game must not depend on game server connection information, such as IP address, being consistent from sign-in to sign-in. |
Intent | Publisher XLSP servers may move, go offline, or be reconfigured. Ensure that the games are connecting to the right server, and give the publisher the necessary flexibility to make back-end changes to their XLSP servers without requiring a title update. |
TCR # 101 | XLSP Player Sign-Out |
---|---|
Requirement | When a player signs out of Xbox LIVE, the game must not retain a connection between the player and the game server. |
Intent | Game player privileges can change over time. Ensuring that a player is disconnected from the LIVE service protects the security of the platform for both Microsoft and the publisher. Players expect to be in an offline state when they sign out of the LIVE service. |
System Link (SL)
The following requirements apply to games that implement system link features.
TCR # 102 | SL System Link Play Interoperability |
---|---|
Requirement | Games must not support gameplay with any non-Xbox 360 systems or components and must only connect to consoles directly or through a local network. |
Remarks |
Xbox LIVE connectivity must not be required for system link gameplay. |
Intent | System link play between consoles or over a local area network should be easy for game players to set up. To protect the integrity of the Xbox LIVE service and the console, connectivity with non-trusted consoles or servers is not allowed. |
Advertised Feature Requirements (AFR)
Advertised features are select game features that are denoted on the game packaging. The feature icon on the packaging identifies that a game has met the functionality requirements to support specific features.
TCR # 104 | AFR Online Multiplayer |
---|---|
Requirement | To qualify for the multiplayer feature icon, games must support online multiplayer gameplay between at least two players on the Xbox LIVE service. |
Intent | Ensure that the game provides the functionality listed on the packaging. |
TCR # 105 | AFR Leaderboards |
---|---|
Requirement | To qualify for the leaderboards feature icon, games must provide the player a way to access the game-specific leaderboard information from within the game. |
Intent | Ensure that the game provides the functionality listed on the packaging. |
TCR # 106 | AFR System Link |
---|---|
Requirement | To qualify for a system link feature icon, games must support multiplayer system link gameplay between a minimum of two consoles that are connected to each other via an Ethernet cable. |
Intent | Ensure that the game provides the functionality listed on the packaging. |
TCR # 107 | AFR Spectator Mode |
---|---|
Requirement | To qualify for the spectator mode feature icon, games must allow online players to watch other online players without participating in the game session. |
Intent | Ensure that the game provides the functionality listed on the packaging. |
TCR # 108 | AFR Offline Co-Op |
---|---|
Requirement | To qualify for the co-op feature icon, games must support offline cooperative multiplayer gameplay on the same console. |
Intent | Ensure that the game provides the functionality listed on the packaging. |
TCR # 109 | AFR Online Co-Op |
---|---|
Requirement | To qualify for the Xbox LIVE co-op feature icon, games must support online cooperative multiplayer gameplay. |
Intent | Ensure that the game provides the functionality listed on the packaging. |
Game Demos (DEM)
The following requirements apply to game demos and promotional discs, including magazine companion discs and retail promotional giveaways. Game demos must also meet all requirements in the preceding sections. Xbox LIVE Arcade titles are not considered game demos.
TCR # 110 | DEM Exiting Demo |
---|---|
Requirement | If the game demo is launched by a shell or a launcher program, the game demo must include a UI option to return to the launcher. |
Remarks |
Demos used as part of a compilation disc or supplied at Xbox LIVE Marketplace are launched by a shell or launcher program. |
Exemption | Stand-alone demos are not required to have an option to return to a launcher. |
Intent | Ensure that players have an obvious way to quit the game without having to restart the console or open the Xbox Guide. |
TCR # 111 | DEM Timeout |
---|---|
Requirement | Demos must return to the launcher when there has been no user interaction for the duration of the specified demo timeout. |
Remarks |
Because demos may end up on compilation discs, the control for how long they run without user interaction is determined by settings on the compilation disc. |
Exemption | Stand-alone demos are not required to return to a launcher. |
Intent | Allowing game demos to rotate in the kiosk promotes an engaging retail experience that ultimately encourages the sale of games and consoles. |
TCR # 112 | DEM Storage Use |
---|---|
Requirement | Unless otherwise approved, game demos are not allowed to use storage. |
Intent | Demos are not intended to be as fully featured as full titles. Prohibiting storage use for demos reduces the complexity of demo certification for both Microsoft and publishers. |
TCR # 114 | DEM No Achievements |
---|---|
Requirement | Demos must not use achievements. |
Intent | Demos are not intended to be as fully featured as full titles. Achievements promote the sale of the full retail title. |
Xbox LIVE Arcade (XLA)
The following requirements apply to Xbox LIVE Arcade titles. Xbox LIVE Arcade titles must also meet requirements in the preceding sections.
TCR # 126 | XLA Trial and Full Version |
---|---|
Requirement | Xbox LIVE Arcade titles must support both trial and full versions of the game. The game must check the license and launch the trial or the full version appropriately. The trial version must provide the player the option to purchase the full version when exiting the game. |
Remarks |
In order to meet the requirement to launch the game appropriately, games use XContentGetLicenseMask() to check for the proper license mask for the current user on the current machine upon three events:
If the license mask purchased bit is '0', the game is available in trial mode. If the purchased bit is '1', the game is available as the full version. The trial version is not allowed to create or access save games, post to leaderboards, provide online multiplayer modes, distribute achievements, or access downloadable content. This restriction does not apply to user preferences. Trial versions can allow players to store user preferences and control mappings in the player's profile. |
Intent | Promote the sale of the full arcade title, and ensure that users are getting the correct version. |
TCR # 127 | XLA Main Menu |
---|---|
Requirement | Xbox LIVE Arcade titles must support a main menu that includes the following menu options.
|
Remarks |
Information about the contents for each menu option can be found in the XDK documentation. Games typically display their primary game modes, such as single player and multiplayer, at the top of this menu. It is acceptable to add additional menu options. |
Intent | Promote a consistent experience across all Xbox LIVE Arcade titles. |
TCR # 128 | XLA Pause Menu |
---|---|
Requirement | Xbox LIVE Arcade titles must support a pause menu that includes the following menu options.
|
Remarks |
Information about the contents for each menu option can be found in the XDK documentation. It is acceptable to add additional menu options. |
Intent | Promote a consistent experience across all Xbox LIVE Arcade titles. |
TCR # 129 | XLA Help & Options Menu |
---|---|
Requirement | Xbox LIVE Arcade titles must support a Help & Options menu that includes the following menu options.
|
Remarks |
Information about the contents for each menu option can be found in the XDK documentation. It is acceptable to add additional menu options. |
Intent | Promote a consistent experience across all Xbox LIVE Arcade titles. |
TCR # 130 | XLA Leaderboard Support |
---|---|
Requirement | Xbox LIVE Arcade titles must support at least one leaderboard that is displayed in the Xbox LIVE Arcade dashboard. In-game leaderboards must offer, at a minimum, a Friends view, an Overall view, and a My Score view. |
Remarks |
Information about leaderboard views can be found in the XDK documentation. |
Intent | Promote a consistent experience across all Xbox LIVE Arcade titles. |