游戏架构与设计 第2版PDF电子书下载

目录 1

第一部分 游戏设计 1

第1章 初步概念 3

1.1 新技术的震撼 3

1.2 创造性指导方针 4

1.3 形成创意 5

1.3.1 灵感 5

1.3.2 合成 6

1.3.3 共鸣 7

1.3.4 汇聚 7

1.4 修正创意 8

戏剧效果 8

1.5 论述 10

1.6 审查 11

1.6.1 分析 11

1.6.2 评估 11

1.6.3 论证 11

案例分析1.1 一页的展示 12

1.7 可行性 13

1.7.1 商业因素 13

1.7.2 技术因素 13

1.7.3 开发因素 13

1.8 写下你的想法 14

案例分析1.2 Conquerors的初始论述 14

2.1.2 奇特的图形 22

2.1.1 酷的特色 22

第2章 核心设计 22

2.1 游戏是什么 22

2.1.3 谜题 23

2.1.4 背景和故事 23

2.2 游戏不是一切 23

案例分析2.1 故事与可玩性 24

2.3 游戏意味着游戏可玩性 24

案例分析2.2 一个错过的机会？ 24

2.4 创建游戏规格说明 26

案例分析2.3 集成游戏目标 26

2.4.1 特色 26

案例分析2.4 一个浮现的实例 27

2.4.2 游戏可玩性 28

2.4.4 规则 29

2.4.3 界面 29

案例分析2.5 优美界面 29

案例分析2.6 规则必须为特色服务 30

2.4.5 关卡设计 30

案例分析2.7 有趣的关卡设计 31

2.5 游戏规格说明举例 32

案例分析2.8 游戏说明 32

2.5.1 原型的价值 34

2.5.2 文档的必要性 35

第3章 游戏可玩性 36

3.1 游戏可玩性 37

3.1.1 游戏可玩性的实现 37

3.1.3 准支配 38

3.1.2 支配性策略问题 38

案例分析3.1 环境＋规则＝游戏的可玩性 41

3.1.4 投资支持 43

3.1.5 多功能性 43

案例分析3.2 出乎意料的多功能性 44

3.1.6 补偿因素 45

案例分析3.3 平衡补偿因素 45

3.1.7 非永久性 46

3.1.8 影子成本 46

案例分析3.4 《帝国时代》的影子成本 46

3.1.9 协作 47

3.1.10 游戏可玩性的最后评论 47

3.2.1 互动的种类 48

3.2 互动 48

案例分析3.5 不同种类的互动 49

3.2.2 为什么，与什么？ 50

第4章 详细设计 52

4.1 设计师的作用 52

案例分析4.1 开发时限 52

4.2 设计文档 55

4.2.1 游戏可玩性规格说明 55

4.2.2 设计师的备注 55

案例分析4.2 针对规格说明编制文档 55

4.3 使用设计文档 56

4.4 使设计适应开发 58

层和试验台 58

案例分析4.3 计划详细规格说明以适应体系结构 60

4.5 为什么要使用文档 61

第5章 游戏平衡 62

5.1 玩家／玩家平衡 62

对称 63

5.2 玩家／游戏可玩性平衡 65

案例分析5.1 这样有趣吗？ 65

5.2.1 奖赏玩家 66

5.2.2 让机器来做这件事情 67

5.2.3 创作可玩性游戏 67

案例分析5.2 保存游戏的问题 67

5.3 游戏可玩性／游戏可玩性平衡 68

5.3.1 组件和特性平衡 69

案例分析5.3 Dungeon Keeper中的组件和特性平衡 70

5.3.2 非传递游戏力学保证平衡 71

案例分析5.4 使用SPS的特性平衡 74

案例分析5.5 使用游戏理论分析来实现平衡 78

5.4 游戏平衡性核对清单 82

第6章 外观和感觉 83

6.1 氛围 83

6.1.1 声音 84

案例分析6.1 最佳音效 84

6.1.2 视觉 85

案例分析6.2 一个荒腔走板的摘记 86

6.1.3 触觉 86

6.2 界面 87

案例分析6.3 把界面、外观和感觉结合在一起 87

