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

  • 發行項

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

本文包含下列各節：

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 Microsoft Store應用程式和傳統型 Win32 應用程式都可以使用XINPUT 1.4。 所有版本的 Windows都可以使用XINPUT 9.1.0 來簡化的常見控制器，但沒有與XINPUT 9.1.0 搭配轉散發套件。 所有版本的 Windows也可以使用現有的 DirectX SDK 版本XINPUT 1.3，這需要 DirectSetup 才能部署。

請參閱1.4 支援 Xbox 360 Common Controller for Windows。

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 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，請將標題向下修剪為最低所需的 CA 集。

請參閱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 的自動執行程式或其他預先安裝技術

您可以假設只有 .NET 2.0 相容執行時間 (2.0、3.0、3.5) 存在於 Windows Vista 和 Windows 7 上。 根據預設，只有 .NET 4.0 相容執行時間存在Windows 8上。

請參閱 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 上的[遊戲] 資料夾) 。 選取時，遊戲也必須顯示正確的中繼資料，其中包括發行者、開發人員、發行日期、版本、Windows體驗索引分數、評等 (，如果適用) ，以及相關聯的超連結。

如果遊戲透過線上遊戲服務以數位方式散發，則服務提供者也應該出現在遊戲總管中。 為了確保正確處理提供者，並啟用 RSS 摘要的使用，應該使用遊戲定義檔案的第 2 版架構， (GDF) 。 (如需 GDF 的詳細資訊，請參閱其他資訊。)

此外，遊戲安裝程式必須在 Windows Vista 和 Windows 7 上執行下列規則：

  • 安裝不得建立快捷方式，以在桌面、[開始] 功能表或任何其他位置啟動遊戲。
  • 不得建立移除的工作和快捷方式。
  • 使用者必須使用 Windows Vista 和 Windows 7 主控台 中的程式和功能，或在 Windows XP 的 主控台 中新增或移除程式，來移除遊戲。

在 Windows XP 和舊版 Windows 上，遊戲安裝程式可以視需要建立程式群組、桌面圖示或快捷方式。

理由

Windows [遊戲總管] 的概念類似于 [我的檔] 或 [我的圖片] Windows XP 資料夾。 此概念是集中處理同一個位置的類似內容，並允許更輕鬆地組織和內容相關活動。 遊戲總管藉由允許更豐富的組織和控制遊戲，來擴充 我的檔 或 我的圖片 概念。 遊戲總管可讓玩家檢視、組織及與其系統上安裝的所有遊戲互動。 它也可讓遊戲發行者更有效率地傳達重要的遊戲資訊。 系統會以資料驅動，讓遊戲發行者在產品生命週期內輕鬆更新遊戲資訊。

其他資訊

與遊戲總管整合需要您撰寫遊戲定義檔 (GDF) ，這是內嵌在二進位檔中的 XML 文字檔， (可執行檔或 DLL) 做為資源，以及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 會處理使用第 2 版 GDF 檔案搭配 Windows Vista 所需的所有註冊和舊版支援。 從 2009 年 8 月或更新版本使用 DirectX SDK 的工具和範例程式碼。 建議使用第 2 版 GDF 檔案來啟用 RSS 摘要、遊戲統計資料和更新通知的支援。 另請參閱 ProviderGDFExampleBinary 和 GameStatisticsExample 範例。

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

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

1.2 支援家庭安全/家長監護

要求

遊戲必須遵循下列規則，完全支援Windows系列安全：

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

理由

所有遊戲都必須在標準使用者帳戶的內容中執行，以允許由Windows家長監護所控制的帳戶進行遊戲。 家長希望能夠監視和控制其子系對遊戲的存取權。 此外，許多產業、政府與宣傳群組想要更理想的方式，讓家長能夠監視及控制其子系公開的遊戲。 Microsoft 搭配遊戲總管所提供的架構，透過Windows家長監護提供這項功能。

即使是未參與評等面板計畫的遊戲，要求提高的許可權，對於大部分的使用者帳戶，都會產生不佳的遊戲體驗。 這特別是啟用家長監護時的情況，這會要求父系在每次啟動遊戲時輸入系統管理員密碼。

