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

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

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

• Windows 8の違い
  • 追加情報
• Windows 用ゲーム
  • 1.1 Games Explorer の統合
  • 1.2 家族の安全/保護者のコントロールをサポートする
  • 1.3 豊富な保存済みゲームをサポート
  • 1.4 Windows 用 Xbox 360 Common Controller をサポートする [条件付き要件]
  • 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 Common Controller for Windows の用語
• ゲーム ミドルウェア製品のガイドライン
  • はじめに
  • その他の推奨事項
  • Windows ショーケース用ゲーム
• リソース

Windows 8の違い

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

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

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

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

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

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

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 Common Controller のサポート」を参照してください。

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

Windows 7 で実行されるゲームは、Windows 8 x86 および x64 プラットフォームで正しく動作する必要があります。

「2.2 Windows x64 バージョンのサポート」を参照してください。

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

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

DirectX End-User再配布パッケージは、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) を必要とするゲームでは、引き続き既存の展開メカニズムが使用されます

これらのゲームは、(ネットワーク アクセスを必要とする) .NET 3.5 ランタイムを自動的に有効にするために、Windows 8でアプリケーションの互換性動作をトリガーします。 ただし、.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) のみが存在すると想定できます。 既定では、.NET 4.0 互換ランタイムのみがWindows 8に存在します。

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

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

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

「4.2 アプリケーション検証ツールのエラーを排除する」を参照してください。

追加情報

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

Windows 用ゲーム

ゲームの要件の概要

お客様の特典

コンピューター ゲームは Windows の主要なエンターテイメント エクスペリエンスですが、使いやすさに関する懸念が長年にわたって顧客の不満を引き起こしてきました。 従来、ゲームはアプリケーションのようにインストールされますが、エンターテイメント メディア (映画や曲など) に似ています。 Games Explorer などのイノベーションは、標準アプリケーションとは異なる一貫した方法でゲームを公開します。 これらのイノベーションにより、Windows でゲームの一流の市民状態が、音楽と画像と共に提供されます。 次の要件は、Windows Vista と Windows 7 が、改善され、よりアクセシビリティが高く、統一されたゲーム エクスペリエンスを提供するのに役立ちます。 同時に、Windows XP との互換性を確保します。

1.1 Games Explorer の統合

要件

ゲームは、Windows Vista および Windows 7 の Games Explorer ( Games フォルダー) 内に表示されている必要があります。 選択すると、ゲームには、公開元、開発者、リリース日、バージョン、Windows Experience Index スコア、評価 (該当する場合)、関連するハイパーリンクなど、適切なメタデータも表示する必要があります。

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

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

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

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

根拠

Windows ゲーム エクスプローラーの概念は、Windows XP フォルダー の [マイ ドキュメント] または [ マイ ピクチャ] と似ています。 同じようなコンテンツを 1 か所で一元化し、組織や状況依存のアクティビティをより簡単にできるようにすることが考えられます。 Games Explorer は、ゲームをより充実した編成と制御できるようにすることで、 マイ ドキュメント または マイ ピクチャ の概念を拡張します。 Games Explorer を使用すると、ゲーマーはシステムにインストールされているすべてのゲームを表示、整理、操作できます。 また、ゲームパブリッシャーは重要なゲーム情報をより効果的に伝えることもできます。 このシステムはデータ駆動型であるため、ゲーム発行元は製品の有効期間にわたってゲーム情報を簡単に更新できます。

追加情報

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

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

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

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 で [スタート] メニュー プログラム グループ、ショートカット、デスクトップ アイコンを自由に作成できます。 このような関連アプリケーションは、Windows の要件に該当するゲームに合格する必要があります。詳細については、「 ゲーム ミドルウェア製品のガイドライン」を参照してください。 ゲーム サービスは、Windows 7 用ゲーム プロバイダーとして Games Explorer に登録することをお勧めします。 1

1.2 家族の安全/保護者のコントロールをサポートする

要件

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

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

根拠

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

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

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

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

追加情報

評価のないゲームは、引き続き Standard ユーザーとしてのプレイをサポートし、 VerifyAccess を呼び出す要件を満たしている必要があります。 このようなゲームは既定で [評価なし] カテゴリに設定され、ゲーム エクスプローラーに "評価なし" というテキストが表示され、評価されていないゲームのペアレンタル コントロールの [ゲーム制限] 設定の対象となります。 既定の [制限] 設定は [許可] です。

GDF 内の評価情報は、含まれているバイナリが正しく Authenticode 署名されていない場合は無視されます。 要件 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 では "Unrated" と表示されます。

