Technical Certification Requirements - March 2009 (v1.5i)
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 [email protected].
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| 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. |
| 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. |
| Games must be playable on the most basic retail console configuration. |
| 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. |
| Xbox LIVE Arcade games are allowed to require a profile for gameplay. Primetime titles use the hard drive. |
| 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. |
| 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. |
| 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. |
| 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. |
| Games must not eject the game disc, require the player to eject the game disc, or require the player to restart the console. |
| 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. |
| The Xbox 360 experience is designed to allow players to enjoy games without having to repeatedly interact with the console. |
| 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. |
| 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. |
| 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. |
| Games that take longer than 15 seconds to load must employ methods to engage the player. Overall load times must not exceed 60 seconds. |
| 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. |
| 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. |
| 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. |
| The most recent and approved library update, or QFE, for an XDK version is considered to be part of a specific XDK release. |
| Approved XDK libraries undergo extensive integrity testing as a family unit. Security and integrity cannot be guaranteed across library versions. |
| Game executables must be linked with the approved LIBCMT or LIBCPMT library that is included in the XDK. |
| The Xbox 360 CRT includes console security features not available in generic implementations of the C runtime. |
| The Microsoft approved XDK C/C++ run-time libraries contain security and integrity features that protect the console. |
| Games must not request, store, or transmit any player's personal information, including, but not limited to:
|
| Player account credentials include Windows Live ID, password, secret question, secret answer, Xbox LIVE pass code, and so on. |
| Protect private consumer information. |
| 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. |
| 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. |
| 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. |
| Games must not change the clock speed of the memory or of any processor. |
| Adjusting the clock speed of memory or processors may damage the Xbox 360 console. |
| Games must not output debug information via the network, on-screen messages, or a file on any storage device. |
| Games must not use OutputDebugString() in retail builds. |
| 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. |
| Games must properly detect and handle player profiles signing in or out in all areas of the game. |
| 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. |
| 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| Games must not require the player to swap the disc during system link or Xbox LIVE session-based multiplayer gameplay. |
| Swapping a game disc during multiplayer game play could adversely disrupt the experience of other players. |
| Games must clearly identify which disc must be inserted to continue gameplay. |
| 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. |
| 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| 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. |
| 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. |
| The Xbox 360 console is designed for a high-definition gaming experience. High definition includes a 16:9 aspect ratio. |
| Games must ensure that system UI can be rendered at least every 66 milliseconds in all areas of the game for any display mode. |
| 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. |
| 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. |
| Games must support all video output packs, modes, and resolutions. Games must not have dependencies on any video output packs, modes, or resolutions. |
| 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. |
| PAL 50 is not required. |
| 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| When an avatar is changed, games must reload the changes prior to rendering the avatar. |
| The console receives an XN_SYS_AVATARCHANGED system notification when an avatar is changed. |
| 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| Games must not play their own background music if the player has enabled music playback in the Xbox Guide or Xbox Dashboard. |
| 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. |
| 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. |
| 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| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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| Games must not restrict input based on device subtypes. |
| 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. |
| 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. |
| 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. |
| Players expect to be able to pick up any controller and start playing, without having to swap controllers once they have started a game. |
| 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. |
| 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| Games must recognize the availability of a voice peripheral and enable its functionality without disrupting gameplay. |
| Voice may become available when the player connects a headset to a controller or connects a controller with a headset already attached. |
| 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| Games that support a virtual keyboard must also accept input from a physical text input device (TID). |
| 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. |
| 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| When using the video camera to send video to other players, games must display a preview of the outgoing video. |
| 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:
|
| 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| Saved games must fit on an empty, formatted, 64-MB memory unit. |
| 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. |
| 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. |
| Games may only access content from storage devices using approved XDK storage APIs. |
| Approved APIs can be found in the XDK documentation. |
| 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. |
| Games must display a message during storage writes for the following conditions and the respective amount of time:
|
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| Games that do not support saves or only store data in the player's profile using the XUserWriteProfileSetting() function are exempt from this requirement. |
| 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. |
| Games must notify the player if the in-use storage device is unavailable. |
| 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:
|
| Players want to know when their game progess/state is not going to be saved. |
| Games that cache static content to improve performance must save that content into the game's assigned cache partition. |
| 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. |
| 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. |
| Game save progress must be associated with a gamer profile and must not have any dependencies on shared content. |
| 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. |
| 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| Games must not upload text chat, voice chat, or video chat recorded in an interactive game session as a gameclip. |
| Games are allowed to upload game replay data and game state as part of a game clip. |
| Microsoft policy does not permit the recording of chat. |
| Games must not automatically or silently download game clips. Game clips must only be downloaded individually through player-initiated action. |
| 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| 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. |
| 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. |
| 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. |
| A game must not move or copy any element of a content package to alternate storage locations. |
| 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. |
| Games that offer items for sale within the game must display the item price in points, the item name, and the item description. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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| Games must not receive any player-created content if the player-created content viewing flag is turned off. |
| 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. |
| Maintain integrity of the privilege system. Players who turn off the player-created content viewing flag do not expect to see player-created content. |
| 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 mi
分享到：
发表评论
wapysun
最新评论
|
评论