Games for Windows : 技術要件
Microsoft Corporation
Version 1.2.0008
2008 年 3 月
このガイドラインに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。変化する市場状況に対応する必要があるため、これらの見解は変更される場合があります。マイクロソフトは、このドキュメントの内容に関して、明示的か暗黙的かを問わず、一切保証致しません。法律によって許可される場合を除き、マイクロソフトの書面による許可なくこのドキュメントを複製することを禁じます。
ここでは、次のカテゴリについて説明します。
- Games for Windows
- セキュリティおよび互換性
- インストール
- 信頼性
- Xbox 360 Controller for Windows の用語
- ゲーム ミドルウェア製品のガイドライン
- Games for Windows ショーケース
- リソース
Games for Windows
ゲームの要件の概要
お客様に対する利点
コンピューター ゲームは、Windows における主要なエンターテイメント体験の 1 つですが、ここ何年もの間、使いやすさに関する問題がお客様のフラストレーションの原因となっています。従来から、ゲームはアプリケーションのようにインストールされますが、Xbox 360 コンソールのゲーム体験に示されるように、その利用方法はむしろ映画や音楽などのエンターテイメント メディアに近いものです。ゲーム エクスプローラーのような新技術によって、標準的なアプリケーションとは異なる一貫した方法でゲームが公開されます。また、このような新技術によって、ミュージックやピクチャと共にゲームにも Windows で最上の市民権が与えられます。ここに示す要件は、Windows Vista で、よりアクセスしやすく統一され、向上したゲーム体験を提供できるようにするためのものです。それと同時に、これらの要件によって Windows XP との互換性も保証します。
ここでは、次の要件について説明します。
- 1.1 ゲーム エクスプローラーとの統合
- 1.2 家族のための安全設定/保護者による制限のサポート
- 1.3 リッチ セーブ データのサポート
- 1.4 Xbox 360 Controller for Windows のサポート
- 1.5 マルチ アスペクトおよびマルチ解像度のサポート
- 1.6 Windows Media Center からの起動のサポート
- 1.7 Direct3D のサポート
1.1 ゲーム エクスプローラーとの統合
要件
ゲームは、Windows Vista のゲーム エクスプローラー (ゲーム フォルダー) 内に表示される必要があります。また、ゲームを選択すると、パブリッシャー、開発者、リリース日、バージョン、Windows エクスペリエンス インデックスのスコア、レーティング (該当する場合)、および関連するハイパーリンクなど、正しいメタデータが表示されなければなりません。
さらに、Windows Vista 以降のバージョンの Windows で開発する際、ゲームのインストーラーは次のルールに準拠する必要があります。
- インストール時に、ゲームを起動するショートカットをデスクトップ、[スタート] メニュー、およびその他の場所に作成してはいけません。
- 削除のためのタスクおよびショートカットを作成してはいけません。
- ユーザーが、Windows Vista 以降のバージョンの Windows ではコントロール パネルの [プログラムと機能] を、Windows XP では [プログラムの追加と削除] を使用してゲームを削除できる必要があります。
Windows XP 以前のバージョンの Windows では、ゲーム インストーラーでプログラム グループ、デスクトップ アイコン、またはショートカットを必要に応じて自由に作成することができます。
理由
Windows Vista のゲーム エクスプローラーは、コンセプト的には Windows XP のマイ ドキュメント フォルダーやマイ ピクチャ フォルダーと似ています。そのコンセプトは、同じ種類のコンテンツを 1 か所にまとめて、整理やコンテキストに応じた操作を容易にするというものです。ゲーム エクスプローラーは、マイ ドキュメントやマイ ピクチャのコンセプトを拡張して、ゲームの整理や管理の機能をさらに充実させます。プレイヤーはゲーム エクスプローラーを使用して、システムにインストールされているすべてのゲームに対して、表示、整理など、必要な操作を行えます。また、ゲーム パブリッシャーは、重要なゲーム情報をより効果的に伝えることができます。システムは完全にデータ主導型であるため、ゲーム パブリッシャーは製品のライフサイクルを通じてゲーム情報を簡単に更新できます。
Additional Information
ゲーム エクスプローラーと統合するには、ゲーム定義ファイル (GDF) を作成する必要があります。GDF は、サムネイル ビットマップ イメージと共にリソースとしてバイナリ ファイル (実行可能ファイルまたは DLL) に埋め込まれる XML テキスト ファイルです。次に、ゲームをゲーム エクスプローラーに登録する必要があります。GDF を使用して、ゲームのタイトル、パブリッシャー、開発者、Web サイトやオプション タスクへのリンクなど、追加情報へのアクセスを提供することもできます。サポート タスクは Web サイトへのリンクのみですが、プレイ タスクはオプションのサポート タスクにも使用できます。
Windows Vista のゲーム エクスプローラーとの統合の詳細は、DirectX SDK に記載されています。DirectX SDK には GDF エディターが含まれているほか、GDFExampleBinary サンプルに GDF のサンプルが含まれています。GameUxInstallHelper サンプルは、必要な機能を既存のインストール システムに統合するためのルーチンを提供します。Game Definition File Validator は、GDF を評価するためのデバッグ サポートを提供します。また、C++ 用 DirectX SDK ドキュメントの Windows ゲーム エクスプローラーの統合に関する記事も参照してください。
Windows Vista Business Edition および Enterprise Edition では、[スタート] メニューに [ゲーム] リンクが表示されません。ただし、[すべてのプログラム]、[ゲーム] の順にクリックすることで、ゲーム エクスプローラーを [スタート] メニューから使用できます。
ゲームと共にインストールされる、ゲーム以外の関連アプリケーションは、Windows Vista を含むすべてのバージョンの Windows で [スタート] メニューのプログラム グループ、ショートカット、およびデスクトップ アイコンを自由に作成することができます。このような関連アプリケーションは、Games for Windows の該当する要件を満たす必要があります。詳細については、「ゲーム ミドルウェア製品のガイドライン」を参照してください。
1.2 家族のための安全設定/保護者による制限のサポート
要件
ゲームでは、次のルールに準拠して、Windows Vista の家族のための安全設定を完全にサポートする必要があります。
- ゲームをプレイするのに、管理者権限を要求してはいけません。インストール、修正プログラムの適用、および削除には、セクション 3 の要件に従い、管理者権限を要求してもかまいません。
- ESRB や PEGI など、Windows Vista がサポートするレーティング ボードによって規制されているゲームでは、そのレーティング情報をゲーム定義ファイル (GDF) に含める必要があります。使用可能なすべてのレーティング データを、ローカライズされているすべてのバージョンの GDF と共に、言語に依存しないバージョンに含める必要があります。
- ランダムに命名された実行可能ファイルを実行時に作成する海賊版対策テクノロジをゲームで使用していない限り、アプリケーションの制限機能の操作性を向上させるために、実行可能ファイルの一覧を GDF に含める必要があります。
- ゲームは Windows Vista での起動中にゲーム エクスプローラー インターフェイスの VerifyAccess メソッドを呼び出し、*pfHasAccess を FALSE として返した場合は終了する必要があります。
理由
すべてのゲームは、Windows Vista の保護者による制限によって制御されたアカウントでゲームをプレイできるように、標準ユーザー アカウントのコンテキストで動作する必要があります。保護者は、子供によるゲームへのアクセスを監視および制限する機能を必要としています。さらに、子供が目にするゲームを保護者が監視および制限できるようにするためのより優れた方法を求める声が、数多くの業界、政府、および支持団体から上がっています。マイクロソフトでは、Windows Vista のゲーム エクスプローラーによって提供される新しいアーキテクチャと併せて、Windows Vista の保護者による制限によってこの機能を保護者に提供します。
レーティング ボード プログラムに参加していないゲームでも、上位の権限を要求すると、大部分のユーザー アカウントでプレイがしづらくなります。保護者による制限が有効になっており、ゲームを起動するたびに保護者が管理者パスワードを入力しなければならない場合は特に、その傾向があります。
Windows Vista の保護者による制限システムでは、子供に対して適切と思われるレーティングを保護者が選択できます。保護者による制限は、世界中のレーティング システムの多くをサポートしています。また、保護者はコンテンツ記述子 (該当するレーティング システムでサポートされている場合) に基づいて制限を加えたり、ゲームごとにアクセスを許可または拒否することができます。
Windows Vista の保護者による制限におけるレーティング システムの既定の選択は、システムのローカル設定に基づきますが、コントロール パネルの [地域と言語のオプション] を使用すると、ユーザーによる変更が可能です。そのため、必要なレーティング ボードをユーザーが自由に選択できるように、サポートされている各言語で使用可能なすべてのレーティング データを提供する必要があります。
Additional Information
レーティング取得していないゲームも、標準ユーザーでのプレイをサポートし、VerifyAccess を呼び出すように、この要件を満たす必要があります。このようなゲームは、既定で規制なしのカテゴリに設定され、ゲーム エクスプローラーに "レーティングは提供されていません" というテキストが表示されます。また、これらのゲームには、規制なしのゲームに関するペアレンタル コントロールの [ゲームの制限] 設定が適用されます。制限の既定の設定は [許可]です。
コンテナー バイナリが正しく Authenticode 署名されていない場合、GDF のレーティング情報は無視されます。要件 2.3 を参照してください。
DirectX SDK の Game Definition File Editor にはサポートされているすべてのレーティング システムが含まれており、ローカライズされているすべてのバージョンの GDF および言語に依存しないバージョンにこの情報が正しく複製されます。GDFTrace ツールによって、存在するすべてのレーティング情報がデコードされて確認されます。2008 年 3 月以降のバージョンのツールを使用してください。
Windows Vista Service Pack 1 では、ペアレンタル コントロール サポートを強化するために、GRB (韓国) のレーティング システムを追加すると共に、既存のコンテンツ記述子の "mild" のバリエーションを追加して ESRB コンテンツ記述子を拡張しています。注意 :Windows Vista Service Pack 1 (SP1) の新しい ESRB コンテンツ記述子を含めたタイトルは "規制なし" と表示されます。SP1 を適用していない Windows Vista の場合、GRB のデータは無視されます。
ゲームを標準ユーザーの権限に対応させる方法の詳細については、DirectX SDK の記事「ゲーム開発者向けのユーザー アカウント制御」を参照してください。
ゲーム定義ファイル (GDF) の詳細については、要件 1.1 を参照してください。
1.3 リッチ セーブ データのサポート
[この要件は廃止されました]
1.4 Xbox 360 Controller for Windows のサポート
要件
ゲームパッド コントローラーをサポートするゲームでは、XInput API を使用して Xbox 360 Controller for Windows をサポートする必要があります。DirectInput 周辺機器もサポートする場合は、DirectInput を使用することもできます。ただし、Xbox 360 対応デバイスを使用する場合は、XInput が既定の API でなければなりません。
共通コントローラーのトリガーおよびボタンを参照する場合はすべて、Xbox 360 の名前を使用する必要があります。詳細については、「Xbox 360 Controller for Windows の用語」を参照してください。
ポーズ中、もしくはプレイヤーからの入力を必要としない状態ではコントローラーの振動をオフにする必要があります。
マウス/キーボードによる制御は、いかなるときでも完全に無効にすることはできません。最低でも、ゲーム メニューに戻るオプションが使用可能でなければなりません。
理由
この要件によって、ゲーマーは Xbox 360 コントローラーまたはキーボード/マウスの使用を、どちらの入力方法がより自然で直感的なインターフェイスであるかに応じて自由に選択することができます。
Additional Information
この要件は、マウスとキーボードのみを使用するゲームには適用されません。
次のような広く使用されている標準的なコントローラー ボタンを使用するメニュー ナビゲーションを実装することをお勧めします。
- A ? 決定
- B ? キャンセル
- START ? 決定またはポーズ
- BACK ? キャンセル、1 つ前の画面に戻る、または 1 つ上のメニュー レベルに移動する
詳細については、XInput に関する DirectX SDK ドキュメントを参照してください。
XInput と DirectInput に関するトピックには、両方の API を同時に使用する場合の問題点が記載されています。
1.5 マルチ アスペクトおよびマルチ解像度のサポート
要件
ゲームでは、最低限、次に示す縦横比および関連する画面解像度をサポートする必要があります。
- 4:3 標準 (800x600 または 1024x768)
- 16:9 ワイドスクリーン (1280x720)
- 16:10 ワイドスクリーン (1152x720 または 1680x1050 または 800x480)
画面解像度の構成と検出については、ゲームは次のルールに準拠する必要があります。
- 表示デバイスのデスクトップの解像度が、サポートされる解像度である場合、ゲームでは既定でその解像度を使用します。ゲームで別の既定の解像度を選択する場合、デスクトップの縦横比を検索条件として使用する必要があります。
- 表示設定が変更された場合、ゲームでは、新しい表示設定を使用してよいかどうかをユーザーに確認する必要があります。ユーザーが 15 秒以内に承認しない場合は、表示を前の設定に戻す必要があります。
- ゲームでは、ワイドスクリーンの縦横比をサポートするために、ピクセルを引き伸ばしたり、4:3 のレンダリング ウィンドウを中央に表示したりしてはいけません。ただし、レターボックス化することはできます。
理由
Windows Vista の 3D デスクトップでは、次の要因によって、特定の縦横比または解像度を前提とすることはできません。
- 高精細ディスプレイのサポート
- ワイドスクリーン モニターの市場シェアの拡大
- Windows Media Center の HDTV 展開
- アクセシビリティ要件
Additional Information
ゲームでは、既定でディスプレイのネイティブのアスペクト比を使用することが理想です。しかし、この情報を確実に取得することは難しい場合があるため、より一般的な解決策として、デスクトップがネイティブの縦横比で表示されていると仮定できます。デスクトップの解像度を取得するには、ENUM_REGISTRY_SETTINGS を指定して EnumDisplaySettings を呼び出します。
詳細については、DirectX SDK の記事「Windows ゲーム開発者を対象にした 10 フィート エクスペリエンスの概要」のアスペクト比およびワイドスクリーンについての説明を参照してください。
1.6 Windows Media Center からの起動のサポート
要件
Windows Vista Media Center インターフェイスにゲームが表示されている必要があります。また、Media Center からゲームを正常に起動できる必要があります。Media Center から起動されるゲームでは、最適化された 10 フィート インターフェイスを提供する必要はありません。
ディスプレイ デバイスが適切でない場合にゲームを起動しないようにすることができますが、適切なメッセージをユーザーに表示する必要があります (たとえば "このディスプレイはこのゲームをプレイするために必要な最小解像度をサポートしていません" など)。
Media Center インターフェイスからゲームが起動される場合は、ゲームが終了した時点で Media Center に戻る必要があります。
理由
Windows XP Media Center Edition は、部屋のどこからでもコンピューターを使用できるようにする Media Center ユーザー インターフェイス (UI) を通じて、これまでにないエキサイティングな体験をユーザーに提供します。Windows XP Media Center Edition を実行しているコンピューターは、これまでのように Windows オペレーティング システムの能力を利用する一方で、ソファに座ったまま操作できることから、ゲームのプラットフォームとして非常に強力です。Windows Vista Home Premium エディションと Windows Vista Ultimate エディションには Media Center が搭載されています。このため、Windows を使用する多くのユーザーが、Media Center をサポートする Windows バージョンを購入するか、そのバージョンにアップグレードすることになります。
Additional Information
Media Center をサポートする方法の詳細については、DirectX SDK の記事「Windows ゲーム開発者を対象にした 10 フィート エクスペリエンスの概要」、MCELauncher サンプル、および MediaCenterGame サンプルを参照してください。
GameUxInstallHelper サンプルでは、ゲーム エクスプローラーで提供されているメタ データと同じデータを使用して、必要な登録が処理されています。セクション 1.1 を参照してください。
1.7 Direct3D のサポート
要件
ゲームで Direct3D を使用する場合は、Direct3D 9 以上のバージョンをサポートする必要があり、Direct3D を既定の設定とする必要があります。
理由
Windows Vista のコア グラフィックス アーキテクチャは Direct3D を中心として設計されています。Direct3D 8 以前のバージョンは、レガシ インターフェイスの再マッピングによってサポートされます。
セキュリティおよび互換性
セキュリティおよび互換性の要件の概要
お客様に対する利点
ここに示す要件は、ゲーム全体のセキュリティを向上させると共に、ゲームが Windows Vista 上でさまざまなアーキテクチャ、さまざまな構成、およびさまざまなモードで動作できるようにするためのものです。
ここでは、次の要件について説明します。
- 2.1 ユーザー アカウント制御のガイドラインの遵守
- 2.2 x64 バージョンの Windows Vista のサポート
- 2.3 ファイルの署名
- 2.4 ドライバーの署名
- 2.5 適切なバージョン チェックの実行
- 2.6 同時ユーザー セッションのサポート
- 2.7 長い名前のサポート
2.1 ユーザー アカウント制御のガイドラインの遵守
要件
すべての実行可能ファイル (つまり、拡張子が .exe のすべてのファイル) に、次のタグを含めることによって、実行レベルを定義するマニフェストが埋め込まれている必要があります。
<requestedExecutionLevel>
要件 1.2 に従って、ゲームのメインの自動実行の実行可能ファイルでは、標準ユーザー コンテキストをサポートするために実行レベルを asInvoker とする必要があります。
ファイル エクスプローラーにファイルの関連付けが登録されているユーザー データ ファイルは、CSIDL_PERSONAL (ドキュメントまたはマイ ドキュメントとも呼ばれます) によって指定されたフォルダーのサブフォルダーに格納する必要があります。それ以外のユーザー データ ファイルはすべて、CSIDL_LOCAL_APPDATA または CSIDL_COMMON_APPDATA によって指定されたフォルダーのサブフォルダーに格納する必要があります。(これらのディレクトリは、既定で個々のユーザーおよびすべてのユーザーに対して表示されません)。
理由
必要なアクセス許可がある場合にのみアプリケーションが動作すると、ユーザーの Windows 体験のセキュリティが向上します。
Additional Information
アプリケーションの少数の機能のみに管理者権限が必要である場合も (ファイアウォールを設定する必要があるアプリケーションなど)、アプリケーションのメイン プロセスは標準ユーザーの権限を使用して動作する必要があります。管理者権限を必要とする機能は、インストーラーや構成ユーティリティなど、別個のプロセスに移動する必要があります。
管理者権限が必要でない場合は、埋め込みマニフェスト XML に以下が含まれている必要があります。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
<ms_asmv2:security>
<ms_asmv2:requestedPrivileges>
<ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
</ms_asmv2:requestedPrivileges>
</ms_asmv2:security>
</ms_asmv2:trustInfo>
</assembly>
管理者権限が必要な場合は、埋め込みマニフェスト XML に以下が含まれている必要があります。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
<ms_asmv2:security>
<ms_asmv2:requestedPrivileges>
<ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</ms_asmv2:requestedPrivileges>
</ms_asmv2:security>
</ms_asmv2:trustInfo>
</assembly>
インストール、修正プログラムの適用、および削除に関する特殊な場合の詳細については、要件 3.1 を参照してください。
ダイナミック リンク ライブラリ (DLL) には、このようなマニフェストは必要ありません。
ユーザー アカウント制御の詳細については、「ゲーム開発者向けのユーザー アカウント制御」を参照してください。
2.2 x64 バージョンの Windows Vista のサポート
要件
64 ビット バージョンの Windows との互換性を維持するために、ゲームは次の要件を満たす必要があります。
- タイトルおよびタイトルのインストーラーには 16 ビット コードを含めず、また、それらが 16 ビット コンポーネントに依存しないようにする必要があります。
- ゲームの動作がカーネルモード ドライバーに依存する場合は、これらのドライバーの x64 バージョンを用意する必要があります。ゲームのセットアップで、64 ビット バージョンの Windows の適切なドライバーおよびコンポーネントを検出してインストールする必要があります。
理由
多くの Windows Vista ユーザーは、製品のライフサイクルを通じて 64 ビット バージョンのオペレーティング システムを実行するため、アプリケーションがそのオペレーティング システムと互換性を持つことは不可欠です。
Additional Information
Windows on Windows 64 (WOW64) を使用すると、64 ビット バージョンの Windows で 32 ビット コードを実行できるため、x64 バージョンの Windows 上でアプリケーションが必ずしもネイティブの 64 ビット コードである必要はありません。16 ビット コードは、64 ビット バージョンの Windows では動作しません。
Windows XP Professional x64 Edition との互換性を維持することは必須ではありませんが、強くお勧めします。
詳細については、「ゲーム開発者のための 64 ビット プログラミング」を参照してください。
2.3 ファイルの署名
要件
すべての実行可能コード ファイル (通常は拡張子が .exe または .dll のファイル) は、公的に有効な Authenticode 証明書によって署名されている必要があります。
ゲームで Windows インストーラーを使用する場合は、インストーラー パッケージ ファイル (.msi ファイル) が署名されている必要があります。
理由
ファイルの署名により、ユーザーはアプリケーションを信頼するかどうかを判断しやすくなるほか、ファイルが改ざんされていないことを確認することができます。また、ロックされた環境でアプリケーションが適切に動作できます。
Additional Information
詳細については、「ゲーム開発者のための Authenticode 署名」を参照してください。
ゲームで Windows インストーラーを使用する場合は、MsiPatchCertificate テーブルを含めて、UAC/LUA による修正プログラムの適用を有効にすることをお勧めします。詳細については、「User Account Control (UAC) Patching (ユーザー アカウント制御 (UAC) での修正プログラム適用)」を参照してください。
キャビネット (.cab) ファイルについては、ファイルが比較的小さい (100 MB 未満) 場合を除き、署名しないことをお勧めします。
2.4 ドライバーの署名
要件
ゲームによってインストールされるカーネルモード ドライバーは、いずれも公的に有効な Authenticode 証明書によって署名されている必要があります。
ゲームによってインストールされるすべてのカーネルモード ハードウェア デバイス ドライバーには、Windows Hardware Quality Labs (WHQL) または Driver Reliability Signature (DRS) プログラムから取得可能な Microsoft 署名が必要です。
理由
品質の悪いドライバーやマルウェアとして作られたドライバーは、システムの安定性およびセキュリティに重大な影響を与える可能性があります。64 ビット バージョンの Windows Vista では、署名無しのドライバーは読み込まれません。このポリシーは、32 ビット バージョンの Windows Vista でも有効にすることができます。
Additional Information
要件 2.2 に従って、32 ビット ネイティブと 64 ビット ネイティブ両方のバージョンのカーネルモード ドライバーすべてが必要です。
Microsoft のドライバー署名プログラムの詳細については、Windows Hardware Developer ポータルを参照してください。
2.5 適切なバージョン チェックの実行
要件
使用許諾契約書で将来のオペレーティング システムでの使用を禁止している場合を除き、Windows のバージョン番号の変更によって示される将来のオペレーティング システムでもゲームが引き続き動作する必要があります。新しいバージョンで動作しない場合は、適切なメッセージをユーザーに表示して、正常に終了する必要があります。
Windows のバージョン チェックを実行する場合は、バージョン チェック API (GetVersionEx) を使用してオペレーティング システムのバージョンをチェックする必要があります。バージョンを確認するためにレジストリ キーを読み取ることはできません。
ゲームには、DirectX ランタイムの明示的なバージョン チェックを含めてはいけません。DirectX ランタイムのセットアップ (DirectSetup) を起動するインストールに、このようなバージョン チェックを含めてはいけません。
理由
Windows ユーザーがオペレーティング システムをアップグレードしたときに、単に Windows のバージョン番号が増えたからという理由で、現在のゲームをプレイできなくなることがあってはいけません。
DirectX ランタイムのバージョン チェックの比較ロジックは脆弱なため、異なるバージョンの Windows で実行された場合、インストールに失敗することが多々あります。DirectX のバージョン番号は、コア オペレーティング システム コンポーネントのみに適用されます。多くのゲームで使用されているサイドバイサイド DirectX SDK コンポーネントには適用されません。
Additional Information
DirectX のランタイム再配布パッケージ (DirectX Setup) を適切に使用すると、インストール中にそれが常に起動されます (できるだけ、サイレント モードを使用してください)。これによって、マイクロソフトから提供されたコードで、必要なバージョンの更新を実行することができます。また、D3DX、XACT、MDX、XInput など、オプションのサイドバイサイド DirectX SDK コンポーネントをインストールすることもできます。
DirectX ランタイムを展開する際のベスト プラクティスについては、「ゲーム開発者のための DirectX のインストール」を参照してください。
2.6 同時ユーザー セッションのサポート
要件
3D グラフィックスに依存するゲームの場合、リモート デスクトップ接続で動作することは必須ではありませんが、ゲームが異常終了したときにユーザーに警告を表示する必要があります。
ゲームでは、次のルールに準拠して、Windows の標準的なマルチタスク シナリオをサポートする必要があります。
- ゲームで同時ユーザー セッションの使用をブロックしてはいけません。
- ゲームが既に別のセッションで実行中の場合、新しいユーザー セッションでゲームが実行されなければなりません。
- 1 つのユーザー セッションにおけるゲームのサウンドが、別のユーザーが別のセッションでアクティブであるときに聞こえてはいけません。
- ゲームで高速ユーザー切り替え機能をサポートする必要があります。
- ゲームで標準のタスク切り替えを無効にしようとしてはいけません。ゲームで Alt + Tab のキーボード ショートカットを無効にしてはいけません。アクセシビリティ機能のキーボード ショートカットは無効にすることができます。詳細については、「ゲームでのショートカット キーの無効化」を参照してください。
理由
Windows ユーザーは、競合や中断なしに複数の同時セッションを実行できる必要があります。これは、Windows コンピューターを家族やルームメイトなどと共有している場合によく見られる状況です。
Additional Information
ゲームがリモート セッションで起動されているかどうかをテストするには、GetSystemMetrics(SM_REMOTESESSION) を呼び出します。結果がゼロ以外の値であれば、セッションはリモートです。
詳細については、ユーザーの簡易切り替えに関する文書を参照してください。保護者による制限の時間の制限が有効な場合、ユーザーの時間が終了すると、高速ユーザー切り替えが行われます。詳細については、要件 1.2 を参照してください。
2.7 長い名前のサポート
要件
ゲームでファイルの保存をサポートしている場合は、長い名前およびパスを使用するファイルを保存できるようにする必要があります。ファイル名またはパスの作成に使用されるユーザー入力フィールドに入力された特殊なファイル システム文字 (\、/、:、*、?、"、<、> など) がゲームで適切に処理されなければなりません。
ユーザーが長いユーザー名を使用した場合でも、ゲームは正しく動作する必要があります。
理由
プレイヤーは、オペレーティング システムでサポートされている深いパス上の長い名前を使用することに慣れています。
Additional Information
長い名前とは、Windows SDK で定義されている最大値を使用する名前として定義されます。
インストール
インストールの要件の概要
お客様に対する利点
お客様は、正式なシステム コンポーネント配布方法が使用されている場合、インストールするアプリケーションが、オペレーティング システムや他のアプリケーションに悪い影響を与えることなく Windows にインストールされることを確信できます。インストール手順の簡略化によって、よりアクセスしやすく、問題のない out-of-box experience がゲームにもたらされます。
ここでは、次の要件について説明します。
- 3.1 簡易インストールのサポート
- 3.2 インストール時のユーザー アカウント制御のサポート
- 3.3 正しいフォルダーへのインストール
- 3.4 Windows リソースの適切なインストール
- 3.5 インストール中の再起動の回避
- 3.6 正しいファイル バージョン管理の使用
- 3.7 自動実行のサポート
3.1 簡易インストールのサポート
要件
ゲームでは、次の要件を実装して、セットアップのユーザー インターフェイスで簡略化したパスを提供する必要があります。
- EULA のダイアログを表示するのは 1 回だけにします。
- 既定のインストール パスでは、インストールに関する選択事項 (インストール先フォルダー、コンポーネントの選択など) をすべて省略して既定の選択内容を使用し、インストールが成功した場合には追加のダイアログを表示せずにゲームまたはラウンチャーが起動されるようにする必要があります。必要に応じて、高度な構成オプションに対応したカスタム インストール オプションを用意することができます。
- 正しいマイクロソフトの再配布パッケージを使用して、必要なすべてのオペレーティング システム コンポーネント (DirectX ランタイムや Visual C ランタイムなど) をインストールします。メッセージを表示したり、コンポーネントのバージョン チェックで中断されたりすることなく、インストールがサイレントに実行される必要があります。
- ゲーム アプリケーションと生成された作業ファイルの両方について、コントロール パネルの [プログラムと機能] を使用して削除する機能を提供します。ユーザーによって作成された全てのデータ ファイルを削除するオプションを用意することをお勧めします。削除プロセスによって、インストールされたすべてのファイルの削除と、すべての設定 (ファイアウォールの例外リストのエントリやレジストリ キーなど) のクリアが確実に行われるようにする必要があります。再配布されたオペレーティング システム コンポーネントを削除してはいけません。
- ゲームで Windows ファイアウォールに例外を追加する必要がある場合、セットアップ プロセスでこの変更が必要であることをユーザーに通知するメッセージを表示することができます。このメッセージは、インストールが開始される前に表示されなければなりません。
インストールおよび削除には管理者権限を要求することができます。修正プログラムの適用には、更新の頻度に応じて、管理者の資格情報を要求することができます。「2.1 ユーザー アカウント制御のガイドラインの遵守」の要件に従って、通常のゲーム プレイに管理者権限を要求してはいけません。
理由
簡易インストールは、Windows を中心としたゲーム開発の理念の 1 つであり、Windows オペレーティング システムを実行しているコンピューターにゲームをインストールする際の、しばしば単調でわかりにくいプロセスを簡単で効率的なものにすることを目的としています。簡易インストールを実現するには、Windows コンピューターにゲームをインストールするときの不要な複雑さや既知のリスクを減らす、一連のテクノロジおよびベスト プラクティスを活用します。
主要な目標は次のとおりです。
- ゲームが起動するまでの時間とプレイを開始できるまでの時間を短縮する。
- ゲームのインストール手順を簡略化するために、ダイアログ ボックスや選択肢の数をごくわずかにするか、またはまったくなくす。
これまでのインストールの中には、アプリケーションが正常にインストールされたように見えても、インストールが機能しない状態になるようなダイアログが表示されるものがあります。たとえば、ユーザーがゲームで EULA に同意するよう求められます。EULA に同意すると、ゲームがインストールされ、続いて DirectX の EULA が表示されます。ユーザーはこの EULA を拒否することができ、その場合、DirectX ランタイムのインストールがスキップされます。このシナリオでは、コンポーネントが不足しているためにゲームを正常に実行できない可能性があります。
Additional Information
ゲームのインストール、従来とは異なるゲームのインストール テクニック、UAC 対応の修正プログラム適用ソリューション、および頻繁な修正プログラム適用の処理の詳細については、次の内容に関する DirectX SDK の記事を参照してください。
- ゲームのインストールの単純化
- ゲームのオン デマンド インストール
- Windows XP および Windows Vista でのゲーム ソフトウェアの修正プログラムの適用
- 大規模なマルチプレイヤー オンライン ゲームのインストール実践ガイド
生成されたユーザー固有のデータ ファイルの削除は、現在のユーザーおよび共有されている共通のユーザーの場所に対してのみ実行する必要があります。削除に管理者の資格情報が必要な場合でも、システムをスキャンして、他のユーザーのユーザー固有のファイルを強引に削除することはできません。
3.2 インストール時のユーザー アカウント制御のサポート
要件
ゲームのインストーラーは、ユーザーと同じコンテキストで動作していることを前提としてはいけません。管理者の資格情報への移行によるシングル ユーザー システムの場合であっても、ユーザー固有の場所はインストーラーおよびプレイヤーとは異なります。そのため、ゲームが初めて起動されたときには、インストール プロセスとは別にユーザー固有のタスクを実行する必要があります。
ユーザーがホストになる、あるいはマルチプレイヤー ゲームに参加する場合に、Windows ファイアウォールの例外ダイアログ ボックスが表示されてはいけません。インストール時に、必要なすべての設定が行われる必要があります。セットアップの一環としてこの処理が行われることを、セットアップの指示によってユーザーに知らせる必要があります。
ゲームのインストーラーには、「2.1 ユーザー アカウント制御のガイドラインの遵守」の要件に従って、必要な実行レベルを指定した埋め込みマニフェストを用意する必要があります。
インストールの完了後にゲームがインストーラーによって起動される場合は、元のユーザーのコンテキストで起動される必要があります。
理由
Windows Vista における Windows オペレーティング システムの最も大きな変更の 1 つは、ユーザー アカウント制御の追加です。これにより、既定では下位の権限でアプリケーションが実行されます。そのため、インストーラーは、それに従って権限レベルを管理する必要があります。
Additional Information
Windows ファイアウォールの構成の詳細については、DirectX SDK の「ゲーム開発者向け Windows ファイアウォール」および FirewallInstallHelper サンプルを参照してください。
インストールが標準ユーザーによって開始され、さらにセットアップ プロセスで管理者権限 (つまり、管理者の資格情報) が要求された場合、インストール プロセスが終了したときのゲームの標準的な起動は、この要件の最後の部分に違反します。この場合、管理者権限が継承され、セキュリティ リスクとなる可能性があります。そのため、代わりに、インストーラーの正常な起動から戻った後、セットアップ ブートストラップがゲームを起動する必要があります。詳細については、MSDN マガジンの記事「アプリケーションで Windows Vista のユーザー アカウント制御を有効に活用する」を参照してください。
3.3 正しいフォルダーへのインストール
要件
すべてのユーザーに対してインストールされるゲームは、既定で Program Files フォルダーにインストールされる必要があります。ユーザー データは、ゲームのインストール中ではなく、最初に起動したときに書き込まれなければなりません。
理由
ユーザーは、必要な場所にアプリケーションを柔軟にインストールできなければなりません。また、ファイルの既定の場所に関しては矛盾がなく、かつ安全でなければなりません。
Additional Information
ゲームでは、さまざまな既知のフォルダーの場所 (CSIDL_LOCAL_APPDATA や CSIDL_COMMON_APPDATA によって指定される場所など) を利用して大量の重要なゲーム データや関連する実行可能ファイルを保存することにより、高度なオンデマンド インストールおよび修正プログラム適用のシナリオを実現することができます。
インストールでは、すべてのユーザーに対するインストール プロセスで別のユーザー アカウントへの移行を要求することがあるため、インストール時にデータを格納する正しいユーザーの場所というものはありません。また、ファイルの暗号化が有効になっている場合、暗号化されたファイルは、それを作成したユーザー アカウントによってのみアクセスできます。
3.4 Windows リソースの適切なインストール
要件
アプリケーションは、Windows リソース保護 (WRP) によって保護されたファイルまたはレジストリ キーをインストールすることはできません。アプリケーションがシステム コンポーネントの新しいバージョンを必要とする場合は、マイクロソフトのサービス パックを使用するか、またはシステム コンポーネントを含む、マイクロソフトによって承認されたインストール パッケージを使用して、コンポーネントを更新する必要があります。システム コンポーネントを再パッケージしてはなりません。
理由
Windows リソース保護 (WRP) は、マイクロソフトによって承認されたインストールまたは更新メカニズムによってのみ、保護されたシステム リソースが更新されるように設計されています。WRP は、インストールの結果を予測可能にすることで、システムの信頼性を向上させます。
Additional Information
WRP は、Windows フォルダーにインストールされたシステム コンポーネントの大部分を保護する、Windows ファイル保護の後継機能です。WRP は、COM オブジェクトの作成に関する設定を格納するほとんどのレジストリ キーを保護します。また、オペレーティング システムで排他的に使用できるように、特定のフォルダーを予約します。保護されたリソースにアクセスしようとすると、通常はアクセス拒否エラーが発生します。
DirectX ランタイムをゲームで展開する際のベスト プラクティスの詳細については、DirectX SDK の「ゲーム開発者のための DirectX のインストール」を参照してください。
3.5 インストール中の再起動の回避
要件
ゲーム インストーラーでは、戻り結果またはマイクロソフトのドキュメントによって再起動が指示されている場合を除き、再配布パッケージ内の Windows コンポーネントのインストール時に再起動が必要であることを前提としてはいけません。
ゲーム インストーラーで常に再起動を強制する場合は、マイクロソフトによる承認が必要です。
Windows インストーラー パッケージに含まれる [使用中のファイル] ダイアログ ボックスには、セットアップの完了後、アプリケーションを自動的に終了して、再起動するオプションを用意する必要があります。
理由
インストール後にシステムを再起動することは、ユーザーにとって不便な中断であり、通常は不要です。
Additional Information
詳細については、「Using Windows Installer with Restart Manager (Windows インストーラーでの再起動マネージャーの使用)」を参照してください。
3.6 正しいファイル バージョン管理の使用
要件
ゲームのインストール プログラムでは、最新バージョンのファイルがインストールされることを適切に確認する必要があります。このゲームで生成する以外のファイル、およびこのゲームで生成される以外のアプリケーションで共有されるファイルが、ゲームのインストールによって古いバージョンに戻ることのないようにする必要があります。
理由
共有コンポーネントやシステム コンポーネントは、セキュリティ修正プログラムや機能の拡張に伴って更新されることがよくあります。更新されたコンポーネントの古いバージョンを含むインストールによって、既に適用されている更新プログラムや修正プログラムが失われないようにする必要があります。
3.7 自動実行のサポート
要件
CD、DVD、または自動実行をサポートするその他のリムーバブル メディアで配布されるゲームでは、ディスクを初めて挿入したときに、アプリケーションが自動的に実行するか、ゲームのインストールをユーザーに確認する必要があります。ただし、ユーザーが自動実行機能を無効にしている場合は除きます。
アプリケーションのインストールが正常に完了した後は、ドライブにディスクを挿入し直してもインストールが再度自動的に開始されることがないようにする必要があります。インストールの選択肢を更新または変更するかどうかをユーザーに確認することは許容されます。
自動実行アプリケーションでは、上位の権限を要求してはいけません (つまり、セットアップ プログラムまたは管理者権限を必要とする別のユーティリティを起動できても、要件 2.1 に従って、マニフェストに asInvoker を含める必要があります)。上位の権限への移行は、ゲームがインストールされない場合、またはユーザーが明確にそれを選択した場合にのみ行う必要があります。
理由
自動実行によって、通常、ゲームをプレイするためにドライブにディスクを挿入しておく必要があるゲームなど、メディアで配布されるアプリケーションの使用手順が簡略化されます。
Additional Information
CD または DVD からインストールを起動するために、ユーザーにファイル エクスプローラーでの操作を要求することは許可されません。
複数のディスクで配布されるゲームの場合、2 枚目以降のディスクでは、自動実行機能を使用するか、またはユーザーにキーを押す等々の操作を求めることなくインストールを続行することが理想です。
自動実行プログラムを作成する際には必ず、必要なコンポーネントすべてが Windows の新規インストールに存在するようにしてください。一般的なアプリケーションは、セットアップによってインストールされるテクノロジに依存しますが、自動実行自体はこのようなセットアップが行われる前に実行されます。よく見られる例として、Visual C ランタイム DLL が Windows セットアップに含まれていなかったことによる自動実行プログラムの失敗があります。したがって、自動実行プログラムでは、アプリケーションのローカル CRT 展開を使用するか、静的に CRT をリンクする必要があります。
Windows Vista より前のバージョンの Windows での使用を目的として作成された自動実行プログラムでは、.NET ランタイムを使用してはいけません。Windows XP 以前のバージョンの Windows には、このテクノロジが含まれていないためです。Windows Server 2003 および Windows Vista で初めて、オペレーティング システムの一部として .NET ランタイムが含まれました。
同様の理由から、自動実行プログラムで、D3DX9、D3DX10、XAudio2、X3DAudio、XACT、XINPUT、MDX 1.1 など、オプションの DirectX SDK サイドバイサイド コンポーネントの存在を要求することはできません。
信頼性
信頼性の要件の概要
お客様に対する利点
ここに示す要件は、クラッシュ、ハング、および再起動の回数を最小限に抑えることによって、アプリケーションの信頼性を向上させるためのものです。信頼性の要件は、ソフトウェアの予測可能性、保守性、復元性、および復帰可能性を高めるのに役立ちます。
ここでは、次の要件について説明します。
- 4.1 不要な再起動の回避
- 4.2 Application Verifier のエラーの回避
- 4.3 Windows エラー報告およびファイル バージョン情報のサポート
4.1 不要な再起動の回避
要件
アプリケーションのインストーラーはすべて、再起動マネージャー API を利用して、システムの再起動を回避する必要があります (要件 3.5 を参照)。
ゲームでシャットダウンをブロックしてはいけません。
アプリケーションはすべて、次のシャットダウン メッセージを監視し、それに応答することによって、再起動マネージャーに応答する必要があります。
- WM_QUERYENDSESSION with LPARAM = ENDSESSION_CLOSEAPP (0x1)
GUI アプリケーションは、再起動の準備としてこのメッセージに直ちに応答 (TRUE) する必要があります。 - WM_ENDSESSION with LPARAM = ENDSESSION_CLOSEAPP (0x1)
アプリケーションは 5 秒以内に 0 の値を返し、終了する必要があります。 - Ctrl + C
このメッセージを受け取ったコンソール アプリケーションは、直ちに終了する必要があります。
理由
システムの再起動は大きな中断です。ユーザーの印象が悪くなるため、再起動を最小限に抑える必要があります。重要なシステムの更新など、一部の操作では再起動を要求してもかまいません。シャットダウン メッセージを監視することで、ゲームおよびその他のアプリケーションは再起動マネージャーからの要求にすばやく対応することができます。これによって、有効な再起動要求に対する応答が不要に遅れるのを防ぐことができます。
Additional Information
ゲームのインストーラーで、Windows インストーラー テクノロジ (MSI) をカスタムの動作なしで使用している場合は、この機能が自動的に提供されます。マイクロソフトの再配布パッケージも再起動マネージャーをサポートしています。
再起動マネージャーの詳細については、MSDN の記事「About Restart Manager (再起動マネージャーについて)」を参照してください。
4.2 Application Verifier のエラーの回避
要件
Microsoft Application Verifier (AppVerifier) バージョン 3.3 以降での実行時に、次のテストでエラーが生成されないようにする必要があります。
- 基本 : ハンドル、ヒープ、ロック、メモリー、TLS
- その他 : DangerousAPIs、DirtyStacks
理由
AppVerifier では、Windows アプリケーションでクラッシュやハングの原因となる多くの既知の問題、および既知のセキュリティの脆弱性をテストします。
Additional Information
Application Verifier は Microsoft TechNet からダウンロードできます。概要と一般的な手順については、MSDN の記事「ソフトウェア開発ライフサイクル内で Application Verifier を使用する」を参照してください。
この要件は、ネイティブな相互運用がない純粋なマネージ アプリケーションには適用されません。
これらのテストはリリース ビルドで実行する必要があります。デバッグ ビルドでは、正しくないエラーが生成されることがあります。海賊版対策および不正行為対策テクノロジの中には、AppVerifier の実行を妨げる可能性があるものがあります。そのため、これらのテストは、海賊版対策および不正行為対策テクノロジを有効にせずに実行する必要があります。
基本 : ヒープ テストの Full プロパティを FALSE に設定しなければならないことがあります。これは、完全 PageHeap によって、実行中のアプリケーションのメモリーの圧迫が大幅に増大するためです。部分 PageHeapのみを使用した場合も、エラーは検出されますが、エラーを追跡するのがより難しくなる可能性があります。
2.1 および 3.2 のユーザー アカウント制御に関する要件を満たすために Application Verifier で UAC/LUA 関連のテストを使用する場合は、Standard User Analyzer を使用して結果を検討する必要があります。
Visual Studio 2005 Team System には、デバッグ環境に統合された AppVerifier 機能のサブセットが含まれています。この機能は、基本 : ヒープ、ハンドル、およびロックに関する問題の追跡と解決に役立つ場合があります。
4.3 Windows エラー報告およびファイル バージョン情報のサポート
要件
Windows エラー報告のサポートを実現するには、ゲームで次の要件を満たす必要があります。
- ゲームでは、既知の例外または予期される例外のみを処理する必要があります。Windows エラー報告を無効にしてはいけません。ゲームでアクセス違反などのエラーを表示する場合は、Windows エラー報告でクラッシュ時のレポートができるようにする必要があります。
- すべての実行可能ファイル (.exe ファイル、DLL など) に、正確な製品名、会社名、およびファイル バージョンが含まれている必要があります。
- ゲームが正常に終了したときに不明な例外が発生しないようにする必要があります。
理由
Windows エラー報告 API は、アプリケーションで広く見られるクラッシュやハングを検出するためにマイクロソフトに重要なフィードバックを提供します。これによって、マイクロソフトとそのパートナーは、すぐにアプリケーションの障害につながるようなシステムやドライバーの問題を迅速に検出して解決できます。
Additional Information
ゲームには、独自のサポートおよび報告機能を実現するために、カスタムの未処理例外ハンドラーを含めることができますが、どのエラーも ReportFault API に渡す必要があります。
Windows のデスクトップ UI でファイルのプロパティを表示し、[バージョン情報](Version) プロパティ ページを確認することにより、適切なファイル バージョン情報を確認できます。
Windows エラー報告 API、およびこのサービスの使用時に生成されるクラッシュ ダンプを分析する方法の詳細については、DirectX SDK の「クラッシュ ダンプの分析」を参照してください。
Xbox 360 Controller for Windows の用語
A | A ボタン。 |
B | B ボタン。 |
BACK | BACK ボタン。 |
(右/左) バンパー | コントローラーの右上隅および左上隅にあるボタン。ショルダ ボタンと同義です。 |
方向パッド | コントローラーの方向パッド。 |
D パッド | 方向パッドの有効な省略形。 |
DP | 方向パッドの省略形およびコントローラー ラベル。 |
RB、LB | 右/左バンパーの省略形およびコントローラー ラベル。 |
RS、LS | 右/左スティックの省略形およびコントローラー ラベル。 |
RT、LT | 右/左トリガーの省略形およびコントローラー ラベル。 |
START | START ボタン。 |
(右/左) スティック | コントローラーのスティック。以前はサムスティックと呼ばれていました。 |
(右/左) スティック ボタン | コントローラーのスティック ボタン。以前はサムスティック ボタンと呼ばれていました。 |
(右/左) トリガー | コントローラーのトリガー。 |
バイブレーション | コントローラーのモーターによって生成されるゲームプレイ フィードバック。振動は使用しないでください。 |
X | X ボタン。 |
Xbox 360 Controller for Windows | Windows デバイス ドライバー ディスクを含む、PC ハードウェア SKU として販売される Xbox 360 のゲームパッド。 |
Xbox360 Wireless Controller for Windows | Windows デバイス ドライバー ディスクを含む、PC ハードウェア SKU として販売される Xbox 360 のワイヤレス ゲームパッド。 |
ゲーム ミドルウェア製品のガイドライン
はじめに
ゲームが Games for Windows プログラムの認定を受けるには、一連の技術要件を満たす必要があります。タイトルに含まれるサードパーティ製のコンポーネント (.exe ファイル、DLL、ドライバーなど) もすべて、ゲームが認定を受けるには、これらの要件を満たす必要があります。ここでは、ゲームが準拠テストに合格するためにサードパーティ製のコンポーネントも満たす必要がある最も一般的な要件について説明します。インストーラーおよびゲーム エンジン/プロダクション パッケージ全体で、Games for Windows の技術要件ドキュメント全体を検討する必要があります。これは、Games for Windows の技術要件の多くがこれらのツールの影響を受けるためです。
その他の推奨事項
Games for Windows の要件に準拠したタイトルの作成をコンポーネントでサポートする以外にも、Windows ゲームのライブラリまたはサポート ユーティリティを設計および展開する際に注意する必要がある考慮事項がいくつかあります。
- 64 ビット ネイティブの x64 アプリケーションに取り組んでいる開発者をサポートするには、32 ビット ネイティブと 64 ビット ネイティブ両方のバージョンのライブラリを提供します。2.2 に従って、32 ビット バージョンは 64 ビット互換でなければなりません。32 ビット アプリケーションのライブラリでは、LARGEADDRESSAWARE x86 アプリケーション内での使用をサポートするために、32 ビット アドレスの上位ビットが使用されないことを前提としてはいけません。
- スタティック リンク ライブラリを使用する場合は、DLL とは異なり、ライブラリの標準リリース バージョンに加えて、リンク時コード生成 (LTCG) リリース バージョンを提供します。LTCG の生成に使用する正確なコンパイラ バージョンを記載する必要があります。サポートされている各コンパイラ リリース (VS 2005、VS 2005 SP1 など) について固有の LTCG バージョンを生成しなければならないことがあります。
- ネイティブ コード (C/C++) のヘッダーを提供する場合は、Standard Annotation Language (SAL) 属性構文を使用して、パブリック API ルーチンを装飾します。これによって、ライブラリのユーザーはスタティック コード分析 (/analyze) を最大限に活用することができます。スタティック コード分析は、Visual Studio Team System 2005 および一般に利用可能な Windows SDK コンパイラ ツールに含まれています。
- 製品でユーザーのプロセス内にスレッドを作成する場合は、デバッグ ツールが実行中のスレッドに正しく注釈を付けられるように各スレッドの名前を設定してください。
- ゲームのメイン ループ内で呼び出されるルーチンを作成する場合は、PIX for Windows を使用してボトルネックを容易に特定できるように、D3DX ルーチン D3DPERF_BeginEvent/EndEvent および D3DPERF_SetMarker を使用して上位レベルの処理に注釈を付けます。
- ネットワーク ライブラリについては、IP に依存しない 実装を提供し、Windows XP SP2、Windows Vista、および将来のバージョンの Windows で IPv6 と Teredo テクノロジをサポートするために、廃止された IPv4 専用のルーチンを使用しないようにします。
Games for Windows ショーケース
はじめに
Games for Windows ショーケースは、Windows PC で充実したゲーム体験を提供するだけにとどまりません。ショーケース機能をゲームに実装することで、最新の Windows プラットフォームでのユーザー体験をいっそう盛り上げることができます。
Games for Windows のタイトルは、このドキュメントに記載されているすべての技術要件を満たす必要がありますが、ショーケース機能は任意です。これらのタイトルでは、次のショーケースの一部または全部を実装することも、いずれも実装しないことも自由です。
- S.1 Direct3D 10 の活用
- S.2 x64 ネイティブの活用
- S.3 マルチコアの活用
S.1 Direct3D 10 の活用
要件
ゲームが Direct3D 10 レンダリング パイプラインを実装していて、プレイヤーに既存のグラフィックス API を使用した画像を超えた新しいグラフィックス体験を提供すること。ゲームが Direct3D 9 も実装している場合は、並列比較した場合に、コンテンツのクオリティ、ビジュアル、パフォーマンス、シーンの作りこみ、またはその他のグラフィックスの品質面において、目に見える向上が認められる必要があります。Direct3D 10 によって前世代のビデオ カードとは一線を画する体験をもたらすためには、既存のコンテンツを新しい Direct3D API へ単に移植するのではなく、強化された次世代コンテンツが必要です。
このショーケースを実装するタイトルは、Direct3D 9 レンダリング エンジンも自由に実装してかまいません。このような実装は、Direct3D 10 対応のハードウェアが搭載されていない Windows Vista マシンや、Windows XP のサポートに使用されます。これは、Games for Windows 技術要件1.7 に準拠します。
Direct3D 10 対応のデバイスが搭載された Windows Vista システムでは、ゲームが既定で Direct3D 10 を使用するように設定されなければなりません。
理由
Direct3D 10 は、この 10 年間の進歩に基づいて Direct3D グラフィック テクノロジを大幅に刷新したものです。この新しい API に根本的な改良を実装するため、パフォーマンスの向上のためのパイプラインの効率化と操作性の大幅な簡素化を目的として、コア アーキテクチャに徹底的な変更が加えられました。そのため、やむなく段階的な改良モデルを採用することは断念されました。既存の Direct3D 9 カードはどれも Direct3D 10 インターフェイスをサポートしていません。また、新しい API は Windows Display Driver Model (WDDM) という一新されたドライバー モデルと連動しており、古いバージョンの Windows では使用できません。
Direct3D 10 対応のハードウェアはパフォーマンスの高い優れた Direct3D 9 機能を備えており、既存のゲームをサポートするほか、新しい Windows Vista ユーザー インターフェイスでのゲーム以外のさまざまな用途に対応しています。新しいビデオ カード ハードウェアの高度な新機能を最大限に活用するため、また Windows Vista でのソフトウェア サポートに備えるため、ゲームが新しい Direct3D 10 API を通じてレンダリングを実装している必要があります。
Additional Information
新しい Direct3D 10 インターフェイスを使用するためにDirect3D 9 レンダリング エンジンから移行する処理は、明確に定義されています。移行に必要な作業として、プログラマブル シェーダーを優先して固定機能演算をすべて除去する、既存のすべてのシェーダーを新しいシェーダー モデル 4 にアップデートする、新しいビュー モデルをサポートするためにリソース管理インターフェイスを効果的に変更する、使用可能なフォーマットの新しいリストを使用するためにアセットをすべて変換する、などがあります。移行には、シェーダー定数だけでなく、レンダリング ステートの処理の大幅な変更も含まれます。この変換は Direct3D 10 ショーケースの実現には不可欠ですが、これを行ったことで新しい API を活用するというショーケース要件を満たしたことにはなりません。
新しい API とその関連するシェーダー モデル 4 HLSL プログラミング モデルは、コンテンツを強化するためのさまざまな機会を提供します。
- 新しいジオメトリ シェーダー ステージでは、エッジエンハンスメント、頂点デシメーション、リミテッド ジオメトリ マグニフィケーション、および GPU 内マテリアル セレクションを実行できます。
- ストリーム アウトを使用すると、コストの高い CPU ラウンドトリップ無しで、マルチパス テクニックを非常に効率的に実装できます。
- 信頼性の高い共通の計算モデルにより、シェーダー コードをパイプラインの上位または下位へ簡単に移動できるので、頂点単位、プリミティブ単位、またはピクセル単位レベルでの計算の効率が向上します。
- シェーダーからの統一されたリソースへのアクセスにより、GPU ベースのスキニング、アニメーション、パーティクル システム、および GPGPU スタイルの操作を効率的に実装できます。
Direct3D 10 では、Direct3D 9 において高い CPU コストを頼りに実装されていたテクニックを GPU に効率的に扱うことができるようになりました。そのため、CPU リソースに余裕ができ、その分をゲームの他の要求に回すことができます。Direct3D 10 API、Effects 10、シェーダー モデル 4 HLSL、およびサポート ツールは、 から入手できます。DirectX SDK の「Windows Vista のグラフィック API」も参照してください。
S.2 x64 ネイティブの活用
要件
ゲームに 64 ビット ネイティブの実行可能ファイルが含まれていて、x64 に対応したハードウェアで Windows x64 エディションが実行されている場合にプレイヤーに新しい体験を提供すること。32 ビット バージョンと並列比較した場合、コンテンツの作りこみ、全体的なロード時間の短縮、およびパフォーマンスにおいて、目に見える向上が認められる必要があります。
64 ビット バージョンの Windows では、インストール時に必ず、64 ビット ネイティブ バージョンのゲームをゲーム エクスプローラーの既定値として設定すると共に、Windows XP x64 Edition のショートカットおよび Windows Media Center の登録を設定する必要があります。デュアル インストールが必要な場合は、Windows Vista 上のゲーム エクスプローラーに、32 ビット バージョンを指す追加のプレイ タスクを指定できますが、既定は 64 ビット ネイティブ バージョンのままでなければなりません。
このショーケース要件を満たすには、ゲームで Windows Vista x64 をサポートする必要があります。Windows XP Professional x64 Edition のサポートもお勧めしますが、必須ではありません。
理由
x64 テクノロジはコンシューマー市場とサーバー市場のどちらにも 64 ビット アドレッシング機能をもたらすと共に、既存のアプリケーションでのフルスピードでの 32 ビット下位互換性も維持しています。x64 は、AMD (AMD64) と Intel (EMT64) に加えて、現行および次世代のすべてのプロセッサ (このテクノロジをサポートする一部のウルトラモバイル CPU を除く) のロードマップの中核です。
x64 テクノロジをサポートした最初のコンシューマー Windows OS は Windows XP Professional x64 Edition でした。Windows Vista では、64 ビット コンシューマー コンピューティングにおける OS の利用可能性が大幅に拡張されています。多くの新しいコンピューターでは 2 GB の RAM が標準となり、2 GB を超える物理 RAM をアドレス指定できない 32 ビット アプリケーションでは、もはやメモリー拡張によるメリットは得られません。
32 ビット ゲームの x64 との互換性は Games for Windows 技術要件 (2.2) ですが、この新しいテクノロジを最大限に活用するためには 64 ビット ネイティブの実装が必要となります。
Additional Information
64 ビット アドレッシングの一番の利点は、2 GB を超える物理メモリーおよび仮想メモリーに直接アクセスできることです。巨大な仮想メモリー アドレス空間では、32 ビット プログラミングにつきまとう仮想メモリー アドレス空間の消費問題を気にすることなく、メモリーマップ I/O を存分に利用できます。ゲームでこの新しいアドレス空間を活用すれば、ロード時間を大幅に短縮できるほか、場合によってはコンテンツのロードの中断を解消するといった利点を得ることができます。
既存の 32 ビット アプリケーションも、ビルド時に大きいサイズのアドレス ((/LARGEADDRESSAWARE)) リンカー オプションを指定して完全な 32 ビット データを持つアドレスを処理できるようにすることで、x64 エディションの利点を享受できます。32 ビット バージョンの Windows XP では、特殊なブート モードを使用することによって、このようなアプリケーションで最大 3 GB の RAM をアドレス指定できましたが、x64 エディションでは、大きいサイズのアドレスに対応した (Large Address Aware : LAA) アプリケーションで最大 4 GB の RAM にアクセスできます。32 ビット アプリケーションで LAA を使用することでこのショーケース要件を満たしたことにはなりませんが、このブリッジ テクノロジは、x64 バージョンの Windows におけるさらなるスケーリングのメリットを、このショーケース要件を完全には実装していないアプリケーションに提供する非常に効果的な方法です。
詳細については、DirectX SDK の「ゲーム開発者のための 64 ビット プログラミング」を参照してください。
注意しなくてはならないこのショーケースの大きな課題は、ゲームが依存しているサードパーティ製ライブラリまたはコンポーネントがすべて 64 ビット ネイティブの開発に使用できなければならないことです。マイクロソフトの多くのレガシ API も 64 ビット ネイティブの環境から除去されており、このことがキー システムの古い実装を含むエンジン コードベースにとって難題となる場合があります。
S.3 マルチコアの活用
要件
ゲームが、複数の CPU コアが存在する場合にそのマルチコアを利用する機能を実装していること。シングルコア マシンとデュアルコアまたはクワッドコア マシンでの並列比較により、知覚できる新しい機能、魅力的な追加エフェクト、およびパフォーマンスの向上が認められる必要があります。
理由
CPU パフォーマンスのとどまることのない成長は、クロック レートの向上からコアの追加へ移行しました。AMD と Intel のロードマップはどちらも、スケーラブルなマルチコア設計に基づいています。このプロセッサ進化の抜本的な変化により、次世代ゲーム プラットフォームはすべてマルチコア CPU を搭載しています。シングルスレッド アプリケーションでは、もはや次世代 CPU から多くのメリットを得ることはできません。また、単純にマルチスレッド化しただけでは、一般的な CPU コアの数が 3 個以上に増えたときに、それに応じたアプリケーションのパフォーマンスの向上は望めません。
Additional Information
アプリケーションで使用するスレッドの数を増やしたことによるパフォーマンスの向上は、スレッド間通信とその同期のコストが抑えられている場合にのみ、その効果が得られます。短期的には、機能ベースのスケーリング、つまりシングルコア システムではスレッドを増やさずに普通にゲームを実行し、追加の CPU パワーが使用可能な場合はマルチスレッドを可能にする方法をとる方が、より簡単なソリューションとなります。
DirectX SDK の「Xbox 360 および Microsoft Windows における複数コアのコーディング」を参照してください。マルチコア システムのタイミングを計算する際に Windows API ではなく直接 RDTSC を使用すると、ハードウェアおよび OS の構成によっては、問題が発生する可能性があります。詳細については、DirectX SDK の「ゲームのタイミングとマルチコア プロセッサ」を参照してください。
リソース
Windows Vista SDK
ユーザー アカウント制御のガイドライン
Windows インストーラー情報
WinQual 開発者ポータル
DirectX 開発者ポータル
その他の DirectX SDK 記事