適用於 Windows 技術需求的遊戲：Windows XP、Windows Vista、Windows 7 和 Windows 8 上遊戲的最佳做法

發行項
01/10/2024

本文提供在 Windows 上執行之遊戲的技術需求和最佳做法。我們撰寫了這些技術需求和最佳做法，主要是涵蓋 Windows Vista 和 Windows 7，以及舊版 Windows XP 操作系統。這些最佳做法通常也適用於 Windows 8 上的桌面 Win32 遊戲。

本文包含下列各節：

Windows 8 的差異
- 其他資訊
適用於 Windows 的遊戲
安全性和相容性
安裝
可靠性
適用於 Windows 術語的 Xbox 360 通用控制器
遊戲中間件產品的指導方針
資源

Windows 8 的差異

以下是將這些技術需求和最佳做法套用至 Windows 8 時的主要差異摘要。

無法看見遊戲總管 UI

您向遊戲總管註冊的所有遊戲都會顯示為新 Windows UI 中的圖格，但與標題相關聯的大部分元數據都不再顯示。您仍然使用遊戲定義檔案製作工具（GDFMAKER.EXE），現在可在 Windows 軟體開發工具包（SDK）中取得，以撰寫元數據。您也可以使用現有的機制來部署元數據。繼續使用 Windows 7 來測試遊戲總管註冊，並在 Windows 8 上安裝新的 Windows UI 圖格時確認其顯示（請參閱 1.1 遊戲總管整合）。

若要下載 Windows 8 SDK，請參閱下載以開發傳統型應用程式。

使用遊戲總管 API 註冊仍然是向 Windows 家長監護註冊遊戲的機制

建議您在發行的 Windows 8 版本上執行 Windows SDK 版本的 GDFMAKER，以確保它可以填入所有目前支援的評等系統。

注意

此 GDFMAKER 版本需要 .NET 4.0。

請參閱 1.2 支援家庭保管庫/家長監護。

根據您的需求，現在有三種使用 XINPUT API 的選項

XINPUT 1.4 內建於 Windows 8。 Windows 市集應用程式和桌面 Win32 應用程式都可以使用 XINPUT 1.4。所有版本的 Windows 都可以針對簡化的通用控制器使用 XINPUT 9.1.0，但沒有使用 XINPUT 9.1.0 的轉散發套件。所有版本的 Windows 也可以使用現有的 DirectX SDK 1.3 版 XINPUT 1.3，這需要部署 DirectSetup。

請參閱 1.4 支援適用於 Windows 的 Xbox 360 通用控制器。

Windows RT 僅支援一組有限的桌面 Win32 應用程式

在 Windows 7 上執行的遊戲可以在 Windows 8 x86 和 x64 平台上正確執行。

請參閱 2.2 支援 Windows x64 版本。

請確定已正確完成任何 OS 檢查

Windows 8 OS 版本為 6.2 。 Windows 8 通過我們建議用於遊戲部署的目前最低列測試。

DirectX 終端使用者轉散發套件在 Windows 8 上成功執行，就像在 Windows 7 上一樣，部署 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 運行時間。

注意

舊版 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 資料夾[我的檔] 或 [我的圖片]。 其概念是將類似的內容集中到一個地方，並允許更輕鬆的組織與內容相關活動。遊戲總管藉 由允許更豐富的組織和控制遊戲，來擴充「我的檔 」或 「我的圖片 」概念。遊戲總管可讓玩家檢視、組織及與安裝在其系統上的所有遊戲互動。它也允許遊戲發行者更有效地傳達重要的遊戲資訊。系統會以數據驅動，讓遊戲發行者在產品生命週期中輕鬆更新遊戲資訊。

其他資訊

與遊戲總管整合需要您撰寫遊戲定義檔（GDF），這是內嵌在二進位檔（可執行檔或 DLL）作為資源的 XML 文字檔，以及 Windows 圖示。然後，遊戲必須向遊戲總管註冊。 GDF 也可讓您暴露提供的資訊，例如遊戲標題、發行者、開發人員、網站鏈接和選擇性工作。請注意，支援工作只能連結至網站，但播放工作也可以用於選擇性支援工作。

遊戲總管可以使用縮圖位圖影像，但建議您改為提供具有大型圖示的 Windows 圖示資源（256 256）。圖示資源應包含 256 256 48 48、32 32 和 16 16 的影像大小，包括 24 位（True Color）和 8 位（256）色彩深度。 Visual Studio 2008 和 2010 中提供的圖示編輯器支援這些大型圖示格式，IconWorkshop Lite 也一樣。

DirectX SDK 中提供與 Windows Games Explorer 整合的詳細數據。 DirectX SDK 包含遊戲定義檔（GDF）編輯器，以及範例 GDFExampleBinary 中包含的範例 GDF。另一個範例 GameUxInstallHelper 提供將必要功能整合到現有安裝系統的例程。遊戲定義檔驗證程式（gdftrace.exe）提供評估 GDF 的偵錯支援。另請參閱適用於 C++ 的 DirectX SDK 檔中的「Windows 遊戲總管整合」。

Windows 7 引進 GDF 檔案架構的第二個版本支援。新版本包含簡化的方法來建立遊戲工作，並支援更新通知、遊戲服務提供者、遊戲統計數據，以及遊戲服務提供者的 RSS 摘要。最新版的 GameUxInstallHelper 會處理搭配 Windows Vista 使用第 2 版 GDF 檔案所需的所有註冊和舊版支援。從 2009 年 8 月或更新版本使用 DirectX SDK 的工具和範例程式代碼。建議使用第 2 版 GDF 檔案來啟用 RSS 摘要、遊戲統計數據和更新通知的支援。此外，請參閱 ProviderGDFExampleBinary 和 GameStatisticsExample 範例。

在 Windows Vista Business Edition、Windows 7 專業版 Edition 和 Windows Vista 和 Windows 7 的 Enterprise Edition 上，會隱藏 [開始] 功能表上的遊戲連結。遊戲總管仍可在 [開始] 功能表上按兩下 [所有程式]，然後按兩下 [遊戲]。

