Windows 向けゲームの技術要件: Windows XP、Windows Vista、Windows 7、Windows 8 でのゲームのベスト プラクティス

この記事では、Windows で実行されるゲームの技術要件とベスト プラクティスについて説明します。 これらの技術要件とベスト プラクティスは、主に Windows Vista と Windows 7、および従来の Windows XP オペレーティング システムを対象に作成されました。 これらのベスト プラクティスは、通常、Windows 8 上のデスクトップ Win32 ゲームにも適用されます。

この記事には次のセクションが含まれています:

• Windows 8 の違い
  • 追加情報
• Windows 用ゲーム
  • 1.1 ゲームエクスプローラーの統合
  • 1.2 ファミリーセーフティ/ペアレンタルコントロールのサポート
  • 1.3 豊富なセーブゲームをサポート
  • 1.4 Windows 用 Xbox 360 共通コントローラーのサポート [条件付き要件]
  • 1.5 複数のアスペクト比と解像度をサポート
  • 1.6 Windows Media Centerからの起動をサポート
  • 1.7 Direct3D サポート
  • 1.8 高DPI対応を有効にする
• セキュリティと互換性
  • 2.1 ユーザーアカウント制御ガイドラインに従う
  • 2.2 Windows x64 バージョンのサポート
  • 2.3 ファイルの署名
  • 2.4 ドライバーの署名
  • 2.5 適切なバージョンチェックを実行する
  • 2.6 同時ユーザーセッションのサポート
  • 2.7 長い名前のサポート
• インストール
  • 3.1 簡単なインストールをサポート
  • 3.2 インストール時のユーザーアカウント制御のサポート
  • 3.3 正しいフォルダにインストールする
  • 3.4 Windowsリソースを適切にインストールする
  • 3.5インストール中の再起動を避ける
  • 3.6 ファイルのバージョン管理を正しく使用する
  • 3.7 自動実行をサポートする [条件付き要件]
• 信頼性
  • 4.1 不要な再起動を排除する
  • 4.2 アプリケーション検証の失敗を排除する
  • 4.3 Windows エラー報告とファイル バージョン情報のサポート
• Xbox 360 Windows 用共通コントローラーの用語
• ゲームミドルウェア製品のガイドライン
  • はじめに
  • 追加レコメンデーション
  • Windows 向けゲームのショーケース
• リソース

Windows 8 の違い

ここでは、これらの技術要件とベスト プラクティスを Windows 8 に適用する場合の主な違いの概要を示します。

ゲームエクスプローラーのUIが表示されない

ゲームエクスプローラー に登録したすべてのゲームは、新しい Windows UI にタイルとして表示されますが、タイトルに関連付けられているメタデータの多くは表示されなくなります。 メタデータを作成するには、Windows ソフトウェア開発キット (SDK) で使用できるゲーム定義ファイル メーカー ツール (GDFMAKER.EXE) を引き続き使用します。 メタデータを展開するための既存のメカニズムも使用します。 Windows 7 を使用してゲームエクスプローラーの登録を引き続きテストし、Windows 8 にインストールしたときに新しい Windows UI タイルが表示されることを確認します (1.1 ゲームエクスプローラーの統合を参照)。

Windows 8 SDK をダウンロードするには、デスクトップ アプリを開発するためのダウンロードに関する記事を参照してください。

ゲームエクスプローラーAPIへの登録は、引き続きWindowsペアレンタルコントロールにゲームを登録するためのメカニズムです。

現在サポートされているすべての評価システムを入力できるように、Windows 8 のリリース バージョンで GDFMAKER の Windows SDK バージョンを実行することをお勧めします。

Note

このバージョンの GDFMAKER には .NET 4.0 が必要です。

1.2 ファミリーセーフティ/ペアレンタルコントロールのサポートを参照してください。

要件に応じてXINPUT APIを使用するには、現在3つの選択肢があります。

XINPUT 1.4 は Windows 8 に組み込まれています。 Windows ストア アプリとデスクトップ Win32 アプリの両方で XINPUT 1.4 を使用できます。 すべてのバージョンの Windows は、簡略化された共通コントローラーとして XINPUT 9.1.0 を使用できますが、XINPUT 9.1.0 の再配布パッケージはありません。 すべてのバージョンの Windows では、既存の DirectX SDK バージョン XINPUT 1.3 も使用できますが、これを展開するには DirectSetup が必要です。

1.4 Windows用Xbox 360共通コントローラーのサポートを参照してください。

Windows RTでは、限られたデスクトップWin32アプリのみがサポートされています

Windows 7 で実行されるゲームは、Windows 8 x86 および x64 プラットフォームでも正常に実行できます。

See 2.2 Windows x64 バージョンのサポート。

OSチェックが正しく行われていることを確認する

Windows 8 OS バージョンは 6.2 です。 Windows 8 は、ゲームの展開に推奨される現在の最低限の基準テストに合格しています。

DirectX エンドユーザー再配布パッケージは、Windows 7 と同様に Windows 8 でも正常に実行され、D3DX9、D3DX10、D3DX11、XINPUT 1.3、XAUDIO 2.7、XACTEngine などを展開できます

ただし、従来の Managed DirectX 1.1 アセンブリの展開処理が原因で、.NET 4.0 のみがインストールされているシステムでは、DirectSetup に既知の問題が存在します。 この問題は、デフォルトで .NET 4.5 が付属する Windows 8 と、.NET 4.0 ランタイムがインストールされた新しい Windows XP コンピューターの両方に適用されます。 ただし、この問題は .NET 4.0 より前のバージョンの .NET には適用されません。 Windows 8 には、この問題を自動的に解決するアプリケーション互換性動作 (ネットワーク アクセスが必要) がありますが、DirectSetup を引き続き展開するゲームでは、DirectX SDK (2010 年 6 月) の更新されたバージョンの REDIST ファイルに更新することをお勧めします。 いつものように、タイトルに DirectSetup を使用する場合は、タイトルを最小限の必要 CAB セットに切り詰めます。

3.4 Windows リソースを適切にインストールするを参照してください。.

.NET 2.0互換ランタイム（2.0、3.0、3.5）を必要とするゲームは、既存の展開メカニズムを引き続き使用します。

これらのゲームは、Windows 8 でアプリケーション互換性動作をトリガーし、.NET 3.5 ランタイムを自動的に有効にします (ネットワーク アクセスが必要)。 ただし、.NET 開発者には .NET 4.0 ランタイムに移行することをお勧めします。

Note

従来の Managed DirectX 1.1 アセンブリは、.NET 4.x ランタイムと互換性がありません。

3.4 Windows リソースを適切にインストールするを参照してください。.

.NET に依存するオートランナーやその他のプリインストール テクノロジの使用は推奨されません

Windows Vista および Windows 7 には、.NET 2.0 互換ランタイム (2.0、3.0、3.5) のみが存在すると想定できます。 Windows 8 には、デフォルトで .NET 4.0 互換ランタイムのみが存在します。

3.7 自動実行のサポートを参照してください。

Windows 8用の更新されたアプリケーション検証ツールがあります

Windows 8 SDK には、この更新されたアプリケーション検証ツールが含まれています。

4.2 アプリケーション検証の失敗を排除するを参照してください。

追加情報

Windows 8 と Windows Server 2012 の互換性に関するクックブック
DirectX SDK の場所

Windows 用ゲーム

ゲーム要件の概要

顧客メリット

コンピュータ ゲームは Windows における主要なエンターテイメント体験ですが、使いやすさに関する懸念が長年にわたって顧客の不満の原因となってきました。 従来、ゲームはアプリケーションのようにインストールされますが、エンターテイメント メディア (映画や歌など) のように利用されます。 ゲームエクスプローラーなどの革新的な技術により、標準のアプリケーションとは異なる一貫した方法でゲームが公開されます。 これらの革新により、音楽や画像とともに、ゲームも Windows で第一級の地位を獲得しました。 次の要件は、Windows Vista および Windows 7 が、改善され、よりアクセスしやすく、統一されたゲーム エクスペリエンスを提供することを保証するのに役立ちます。 同時に、Windows XP との互換性も確保されます。

1.1 ゲームエクスプローラーの統合

要件

ゲームは、Windows Vista および Windows 7 のゲームエクスプローラー (Games フォルダー) 内で表示される必要があります。 選択した場合、ゲームには、発行元、開発者、リリース日、バージョン、Windows エクスペリエンス インデックス スコア、評価 (該当する場合)、および関連するハイパーリンクを含む正しいメタデータも表示される必要があります。

ゲームがオンラインゲームサービスを通じてデジタル配信されている場合、サービスプロバイダーもゲームエクスプローラーに表示されるはずです。 プロバイダーの適切な処理を保証し、RSS フィードを使用できるようにするには、ゲーム定義ファイル (GDF) のスキーマのバージョン 2 を使用する必要があります。 (GDF の詳細については、「追加情報」を参照してください。)

さらに、ゲーム インストーラーは、Windows Vista および Windows 7 で実行する場合、次の規則に従う必要があります。

• インストールでは、デスクトップ、スタート メニュー、またはその他の場所にゲームを起動するためのショートカットを作成してはなりません。
• 削除用のタスクやショートカットは作成しないでください。
• ユーザーは、Windows Vista および Windows 7 のコントロール パネルの [プログラムと機能]、または Windows XP のコントロール パネルの [プログラムの追加と削除] を使用してゲームを削除できる必要があります。

Windows XP および以前のバージョンの Windows では、ゲーム インストーラーは必要に応じてプログラム グループ、デスクトップ アイコン、またはショートカットを自由に作成できます。

理由

Windows ゲームエクスプローラーは、Windows XP のフォルダー マイ ドキュメント または マイ ピクチャと概念が似ています。 同様のコンテンツを 1 か所に集めて、整理しやすくし、状況に応じたアクティビティを可能にすることが目的です。 ゲームエクスプローラーは、 マイ ドキュメント または マイ ピクチャ の概念を拡張し、ゲームをより詳細に整理および制御できるようにします。 ゲームエクスプローラーを使用すると、ゲーマーはシステムにインストールされているすべてのゲームを表示、整理、操作できます。 また、ゲームパブリッシャーは重要なゲーム情報をより効果的に伝達できるようになります。 このシステムはデータ駆動型であるため、ゲーム発行者は製品の寿命を通じてゲーム情報を簡単に更新できます。

