查看: 835|回复: 23
游戏策划:怎么写好一份游戏策划案？
主题帖子积分
把哪几个方面写清楚、抠明白算及格？你见过的最好的模版是哪个？
主题帖子积分
这是唯独一个虽然我没什么好想法但有发言权的问题。
首先我有收集癖，之前收集了近百个项目的文档，可惜后来硬盘坏了，有微博为证：
&&其次，因为盛大的关系，看过早期街霸的设计文档、魔界村的设定文档、FF的系统文档；多亏中国人遍布世界，让我见过NCsoft、Rovio等公司的设计文档；又因为伟大的黑客，让我目睹wow的技能文档、hellgate的数值文档和一众韩国网游的全部文档；感谢国内的外企，让我见识了EA、UBI、Gameloft等公司的游戏设计案。
其次，因为盛大的关系，看过早期街霸的设计文档、魔界村的设定文档、FF的系统文档；多亏中国人遍布世界，让我见过NCsoft、Rovio等公司的设计文档；又因为伟大的黑客，让我目睹wow的技能文档、hellgate的数值文档和一众韩国网游的全部文档；感谢国内的外企，让我见识了EA、UBI、Gameloft等公司的游戏设计案。
我用人格担保，根本没有规范。几乎每家公司在初期人少时，文档都写的很简略，而到人多之后开始做大作，文档都浩浩荡荡图文并茂。而且个人特色极为鲜明，早期街霸的设计文档，分明就是一些草图漫画……而有的程序员做策划，写的文档几乎就是流程图、状态机和表格的混合体……做UI则有用word、excel、powerpoint、visio、axure、画图、ps、flash、cd甚至autocad的……至于国内策划写的策划案，完全不合格的除外，常见的问题反而是废话太多，因为缺乏足够的功力让程序迅速理解。
说到底，策划案写得好不好真是要看阅读者。比如下图，不懂的只以为是犯罪现场取证，但是张亮看到了就能接收到完整的信息。
国内情况相对国外要离谱，网龙某成绩不算烂的游戏，策划案渣到爆，蓝港有款秒挂的游戏，策划案质量绝对上佳。说到底，产品经理、程序和测试都很给力再加上有运气的时候，策划案真心是浮云（我并不鼓励这种不科学尝试）。反之，策划的思路失误或是设计糟糕，再严谨完美的策划案也是严谨完美的失败品。顺便说下，梦幻诛仙传说一句话“照抄QQ”的聊天系统策划案并不真的存在过。
关于如何写好策划案，我在07年GDC上看过Bioware Austin的Damion Schubert做过的一个报告，至今我认为没有出现更加实用的，因为里面的内容足够了。下载地址是：
http://twvideo01.ubm-us.net/o1/vault/gdc07/slides/S3782i1.ppt
最后给大家看下GTA一代的策划案，根本没什么稀奇：
主题帖子积分
以下，来自1997年Tzvi Freeman关于游戏文档的梳理文章，标题很宏大，叫Creating A Great Design Document，非常详实，且相当有逻辑
我必须做出一个游戏。就在不知失措、头昏眼花之时，我一头撞在了电脑显示屏上。接着，古铜色的灯里轻烟似地冒出了个灯神，许诺我三个愿望。我不假思索地说：“我想要……
*一支有才能、有技巧、有献身精神的程序师和美工组成的团队（包括非常善解人意的老婆一枚）且个个擅长人际交往。
*足够的时间和资金允许搞砸一两次。
*一流的设计文件。
很久以前，编写一款游戏只需要一名程序师（和一名美工）加上接了就做的预算和宽松的开发期限，所以大家对文件编制没必要太上心。你知道想要什么就去做什么。因此，如果在这过程中发生了个把重大变故，你只能责怪你自己。现在，一份周全易读的设计文件意味着什么呢？就是迅速地坠入一文不值的地狱和平稳地飞升到富丽堂皇的天堂之间的差别。
如何展开工作？
大多数游戏的开发从概念到制作完成需要经历三个阶段，即“产生灵感”、“纸上计划”和“身体力行”。
在第一阶段，概念文件不仅是一封写给自己的信——提醒你不要忘记它们；还是一个应对投资商和营销商的销售工具。有时候，还要在这个阶段制作一个微型原型，这样你就可以用它做实验并修改自己的创意。
第二阶段是和一大堆美工、动画师、音乐师和编程人员讨论——实验想法，然后找出组织办法，最后敲定主意。
在最后阶段，管理制作过程的工作通常交给一些擅长处理流程和冲突的行家负责。原创意的设计师可能只允当团队的主要成员，但在许多情况下——特别是在大公司，这位设计师往往变成旁观的顾问。
毫无疑问，如果说设计文件是项目的父母，那么它对项目的成长影响当然最大。即使作为设计师的你兼任项目经理，你也不能欺骗自己：你确实不能全盘兼顾。复杂的项目需要许多有才能的人共同完成。有技术的程序师和美工往往有自己的一套心思。当你打算做一匹马，美工画出的可能是只独角兽，而程序师想到则是吃苦耐劳的骆驼。好的设计文件可以确保大伙想法一致、感觉一致。这好比一支大乐队的爵士乐总乐谱，尽管仍然有大量即兴表演的余地，但在总乐谱统领作用下，大家的心思都被放在一处。
设计文件是想法与现实之间的桥梁。它能确保承载想法的野马不会脱缰跑出现实所能驾驭的范围，同时又保证最后抵达的终点正是最初创意的指向。
最后，记住这句久经玩家证实的格言：“伟大的艺术来自细节”。光彩夺目的细节自然而然地从游戏中流露出来，就好像它们当初从第一道灵感中闪现光芒一样。但是，一旦你进入实际的执行阶段，细节的火花往往容易熄灭。
给项目制做局部原型当然是个好主意——尽可能画出所有草图。但此外，那些细节才是最重要的。你的想象能承载的细节越多，你的作品就会越出色。
根据文件工作也有消极面。刺激的游戏的开发过程本身就必须刺激。例如，有许多项目的闪光点往往是到了令人恐慌的截止期时才被发现。诚然，时间和成本预算的压力不允许概念的不断重复，但你只是不希望做出一款干巴巴、没惊喜的游戏。制作设计文件的挑战在于，能够忍受你的项目发生意料之外的调整，但又不迷失原创意的整体方向和视野。
成功的设计文件十个要点
1、除了形体，还要描述灵魂。 如果游戏开发只是自动输入/输出的问题（就像编写代码和预测过程）——那么你只需要一份干巴巴、描述性的文件就行了。但事实是，开发是人做的， 这些人是有创意的人、有独立想法的人、想在所有自己做的工作上盖个戳的人。
再继续说你想要的那匹马的故事：你把说明书交给美工，然后和他们讨论要做什么。之后你给程序师看了下说明书。两边都对你所说的话点头称是。
当天晚上，大约凌晨2点，正当C++的群星闪烁在西天，处于中年危机的程序师开始胡思乱想：“什么，我的下半辈子就是一个程序呆子？我妈对我的指望就这样？为什么，我也可以像其他人一样设计游戏！“然后继续埋头输代码。
大约与此同时，美工等着他那台陷入死机的电脑完成复杂的3D渲染，等着等着就睡着了，这会儿刚醒过来。他不确定也不关心他是不是在做梦，或者从这些工作中取得报酬，只是沉浸在艺术天才的狂想世界里，在不可思议的幻想和现实的融合作用下，神兽诞生了——当然不是你文件所描述的那匹马。
第二天一大早，你的马，当然没来，来的是长着两个驼峰的独角兽。对于这些创意星人，光给指示行不通，启发才是硬道理。
在你的设计文件中，别满足于对各个物品和细微差别的细节性描述。花时间形容一下游戏应该有的感觉、各个元素潜在的目的、玩家应该有的体验和你可以想到的、能够形容的游戏灵魂的方方面面。
例如，你在设计一款射击游戏。你的目标是通过游戏训练玩家如何应对现实中遇到的某些挑战，所以一开始设定的难度不高。你得向团队的所有成员解释你的用意，这样他们才会理解为什么某些东西要放在这，为什么要这样做。即使你的团队不太认真地对待或胡乱删改你的创意，你仍然可以抱着希望，即结果达到或接近整体效果。或者可能还更好。
2、易读性。给团队成员一份每页标明10个要点、无衬线字体印刷、80个字符一行的文本，并且要求每个人都要阅读。你可能得在每件份文件里准备一捆止痛药了——这是为那些确实要忍痛遵守指令的人准备的。
以下是我遵循的页面布局原则：
文本主体以衬线字体（游戏邦注：指西文中有衬线的字体，与汉字字体中的黑体相对应）印刷粗体字标题
段与段之间有空隙
文本句子简短
引导视线直指重点内容
分层次，大纲视图
用表格、图表、图片等说明例子。把图表、表格、图片等制作得醒目一些。
3、区分优先次序。既然你意识到你是和头脑清楚、有自我的人一起工作，就有必要让这些人意识到某些加标记的游戏元素的神圣性。我确实不敢打包票，但如果你能好好利用标记，你想强调的地方大概还是能得到一点尊重吧。这还没完，既然打了标记，当然还要区分不同的标记含义——有些是你计划要做的，有些是时间、预算和技术允许就做的。
然后垃圾来了——那些听起来很棒，实际上完全有理由当成垃圾的东西。你需要明确地指出来并解释需对其警惕的原因。如果你不这么做，我敢说这些垃圾还是会再跑出来。以下是标记列表：
你可能希望用上一些视觉符号来代替标记。但不要依赖颜色，因为文件不一定总是彩色印刷。
4、深入细节。没有细节的文件毫无用处。大家可以随意地理解大纲。“Thou Shalt Not Kill”（不可杀生） 这句话对摩西来说是一个意思，对西班牙征服者来说是另一个意思。详细地说明哪些角色不能杀、为什么不能杀、还有什么用途。设计文件也是一样：一旦你描述了一些实用的细节并给出相应的例子，你的想法就具体化了——不会被轻易地晒在一边。
例如，不要只说：“铜鸟是无敌的。”明确地描述这家伙被攻击时会发生什么情况及之后如何恢复。确实，如果动画师有脾气又有艺术家的尊严，你可以肯定他不会听从你的指示。但至少他会另想出一个更清楚的、又不违背你的主意，且他的修改不会严重地改变相关的部分。
别只说：“此时，用户会按下带箭头的跳跃键爬上墙。”而是详尽描述如果玩家不那么做会发生什么情况。解释为什么你认为用户能够想到你所提供的操作组合。解释环境暗示玩家爬墙的可能性。
另外，美工也会冒出其他想法，可能比你最初的设想更适合。如果是那样，那就真是太好了，因为成品可能甚至比你的纸上描述更接近你最初的灵感。但除非你一开始就清楚地描述了你的概念，不然这种事不可能发生。
别只说：“Bongo Man 比Bongo Boy更强大，但Bongo Boy的反应更快。”请用表格来表现角色的动作速度值、角色可拥有的攻击点数、角色的攻击伤害点数、发动攻击需要的能量等等。这种表格在Q/A和制作阶段是非常有价值的。
别只说：“大多数人会在几天内想通整个游戏。”制作表格，用于预测不同用户持有的产品的寿命；表明你希望各种功能特征被发现的时间点。之后的用户测试会为下一款游戏的设计提供有价值的反馈。
5、演示某些东西。有时候，几张草稿就够了，但如果这个创意对你的概念和项目确实重要，你可能得亲自制作粗略的动画。当元素的活动太过复杂和模糊，难以用文字表达，你就得制做原型。原型的好处之一是，通过实践往往可以催生更简单更高明的解决方案。
除了提供动画和原型，你还是需要提供概念的文字描述。动画确实比十亿字节的文字更有价值，可是文字也有动画无法达到的交流效果。看动画时可能会遗忘了某些重要的差别，而文字可以清晰地描述出细微之处。
6、别只说“什么”而不说“如何”。在现实世界，“如何”决定了“什么”。例如，假设你已经选择了粘土动画，那么就要制定出捕捉画面的方法，然后在文件中描述这个过程。背景应该用什么材料和什么颜色？应该用什么摄像技术和为什么用这种摄相技术？塑造框架的步骤是什么？等等等。如果你尝试过，你会知道这些因素中的任意一个对结果都有重大影响。
或假设你在制作一款摩托车竞赛游戏。你表示摩托车必须在优势和弱点之间达到平衡，所以你要在文件中提供实现平衡的表格，并注明调整是必要的，还要说明你打算如何实现调整——过程是什么？假设游戏的主要角色是歌剧幽灵。描述玩家的键盘如何映射管风琴键。提供一张各个键的映射图。列举发声的可用渠道的数量。和你的程序师讨论一下怎么实现各个细节，再用文件记录下来。两个不同的“如何”可能会产生非常不同的结果。
7、提供替代性选择。项目经理耗费大把时间在制作甘特图和PERT项目评估上。个人认为，我真的不敢说这种东西对游戏开发是有效的——很大程度上是因为未知的东西太多了。你的游戏技术越激进越新，开发过程中可预测的情况就越少。要保证你的团队达到日程表上的阶段时间点，你能做的不过就是提供另一条通路。（游戏邦注：甘特图：美国工商业管理专家甘特设计的，是一种用平行线表示一定时间内生产的计划数字和实际完成数字的图表；PERT项目评估：在一个给定的项目中对潜在任务进行分析的一种方法。）
我们返回键盘映射管风琴键这个例子。你的程序师向你描述实现最佳效果的最终方法，此法需要50人/小时来执行。因为我们已经讨论过其他事了，所以你已经记下所有东西。
你不能止步于此。你得问：“如果我们只需要一个切边、8槽的管风琴，要费多少人力时间？如果是绝对最小值呢？如是要我们只有几个助理能做这个怎么办？”然后你照旧记下一切。当最后面临抉择之时，你只需要脱口而出：“好吧，计划C。”
在文件设计方面，我犯下的最大的错误就是问程序师：“这办得到吗？”除非你问的是一流的程序师，否则这个问题根本就是白问。更具体地说，回答可以分成以下三种：
（差劲的程序师）：“当然，没问题。”
（一般的程序师）：“不，不能。”
（一流的程序师）：“我这样做要花两周的时间。或者我可以小调整一下，只要五小时。”
总是不忘问另种方法和所需时间。然后表明你的倾向——如果有时间就这样做，否则就做罢。
8、允许修改。灵感和创意往往与兴奋和乐趣同在，我已经警告你要防止闷死这种灵感和自然的创意。你得允许设计文件被你自己或其他人（但愿是有才能的人）修改。
我在British Columbia大学主修音乐作曲时第一次吸取了这个教训。千辛万苦，我终于写好了一个新文艺复兴的铜管五重奏，我真是相当自豪。我的导师也很喜欢。当我们把乐曲拿给学院的铜管乐队演练，然而，在十秒钟的时间内，我的情绪就经历了几个阶段的起伏：惊骇、怀疑、愤怒和沮丧。乐队开始演奏了，一个大号手停下来向其他乐手示意，接着他取出笔开始修改几个音节，然后所有人又继续演奏。这种情况发生了不止一次。
我的导师，注意到我的脸色突然苍白了，转过身来对我说：“别担心，他们对莫扎特的曲子也这样。他们通常是对的。”
真相是，无论在纸上看起来有多好的东西，被置于现实世界的客观解读之下，最棒的专家仍然会修改它。虽然如此，你不想目睹自己的设计和梦想被无情地篡改。你希望自己的灵感以一种自然的姿态成长——永远是那颗你播下的种子，它的成长不经过外来根枝的嫁接。
以下技巧可以帮助你制作出一份可接受修改，又不会中断原始想法或扼杀开发进程的文件：
如果某方面是游戏概念的重点，确保大家牢记于心。
确保所有人领会游戏的灵魂及各个细节的用意。
如果有信息重复，必须互相参照。否则，如有改变，就会产生矛盾指示。
以下是实际执行阶段的技巧：
当有人提出改变时，回头检查你的设计文件，看看它是否和游戏的“灵魂”一致。
检查这是否是独立的改变，或它是否产生系统性影响（牵一发而动全身）。如果是后者，就在下一份计划中拯救它吧。
及时更正设计文件，包括修改的原因。或如果你不想修改，明确指出并解释原因。
修改、删除和否绝想法应该保留在主控文件中，以免重复讨论相同的事。
所有人都必须以相同的版本作为工作对象。过去的版本应该销毁。
重要的、关键的和紧急的一点：设计文件必须置于一人且仅有一人的监管之下。
9、应提供必要的参照和指示内容。我曾见过有些人的文件甚至连页码都没有，结果却抱怨成员没有遵循文件指示。优秀的文字处理器会自动计算页数并且印刷每一页的日期和页眉或页角。有些甚至允许你在新章节里改变页眉。用黑体字印刷重要的内容。你可以随意在不同的部分重申你自己的想法，前提是你把重申的部分相互参照了，这样你就可以一次性更新所有内容。制作一个周全的内容表格。
你可能希望用HTML写下你的文件和运用超链接。有些高级的文字处理器不需HTML也能使用超链接。但记着，人们往往更喜欢看着死复印件文本（因为有了实实在在的文件在手，那么在系统崩溃后重新启动的一个小时内，就还有点东西可以读）。
10、好文件也要好包装。最后，你需要做的就是使文件便于阅读和使用。没有愿意阅读一叠纸——因为看起来也不重要。只有带硬封面的东西看起来才重要。
制作一份应持有复印件人员的名册并进行保存。打印出所有东西，且每一页都要带眉头和日期。接着在每一页上打洞做成活页。最后在每一份活页本的书脊和封面上贴标签。更新时，人手一份校订页。有时，你可能需要提拱新活页本，丢掉旧活页本。
电影制作人使用步骤原稿。建筑师使用蓝图。音乐家使用乐谱。根据古代的传说，甚至是宇宙造物主也制作了设计文件，在最初的文明之光普照大地之前，他让一小撮先知瞄了一眼——所以有了这个古代传说。既然神都是这么做的，那么游戏开发者就以之为榜样吧。
游戏邦注：原文发表于日，所涉数据及事件均以此为准。
另外可以参照的一些内容：
设计教程：如何撰写游戏的特征概要
游戏设计文件撰写原则之理念大纲和项目提案
&&/archives/49779
阐述游戏设计文件撰写原则之技术规格书
/archives/56005
阐述游戏设计文件制作步骤及注意要点
Creating A Great Design Document
by Tzvi Freeman
I’ve got to get product out. In the panic and dizziness, my head smashes against the CRT and next thing I know this genie whiffs up out of a virtual bronze-texture-mapped lamp and offers me three wishes. Without missing a beat, I answer, “I need…
A great team of talented, skilled, and dedicated engineers and artists (including a very understanding wife) with strong interpersonal skills.
Enough time and money to allow for a mess-up or two.
A first class design document.
Once upon a time, when coding a game involved one programmer (and maybe an artist) with a take-it-as-you-go budget and a loose deadline, documentation didn’t need to be taken so seriously. You knew what you wanted to make and you made it. If there were a few major changes along the way, the only one to complain was you. Nowadays, a thorough and readable document can mean the difference between a swift descent to budgetless Hell and a smooth ride to shrinked-wrapped Nirvana.
How the System Works
Most games go through three development stages, from concept to design to production. Think of them as “flash,” “paper,” and “grind.”
In the first stage, the concept paper acts both as a letter to yourself – setting out your goals clearly so you won’t lose sight of them – and as a sales tool for whomever takes the product to market down the road. Sometimes, this stage involves a working mini-prototype as well, which gives you a chance to experiment and revise your ideas.
The intermediate stage of design involves a lot of discussions with artists, animators, musicians, and engineers – trying things out, and finding ways to organize and set down your ideas.
In the final stage, production management is often left up to some expert in moving trains and tracks without major collisions. The original designer may be an integral part of the team, but in many cases – especially in large companies – the designer ends up as a kind of outside consultant.
Without question, the design document is where the original parent of the project exercises the most influence on how this little baby is going to grow up. Even if you, the designer, have decided to double as project manager, don’t delude yourself into thinking that you hold all the reins. A complex project involves many talented people. Skilled programmers and artists tend to have minds of their own. While you intend to create a horse, the artist may be envisioning a unicorn and the programmer a highly efficient camel. A good document ensures that you are all planning to make the same thing. A great document ensures you all have the same feel for the inner soul of this thing. Think of it as a big band jazz score – it puts everybody’s mind in the same place, even when there’s still plenty of room for the stars to improvise.
Your document is a sort of intermediary between your mind and the real world. It ensures that what you have in mind is something that the real world is able to handle, and that what you end up with will be what you originally had in mind.
Finally, remember the adage to which any salty gamer will attest: “Great art is in the details.” Brilliant details flow naturally from the general gestalt as though they were present in that first flash of inspiration. But once you get into the hands-on implementation, it’s easy to lose that spark.
The Challenge
Prototyping parts of the project yourself is definitely a good idea – make whatever rough sketches you can. But again, it’s those details that count. The more details your imagination can hold, the greater a masterpiece your work will be.
Working from a document has a flip side, as well. Developing an exciting game has to be exciting. Some of the best parts of many projects were discovered in the heat of last-minute deadline panic. True, the pressures of time and cost budgeting don’t allow for perpetual reiteration of concept, but you simply cannot expect a killer game to come out of dry, predictable work. The challenge is to create a design document that will allow your project to tolerate surprise adaptations without losing the integrity of its original direction and scope.
Table 1. The three stages of documentation.
Contents Purpose
1. Concept Paper G most cost and time to develop. It defines the concept, scope, worthi sells the idea to your client, publisher, employer, and venture capitalist.
2. Design Document Description of the body and soul of the entire project, with all the details, and the method by which each element will be implemented. It ensures that what is produced is what you want to produce.
3. Production Documents Time-management charts (Gantt, PERT, and so on); tech Q/A database. It implements the design document on time and within budget.
Ten Points for a Successful Design Document
1. DESCRIBE NOT JUST THE BODY, BUT THE SOUL. If game development was just an automated input/output issue – something like writing code and being able to predict how it’s going to work – you could get by with a dry, descriptive document. The reality is that development is done by people, many of them creative people, who
most will want to leave a stamp of that mind on everything they do.
It works like this: You provide specs to the artists and discuss with them what to do. You then visit the programmers and go over their specs. Both groups nod to everything you say.
That night, around 2AM, just as the constellation of C++ is rising in the west, the programmer reaches a mid-life crisis and begins to think, “What, a geek programmer the rest of my life? Is this what my mother expected from me? Why, I can design a game just as well as anybody else!” And the hands keep typing code.
Around the same time, the artist has just woken up before his machine, having fallen into a deep stupor while waiting for a complex 3D rendering to finish. Unsure and not really caring whether he’s dreaming or is actually getting paid for all this, immersed in that wild world of artistic genius where fantasy and reality blend as one, the phosphors come together in ways previously unimagined – certainly not by you.
By the next morning, your horse has become a unicorn with two humps. With creative people, instructing is not good enough. You need to inspire.
In your design document, don’t satisfy yourself with a detailed description of every article and nuance. Take time to describe the feel that the game should have, the purpose behind each element, the experience each user will have, and any other aspects of the game’s soul you can envision and describe.
For example, say you’re designing a shooter. You want to train your players to deal with certain challenges before they actually meet them, so you place less lethal mini-challenges a few steps in advance. You’re going to have to explain that to everybody on the development team, so they’ll understand why certain things are where they are and why they work the way they do. That way, even if (read: when) your team toys with and mangles your ideas as they exist on paper, you can still harbor hopes that the outcome will have the same or similar overall effect. Or maybe even better.
2. MAKE IT READABLE. Go ahead, provide your people with full pages of 10-point, sans serif, 80-characters-per-line text, and demand that they read it. You may want to bundle Advil in the package – for those who actually take the pains to obey orders.
I try to follow at least some of the guidelines of good page layout.
Plenty of white space
Serif font for body text
Bold headers
Spaces between paragraphs
Short lines of text
Direct the eye towards important material
Use a hierarchical, “2D” format (see what I wrote about outliners in the “Design Documentation Tools” sidebar)
Many instances call for a table, spreadsheet, or chart. Use them and make them sensibly attractive.
3. PRIORITIZE. Now that you realize that you’re working with other conscious egos, you’ll appreciate the urgency of tagging certain game elements as sacred. True, there are no guarantees, but if you use the tag sparsely enough, it may get some respect. But don’t stop there. As long as you’re tagging ideas, you’ll also want to distinguish between things that you intend to do and things that you’d like to do if time, budget, skill sets, and technicalities permit.
Then there’s the trash bin – things that sounded great, but were trashed for good reason. Refer to them explicitly and explain the reason that they were trashed. If you don’t, I can almost guarantee that they will be resurrected. Here’s your list of tags:
Indispensable
If Possible
You may wish to use visual symbols to represent these. Don’t rely on color, since documents aren’t always printed in color.
4. GET INTO THE DETAILS. A document without details is useless. Generalities can be interpreted by anybody in any way that they like. “Thou Shalt Not Kill” meant one thing to Moses and another to a Spanish conquistador. Detailing whom you shouldn’t kill and under which circumstances would have been more helpful. The same holds true for your document: Once you’ve described some practical details and given some examples, your idea becomes more concrete – and harder to shove around.
For example, don’t just say, “Bronze bird is invincible.” Describe exactly what happens to this creature in each possible instance of its being hit, and how it recovers afterward. True, if the animator has any spunk and artistic dignity, you can rest assured that he won’t follow your specifications. But at least he’ll have a clear idea of what you want to achieve, and his modifications won’t seriously alter the related portions of the game.
Don’t just say, “At this point, users will have to press the jump key with the arrow key to climb the wall.” Describe what will happen if a player tries anything else. Explain why you think users will be able to figure out the combination that you’ve provided. Explain what about the environment suggests that it’s possible to climb this wall.
Again, your artist will come up with something else, perhaps something even more suitable than what you originally conceived. That’s real success: When your developers’ results come out even closer to your original flash of conception than what you were able to describe on paper. But this won’t happen unless you first lucidly describe your concept.
Don’t just say, “Bongo Man is stronger than Bongo Boy, but Boy has faster reflexes.” Use tables, spreadsheets, and charts to assign real values to the character’s speed of movement, how many hits the character can take, how much damage the character’s hits do, how many cels it takes to animate a hit, and so on. This sort of spreadsheet is invaluable in the Q/A and tweaking stages of production.
Don’t just say, “Most people will figure out the whole game in a few days.” Make a chart of predicted product life in different households, indicating at which points in time you expect various features to be discovered. User testing will later provide valuable feedback for designing your next game.
5. SOME THINGS MUST BE DEMONSTRATED. Sometimes a few rough sketches are enough, but if the idea is truly important to your concept of the project, you may want to make a rough animation yourself. When behaviors of elements become too complex and ambiguous to describe on paper, you’ll want to make a prototype. A side benefit of prototyping is that this practice often leads to a simpler, more elegant solution.
Even when you provide animations and prototypes, put the concept in words as well. True, an animation is worth a gigabyte of words, but words can communicate in ways that animations can’t. Words also clearly spell out the vital nuances that may be missed when watching the animation.
6. NOT JUST “WHAT” BUT “HOW.” In the real world, the “how” determines the “what.” For example, suppose you’ve opted for claymation. Work out the process of how the images will be captured and document everything. What material and what color should the backdrop be? What camera should be used and why? What are the steps for processing the captured frames? And on and on. If you’ve tried it, you’ll know that any one of these factors can have a serious impact on the end result.
Or suppose you’re working on a motorcycle racing game. You state that the motorbikes must be balanced by their differing pros and cons. You even provide a chart that shows how balanced they are. Then you state that tweaking will be necessary. State how you plan to tweak – what is the process? Suppose the main character in your game is the Phantom of the Opera. Describe how the player’s keyboard is mapped as a pipe organ. Provide a map of each key. Specify how many channels of sound will be available. Talk it over with your programmer and work out every detail of how. Then document it. Two different “hows” can mean two very different results.
7. PROVIDE ALTERNATIVES. Project managers spend a lot of time with their Gantts and PERTs. Personally, I can’t really say that this stuff is effective for game development – principally because there are just so many unknowables. The more radical and pioneering your game technology, the less predictable the development stream is going to be. The best thing you can do to ensure that your team reaches your milestones on schedule is to provide more than one way of doing things.
Lets go back to the keyboard as pipe organ example. Your engineer describes to you the ultimate method of getting awesome and funky results with tremendous power and depth to the user – at a cost of about 50 person-hours to implement. As with everything else we’ve discussed, you document the whole thing.
You can’t stop there. You’ve got to ask, “What would it take if we just wanted a trimmed-down, eight-channel pipe-organ? And what will we need to achieve the bare minimum? And what if we just had some assistant doing this?” And then you document all that as well. When the FedEx truck is on its way over for the final daily pickup, you’ll be able to save your skin with a simple, “OK, do Plan C.”
One of the biggest mistakes I’ve made in product design is asking engineers, “Can it be done?” Unless you’re asking a first-class programmer, the question is useless. More specifically, responses fall into one of three categories:
(Lousy programmer) “Sure, that’s no problem.”
(Mediocre programmer) “Nope. Can’t be done.”
(First-class programmer) “I could do it like this and it’ll take two weeks. Or I could make a slight modification like this and it’ll take five hours.”
Always ask for more than one alternative and an estimate of how long each will take. Then indicate your preference – do this is if we have time, or this if we don’t.
8. GIVE IT A LIFE. I’ve already warned you against strangling the inspiration and spontaneous creativity that comes with the excitement and fun of seeing ideas become living objects in your hands. You’ve got to allow your document to tolerate change – by you or by (hopefully intelligent) others.
I first learned this lesson as a music composition major at the University of British Columbia. With much toil, I had written a neo-renaissance brass quintet of which I was quite proud. My professor liked it, too. When we brought it to the college’s star brass quintet for rehearsal, however, I passed through several stages of horror, disbelief, indignation, and clinical depression within ten seconds. The quintet began to play, then stopped on signal from the tuba player. The fellow took out his pencil and began to change a few notes, and then everyone continued. It happened more than once.
My professor, noting my sudden faint state of health, turned to me and commented, “Don’t worry, they did that to Mozart as well. And they’re usually right.”
The fact is, no matter how good something looks on paper, the greatest expert still modifies things when it enters the concrete world of objective perception. Nevertheless, you don’t want to witness the ruthless rape of your design and dreams. Rather, you’re hoping for a kind of organic growth – ideas growing naturally out of the seeds you’ve planted without needing foreign limbs and bodies grafted onto them.
Here are some tips for creating a document that can tolerate change without corrupting the original idea or sabotaging the development process:
Make certain to engrave in stone those aspects that are so essential to the game concept that they must not be changed.
Make certain everybody understands the feel that the game is supposed to have and the purpose of each of its details.
If information is repeated, it must be cross-referenced. Otherwise, if there are changes, you can end up with contradictory instructions.
And here are some tips for the actual implementation stage:
When a change is suggested, check back in your design document and see if it is in concordance with the “soul” of your game.
Check whether this is just an isolated change, or it’s of major global ecological impact (see “The Ecology of Improvement”). If it’s the latter, save it for your next project.
Update the design document and include the reasons for the change. Or if you didn’t make the change, say so and explain why it was rejected.
Changes, deletions, and rejected ideas should be retained in a master document to avoid discussing the same thing twice.
Everyone must be working from the same version. Past versions should be destroyed.
Crucial, Vital, and Urgent: The design document must be maintained under one person’s supervision only.
9. NOBODY SHOULD BE ABLE TO SAY, “I DID IT THAT WAY BECAUSE I COULDN’T FIND ANY REFERENCE TO IT IN THE DOCUMENT.” I’ve seen documents that didn’t even have the pages numbered. And then they complain that people didn’t follow instructions. Every good word processor will auto-number pages and print the date and title in the header or footer of every page. Some will even allow you to change the header at new chapters. Use bold text to direct attention to important material. Repeat yourself in different parts of the document as much as you like, as long as you cross-reference so you can update everything together as well. Make a thorough Table of Contents.
You may wish to write your document using HTML and provide hot links. Some progressive word processors provide hot link capabilities without HTML. But remember that more often than not, people prefer to work from a hard copy. (That way there’s something to read while rebooting after the hourly system crash.)
10. DELIVER IT IN GOOD CONDITION. After all this, you need to do whatever you can to facilitate everyone actually reading and using the thing. A pile of papers doesn’t get read – it doesn’t look important enough. Only things with hard covers look important.
Create a list of everyone who is supposed to have a copy. Keep the list. Print out the whole thing with the date in the header of each page. Have holes made and put it in binders. Label the spine and cover of each binder. When there are updates, provide everyone with the revised pages. At some points, you may need to provide new books and throw out the old ones.
In Sum Check…
Movie makers use move scripts. Architects use blueprints. Musicians use a score. According to ancient hearsay evidence, even the Cosmic Creator created a design document – which He later let a few prophets take a peek at – before the primal “Let there be light!” So game developers, following their Supernal Role Model, can certainly do the same. Do it right and it’s smooth sailing the rest of the way.
Tzvi Freeman teaches Game Design and Documentation at Digipen School of Computer Gaming in Vancouver, British Columbia, Canada. He has designed several commercial games and has acted as a consultant on many others. He can be reached at . （source:gamasutra）
主题帖子积分
手痒，把工作先放一边，简单列一下提纲和要点，细节恕不展开。
首先，在写策划案之前，我们应该先明确一点：为什么要有策划案这种存在。原因有以下：
规整设计者的思路。
准确传达设计者的意图。
帮助开发人员准确理解和评估开发工作量。
4、可以据此
进行工作分配，明确权责。
5、开发完成后，
可根据策划案内容进行验收及测试。
6、后续开发时
可反溯最初设计并进行修改及二次开发。
明确了这些基本目的，你就把握了案子的内容、层级及边界。
其次，“游戏策划案”这个说法太笼统，细说来，系统案子和活动案子有区别，数值案子和美术案子也不相同。但都需要包含以下部分：
1、设计目标、预期效果和实现方向，
2、具体的需求细则、功能流程、表现原型，
3、与其他部分的关联，所占比重、可能造成的影响，
4、可能涉及的资源调配及人员配合，
5、基本的测试用例。
以下的内容偏向系统案，其他的策划案要点相似，细节和表现上有区别）
有关“设计目标、预期效果和实现方向”。这是开篇明义，让阅读文档的人掌握基本要点，简单即可
1、为什么要进行这个设计，它的目的是什么？
2、完成之后你希望他是什么形态？
3、这个开发是已有改进还是全新开发，准备如何实现？
4、补充：如果涉及多个模块，请附上结构图，标明相互关系。
有关“具体需求”。这是策划案主体，要意图清晰，不啰嗦；要一目了然，不绕弯，要便于量化执行
1、细致阐述功能，客观描述，简练，避免歧义，
2、分条罗列需求，尽量细分，尽量全面，避免重复，
3、功能附上流程图，存在选择的情况要有判定流程，
4、前端表现附上页面迁移图，
5、新增数据的，设计好数据表格，
5、页面设计附上原型图及期望的风格概念图。
有关“与其他部分的关联”。游戏是一个整体，各部分是相互关联的，要有全局观。
1、新增部分与原系统是否有所关联，改动会造成何种影响，在具体需求中是否已解决，
2、新增部分对于数值体系的影响在哪，如何进行分配，
3、新增部分与原有部分的相互配合方式。
4、新增部分对整体的影响，计划在游戏生命周期的哪个阶段着力表现。
有关“资源调配和人员配合”。事前明确权责好过事中扯皮事后推诿，如果大家合作愉快这条作罢。
1、完成开发需要哪些资源，
2、完成工作需要的组间配合，
3、各自的工作内容及完成时间。
有关“测试用例”。其实，如果需求写得够明晰，这部分其实很简单，就是比较烦。
2、表现是否正常
3、数据存储调用是否正确
4、分步拆解纠错
5、关联系统对接是否通畅
Tips。（喂！不是说好不展开了吗）
流程图有助于梳理设计思路，条件判定有助于查缺补漏，请细心。
迁移图可以理清你的操作逻辑，在保证功能的基础上，适当减法。
原型图可以简陋，但要点和你期望的焦点功能和布局方式，请凸出。
4、认真设计
数据表格，这些都是日后你要自己填的，请善待自己。
5、策划案要
标题明确，层级清晰，方便通过文档结构图进行查阅与检索。
6、关联其他开发的部分给出
对应文档的名称和所在位置。
7、在策划案里留下历次的
版本修改记录与游戏实际情况保持一致。
最后，一些辅助工具
Mindmanager，思维导图，可以很好展现整体的树状系统结构，也可以详细阐述一个功能，
Axure，页面原型，页面迁移跳转，快速制作可进行操作体验的页面原型，
excel、visio，基本工具，博大精深，
知乎，嗯，开小差的时候不至于有太多负罪感。
最后，我这一篇回答，换个视角就是一个基本的策划案框架思路。
主题帖子积分
其实这个东西不应该由一个策划来答。
一个策划的案子写得好不好，永远只能是和他接口的人员（程序、美术、测试）说了算。
仅从工作角度来看，游戏策划案有以下三个作用：
1.让程序美术明白需求。
2.留档，防止出了问题找不到原因和负责人。也可以看到一个功能经过了哪些修改，这些修改是好是坏。
3.给测试让测试写用例或者给其他合作策划了解你的功能。
因为上面这个原因，策划案也没有什么固定的模版，有的程序只需要几句话就可以开工，有的程序不玩游戏就需要你给个表然后讲上半小时。
一份策划案，通常就包含三个部分：
给服务端看的、给客户端看的、给美术的需求。
这三个部分具体应该写清楚哪方面，是无法用很短的篇幅来形容的，如果真那么容易就讲出来，策划的工作经验就不值钱了。
比如很简单的一个背包，就需要写清楚：横向几格，纵向几格，如何翻页，能翻多少页，是否分栏，分几个栏，背包格数能否扩展，栏目能否扩展，背包满了的时候捡取、交易、完成任务如何处理，要不要做自动排序，如何自动排序，单物品叠加上限多少，筛选怎么做，在不同的功能NPC处有哪些功能按钮，处于不同的功能下有什么样的特殊显示方案等等等等……
+++++++++++++++++++++++++++++++++++++++++++++++++++++
下去抽了根烟，想了想还是再补点东西吧，
关于如何让你的接口人喜欢你写的东西：
后端就画好流程图，写好表格式（你的表要几列，这些列会不会再添加，每列里写的东西最大几位最小几位，是不是有负数、小数等）
前端把交互说清楚，在这里推荐一个软件AXURE，这东西产品经理用得多，但是游戏策划拿来做前端交互说明稿也是相当不错的。
美术就是你给需求的时候最好把样例给出来，百度搜几张图不费劲。还有就是千万要记住，给美术的文本必须要是可复制的，美术比较痛恨的事儿就是经常需要扔下手写笔然后在键盘上自己输入文字。
如果这些想不全，那么不是一个经验丰富的策划；如果完全想不到，那还是好好地当个游戏玩家吧，做游戏不是个好玩的事情。
主题帖子积分
能明白张亮同学在这方面的困惑，但简单地说，最好的策划案是不存在的。不过，能不能这么理解，这个问题的实质是：
如何量化地评估一份策划案？如何通过文本信息评估一个策划？
这是可以做到的。
（先蹲着占个坑，下班了再写吧）
主题帖子积分
初级策划成长中..就我个人现阶段的理解，策划案是给人看的，好的策划案就是能让人看得懂的策划案。
一个策划案，从构思出来的框架案，到最后给相应执行人开发的执行案，我认为在这期间应该至少有3个版本。
第一个版本是构思的框架案，框架案主要作用是讨论玩法的可行性。是写给主策，或者说策划内部讨论用的。在这个阶段，
主要应该阐明的是，这个玩法的设计目的，核心玩法。也就是这个案子是为了解决什么需求，怎样去解决这个需求。抓住设计目的，才能在构思的时候不会脑洞打开跑火车跑的不着边际。
第二个版本是有基本内容的草案。草案的作用（我这边）是召集前后端美术QA进行讨论。主要在于玩法的可实施性。对于现有系统暂不支持的新的需求，在实现上是否有困难。是否有更好更合适的方案来满足设计目的。以及功能基本工作量的计算。在这个阶段，
主要应该阐明的是，案子对于各部门的需求。这需要对各部门的工作内容有一定程度的了解，主要是程序的实现方面。懂一些代码，才不会被程序忽悠这不能做那不能做嘛。
第三个版本是具体需求细化的执行案。在玩法都讨论结束，确定方案可执行以后，就需要细化草案，完成一个可执行的执行案。执行案的作用，顾名思义，是开发人员开发过程中具体的执行文档。
需求是尽可能的细化你的需求。力求做到开发人员在开发过程中碰到的每个疑点都可以在案子中找到答案，例如这个按钮的tips是什么？点击后是否置灰？主要集中在前端的表现上。如果执行案足够详细，那么开发者在开发过程中可以一气呵成，也不会不停的问策划这里要怎么表现，那里要怎么表现。提高开发效率，策划也可以有更整块的时间去构思新的案子。
总而言之，好的策划案，应该针对不同的“读者”，都让他们看到他们想看的东西。
而其中最重要的，还是设计目的吧。手里的项目有的功能开发出来，反思一下都不明白为何要开发这个功能。。我觉得这就是挺失败的案子。
至于模板，还没有觉得非常好的（这边根本没几个模板。。），希望大家有好的模板不吝分享呀！
主题帖子积分
我来谈谈我的观点吧，与伊力其、戴鑫一样，我日常写的文档就是详细的将我心目中的游戏描述出来，得亏我以前写过代码，所以写的时候也会考虑他们如何实现，有时候也会顺带的写一点进去。
1，你总会发现你有一些没有想到或者你默认这个东西大家都这么想的功能模块流程，程序或者美术那儿没想到。好一点的他们会来问你，不好的自己就想当然的做。
譬如：大家可以看看＜放开那三国＞手游的登陆流程，一个流程是确认帐户信息，一个流程是确认登陆服务器信息，当玩家第一次打开这个游戏的时候，如果没联网，服务器信息是不会显示的，如果你这一点没想到，你家程序也许会给你默认显示。然后是当你注册帐户点击确认后，直接进入了推荐服务器进行游戏。如果当时你没有考虑注册帐户后是返回主登陆界面继续选择服务器还是直接就让玩家随便进入推荐服务器玩。程序也许会默认给你一个惊喜。
以上的例子基本上无伤大雅，因为伤大雅的不能说。
2，你将一个策划们讨论好的东西扔给程序美术做，他们就会认为他们只是一个执行者不是参与者，事无巨细的都会来问你，你担责任却没有工作量，他们担着工作量却没有责任，最终会导致很多做一做交差的情况出现。朝九晚五领工资跟工厂上班一样，这样子很难做出好游戏，当然，如果有一个非常有领导能力的人也许会带得动这些人，但是这种人第一难找第二难留第三难养。
3，开发过程中有太多太频繁的迭代了，有时候一个策划案会改特别多版本，改到最后你都可以放到github里做血泪史了。当然也会有懒得改的飘逸型策划，负手而立，站在程序美术后面指点江山，策划案只有初版。然后呢？他效率高，跳槽或者高升了以后，你跑过来一接手，哇靠，确定这是同一个游戏？
在非工作中，我也会想一些点子，整理成我自己风格的策划案。策划案中没有具体的实现，只有愿景和开发块面框架。
比如我想做一个沙滩排球的手游，这个手游的核心块面排球应该怎么打应该怎么做，我有有一个底稿，会以一个附录或者举例的形式描述出来，然后我会想和大家讨论，这个怎么做会比较好，怎么做会有什么风险怎么做会很好操作。让所有人都参与进来，大家都是设计者，最后可能会有一个初步的方案出来，然后迅速开发一版核心模块的demo,然后大家一起来看，什么地方好，什么地方有需要改进的地方。不停的迭代，当这个块面大体满意时，进入下一个块面，沙滩排球的赛程怎么确定，等等。
这种模式就和以前的小手工作坊一样，没有了明显的职业划分，避免了在某一开发阶段，某一类特殊工种无事可干但是其他工种忙得跟狗一样的情况，最后项目中总是缺人，却总是有人没事做，不停加人最后会传染成大家互相推脱的情况。
当然这种模式非常非常非常依赖人，只要团队中有一人离开，这个项目就很可能搁置很久。
偏题这么久，其实我认为的好的策划案是说出了我想做成什么东西，而不是事无巨细的写出我要让你怎么做这个东西。
这样只写出框架会让团队里每个人都知道团队的目标是什么，怎么做就是团队能力的事了。
主题帖子积分
非策划专业人士，应领导要求写过几次策划方案。
不过策划方案这东西个人认为都是通的，要解决以下问题：
1、我们为什么要做一件事
2、我们要怎么做这件事（思路及所需要支撑的条件）
3、我们采取的行动会有哪些收益和弊病，针对这些会有哪些后续方案
4、综合预期
在我这个行业的策划方案基本是这样。
我之所以以一个非策划人士来回答这个问题，是因为你问了
&&你见过的最好的模板是哪个？
我觉得吧，学做一件事，不能只去追求个“最好”，应该追求更好和更合适，自己多看一些方案然后加入自己对项目的理解，然后动笔，多改多问。
主题帖子积分
格式和叙述方式当然其实并不怎样重要
不过我还是习惯要求我带的人写清楚设计目的，并从数据表结构到服务端逻辑、客户端逻辑、美术需求等几个基本点写起
并不只是因为研发的分工，针对不同接口做切合的表达。更重要我希望他们能够尽快弄懂这些内容间的I／O概念
数据库与服务端，服务端与客户端，客户端与美术资源
最后进而要求
数据表的建立在能用后还需考虑扩展性，尽量减少数据关联以及考虑排序遍历的效率
服务端能想到数据存储的时机和方式，模块能够细分到内部无耦合逻辑，判定能够清楚不同顺序的不同结果，与客户端通信需考虑网延并尽量保证信息发送的单向性
客户端能想到减少恶意和不必要的封包发送，不同表现对于美术资源不同的要求
美术资源能够在发出需求前明确包装核心，在不同情景下需要突出什么需要弱化什么，还有尽量详细的原型描述，草图以及示意效果
好了，这就是一个初级策划的及格标准了。
至于更为关键的：我需要一个什么样的原始需求？需求由哪些功能系统可以很好实现？这些功能系统和现在以及将来可能添加的那些关系应该如何？
可以在你打基础时自行体悟，或者先由你直属上级帮你拿主意
这部分说起来比较大，多种多样的情况就不展开了。
最后，千万记得：不要好高骛远，真觉得案子怎么写都行，只要＂好玩＂；也不要被案子、程序实现、美术表现限制住自己。极端大部是给天才和失败者用的}