遊戲開發概論：遊戲軟體專案管理

遊戲開發概論：遊戲軟體專案管理

Chapter 4

技術設計建立製作藍圖

本章關鍵問題

誰負責撰寫技術設計文件（ TDD ）以及誰會閱讀此文件？

何謂物件導向式設計（ OOD ）？製作期間應該考量哪些安全措施？技術團隊會面臨哪些共通危機？何謂改版控制？

遊戲開發概論：遊戲軟體專案管理第四章第 105 頁

技術設計文件

技術設計文件（ technical design document ； TDD ）──一份建立遊戲程式碼的計畫──通常是由技術指導（ technical director ）或首席程式設計師撰寫。

內容描述包括撰寫或授權的所有軟體、欲儲存與更新的資料，以及整個團隊需要使用到的工具。


架構 TDD 中的架構部分必須描述遊戲中的所有軟體組成要件，這是遊戲的高階技術概觀。

它會大致列出程式流程與資料關係的大綱，若是物件導向式設計則必須明確定義物件與類別。

所有重要的演算法以及它們的來源也必須加以描述。

任何新的方法和參考外界的白皮書或技術文件也都必須在架構中描述。


物件導向式設計（ OOD）

物件導向式設計（ OOD ）則是以一群相互作用的物件（ object ）來描述系統。

物件是以其結構、所含資料，以及本身行為來定義，行為指的是可以對其他物件做的事。


物件導向式設計（ OOD）

相關的物件可以組成類別（ class ），屬於同一個類別的物件可以共用共通的結構與行為。

物件可以傳遞訊息給其他物件，向其他物件要求資訊或要求其執行某個動作。

這些動作稱為方法（ method ）。


程式撰寫標準

TDD 中的程式撰寫標準（ coding standards ）必須描述撰寫遊戲程式時的慣例、指引與風格，讓程式設計團隊的成員有所遵循。它的目的是讓任何程式設計師進行程式碼維護時能夠更加容易。這些標準通常包括： 1. 變數與程式模組的命名習慣 2. 程式碼註解與支援文件 3. 資訊隱藏或黑箱式的應用程式設計介面（ AP

I ） 4. 程式碼與資料結構的再利用 5. 風格指引


應用程式設計介面（ API）

應用程式設計介面（ application programming interface ； API ）是指軟體程式庫或應用程式提供用來建立程式的一組函式或工具。


工具

開發團隊中的每一位成員都會使用工具來建立遊戲中的每項資產。

常用且共通的外部應用程式可以向協力開發廠商取得，例如 3D繪圖視訊壓縮音訊錄放

遊戲開發概論：遊戲軟體專案管理第四章第 108.111 頁

工具

OpenGL ， 2D 與 3D繪圖的應用程式設計介面（ API ）

Microsoft DirectX ， PC上存取 3D繪圖與音效硬體功能

RAD Game Tools Bink ，視訊壓縮與錄放工具 RAD Game Tools Miles Sound System ，音訊壓縮與錄放工具


遊戲引擎

Epic 的 Unreal 3 ， 3D 遊戲開發技術。包括 PC繪圖網路人工智慧動畫內容建立

遊戲開發概論：遊戲軟體專案管理第四章第 112頁

遊戲引擎

Havok ，物理與物件碰撞模擬技術 Criterion Software 的 Renderware ， 3D 遊戲開發技術。包括繪圖物理模擬人工智慧語音

TDD裡必須描述所有的授權技術，不論它重要與否。


風險與緊急應變

TDD 中的風險評估必須涵蓋專案的所有「萬一」，這部分文件包含一系列有系統且有結構的方式，解決技術風險所必須採取的連續活動。


「 75% 效率」規則

請在你的專案中採用 75% 效率規則，如果某個工作預估三天可以完成，那麼請安排四天的時間。


時程延遲

TDD 應該點出程式設計團隊在技術工作方面可能面臨的延遲。


安全原則

TDD 應該描述遊戲的安全原則，常見的內容說明如下 : 角色與程序 : 這一節列出安全小組的角色與責任，包括程式設計師、社群管理員，以及 IT 部門等。

這裡也要定義一些經核准的程序。


安全原則

資產分類資產保護存取控制法規遵循


改版控制

為了追蹤這些變更，所有專案都應該採用改版控制（ revision control ）系統。

改版控制系統是遊戲程式建置過程（ build process ）中最重要的主角，它定義了建立完整遊戲所必須採取的步驟。


行為

AI 是非常複雜的軟體，必須加入明確且詳細的遊戲設計、環境，以及 NPC 的預期行為。


尋找路徑

尋找路徑（ pathfinding ）是由玩家角色（ PC ）和 NPC 在遊戲世界中移動時，用來決定路徑所使用的特殊 AI 演算法。