追加情報

ゲームエクスプローラーとの統合には、ゲーム定義ファイル (GDF) を作成する必要があります。GDF は、Windows アイコンとともに、リソースとしてバイナリ ファイル (実行可能ファイルまたは DLL) 内に埋め込まれた XML テキスト ファイルです。 その後、ゲームを Games Explorer に登録する必要があります。 GDF では、ゲームのタイトル、発行元、開発者、Web サイトへのリンク、オプションのタスクなどの提供された情報を公開することもできます。 サポート タスクは Web サイトへのリンクのみにすることができますが、プレイ タスクはオプションのサポート タスクにも使用できることに注意してください。

ゲームエクスプローラーではサムネイル ビットマップ イメージを使用できますが、代わりに大きなアイコン (256 × 256) を含む Windows アイコン リソースを提供することをお勧めします。 アイコン リソースには、24 ビット (True Color) と 8 ビット (256) の両方の色深度で、256、256、48、48、32、32、および 16 16 の画像サイズが含まれている必要があります。 Visual Studio 2008 および 2010 で提供されるアイコン エディターは、IconWorkshop Lite と同様に、これらの大きなアイコン形式をサポートしています。

Windows ゲームエクスプローラー との統合の詳細については、DirectX SDK で説明されています。 DirectX SDK には、ゲーム定義ファイル (GDF) エディターと、サンプルの GDFExampleBinary に含まれるサンプル GDF が含まれています。 別のサンプルである GameUxInstallHelper は、必要な機能を既存のインストール システムに統合するためのルーチンを提供します。 ゲーム定義ファイル バリデーター (gdftrace.exe) は、GDF を評価するためのデバッグ サポートを提供します。 また、C++ 用の DirectX SDK ドキュメントの「Windows ゲームエクスプローラーの統合」も参照してください。

Windows 7 では、GDF ファイルのスキーマの 2 番目のバージョンのサポートが導入されています。 新しいバージョンには、プレイ タスクを作成するための簡略化された方法と、更新通知、ゲーム サービス プロバイダー、ゲーム統計、ゲーム サービス プロバイダーの RSS フィードのサポートが含まれています。 GameUxInstallHelper の最新バージョンは、Windows Vista でバージョン 2 の GDF ファイルを使用するために必要なすべての登録とレガシー サポートを処理します。 2009 年 8 月以降の DirectX SDK のツールとサンプル コードを使用します。 RSS フィード、ゲーム統計、更新通知のサポートを有効にするには、バージョン 2 の GDF ファイルを使用することをお勧めします。 また、サンプル ProviderGDFExampleBinary と GameStatisticsExample も参照してください。

Windows Vista Business Edition、Windows 7 Professional Edition、および Windows Vista と Windows 7 の Enterprise Edition では、[スタート] メニューの [ゲーム] リンクは非表示になっています。 ゲームエクスプローラーは、スタート メニューで [すべてのプログラム] をクリックし、次に [ゲーム] をクリックすることで引き続き利用できます。

ゲームと一緒にインストールされる関連アプリケーション（それ自体はゲームではない）については、Windows Vista および Windows 7 を含むすべてのバージョンの Windows でスタート メニュー プログラム グループ、ショートカット、およびデスクトップ アイコンを自由に作成できます。 このような関連アプリケーションは、該当する Games for Windows の要件を満たす必要があります。詳細については、 「ゲーム ミドルウェア製品のガイドライン」を参照してください。 ゲーム サービスは、Windows 7 のゲーム プロバイダーとして Games Explorer に登録することをお勧めします。 1

1.2 ファミリーセーフティ/ペアレンタルコントロールのサポート

要件

ゲームは、次のルールに従って Windows ファミリー セーフティを完全にサポートする必要があります。

• ゲームをプレイするには、ユーザーに管理者の資格情報を要求する必要がありません。 インストール、パッチ適用、および削除には、セクション 3 の要件に従って、管理者の資格情報が必要になる場合があります。 (これに関連するのは、要件 2.1「ユーザー アカウント制御ガイドラインに従う」です。)
• ESRB や PEGI などの Windows 対応の評価委員会によって評価されたゲームでは、割り当てられた評価情報がゲーム定義ファイル (GDF) に含まれている必要があります。 利用可能なすべての評価データは、GDF のすべてのローカライズ版と言語中立版の両方に含まれている必要があります。
• ゲームは、実行時にランダムに名前が付けられた実行可能ファイルを作成する著作権侵害対策テクノロジを使用しない限り、一般的なアプリケーション制限に対して優れたユーザー エクスペリエンスを提供するために、GDF に実行可能ファイルをリストする必要があります。
• ゲームは、起動時にゲームエクスプローラー インターフェイスの VerifyAccess メソッドを呼び出す必要があり (使用可能な場合)、*pfHasAccess が FALSE として返された場合は終了する必要があります。

理由

Windows ペアレンタル コントロールによって制御されるアカウントがゲームをプレイできるようにするには、すべてのゲームを標準ユーザー アカウントのコンテキスト内で実行する必要があります。 親は、子供のゲームへのアクセスを監視および制御する機能を望んでいます。 さらに、多くの業界、政府、支援団体は、子供が接するゲームを親が監視し、制御できるより良い方法を望んでいます。 Microsoft は、Games Explorer が提供するアーキテクチャと組み合わせて、Windows ペアレンタル コントロールを通じて保護者にこの機能を提供します。

レーティング委員会プログラムに参加していないゲームであっても、昇格された権限を要求すると、大多数のユーザー アカウントのプレイ エクスペリエンスが低下します。 これは特に、ペアレンタルコントロールが有効になっている場合に当てはまり、ゲームを起動するたびに保護者が管理者パスワードを入力する必要があります。

Windows ペアレンタル コントロール システムを使用すると、保護者は子供に適切と思われる評価を選択できます。 ペアレンタルコントロールは、世界中の多くの評価システムをサポートしています。 ペアレンタルコントロールを使用すると、保護者はコンテンツ記述子に基づいてゲームへのアクセスを制限したり (該当する評価システムがサポートしている場合)、個々のゲームへのアクセスを許可または禁止したりすることもできます。

Windows ペアレンタル コントロールの評価システムのデフォルトの選択はシステムのロケール設定に基づいていますが、ユーザーは コントロール パネル の 地域と言語のオプション で変更できます。 したがって、サポートされているすべての言語で利用可能なすべての評価データが提供され、ユーザーが希望する評価委員会を自由に選択できるようにする必要があります。

追加情報

評価のないゲームでも、標準ユーザーとしてプレイをサポートし、 VerifyAccessを呼び出すための要件を満たす必要があります。 このようなゲームはデフォルトで未評価のカテゴリに分類され、ゲームエクスプローラーに「評価なし」というテキストが表示され、未評価のゲームに対する ペアレンタル コントロール の ゲーム制限 設定の対象となります。 デフォルトの 制限 設定は許可です。

含まれるバイナリが適切に Authenticode 署名されていない場合、GDF の評価情報は無視されます。 要件 2.3を参照してください。

DirectX SDK のゲーム定義ファイル エディターには、サポートされているすべての評価システムが含まれており、この情報は GDF のすべてのローカライズ バージョンと言語に依存しないバージョンに正しく複製されます。 GDFTrace ツールは、存在するすべての評価情報をデコードして検証します。 これらのツールの 2009 年 8 月バージョン以降を使用してください。

ゲームプロバイダーの GDF には通常、評価情報は含まれておらず、評価されていないコンテンツの設定が適用されます。

オペレーティング システム	サポートされている評価システム
Windows Vista	CERO (日本) ESRB (米国) OFLC (オーストラリア) PEGI (ヨーロッパ) PEGI フィンランド (廃止) PEGI ポルトガル PEGI/BBFC（イギリス） USK (ドイツ)
Windows Vista サービスパック	Windows Vista のサービス パックでは、次のサポートが追加されます。 GRB (韓国) ESRB「軽度」バリアントコンテンツ記述子
Windows 7	Windows 7 は、Windows Vista でサポートされている評価システムをサポートし、以下のサポートも追加しています。 CSRR (台湾)
Windows 8	Windows 8 は以前の評価システムをサポートし、以下のサポートが追加されています。 COB-AU (オーストラリア) DJCTQ (ブラジル) PFB (南アフリカ) OFLC-NZ (ニュージーランド) Windows 8 では、現在非推奨となっている以下のシステムのサポートが終了します。 PEGI-FI (フィンランド) OFLC (オーストラリア)

Note

新しい ESRB Windows Vista Service Pack 1 (SP1) コンテンツ記述子を含むタイトルは、サービス パックのない Windows Vista では未評価として表示されます。

新しい評価データは、サポートされていないオペレーティング システムのバージョンでは無視されます。 PEGI (フィンランド) バリアントは、標準の PEGI (ヨーロッパ) 評価システムに置き換えられ、現在は非推奨となっています。 オーストラリアでは、OFLC システムが廃止され、代わりに COB-AU が採用されています。

ゲームを標準ユーザー権限と互換性のあるものにする方法の詳細については、DirectX の記事「ゲーム開発者向けのユーザー アカウント制御」を参照してください。

ゲーム定義ファイル (GDF) の詳細については、要件 1.1 を参照してください。

1.3 豊富なセーブゲームをサポート

[この要件は廃止されました]

1.4 Windows 用 Xbox 360 共通コントローラーのサポート [条件付き要件]

要件

ゲームパッド コントローラーをサポートするゲームは、 XInput API を使用して Xbox 360 Controller for Windows をサポートする必要があります。 DirectInput 周辺機器もサポートされている場合は、DirectInput も使用できます。 ただし、Xbox 360 互換デバイスを使用する場合は、XInput をデフォルトの API にする必要があります。

一般的なコントローラーのトリガーとボタンへの参照では、Xbox 360 の名前を使用する必要があります。 詳細については、 Xbox 360 Common Controller for Windows の用語 リストを参照してください。

ゲームが一時停止または中断状態にあるときは、コントローラーの振動をオフにする必要があります。

