|
|
发表于 2006-8-29 10:55:00
|
显示全部楼层
Re: 一个疑问
回法师猫，国内有中文版的
不过叫做《游戏架构与设计》，作者是罗林斯ROLLINGS，是游戏开发与编程系列的，应该各大书店有售
http://www.huachu.com.cn/itbook/photo.asp?photourl=../photo/2005/BI05923113c.jpg
这是封面图片
前两个月刚看完，感觉还可以
不会像很初级的入门类书籍，更偏向项目的角度来谈游戏开发，并且夹杂一些精彩创意
以下目录：
目录
第一部分 游戏设计 1第1章 初步概念 31.1 新技术的震撼 31.2 创造性指导方针 41.3 形成创意 51.3.1 灵感 51.3.2 合成 61.3.3 共鸣 71.3.4 汇聚 71.4 修正创意 8戏剧效果 81.5 论述 101.6 审查 111.6.1 分析 111.6.2 评估 111.6.3 论证 11案例分析1.1 一页的展示 121.7 可行性 131.7.1 商业因素 131.7.2 技术因素 131.7.3 开发因素 131.8 写下你的想法 14案例分析1.2 Conquerors的初始论述 14第2章 核心设计 222.1 游戏是什么 222.1.1 酷的特色 222.1.2 奇特的图形 222.1.3 谜题 232.1.4 背景和故事 232.2 游戏不是一切 23案例分析2.1 故事与可玩性 242.3 游戏意味着游戏可玩性 24案例分析 2.2 一个错过的机会？ 242.4 创建游戏规格说明 26案例分析2.3 集成游戏目标 262.4.1 特色 26案例分析2.4 一个浮现的实例 272.4.2 游戏可玩性 282.4.3 界面 29案例分析2.5 优美界面 292.4.4 规则 29案例分析2.6 规则必须为特色服务 302.4.5 关卡设计 30案例分析2.7 有趣的关卡设计 312.5 游戏规格说明举例 32案例分析2.8 游戏说明 322.5.1 原型的价值 342.5.2 文档的必要性 35第3章 游戏可玩性 363.1 游戏可玩性 373.1.1 游戏可玩性的实现 373.1.2 支配性策略问题 383.1.3 准支配 38案例分析3.1 环境+规则=游戏的可玩性 413.1.4 投资支持 433.1.5 多功能性 43案例分析3.2 出乎意料的多功能性 443.1.6 补偿因素 45案例分析3.3 平衡补偿因素 453.1.7 非永久性 463.1.8 影子成本 46案例分析3.4 《帝国时代》的影子成本 463.1.9 协作 473.1.10 游戏可玩性的最后评论 473.2 互动 483.2.1 互动的种类 48案例分析3.5 不同种类的互动 493.2.2 为什么，与什么？ 50第4章 详细设计 524.1 设计师的作用 52案例分析4.1 开发时限 524.2 设计文档 554.2.1 游戏可玩性规格说明 554.2.2 设计师的备注 55案例分析4.2 针对规格说明编制文档 554.3 使用设计文档 564.4 使设计适应开发 58层和试验台 58案例分析4.3 计划详细规格说明以适应体系结构 604.5 为什么要使用文档 61第5章 游戏平衡 625.1 玩家/玩家平衡 62对称 635.2 玩家/游戏可玩性平衡 65案例分析 5.1 这样有趣吗？ 655.2.1 奖赏玩家 665.2.2 让机器来做这件事情 675.2.3 创作可玩性游戏 67案例分析 5.2 保存游戏的问题 675.3 游戏可玩性/游戏可玩性平衡 685.3.1 组件和特性平衡 69案例分析 5.3 Dungeon Keeper中的组件和特性平衡 705.3.2 非传递游戏力学保证平衡 71案例分析5.4 使用SPS的特性平衡 74案例分析 5.5 使用游戏理论分析来实现平衡 785.4 游戏平衡性核对清单 82第6章 外观和感觉 836.1 氛围 836.1.1 声音 84案例分析6.1 最佳音效 846.1.2 视觉 85案例分析6.2 一个荒腔走板的摘记 866.1.3 触觉 866.2 界面 87案例分析6.3 把界面、外观和感觉结合在一起 87案例分析6.4 有时少就是不好 886.3 故事讲述 896.3.1 故事讲述技术工具箱 90案例分析 6.5 外观和感觉文档的例子 926.3.2 转折点 95案例分析6.6 预料之外的情节发展 956.3.3 悬念 976.3.4 对话 976.3.5 主题 986.3.6 结局 98案例分析6.7 不满意的结局 996.3.7 变化 996.4 结束语 100第7章 包装 101专家 1017.1.1 游戏概念 1027.1.2 为变化做计划 1037.1.3 技术 1067.1.4 开发 1077.1.5 团队 1097.1.6 成本和时间期限 1107.1.7 游戏可玩性 1117.1.8 未来展望 113第8章 游戏设计的未来 1158.1 设计的必要性 1158.1.1 别害怕作计划 115案例分析 8.1 设计节省了时间 1168.1.2 为什么进行设计是很好的行为 117案例分析8.2 及时更新设计 1188.2 游戏设计的本质 1188.2.1 它是原创吗？ 1198.2.2 它有一致性吗？ 1198.2.3 它是互动的吗？ 1198.2.4 它吸引人吗？ 1208.2.5 它富于趣味吗？ 1208.3 设计的未来 1218.3.1 让设计更具共性 1218.3.2 非象征性的设计 122案例分析8.3 比较象征性和非象征性的设计 1238.4 游戏的未来 1238.4.1 下一个10年 1248.4.2 软件的强项 1258.4.3 创意的十字路口 126案例分析 8.4 舞台剧的范例 1288.5 游戏如娱乐 1308.6 前进之路 131第二部分 团队组建和管理 133第9章 当前的团队管理方式 135当前的开发模式 1359.1.1 游戏业的起源 1359.1.2 游戏开发者的难题 1379.1.3 存在问题的开发者 1389.1.4 加班时间过长意味项目的失败 1429.1.5 规则的例外 143案例分析9.1 《雷神之锤》、《星际争霸》与《幽浮——突击者》 143第10章 角色和部门 14510.1 分派人员 14510.1.1 管理和设计部门 14610.1.2 编程部门 14710.1.3 美工部门 14710.1.4 音乐和杂项部门 14810.1.5 支持和质保部门 14910.2 提高士气和工作环境 15010.2.1 提高士气和改善工作环境 15010.2.2 士气高涨的告诫和警告 15310.3 分散风险 154第11章 软件工厂 15511.1 关于软件工厂 15511.2 为什么使用软件工厂 156解决游戏开发问题 156案例分析11.1 失去核心成员的影响 157案例分析11.2 代码重用 15811.3 组织软件工厂 15911.3.1 软件工厂的结构 15911.3.2 小组责任和沟通 160案例分析11.3 没有有效地处理问题 161案例分析11.4 有效处理问题的方法 162案例分析11.5 工具重用的好处 16411.4 实施软件工厂结构和方法 16611.4.1 开始 16611.4.2 知道什么时候使用哪个团队——并行开发时间表 16711.4.3 轮换、重新分配组员 168案例分析11.6 必不可少的注释 16811.5 软件工厂的适用性 16911.6 小一些的团队 16911.7 结束语 169第12章 里程标和截止日期 17012.1 现在的里程标是如何工作的 170案例分析12.1 模糊的里程标会给项目带来什么影响？ 17212.2 模糊的里程标 17312.3 里程标和小里程标 17312.4 什么时候使用里程标 17412.5 制定精确的里程标 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 项目初始化 18012.6 定义里程标 18112.6.1 差的里程标 18212.6.2 好的里程标 184案例分析12.3 一个发生在现实生活中的里程标 18512.6.3 研究以及截止日期 18612.6.4 里程标的评价 186第13章 步骤和流程 18713.1 步骤 18713.1.1 检查 18813.1.2 总体测试 19013.2 流程 194案例分析13.1 愚蠢的流程 19713.3 步骤：什么时候使用 19813.3.1 设计阶段 19913.3.2 开发阶段 20113.3.3 测试阶段 20213.4 源控制和代码检查：协同 202案例分析13.2 不需要源控制 203源控制用来干什么？ 20413.5 信息传递的重要性 204前摄的信息传递和被动的信息传递 206第14章 疑难解答 208风险 21014.1.1 设计和体系结构问题 212案例分析14.1 不听劝告的管理人员 21414.1.2 进度表威胁 218案例分析14.2 重新调整进度表 22114.1.3 组织机构的问题 22214.1.4 合同问题 22314.1.5 人员问题 22414.1.6 开发问题 22514.1.7 过程问题 227第15章 游戏业的未来 22915.1 游戏业现状 22915.1.1 第一时期 22915.1.2 第二时期 23015.1.3 第三时期 23015.1.4 游戏中的暴力 23215.2 新模块开发者 235案例分析15.1 对开发者来说很艰难 23615.3 在线革命 23815.3.1 在线交付游戏 23815.3.2 在线玩游戏 238第三部分 游戏体系结构 241第16章 当前的开发方法 24316.1 游戏开发技术的历史 24416.1.1 最初的游戏创意的兴衰 24516.1.2 开发环境 24816.2 现在的情况 254复用能力 255第17章 初步设计 25717.1 开始 258案例分析17.1 《雷神之锤II》中的抽象 25917.2 硬件抽象 26017.2.1 图形硬件抽象 26017.2.2 声音硬件抽象 26317.2.3 其他硬件问题 26417.2.4 “不构造在这里”可能更好 26817.2.5 模糊地带 26917.3 问题域 270什么是游戏？（回顾） 27017.4 以token的方式考虑 27117.4.1 Pong游戏的token化 27217.4.2 Pac-Man的token化 27717.4.3 状态转换及属性 282案例分析 17.2 缺乏灵活性产生的陷阱 283第18章 技术的使用 28818.1 美工的状态 29018.1.1 3D引擎的起落 29018.1.2 技术的理解 295案例分析18.1 第一印象 29518.2 不保险的研究 29918.2.1 研究的类型 300案例分析18.2 忽略了可能存在的机会 301案例分析18.3 俄罗斯方块：一个告诫 304案例分析18.4 《时空英豪》：技术的很好运用 30518.2.2 做好工作日志 30518.3 重新发明轮子 30618.4 使用对象技术 307抽象方法的利弊 310第19章 建立模块 312软件中的代码重用 31319.1.1 代码重用 313案例分析 19.1 引擎重用 31319.1.2 设计重用：模式 31419.1.3 特定于游戏的模式 347第20章 初始体系结构设计 34820.1 体系结构的诞生 348体系结构的概念 34920.2 层式系统 35320.2.1 0层：原型 354案例分析20.1 一个数据库驱动的方法 35720.2.2 一层及其上各层 35720.3 体系结构设计 36020.3.1 将基于层的方法用于架构设计 362案例分析20.2 讨论Warbots的架构 36320.3.2 体系结构的正交性 364第21章 开发 36521.1 开发过程 36521.2 代码质量 367编码标准 36721.3 编码优先级 38521.3.1 速度 38521.3.2 规模 38621.3.3 灵活性 38621.3.4 可移植性 38721.3.5 可维护性 38721.4 调试和模块完成 387Bug的类型 388案例分析21.1 是A类bug吗？ 38921.5 7个黄金法则 39221.5.1 重用 392案例分析21.2 可重用的体系结构 39321.5.2 文档 39321.5.3 先设计 39321.5.4 进度表 39321.5.5 在项目进行过程中捕捉错误 39421.5.6 控制研发程度（R&D） 39421.5.7 知道什么时候划定最后界限 39421.6 3种毫无作用的行为 39421.6.1 糟糕的管理 39521.6.2 特性蔓延 39521.6.3 编码人员的僵化 395第22章 发布前的预备阶段 39622.1 后期评估 39722.1.1 最终分析 39722.1.2 游戏达到标准了吗？ 398案例分析22.1 一起自食其果的灾难 398案例分析22.2 一份恢复计划 400案例分析22.3 许可协议地狱 403案例分析22.4 最后的疯狂 40322.2 后期的本地化 40422.2.1 许可协议 40522.2.2 语言 40522.2.3 Demos 406案例分析22.5 把游戏拱手交出去 406案例分析22.6 留一手 40722.3 玩法测试 407案例分析22.7 他们怎么会没有发现呢？！ 40822.4 焦点小组 40922.5 网站 41022.6 为Gold Master准备就绪 41122.7 补丁 411第23章 事后剖析 414案例分析23.1 两个项目的故事 41523.1 团队动力 417案例分析23.2 所有可怕的错误 41723.2 概念 41923.2.1 趋势 420案例分析23.3 对趋势的错误判断 42023.2.2 亲和力 42223.3 开发阶段 42323.3.1 软件计划 424案例分析23.4 地下密牢 42423.3.2 编码 42523.3.3 测试 42623.4 商业方面 426案例分析23.5 保证你的资金流 42623.5 事后剖析本身的事后剖析 427第24章 游戏开发的未来 42824.1 基于背景开发 42824.2 未来开发 43124.2.1 市场营销 431案例分析24.1 市场意味着定位 43224.2.2 内容 433案例分析24.2 无战略的开发 43324.2.3 计划 43524.2.4 开发人员 43624.3 虽小仍美 43724.4 未来团队的建立 43724.4.1 角色 43724.4.2 动机 43924.4.3 士气 44024.5 开发中的新方向 44124.5.1 整体方法 44124.5.2 “侏罗纪公园”软件 44324.5.3 固有的及超然的世界 44424.6 未来事物的定形 446第四部分 附录 449附录A 游戏设计文档样例 451A.1 详细设计讨论 451A.1.1 弹珠游戏简介 451A.1.2 游戏玩法概述 451A.1.3 平台 452A.1.4 时间比例 453A.1.5 为什么迷宫类游戏今不如昔？ 453A.1.6 迷宫类游戏魅力 454A.1.7 为什么弹珠游戏如此出色？ 454A.1.8 游戏设计：用户界面元素 456A.1.9 弹珠的物理学 459A.1.10 方块 464A.1.11 特殊例子——方块之间的碰撞 466A.1.12 玩游戏 468A.1.13 更多的修饰 469A.2 初步设计和样例设计 472A.3 芝加哥黑帮：在20年代繁荣的美国黑帮火拼 472A.3.1 概述 472A.3.2 游戏目标 473A.3.3 图形 474A.3.4 进入游戏 476A.3.5 角色类型 477A.3.6 角色个性 480A.3.7 命令 481A.3.8 战斗 482A.3.9 游戏世界 483A.3.10 营业场所 485A.3.11 消息 488A.3.12 战役指南 488A.3.13 目标平台 490A.3.14 营救者 490A.3.15 游戏元素 491A.3.16 游戏怎么玩？ 495A.4 技术规约 497技术规约：弹珠游戏完全3D置入式图形模块 497A.5 代码评审表 512A.6 测试脚本 513附录B 参考文献 514B.1 参考书目 514B.2 期刊 516B.3 新闻组 516术语表 517
……目录将就一下，考虑到节省空间 |
|
发表于 2006-8-28 21:31:00
楼主