大部分的程式都是使用 A* 搜尋演算法，計算A點到 B點之間的最短路徑，而且不會撞到牆或跑得太遠的路徑。


A* 搜尋

A* 搜尋演算法利用啟發式方法找出到達目標狀態的最短路徑。

啟發式（ heuristic ）是一種解決問題的方法，它是以犧牲準確度而求得更快的計算得解。

A* 搜尋一定會得到某一點到其他點的一條路徑，它可以在配置給搜尋的時間內得到最佳解。


物理模擬

許多主要遊戲在其核心都含有物理模擬（ physics ）的程式碼，從簡單的碰撞偵測到更複雜的毛髮與服飾模擬。

你的 TDD 必須描述每一個物理模擬子系統，以及如何與遊戲其他部分界接。


媒體格式

TDD 必須指定媒體格式，並且描述資料應該如何儲存與取用。

藍光光碟（ Blu-Ray Disc ） DVD-ROM CD-ROM UMD


串流

以穿插的形式儲存資料並且持續擷取資料的過程稱為串流（ streaming ）。透過這項技術可以讓玩家穿梭於無盡的 3D空間。

TDD 必須考量媒體的傳輸速率，並且在關卡設計時加上一些限制條件。


最低需求規格

最低需求規格（ minimum specification ）通常會列出所需的處理器類型、最低的處理器速度、記憶體大小、硬碟空間，以及可支援的視訊卡。


多重處理器

如果目標平台需要多重處理器， TDD 應該說明如何運用這些處理器，工作如何分配給這些處理器，以及如何處理這些工作之間的溝通？PC 遊戲也必須考量多核心處理器


執行效能目標

盡可能的量化正常情況下的預期執行效能，指定的項目包括：影格速率（平均、最少與最高）每秒的多邊形數（變形、材質與燈光）最大的記憶體使用量最大的載入時間最大的 CPU 負載（以每個程式碼模組計算）相容性（驅動程式、故障安全、撤回）


多人玩家與網際網路

TDD 必須考慮到多人玩家互動的情形，在設計中定義通訊協定以及建立一些限制條件。

例如，即時戰略（ RTS ）遊戲的玩家可能必須限制可同時出現在戰場中部隊數量。


多人玩家與網際網路

架構是使用主從式（ client/server ）或點對點（ peer-to-peer ）也必須加以定義。

預期玩家在 50 位以上的任何多人遊戲，都不可能以傳統的方式進行測試。你必須讓數百位玩家或甚至數千位玩家進行測試，而且要有一個很好的報告流程。


繪圖

美術設計師和製作人必須知道模型與材質的技術需求，而程式設計師應該了解如何運用這些美術資產，以及玩家在鏡頭檢視中的自由度。


3D繪圖流程

TDD 應該描述用來取得物件顯示在畫面上每一個影格中的 3D繪圖流程。

大部分的遊戲都是使用相同的基本流程，再加上一些遊戲特定的最佳化方法。


3D繪圖流程


使用者介面

使用者介面包括遊戲過程中提供資訊給玩家的所有顯示項目。

從生命條到地圖、從選單按鈕到選項螢幕等，TDD 都必須指定用來布局與編輯這些介面的系統與工具。


音效

TDD 必須描述遊戲中音樂和音效的編碼、儲存、擷取，以及播放方式。

TDD 應該包含這些音效的明確規範，以及所需記憶體和儲存容量的預估。


研發

TDD 必須識別出一般的方法，並且列出每一個需要進行研發項目的相關技術。


技術設計審查（ TDR）

TDD完成之後應該由資深工程師與技術指導進行審查，這是技術設計審查（ technical design review ； TDR ）流程的一部分。


技術設計審查（ TDR）

TDR 的結果應該是各審查員一致認為 TDD 夠徹底且完整，才可以開始進行製作。如果不是這樣， TDD 作者應該解決被認為是弱點的部分。

TDR 應該限制只審查技術性的計畫，而不是遊戲設計的整體價值，這部分應該是在許可審核會議中處理。

TDR 應該是在許可審核會議之前舉行，以便技術性的問題可以提前獲得解決。


雛型製作指南

雛型製作事前製作中很重要的部分，它讓你有機會測試構想的可行性。

開發商必須看過雛型之後才知道投資的是什麼，而團隊本身也必須透過雛型來整合。

雛型製作有許多形式，不只是建立眾所皆知的「垂直切片，」它也可以採用較小的形式。以快速雛型來證明概念的構想是同樣有利的，尤其是在早期階段。


雛型

TDD 的主要目的是提供一份實作設計的書面計畫。一旦專案經過許可審核會議的核准而開始製作時， TDD 中的資訊就必須進行更新。


遊戲開發概論： 遊戲軟體專案管理

Documents

遊戲開發概論：遊戲軟體專案管理