マウス/キーボードのコントロールは、いつでも完全に無効にすることはできません。 少なくとも、ゲーム メニューに戻るオプションが用意されている必要があります。

理由

この要件により、ゲーマーは、より自然で直感的なインターフェイスである入力方法に応じて、Xbox 360 コントローラーまたはキーボードとマウスのいずれかを使用する自由を選択できます。

追加情報

この要件は、マウスとキーボードのみを使用するゲームには適用されません。

広く受け入れられている標準のコントローラー ボタンを使用するようにメニュー ナビゲーションを実装することをお勧めします。

• A - 承認
• B - キャンセル
• 開始 - 承認または一時停止
• 戻る - キャンセル、1画面戻る、またはメニューレベルを上げる

詳細については、 XInputを参照してください。

トピック「XInput と DirectInput」では、両方の API を同時に使用する場合の問題について説明します。

キーボードまたはマウスのコントロールを実装するために DirectInput を使用しないことをお勧めします。 キーボードとマウスのコントロールは、Windows メッセージと Win32 API を使用してのみ実装する必要があります。 DirectInput を使用せずに高解像度のマウス移動情報を取得する方法の詳細については、「高解像度のマウス移動の活用」を参照してください。

1.5 複数のアスペクト比と解像度をサポート

要件

ゲームは少なくとも次のアスペクト比と関連する画面解像度をサポートする必要があります。

• 4:3 通常 (800 600 または 1024 768)
• 16:9 ワイドスクリーン (1280 720)
• 16:10 ワイドスクリーン (1152 720 または 1680 1050 または 800 480)

画面解像度の設定と検出については、ゲームは次のルールに従う必要があります。

• サポートされている解像度であれば、ゲームはデフォルトでディスプレイ デバイスのデスクトップ解像度を使用します。 ゲームが別のデフォルト解像度を選択する場合は、デスクトップのアスペクト比を検索基準として使用する必要があります。
• ゲームでは、変更が行われたときにユーザーに新しい表示設定を確認するよう求める必要があります。 ユーザーが 15 秒以内に承認しない場合は、表示は以前の設定に戻る必要があります。
• ゲームは、ワイドスクリーンのアスペクト比をサポートするためにピクセルを引き伸ばしたり、4:3 レンダリング ウィンドウを中央に配置したりしてはなりません。 ただし、レターボックスは許容されます。

理由

Windows 3D デスクトップでは、次の要因により、特定のアスペクト比または解像度を想定することはできません。

• 高精細ディスプレイのサポート。
• ワイドスクリーンモニターの市場シェアが拡大。
• Windows Media Center の HDTV 展開。
• アクセシビリティ要件。

追加情報

理想的には、ゲームはデフォルトでディスプレイのネイティブ アスペクト比に設定されます。 ただし、この情報を確実に取得するのは難しい場合があるため、より一般的な解決策として、ゲームではデスクトップがネイティブのアスペクト比で実行されていると想定できます。 デスクトップの解像度は、ENUM_REGISTRY_SETTINGS を指定して EnumDisplaySettings を呼び出すことによって取得できます。

詳細については、DirectX の記事「Windows ゲーム開発者向けの 10 フィート エクスペリエンスの概要」の「アスペクト比」および「ワイド スクリーン」のセクションを参照してください。

1.6 Windows Media Centerからの起動をサポート

[この要件は廃止されました。]

1.7 Direct3D サポート

要件

ゲームで Direct3D を使用する場合、サポートされる最小バージョンは Direct3D 9 であり、デフォルトのレンダラーとして Direct3D を選択する必要があります。

理由

Windows Vista および Windows 7 のコア グラフィックス アーキテクチャは、Direct3D を中心に設計されています。 Direct3D 8 以前のバージョンは、従来のインターフェイスを再マッピングすることでサポートされます。

Direct3D 9 より新しいバージョンの Direct3D の使用を強くお勧めします。 Games for Windows ショーケース S.1 をご覧ください。 Direct3D 10 または Direct3D 11 を要求することは、要件 1.7 に完全に準拠しています。

1.8 高DPI対応を有効にする

要件

Windows Vista および Windows 7 で、ドット/インチ (DPI) スケーリングが有効になっている場合 (ディスプレイ解像度 1600 x 1200 で 144 DPI の 150% スケーリングでテスト済み)、ゲームとそのインストーラーは視覚的な問題なく正常に実行される必要があります。

通常、ゲーム実行可能ファイルが DPI 対応であることを宣言する必要があります。 これは、マニフェスト要素 <dpiAware>true<dpiAware>を埋め込むことによって実現されます。

理由

高品質の LCD モニターはコンピューターのディスプレイとして一般的であり、ネイティブ解像度 (通常は 1280、1024、1600、1200 など) で駆動すると最も美しく表示されます。 この解像度でテキストを読んだり画像を見たりするのが難しいお客様は、多くの場合、コンピューターのデスクトップを低い解像度に設定し、LCD のスケーリングによる視覚的なアーティファクトに悩まされています。 代わりに、顧客は解像度をネイティブ サイズのままにして、Windows ディスプレイの DPI を変更することで、画像の品質を犠牲にすることなく、アイテムとテキストの外観を大きくすることができます。

この機能は Windows XP 以降何らかの形で利用可能でしたが、顧客や OEM によって有効にされることはほとんどありません。 顧客からのフィードバックによると、現在、コンピューター ディスプレイの半分以上が、モニターのネイティブ解像度よりも低い解像度に設定されています。 Windows 7 では、初期セットアップ時やディスプレイ設定の変更時にこの機能が顧客にとってよりわかりやすくなり、デスクトップ解像度を変更するのではなく DPI スケーリングを使用するように促します。

追加情報

プロセス起動コードの早い段階で呼び出される場合は、代わりに SetProcessDPIAware 関数を使用できます。 メイン エントリ ポイントが呼び出される前に初期化される可能性のあるソフトウェア要素 (DLL など) との競合状態が発生しないようにするために、マニフェストに追加することをお勧めします。 SetProcessDPIAware は Windows Vista および Windows 7 にのみ存在することに注意してください。

マニフェスト要素の追加は、Visual Studio 2005 および 2008 を使用すると簡単です。次のテキストを含む dpiaware.manifest という名前のファイルを作成します。

            <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
            <asmv3:application>
            <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware>true</dpiAware>
            </asmv3:windowsSettings>
            </asmv3:application>
            </assembly>

次に、Visual Studio 内で、dpiware.manifest をプロジェクトに追加します。 プロジェクトのプロパティで、 「マニフェストの埋め込み」 が 「はい」 に設定されていることを確認します。 マニフェスト ツール (Mt.exe) の古いバージョンでは、DPI 対応のマニフェスト要素で誤った警告が生成されることに注意してください。 この問題を解決するには、Windows SDK から Mt.exe を最新バージョンに更新します。

Visual Studio 2010 には、プロジェクト プロパティに DPI 認識を有効にする という設定が含まれており、これにより dpiaware.manifest のようなファイルは不要になります。 構成プロパティ と マニフェスト ツールを展開し、 入力 & 出力を選択して、 DPI 認識を有効にする を見つけます。

Windows では、従来の表示モードはデフォルトで 96 DPI に設定されており、これは CRT モニターでは一般的でした。

フルスクリーン アプリケーションはディスプレイの解像度を変更しますが、バッファーとディスプレイの四角形を設定するときに、ウィンドウ メッセージとメトリックを使用することが多いです。 DPI 仮想化により、これらの全画面表示モードは切り取られて表示されますが、DPI 対応を宣言するとこれらの問題を回避できます。 詳細については、 「DPI 対応 Win32 アプリケーションの作成」を参照してください。

セキュリティと互換性

>セキュリティと互換性の要件の概要

顧客メリット

次の要件により、ゲームの全体的なセキュリティが向上し、さまざまなアーキテクチャ、さまざまな構成、さまざまなモードで Windows でゲームが動作することが保証されます。

2.1 ユーザーアカウント制御ガイドラインに従う

要件

すべての実行可能ファイル (つまり、.exe 拡張子を持つすべてのファイル) には、次のタグを含めることによって実行レベルを定義する埋め込みマニフェストが含まれている必要があります。

            <requestedExecutionLevel>

要件 1.2 に従い、標準ユーザー コンテキストをサポートするには、メイン ゲームと Autorun 実行可能ファイルの実行レベルが asInvoker である必要があります。

ファイル エクスプローラー でファイルの関連付けが登録されているユーザー データ ファイルは、CSIDL_PERSONAL で指定されたフォルダー (ドキュメント または マイ ドキュメントとも呼ばれます) のサブフォルダーに配置する必要があります。 その他のすべてのユーザー データ ファイルは、CSIDL_LOCAL_APPDATA または CSIDL_COMMON_APPDATA で指定されたフォルダーのサブフォルダーに保存する必要があります。 (これらのディレクトリは、個々のユーザーおよびすべてのユーザーに対してデフォルトで非表示になっています。)

理由

アプリケーションが必要な権限でのみ実行される場合、ユーザーの Windows エクスペリエンスはより安全になります。

追加情報

アプリケーション内の少数の機能のみが管理者権限を必要とする場合 (たとえば、ファイアウォールを構成する必要があるアプリケーション)、アプリケーションのメイン プロセスは、標準のユーザー権限を使用して実行する必要があります。 管理者権限を必要とする機能は、インストーラーや構成ユーティリティなどの別のプロセスに移動する必要があります。

管理者権限が必要ない場合は、埋め込まれたマニフェスト 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>

Visual Studio 2005 では、前述のブロックのいずれかを含むマニフェスト (.manifest) ファイルをプロジェクトに追加し、マニフェスト ツールのプロジェクト プロパティで [マニフェストの埋め込み] が [はい] に設定されていることを確認するだけで、簡単に埋め込むことができます。 Visual Studio 2008 および 2010 の場合、UAC プロパティは、 マニフェスト ファイル ページのリンカーのプロジェクト プロパティで直接設定できます。 マニフェスト ツール (Mt.exe) の古いバージョンでは、UAC マニフェスト要素で誤った警告が生成されることに注意してください。 この問題を解決するには、Windows SDK から Mt.exe を最新バージョンに更新します。