Windows家長監護系統可讓家長選取其認為適合其兒童的分級。 家長監護支援許多全球分級系統。 如果適用的分級系統支援他們) ，以及允許或不允許存取個別遊戲，家長也可根據內容描述元 (來限制對遊戲的存取。

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

其他資訊

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

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

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

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

作業系統 支援的評等系統
Windows Vista
  • CERO (日本)
  • ESRB (USA)
  • OFLC (澳洲)
  • PEGI (歐洲)
  • PEGI 芬蘭 (已被取代)
  • PEGI 葡萄牙
  • PEGI/BBFC (英國)
  • USK (德國)
使用 Service Pack Windows Vista Windows Vista 的 Service Pack 新增下列專案的支援：
  • 南韓 (GRB)
  • ESRB 「一元」 變體內容描述元
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 (芬蘭) 變體現在已被取代，而支援標準 PEGI (歐洲) 評等系統。 OFLC 系統現在已被取代，適用于澳洲的 COB-AU。

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

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

1.3 支援豐富的已儲存遊戲

[此需求已淘汰]

1.4 支援 xbox 360 Common Controller for Windows [條件式需求]

要求

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

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

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

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

理由

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

其他資訊

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

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

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

如需詳細資訊，請參閱 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媒體中心的 HDTV 部署。
  • 協助工具需求。

其他資訊

在理想情況下，遊戲預設為顯示器的原生外觀比例。 不過，可靠地取得此資訊可能是一項挑戰，因此，遊戲可以假設桌面是以原生外觀比例執行。 您可以使用 ENUM_REGISTRY_SETTINGS 呼叫 EnumDisplaySettings 來取得桌面解析度。

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

1.6 支援從 Windows 媒體中心啟動

[此需求已淘汰。]

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 感知

要求

當每英吋 (DPI) 縮放點啟用時，遊戲及其安裝程式必須正確執行， (以 144 DPI 測試，以 1600 1200) 在 Windows Vista 和 Windows 7 的顯示器解析度上縮放 1600 1200) 。

這通常需要遊戲可執行檔宣告為 DPI 感知。 這可藉由內嵌資訊清單專案來完成： < DPIAwaretrueDPIAware <>> 。

理由

高品質的 ANDROID 監視器在電腦顯示時很常見，而且在以原生解析度驅動時看起來最好， (通常是 1280 1024、1600 1200 等等) 。 難以閱讀文字和在此解析度上看到影像的客戶，通常會將其電腦桌面設定為較低的解析度，並遭受來自「LED 縮放」的視覺成品。 相反地，客戶可以將解析度保留為原生大小，並變更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 包含專案屬性中名為Enable DPI Awareness的設定，可免除 DPIaware.manifest 之類的檔案需求。 展開 [組態屬性和資訊清單工具]，然後選取 [輸入 & 輸出]，以尋找[啟用 DPI 感知]。

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

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

安全性和相容性

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

客戶權益

下列需求可改善遊戲的整體安全性，並協助確保它們在不同的架構、不同組態和不同模式下，使用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 資訊清單元素的假警告。 若要解決此問題，請從 Windows SDK 將Mt.exe更新為最新版本。

如需安裝、修補和移除的特殊案例詳細資訊，請參閱需求 3.1。

動態連結程式庫 (DLL) 不需要這類資訊清單。

如需使用者帳戶控制的詳細資訊，請參閱 遊戲開發人員的使用者帳戶控制。

2.2 支援 Windows x64 版本

要求

為了維持與 64 位版本的Windows相容性，遊戲應符合下列需求。

  • 標題和標題安裝程式不得包含任何 16 位程式碼，或依賴任何 16 位元件。
  • 如果遊戲相依于核心模式驅動程式以進行作業，則必須提供這些驅動程式的 x64 版本。 遊戲安裝程式必須偵測並安裝 64 位版本Windows的適當驅動程式和元件。

理由

許多Windows Vista 和 Windows 7 使用者都會在產品生命週期內執行 64 位版本的作業系統，因此應用程式必須與此作業系統相容。

其他資訊