針對隨遊戲一起安裝但不是本身遊戲的相關聯應用程式，您可以在所有版本的 Windows 上建立 [開始] 功能表程式群組、快捷方式和桌面圖示，包括 Windows Vista 和 Windows 7。這類相關聯的應用程式應傳遞適用於 Windows 需求的遊戲;如需詳細資訊，請參閱遊戲中間件產品的指導方針。鼓勵遊戲服務向遊戲總管註冊為 Windows 7 的遊戲提供者。 1

1.2 支援家庭保管庫/家長監護

需求

遊戲必須完全支援 Windows 系列保管庫遵循下列規則：

遊戲不得要求使用者具有系統管理認證才能播放。安裝、修補和移除可能需要系統管理認證，但受限於第 3 節中的需求。（與此相關是需求 2.1，請遵循用戶帳戶控制指導方針。
由 Windows 支援的評等面板評等遊戲，例如 ESRB 和 PEGI，必須在其遊戲定義檔（GDF）中包含其指派的評等資訊。所有可用的評等數據都必須包含在 GDF 的每個當地語系化版本，以及語言中性版本。
遊戲必須在 GDF 中列出其可執行檔，以提供一般應用程式限制的良好用戶體驗，除非遊戲使用在運行時間建立隨機命名可執行檔的反盜版技術。
如果可用，遊戲必須在啟動期間呼叫 Games Explorer 介面的 VerifyAccess 方法，並在它傳回 *pfHasAccess 為 FALSE 時結束。

理由

所有遊戲都必須在標準用戶帳戶的內容中執行，以允許由 Windows 家長控制所控制的帳戶進行遊戲。父母希望能夠監視和控制孩子進入遊戲的能力。此外，許多行業、政府和宣導團體希望有更好的方法允許父母監視和控制他們孩子接觸的遊戲。搭配遊戲總管所提供的架構，Microsoft 透過 Windows 家長監護提供這項功能。

即使對於不參與評等棋盤計劃的遊戲，要求提高的許可權也會為大多數用戶帳戶創造糟糕的遊戲體驗。特別是如果啟用家長監護功能，這會要求家長在每次啟動遊戲時輸入系統管理員密碼。

Windows 家長監護系統可讓家長選取他們認為適合子女的分級。家長監護支援許多全球分級系統。家長控制也允許家長根據內容描述元限制對遊戲的存取（如果適用的分級系統支持它們），並允許或不允許存取個別遊戲。

Windows 家長監護的預設評等系統選擇是以系統的地區設定為基礎，但可由控制台 中的地區和語言選項中的使用者修改。因此，每個支援的語言都應該提供所有可用的評等數據，讓使用者可以自由選取他們想要的任何評等面板。

其他資訊

沒有評等的遊戲仍然必須符合支援以標準使用者身分進行遊戲的需求，並呼叫 VerifyAccess。這類遊戲預設為 [未分級] 類別，在遊戲總管中顯示「未提供評等」文字，並受限於未分級遊戲的家長監護中的遊戲限制設定。預設 的限制 設定為 [允許]。

如果包含的二進位檔未正確簽署 Authenticode，則會忽略 GDF 中的評等資訊。請參閱需求 2.3。

DirectX SDK 中的遊戲定義檔案編輯器包含所有支援的評等系統，並將此資訊正確地復寫到 GDF 的所有當地語系化版本，以及語言中性版本。 GDFTrace 工具會譯碼並驗證所有評分資訊。使用這些工具的 2009 年 8 月版本或更新版本。

遊戲提供者的 GDF 通常不包含評等資訊，而且會受限於未評分內容的設定。

作業系統	支援的評等系統
Windows Vista	CERO（日本） ESRB （美國） OFLC（澳大利亞） PEGI （歐洲）佩吉芬蘭（已淘汰） PEGI 葡萄牙 PEGI/BBFC（英國） USK （德國）
具有 Service Pack 的 Windows Vista	適用於 Windows Vista 的 Service Pack 新增下列支援： GRB（韓國） ESRB “Mild” 變體內容描述元
Windows 7	Windows 7 支援 Windows Vista 支持的評等系統，並新增下列支援： CSRR（臺灣）
Windows 8	Windows 8 支援先前的評等系統，並新增下列支援： COB-AU（澳大利亞） DJCTQ （巴西） PFB （南非） OFLC-NZ（紐西蘭） Windows 8 已淘汰下列已淘汰系統的支援： PEGI-FI （芬蘭） OFLC（澳大利亞）

注意

任何包含新 ESRB Windows Vista Service Pack 1 （SP1）內容描述項的標題，都會在不含 Service Pack 的 Windows Vista 上顯示為未分級。

較新的評等數據會在操作系統版本上忽略，而不支援這些數據。 PEGI（芬蘭）變體現在已被取代，有利於標準PEI（歐洲）評級系統。 OFLC系統現在已被取代，有利於澳大利亞的COB-AU。

如需讓遊戲與標準使用者許可權相容的詳細資訊，請參閱 DirectX 文章遊戲開發人員的用戶帳戶控制。

如需遊戲定義檔（GDF）的詳細資訊，請參閱需求 1.1。

1.3 支援豐富儲存的遊戲

[此需求已淘汰]

1.4 支援適用於 Windows 的 Xbox 360 通用控制器 [條件式需求]

需求

支援遊戲板控制器的遊戲必須使用 XInput API 支援適用於 Windows 的 Xbox 360 控制器。如果也支援 DirectInput 周邊，也可以使用 DirectInput。不過，如果使用 Xbox 360 相容裝置，XInput 必須是預設 API。

通用控制器觸發程式和按鈕的所有參考都必須使用 Xbox 360 名稱。如需詳細資訊，請參閱適用於 Windows 術語的 Xbox 360 通用控制器清單。

當遊戲處於暫停或暫停狀態時，必須關閉控制器震動。

滑鼠/鍵盤控件無法隨時完全停用。至少必須有一個選項可以返回遊戲功能表。

理由

這項需求可讓玩家自由選擇使用 Xbox 360 控制器或鍵盤和滑鼠，視輸入法更自然且直覺的介面而定。

其他資訊

這項需求不適用於只使用滑鼠和/或鍵盤的遊戲。