案例分析6.4 有时少就是不好 88

6.3 故事讲述 89

6.3.1 故事讲述技术工具箱 90

案例分析6.5 外观和感觉文档的例子 92

6.3.2 转折点 95

案例分析6.6 预料之外的情节发展 95

6.3.3 悬念 97

6.3.4 对话 97

6.3.5 主题 98

6.3.6 结局 98

案例分析6.7 不满意的结局 99

6.3.7 变化 99

6.4 结束语 100

专家 101

第7章 包装 101

7.1.1 游戏概念 102

7.1.2 为变化做计划 103

7.1.3 技术 106

7.1.4 开发 107

7.1.5 团队 109

7.1.6 成本和时间期限 110

7.1.7 游戏可玩性 111

7.1.8 未来展望 113

第8章 游戏设计的未来 115

8.1 设计的必要性 115

8.1.1 别害怕作计划 115

案例分析8.1 设计节省了时间 116

8.1.2 为什么进行设计是很好的行为 117

案例分析8.2 及时更新设计 118

8.2 游戏设计的本质 118

8.2.1 它是原创吗？ 119

8.2.2 它有一致性吗？ 119

8.2.3 它是互动的吗？ 119

8.2.4 它吸引人吗？ 120

8.2.5 它富于趣味吗？ 120

8.3 设计的未来 121

8.3.1 让设计更具共性 121

8.3.2 非象征性的设计 122

8.4 游戏的未来 123

的设计 123

案例分析8.3 比较象征性和非象征性 123

8.4.1 下一个10年 124

8.4.2 软件的强项 125

8.4.3 创意的十字路口 126

案例分析8.4 舞台剧的范例 128

8.5 游戏如娱乐 130

8.6 前进之路 131

第二部分 团队组建和管理 133

第9章 当前的团队管理方式 135

当前的开发模式 135

9.1.1 游戏业的起源 135

9.1.2 游戏开发者的难题 137

9.1.3 存在问题的开发者 138

9.1.4 加班时间过长意味项目的失败 142

9.1.5 规则的例外 143

案例分析9.1 《雷神之锤》、《星际争霸》与《幽浮——突击者》 143

第10章 角色和部门 145

10.1 分派人员 145

10.1.1 管理和设计部门 146

10.1.2 编程部门 147

10.1.3 美工部门 147

10.1.4 音乐和杂项部门 148

10.1.5 支持和质保部门 149

10.2 提高士气和工作环境 150

10.2.1 提高士气和改善工作环境 150

10.2.2 士气高涨的告诫和警告 153

10.3 分散风险 154

第11章 软件工厂 155

11.1 关于软件工厂 155

11.2 为什么使用软件工厂 156

解决游戏开发问题 156

案例分析11.1 失去核心成员的影响 157

案例分析11.2 代码重用 158

11.3 组织软件工厂 159

11.3.1 软件工厂的结构 159

11.3.2 小组责任和沟通 160

案例分析11.3 没有有效地处理问题 161

案例分析11.4 有效处理问题的方法 162

案例分析11.5 工具重用的好处 164

11.4.1 开始 166

11.4 实施软件工厂结构和方法 166

11.4.2 知道什么时候使用哪个团队——并行开发时间表 167

11.4.3 轮换、重新分配组员 168

案例分析11.6 必不可少的注释 168

11.5 软件工厂的适用性 169

11.6 小一些的团队 169

11.7 结束语 169

第12章 里程标和截止日期 170

12.1 现在的里程标是如何工作的 170

案例分析12.1 模糊的里程标会给项目带来什么影响？ 172

12.2 模糊的里程标 173

12.3 里程标和小里程标 173

12.5 制定精确的里程标 174

12.4 什么时候使用里程标 174

案例分析12.2 取消项目的花费 175

检查点1.0 收集基本需求 176

检查点1.1 收集技术需求 177

检查点1.2 收集资源需求 177

检查点2.0 基本可行性研究 178

检查点2.1 技术可行性研究 179

检查点2.2 资源可行性研究 180

检查点3.0 起草体系结构规范 180

检查点3.1 项目初始化 180

12.6 定义里程标 181