Windows Windows 64 (WOW64) 允許在 64 位版本的 Windows 上執行 32 位程式碼，因此應用程式不需要在 64 位版本的 Windows 上原生 64 位程式碼。 十六位程式碼不會在 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 Hardware Quality Labs (WHQL) 或驅動程式可靠性簽章 (DRS) 計畫取得。

理由

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

其他資訊

每個需求 2.2 都需要 32 位和 64 位原生版本的所有核心模式驅動程式。

如需 Microsoft 驅動程式簽署程式的詳細資訊，請參閱Windows硬體開發人員入口網站。

2.5 執行適當的版本檢查

要求

除非終端使用者授權合約禁止在未來作業系統上使用，否則遊戲不得在Windows版本號碼變更所指出的未來作業系統上執行。 如果遊戲應該失敗，它必須藉由向使用者顯示適當的訊息，以正常執行。

如果Windows版本檢查，則必須使用GetVersionEx 或 VerifyVersionInfo (版本檢查 API 或 VerifyVersionInfo) 來檢查作業系統版本。 登錄機碼不得讀取以判斷版本。

DirectX 執行時間的明確版本檢查不得出現在遊戲中。 這些版本檢查不得出現在啟動 DirectX 執行時間安裝程式的安裝中， (DirectSetup) 。

理由

Windows使用者升級其作業系統時，不應該因為Windows版本號碼增加而禁止他們播放目前的遊戲。 撰寫不良的版本檢查程式會繼續為軟體建立問題，否則可在較新版本的 Windows 上運作，或只是新增 Windows Service Pack。

DirectX 執行時間的弱弱版本檢查比較邏輯在不同版本的Windows上執行時，已建立許多失敗的安裝。 DirectX 版本號碼僅適用于核心作業系統元件。 它不適用於許多遊戲所使用的並存 DirectX SDK 元件。

其他資訊

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

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

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

建議支援 Windows XP 檢查 2 或更高版本的 Service Pack 層級的遊戲，因為 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防火牆的詳細資訊，請參閱DirectX 文章Windows適用于遊戲開發人員的防火牆和 FirewallInstallHelper 範例。

如果標準使用者啟動安裝，而且安裝程式需要系統管理許可權， (即提示系統管理員認證) ，則安裝程式無法在安裝程式結束時符合此需求的最後一個層面。 它也會繼承系統管理許可權，這是潛在的安全性風險。 相反地，安裝程式啟動程式載入器應該在從安裝程式成功叫用後啟動遊戲。 如需詳細資訊，請參閱 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 Install for Game Developers。

3.5 避免在安裝期間重新開機

要求

除非傳回結果或 Microsoft 檔指出重新開機，否則遊戲安裝程式不應該假設從轉散發套件安裝Windows元件需要重新開機。

如果遊戲安裝程式一律強制重新開機，則必須由 Microsoft 核准。

Windows安裝程式套件中包含的檔案使用中對話方塊必須包含一個選項，才能自動關閉應用程式，並在安裝程式完成之後嘗試重新開機它們。

理由

在安裝之後重新開機系統對使用者而言是不方便的中斷，而且通常不需要。

其他資訊

如需詳細資訊，請參閱搭配重新開機管理員使用 Windows 安裝程式。

3.6 正確使用檔案版本設定

要求

遊戲安裝程式必須正確檢查，以確保已安裝最新的檔案版本。 安裝遊戲絕對不能回歸您不會產生的任何檔案，或是您未產生的應用程式所共用的任何檔案。

理由

共用元件和系統元件通常會針對安全性修正和擴充功能進行更新。 包含舊版更新元件的安裝不應造成已套用的更新和修正遺失。

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

要求

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

成功安裝應用程式之後，在磁片磁碟機中重新插入磁片磁碟機不得自動開始安裝。 可以接受要求使用者是否要更新或變更其安裝選擇。

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

理由

自動執行可簡化使用媒體分散式應用程式的體驗，例如通常需要磁片磁碟機中存在的遊戲，才能播放遊戲。

其他資訊

無法接受要求使用者在 檔案總管 中流覽，才能從 CD 或 DVD 開機安裝。

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

撰寫自動執行程式時，請確定所有必要元件都存在於全新安裝Windows。 一般應用程式依賴安裝的技術，但自動執行本身會在發生任何這類設定之前執行。 其中一個常見範例是自動執行程式失敗，因為 Visual C 執行時間 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) 。