インストール、パッチ適用、削除の特殊なケースの詳細については、要件 3.1 を参照してください。

ダイナミック リンク ライブラリ (DLL) には、このようなマニフェストは必要ありません。

ユーザー アカウント制御の詳細については、「ゲーム開発者向けのユーザー アカウント制御」を参照してください。

2.2 Windows x64 バージョンのサポート

要件

64 ビット版の Windows との互換性を維持するには、ゲームは次の要件を満たす必要があります。

• タイトルおよびタイトル インストーラーには、16 ビット コードを含めたり、16 ビット コンポーネントに依存したりしてはなりません。
• ゲームの動作にカーネル モード ドライバーが必要な場合は、これらのドライバーの x64 バージョンが利用可能である必要があります。 ゲームのセットアップでは、64 ビット版の Windows 用の適切なドライバーとコンポーネントを検出してインストールする必要があります。

理由

多くの Windows Vista および Windows 7 ユーザーは、製品の寿命を通じて 64 ビット版のオペレーティング システムを実行するため、アプリケーションがこのオペレーティング システムと互換性があることは非常に重要です。

追加情報

Windows on Windows 64 (WOW64) では、32 ビット コードを 64 ビット エディションの Windows で実行できるため、アプリケーションが 64 ビット エディションの Windows 上のネイティブ 64 ビット コードである必要はありません。 16 ビット コードは、64 ビット版の Windows では実行されません。

Windows XP Professional x64 Edition との互換性を維持することは必須ではありませんが、強く推奨されます。

詳細については、 ゲーム開発者向け 64 ビット プログラミングを参照してください。

2.3 ファイルの署名

要件

すべての実行可能コード ファイル (通常、拡張子が .exe または .dll のファイル) は、公的に有効な Authenticode 証明書で署名されている必要があり、運用署名用の有効なタイムスタンプ サーバー URL を持っている必要があります。

ゲームで Windows インストーラーを使用する場合は、インストーラー パッケージ ファイル (.msi ファイル) に署名する必要があります。

理由

ファイルに署名すると、ユーザーはアプリケーションを信頼するかどうかを決定し、ファイルが改ざんされていないことを保証できます。 また、ロックダウンされた環境でもアプリケーションを適切に実行できるようになります。

追加情報

詳細については、 ゲーム開発者向けの Authenticode 署名を参照してください。

ゲームで Windows インストーラーを使用する場合は、MsiPatchCertificate テーブルを追加して、UAC/LUA パッチを有効にすることをお勧めします。 詳細については、 ユーザー アカウント制御 (UAC) のパッチ適用を参照してください。

キャビネット ファイル (.cab) が比較的小さい場合 (100 MB 未満) を除き、署名することはお勧めしません。

2.4 ドライバーの署名

要件

ゲームによってインストールされるカーネル モード ドライバーは、公的に有効な Authenticode 証明書で署名されている必要があります。

ゲームによってインストールされるカーネル モードのハードウェア デバイス ドライバーには、Windows Hardware Quality Labs (WHQL) または Driver Reliability Signature (DRS) プログラムから取得できる Microsoft 署名が必要です。

理由

不適切に記述されたドライバーやマルウェア ドライバーは、システムの安定性とセキュリティに重大な影響を及ぼす可能性があります。 Windows Vista および Windows 7 の 64 ビット版では、署名されていないドライバーは読み込まれません。 このポリシーは、Windows Vista および Windows 7 の 32 ビット版でも有効にできます。

追加情報

要件 2.2 に従って、すべてのカーネル モード ドライバーの 32 ビットおよび 64 ビットのネイティブ バージョンが必要です。

Microsoft ドライバー署名プログラムの詳細については、 Windows ハードウェア デベロッパー センターを参照してください。

2.5 適切なバージョンチェックを実行する

要件

エンド ユーザー ライセンス契約で将来のオペレーティング システムでの使用が禁止されていない限り、Windows バージョン番号の変更によって示されるように、ゲームは将来のオペレーティング システムでも実行可能である必要があります。 ゲームが失敗する場合は、ユーザーに適切なメッセージを表示して適切に処理する必要があります。

Windows バージョンのチェックを行う場合は、バージョン チェック API (GetVersionEx または VerifyVersionInfo) を使用してオペレーティング システムのバージョンを確認する必要があります。 バージョンを確認するためにレジストリ キーを読み取ってはなりません。

ゲーム内に DirectX ランタイムの明示的なバージョン チェックが存在してはなりません。 これらのバージョン チェックは、DirectX ランタイム セットアップ (DirectSetup) を起動するインストールには存在してはなりません。

理由

Windows ユーザーがオペレーティング システムをアップグレードする場合、Windows のバージョン番号が上がったという理由だけで、現在のゲームをプレイできなくなるべきではありません。 適切に記述されていないバージョン チェッカーは、新しいバージョンの Windows や Windows サービス パックの追加だけで正常に動作するソフトウェアに問題を引き起こし続けます。

DirectX ランタイムのバージョン チェック比較ロジックが脆弱なため、異なるバージョンの Windows で実行した場合にインストールが何度も失敗します。 DirectX のバージョン番号は、コア オペレーティング システム コンポーネントにのみ適用されます。 これは、多くのゲームで使用されるサイドバイサイド DirectX SDK コンポーネントには適用されません。

追加情報

インストーラーが最小 OS バージョンをチェックするのはよくあることです。 ただし、このチェックは、単純な等価性ではなく、より大きいか等しいことをテストして、オペレーティング システムの特定のバージョンにロックするように注意して行う必要があります。 Application Verifier の HighVersionLie テストを使用すると、インストーラーが OS バージョン番号の大幅な変更にどのように反応するかをすばやく簡単に判断できます。

DirectX ランタイム再配布パッケージ (DirectX セットアップ) を適切に使用するには、インストール中に常にこれを起動し、できればサイレント モードで起動する必要があります。 これにより、Microsoft が提供するコードで必要なバージョン更新を実行できるようになります。 また、D3DX、XACT、MDX、XInput などのオプションのサイドバイサイド DirectX SDK コンポーネントをインストールすることもできます。

DirectX ランタイムを展開するためのベスト プラクティスについては、 「ゲーム開発者向けの DirectX のインストール」を参照してください。

Windows XP をサポートするゲームでは、Service Pack 2 (SP2) および Service Pack 3 (SP3) によってセキュリティが大幅に強化され、DirectX ランタイムの再配布要件が簡素化され、展開範囲が非常に広くなるため、Service Pack レベル 2 以上を確認することをお勧めします。 Windows XP をサポートする最新の Microsoft テクノロジのほとんどには、SP2 または SP3 (XAudio2、Games for Windows - LIVE など) が必要です。

2.6 同時ユーザーセッションのサポート

要件

3D グラフィックスに依存するゲームはリモート デスクトップ接続で動作する必要はありませんが、ゲームが失敗した場合はユーザーに警告する必要があります。

ゲームは、次のルールに従って、標準の Windows マルチタスク シナリオをサポートする必要があります。

• ゲームは同時ユーザーセッションの使用をブロックしてはなりません。
• ゲームがすでに別のセッションで実行されている場合は、新しいユーザー セッションで実行する必要があります。
• あるユーザー セッションのゲーム サウンドは、別のユーザーが別のセッションでアクティブになっているときには聞こえてはなりません。
• ゲームは Fast User Switching をサポートしている必要があります。
• ゲームは標準のタスク切り替えを無効にしようとしてはなりません。 ゲームでは、ALT + TAB キーボード ショートカットを無効にしないでください。 「ゲームでのショートカット キーの無効化」で説明されているように、ゲームではアクセシビリティ キーボード ショートカットを無効にすることができます。

理由

Windows ユーザーは、競合や中断なしに同時セッションを実行できる必要があります。 これは、家族、ルームメイト、その他の人と共有されている Windows コンピューターによくあるシナリオです。

追加情報

ゲームがリモート セッションで起動されているかどうかをテストするには、 GetSystemMetrics(SM_REMOTESESSION) を呼び出します。 ゼロ以外の値は、セッションがリモートであることを示します。

詳細については、「ユーザーの簡易切り替え」を参照してください。 ペアレンタルコントロールの時間制限が有効になっている場合、ユーザーの時間が終了したときに、ユーザーの簡易切り替えが発生することに注意してください。 詳細については要件 1.2 を参照してください。

2.7 長い名前のサポート

要件

ゲームがファイルの保存をサポートしている場合は、長い名前とパスを持つファイルを保存できる必要があります。 ゲームは、\ / : * ? などの特殊なファイルシステム文字を適切に処理する必要があります。 「<>、ファイル名またはパスを作成するために使用されるすべてのユーザー入力フィールド内。

ユーザーのユーザー名が長い場合でも、ゲームは正常に動作する必要があります。

理由

プレイヤーは、基盤となるオペレーティング システムでサポートされている深いパスで長い名前を使用することに慣れています。

追加情報

長い名前は、Windows SDK で定義されている最大値を含む名前として定義されます。

インストール

>セキュリティと互換性の要件の概要

顧客メリット

アプリケーションが公式のシステム コンポーネント配布方法を使用する場合、オペレーティング システムや他のアプリケーションのパフォーマンスを低下させることなく、アプリケーションが Windows にインストールされることをお客様は確信できます。 合理化されたインストール エクスペリエンスにより、ゲームをより簡単に、そしてトラブルなくすぐに使用できるようになります。

3.1 簡単なインストールをサポート

要件

ゲームでは、以下を実装して、セットアップ ユーザー インターフェイスに簡略化されたパスを提供する必要があります。