12.6.1 差的里程标 182

12.6.2 好的里程标 184

案例分析12.3 一个发生在现实生活中的里程标 185

12.6.4 里程标的评价 186

12.6.3 研究以及截止日期 186

第13章 步骤和流程 187

13.1 步骤 187

13.1.1 检查 188

13.1.2 总体测试 190

13.2 流程 194

案例分析13.1 愚蠢的流程 197

13.3 步骤：什么时候使用 198

13.3.1 设计阶段 199

13.3.2 开发阶段 201

13.3.3 测试阶段 202

13.4 源控制和代码检查：协同 202

案例分析13.2 不需要源控制 203

源控制用来干什么？ 204

13.5 信息传递的重要性 204

前摄的信息传递和被动的信息传递 206

第14章 疑难解答 208

风险 210

14.1.1 设计和体系结构问题 212

案例分析14.1 不听劝告的管理人员 214

14.1.2 进度表威胁 218

案例分析14.2 重新调整进度表 221

14.1.3 组织机构的问题 222

14.1.4 合同问题 223

14.1.5 人员问题 224

14.1.6 开发问题 225

14.1.7 过程问题 227

第15章 游戏业的未来 229

15.1 游戏业现状 229

15.1.1 第一时期 229

15.1.2 第二时期 230

15.1.3 第三时期 230

15.1.4 游戏中的暴力 232

15.2 新模块开发者 235

案例分析15.1 对开发者来说很艰难 236

15.3 在线革命 238

15.3.1 在线交付游戏 238

15.3.2 在线玩游戏 238

第三部分 游戏体系结构 241

第16章 当前的开发方法 243

16.1 游戏开发技术的历史 244

16.1.1 最初的游戏创意的兴衰 245

16.1.2 开发环境 248

16.2 现在的情况 254

复用能力 255

第17章 初步设计 257

17.1 开始 258

案例分析17.1 《雷神之锤Ⅱ》中的抽象 259

17.2 硬件抽象 260

17.2.1 图形硬件抽象 260

17.2.2 声音硬件抽象 263

17.2.3 其他硬件问题 264

17.2.4 “不构造在这里”可能更好 268

17.2.5 模糊地带 269

17.3 问题域 270

什么是游戏？（回顾） 270

17.4 以token的方式考虑 271

17.4.1 Pong游戏的token化 272

17.4.2 Pac-Man的token化 277

17.4.3 状态转换及属性 282

案例分析17.2 缺乏灵活性产生的陷阱 283

第18章 技术的使用 288

18.1 美工的状态 290

18.1.1 3D引擎的起落 290

18.1.2 技术的理解 295

案例分析18.1 第一印象 295

18.2 不保险的研究 299

18.2.1 研究的类型 300

案例分析18.2 忽略了可能存在的机会 301

案例分析18.3 俄罗斯方块：一个告诫 304

案例分析18.4 《时空英豪》：技术的很好运用 305

18.2.2 做好工作日志 305

18.3 重新发明轮子 306

18.4 使用对象技术 307

抽象方法的利弊 310

第19章 建立模块 312

软件中的代码重用 313

19.1.1 代码重用 313

案例分析19.1 引擎重用 313

19.1.2 设计重用：模式 314

19.1.3 特定于游戏的模式 347

20.1 体系结构的诞生 348

第20章 初始体系结构设计 348

体系结构的概念 349

20.2 层式系统 353

20.2.1 0层：原型 354

案例分析20.1 一个数据库驱动的方法 357

20.2.2 一层及其上各层 357

20.3 体系结构设计 360

20.3.1 将基于层的方法用于架构设计 362

案例分析20.2 讨论Warbots的架构 363

20.3.2 体系结构的正交性 364

第21章 开发 365

21.1 开发过程 365

编码标准 367

21.2 代码质量 367

21.3 编码优先级 385

21.3.1 速度 385

21.3.2 规模 386

21.3.3 灵活性 386

21.3.4 可移植性 387

21.3.5 可维护性 387

21.4 调试和模块完成 387

Bug的类型 388

案例分析21.1 是A类bug吗？ 389