新しい評価データは、サポートされていないオペレーティング システムのバージョンでは無視されます。 PEGI (フィンランド) バリアントは、標準の PEGI (ヨーロッパ) 評価システムを優先して非推奨になりました。 OFLC システムは、オーストラリアの COB-AU を優先して非推奨になりました。

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

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

1.3 豊富な保存済みゲームをサポート

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

1.4 Windows 用 Xbox 360 Common Controller をサポートする [条件付き要件]

要件

ゲームパッド コントローラーをサポートするゲームでは、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 を使用せずに高解像度のマウスの移動情報を取得する方法の詳細については、「 High-Definitionマウス移動の活用」を参照してください。

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 を使用することを強くお勧めします。 「Windows ショーケース S.1 用ゲーム」を参照してください。 Direct3D 10 または Direct3D 11 の要求は、要件 1.7 に完全に準拠しています。

1.8 高 DPI 対応を有効にする

要件

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

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

根拠

高品質の液晶モニターは、コンピューターのディスプレイとして一般的であり、ネイティブ解像度 (通常は 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 対応のマニフェスト要素で誤った警告が生成されることに注意してください。 これを解決するには、Mt.exeを Windows SDK から最新バージョンに更新します。

Visual Studio 2010 には、dpiaware.manifest などのファイルを必要とすることを排除するプロジェクト プロパティの [ DPI 認識を有効にする] という名前の設定が含まれています。 [構成プロパティとマニフェスト ツール] を展開し、[入力&出力] を選択して、[DPI 認識を有効にする] を探します。

Windows では、従来の表示モードの既定値は 96 DPI で、CRT モニターでは一般的でした。

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

セキュリティと互換性

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

お客様の特典

次の要件により、ゲームの全体的なセキュリティが向上し、さまざまなアーキテクチャ、異なる構成、および異なるモードで Windows を使用できるようになります。

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

要件

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

            <requestedExecutionLevel>

要件 1.2 に従って、メイン ゲームと自動実行実行可能ファイルは、Standard ユーザー コンテキストをサポートするために 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 マニフェスト要素で誤った警告が生成されることに注意してください。 これを解決するには、Mt.exeを Windows SDK から最新バージョンに更新します。

インストール、修正プログラムの適用、および削除の特殊なケースの詳細については、要件 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 の修正プログラムを有効にすることをお勧めします。 詳細については、「 User Account Control (UAC) Patching」を参照してください。

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

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 Service Pack を追加するだけで正常に動作するソフトウェアの問題を引き続き作成します。

DirectX ランタイムの脆弱なバージョン チェック比較ロジックでは、さまざまなバージョンの Windows で実行すると、多数の失敗したインストールが作成されました。 DirectX のバージョン番号は、オペレーティング システムのコア コンポーネントにのみ適用されます。 多くのゲームで使用されている Side-by-side DirectX SDK コンポーネントには適用されません。

追加情報

インストーラーで OS の最小バージョンがチェックされるのが一般的です。 ただし、このチェックは、単純な等価性ではなく、より大きいか等しいかどうかをテストし、オペレーティング システムの特定のバージョンにロックするように注意して行う必要があります。 アプリケーション検証ツールの HighVersionLie テストを使用すると、OS バージョン番号の大幅な変更にインストーラーがどのように対応するかを迅速かつ簡単に判断できます。

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

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

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

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

要件

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

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

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

根拠

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

追加情報

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

詳細については、「 高速ユーザー切り替え」を参照してください。 ユーザーの時間が稼働しているときにペアレンタルコントロールの時間制限が有効になっている場合、高速ユーザー切り替えが行われることに注意してください。 詳細については、要件 1.2 を参照してください。

2.7 長い名前のサポート

要件

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

ユーザーが長いユーザー名を持っている場合、ゲームは正常に動作する必要があります。

根拠

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

追加情報

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

インストール

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

お客様の特典

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

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

要件

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

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

インストールと削除には管理者権限が必要な場合があります。 更新プログラムの適用には、更新の頻度に応じて、管理者資格情報の入力を求めるメッセージが必要な場合があります。 ゲームの通常のプレイでは、要件 2.1 に従って、管理者権限を必要としてはなりません。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 Firewall for Game Developers 」および FirewallInstallHelper サンプルを参照してください。

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

3.3 フォルダーを正しくインストールする

要件

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

根拠

ユーザーは、必要な場所にアプリケーションを柔軟にインストールできる必要があります。 また、ファイルの既定の場所と一貫性があり、セキュリティで保護されたエクスペリエンスが必要です。

追加情報

ゲームでは、さまざまな既知のフォルダーの場所 (CSIDL_LOCAL_APPDATA や CSIDL_COMMON_APPDATA で指定されたものなど) を利用して、大量のゲーム データを格納し、実行可能ファイルをサポートして、高度なオンデマンド インストールと修正プログラムの適用シナリオを実装できます。

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

3.4 Windows リソースを正しくインストールする

要件

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

根拠

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

追加情報

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

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

3.5 インストール中に再起動を回避する

要件

再配布パッケージからの Windows コンポーネントのインストールには再起動が必要であると想定しないでください。再起動は、戻り値の結果または Microsoft のドキュメントによって示されない限りです。

ゲーム インストーラーが常に再起動を強制する場合は、Microsoft によって承認される必要があります。

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

根拠

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

追加情報

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

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

要件

ゲームインストールプログラムは、最新のファイルバージョンがインストールされていることを正しく確認する必要があります。 ゲームをインストールすると、生成しないファイルや、生成しないアプリケーションで共有されているファイルがリグレッションされることはありません。

根拠

多くの場合、共有コンポーネントとシステム コンポーネントは、セキュリティ修正と拡張機能のために更新されます。 以前のバージョンの更新済みコンポーネントを含むインストールでは、既に適用されている更新プログラムと修正プログラムが失われる可能性はありません。

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

要件

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

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

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

根拠

自動実行を使用すると、メディア分散アプリケーションを使用するエクスペリエンスが簡略化されます。たとえば、通常、ゲームをプレイするためにディスクがドライブに存在する必要があるゲームなどです。

追加情報

ユーザーが CD または DVD からインストールを起動するためにエクスプローラー内を移動するように要求することは許容されません。

複数のディスクに配布されているゲームの場合、後続のディスクは、オートラン機能を使用するか、ユーザーにキーを押すか、他のアクションを実行するように求めずにインストールを続行するのが理想的です。

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

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

同様の理由から、自動実行プログラムでは、D3DX9、D3DX10、D3DX11、XAudio2、X3DAudio、XACT、XINPUT、MDX 1.1 などの DirectX SDK オプションのサイド バイ サイド コンポーネントが存在する必要はありません。

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

[信頼性]

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

お客様の特典

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

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

要件

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

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

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

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

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

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

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

Ctrl + C

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

根拠

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

追加情報

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

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

4.2 アプリケーション検証ツールの障害を排除する

要件

このゲームでは、次のテストで、Microsoft Application Verifier (AppVerifier) バージョン 4.0 以降で実行されているエラーを生成する必要はありません。

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

根拠

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

追加情報

アプリケーション検証ツールの詳細については、MSDN の「 アプリケーション検証ツール 」および「 ソフトウェア開発ライフサイクル内でのアプリケーション検証ツールの使用 」を参照してください。 アプリケーション検証ツールは、「ダウンロードの詳細: Microsoft ダウンロード センターの アプリケーション検証ツール」 からダウンロードできます。

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

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

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

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

Visual Studio Team System には、デバッグ環境に統合された AppVerifier 機能のサブセットが含まれています。 これは、基本: ヒープ、ハンドル、ロックテストに関する問題を追跡して解決する場合に役立ちます。

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

要件

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

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

根拠

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

追加情報

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

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

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

Windows 用 Xbox 360 Common Controller の用語

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

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

はじめに

ゲームが Windows 用ゲーム プログラムの対象となるには、技術的な要件の一覧を満たす必要があります。 タイトル (実行可能ファイル、DLL、ドライバーなど) が付属しているサード パーティ製コンポーネントも、ゲームの資格を得るためにこれらの要件を満たす必要があります。 このドキュメントでは、ゲームがコンプライアンス テストに合格するためにサード パーティのコンポーネントも満たす必要がある最も一般的な要件について説明します。 インストーラーと完全なゲーム エンジン/運用パッケージは、これらの要件の多くがこれらのツールの影響を受けるので、Windows 用ゲームの技術要件に関する完全なドキュメントを確認する必要があります。

その他の推奨事項

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

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

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

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

• ゲームのメイン ループ内で呼び出すことを目的としたルーチンを記述する場合は、D3DX ルーチン D3DPERF_BeginEvent/EndEvent を使用し、D3DPERF_SetMarkerを使用して、WINDOWS 用 PIX を使用してボトルネックを簡単に特定できるように、高レベルの操作に注釈を付けます。

  Note

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

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

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

Windows ショーケース用ゲーム

はじめに

Windows 用ゲームショーケースは、Windows PC で確かなゲーム体験を提供する以外にも行きます。 これらの機能を実装することで、ゲームは最新の Windows プラットフォームのユーザー エクスペリエンスにさらに興奮を加えることができます。

Windows タイトル用のゲームは、この記事に記載されているすべての技術的な要件を満たす必要がありますが、ショーケース機能は省略可能です。 これらのタイトルは、これらのショーケースの一部、なし、またはすべてを自由に実装できます。

S.1 Exploit Direct3D 11

要件

Direct3D 11 は、Windows Vista および Windows 7 用の次世代レンダリング API です。 Direct3D 11 を利用するゲームでは、最適化されたコンテンツ、高度なレンダリング手法、および新しいハードウェア機能を使用して、10、10.1、11 をサポートするハードウェアで魅力的なエクスペリエンスを作成します。

ゲームに Direct3D 9 も実装されている場合、サイド バイ サイド比較では、コンテンツの品質、視覚的な忠実性、パフォーマンス、シーンの複雑さ、Direct3D 11 のグラフィックス忠実度のその他の領域の知覚可能な改善を示す必要があります。 このサポートは、Windows 用ゲーム技術要件 1.7 の対象となります。

Direct3D 10level9 テクノロジを使用すると、広範なハードウェアサポートに Side-by-side Direct3D 9 実装を使用するのではなく、Windows Vista および Windows 7 でシェーダー モデル 2.0/3.0 Direct3D 9 クラスのビデオ ハードウェアをサポートできます。 ただし、このショーケースを示すには十分ではありません。

Direct3D 11 がインストールされている Windows Vista または Windows 7 を実行しているコンピューターでは、ゲームは既定で Direct3D 11 を使用する必要があります。

根拠

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

追加情報

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

• プログラミング可能なシェーダーを優先して、すべての固定関数操作を排除します。
• 既存のすべてのシェーダーをシェーダー モデル 4.x/5 の新しい構文に更新します。
• 新しいビュー モデルをサポートするようにリソース管理を更新します。
• すべてのアセットを変換して、使用可能な形式の新しいリストを使用します。
• 変更できない状態ブロックを使用するようにレンダリング状態処理を更新し、シェーダー定数を定数バッファーに修正します。

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

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

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

Direct3D 9 で実装できる手法 (主に高い CPU コストを通じて) を効率的に GPU に読み込むため、CPU リソースを解放して他のゲームの需要をサポートできます。

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

S.2 Exploit x64 Native

要件

このゲームには、x64 対応ハードウェアで実行されている x64 エディションの Windows で有効になっている魅力的な新しいエクスペリエンスを提供する 64 ビットネイティブ実行可能ファイルが含まれています。 32 ビット 版のゲームと並べて比較すると、コンテンツの複雑さ、全体的な読み込み時間の短縮、パフォーマンスの向上が認識可能であることを示す必要があります。

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

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

根拠

x64 テクノロジは、コンシューマーとサーバーの両方の市場に対して 64 ビットのアドレス指定機能を提供します。これには、既存のアプリケーションに対してフルスピードの 32 ビット後方互換性が含まれています。 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 ビットの個々のアプリケーションにはメリットがありません。 今日の多くのゲームでは、利用可能なすべてのコンテンツを 2 GB の仮想アドレス空間の制約に適合させる課題に直面しています。特に、ハイエンド GPU で利用可能な大規模なビデオ メモリと組み合わせると、x64 テクノロジに移行すると、サポート可能な詳細レベルが大幅に向上します。

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

追加情報

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

既存の 32 ビット アプリケーションは、大きなアドレスを有効にする (/LARGEADDRESSAWARE) リンカー オプションを使用してビルドするときに、完全な 32 ビット データでアドレスを処理する機能を備えることで、x64 エディションのメリットを得ることができます。 32 ビット バージョンの Windows XP では、特別なブート モードを使用すると、このようなアプリケーションで最大 3 GB の RAM に対処でき、x64 エディションでは、L アドレス対応 (LAA) アプリ用に最大 4 GB の RAM にアクセスできます。 32 ビット アプリケーションでの LAA の使用は、このショーケースの要件を満たしていませんが、このブリッジ テクノロジは、このショーケース要件を完全に実装していないユーザーに対して、x64 バージョンの Windows で追加のスケーリングの利点を提供する非常に便利な方法です。

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

Note

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

S.3 Exploit Many-Core Processors

要件

このゲームでは、マルチコア プロセッサを利用し、使用可能な場合は 3 つ、4 つ以上のコアにスケーリングする機能を実装します。

ゲームがシングルプロセッサまたはデュアルコア システムをサポートしている場合、クアッド コア システムとのサイド バイ サイド比較では、知覚可能な新機能、追加の説得力のある効果、コンテンツ品質の向上、パフォーマンスの向上を示す必要があります。

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

根拠

CPU のパフォーマンスの継続的な増加は、クロック レートの向上から計算コアの追加に切り替わりました。 AMD と Intel の両方のロードマップは、スケーラブルなマルチコア設計に基づいています。 次世代のゲームプラットフォームはすべて、プロセッサの進化におけるこの根本的な変化のためにマルチコアCPUを備えています。 シングルスレッド アプリケーションでは、次世代 CPU の大幅な向上はなくなりました。 また、一般的に使用される CPU コアの数が 3 つ以上に増えるにつれて、単純なマルチスレッドもスケーリングに失敗します。

追加情報

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

アプリケーション内のスレッドの数を増やすことによるスケーリングは、通信とスレッドの同期のコストが確認された場合にのみ戻り値を提供します。 機能ベースのスケーリングは、短期的にはより簡単なソリューションであることが証明される可能性があり、単一コア システム上の追加スレッドなしでゲームを正常に動作させ、追加の CPU 電力が使用可能になったときにそれらを有効にできます。

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

Direct3D 11 のフリー スレッド リソース作成とデバイス コンテキストを使用すると、グラフィックス リソースのレンダリングと読み込みにおいて多くのコアスケーラビリティを実現するのに役立ちます。 「Windows 用ゲーム ショーケース S.1」を参照してください。

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

Windows 用 S.4 サポート ゲーム - LIVE

Windows 用ゲーム - LIVE は Microsoft ではサポートされなくなりました。

S.5 Windows Touch のサポート

要件

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

タッチを有効にして、技術的な要件 1.4 に従って、マウスまたは一般的なコントローラーの使用を妨げないようにする必要があります。

このゲームのインストーラーでは、Windows Touch 機能はサポートされていません。

根拠

コンピューター用のマルチタッチ対応ディスプレイは、ノート PC とデスクトップで使用でき、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 ビット範囲へのトーン マッピングを実行するときに、High-Dynamic範囲 (HDR) コンテンツを拡張または広色域でレンダリングできます。

根拠

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

追加情報

高色 (Hi Color) は、従来、256 (8 ビット) のカラー ディスプレイから 15 ビットまたは 16 ビットのカラー ディスプレイに移行することを指します。 ほとんどのディスプレイ システムは、24 ビットカラーの True Color に移動してから長く、赤、緑、青の場合はカラー チャネルあたり 8 ビットです。 ここでハイカラーとは、個々のカラーチャンネルあたり8ビット以上で動作できる新世代のディスプレイシステムを意味します。 はディープ カラーとも呼ばれます。

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

はじめに

技術要件を満たすだけでなく、タイトルに 1 つ以上のショーケースを採用するだけでなく、すべての Windows ゲームに従う必要があるベスト プラクティスがいくつかあります。 これらの推奨事項は、主要な技術要件の範囲外ですが、Windows タイトルのすべてのゲームに使用することを強くお勧めします。

その他の推奨事項

• 最新の Visual Studio コンパイラとランタイムを使用します。 新しいバージョンのコンパイラでは、生成されたコードの品質とセキュリティの問題に対して大幅な改善が実装され、最新のプロセッサ最適化戦略が採用されています。 コンパイラを更新し、最新の C ランタイムを使用することは、最新のコーディング プラクティスに簡単に移行する方法です。
• 静的リンクではなく、C ランタイムのダイナミック リンク ライブラリ (DLL) バージョンを使用し、Secure CRT を使用します。 (例外は、自動実行プログラムやインストーラー自体など、特別なプレインストールの場合に行うことができます)。
• ゲーム オーディオの場合は、DirectSound ではなく、XAudio2、X3DAudio、または XACT を使用します。 すべてのミキシングとソースレート変換を行い、オーディオ出力に低遅延のソリューションのみを必要とするオーディオ エンジンの場合は、Windows Vista および Windows 7 の Windows XP (のみ) と WASAPI の DirectSound を使用します。
• 従来の API と非推奨の API (DirectDraw、DirectSound、DirectPlay、DirectMusic のパフォーマンス レイヤー、DirectPlay Voice、Direct3D 保持モード) は使用しないでください。 DirectPlay Voice と Direct3D 保持モードは、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 コンパイラを使用してください。 アプリケーションでピクセル シェーダー 1.x のサポートが必要な場合は、HLSL ではなくシェーダー アセンブリを使用するか、古いコンパイラの使用をこれらのシナリオのみに制限します。

リソース

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