• 最大 1 つの EULA プロンプトを表示します。
• デフォルトのインストール パスでは、インストールのすべての選択 (インストール フォルダーやコンポーネントの選択など) をバイパスし、デフォルトの選択を前提として、インストールが成功すると追加のプロンプトなしでゲームまたはランチャーを実行する必要があります。 必要に応じて、高度な構成オプション用のカスタム インストール オプションを提供できます。
• 適切な Microsoft 再配布パッケージを使用して、必要なオペレーティング システム コンポーネント (DirectX や Visual C ランタイムなど) をインストールします。 インストールは、プロンプトが表示されず、コンポーネントのバージョン チェックによって保護されることなく、サイレントに実行される必要があります。
• ゲーム アプリケーションと生成された作業ファイルの両方について、 コントロール パネル の プログラムと機能 から削除を提供します。 ユーザーが作成したデータ ファイルを削除するオプションをお勧めします。 削除プロセスでは、インストールされているすべてのファイルが削除され、すべての設定 (ファイアウォールの例外リストのエントリやレジストリ キーなど) がクリアされることを確認する必要があります。 再配布されたオペレーティング システム コンポーネントは削除しないでください。
• ゲームで Windows ファイアウォールに例外を追加する必要がある場合、セットアップ プロセスでこの変更が必要であることをユーザーに通知するプロンプトを表示できます。 このプロンプトはインストールが始まる前に表示されます。

インストールと削除には管理者権限が必要になる場合があります。 更新の頻度によっては、パッチ適用時に管理者の資格情報の入力を求める必要がある場合があります。 ゲームの通常のプレイでは、要件 2.1 ユーザー アカウント制御ガイドラインに従って、管理者権限を必要としません。

理由

簡単なインストールは、Windows オペレーティング システムを実行しているコンピューターにゲームをインストールするという、面倒でわかりにくいプロセスを簡素化および合理化するように設計された、Windows 中心のゲーム開発哲学です。 一連のテクノロジとベスト プラクティスを利用することで、Windows コンピューターにゲームをインストールする際の不要な複雑さとリスクを軽減し、簡単なインストールが可能になります。

主な目標は次のとおりです。

• ゲームに参加してプレイを開始するまでの時間を短縮します。
• ゲームのインストール操作を簡素化するために、ダイアログ ボックスと選択肢の数を非常に少なくするか、まったくなくします。

従来のインストールには、アプリケーションが正常にインストールされたように見えても、機能しないインストールを許可するプロンプトが表示されるものがあります。 たとえば、ゲームではユーザーに EULA への同意を求めることができます。 ゲームがインストールされ、DirectX EULA が表示されます。 この EULA により、ユーザーは DirectX ランタイムのインストールを拒否してスキップすることができます。 このシナリオでは、コンポーネントが不足しているためにゲームの実行に失敗する可能性があります。

追加情報

ゲームのインストール、従来とは異なるゲームのインストール手法、UAC 互換のパッチ適用ソリューション、頻繁なパッチ適用の処理の詳細については、次の DirectX の記事を参照してください。

• ゲームインストールの簡略化
• ゲームのオンデマンドインストール
• Windows XP、Windows Vista、Windows 7 でのゲーム ソフトウェアのパッチ適用
• 大規模マルチプレイヤーオンラインゲームのインストールに関するベストプラクティス

Note

ユーザー固有の生成データ ファイルの削除は、現在のユーザーと共通の共有ユーザーの場所に対してのみ実行する必要があります。 削除に管理者の資格情報が必要な場合でも、システムをスキャンして他のユーザーのユーザー固有のファイルを削除する堅牢な方法はありません。

3.2 インストール時のユーザーアカウント制御のサポート

要件

ゲーム インストーラーは、ユーザーと同じコンテキストで実行されていると想定してはなりません。 管理者の資格情報の昇格により、ユーザー固有の場所は、シングルユーザー システムの場合でもインストーラーやプレーヤーとは異なります。 したがって、ゲームを初めて実行するときは、インストール プロセスとは別に、ユーザー固有のタスクを実行する必要があります。

ユーザーがマルチプレイヤー ゲームをホストまたは参加するときに、Windows ファイアウォールの例外ダイアログ ボックスが表示されてはなりません。 必要な構成はインストール時に行う必要があります。 セットアップ手順では、この操作がセットアップの一部として実行されることをユーザーに通知する必要があります。

ゲーム インストーラーは、要件 2.1 ユーザー アカウント制御ガイドラインに従って、必要な実行レベルを指定する埋め込みマニフェストを提供する必要があります。

インストールが完了した後にインストーラーによってゲームが起動される場合は、元のユーザーのコンテキストで起動する必要があります。

理由

Windows Vista における Windows オペレーティング システムの最大の変更点の 1 つは、ユーザー アカウント制御 (UAC) の追加です。これにより、アプリケーションはデフォルトで制限された権限で実行されます。 その結果、インストーラーはそれに応じて権限レベルを管理する必要があります。 Windows 7 でも UAC が広く使用されています。 Windows 7 では UAC のユーザー エクスペリエンスが向上していますが、混乱を招く可能性のある仮想化動作に依存せずにインストーラーが適切に機能するには、Windows Vista と同じ要件を満たす必要があります。

UAC は Windows Vista および Windows 7 ではデフォルトで有効になっており、大多数のお客様 (フィードバックに基づくと 88% 以上) はこの機能を有効のままにしています。

追加情報

Windows ファイアウォールの構成の詳細については、DirectX の記事「ゲーム開発者向け Windows ファイアウォール」および FirewallInstallHelper サンプルを参照してください。

インストールが標準ユーザーによって開始され、セットアップ プロセスに管理者権限が必要な場合 (つまり、管理者の資格情報の入力を求める場合)、インストール プロセスの最後にゲームを標準的に起動すると、この要件の最後の側面が満たされません。 また、管理者権限も継承されるため、潜在的なセキュリティ リスクとなります。 代わりに、インストーラーの正常な呼び出しから戻った後、セットアップ ブートストラップ ローダーがゲームを起動する必要があります。 詳細については、MSDN マガジンの記事「Windows Vista ユーザー アカウント制御を使用してアプリを正常に動作させる方法」を参照してください。

3.3 正しいフォルダにインストールする

要件

すべてのユーザー向けにインストールされるゲームは、デフォルトで Program Files フォルダーにインストールする必要があります。 ユーザー データは、インストール時ではなく、ゲームを初めて実行するときに書き込む必要があります。

理由

ユーザーは、必要な場所にアプリケーションを柔軟にインストールできる必要があります。 また、ファイルのデフォルトの場所に関しても、一貫性のある安全なエクスペリエンスを実現する必要があります。

追加情報

ゲームでは、さまざまな既知のフォルダーの場所 (CSIDL_LOCAL_APPDATA や CSIDL_COMMON_APPDATA で指定される場所など) を利用して、大量のゲーム データとサポート実行可能ファイルを保存し、高度なオンデマンド インストールやパッチ適用のシナリオを実装できます。

インストールでは、すべてのユーザーのインストール プロセス中に別のユーザー アカウントへの昇格が必要になる場合があるため、インストール時にデータを保存する正しいユーザーの場所はありません。 また、ファイル暗号化が有効になっている場合、暗号化されたファイルにアクセスできるのは、そのファイルを作成したユーザー アカウントのみです。

3.4 Windowsリソースを適切にインストールする

要件

アプリケーションは、Windows リソース保護 (WRP) によって保護されているファイルまたはレジストリ キーのインストールを試行してはなりません。 アプリケーションに新しいバージョンのシステム コンポーネントが必要な場合は、Microsoft Service Pack またはシステム コンポーネントを含む Microsoft 承認のインストール パッケージを使用して、これらのコンポーネントを更新する必要があります。 システム コンポーネントは絶対に再パッケージ化しないでください。

理由

Windows リソース保護 (WRP) は、保護されたシステム リソースが、Microsoft が承認したインストールまたは更新メカニズムのみを使用して更新されるように設計されています。 WRP は、インストールの結果が予測可能であることを保証することで、システムの信頼性を向上させます。

追加情報

WRP は、Windows フォルダーにインストールされているシステム コンポーネントの大部分を保護する Windows ファイル保護の後継です。 WRP は、COM オブジェクトの作成設定を保存するほとんどのレジストリ キーを保護します。 また、オペレーティング システム専用に特定のフォルダーを予約します。 保護されたリソースにアクセスしようとすると、通常はアクセス拒否エラーが発生します。

DirectX ランタイムをゲームと共に展開する場合のベスト プラクティスの詳細については、DirectX の記事「ゲーム開発者向けの DirectX のインストール」を参照してください。

3.5 インストール中の再起動を避ける

要件

ゲーム インストーラーは、返される結果または Microsoft のドキュメントで再起動が指示されていない限り、再配布パッケージからの Windows コンポーネントのインストールに再起動が必要であると想定してはなりません。

ゲーム インストーラーが常に再起動を強制する場合は、Microsoft の承認が必要です。

Windows インストーラー パッケージに含まれる使用中のファイル ダイアログ ボックスには、セットアップの完了後にアプリケーションを自動的に閉じて再起動するオプションが含まれている必要があります。

理由

インストール後にシステムを再起動することは、ユーザーにとって不便な中断であり、通常は必要ありません。

追加情報

詳細については、「Restart Manager での Windows インストーラーの使用」を参照してください。

3.6 ファイルのバージョン管理を正しく使用する

要件

ゲームのインストール プログラムは、最新のファイル バージョンがインストールされているかどうかを適切に確認する必要があります。 ゲームをインストールしても、自分で作成していないファイルや、自分で作成していないアプリケーションによって共有されているファイルが元に戻ってはなりません。

理由

共有コンポーネントとシステム コンポーネントは、セキュリティ修正や機能拡張のために頻繁に更新されます。 更新されたコンポーネントの古いバージョンを含むインストールでは、既に適用されている更新と修正が失われることはありません。

3.7 自動実行をサポートする [条件付き要件]

要件

自動実行をサポートする CD、DVD、またはその他のリムーバブル メディアで配布されるゲームの場合、ユーザーが自動実行機能を無効にしていない限り、ディスクが初めて挿入されたときに、アプリケーションは自動的に実行されるか、ユーザーにゲームのインストールを促す必要があります。

アプリケーションが正常にインストールされた後、ディスクをドライブに再度挿入しても、インストールが自動的に再開されないようにする必要があります。 インストールの選択を更新または変更するかどうかをユーザーに確認することは許容されます。

自動実行アプリケーションは、管理者権限を必要とするセットアップ プログラムまたは別のユーティリティを起動することはできますが、昇格を要求するプロンプトを表示してはなりません (つまり、要件 2.1 に従って、マニフェストに asInvoker が含まれている必要があります)。 昇格は、ゲームがインストールされていない場合、またはユーザーが明示的に選択した場合にのみ発生します。