21.5 7个黄金法则 392

21.5.1 重用 392

21.5.4 进度表 393

21.5.3 先设计 393

案例分析21.2 可重用的体系结构 393

21.5.2 文档 393

21.5.5 在项目进行过程中捕捉错误 394

21.5.6 控制研发程度（R D） 394

21.5.7 知道什么时候划定最后界限 394

21.6 3种毫无作用的行为 394

21.6.1 糟糕的管理 395

21.6.2 特性蔓延 395

21.6.3 编码人员的僵化 395

第22章 发布前的预备阶段 396

22.1 后期评估 397

22.1.1 最终分析 397

案例分析22.1 一起自食其果的灾难 398

22.1.2 游戏达到标准了吗？ 398

案例分析22.2 一份恢复计划 400

案例分析22.3 许可协议地狱 403

案例分析22.4 最后的疯狂 403

22.2 后期的本地化 404

22.2.1 许可协议 405

22.2.2 语言 405

22.2.3 Demos 406

案例分析22.5 把游戏拱手交出去 406

案例分析22.6 留一手 407

22.3 玩法测试 407

案例分析22.7 他们怎么会没有发现呢？！ 408

22.4 焦点小组 409

22.5 网站 410

22.6 为Gold Master准备就绪 411

22.7 补丁 411

第23章 事后剖析 414

案例分析23.1 两个项目的故事 415

23.1 团队动力 417

案例分析23.2 所有可怕的错误 417

23.2 概念 419

23.2.1 趋势 420

案例分析23.3 对趋势的错误判断 420

23.2.2 亲和力 422

23.3 开发阶段 423

案例分析23.4 地下密牢 424

23.3.1 软件计划 424

23.3.2 编码 425

23.3.3 测试 426

23.4 商业方面 426

案例分析23.5 保证你的资金流 426

23.5 事后剖析本身的事后剖析 427

第24章 游戏开发的未来 428

24.1 基于背景开发 428

24.2 未来开发 431

24.2.1 市场营销 431

案例分析24.1 市场意味着定位 432

24.2.2 内容 433

案例分析24.2 无战略的开发 433

24.2.3 计划 435

24.2.4 开发人员 436

24.3 虽小仍美 437

24.4 未来团队的建立 437

24.4.1 角色 437

24.4.2 动机 439

24.4.3 士气 440

24.5 开发中的新方向 441

24.5.1 整体方法 441

24.5.2 “侏罗纪公园”软件 443

24.5.3 固有的及超然的世界 444

24.6 未来事物的定形 446

第四部分 附录 449

A.1.2 游戏玩法概述 451

A.1.1 弹珠游戏简介 451

A.1 详细设计讨论 451

附录A 游戏设计文档样例 451

A.1.3 平台 452

A.1.4 时间比例 453

A.1.5 为什么迷宫类游戏今不如昔？ 453

A.1.6 迷宫类游戏魅力 454

A.1.7 为什么弹珠游戏如此出色？ 454

A.1.8 游戏设计：用户界面元素 456

A.1.9 弹珠的物理学 459

A.1.10 方块 464

A.1.11 特殊例子——方块之间的碰撞 466

A.1.12 玩游戏 468

A.1.13 更多的修饰 469

A.3.1 概述 472

A.2 初步设计和样例设计 472

A.3 芝加哥黑帮：在20年代繁荣的美国地下社会 472

A.3.2 游戏目标 473

A.3.3 图形 474

A.3.4 进入游戏 476

A.3.5 角色类型 477

A.3.6 角色个性 480

A.3.7 命令 481

A.3.8 战斗 482

A.3.9 游戏世界 483

A.3.10 营业场所 485

A.3.11 消息 488

A.3.12 战役指南 488

A.3.14 营救者 490

A.3.13 目标平台 490

A.3.15 游戏元素 491

A.3.16 游戏怎么玩？ 495

A.4 技术规约 497

技术规约：弹珠游戏完全3D置入式图形模块 497

A.5 代码评审表 512

A.6 测试脚本 513

附录B 参考文献 514

B.1 参考书目 514

B.2 期刊 516

B.3 新闻组 516

术语表 517