建議您實作功能表導覽，以使用廣泛接受的標準控制器按鈕：

A - 接受
B - 取消
開始 - 接受或暫停
上一頁 - 取消、備份一個畫面或向上功能表層級

如需詳細資訊，請參閱 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 呼叫 EnumDisplay 來取得桌面解析度設定。

如需詳細資訊，請參閱 DirectX 文章的 10 英呎體驗簡介 Windows 遊戲開發人員的長寬螢幕小節。

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 上以 1600 1200 的顯示器解析度測試 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 包含專案屬性中名為 Enable DPI Awareness 的設定，可免除 dpiaware.manifest 等檔案的需求。展開 [組態屬性] 和 [指令清單工具]，然後選取 [輸入與輸出]，以尋找 [啟用 DPI 感知]。

在 Windows 上，傳統顯示模式預設為 96 DPI，這適用於 CRT 監視器。

當全螢幕應用程式變更顯示解析度時，通常會在設定緩衝區和顯示矩形時使用視窗訊息和計量。 DPI 虛擬化會導致這些全螢幕顯示模式出現裁剪，而宣告 DPI 感知會防止這些問題。如需詳細資訊，請參閱撰寫 DPI 感知 Win32 應用程式。

安全性和相容性

安全性和相容性需求的摘要

客戶權益

下列需求可改善遊戲的整體安全性，並協助確保它們在不同的架構、不同組態和不同模式下，使用 Windows。

2.1 遵循用戶帳戶控制指導方針

需求

每個可執行檔（也就是每個擴展名為 .exe 的檔案）都必須包含內嵌指令清單，其中包含下列標記來定義其執行層級：

            <requestedExecutionLevel>

根據需求 1.2，主要遊戲和自動執行可執行文件必須具有 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 64 上的 Windows （WOW64）允許 32 位程式代碼在 64 位版本的 Windows 上執行，因此應用程式在 64 位版本的 Windows 上不需要原生 64 位程式代碼。 16 位程序代碼不會在64位版本的 Windows 上執行。

不需要維護與 Windows XP Professional x64 Edition 的相容性，但強烈建議使用。

如需詳細資訊，請參閱遊戲開發人員的64位程序設計。

2.3 簽署檔案

需求

所有可執行的程式代碼檔案（通常是擴展名為 .exe 或 .dll 的檔案）都必須使用公開有效的 Authenticode 憑證簽署，而且必須具有有效的時間戳伺服器 URL 才能進行生產簽署。

如果您的遊戲使用 Windows Installer，則必須簽署安裝程式套件檔案（.msi 檔案）。

理由

簽署檔案可協助用戶決定是否信任應用程式，並確保使用者檔案未遭到竄改。它也允許應用程式在鎖定的環境中正常執行。

其他資訊

如需詳細資訊，請參閱遊戲開發人員的 Authenticode 簽署。

如果您的遊戲使用 Windows Installer，建議您藉由包含 MsiPatchCertificate 數據表來啟用 UAC/LUA 修補。如需詳細資訊，請參閱用戶帳戶控制（UAC）修補。

我們不建議簽署封包（.cab）檔案，除非檔案相對較小（小於 100 MB）。

2.4 簽署驅動程式

需求

遊戲所安裝的任何內核模式驅動程式都必須使用公開有效的 Authenticode 憑證簽署。

遊戲所安裝的任何內核模式硬體設備驅動器都必須具有 Microsoft 簽章，該簽章可以從 Windows 硬體質量實驗室（WHQL）或從驅動程式可靠性簽章（DRS）程式取得。

理由

撰寫不佳或惡意代碼驅動程式可能會嚴重影響系統的穩定性和安全性。在 64 位版本的 Windows Vista 和 Windows 7 上，未簽署的驅動程式不會載入。此原則也可以針對 32 位版本的 Windows Vista 和 Windows 7 啟用。

其他資訊

每個需求 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 版本號碼僅適用於核心操作系統元件。它不適用於許多遊戲所使用的並存 DirectX SDK 元件。

其他資訊

查看安裝程序檢查最低 OS 版本相當常見。不過，這項檢查必須謹慎完成，以確保其測試是否大於或等於，而不是簡單的相等，從而鎖定特定版本的操作系統。使用應用程式驗證器的 HighVersionLie 測試是一種快速且簡單的方法，可判斷您的安裝程式對 OS 版本號碼的重大變更的反應。

適當地使用 DirectX 運行時間轉散發套件（DirectX Setup）牽涉到一律在安裝期間啟動它，最好是在無訊息模式中啟動它。這可讓 Microsoft 提供的程式碼執行任何必要的版本更新。它也允許安裝任何選擇性的並存 DirectX SDK 元件，例如 D3DX、XACT、MDX 或 XInput。

如需部署 DirectX 執行時間的最佳做法，請參閱遊戲開發人員的 DirectX 安裝。

建議針對 Service Pack 2 或更新版本支援 Windows XP 檢查的遊戲，因為 Service Pack 2 （SP2）和 Service Pack 3 （SP3）提供顯著的安全性改進、簡化的 DirectX 運行時間轉散發需求，以及極廣泛的部署。支援 Windows XP 的大多數現代 Microsoft 技術都需要 SP2 或 SP3（XAudio2、適用於 Windows 的遊戲 - LIVE 等等）。

2.6 支援並行用戶會話

需求

依賴 3D 圖形的遊戲不需要透過遠端桌面連線運作，但在遊戲失敗時，用戶必須收到警示。

遊戲必須遵循下列規則，以支持標準的 Windows 多任務案例：

遊戲不得封鎖使用並行用戶會話。
當遊戲已在另一個會話中執行時，遊戲必須在新的使用者會話中執行。
當另一位使用者在不同會話中處於作用中狀態時，不得在一個用戶會話中聽到遊戲音效。
遊戲必須支援快速用戶切換。
遊戲不得嘗試停用標準工作切換。遊戲不得停用 ALT+TAB 鍵盤快捷方式。遊戲可以停用輔助功能鍵盤快捷方式，如停用遊戲中的快捷鍵中所述。

理由