理由

Autorun は、ゲームをプレイするために通常ディスクがドライブに挿入されている必要があるゲームなど、メディア配布アプリケーションの使用を簡素化します。

追加情報

CD または DVD からインストールを起動するために、ユーザーにファイル エクスプローラーでの操作を要求することは許容されません。

複数のディスクで配布されるゲームの場合、理想的には、後続のディスクでは自動実行機能を使用するか、ユーザーにキーを押すなどのアクションを要求せずにインストールを続行する必要があります。

自動実行プログラムを作成するときは、Windows の新規インストール時に必要なすべてのコンポーネントが存在することを確認してください。 一般的なアプリケーションはセットアップによってインストールされるテクノロジに依存しますが、Autorun 自体はそのようなセットアップが行われる前に実行されます。 よくある例としては、Visual C ランタイム DLL が Windows セットアップの一部として含まれていなかったために自動実行プログラムが失敗するというものがあります。 したがって、自動実行プログラムは、アプリケーションのローカル CRT 展開を使用するか、CRT を静的にリンクする必要があります。

Windows Vista より前のバージョンの Windows で使用するために作成された自動実行プログラムでは、.NET ランタイムを使用しないでください。このテクノロジは、Windows XP またはそれ以前のバージョンの Windows には含まれていないためです。 Windows Server 2003 と Windows Vista は、オペレーティング システムの一部として .NET ランタイムを組み込んだ最初の Windows バージョンです。

同様の理由から、Autorun プログラムでは、D3DX9、D3DX10、D3DX11、XAudio2、X3DAudio、XACT、XINPUT、MDX 1.1 などの DirectX SDK オプションのサイドバイサイド コンポーネントの存在を要求できません。

Autorun の使用例については、「AutoRun サンプル」を参照してください。

信頼性

>セキュリティと互換性の要件の概要

顧客メリット

これらの要件により、クラッシュ、ハング、再起動の回数が最小限に抑えられ、アプリケーションの信頼性が向上します。 信頼性要件は、ソフトウェアの予測可能性、保守可能性、回復性、回復可能性を高めるのに役立ちます。

4.1 不要な再起動を排除する

要件

すべてのアプリケーション インストーラーは、システムの再起動を回避するために再起動マネージャー API を利用する必要があります (要件 3.5 を参照)。

ゲームはシャットダウンをブロックしてはなりません。

すべてのアプリケーションは、次のシャットダウン メッセージをリッスンして応答することにより、再起動マネージャーに応答する必要があります。

WM_QUERYENDSESSION と LPARAM = ENDSESSION_CLOSEAPP (0x1)

GUI アプリケーションは、再起動に備えてすぐに応答 (TRUE) する必要があります。

LPARAM を使用した WM_ENDSESSION = ENDSESSION_CLOSEAPP (0x1)

アプリケーションは 5 秒以内に 0 の値を返して閉じる必要があります。

CTRL+C

このメッセージを受信したコンソール アプリケーションはすぐに閉じる必要があります。

理由

システムの再起動は大きな混乱を招きます。 これらはユーザーエクスペリエンスの低下につながるため、最小限に抑える必要があります。 重要なシステム更新などの一部の操作では再起動が必要になる場合があります。 シャットダウン メッセージをリッスンすることで、ゲームやその他のアプリケーションは再起動マネージャーからの要求に迅速に対応できます。 このようにして、有効な再起動要求の不必要な遅延を回避できます。

追加情報

ゲーム インストーラーがカスタム アクションなしで Windows インストーラー テクノロジ (MSI) を使用する場合、この機能は自動的に提供されます。 Microsoft 再配布パッケージも Restart Manager をサポートしています。

再起動マネージャーの詳細については、「再起動マネージャーについて」を参照してください。

4.2 アプリケーション検証の失敗を排除する

要件

ゲームは、Microsoft Application Verifier (AppVerifier) バージョン 4.0 以降で実行され、次のテストでエラーが発生してはなりません。

• 基礎: ハンドル、ヒープ、ロック、メモリ、TLS
• その他: DangerousAPIs、DirtyStacks

理由

AppVerifier は、Windows アプリケーションのクラッシュやハングの原因となる多くの既知の問題や、既知のセキュリティ脆弱性をテストします。

追加情報

Application Verifier の詳細については、「Application Verifier」および「ソフトウェア開発ライフサイクル内での Application Verifier の使用」を参照してください。

この要件は、ネイティブ相互運用性のない純粋なマネージド アプリケーションには適用されません。

これらのテストはリリース ビルドで実行する必要があります。 ビルドをデバッグすると、誤った失敗が発生する可能性があります。 一部の著作権侵害対策および不正行為対策テクノロジーは、AppVerifier の実行を妨げる可能性があります。 したがって、これらのテストは、著作権侵害対策および不正行為対策テクノロジを有効にせずに実行する必要があります。

PageHeap がいっぱいになると実行中のアプリケーションのメモリ負荷が大幅に増加するため、Basics:Heaps テストの Full プロパティを FALSE に設定する必要がある場合があります。 障害は検出されますが、部分的な PageHeap のみを使用する場合は、障害の追跡がより困難になる可能性があります。

ユーザー アカウント制御の要件 2.1 および 3.2 を満たすために、Application Verifier の UAC/LUA 関連のテストを使用する場合は、 Standard User Analyzer を使用して結果を確認する必要があります。 Application Verifier には、その他の便利なテストも多数用意されており、Windows の現在のバージョンおよび将来のバージョンとの高い互換性を確保するために、開発およびテストで使用することを強くお勧めします。 HighVersionLie テストは、要件 2.5 への準拠を確認するために使用されます。

Visual Studio Team System には、デバッグ環境に統合された AppVerifier 機能のサブセットが含まれています。 これは、Basics: Heaps、Handles、および Locks テストの問題を追跡して解決するのに役立つ可能性があります。

4.3 Windowsエラー報告とファイルバージョン情報のサポート

要件

Windows エラー報告のサポートを有効にするには、ゲームが次の要件を満たしている必要があります。

• ゲームは、既知で予期される例外のみを処理する必要があります。 Windows エラー報告を無効にしないでください。 ゲームでアクセス違反などの障害が発生した場合は、Windows エラー報告がクラッシュを報告できるようにする必要があります。
• すべての実行可能ファイル (.exe ファイルや DLL など) には、正確な製品名、会社名、およびファイル バージョンが含まれている必要があります。
• ゲームの通常の終了によって、不明な例外エラーが発生してはなりません。

理由

Windows エラー報告 API は、アプリケーションにおける広範囲にわたるクラッシュやハングを検出するための重要なフィードバックを Microsoft に提供します。 これにより、Microsoft とそのパートナーは、アプリケーションの障害につながるシステムおよびドライバーの問題を迅速に検出し、解決できるようになります。

追加情報

ゲームには、カスタム サポートとレポート機能を実行するためのカスタムの未処理例外ハンドラーを含めることができますが、エラーを ReportFault または WerReportSubmit 関数に渡す必要があります。

適切なファイル バージョン情報は、Windows デスクトップ UI でファイルのプロパティを表示し、バージョン プロパティ ページを確認することで確認できます。

Windows エラー報告 API の詳細と、このサービスの使用時に生成されるクラッシュ ダンプを分析する方法については、DirectX の記事「クラッシュ ダンプの分析」を参照してください。

Xbox 360 Windows 用共通コントローラーの用語

名前	説明
A	A ボタン
B	B ボタン
BACK	戻るボタン
(右/左) バンパー	コントローラーの右上と左上端にあるボタン。 ショルダーボタンに相当します。
方向パッド	コントローラーの方向パッド。
D パッド	方向パッドの略語として認められています。
DP	方向パッドの略語とコントローラーのラベル。
RB, LB	右と左のバンパーの略語とコントローラーのラベル。
RS, LS	右スティックと左スティックの略語とコントローラーのラベル。
RT, LT	右トリガーと左トリガーの略語とコントローラーのラベル。
RSB、 LSB	右スティックと左スティックの略語とコントローラーのラベル。
START	スタートボタン。
(右/左) スティック	コントローラースティック。 以前はサムスティックでした。
(右/左) スティックボタン	コントローラースティックボタン。 以前はサムスティックボタンでした。
(右/左) トリガー	コントローラートリガー。
振動	コントローラーのモーターによって生成されるゲームプレイ フィードバック。 ランブルを使用しないでください。
x	X ボタン
年	Y ボタン。
Windows 用 Xbox 360 コントローラー	Xbox 360 ゲームパッドは、Windows デバイス ドライバー ディスクを含む PC ハードウェア SKU として販売されました。
Windows 用 Xbox 360 ワイヤレス コントローラー	Xbox 360 ワイヤレス ゲームパッドは、Windows デバイス ドライバー ディスクを含む PC ハードウェア SKU として販売されました。

ゲームミドルウェア製品のガイドライン

はじめに

ゲームが Games for Windows プログラムの対象となるには、一連の技術要件を満たす必要があります。 方向パッドの略語として認められています。 このドキュメントでは、ゲームがコンプライアンス テストに合格するためにサードパーティ コンポーネントも満たす必要がある最も一般的な要件について説明します。 インストーラーと完全なゲーム エンジン/制作パッケージでは、これらの要件の多くがこれらのツールの影響を受けるため、Games for Windows の技術要件ドキュメント全体を確認する必要があります。

追加レコメンデーション

コンポーネントが Games for Windows の要件に準拠したタイトルの作成をサポートしていることを確認するだけでなく、Windows ゲーム用のライブラリまたはサポート ユーティリティを設計および展開するときには、考慮すべき事項がいくつかあります。

• 64 ビット ネイティブ x64 アプリケーションで作業する開発者をサポートするには、ライブラリの 32 ビット バージョンと 64 ビット ネイティブ バージョンの両方を提供します。 32 ビット バージョンは、2.2 に従って 64 ビットと互換性がある必要があります。 32 ビット アプリケーション用のライブラリは、LARGEADDRESSAWARE x86 アプリケーション内での使用をサポートするために、32 ビット アドレスの上位ビットが未使用であると想定してはなりません。

