手工艺的什一税.ppt

怎样写优秀的设计文档 Damion Schubert Bioware Austin 关于我 超过10年的MMO设计者 其中大部分的主设计师 过去常和非常复杂的系统工作 成长为可以评价好的文档进程. 发现成为“文档人”对我的职业生涯是非常有益的 仍在学习怎样做得好 我听到的 “设计文档是浪费时间” “没人阅读设计文档。” “我的程序员发现检查设计文档占用了全部的时间。” 这或许是一个关于你的文档的说明，通常并不是一个文档的真正遗嘱。 严峻的事实 所有的设计师应主动共享他们的想法 所有程序员（以及其他的团队成员）应主动了解他们所做的事情。 另一方面，绝大多数设计文档不太好，大部分文档进程忽视了发现乐趣的迭代性质。 要讲述的 设计文档的目标 为什么好的设计文档很珍贵 撰写游戏设计文档的规则 给领导的告诫 – 建立一个游戏设计文档的进程 陈述的焦点： 经理的简略/远景文档 设计概要文档/DDRs 测试计划 优秀文档的目标 为什么好的设计文档如此珍贵？ 大多数游戏的设计文档处理复杂、相关联的系统。 设计者倾向于保险的设计。 设计系统的时间少于构建的时间。 “愚蠢的大预定” 大多数设计文档不包含迭代。 大多数文档很少随项目进程进行更新。 优秀设计文档的规则 其他开发者的话： “ 就给我一些简短、目标明确、必威体育精装版的东西。” 1. 了解你的目标 对一份设计文档感兴趣的人： 设计团队。 达成设计共识。 程序团队。 制作游戏。 制作人。 制订时间表并获得资金。 QA. 建立测试计划。 外部伙伴。 达到恼人的需求的限额。 1. 了解你的目标 程序员 是最重要的目标。 他们是游戏如何做出来的关键。 通常，不管怎么说其他文档对其他读者来说是更有用的。 当心存疑虑时，让文档为程序员服务。 询问程序员他们想要的是什么 如果他们说忽略一条我的规则，就照着做！ 2. 保持简短 简短的文档是： 更容易阅读 更容易撰写 更容易保养并保持更新 更容易精明地处理 不太可能充满矛盾 更可能是简单的设计 2. 保持简短 消灭错误 消灭空白部分 消灭 ‘剪切和粘贴’ 的材料 消灭明白的系统里多余的文本 2. 保持简短 2. 保持简短 2. 保持简短 2. 保持简短 2. 保持简短 记住： 程序员几乎总是想要一个简短的子弹列表 (他们有点喜欢从列表上核对事情) 3. 区分设计的优先顺序 给特色一个优先级，把它们分到不同阶段中去 确定文档里清楚地将后期阶段的特色分离了出来。 3. 区分设计的优先顺序 3. 区分设计的优先顺序 3. 区分设计的优先顺序 装备基本要素 (原型) 3. 区分设计的优先顺序 阶段 1： 原型特色 (为使游戏生效或演示游戏所必需的) 阶段 2： 核心特色 (容纳内容创作的特色和工具在这里) 阶段 3： 必须在已发行的产品里 (包括基于前2个特色的其他特色) 阶段 4： 愿望列表，可能的扩展 阶段 5： 耶，好了 3. 区分设计的优先顺序 优先化要贯穿项目，而非特色——1个完整的特色或文档可包含了阶段2、阶段3、或阶段4的特色。 4. 举例说明 一张图片胜过千言万语。 战术： 其他有着相似特点的游戏的截图。 Visio 图表 ‘例子’ 文本 4. 举例说明 4. 举例说明 兽人 精灵 矮人 霍比人 狮人 图片越抽象，对读者来说就更容易突出他自己的观点 * 假设你有一个能干的、待遇不错的UI美术，你要给他想象空间——别试着做他的工作！ * 理解漫画，Scott McCloud。 我认真地希望每个人都读过这个。 5. 别告诉其他人怎么做他们的工作 5.别告诉其他人怎么做他们的工作 5.别告诉其他人怎么做他们的工作 6. 使用用户故事 中立 – 不要重复其他的用户故事 可磋商 – 细节和完成与最终用户满意相对不太重要。 有价值 – 写出脑海里的最终用户。 可评估 – 对程序员到设计师和时间表来说足够详细。 短小 – 不超过一星期。 可测试 – 当完成时设计和编程都认可。 6.使用用户故事 6.使用用户故事 7. 根据内容分别编码 7. 根据内容分别编码 7. 根据内容分别编码 不要让人搜寻他们想要的信息。 把内容分离到附录中，或表格中。 8. 投入一个好的格式 使用一个团队模板 更换字体 使用水平线 为例子使用标注框 使用符号目录 但是 别成为你格式的奴隶 差异万岁 这是微软PPT的初始模板 看上去不太好，对吧？ 花一点时间改变你的字体或加一个水印能大大增强你文档的专业性的感觉。 9. 使用清晰的术语 9.使用清晰的术语 使用标准的英语 避免模糊的措辞 避免公司性质的措辞 坚持使用新措辞 参考一份辞典 10. 杀光冗余 复制是魔鬼、导向混乱、更新错误