Windows 使用者應該能夠執行並行會話，而不會發生衝突或中斷。這是由家庭、室友或其他人員共用之 Windows 計算機的常見案例。

其他資訊

若要測試遊戲是否在遠端會話中啟動，請呼叫 GetSystemMetrics（SM_REMOTESESSION）。非零值表示會話是遠端的。

如需詳細資訊，請參閱快速使用者切換。請注意，當使用者的時間已啟動時，如果啟用家長監護時間限制，就會發生快速使用者切換。如需詳細資訊，請參閱需求 1.2。

2.7 支援長名稱

需求

如果遊戲支援儲存盤案，它必須能夠儲存具有長名稱和路徑的檔案。遊戲必須正確處理特殊檔案系統字元，例如 \ / * ？ “， <>在用來建立檔名或路徑的任何使用者輸入欄位中。

當使用者具有長用戶名稱時，遊戲必須正常運作。

理由

玩家習慣在基礎操作系統支援的深層路徑上使用長名稱。

其他資訊

長名稱會定義為包含 Windows SDK 中所定義之最大值的名稱。

安裝

安全性和相容性需求的摘要

客戶權益

如果應用程式使用官方系統元件散發方法，客戶可以確信應用程式會在 Windows 上安裝，而不會降低操作系統或其他應用程式。簡化的安裝體驗可為遊戲提供更容易存取且無問題的全新體驗。

3.1 支援簡易安裝

需求

遊戲必須藉由實作下列專案，在設定使用者介面中提供簡化的路徑：

最多顯示一個 EULA 提示。
默認安裝路徑必須略過安裝的所有選取專案（例如安裝資料夾或元件選取專案）、假設預設選項，然後在安裝成功時執行遊戲或啟動器，而不需其他提示。如有需要，可以針對進階組態選項提供自定義安裝選項。
使用正確的 Microsoft 轉散發套件安裝任何必要的作業系統元件（例如 DirectX 和 Visual C 運行時間）。安裝應該以無訊息方式執行，而不需要提示，也不需要受到元件版本檢查的防護。
針對遊戲應用程式和產生的工作檔案，透過控制台中的程式和功能提供移除。 建議您選擇刪除使用者所建立的任何資料檔。拿掉程式必須確保移除所有已安裝的檔案，並清除所有設定（例如防火牆例外狀況清單專案和登錄機碼）。不得移除轉散發的作業系統元件。
如果遊戲需要將例外狀況新增至 Windows 防火牆，安裝程式可能會提示使用者通知使用者需要這項變更。安裝開始之前應該會出現此提示。

安裝和移除可能需要系統管理許可權。根據更新的頻率，修補可能需要提示系統管理認證。遊戲的正常遊戲不得要求系統管理許可權，每個需求 2.1 遵循用戶帳戶控制指導方針。

理由

輕鬆安裝是 Windows 遊戲開發理念，其設計目的是簡化和簡化在執行 Windows 作業系統的電腦上安裝遊戲有時乏味且令人困惑的程式。藉由利用一組技術和最佳做法來輕鬆安裝，可降低在 Windows 計算機上安裝遊戲的不必要複雜度和感知風險。

主要目標是：

減少進入遊戲並開始遊戲的時間量。
將對話框數目和選項減少為極少數或無，以簡化遊戲安裝體驗。

有些傳統安裝會提示允許非功能性安裝，即使應用程式似乎已成功安裝也一樣。例如，遊戲可能需要使用者接受EULA。接著會安裝遊戲，然後會出現 DirectX EULA。此 EULA 可讓使用者拒絕，因而略過 DirectX 執行時間的安裝。此案例可能會導致因為缺少元件而無法執行的遊戲。

其他資訊

如需遊戲安裝、非傳統遊戲安裝技術、UAC 相容的修補解決方案，以及處理頻繁修補的詳細資訊，請參閱下列 DirectX 文章：

注意

拿掉使用者特定的產生的數據檔，應該只針對目前使用者和一般共用使用者位置執行。即使移除需要系統管理認證，也無法掃描系統以移除其他使用者的特定檔案。

3.2 支援安裝用戶帳戶控制

需求

遊戲安裝程式不得假設它正在與使用者相同的內容中執行。使用者特定位置會與安裝程式和播放機不同，即使是因為系統管理員認證提升而讓單一用戶系統使用。因此，當遊戲第一次執行時，它必須執行使用者特定的工作，與安裝程式分開執行。

當使用者裝載或加入多人遊戲時，不得顯示 [Windows 防火牆例外狀況] 對話框。任何必要的設定都必須在安裝時間完成。安裝指示應通知使用者，此作業將會在安裝期間發生。

遊戲安裝程序必須提供內嵌指令清單，以指定所需的執行層級，每個需求 2.1 遵循使用者帳戶控制指導方針。

如果安裝程式在安裝完成後啟動遊戲，則必須在原始使用者的內容中啟動遊戲。

理由

Windows Vista 中 Windows 作業系統的最大變更之一是新增使用者帳戶控制（UAC），預設會執行許可權降低的應用程式。因此，安裝程式必須據以管理許可權等級。 Windows 7 也廣泛使用 UAC。雖然 Windows 7 可改善 UAC 的用戶體驗，但安裝程式仍必須符合與 Windows Vista 相同的需求，才能正常運作，而不需要依賴可能混淆的虛擬化行為。

根據預設，UAC 在 Windows Vista 和 Windows 7 上為使用中，而且絕大多數客戶（88% 或更多根據意見反應）會讓此功能保持啟用。

其他資訊

如需設定 Windows 防火牆的詳細資訊，請參閱適用於遊戲開發人員的 Windows 防火牆和 FirewallInstallHelper 範例的 DirectX 文章。

如果標準使用者啟動安裝，且安裝程式需要系統管理許可權，安裝程式需要系統管理許可權，則安裝程式無法在安裝程序結束時符合此需求的最後一個層面（也就是提示系統管理員認證）。它也會繼承系統管理許可權，這是潛在的安全性風險。相反地，安裝程式啟動程式載入器應該在從安裝程式成功叫用后啟動遊戲。如需詳細資訊，請參閱 MSDN Magazine 文章：教導您的應用程式使用 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 Installer 套件中包含的檔案使用對話框必須包含一個選項，才能自動關閉應用程式，並在安裝程式完成之後嘗試重新啟動它們。