• ネイティブ コード (C/C++) ヘッダーを提供する場合は、標準注釈言語 (SAL) 属性構文を使用してパブリック API ルーチンを装飾します。 これにより、ライブラリのユーザーは、Visual Studio Team System 2005、Visual Studio Team System 2008、Visual Studio 2010 Premium、Visual Studio 2010 Ultimate の一部である静的コード分析 (/analyze) や、公開されている Windows SDK コンパイラ ツールを最大限に活用できるようになります。

• 製品がユーザーのプロセス内にスレッドを作成する場合は、デバッグ ツールが実行中のスレッドに適切に注釈を付けることができるように、各スレッドに必ず名前を付けてください。

• ゲームのメイン ループ内で呼び出されるルーチンを作成する場合は、D3DX ルーチン D3DPERF_BeginEvent/EndEvent および D3DPERF_SetMarker を使用して高レベルの操作に注釈を付け、PIX for Windows を使用してボトルネックを簡単に識別できるようにします。

  Note

  Visual Studio 2012 グラフィックス診断機能では、これらの D3DX および PIX ルーチンは ID3DUserDefinedAnnotation インターフェイスに置き換えられます。

• ネットワーク ライブラリについては、Windows XP Service Pack 2、Windows Vista、および Windows 7 で IPv6 および Teredo テクノロジをサポートするために、IP に依存しない実装を提供し、非推奨の IPv4 のみのルーチンを回避します。

• ゲーム サービス プロバイダーは、GDF スキーマ バージョン 2 を使用して Games Explorer に登録し、RSS 機能を使用してサービス関連のニュースを提供する必要があります。

Windows 向けゲームのショーケース

はじめに

Games for Windows ショーケースは、Windows PC 上で安定したゲーム体験を提供するだけにとどまりません。 これらの機能を実装することで、最新の Windows プラットフォームでのゲームユーザー エクスペリエンスがさらに向上します。

Games for Windows タイトルは、この記事に記載されているすべての技術要件を満たす必要がありますが、ショーケース機能はオプションです。 これらのタイトルは、これらのショーケースの一部、またはすべてを自由に実装できます。

S.1 Direct3D 11 の活用

要件

Direct3D 11 は、Windows Vista および Windows 7 向けの次世代レンダリング API です。 Direct3D 11 を活用したゲームは、最適化されたコンテンツ、高度なレンダリング技術、新しいハードウェア機能を使用することで、10、10.1、および 11 をサポートするハードウェア上で魅力的なエクスペリエンスを生み出します。

ゲームに Direct3D 9 も実装されている場合、並べて比較すると、コンテンツの品質、視覚的な忠実度、パフォーマンス、シーンの複雑さ、および Direct3D 11 のグラフィックス忠実度のその他の領域で顕著な改善が見られるはずです。 このサポートは、Games for Windows 技術要件 1.7 の対象となります。

Direct3D 10level9 テクノロジを使用すると、幅広いハードウェア サポートのためにサイドバイサイドの Direct3D 9 実装を使用するのではなく、Windows Vista および Windows 7 で Shader Model 2.0/3.0 Direct3D 9 クラスのビデオ ハードウェアをサポートできます。 しかし、このショーケースを説明するにはこれだけでは不十分です。

Direct3D 11 がインストールされた Windows Vista または Windows 7 を実行しているコンピューターでは、ゲームはデフォルトで Direct3D 11 を使用するようになります。

理由

Direct3D 11 API は、Windows Display Driver Model (WDDM) と Direct3D 10.1 インフラストラクチャを基盤として、ハードウェア テッセレーション、コンピューティング シェーダー、マルチスレッド レンダリングとリソース作成、新しいテクスチャ圧縮形式、より柔軟なシェーダー言語などの新しい機能をサポートします。 Direct3D 11 は、最新世代の Direct3D 11 パーツ、すべての Direct3D 10 および 10.1 ビデオ カード、および多くの Shader Model 2.0/3.0 Direct3D 9 ビデオ カードを含む最新のビデオ カードに対して統合されたハードウェア サポートを提供します。これは、Aero 3D デスクトップに必要な最小限のビデオ ハードウェアです。

追加情報

Direct3D 9 レンダリング エンジンを新しい Direct3D 11 インターフェイスを使用するように移行することは、明確に定義されたタスクです。

• すべての固定機能操作を排除し、プログラム可能なシェーダーを採用します。
• 既存のシェーダーをすべて Shader Model 4.x/5 の新しい構文に更新します。
• 新しいビュー モデルをサポートするためにリソース管理を更新します。
• すべてのアセットを変換して、使用可能な形式の新しいリストを使用します。
• レンダリング状態の処理を更新して不変の状態ブロックを使用し、シェーダー定数を定数バッファーに作り直します。

この変換は Direct3D 11 ショーケースを有効にするために不可欠ですが、結果は新しい API を活用するというショーケースの要件を満たしません。

新しい API と関連する HLSL プログラミング モデルにより、コンテンツを強化するための多くの機会が提供されます。

• ジオメトリ シェーダー、ストリーム出力、テクスチャ配列、BC4/BC5 圧縮テクスチャ形式などの既存の Direct3D 10 ハードウェア機能を活用します。
• 独立したレンダリング ターゲットごとのブレンド モード、MSAA 深度リードバック、MSAA サンプルごとのシェーダー アクセス、キューブ マップ配列、ブロック圧縮 (BC) 形式へのレンダリングなど、既存の Direct3D 10.1 ハードウェア機能を活用します。
• 既存の Direct3D 10/10.1 ビデオ カード (更新されたビデオ ドライバーによって有効化) 上の CS4.x または次世代の Direct3D 11 ビデオ カード上の CS 5.0 で Compute Shader を使用して高度な GPU アルゴリズムを実装します。
• フリースレッド リソース作成と複数のデバイス コンテキストを使用して複数のスレッドでレンダリングし、マルチコア システム (更新されたビデオ ドライバーを使用) でのパフォーマンスを向上します。 詳細については、「Games for Windows Showcase S.3」を参照してください。
• ハル シェーダーとドメイン シェーダーを使用したハードウェア テッセレーションなどの Direct3D 11 クラスのビデオ ハードウェアの新機能を活用した Shader Model 5.0 HLSL シェーダー ハードウェアは、BC6HBC7 圧縮テクスチャ形式とダイナミック シェーダー リンクを備えています。

Direct3D 9 で実装できるテクニック (主に CPU コストが高い) は、効率的に GPU にオフロードできるため、CPU リソースを解放して他のゲームの要求をサポートできます。

Direct3D 11 API、サポート ツール、サンプルは、DirectX SDK で入手できます。 Windows のグラフィックス API も参照してください。

S.2 x64 ネイティブの活用

要件

このゲームには、x64 対応ハードウェアで実行される x64 エディションの Windows によって実現される魅力的な新しいエクスペリエンスを提供する 64 ビットのネイティブ実行可能ファイルが含まれています。 ゲームの 32 ビット バージョンと並べて比較すると、コンテンツの複雑さ、全体​​的な読み込み時間の短縮、パフォーマンスが顕著に改善されていることがわかります。

64 ビット版の Windows では、インストール時に、ゲームエクスプローラーおよび Windows XP Professional x64 Edition のショートカットの既定値として、常にゲームの 64 ビット ネイティブ バージョンが設定されるはずです。 デュアル インストールが必要な場合は、Windows Vista および Windows 7 のゲームエクスプローラーに対して 32 ビット バージョンを指す追加の再生タスクを指定できますが、既定値は 64 ビット ネイティブ バージョンのままにする必要があります。

このショーケースのレコメンデーションを満たすには、ゲームが Windows Vista および Windows 7 の 64 ビット エディションをサポートしている必要があることに注意してください。 Windows XP Professional x64 Edition のサポートは推奨されますが、必須ではありません。

理由

x64 テクノロジーは、既存のアプリケーションに対するフルスピードの 32 ビット下位互換性を含む、コンシューマー市場とサーバー市場の両方に 64 ビット アドレス指定機能を提供します。 x64 は、AMD (AMD64) と Intel (EMT64) の両方にとってロードマップの重要な部分であり、ウルトラモバイル CPU を除いて、現在の世代と将来の世代のすべてのプロセッサのテクノロジをサポートします。

Windows XP Professional x64 Edition は、x64 テクノロジをサポートする最初のコンシューマー向け Windows オペレーティング システム (OS) であり、Windows Vista および Windows 7 では、64 ビット コンシューマー コンピューティング向けの OS 対応の可用性が大幅に拡張されています。 多くの新しいコンピュータでは 2 GB の RAM が標準で搭載されているため、メモリ スケーリングをさらに改善しても、2 GB を超える物理 RAM をアドレス指定できない 32 ビットの個々のアプリケーションにはメリットがありません。 今日の多くのゲームは、特にハイエンド GPU で利用可能な大容量のビデオ メモリと組み合わせると、利用可能なすべてのコンテンツを 2 GB の仮想アドレス空間の制約内に収めるという課題に直面しており、x64 テクノロジに移行すると、サポート可能な詳細レベルが大幅に向上します。

32 ビット ゲームの x64 互換性は Games for Windows の技術要件 (2.2) ですが、新しいテクノロジを最大限に活用するには 64 ビットのネイティブ実装が必要です。

追加情報

64 ビット アドレス指定の主な利点は、2 GB を超える物理メモリと仮想メモリに直接アクセスできることです。 大規模な仮想メモリ アドレス空間により、32 ビット プログラミングでよく見られる VM アドレス空間枯渇の問題を気にすることなく、メモリ マップ I/O を広範囲に使用できます。 ゲームでは、新しいスペースを活用して読み込み時間を大幅に短縮したり、場合によってはコンテンツの読み込みのための一時停止を排除したりできます。

既存の 32 ビット アプリケーションは、Enable Large Addresses (/LARGEADDRESSAWARE) リンカー オプションを使用してビルドすると、完全な 32 ビット データでアドレスを処理できるため、x64 エディションのメリットを享受できます。 Windows XP の 32 ビット バージョンでは、特別なブート モードにより、このようなアプリケーションは最大 3 GB の RAM をアドレス指定でき、x64 エディションでは、Large Address Aware (LAA) アプリケーションに対して最大 4 GB の RAM へのアクセスが提供されます。 32 ビット アプリケーションで LAA を使用すると、このショーケース要件は満たされませんが、このブリッジ テクノロジは、このショーケース要件を完全に実装していない場合に、x64 バージョンの Windows で追加のスケーリングの利点を提供する非常に便利な方法です。