遊戲不得封鎖關機。

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

使用 LPARAM = ENDSESSION_CLOSEAPP (0x1) WM_QUERYENDSESSION

GUI 應用程式必須立即回應 TRUE (TRUE) ，才能準備重新開機。

WM_ENDSESSION與 LPARAM = ENDSESSION_CLOSEAPP (0x1)

應用程式必須在 5 秒內傳回 0 值，然後關閉。

CTRL+C

接收此訊息的主控台應用程式必須立即關閉。

理由

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

其他資訊

如果遊戲安裝程式使用Windows安裝程式技術 (MSI) ，則會自動提供這項功能。 Microsoft 轉散發套件也支援重新開機管理員。

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

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

要求

在下列測試中，遊戲不得在 Microsoft Application Verifier (AppVerifier) 4.0 版或更新版本下執行任何失敗：

  • 基本概念：控制碼、堆積、鎖定、記憶體、TLS
  • 其他：危險 API、DirtyStacks

理由

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

其他資訊

如需應用程式驗證器的詳細資訊，請參閱 MSDN上軟體發展生命週期內的應用程式驗證器和使用應用程式驗證器。 您可以從下載詳細資料下載應用程式驗證器：Microsoft 下載中心上的 應用程式驗證器 。

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

這些測試應在發行組建上執行。 偵錯組建可能會產生 False 失敗。 某些反詐騙和反速查技術可能會干擾 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 通用控制器

Name 描述
A A 按鈕。
B B 按鈕。
返回 [上一步] 按鈕。
(右/左) 凸 控制器右上方和左邊緣的按鈕。 相當於手部按鈕。
方向板 控制器方向板。
D-pad 接受方向板的縮寫。
DP 方向板縮寫和控制器標籤。
RB、LB 向右和左凸起的縮寫和控制器標籤。
RS、LS 向右和左杆縮寫和控制器標籤。
RT、LT 由右和左觸發縮寫和控制器標籤。
RSB、LSB 向右和左杆縮寫和控制器標籤。
START [開始] 按鈕。
(右/左) 杆 控制器杆。 先前稱為搖桿。
(右/左) 杆按鈕 控制器杆按鈕。 先前稱為指紋按鈕。
(右/左) 觸發程式 控制器觸發程式。
震動 控制器馬達所產生的遊戲回饋。 請勿使用 Rumble。
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 常式。 這可讓使用者使用靜態Code Analysis (/analyze) ，這是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批註高階作業，以更輕鬆地識別使用 PIX 進行Windows瓶頸。

    注意

    針對 Visual Studio 2012 圖形診斷功能，這些 D3DX 和 PIX 常式會由ID3DUserDefinedAnnotation介面取代。

  • 對於網路程式庫，請提供 IP 中性實作，並避免僅淘汰的 IPv4 常式，以支援具有 Service Pack 2、Windows Vista 和 Windows 7 的 XP Windows XP 中的 IPv6 和 Teredo 技術。

  • 遊戲服務提供者應該使用 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 Technical Requirement 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 Display Driver Model (WDDM) 和 Direct3D 10.1 基礎結構為基礎，以支援新功能：硬體鑲嵌、計算著色器、多執行緒轉譯和資源建立、新的紋理壓縮格式，以及更具彈性的著色器語言。 Direct3D 11 提供新式視訊卡的統一硬體支援，包括最新一代 Direct3D 11 元件、所有 Direct3D 10 和 10.1 視訊卡，以及許多著色器模型 2.0/3.0 Direct3D 9 視訊卡，這是適用于 Windows 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 版本在 x64 支援硬體上執行的 x64 版Windows所啟用的吸引人的新體驗。 與 32 位版本的遊戲並存比較應該會顯示內容複雜度、降低整體負載時間和效能的可感知改善。

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

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

理由

x64 技術可為消費者和伺服器市場提供 64 位的定址功能，其中包含現有應用程式的全速 32 位回溯相容性。 x64 是 AMD (AMD64) 和 Intel (EMT64) 藍圖的重要部分，除了 Ultra 行動 CPU 之外，也支援所有目前和未來世代處理器的技術。