理由

在安裝之後重新啟動系統對用戶來說並不方便，而且通常不需要。

其他資訊

如需詳細資訊，請參閱使用 Windows Installer 搭配重新啟動管理員。

3.6 正確使用檔案版本設定

需求: 遊戲安裝程序必須正確檢查，以確保已安裝最新的檔案版本。安裝遊戲絕不必須回歸您未產生或由您不產生之應用程式共用的任何檔案。
理由: 共用元件和系統元件通常會更新，以取得安全性修正和擴充功能。包含舊版更新元件的安裝不應導致已套用的更新和修正程式遺失。

3.7 支援自動執行 [條件式需求]

需求

對於在 CD、DVD 或其他支援自動執行的卸載式媒體上散發的遊戲，第一次插入光碟時，應用程式必須自動執行或提示使用者安裝遊戲，除非使用者已停用自動執行功能。

成功安裝應用程式之後，在磁碟驅動器中重新插入光碟不會導致安裝再次自動開始。可以接受詢問使用者是否想要更新或變更其安裝選擇。

自動執行應用程式不得提示提高許可權（也就是說，每個需求 2.1 的指令清單中都必須有 asInvoker，不過它可以啟動安裝程式或其他需要系統管理許可權的公用程式。只有在未安裝遊戲，或用戶特別選取它時，才會發生提高許可權。

理由

自動執行可簡化使用媒體分散式應用程式的體驗，例如通常要求磁碟驅動器中有光碟才能玩遊戲的遊戲。

其他資訊

用戶無法接受流覽檔案總管從 CD 或 DVD 啟動安裝。

針對在多個光碟上散發的遊戲，後續光碟最好是使用自動執行功能或繼續安裝，而不會提示使用者按下按鍵或採取其他動作。

撰寫自動執行程式時，請確定 Windows 全新安裝上存在所有必要的元件。一般應用程式依賴安裝程式所安裝的技術，但自動執行本身會在發生任何這類設定之前執行。其中一個常見範例是自動執行程式失敗，因為Visual C Runtime DLL並未包含在 Windows 安裝程式中。因此，自動執行程式必須使用應用程式本機CRT部署，或必須以靜態方式連結CRT。

在 Windows Vista 之前針對 Windows 版本撰寫的自動執行程式不應該使用 .NET 運行時間，因為這項技術未隨附於 Windows XP 或舊版 Windows 中。 Windows Server 2003 和 Windows Vista 是 Windows 的第一個版本，可包含 .NET 運行時間做為其操作系統的一部分。

基於類似的原因，自動執行程式不一定需要 DirectX SDK 選擇性並存元件，例如 D3DX9、D3DX10、D3DX11、XAudio2、X3DAudio、XACT、XINPUT 和 MDX 1.1。

如需使用自動執行的範例，請參閱 AutoRun 範例。

可靠性

安全性和相容性需求的摘要

客戶權益

這些需求可藉由將當機、停止回應和重新啟動的數目降到最低，讓應用程式更可靠。可靠性需求可協助確保軟體更可預測、可維護、復原且可復原。

4.1 消除不必要的重新啟動

需求

所有應用程式安裝程式都必須利用重新啟動管理員 API 以避免系統重新啟動（請參閱需求 3.5）。

遊戲不得封鎖關機。

所有應用程式都必須接聽並回應下列關機訊息，以回應重新啟動管理員：

WM_QUERYENDSESSION與 LPARAM = ENDSESSION_CLOSEAPP （0x1）: GUI 應用程式必須立即回應（TRUE），才能準備重新啟動。
使用 LPARAM = ENDSESSION_CLOSEAPP WM_ENDSESSION （0x1）: 應用程式必須在 5 秒內傳回 0 值，然後關閉。
CTRL+C: 接收此訊息的主控台應用程式必須立即關閉。

理由

系統重新啟動是重大中斷。它們會導致用戶體驗不佳，而且應該最小化。某些作業，例如重大系統更新可能需要重新啟動。藉由接聽關機訊息，遊戲和其他應用程式可以立即回應重新啟動管理員的要求。如此一來，他們就可以避免在有效的重新啟動要求中不必要的延遲。

其他資訊

如果遊戲安裝程式使用 Windows Installer 技術（MSI）而沒有任何自定義動作，則會自動提供此功能。 Microsoft 轉散發套件也支援重新啟動管理員。

如需重新啟動管理員的詳細資訊，請參閱 MSDN 關於重新啟動管理員一文。

4.2 消除應用程式驗證器失敗

需求

在下列測試中，遊戲不得在 Microsoft 應用程式驗證器（AppVerifier） 4.0 版或更新版本中產生任何失敗：

基本概念：句柄、堆積、鎖定、記憶體、TLS
其他：DangerousAPIs、DirtyStacks

理由

AppVerifier 會測試許多導致 Windows 應用程式中當機和停止回應的已知問題，以及已知的安全性弱點。

其他資訊

如需應用程式驗證器的詳細資訊，請參閱應用程式驗證程式和在軟體開發生命週期內使用應用程式驗證器。

此需求不適用於沒有原生 Interop 的純受控應用程式。

這些測試應在發行組建上執行。偵錯組建可能會產生錯誤的失敗。某些反盜版和反作弊技術可能會干擾AppVerifier的執行。因此，在沒有啟用反盜版和反作弊技術的情況下，應該執行這些測試。

您可能需要將 Basics：Heaps 測試的 Full 屬性設定為 FALSE，因為完整 PageHeap 會大幅增加執行中應用程式的記憶體壓力。仍然會偵測到失敗，但如果您只使用部分 PageHeap，可能會更難以追蹤。

如果您在應用程式驗證器中使用 UAC/LUA 相關測試來符合使用者帳戶控制需求 2.1 和 3.2，您應該使用標準使用者分析器來檢閱結果。應用程式驗證器也提供許多其他有用的測試，強烈建議您在開發和測試中使用，以確保與目前和未來的 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 通用控制器

