游戏架构与设计 第2版PDF|Epub|txt|kindle电子书版本网盘下载

游戏架构与设计 第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 Demos406

案例分析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