詳細については、ゲーム開発者向け Web サイトの「ゲーム開発者向け 64 ビット プログラミング」および「RAM、VRAM、その他の RAM: 64 ビット ゲームが登場」を参照してください。

Note

このショーケースの主な課題は、ゲームが依存するサードパーティのライブラリまたはコンポーネントが 64 ビットのネイティブ開発で利用できるようにすることです。 多くのレガシー Microsoft API も 64 ビット ネイティブ環境から削除されており、主要システムの古い実装を含むエンジン コード ベースにとっては課題となる可能性があります。

S.3 マルチコアプロセッサの活用

要件

ゲームは、マルチコア プロセッサを活用した機能を実装しており、利用可能な場合は 3、4、またはそれ以上のコアに拡張できます。

ゲームがシングルプロセッサまたはデュアルコア システムをサポートしている場合、クアッドコア システムと並べて比較すると、目に見える新しい機能、追加の魅力的な効果、コンテンツ品質の向上、および/またはパフォーマンスの向上が示されるはずです。

デュアルコア スケーリングは既にゲームで広くサポートされており、さまざまな Direct3D ドライバー拡張機能によって自動的に利用されているため、デュアルコア スケーリングだけではこのショーケースをデモンストレーションするには不十分です。

理由

CPU のパフォーマンスの継続的な向上は、クロック レートの向上から計算コアの追加へと移行しました。 AMD と Intel のロードマップはどちらも、スケーラブルなマルチコア設計に基づいています。 プロセッサの進化におけるこの根本的な変化により、すべての次世代ゲーム プラットフォームにはマルチコア CPU が搭載されています。 シングルスレッド アプリケーションでは、次世代 CPU による大きなメリットは得られなくなります。 一般的に使用される CPU コアの数が 3 個以上に増えると、単純なマルチスレッドも拡張できなくなります。

追加情報

コア数は 2 の累乗である必要はないことに注意してください。ゲームは線形にスケーリングされ、3、4、5、6、7、8 などのコア数を処理できる必要があります。

アプリケーション内のスレッド数を増やすことでスケーリングすると、通信とスレッド同期のコストが抑制されている場合にのみ利益が得られます。 機能ベースのスケーリングは、短期的にはより簡単なソリューションとなる可能性があり、シングルコア システムで追加のスレッドがなくてもゲームを正常に動作させ、追加の CPU パワーが利用可能なときにスレッドを有効にすることができます。

詳細については、DirectX の記事の 「Xbox 360 および Microsoft Windows での複数のコアのコーディング」 および 「Xbox 360 および Microsoft Windows のロックレス プログラミングに関する考慮事項」 のほか、DXUTLockFreePipe ユーティリティと CoreDetection サンプルを参照してください。

Direct3D 11 のフリースレッド リソース作成とデバイス コンテキストを利用すると、グラフィックス リソースのレンダリングと読み込みにおけるマルチコア スケーラビリティを実現するのに役立ちます。 Games for Windows Showcase S.1 を参照してください。

マルチコア システムでタイミングを計算するために Windows API を使用する代わりに、CPU 命令 rdtsc を直接使用すると、一部のハードウェアおよび OS 構成で問題が発生する可能性があることに注意してください。DirectX の記事の 「ゲームのタイミングとマルチコア プロセッサ」 を参照してください。

S.4 Windows 向けゲームのサポート - LIVE

Games for Windows - LIVE は Microsoft によってサポートされなくなりました。

S.5 Windowsタッチをサポート

要件

Windows タッチ対応ゲームは、タッチ ディスプレイを備えた Windows 7 を実行しているコンピューターで、タッチやジェスチャを使用してプレイできます。 キーボード入力も使用できますが、主なプレイ インターフェイスはタッチベースである必要があります。

技術要件 1.4 に従い、タッチを有効にしてもマウスや一般的なコントローラーの使用が妨げられることはありません。

ゲームのインストーラーは Windows Touch 機能をサポートする予定はありません。

理由

マルチタッチ対応のコンピューター用ディスプレイは、ラップトップとデスクトップで利用でき、Windows 7 のリリースで推進されている重要なハードウェア機能を表しています。 Windows 7 は、デスクトップおよび共通コントロール インターフェイス全体で Windows Touch をサポートしています。

追加情報

ネイティブ コード アプリケーションは、 RegisterTouchWindow 関数と組み合わせて、WM_TOUCH メッセージを通じてマルチタッチにアクセスできます。 操作と慣性 API も参照してください。

Windows Presentation Foundation (WPF) 4.0 は、マルチタッチ インターフェイス用の管理ソリューションを提供します。

詳細については、Windows Touch SDK を参照してください。

S.6 ハイカラーをサポート

要件

High Color をサポートするゲームでは、レンダリング バック バッファーと全画面表示モードに 10:10:10:2 (DXGI_FORMAT_R10G10B10A2、D3DFMT_A2B10G10R10) または 16:16:16:16 (DXGI_FORMAT_R16G16B16A16、D3DFMT_A16B16G16R16) 形式が使用されます。

High Color レンダー ターゲットを使用すると、10 ビットまたは 16 ビットの範囲にトーン マッピングを実行するときに、ハイダイナミック レンジ (HDR) コンテンツを拡張または広い色域でレンダリングできます。

理由

CRT ディスプレイが普及していた時代から、モニターは長年にわたり、チャネルあたり 256 色以上の色レベルを表示できました。 ビデオ カードのスキャン出力ハードウェアが制限要因となっていました。 最新の GPU (ほとんどの Direct3D 9 クラスのハードウェアとすべての Direct3D 10 クラス以上のハードウェアを含む) には、少なくともチャネルあたり 10 ビットのスキャンアウト ハードウェアが搭載されており、ハードウェア機能は将来的にカラー チャネルあたり 16 ビットまで拡張される予定です。 HD TV 相互接続システム (HDMI、DisplayPort) もチャネルあたり 8 ビット以上を処理できるように設計されており、アナログ VGA はすでにそのような信号を伝送します。

追加情報

High Color または Hi Color は、歴史的には 256 (8 ビット) カラー ディスプレイから 15 ビットまたは 16 ビット カラー ディスプレイへの移行を指します。 ほとんどのディスプレイ システムは、すでに 24 ビット カラー、つまり赤、緑、青の各カラー チャネルあたり 8 ビットの True Color に移行しています。 ここでの High Color とは、個々のカラー チャネルごとに 8 ビット以上で動作できる新世代のディスプレイ システムを意味します。 ディープカラーとも呼ばれます。

推奨されるベストプラクティス

はじめに

技術要件を満たし、タイトルに 1 つ以上のショーケースを採用することに加えて、すべての Windows ゲームで従うべきベスト プラクティスがいくつかあります。 これらのレコメンデーションはコア技術要件の範囲外ですが、すべての Games for Windows タイトルに適用することを強くお勧めします。

追加レコメンデーション

• 最新の Visual Studio コンパイラとランタイムを使用します。 新しいバージョンのコンパイラでは、生成されるコードの品質とセキュリティの問題が大幅に改善され、最新のプロセッサ最適化戦略が採用されています。 コンパイラを更新し、最新の C ランタイムを使用すると、最新のコーディング手法に簡単に移行できます。
• 静的リンクではなく、C ランタイムのダイナミック リンク ライブラリ (DLL) バージョンを使用し、セキュア CRT を活用します。 (自動実行プログラムやインストーラー自体など、特別な事前インストールの場合には例外が認められる場合があります)。
• ゲーム オーディオの場合は、DirectSound ではなく、XAudio2、X3DAudio、XACT を使用します。 すべてのミキシングとソース レート変換を実行し、オーディオ出力に低遅延ソリューションのみを必要とするオーディオ エンジンの場合は、Windows XP (のみ) では DirectSound を使用し、Windows Vista および Windows 7 では WASAPI を使用します。
• レガシー API や非推奨の API (DirectDraw、DirectSound、DirectPlay、DirectMusic のパフォーマンス レイヤー、DirectPlay Voice、Direct3D Retained Mode) の使用は避けてください。 DirectPlay Voice および Direct3D Retained Mode は、Windows Vista または Windows 7 ではまったく使用できないことに注意してください。 DirectPlay および DirectMusic のパフォーマンス レイヤーは、x64 ネイティブ アプリケーションでは使用できません。
• SSE/SSE2 SIMD 命令セットを使用して最適化します。 SIMD に最適化された数学演算のクロスプラットフォーム ソリューションとして、Windows SDK の DirectXMath API を参照してください。
• Windows セキュリティの最新のベスト プラクティスを使用します (/NXCOMPAT、 /GS、 /SAFESEH、 /DYNAMICBASE、 /SDLなどのコンパイラおよびリンカー オプションを含む)。 詳細については、 ゲーム開発におけるセキュリティのベストプラクティスを参照してください。
• 最新の Windows SDK コンポーネントとライブラリを使用します。 D3DX9、D3DX10、D3DX11 などの従来の DirectSetup で展開された帯域外コンポーネントへの依存関係を削除します。 DirectXTex または DirectXTK あるいはその両方の使用を検討してください。
• 古い HLSL コンパイラーの使用を避け、代わりに最新の HLSL コンパイラーを使用してください。 アプリケーションで Pixel Shader 1.x のサポートが必要な場合は、HLSL ではなくシェーダー アセンブリを使用するか、古いコンパイラの使用をそれらのシナリオのみに制限します。

リソース

用語	説明
Windows 向けゲーム: テストケース	Windows XP、Windows Vista、Windows 7 でのゲームのベスト プラクティス
Windows SDK	Windows SDKs
ユーザーアカウント制御ガイドライン	ユーザー アカウント制御の互換性に関する Windows Vista アプリケーション開発要件
DirectX 開発者ポータル	Directx 開発者センター
Windows 向けゲームと DirectX SDK ブログ	Windows と DirectX SDK 向けのゲームに関するブログ
DirectX に関する追加記事	DirectX 技術記事