名稱	描述
A	A 按鈕。
B	B 按鈕。
BACK	[上一頁] 按鈕。
（右/左）保險杠	控制器右上方和左邊緣的按鈕。相當於肩部按鈕。
方向板	控制器方向板。
D-pad	已接受方向板的縮寫。
DP	方向板縮寫和控制器標籤。
RB、LB	右和左保險杠縮寫和控制器標籤。
RS、LS	左右遊戲桿縮寫和控制器標籤。
RT、LT	左右觸發程式縮寫和控制器標籤。
RSB、LSB	左右遊戲桿縮寫和控制器標籤。
START	[開始] 按鈕。
（右/左）棒	控制器桿。以前是遊戲桿。
（右/左）遊戲桿按鈕	控制器遊戲桿按鈕。先前的遊戲桿按鈕。
（右/左）觸發程式	控制器觸發程式。
震動	控制器馬達所產生的遊戲意見反應。請勿使用朗姆。
X	X 按鈕。
Y	Y 按鈕。
適用於 Windows 的 Xbox 360 控制器	Xbox 360 遊戲板以計算機硬體 SKU 銷售，包括 Windows 裝置驅動程式光碟。
適用於 Windows 的 Xbox 360 無線控制器	Xbox 360 無線遊戲板以電腦硬體 SKU 銷售，包括 Windows 裝置驅動程式光碟。

遊戲中間件產品的指導方針

簡介

若要讓遊戲符合 Windows 遊戲計劃資格，他們必須符合技術需求清單。任何隨附標題的第三方元件（可執行檔、DLL、驅動程式等等）也必須符合遊戲資格的這些需求。本檔強調遊戲第三方元件必須符合的最常見需求，才能通過合規性測試。安裝程式和完整的遊戲引擎/生產套件應該檢閱 Windows 技術需求的完整遊戲檔，因為這些需求有許多都會受到這些工具的影響。

其他建議

除了確保您的元件支援建立符合適用於 Windows 遊戲之遊戲需求的標題之外，在設計及部署 Windows 遊戲的連結庫或支援公用程式時，您應該考慮一些其他考慮。

若要支援 64 位原生 x64 應用程式的開發人員，請同時提供 32 位和 64 位原生版本的連結庫。 32 位版本必須每 2.2 個 64 位相容。 32 位應用程式的連結庫不應該假設任何 32 位位址的高位未使用，以支援在 LARGEADDRESSAWARE x86 應用程式中使用。
如果您提供原生程式代碼（C/C++）標頭，請使用標準註釋語言（SAL）屬性語法來裝飾您的公用 API 例程。這可讓使用者使用靜態程序代碼分析（/分析），這是Visual Studio Team System 2005、Visual Studio Team System 2008、Visual Studio 2010 進階版和 Visual Studio 2010 Ultimate 的一部分，以及公開提供的 Windows SDK 編譯程式工具。
如果您的產品會在用戶的進程內建立線程，請務必命名每個線程，讓偵錯工具可以正確地標註執行中的線程。
如果您撰寫的例程是要在遊戲的主要循環內呼叫，請使用 D3DX 例程D3DPERF_BeginEvent/EndEvent，並D3DPERF_SetMarker批注高階作業，以更輕鬆地識別使用適用於 Windows 的 PIX 的瓶頸。

注意

針對 Visual Studio 2012 圖形診斷功能，這些 D3DX 和 PIX 例程會由 ID3DUserDefinedAnnotation 介面取代。
針對網路連結庫，請提供IP中性實作，並避免僅使用已取代的IPv4例程來支援 Windows XP 中的 IPv6 和 Teredo 技術與 Service Pack 2、Windows Vista 和 Windows 7。
遊戲服務提供者應該使用 GDF 架構的第 2 版向遊戲總管註冊自己，並使用 RSS 功能來提供服務相關的新聞。

適用於 Windows 展示的遊戲

簡介

適用於 Windows 的遊戲展示超越在 Windows 電腦上提供穩固的遊戲體驗。藉由實作這些功能，遊戲可以在最新的 Windows 平臺上為用戶體驗增添更多興奮。

Windows 遊戲標題必須滿足本文所列的所有技術需求，但展示功能是選擇性的。這些標題是免費的，可以實作一些、無或全部的展示。

S.1 惡意探索 Direct3D 11

需求

Direct3D 11 是適用於 Windows Vista 和 Windows 7 的下一代轉譯 API。利用 Direct3D 11 的遊戲會使用優化的內容、進階轉譯技術和新的硬體功能，在支援 10、10.1 和 11 的硬體上建立令人信服的體驗。

如果遊戲也實作 Direct3D 9，則並存比較應該示範可感知的內容品質、視覺逼真度、效能、場景複雜度，以及 Direct3D 11 圖形逼真度的其他區域。這項支援受限於 Windows 技術需求 1.7 的遊戲。

Direct3D 10level9 技術可用來支援 Windows Vista 和 Windows 7 上的著色器模型 2.0/3.0 Direct3D 9 類別視訊硬體，而不是使用並存 Direct3D 9 實作進行廣泛的硬體支援。不過，這不足以展示這個展示。

在執行 Windows Vista 或已安裝 Direct3D 11 的 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 9 轉譯引擎以使用新的 Direct3D 11 介面是定義完善的工作：

排除所有固定函式作業，以利於可程式化著色器。
將所有現有的著色器更新為著色器模型 4.x/5 的新語法。
更新資源管理以支援新的檢視模型。
將所有資產轉換為使用新的可用格式清單。
更新轉譯狀態處理以使用不可變的狀態區塊，並將著色器常數重新處理成常數緩衝區。

這項轉換對於啟用 Direct3D 11 展示至關重要，雖然結果不符合探索新 API 的展示需求。

新的 API 和相關聯的 HLSL 程式設計模型提供許多增強內容的機會：

