游戏设计文档

1.想法与设计决策

“蛇应该保护下的蛋”这是想法；

“只要巢中有蛋，母蛇就不会远离巢的可视范围，如果敌人出现在巢的50米以内，母蛇就会放弃其他任何活动返回巢中以保护蛇蛋，只要敌人不离开蛇就不离开”这就是决策；

区别是什么：想法是抽象的，决策是要实施的，是要具体执行的，我们必须具体到每个细节的设定；

2.设计文档的格式和风格

特点：

• 1.便于阅读：让别人明白设计师到底表达的是什么意思，什么内容；
• 2避免重复，一改则全改；
• 3.简洁明确：注意文档的用途，设计文档最重要的是让开发团队理解设计师的意图

  3.设计文档涉及（不涉及）的内容

• 应该包含的：与环境有关的世界观，故事背景，角色，道具，实体对象，游戏进程，大体让玩家了解游戏；

  与游戏规则的相关的行动规则，战斗规则，多人团队规则，经济系统规则，升级体制，打造系统，界面操作，视角定义

  与任务开发相关的美工，音乐风格及任务列表；

• 不包含的内容：美术设计方面的细节内容，动画脚本，特效构成，技术设计方面的细节内容，引擎结构，程序模块等，游戏的市场销售内容，包括销售策略，预算和其他项目管理信息；

  4.设计文档编写的误区

• 编写过于简单：内容肯定不会过少，四五十页的是一般水平：不要写模糊性的词语甚至直接省略号一笔带过，这是很不负责任的，“游戏会很有趣”，“战斗会很激烈”这是很没有意义的词语，记住永远不要说像什么，会什么，而是具体的描述出来；

• 不要过多的去描写背景故事：设计文档更偏向于一种应用文体的参考资料，不是小说，因此类似索引目录的东西是需要的；

• 设计的不要过于繁琐：设计文档应限于游戏的操作方面而非艺术方面，我们可以描写，角色可以会轻功，具体的怎么会轻功，是怎么设计的，这不是我们要关心的事情，我们有美术——；游戏的数值设定的问题，我们可以描述双筒猎枪比步枪的精度小，准确性低，但规定本身的数值就没有什么意义了，因为数值我们完全可以在后期游戏测试的时候去进行测试修改

• 过多的幻想：一句话，一切可以以技术达到的为准，技术达不到想的再多也是空想

• 文档要即是更新，程序代码有SourceSafe，开发文档也是啊

•