目录 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