书籍详情
游戏架构与设计（第2版）
作者：（美国）罗林斯等著、付煜等译
出版社：红旗出版社
出版时间：2005-03-01
ISBN：9787505110243
定价：¥58.00
购买这本书可以去
内容简介
本书由浅入深，讲解透彻，是一本非常好的游戏开发书籍。本书内容广泛，适合于游戏设计流程中的各个环节的游戏设计人员，包括游戏等策划师、项目经理、程序员、美工等。本书是游戏设计的经典之作，是所有游戏工作者的案头必备之书。本书系统、全面地讲述了游戏设计流程的各个方面。全书共分为三个部分和两个附录，第一部分介绍了游戏设计中的一些基本概念，如游戏组成、游戏可玩性、游戏平衡、游戏观感等；第二部分介绍了游戏设计过程中的团队组建和管理，以及游戏开发的各个步骤；第三部分讨论了游戏的体系结构，同时探讨了游戏大师的设计方法学；附录给出了几个游戏的详细设计文档，很有实用价值。
作者简介
Andrew Rollings拥有伦敦帝国理工学院（Imperial College， London）和英国布里斯托大学（Bristol University）的物理学学士学位。从1995年起，他就担任许多行业的技术和设计顾问，Andrew居住在美国阿拉巴马州的奥本亚市。
目录
第一部分 游戏设计
第1章 初步概念
1.1 新技术的震撼
1.2 创造性指导方针
1.3 形成创意
1.3.1 灵感
1.3.2 合成
1.3.3 共鸣
1.3.4 汇聚
1.4 修正创意
戏剧效果
1.5 论述
1.6 审查
1.6.1 分析
1.6.2 评估
1.6.3 论证
案例分析1.1 一页的展示
1.7 可行性
1.7.1 商业因素
1.7.2 技术因素
1.7.3 开发因素
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 创建游戏规格说明
案例分析2.3 集成游戏目标
2.4.1 特色
案例分析2.4 一个浮现的实例
2.4.2 游戏可玩性
2.4.3 界面
案例分析2.5 优美界面
2.4.4 规则
案例分析2.6 规则必须为特色服务
2.4.5 关卡设计
案例分析2.7 有趣的关卡设计
2.5 游戏规格说明举例
案例分析2.8 游戏说明
2.5.1 原型的价值
2.5.2 文档的必要性
第3章 游戏可玩性
3.1 游戏可玩性
3.1.1 游戏可玩性的实现
3.1.2 支配性策略问题
3.1.3 准支配
案例分析3.1 环境+规则=游戏的可玩性.
3.1.4 投资支持
3.1.5 多功能性
案例分析3.2 出乎意料的多功能性
3.1.6 补偿因素
案例分析3.3 平衡补偿因素
3.1.7 非永久性
3.1.8 影子成本
案例分析3.4 《帝国时代》的影子成本
3.1.9 协作
3.1.10 游戏可玩性的最后评论
3.2 互动
3.2.1 互动的种类
案例分析3.5不同种类的互动
3.2.2 为什么，与什么?
第4章 详细设计
4.1 设计师的作用
案例分析4.1 开发时限
4.2 设计文档
4.2.1 游戏可玩性规格说明
4.2.2 设计师的备注
案例分析4.2 针对规格说明编制文档一
4.3 使用设计文档
4.4 使设计适应开发
层和试验台
案例分析4.3 计划详细规格说明以适应
体系结构
4.5 为什么要使用文档
第5章 游戏平衡
5.1 玩家，玩家平衡
对称
5.2 玩家／游戏可玩性平衡
案例分析5.1 这样有趣吗?
5.2.1 奖赏玩家
5.2.2 让机器来做这件事情
5.2.3 创作可玩性游戏
案例分析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预料之外的情节发展
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 开发
7.1.5 团队
7.1.6 成本和时间期限
7.1.7 游戏可玩性
7.1.8 未来展望
第8章 游戏设计的未来一
8.1 设计的必要性
8.1.1 别害怕作计划
案例分析8.1 设计节省了时间
8.1.2为 什么进行设计是很好的行为
案例分析8.2 及时更新设计
8.2 游戏设计的本质
8.2.1 它是原创吗?
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 创意的十字路口
案例分析8.4 舞台剧的范例
8.5 游戏如娱乐
8.6 前进之路
第二部分 团队组建和管理
第9章 当前的团队管理方式
当前的开发模式
9.1.1 游戏业的起源
9.1.2 游戏开发者的难题
9.1.3 存在问题的开发者
9.1.4 加班时间过长意味项目的失败
9.1.5 规则的例外
案例分析9.1 《雷神之锤》、 《星际争霸》与《幽浮——突击者》
第10章 角色和部门
10.1 分派人员
10.1.1 管理和设计部门
10.1.2 编程部门
10.1.3 美工部门
10.1.4 音乐和杂项部门
10.1.5 支持和质保部门
10.2 提高士气和工作环境
10.2.1提高士气和改善工作环境
10.2.2 士气高涨的告诫和警告
10.3 分散风险
第11章 软件厂
11.1关于软件工厂
11.2 为什么使用软件工厂
解决游戏开发问题
案例分析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 知道什么时候使用哪个团队——并行开发时间表
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 起草体系结构规范
检查点3.1 项目初始化
12.6 定义里程标
12.6.1 差的里程标
12.6.2 好的里程标
案例分析12.3 一个发生在现实生活中和里程标
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 开发阶段
13.3.3 测试阶段
13.4 源控制和代码检查：协同
案例分析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 开发问题
14.1.7 过程问题
第15章 游戏业的未来
15.1 游戏业现状
15.1.1 第一时期
15.1.2 第二时期
15.1.3 第三时期
15.1.4 游戏中的暴力
15.2 新模块开发者
案例分析15.1 对开发者来说很艰难
15.3 在线革命
15.3.1 在线交付游戏
15.3.2 在线玩游戏
第三部分 游戏体系结构
第16章 当前的开发方法
16.1 游戏开发技术的历史
16.1.1 最初的游戏创意的兴衰
16.1.2 开发环境
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 状态转换及属性
案例分析17.2 缺乏灵活性产生的陷阱
第18章 技术的使用
18.1 美工的状态
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 重新发明轮子
18.4 使用对象技术
抽象方法的利弊
第19 章建立模块
软件中的代码重用
19.1.1 代码重用：
19.1.3 特定于游戏的模式
第20章 初始体系结构设计
20.1 体系结构的诞生
体系结构的概念
20.2 层式系统
20.2.10 层：原型
案例分析20.1 一个数据库驱动的方法.
20.2.2 一层及其上各层
20.3 体系结构设计
20.3.1 将基于层的方法用于架构设计
案例分析20.2讨论Warbots的架构
20.3.2 体系结构的正交性
第21章 开发
21.1 开发过程
21.2 代码质量
编码标准
21.3 编码优先级
21.3.1 速度
21.3.2 规模
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 控制研发程度(R&D)
21.5.7 知道什么时候划定最后界限
21.6 3 种毫无作用的行为
21.6.1 糟糕的管理
21.6.2 特性蔓延
21.6.3 编码人员的僵化
第22章 发布前的预备阶段
22.1 后期评估
22.1.1 最终分析
22.1.2 游戏达到标准了吗?
案例分析22.1 一起自食其果的灾难
案例分析22.2 一份恢复计划
案例分析22.3 许可协议地狱
案例分析22.4 最后的疯狂
22.2 后期的本地化
22.2.1 许可协议
22.2.2 语言
22.2.3 Demos
案例分析22.5 把游戏拱手交出去
案例分析22.6 留一手
22.3 玩法测试
案例分析22.7 他们怎么会没有
发现呢?!
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 开发阶段
23.3.1 软件计划
案例分析23.4地 下密牢
23.3.2 编码
23.3.3 测试
23.4 商业方面
案例分析23.5 保证你的资金流
23.5 事后剖析本身的事后剖析
第24章 游戏开发的未来
24.2.1 市场营销
案例分析24.1 市场意味着定位
24.2.2 内容
案例分析24.2 无战略的开发
24.2.3 计划
24.2.4 开发人员
24.3 虽小仍美
24.4 未来团队的建立
24.4.1 角色
24.4.2 动机
24.4.3 士气
24.5 开发中的新方向
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 战斗
A.3.9 游戏世界
A.3.10 营业场所
A.3.11 消息
A.3.12 战役指南
A.3.13 目标平台
A.3.14 营救者
A.3.15 游戏元素
A.3.16 游戏怎么玩?
A.4 技术规约
技术规约：弹珠游戏完全3D置入式
图形模块
A.5 代码评审表
A.6 测试脚本
附录B 参考文献
B.1 参考书目
B.2 期刊
B.3 新闻组
术语表
24.1 基于背景开发
24.2 未来开发
案例分析19.1 引擎重用
19.1.2 设计重用：模式
第1章 初步概念
1.1 新技术的震撼
1.2 创造性指导方针
1.3 形成创意
1.3.1 灵感
1.3.2 合成
1.3.3 共鸣
1.3.4 汇聚
1.4 修正创意
戏剧效果
1.5 论述
1.6 审查
1.6.1 分析
1.6.2 评估
1.6.3 论证
案例分析1.1 一页的展示
1.7 可行性
1.7.1 商业因素
1.7.2 技术因素
1.7.3 开发因素
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 创建游戏规格说明
案例分析2.3 集成游戏目标
2.4.1 特色
案例分析2.4 一个浮现的实例
2.4.2 游戏可玩性
2.4.3 界面
案例分析2.5 优美界面
2.4.4 规则
案例分析2.6 规则必须为特色服务
2.4.5 关卡设计
案例分析2.7 有趣的关卡设计
2.5 游戏规格说明举例
案例分析2.8 游戏说明
2.5.1 原型的价值
2.5.2 文档的必要性
第3章 游戏可玩性
3.1 游戏可玩性
3.1.1 游戏可玩性的实现
3.1.2 支配性策略问题
3.1.3 准支配
案例分析3.1 环境+规则=游戏的可玩性.
3.1.4 投资支持
3.1.5 多功能性
案例分析3.2 出乎意料的多功能性
3.1.6 补偿因素
案例分析3.3 平衡补偿因素
3.1.7 非永久性
3.1.8 影子成本
案例分析3.4 《帝国时代》的影子成本
3.1.9 协作
3.1.10 游戏可玩性的最后评论
3.2 互动
3.2.1 互动的种类
案例分析3.5不同种类的互动
3.2.2 为什么，与什么?
第4章 详细设计
4.1 设计师的作用
案例分析4.1 开发时限
4.2 设计文档
4.2.1 游戏可玩性规格说明
4.2.2 设计师的备注
案例分析4.2 针对规格说明编制文档一
4.3 使用设计文档
4.4 使设计适应开发
层和试验台
案例分析4.3 计划详细规格说明以适应
体系结构
4.5 为什么要使用文档
第5章 游戏平衡
5.1 玩家，玩家平衡
对称
5.2 玩家／游戏可玩性平衡
案例分析5.1 这样有趣吗?
5.2.1 奖赏玩家
5.2.2 让机器来做这件事情
5.2.3 创作可玩性游戏
案例分析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预料之外的情节发展
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 开发
7.1.5 团队
7.1.6 成本和时间期限
7.1.7 游戏可玩性
7.1.8 未来展望
第8章 游戏设计的未来一
8.1 设计的必要性
8.1.1 别害怕作计划
案例分析8.1 设计节省了时间
8.1.2为 什么进行设计是很好的行为
案例分析8.2 及时更新设计
8.2 游戏设计的本质
8.2.1 它是原创吗?
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 创意的十字路口
案例分析8.4 舞台剧的范例
8.5 游戏如娱乐
8.6 前进之路
第二部分 团队组建和管理
第9章 当前的团队管理方式
当前的开发模式
9.1.1 游戏业的起源
9.1.2 游戏开发者的难题
9.1.3 存在问题的开发者
9.1.4 加班时间过长意味项目的失败
9.1.5 规则的例外
案例分析9.1 《雷神之锤》、 《星际争霸》与《幽浮——突击者》
第10章 角色和部门
10.1 分派人员
10.1.1 管理和设计部门
10.1.2 编程部门
10.1.3 美工部门
10.1.4 音乐和杂项部门
10.1.5 支持和质保部门
10.2 提高士气和工作环境
10.2.1提高士气和改善工作环境
10.2.2 士气高涨的告诫和警告
10.3 分散风险
第11章 软件厂
11.1关于软件工厂
11.2 为什么使用软件工厂
解决游戏开发问题
案例分析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 知道什么时候使用哪个团队——并行开发时间表
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 起草体系结构规范
检查点3.1 项目初始化
12.6 定义里程标
12.6.1 差的里程标
12.6.2 好的里程标
案例分析12.3 一个发生在现实生活中和里程标
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 开发阶段
13.3.3 测试阶段
13.4 源控制和代码检查：协同
案例分析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 开发问题
14.1.7 过程问题
第15章 游戏业的未来
15.1 游戏业现状
15.1.1 第一时期
15.1.2 第二时期
15.1.3 第三时期
15.1.4 游戏中的暴力
15.2 新模块开发者
案例分析15.1 对开发者来说很艰难
15.3 在线革命
15.3.1 在线交付游戏
15.3.2 在线玩游戏
第三部分 游戏体系结构
第16章 当前的开发方法
16.1 游戏开发技术的历史
16.1.1 最初的游戏创意的兴衰
16.1.2 开发环境
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 状态转换及属性
案例分析17.2 缺乏灵活性产生的陷阱
第18章 技术的使用
18.1 美工的状态
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 重新发明轮子
18.4 使用对象技术
抽象方法的利弊
第19 章建立模块
软件中的代码重用
19.1.1 代码重用：
19.1.3 特定于游戏的模式
第20章 初始体系结构设计
20.1 体系结构的诞生
体系结构的概念
20.2 层式系统
20.2.10 层：原型
案例分析20.1 一个数据库驱动的方法.
20.2.2 一层及其上各层
20.3 体系结构设计
20.3.1 将基于层的方法用于架构设计
案例分析20.2讨论Warbots的架构
20.3.2 体系结构的正交性
第21章 开发
21.1 开发过程
21.2 代码质量
编码标准
21.3 编码优先级
21.3.1 速度
21.3.2 规模
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 控制研发程度(R&D)
21.5.7 知道什么时候划定最后界限
21.6 3 种毫无作用的行为
21.6.1 糟糕的管理
21.6.2 特性蔓延
21.6.3 编码人员的僵化
第22章 发布前的预备阶段
22.1 后期评估
22.1.1 最终分析
22.1.2 游戏达到标准了吗?
案例分析22.1 一起自食其果的灾难
案例分析22.2 一份恢复计划
案例分析22.3 许可协议地狱
案例分析22.4 最后的疯狂
22.2 后期的本地化
22.2.1 许可协议
22.2.2 语言
22.2.3 Demos
案例分析22.5 把游戏拱手交出去
案例分析22.6 留一手
22.3 玩法测试
案例分析22.7 他们怎么会没有
发现呢?!
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 开发阶段
23.3.1 软件计划
案例分析23.4地 下密牢
23.3.2 编码
23.3.3 测试
23.4 商业方面
案例分析23.5 保证你的资金流
23.5 事后剖析本身的事后剖析
第24章 游戏开发的未来
24.2.1 市场营销
案例分析24.1 市场意味着定位
24.2.2 内容
案例分析24.2 无战略的开发
24.2.3 计划
24.2.4 开发人员
24.3 虽小仍美
24.4 未来团队的建立
24.4.1 角色
24.4.2 动机
24.4.3 士气
24.5 开发中的新方向
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 战斗
A.3.9 游戏世界
A.3.10 营业场所
A.3.11 消息
A.3.12 战役指南
A.3.13 目标平台
A.3.14 营救者
A.3.15 游戏元素
A.3.16 游戏怎么玩?
A.4 技术规约
技术规约：弹珠游戏完全3D置入式
图形模块
A.5 代码评审表
A.6 测试脚本
附录B 参考文献
B.1 参考书目
B.2 期刊
B.3 新闻组
术语表
24.1 基于背景开发
24.2 未来开发
案例分析19.1 引擎重用
19.1.2 设计重用：模式
猜您喜欢
