游戲架構與設計（第2版）

第一部分 游戲設計
第1章 初步概念
1.1 新技術的震撼
1.2 創(chuàng)造性指導方針
1.3 形成創(chuàng)意
1.3.1 靈感
1.3.2 合成
1.3.3 共鳴
1.3.4 匯聚
1.4 修正創(chuàng)意
戲劇效果
1.5 論述
1.6 審查
1.6.1 分析
1.6.2 評估
1.6.3 論證
案例分析1.1 一頁的展示
1.7 可行性
1.7.1 商業(yè)因素
1.7.2 技術因素
1.7.3 開發(fā)因素
1.8 寫下你的想法
案例分析1.2 Conquerors的初始論述
第2章 核心設計
2.1 游戲是什么
2.1.1 酷的特色
2.1.2 奇特的圖形
2.1.3 謎題
2.1.4 背景和故事
2.2 游戲不是一切
案例分析2.1 故事與可玩性
2.3 游戲意味著游戲可玩性
案例分析2.2 一個錯過的機會?
2.4 創(chuàng)建游戲規(guī)格說明
案例分析2.3 集成游戲目標
2.4.1 特色
案例分析2.4 一個浮現的實例
2.4.2 游戲可玩性
2.4.3 界面
案例分析2.5 優(yōu)美界面
2.4.4 規(guī)則
案例分析2.6 規(guī)則必須為特色服務
2.4.5 關卡設計
案例分析2.7 有趣的關卡設計
2.5 游戲規(guī)格說明舉例
案例分析2.8 游戲說明
2.5.1 原型的價值
2.5.2 文檔的必要性
第3章 游戲可玩性
3.1 游戲可玩性
3.1.1 游戲可玩性的實現
3.1.2 支配性策略問題
3.1.3 準支配
案例分析3.1 環(huán)境+規(guī)則=游戲的可玩性.
3.1.4 投資支持
3.1.5 多功能性
案例分析3.2 出乎意料的多功能性
3.1.6 補償因素
案例分析3.3 平衡補償因素
3.1.7 非永久性
3.1.8 影子成本
案例分析3.4 《帝國時代》的影子成本
3.1.9 協(xié)作
3.1.10 游戲可玩性的最后評論
3.2 互動
3.2.1 互動的種類
案例分析3.5不同種類的互動
3.2.2 為什么，與什么?
第4章 詳細設計
4.1 設計師的作用
案例分析4.1 開發(fā)時限
4.2 設計文檔
4.2.1 游戲可玩性規(guī)格說明
4.2.2 設計師的備注
案例分析4.2 針對規(guī)格說明編制文檔一
4.3 使用設計文檔
4.4 使設計適應開發(fā)
層和試驗臺
案例分析4.3 計劃詳細規(guī)格說明以適應
體系結構
4.5 為什么要使用文檔
第5章 游戲平衡
5.1 玩家，玩家平衡
對稱
5.2 玩家／游戲可玩性平衡
案例分析5.1 這樣有趣嗎?
5.2.1 獎賞玩家
5.2.2 讓機器來做這件事情
5.2.3 創(chuàng)作可玩性游戲
案例分析5.2 保存游戲的問題
5.3 游戲可玩性／游戲可玩性平衡
5.3.1 組件和特性平衡
案例分析5.3 Dungeon Keeper中的組件和特性平衡
5.3.2 非傳遞游戲力學保證平衡
案例分析5.4 使用SPS的特性平衡
案例分析5.5 使用游戲理論分析來
實現平衡
5.4 游戲平衡性核對清單
第6章 外觀和感覺
6.1 氛圍
6.1.1 聲音
案例分析6.1 最佳音效
6.1.2 視覺
案例分析6.2 一個荒腔走板的摘記
6.1.3 觸覺
6.2 界面
案例分析6.3 把界面、外觀和感覺結合在一起
案例分析6.4 有時少就是不好
6.3 故事講述
6.3.1 故事講述技術工具箱
案例分析6.5 外觀和感覺文檔的例子..
6.3.2 轉折點
案例分析6.6預料之外的情節(jié)發(fā)展
6.3.3 懸念
6.3.4 對話
6.3.5 主題
6.3.6 結局
案例分析6.7 不滿意的結局
6.3.7 變化
6.4 結束語
第7章 包裝
專家：
7.1.1 游戲概念
7.1.2 為變化做計劃
7.1.3 技術
7.1.4 開發(fā)
7.1.5 團隊
7.1.6 成本和時間期限
7.1.7 游戲可玩性
7.1.8 未來展望
第8章 游戲設計的未來一
8.1 設計的必要性
8.1.1 別害怕作計劃
案例分析8.1 設計節(jié)省了時間
8.1.2為 什么進行設計是很好的行為
案例分析8.2 及時更新設計
8.2 游戲設計的本質
8.2.1 它是原創(chuàng)嗎?
8.2.2 它有一致性嗎?
8.2.3 它是互動的嗎?
8.2.4 它吸引人嗎?
8.2.5 它富于趣味嗎?
8.3 設計的未來
8.3.1 讓設計更具共性
8.3.2 非象征性的設計
案例分析8.3 比較象征性和非象征性的設計
8.4 游戲的未來
8.4.1 下一個10年
8.4.2 軟件的強項
8.4.3 創(chuàng)意的十字路口
案例分析8.4 舞臺劇的范例
8.5 游戲如娛樂
8.6 前進之路
第二部分 團隊組建和管理
第9章 當前的團隊管理方式
當前的開發(fā)模式
9.1.1 游戲業(yè)的起源
9.1.2 游戲開發(fā)者的難題
9.1.3 存在問題的開發(fā)者
9.1.4 加班時間過長意味項目的失敗
9.1.5 規(guī)則的例外
案例分析9.1 《雷神之錘》、 《星際爭霸》與《幽浮——突擊者》
第10章 角色和部門
10.1 分派人員
10.1.1 管理和設計部門
10.1.2 編程部門
10.1.3 美工部門
10.1.4 音樂和雜項部門
10.1.5 支持和質保部門
10.2 提高士氣和工作環(huán)境
10.2.1提高士氣和改善工作環(huán)境
10.2.2 士氣高漲的告誡和警告
10.3 分散風險
第11章 軟件廠
11.1關于軟件工廠
11.2 為什么使用軟件工廠
解決游戲開發(fā)問題
案例分析11.1 失去核心成員的影響
案例分析11.2 代碼重用
11.3 組織軟件工廠
11.3.1 軟件工廠的結構
11.3.2 小組責任和溝通
案例分析1 1.3 沒有有效地處理問題
案例分析1 1.4 有效處理問題的方法
案例分析1 1.5 工具重用的好處
11.4 實施軟件工廠結構和方法一.
11.4.1 開始
11.4.2 知道什么時候使用哪個團隊——并行開發(fā)時間表
11.4.3 輪換、重新分配組員
案例分析1 1.6 必不可少的注釋
1 1.5 軟件工廠的適用性
11.6 小一些的團隊
11.7 結束語
第12章 里程標和截止日期
12.1 現在的里程標是如何工作的
案例分析12.1 模糊的里程標會給
項目帶來什么影響?
12.2 模糊的里程標
12.3~程標和小里程標
12.4 什么時候使用里程標
12.5 制定精確的里程標
案例分析12.2 取消項目的花費
檢查點1.0 收集基本需求
檢查點1.1 收集技術需求
檢查點1.2 收集資源需求
檢查點2.0 基本可行性研究
檢查點2.1 技術可行性研究
檢查點2.2 資源可行性研究
檢查點3.0 起草體系結構規(guī)范
檢查點3.1 項目初始化
12.6 定義里程標
12.6.1 差的里程標
12.6.2 好的里程標
案例分析12.3 一個發(fā)生在現實生活中和里程標
12.6.3 研究以及截止日期
12.6.4 里程標的評價
第13章 步驟和流程
13.1 步驟
13.1.1 檢查
13.2 總體測試
13.2 流程
案例分析13.1 愚蠢的流程
13.3 步驟：什么時候使用
13.3.1 設計階段
13.3.2 開發(fā)階段
13.3.3 測試階段
13.4 源控制和代碼檢查：協(xié)同
案例分析13.2 不需要源控制
源控制用來干什么?
13.5 信息傳遞的重要性
前攝的信息傳遞和被動的信息傳遞
第14章 疑難解答
風險
14.1.1 設計和體系結構問題
案例分析14.1 不聽勸告的管理人員.
14.1.2 進度表威脅
案例分析14.2 重新調整進度表
14.1.3 組織機構的問題
14.1.4 合同問題
14.1.5 人員問題
14.1.6 開發(fā)問題
14.1.7 過程問題
第15章 游戲業(yè)的未來
15.1 游戲業(yè)現狀
15.1.1 第一時期
15.1.2 第二時期
15.1.3 第三時期
15.1.4 游戲中的暴力
15.2 新模塊開發(fā)者
案例分析15.1 對開發(fā)者來說很艱難
15.3 在線革命
15.3.1 在線交付游戲
15.3.2 在線玩游戲
第三部分 游戲體系結構
第16章 當前的開發(fā)方法
16.1 游戲開發(fā)技術的歷史
16.1.1 最初的游戲創(chuàng)意的興衰
16.1.2 開發(fā)環(huán)境
16.2 現在的情況
復用能力
第17章 初步設計
17.1 開始
案例分析17.1 《雷神之錘Ⅱ》中的
抽象
17.2 硬件抽象
17.2.1 圖形硬件抽象
17.2.2 聲音硬件抽象
17.2.3 其他硬件問題
17.2.4 “不構造在這里”可能更好
17.2.5 模糊地帶
17.3 問題域
什么是游戲?(回顧)
17.4 以token的方式考慮
17.4.1 Pong游戲的token化
17.4.2 Pac-Man的token化
17.4.3 狀態(tài)轉換及屬性
案例分析17.2 缺乏靈活性產生的陷阱
第18章 技術的使用
18.1 美工的狀態(tài)
18.1.1 3D引擎的起落
18.1.2 技術的理解
案例分析18.1 第一印象
18.2 不保險的研究
18.2.1 研究的類型
案例分析18.2 忽略了可能存在的
機會
案例分析18.3 俄羅斯方塊：一個告誡
案例分析18.4 《時空英豪》：技術的很好運用
18.2.2 做好工作日志
18.3 重新發(fā)明輪子
18.4 使用對象技術
抽象方法的利弊
第19 章建立模塊
軟件中的代碼重用
19.1.1 代碼重用：
19.1.3 特定于游戲的模式
第20章 初始體系結構設計
20.1 體系結構的誕生
體系結構的概念
20.2 層式系統(tǒng)
20.2.10 層：原型
案例分析20.1 一個數據庫驅動的方法.
20.2.2 一層及其上各層
20.3 體系結構設計
20.3.1 將基于層的方法用于架構設計
案例分析20.2討論Warbots的架構
20.3.2 體系結構的正交性
第21章 開發(fā)
21.1 開發(fā)過程
21.2 代碼質量
編碼標準
21.3 編碼優(yōu)先級
21.3.1 速度
21.3.2 規(guī)模
21.3.3 靈活性
21.3.4 可移植性
21.3.5 可維護性
21.4 調試和模塊完成
Bug的類型
案例分析21.1 是A類bug嗎?
21.5 7 個黃金法則
21.5.1 重用
案例分析21.2 可重用的體系結構
21.5.2 文檔
21.5.3 先設計
21.5.4 進度表
21.5.5 在項目進行過程中捕捉錯誤
21.5.6 控制研發(fā)程度(R&D)
21.5.7 知道什么時候劃定最后界限
21.6 3 種毫無作用的行為
21.6.1 糟糕的管理
21.6.2 特性蔓延
21.6.3 編碼人員的僵化
第22章 發(fā)布前的預備階段
22.1 后期評估
22.1.1 最終分析
22.1.2 游戲達到標準了嗎?
案例分析22.1 一起自食其果的災難
案例分析22.2 一份恢復計劃
案例分析22.3 許可協(xié)議地獄
案例分析22.4 最后的瘋狂
22.2 后期的本地化
22.2.1 許可協(xié)議
22.2.2 語言
22.2.3 Demos
案例分析22.5 把游戲拱手交出去
案例分析22.6 留一手
22.3 玩法測試
案例分析22.7 他們怎么會沒有
發(fā)現呢?!
22.4 焦點小組
22.5 網站
22.6 為Gold Master準備就緒
22.7 補丁
第23章 事后剖析
案例分析23.1 兩個項目的故事
23.1 團隊動力
案例分析23.2 所有可怕的錯誤
23.2概念
23.2.1 趨勢
案例分析23.3 對趨勢的錯誤判斷
23.2.2 親和力
23.3 開發(fā)階段
23.3.1 軟件計劃
案例分析23.4地 下密牢
23.3.2 編碼
23.3.3 測試
23.4 商業(yè)方面
案例分析23.5 保證你的資金流
23.5 事后剖析本身的事后剖析
第24章 游戲開發(fā)的未來
24.2.1 市場營銷
案例分析24.1 市場意味著定位
24.2.2 內容
案例分析24.2 無戰(zhàn)略的開發(fā)
24.2.3 計劃
24.2.4 開發(fā)人員
24.3 雖小仍美
24.4 未來團隊的建立
24.4.1 角色
24.4.2 動機
24.4.3 士氣
24.5 開發(fā)中的新方向
24.5.1 整體方法
24.5.2 “侏羅紀公園”軟件
24.5.3 固有的及超然的世界
24.6 未來事物的定形
第四部分 附錄
附錄A 游戲設計文檔樣例
A.1 詳細設計討論
A.1.1 彈珠游戲簡介
A.1.2 游戲玩法概述
A.1.3 平臺
A.1.4 時間比例
A.1.5 為什么迷宮類游戲今不如昔?
A.1.6 迷宮類游戲魅力
A.1.7 為什么彈珠游戲如此出色?
A.1.8 游戲設計：用戶界面元素
A.1.9 彈珠的物理學
A.1.10 方塊
A.1.1l 特殊例子——方塊之間的碰撞
A.1.12 玩游戲
A.1.13 更多的修飾
A.2 初步設計和樣例設計
A.3 芝加哥黑幫：在20年代繁榮的美國
地下社會
A.3.1 概述
A.3.2 游戲目標
A.3.3 圖形
A.3.4 進入游戲
A.3.5 角色類型
A.3.6 角色個性
A.3.7 命令
A.3.8 戰(zhàn)斗
A.3.9 游戲世界
A.3.10 營業(yè)場所
A.3.11 消息
A.3.12 戰(zhàn)役指南
A.3.13 目標平臺
A.3.14 營救者
A.3.15 游戲元素
A.3.16 游戲怎么玩?
A.4 技術規(guī)約
技術規(guī)約：彈珠游戲完全3D置入式
圖形模塊
A.5 代碼評審表
A.6 測試腳本
附錄B 參考文獻
B.1 參考書目
B.2 期刊
B.3 新聞組
術語表
24.1 基于背景開發(fā)
24.2 未來開發(fā)
案例分析19.1 引擎重用
19.1.2 設計重用：模式