Windows XP Professional x64 Edition 是第一個取用者導向 Windows的作業系統 (作業系統) ，以支援 x64 技術，Windows Vista 和 Windows 7 大幅擴充 64 位取用者運算作業系統啟用的可用性。 許多新電腦上的 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 位遊戲位於Gamasutra 中。

注意

此展示專案的主要挑戰是確保遊戲依賴的任何協力廠商程式庫或元件都可用於 64 位原生開發。 許多舊版 Microsoft API 也已從 64 位原生環境中排除，這可證明引擎程式碼基底的挑戰，其中包含舊版重要系統的實作。

S.3 惡意探索Many-Core處理器

要求

遊戲會實作可在可用時利用多核心處理器、調整為 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 (DXGI_FORMAT_R16G16B16A16，D3DFMT_A16B16G16R16) 轉譯背景緩衝區和全螢幕顯示模式的格式。

藉由使用高色彩轉譯目標，High-Dynamic Range (HDR) 內容可以在執行 10 位或 16 位範圍的音調對應時，使用延伸或寬色範圍來轉譯。

理由

即使 CRT 顯示器很普遍，監視器也能夠顯示超過每個通道 256 個色彩等級。 視訊卡上的掃描硬體已是限制因素。 新式 GPU，包括大部分的 Direct3D 9 類別硬體，以及所有 Direct3D 10 類別和較佳的硬體，每個通道至少有 10 位的掃描硬體，且硬體功能會設定為未來每個色彩通道成長為 16 位。 HD TV 互連系統 (HDMI、DisplayPort) 設計來處理每個通道超過 8 位，而類比 VGA 也已經具有這類訊號。

其他資訊

請注意，高色彩或 Hi Color 過去是指從 256 (8 位) 色彩顯示器移至 15 位或 16 位色彩顯示。 大部分的顯示器系統都已經移至 True Color，這是 24 位色彩，或每個色彩色板 8 位，以紅色、綠色和藍色表示。 透過高色彩，我們表示新一代的顯示器系統可以針對每個個別色彩通道使用超過 8 位。 也稱為深色。

簡介

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

其他建議

  • 使用最新的Visual Studio編譯器和執行時間。 較新版本的編譯器會針對產生的程式碼品質與安全性問題，實作大幅改善，並採用新式處理器優化策略。 更新編譯器並使用最新的 C 執行時間是移轉至新式程式碼撰寫做法的簡單方式。
  • 使用動態連結程式庫 (DLL) 版本的 C 執行時間，而不是靜態連結，並使用 Secure CRT。 (例外狀況可以在特殊的安裝前案例中進行，例如自動執行程式或安裝程式本身) 。
  • 針對遊戲音訊，請使用 XAudio2、X3DAudio 和/或 XACT，而不是 DirectSound。 對於執行所有混合和來源速率轉換且只需要音訊輸出低延遲解決方案的音訊引擎，請只在 Windows Vista 和 Windows 7 上使用 directSound on Windows XP () 和 WASAPI。
  • 避免使用舊版和已淘汰的 API：DirectDraw、DirectSound、DirectPlay、DirectMusic 的效能層、DirectPlay 語音和 Direct3D 保留模式。 請注意，Windows Vista 或 Windows 7 上完全無法使用 DirectPlay Voice 和 Direct3D 保留模式。 x64 原生應用程式無法使用 DirectPlay 和 DirectMusic 的效能層。
  • 使用 SSE/SSE2 SIMD 指令集進行優化。 請參閱 Windows SDK 中的DirectXMath API 作為 SIMD 優化數學運算的跨平臺解決方案。
  • 使用Windows安全性 (的新式最佳做法，包括/NXCOMPAT、/GS、/CERTIFICATIONEH、/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 應用程式開發需求
WinQual 開發人員入口網站
 Windows Quality Online Services (Winqual)
DirectX 開發人員入口網站
 Directx 開發人員中心
適用于 Windows 和 DirectX SDK 的遊戲部落格
 適用於 Windows 與 DirectX SDK 的遊戲
其他 DirectX 文章
 DirectX 技術文章