0898-08980898 13876453617
0898-08980898 13876453617
其实这个东西不应该由一个策划来答。
一个策划的案子写得好不好，永远只能是和他接口的人员（程序、美术、测试）说了算。
仅从工作角度来看，游戏策划案有以下三个作用：
1.让程序美术明白需求。
2.留档，防止出了问题找不到原因和负责人。也可以看到一个功能经过了哪些修改，这些修改是好是坏。
3.给测试让测试写用例或者给其他合作策划了解你的功能。
因为上面这个原因，策划案也没有什么固定的模版，有的程序只需要几句话就可以开工，有的程序不玩游戏就需要你给个表然后讲上半小时。
一份策划案，通常就包含三个部分：
给服务端看的、给客户端看的、给美术的需求。
这三个部分具体应该写清楚哪方面，是无法用很短的篇幅来形容的，如果真那么容易就讲出来，策划的工作经验就不值钱了。
比如很简单的一个背包，就需要写清楚：横向几格，纵向几格，如何翻页，能翻多少页，是否分栏，分几个栏，背包格数能否扩展，栏目能否扩展，背包满了的时候捡取、交易、完成任务如何处理，要不要做自动排序，如何自动排序，单物品叠加上限多少，筛选怎么做，在不同的功能NPC处有哪些功能按钮，处于不同的功能下有什么样的特殊显示方案等等等等……
+++++++++++++++++++++++++++++++++++++++++++++++++++++
下去抽了根烟，想了想还是再补点东西吧，
关于如何让你的接口人喜欢你写的东西：
后端就画好流程图，写好表格式（你的表要几列，这些列会不会再添加，每列里写的东西最大几位最小几位，是不是有负数、小数等）
前端把交互说清楚，在这里推荐一个软件AXURE，这东西产品经理用得多，但是游戏策划拿来做前端交互说明稿也是相当不错的。
美术就是你给需求的时候最好把样例给出来，百度搜几张图不费劲。还有就是千万要记住，给美术的文本必须要是可复制的，美术比较痛恨的事儿就是经常需要扔下手写笔然后在键盘上自己输入文字。
如果这些想不全，那么不是一个经验丰富的策划；如果完全想不到，那还是好好地当个游戏玩家吧，做游戏不是个好玩的事情。
手痒，把工作先放一边，简单列一下提纲和要点，细节恕不展开。
首先，在写策划案之前，我们应该先明确一点：为什么要有策划案这种存在。原因有以下：
1、有助于规整设计者的思路。
2、可以准确传达设计者的意图。
3、帮助开发人员准确理解和评估开发工作量。
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、各自的工作内容及完成时间。
有关“测试用例”。其实，如果需求写得够明晰，这部分其实很简单，就是比较烦。
1、实现度
2、表现是否正常
3、数据存储调用是否正确
4、分步拆解纠错
5、关联系统对接是否通畅
Tips。（喂！不是说好不展开了吗）
1、流程图有助于梳理设计思路，条件判定有助于查缺补漏，请细心。
2、迁移图可以理清你的操作逻辑，在保证功能的基础上，适当减法。
3、原型图可以简陋，但要点和你期望的焦点功能和布局方式，请凸出。
4、认真设计数据表格，这些都是日后你要自己填的，请善待自己。
5、策划案要标题明确，层级清晰，方便通过文档结构图进行查阅与检索。
6、关联其他开发的部分给出对应文档的名称和所在位置。
7、在策划案里留下历次的版本修改记录与游戏实际情况保持一致。
最后，一些辅助工具
1、Mindmanager，思维导图，可以很好展现整体的树状系统结构，也可以详细阐述一个功能，
2、Axure，页面原型，页面迁移跳转，快速制作可进行操作体验的页面原型，
3、excel、visio，基本工具，博大精深，
4、知乎，嗯，开小差的时候不至于有太多负罪感。
最后，我这一篇回答，换个视角就是一个基本的策划案框架思路。
以下，来自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、好文件也要好包装。最后，你需要做的就是使文件便于阅读和使用。没有愿意阅读一叠纸——因为看起来也不重要。只有带硬封面的东西看起来才重要。
制作一份应持有复印件人员的名册并进行保存。打印出所有东西，且每一页都要带眉头和日期。接着在每一页上打洞做成活页。最后在每一份活页本的书脊和封面上贴标签。更新时，人手一份校订页。有时，你可能需要提拱新活页本，丢掉旧活页本。
总结
电影制作人使用步骤原稿。建筑师使用蓝图。音乐家使用乐谱。根据古代的传说，甚至是宇宙造物主也制作了设计文件，在最初的文明之光普照大地之前，他让一小撮先知瞄了一眼——所以有了这个古代传说。既然神都是这么做的，那么游戏开发者就以之为榜样吧。
游戏邦注：原文发表于1997年9月22日，所涉数据及事件均以此为准。
另外可以参照的一些内容：
http://gamerboom.com/archives/49779
http://gamerboom.com/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 Genre; target audience; description; most compelling features; market information; cost and time to develop. It defines the concept, scope, worthiness and feasibility; 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); task database; budget spreadsheet; technical specifications; 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 have their own minds; 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
Important
If Possible
Rejected
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 TzviF@aol.com. （source:gamasutra）
游戏策划案，广义的理解就是游戏策划所写的案子。
从内容分类来看，主要有：
1.立项策划案，又叫立项报告书，为了项目立项而写的策划案。
2.游戏分析案，也叫游戏体验分析报告等。
3.功能设计案，为了实现游戏中的某一功能而写的案子。
这是游戏策划日常工作中写的最多的东西，也是大家理解上的、狭义的“游戏策划案”，更是所有游戏策划案中最复杂、要求最多的。
这里我们需要明白，分类不同的游戏策划案其内容、构成都是不一样的。
比如说，立项策划案，通常包括游戏综述、游戏设计说明、开发进度规划、资金使用计划、游戏商业化、游戏运营策略等等。
而功能设计案则是围绕功能设计去写，主要包括概述、功能规则、功能属性、功能其他需求（美术、音效等）。
当然，以上也并不是绝对固定。
不同的公司，内部都有一定的模板和特殊的要求。
即使是同类的游戏策划案，也会因阅读者、使用者的身份不同而有所区别。
拿功能设计案来说，
如果你是想向制作人展示一个新颖的功能设计（系统、玩法等），那么你写的时候要侧重写该系统和玩法的设计目的、设计目标、营造的游戏体验、可能的商业化手段等等。
而如果你是要让程序去实现一个功能（系统、玩法等），那么你写的时候就要侧重于实现规则、运行的逻辑机制，甚至还要配上流程图、玩法原型展示等等。
简单来说就是，
前者你是作为乙方，向作为甲方的老板和制作人展示作品，希望获得投资或支持；
后者你是甲方，需要向作为乙方的技术人员和美术人员详细说明你的作品怎么实现。
功能设计案的书写、内容、结构、写作原则等等，简单地用一两千字很难说全。
如果要在工作中提升自己功能设计案的写作能力，
主要途径有两种：
一是向资深前辈学习，找公司内部好的功能设计案学习；
二是在体验游戏时试着做该游戏的系统反推案。当你做得越多，就会发现大部分游戏功能的逻辑机制都有着很多的共通之处。
我是木木，欢迎关注我，一起聊游戏吹水。
其他优质回答：
今天，要亮出我最喜欢的游戏——异域镇魂曲的设计案咯。
很难对它做什么介绍，一个词——标杆。
异域镇魂曲
1. 简介
1.1 这个游戏是什么？
Last Rites是一款等距视角（就是我们常说的第三人称斜45度视角）的角色扮演游戏，设定在TSR公司的Planescape（异度风景）框架下。
采用博德之门被遗忘的国度的机制，并收到Interplay公司的艺术家提供的Planescape的氛围和感觉。
玩家创建一个单一角色，在游戏中选择一系列的盟友（朋友和对象）加入他的队伍，并且提供他更频繁的装逼爽点。队伍的最大人数5个人。
1.2 “Planescape？”那是什么？一种传染病？
Planescape是TSR的众多“世界”（例如被遗忘的国度）的其中之一，采用AD&D机制运行。
“世界”这个说法实际上不太恰当，Planescape是设定在围绕一个中心城市Sigil旋转的众多位面上的，就像轮子上的辐条一样。
Sigil城是Planescape宇宙的中心，它也被称为“笼子”或“门之城”。其的独特之处在于散布在迷宫般的城市街道上的门户（有些是隐藏的，有些是显而易见的）只要你有合适的钥匙，这些门户通向存在的任何地方。Sigil是跨多元宇宙种族的中立位面和传送中枢，所有这些都是在这座城市的神秘统治者痛苦夫人的监视的阴影下。
总的来说与其他的TSR世界相比，Planescape是一个更成人、更硬核的幻想世界，建筑、人、生物等等，一切都有围绕展开，信仰、情感、信念和其他抽象的概念出现在现实中，在Planescape中，信仰有能力重塑世界，杀死和复活力量（神），并改变物理定律。
上面这个像白吉饼形状的东西就是Sigil城，你开始游戏的地方
Sigil就像一个装满奶油的甜甜圈，里面是一个城市。没有人知道是如何变成这样的，但不管怎样，与你在Planescape中找到的大多数狗屎相比，已经相当的不错了。
下面是地面
1.3 规格：目标系统是什么？
我们针对的是16MB的奔腾90，带有2x/4被CD r om驱动和2meg显卡。游戏将是一款多CD的游戏（3CD）
2. 概述
2.1 这个游戏是什么？
Last Rites是一款暴力、不敬和令人叹为观止的美丽的角色扮演游戏，设定在多元宇宙的十字路口，我们打算创造一个有趣的古怪，令人心动，破坏陈词滥调的力量幻想，充满令人叹为观止的暴力的发自内心的时刻。我们将如何实现这一目标细节详见以下页面。
游戏设定在TSR公司的Planescape框架下，采用博德之门被遗忘的国度的crpg机制，并由Interplay团队的艺术家提供的Planescape的氛围。
下面是简短的故事摘要，然后是我们计划包含在游戏中的所有很酷的东西的列表。
2.2 核心概念
玩家是一个伤痕累累的失忆的不朽者，正在寻找自己的身份。在路上玩家角色会杀死很多人……包括他自己。
游戏开始时，角色在停尸房的一块冰冷的石板上醒来，这是Sigil市的一个巨大的停尸房。玩家角色，不知道他是谁，他在那里做什么，也不知道他是怎么死的，他必须逃离并探索停尸房墙外的陌生世界，以揭开他的死亡并重生的秘密。
详细的情节摘要会在愿景声明之后提供，现在来看看这款游戏的酷炫的功能：
3. 牛逼点
3.1 来看看兜帽下面是什么
游戏的引擎很酷炫，我们的引擎里有很牛逼的东西，博德之门提案已经详细概述了这些内容。每张地图都是16位颜色，预渲染且独特，人物可以步入光影池，并被适当照亮，它具有整体照明，允许世界从黎明到中午，从黄昏到夜晚再来回变动，当你的玩家装备的新的盔甲或武器时，你可以看到角色的新外观变化。2次点击就能切到你所需要的任何界面，20多个高质量的咒语和法术效果，玩家挑选和选择的最多5个角色的队伍，以及NPC的人工智能脚本（你队伍里的githzerai一看到他就会嘴里冒泡并且狂化，懦弱的小偷在看到一血之后就会逃跑，反复无常的叛徒，可能会等到其他人都昏迷不醒，你有25%的生命的时候，背刺你）所有的这些都有助于完善机制。
3.2 地砖块是用在浴室里的，不是游戏里
这个游戏没有地格的概念，这是一个值得提及的东西，因为他可能是最开始就吸引玩家的点。
想象一下探索一幅彩绘的风景画，这就是这个游戏要做的。
不再使用重复的地格来构建几何的地牢，不再需要去记忆每一块墙壁纹理中的机关按钮的位置。在这个游戏中，游戏世界的每一寸都将由艺术家去雕刻，这将是独一无二的，会让我们的竞争对手哭泣。
3.3 酷炫的动画和幽默的特效
搞笑艺术风格，有了我们创作的艺术资源，游戏中的生物可以拥有独特的动画。此外，玩家遇到的每个生物和人都会有赋予他们的风格和个性的声音——妖精皮条客在坐立不安时擦拭鼻子，学徒法师在等待时练习他的传送魔法，他的手和眼睛都有微小的火光闪烁。你的亚马逊战士在她等待时摆pose，虚荣的警卫队长会梳理头发或在镜子里欣赏自己。在游戏的初期阶段，玩家可以有一个嘲讽的漂浮的头骨，Morte，作为同伴加入队伍（它唯一的作用是撕咬和嘲讽怪物进行攻击）他拥有100多种不同的嘲讽（当玩家进入新的关卡或者是地点时，嘲讽的菜单会随着增长）。当激动不安时，他会绕着转圈，头骨疯狂的摆动，眼睛滚动，当接近女性亡灵时，他被ai脚本控制漂浮在她们身上，并尝试搭讪，玩家与游戏中的其他角色进行微妙的对话时，它会像驱魔人一样旋转头或向玩家吐牙切齿。
4. 玩法要素
4.1 游戏是角色生成器
你通过你的行动来定义自己，而不是通过在角色生成界面上的一组数字来定义自己。你在游戏中的行为充实了角色，你决定你有多强壮，选择哪条职业道路，你想学习的技能，你发展了什么样的能力，习得什么咒语。整个游戏就是角色生成界面，允许你按照你自己的游戏风格来建立角色。
4.2 以你不会相信的方式造成痛苦
不再使用无聊的剑、匕首或弓在对手的身上击打出血。而是将手术刀插入敌人的眼睛里，用有毒的防腐液涂在食物上，将他们推入食人怪嘴里，用嘲讽骷髅攻击他们，把他们扔进荆棘藤里，在对手的大脑中召唤腐烂的幼虫，释放咒语，使他们七窍流血，或改变一个人的气味，吸引成群饥饿的老鼠。用任何能让你脸上露出笑容的方式进行攻击。
4.3 让你为对手感到抱歉的咒语
当你打开你的技能库时，火球术可能会藏在不起眼的角落。把你的手塞进对手的身体里，撕开他的灵魂，告诉他杀死他的主人。做一个手势，召唤一条爬行的咬人的昆虫毯子，把你的敌人变成一顿快乐的饭菜。在没有通行证的情况下，把你的敌人送去地狱实地旅行。将对手嘲讽致死，。存在中召唤你最黑暗的阴影，并将他们送入战斗，以你的对手的体力为食。你的梦淫妖队友可以亲吻你的对手致死，让他们脸上带着微笑死去。
4.4 没有新手引导
我们不做保姆，当你想做的时候，做你想做的事。当然你从一开始就有方向和目标，但你也有回旋探索和选择自己命运的空间。游戏不是一个居高临下的保姆，用柔和的介绍和手边的任务的向导来指导你前进的每一步，他将让你沉浸在Planescape世界中，并迫使你在具有挑战性的环境中照顾自己。
不要太担心游戏前几分钟的死亡，这不会发生，你会有足够的时间去探索你周围的世界，并且在你的角色真正受到威胁之前站稳脚跟。此外在游戏中，死亡只是你角色的一个暂时状态，正如你会发现，你死后所做的选择，对你和其他人来说同样重要。
4.5 装备粗糙的东西
穿戴装备会吓到小孩子。用手术刀把出你的眼睛，补上一个恶魔烈士的血腥的眼球。剥掉你杀死的野兽的皮，并把它作为盔甲佩戴——骨矛龟甲壳制成的盔甲相当无敌，也不能错过把它的角当成标枪的机会，将剃刀藤收割制成绞刑具，撬开canoleth的下巴，用网挖出粘稠的带刺的舌头，肢解对手用它的四肢作为武器，将巨型爬行动物的融化皮肤蒙在盾上，或像斗篷一样佩戴其多刺的毛皮。
4.6 天哪看看我发生了什么！
玩家可能会在屏幕上看到他的角色，发生可怕的血腥的事情——甚至会死去——他会好起来的。上述发生在怪物的身上的事情，也可能会发生在玩家身上——除了玩家会再生。玩家的手臂可以脱落，双腿被切断，皮肤从身上剥落，几个小时后他就会没事了。在某些情况下，玩家需要卸下自己的四肢来用作武器（手臂是很棒的棍棒），或者将自己从手铐中解放出来，玩家可以使用自己的不死状态来帮助他在冒险中解决问题。
4.7 这是一个游戏，而不是一个生存模拟器
我们希望你玩这个该死的游戏，而不是从微观上掌控它。这不是一个飞行模拟。因为你实际上是不朽的，你不需要吃饭睡觉排泄，也不需要担心通过任何常规手段死亡。没有口渴或饥饿值的负担、道德点或经营策略来阻碍你，用自己的切断的手臂将对手殴打致死，或释放咒语，将对手的阴囊传送到它的胃中进行消化。
但你确实可以管理一队盟友——尽管他们的剧本和态度中总是有一些怪癖，使得他们无法预测（你可以给Marta一把战斧，但由于他在冒险早期已经表达了对给你抽血的不同意见，他不会在战斗中使用它，尽管他用的沉重的擀面杖相当要命）但玩家仍然可以指望能够按照自己的喜好操控战场和战斗。
5. 很酷的故事
5.1 没有像它一样的游戏世界
这是一个你从未经历过的游戏世界，它有冲击的视觉效果，诡异的对手可以用一个想法来谋杀你，奇怪的魔法超出了物理和形而上学的常见概念。探索Sigil，一个充满魔法和工业的城市，在一个被污染的空心甜甜圈内部，在那里最强大的天使和从坑里吐出的最糟糕的恐怖，将邀请你就死亡如何影响两性之间的身体和情感关系发表意见。
忘记脆弱的精灵，摇晃的矮人，一文不值的侏儒，以及和这些一起发布的每个rpg游戏那令人麻木的无聊。我们的游戏会让你探索一个安全的立足点，就在你认为你对这个地方找到感觉的时候，世界会踢你的屁股，在你思想理清楚之前改变规则。
不再有高魔幻想中，骑士翻山越岭，并用魔法剑来杀死邪恶巫师那种狗屎设定，在这个游戏中你是唯一重要的人，这是你的生活……时间不停的流逝。
5.2 自慰
我们得到了黄金、荣耀、力量和英雄崇拜。为什么要拯救一个你一无所知，完全没有依恋的世界，去他妈的。我们知道你真正想要的是什么。你想在一个你是神的世界里猖獗，你想要改变环境的力量，屠杀所有反对你的人，成为群众崇拜的英雄——一切你写论文或者每周40个小时在学校里所不能获得的体验。
因此我们的游戏专注于每个玩家的能力的幻想，并利用自私的动机。你和你的命运是游戏的焦点，你并不是为了拯救世界而是为了拯救你自己，如果在这个过程中拯救了世界那就没问题，但这不是你的问题。
也许这个世界并不会围绕着一个角色转，但如果你愿意的话，它会。你愿意吗？
5.3 是的，都按你说的做，主人
人们（这里指的是游戏中的NPC）将会意识到角色并对他做出反应。玩家可以建立一个反馈体验。人们会在一个可怕的攻击性角色的脚下退缩，或者欢迎（或试图利用）一个和善的角色。当他们发言之前，他们会认出他，并会记得玩家上次和他们说话时是如何对待他们的。游戏中的角色将学会恐惧和尊重其他角色。他们会卑躬屈膝，迎合他的欲望，女人会崇拜他的性格，对他大加赞扬。
当然，在现实生活中，你可能是一个肥胖的单身狗失败者，但在《Last Rites》中，你得到了你一直渴望的女人和尊重。
谣言在Sigil传播得很快，玩家的行为（无论如何解释）将预示着他，人们会做出适当的反应。
5.4 一个世界，而不是一条单行道
总有地方可以去，总有事情可以做，以推进剧情。冒险不会因为你无法解开谜题而停滞不前——只需要去做一些你更喜欢的事情。
这一主题贯穿游戏始终，并延续到场景设计、技巧和陷阱中——对于玩家遇到的每一个障碍，总是有不止一种方法可以将猫剥皮，如果玩家希望留下一个谜题并重新回到它，那么他们将始终有其他途径和冒险
5.5 一个有脉搏的世界
世界上其他人也有生命。仅仅因为角色不在那里观察世界的每一块，并不意味着当他离开这个地区时，世界就停止了。每个人都有自己的日常生活，在没有玩家在场的情况下，事件可能会发生，从而增加了可重播性。游戏将有深度，尽可能成为一个活生生的世界。
5.6 你遇到的人不是麦当劳的机器人
我们游戏中的人都有自己的个性，有时甚至不止一种个性。你遇到的人并不是你见过一千次的那种走路、说话、切饼干的陈词滥调，他们想要的和你一样。对手和盟友不会分成这两个简单的标签，他们甚至会在游戏中来回切换，以回应你的行为。你将不得不与具有多重性格、精神分裂症或被附体的对手打交道。为了在血战中伤害他的一个敌人，向你提供礼物或准确的信息可能符合坑友的最大利益。友好的酒馆酒吧女招待，一头燃烧的头发，一只强壮的剑臂，可以渗透你的荷尔蒙，她可能是来自深渊深渊的难民。你的朋友可能比他们看起来的要多得多——他们可能会根据自己的忠诚和你的行动改变自己的性格。你的一个盟友不会赞同你去掠夺死者的尸体，而如果你不是贪婪的，另一些人则不会和你在一起。一些笑脸之后始终隐藏着等待你陷入危机时落井下石的獠牙。
另一方面，玩家可以建立友谊和关系。他可以与怀疑论者建立信任，帮助那些需要帮助的人，或者与他遇到的人搞对象。我们将努力尝试在游戏中加入积极的关系——玩家在现实生活中可能没有的关系，或者看电影时可能渴望的关系。玩家可以有为角色献出生命的伙伴，贝齐斯、维罗妮卡/金格斯和玛丽·安恩斯为他的感情而战，还有导师、忠诚的仆人等等。他们会感谢玩家的帮助或讨好玩家的关注，给玩家额外的抚慰。
5.7 尖锐的困境之角
艰难道德选择让你思考并将带来不同的后果。大多数奇幻RPG都有正确和错误的选择，而且更多的时候，道德总是清晰明确的。你为了“正确”的理由做了一些事情，就会得到一些信息或奖励。这不是很好吗？
这是可预测的，也是愚蠢的。在《Last Rites》中，活着（和死去）不会那么简单。
没有“正确”和“错误”的行动方案——通常情况下，两个行为都是“错误”或都是“正确”，每一个选择都会有人吃亏。你可能需要偷窃、抢劫尸体或杀人才能生存。为了实现更大的目标，无辜者可能会付出代价。将一名看似冤枉的囚犯从监狱释放出来，可能会带来和谐会都无法阻止的一连串杀人事件。从一群小流氓中救出一个小女孩可能会打断帮派的入会仪式。给一个疾病缠身的饥饿乞丐提供食物可能会导致另外20人死于瘟疫。并不是每个人说的都是真话，行动也不一定会背叛一个人的目标。一个“善良”的巫师心中有自己的利益，袖子里藏着一把毒匕首。你队伍中的叛徒，可能有正当理由做出对你来说完全合理的行为，即使他把匕首插在你的喉咙上。一个马商可能会卖给你一匹马，以换取你一直以来的每一个金币，当知道它很可能会在你身上消失，五分钟后，它就会消失在Sigil污染严重的街道上。相信一个天使措辞谨慎的论点，而不是一个可怕的深渊恶魔直言不讳的言辞，这可能是你一生中最大的错误。
5.8 有件大事要发生了
你是为了拯救自己，但你的活着或死去的后果会影响其他一切。当然，你只是一个人，但这并不意味着你是一个大池塘里的小鱼。你很快就会发现，每个人都想杀死你，和你交朋友，背叛你，崇拜你，他们都有非常好的理由这样做，这超出了你和你的直接需求。你是一个具有传奇色彩、力量和潜力的人，你所做的一切将震动这个位面。这一切都是关于你，你，你。
5.9 哈姆雷特很容易
我们遇到了游戏中最大的难题：你。不再有开关，不再有红色/蓝色/黄色键，不再按正确顺序按下按钮。我们找到了你能找到的最大谜团。为了赢得比赛，你需要找出你是谁，是谁谋杀了你，以及为什么。如果你不这样做，你将在你的余生中成为力量的奴隶。
5.10 您的库存与您交谈
带态度的物品：物品将超出物品的概念。他们将有各自的照片、历史和名字——通过研究，玩家将能够发现他们的武器比最初看起来的有更多用处。
你的一些武器会变丑，会嫉妒，甚至会在被拔出时变得懦弱。有些需要严厉的交谈，有些需要欺凌，而有些则很适合在你卡住或需要提示板时与其交谈。
5.11 “宝贝”有“一卡车”
成吨的宝贝：这款游戏将有很多让玩家“哇”的宝贝。将有恶魔宝贝、人类宝贝、天使宝贝、亚洲宝贝，甚至是不死宝贝。令人遗憾的是，这些宝贝将在没有乳头年龄的情况下出现，并且行为都会在TSR公司的道德规范范围内。
5.12 收起你的钱。你知道个屁，傻瓜？
信息驱动的任务：在这个特定的Planescape游戏中，大多数交易使用的“货币”都不是金币。玩家会发现，他所知道的和他选择告诉别人的，才是这个游戏世界中真正的有价之物。金币很适合购买阿伯林甜南瓜，但如果知道“掠夺者谢姆斯卡当前的计划”，会让玩家进入金币去不了的地方。
5.13 一个如此活跃的界面，你害怕它
动态界面：一个具有动画图标和动画屏幕的动态界面。屏幕会根据你的实力和装备而变化
5.14 还有更多的宝贝
宝贝：想想宝贝。那就多想想吧。
5.15 它不会随着游戏而停止
欢迎来到Planescape……停留一段时间：Last Rites旨在为您提供身临其境的Planescape。玩家和他的角色被抛到了一个陌生的世界，在那里他们两人都必须破译现在支配他们生活（和死后）的奇异文化、人和法律。随着游戏的推进，玩家和角色一起体验世界，而不必像许多角色扮演游戏（《黎明之砧》、《雷雨》、《洛瑞之地》）那样，强迫自己扮演一个角色，让角色与世界及其人民建立联系。怪物、历史、地点和体验对玩家和角色来说都应该是全新的，这使得角色扮演体验更加身临其境和强大。
在游戏结束时，我们希望让玩家对Planescape有一个整体的感觉，并了解它的主旨，而不必详细描述世界的每个角落。希望游戏及其所呈现的区域和人物将成为未来游戏的基础，并有望激励玩家阅读纸质游戏支持材料和小说本身，以寻求游戏中涉及的更多信息（尤其是某些事实，血腥战争，外域的权力和地区，他们在游戏中偶然听到，但没有遇到）。
从本质上讲，将尽可能多地触及Planscape世界的各个方面，足以给人一种全面的宇宙的感觉，但只会详细探讨某些方面。希望这些接触将有助于为未来的游戏奠定基础，并激发玩家对未来游戏和TSR公司的辅助周边的兴趣。
6. 团队愿景声明
6.1 不要做已经做过的事
如果你以前见过它，那么就做得比你以前见过的更好，或者不做。更好的是，试着想一种以前从未尝试过的方法来实现它。
6.2 这是Planescape，不是高魔幻想
这不是高魔幻想。这是前卫的幻想。您创建或绘制的所有内容都应反映这一点。
6.3 这是一个尖尖和锯齿状的世界…
Planescape尖峭不平。它看起来不像是一个柔软舒适的地方。不要想象成Ultima城镇或封建农场——在脑补建筑时，要想成鲨鱼的锯齿状牙齿或豪猪的刺。
6.4 …到处都是参差不齐的人
Planescape里的人长得又尖又参差不齐。他们看起来不像中世纪的老实的农民。
6.5 重新审视你的第一直觉
如果你想创造一些东西，不要用你的第一直觉。停下来一会儿，然后把这个想法转一下。例如，不要像现代人所认识的那样画一艘“帆船”。用蜘蛛网代替帆，用某种恶魔野兽的胸腔代替木质船体，让它能够在气泡中在水中航行，等等。
6.6 发疯
疯狂吧。如果你对一个想法不感兴趣，那就让它激动起来。让它成为你必须努力的事情，而不仅仅是因为你已经用同样的方式做了一百万次了。
7. 角色圣经
本节从视觉和心理上总结了将出现在我们游戏中的好人（或者至少是比你踩到的人更坏的人）。
这本圣经中的艺术包含埃里克·坎帕内拉和詹姆斯·林的概念草图
“在这里徘徊
拧成一团的世界
就像拥有
失忆与DEJAVU
同时有
总是最糟糕的感觉
我已经忘记了
这都是以前的事。”
-无名-
本作的“英雄”：
又名“无名者”“不安者”“死亡者”“迷失者”“行尸走肉”
我们的看似不朽，可怕又恐惧（身体和情感），失忆的男主角。这是玩家用来与Planescape世界互动的伤痕累累的木偶。这位“行尸走肉”不会死，这保证了数小时的游戏享受。他最引人注目的亮点是他伤痕累累、尸体般的外表，他能够摆脱创伤和斩首，他无法记住自己是谁或是什么。
该文档中的角色说明未翻出来，之后应该会和图一起补在专栏中。
Copyright © 2012-2018 开丰娱乐-开丰注册登录绿色站 版权所有 琼ICP备xxxxxxxx号
电话：0898-08980898 手机：13876453617 地址：海南省海口市
在线咨询