利用現有的 Direct3D 10 硬體功能，例如幾何著色器、串流輸出、紋理陣列和 BC4/BC5 壓縮紋理格式。
利用現有的 Direct3D 10.1 硬體功能，例如獨立的個別轉譯目標混合模式、MSAA 深度回讀、MSAA 個別取樣著色器存取、Cube 地圖陣列，以及轉譯成區塊壓縮格式（BC）格式。
在現有的 Direct3D 10/10.10.1 視頻卡上實作使用計算著色器搭配 CS4.x 的進階 GPU 演算法，或在新一代 Direct3D 11 視頻卡上啟用 CS 5.0。
使用自由線程資源建立和多個裝置內容在多個線程上轉譯，以改善多核心系統上的效能（已更新的視訊驅動程式）。如需詳細資訊，請參閱 Windows 展示專案 S.3 的遊戲。
利用 Direct3D 11 類別視訊硬體的新功能，例如具有殼層和網域著色器的硬體鑲嵌、著色器模型 5.0 HLSL 著色器硬體功能BC6HBC7壓縮紋理格式，以及動態著色器連結。

可以使用 Direct3D 9 實作的技術（主要是透過高 CPU 成本）以有效率的方式載入 GPU，從而釋放 CPU 資源以支援其他遊戲需求。

Direct3D 11 API、支援工具和範例可在 DirectX SDK 中使用。另請參閱 Windows 中的圖形 API。

S.2 惡意探索 x64 原生

需求

遊戲包含一個64位原生可執行檔，可提供 x64 版本 Windows 在支援 x64 硬體上執行的令人信服的新體驗。與遊戲 32 位版本的並存比較應該會顯示內容複雜度、降低整體負載時間和效能的可感知改善。

在 64 位版本的 Windows 上，安裝應該一律將遊戲的 64 位原生版本設定為遊戲總管和 Windows XP Professional x64 版本中快捷方式的預設值。如果需要雙重安裝，則可以針對 Windows Vista 上的遊戲總管和 Windows 7 指定額外的播放工作，指向 32 位版本，但預設值應維持為 64 位原生版本。

請注意，遊戲應該支援 64 位版本的 Windows Vista 和 Windows 7，以符合此展示建議。建議支援 Windows XP Professional x64 版本，但並非必要。

理由

x64 技術為消費者和伺服器市場提供64位尋址功能，其中包含現有應用程式的全速32位回溯功能。 x64 是 AMD （AMD64）和 Intel （EMT64）藍圖的關鍵部分，除了超行動 CPU 之外，還支援所有目前和未來世代處理器的技術。

Windows XP Professional x64 Edition 是第一個支援 x64 技術的消費者導向 Windows 操作系統（OS），Windows Vista 和 Windows 7 可大幅擴大 64 位消費者運算的 OS 啟用可用性。由於許多新電腦上的 RAM 標準為 2 GB，記憶體調整的進一步改善將無法讓無法處理超過 2 GB 實體 RAM 的 32 位個別應用程式受益。現今許多遊戲都面臨著將所有可用內容納入 2 GB 虛擬位址空間的限制的挑戰，特別是結合高端 GPU 上可用的大型視訊記憶時，並大幅提升到 x64 技術可支持的詳細程度。

32 位遊戲的 x64 相容性是適用於 Windows 技術需求的遊戲（2.2），但充分利用新技術需要 64 位原生實作。

其他資訊

64 位尋址的主要優點是能夠直接存取超過 2 GB 的實體和虛擬記憶體。大型虛擬記憶體位址空間可讓您廣泛使用記憶體對應 I/O，而不必擔心 32 位程序設計中普遍存在的 VM 位址空間耗盡問題。遊戲可以利用新的空間來大幅改善載入時間，或在某些情況下，排除載入內容的暫停。

現有的 32 位應用程式可以在使用啟用大型位址（/LARGEADDRESSAWARE）連結器選項建置時，透過完整 32 位數據來處理位址，以受益於 x64 版本。在 32 位版本的 Windows XP 上，特殊開機模式允許這類應用程式處理高達 3 GB 的 RAM，而 x64 版本則提供最多 4 GB 的 RAM 存取權給大型位址感知（LAA）應用程式。雖然在32位應用程式中使用LAA不符合此展示需求，但此網橋技術對於未完全實作此展示需求的人來說，在 x64 版本的 Windows 上提供額外的縮放優勢是非常有用的方法。

如需詳細資訊，請參閱遊戲開發人員和 RAM、VRAM 和更多 RAM 的 64 位程序設計：64 位遊戲位於遊戲開發人員網站。

注意

此展示專案的關鍵挑戰是確保遊戲依賴的任何第三方連結庫或元件都可供 64 位原生開發使用。許多舊版 Microsoft API 也已從 64 位原生環境中排除，這可以證明引擎程式代碼基底的挑戰，其中包含舊版密鑰系統的實作。

S.3 惡意探索多核心處理器

需求

遊戲會實作利用多核心處理器、調整為 3、4 或更多核心的功能，當可用時。

如果遊戲支援單處理器或雙核心系統，則與四核心系統的並存比較應該示範可感知的新功能、額外的引人注目效果、改善內容品質及/或改善效能。

由於遊戲已經廣泛支援雙核心調整，以及各種 Direct3D 驅動程序增強功能自動使用，因此雙核心調整不足以示範此展示。

理由

CPU 效能持續成長已從時鐘速率改善切換到新增計算核心。 AMD 和 Intel 藍圖都是以可調整的多核心設計為基礎。所有新一代遊戲平臺都有多核心 CPU，因為這在處理器演進過程中發生了根本性轉變。單個線程應用程式將不再看到來自新一代 CPU 的重大收益。簡單的多線程也會無法調整，因為一般用途中的 CPU 核心數目會成長為三個以上。

其他資訊

請注意，核心計數不一定是兩個電源，因此遊戲應該以線性方式調整，並處理核心計數 3、4、5、6、7、8 等等。

藉由增加應用程式中的線程數目來調整，只有在通訊和線程同步處理的成本保持檢查時，才會提供傳回。功能型調整在短期內可能會證明較容易的解決方案，讓遊戲在單一核心系統上沒有額外的線程正常運作，並在額外的 CPU 電源可用時加以啟用。

如需詳細資訊，請參閱 DirectX 文章中的 Xbox 360 和 Microsoft Windows 和適用於 Xbox 360 和 Microsoft Windows 的無鎖定程式設計考慮，以及 DXUTLockFreePipe 公用程式和 CoreDetection 範例。

利用 Direct3D 11 自由線程資源建立和裝置內容，有助於在轉譯和載入圖形資源方面實現多核心延展性。請參閱 Windows 展示專案 S.1 的遊戲。

請注意，直接使用 CPU 指令 rdtsc，而不是使用 Windows API 在多核心系統上計算計時，可能會導致某些硬體和 OS 設定發生問題：請參閱 DirectX 文章中的遊戲計時和多核心處理器。

S.4 支援 Windows 遊戲 - LIVE

適用於 Windows 的遊戲 - Microsoft 不再支援 LIVE。

S.5 支援 Windows Touch

需求

Windows 觸控遊戲可在執行 Windows 7 且觸控顯示器的電腦上使用觸控和/或手勢進行遊戲。鍵盤輸入也可以使用，但主要播放介面必須是觸控式介面。

啟用觸控不應防止使用滑鼠或通用控制器，受限於技術需求 1.4。

遊戲的安裝程式不應支援 Windows Touch 功能。

理由

適用於電腦的多觸控顯示器適用於膝上型計算機和桌面計算機，它們代表隨著 Windows 7 版本升級的主要硬體功能。 Windows 7 支援整個桌面和通用控件介面的 Windows Touch。

其他資訊

原生程式代碼應用程式可以透過WM_TOUCH訊息與 RegisterTouchWindow 函式一起存取多點觸控。另請參閱操作和慣性 API。

Windows Presentation Foundation （WPF） 4.0 提供多點觸控介面的受控解決方案。

如需詳細資訊，請參閱 Windows Touch SDK。

S.6 支援高色彩

需求

支援高色彩的遊戲會使用 10：10：10：2（DXGI_FORMAT_R10G10B10A2、D3DFMT_A2B10G10R10）或 16：16：16：16：16（DXGI_FORMAT_R16G16B16A16、D3DFMT_A16B16G16R16）格式來轉譯後台緩衝區和全屏幕顯示模式。

藉由使用高色彩轉譯目標，高動態範圍（HDR）內容可以在對10位或16位範圍執行音調對應時，以延伸或寬廣的範圍來轉譯。

理由

多年來，即使CRT顯示器普遍存在，監視器仍能夠顯示每個通道超過256個色彩等級。視訊卡上的掃描硬體是限制因素。新式 GPU，包括大多數 Direct3D 9 級硬體，以及所有 Direct3D 10 類別和更好的硬體，具有每個通道至少 10 位的掃描硬體，而硬體功能在未來會設定為每色通道 16 位。 HD 電視互連系統（HDMI，DisplayPort）也設計為處理每個通道超過8位，類比VGA已經攜帶此類訊號。

其他資訊

請注意，高色彩或Hi Color，從256（8位）色彩顯示器移至15位或16位色彩顯示器。大部分的顯示器系統早已移至 True Color，也就是 24 位色彩，或紅色、綠色和藍色的每個色彩色板 8 位。在這裡，我們指的是新一代的顯示器系統，每個個別的色板可以運作超過8位。也稱為深色。

建議的最佳做法

簡介

除了符合技術需求，並在您的標題中採用一或多個展示專案之外，還有一些應該針對所有 Windows 遊戲遵循的最佳做法。雖然這些建議不屬於核心技術需求的範圍，但強烈建議您將其用於所有適用於Windows 遊戲的遊戲。

其他建議

使用最新的 Visual Studio 編譯程式和運行時間。較新版本的編譯程式會針對產生的程式代碼品質以及安全性問題實作大幅改善，並採用新式處理器優化策略。更新編譯程式並使用最新的 C 執行時間，是移轉至新式程式代碼撰寫做法的簡單方法。
使用 C 執行時間的動態連結庫（DLL）版本，而不是靜態連結，並使用 Secure CRT。（例外狀況可以在特殊安裝前案例中產生，例如自動執行程式或安裝程式本身）。
針對遊戲音訊，請使用 XAudio2、X3DAudio 和/或 XACT，而不是 DirectSound。對於執行所有混合和來源速率轉換且只需要低延遲音訊輸出解決方案的音訊引擎，請在 Windows XP 上使用 DirectSound （僅限）和 Windows Vista 和 Windows 7 上的 WASAPI。
避免使用舊版和已被取代的 API：DirectDraw、DirectSound、DirectPlay、DirectMusic 的效能層、DirectPlay Voice 和 Direct3D 保留模式。請注意，Windows Vista 或 Windows 7 上完全無法使用 DirectPlay Voice 和 Direct3D 保留模式。 DirectPlay 和 DirectMusic 的效能層不適用於 x64 原生應用程式。
使用 SSE/SSE2 SIMD 指令集進行優化。請參閱 Windows SDK 中的 DirectXMath API 作為 SIMD 優化數學作業的跨平台解決方案。
使用 Windows 安全性的新式最佳做法（包括 /NXCOMPAT、/GS、/HYPERVISOREH、/DYNAMICBASE、/SDL 等編譯程式和鏈接器選項）。如需詳細資訊，請參閱遊戲開發中的最佳做法。
使用最新的 Windows SDK 元件和連結庫。拿掉舊版 DirectSetup 部署的頻外元件相依性，例如 D3DX9、D3DX10 和 D3DX11。請考慮使用 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 技術文章

共用方式為

適用於 Windows 技術需求的遊戲：Windows XP、Windows Vista、Windows 7 和 Windows 8 上遊戲的最佳做法

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 錯誤報告 和檔案版本資訊

適用於 Windows 術語的 Xbox 360 通用控制器

遊戲中間件產品的指導方針

簡介

其他 建議

適用於 Windows 展示的遊戲

簡介

S.1 惡意探索 Direct3D 11

S.2 惡意探索 x64 原生

S.3 惡意探索多核心處理器

S.4 支援 Windows 遊戲 - LIVE

S.5 支援 Windows Touch

S.6 支援高色彩

建議的最佳做法

簡介

其他 建議

資源

意見反應

意見反應

其他資源

1.2 支援家庭保管庫/家長監護

4.3 支援 Windows 錯誤報告和檔案版本資訊

其他建議

其他建議