【随便干货】打工人的第一份系统策划案

咕咕了这么久，来点小干货。

我们之前提到说策划案的最好形式是一个wiki站，这不假，无论是对于第一次查看文档的线性体验还是要查阅详细资料的人，wiki提供的历史记录，tag，查阅，排版等等的功能都极为有用。但大部分游戏公司在让你打工时通常缺乏这样一种wiki文档框架来满足wiki式文档创作。

因为游戏是一个团队项目，越是历史悠久的公司就越需要做到青黄相接，我们不希望所有的年轻人都像上一辈那样工作，那反过来想，我们也没有足够的脸面要求所有的老一辈都按照最新的高效方式工作。你可以称其为迂腐，但这依旧包含了资本里关注人文的那一面。

目前，国内各个公司基本还是使用可以在行政层面上逐层递交，可以单独讨论的文档的形式来制作策划案。而鉴于excel可以统合一些有规律的内容，方便布局排版和运算的种种特性，这是一种“传承”相对较久的形式。我们通常会用excel的各种功能来制作我们作为打工人的创作文档。

首先策划案的整体格式一般是设计目的，整体思路，设计细节+设计理由（根据系统的不同再继续分），用户界面，优点痛点分析，不同用户群体体验差别（体验推演），但格式大家都会说，我们说点具体的。作为打工人的这样一份使用excel来制作的系统策划案，我们需要注意哪些点来让老板对我们少唠叨一点呢？

【1】乙方思维:设计目的和层次化方案

为什么？为什么策划案的第一块永远是设计目的？为什么？

因为你是打工人，亲爱的。我们做的不是我们自己的游戏。我们当然可以拿出“这是我的游戏”的热情，我们当然可以和组长和主策提出意见，我们当然可以在会议上分享见解。但这一切都不能改变这个游戏并非你的创作的事实。我们被付了工资，我们交出设计，我们基于这样的契约关系去工作。而如果你是老板……你是老板我能教你嘛，你是老板你让别人写策划案不就好了。

搞懂并妥善记录这些目的有很多好处，但即使没有好处——管他的，只要你围绕设计目的去做，责任就不是你的，既然你不是敲小榔头（决策）的人，你为什么要承担风险呢？

所以记得策划案的第一块永远是设计目的，这是乙方的法宝之一，意思是写下你的甲方（前辈，老板，组长，随便谁），留给你的大致要求……还不止！请尽力去了解去询问项目的当前情况，一些没有说的，包括可行性要高，需要适合什么样的人群，可以花费的资源，类似的事情，你需要多多阐述你的理解，这也让你在设计时有迹可循。

而乙方的第二个法宝是供讨论用的层次化的多方案，因为有些东西我们真的没有办法搞清楚，有些东西”很软“，我们不知道什么样的机制复杂程度对于我们目前的玩家群体是最好的，我们不知道，甚至可能所有人都不知道。通常我们的具体案子都要通过开会来决定，而当你不知道某些细节，同时也很难去通过询问来使得事实较为清晰时。作为乙方仁义至尽的一种工作方式就是写出多种不同需求的方案，如果是不知道复杂度的需求就写出不同复杂度的(这也是最常见的多方案），如果是不知道可用资源多少就写不同资源依赖程度的。我们列出选项后，选择权交给其他人，进行进一步的风险规避，也使得决策更加好做。多个方案的对比要比这些方案单独列出来意义大得多。而多种方案还能产生组合，某种意义上是更高效的方式。请不要觉得麻烦，前期多做，后期少做，往往头疼的不是说你要写那么多东西，而是在反复的沟通修改中迷失了方向，郁郁不乐。

【2】易读性：太长不看

我们要让策划案连猴子都能看懂！当然，你的老板不是猴子，但有的时候人式不如猴子的。易读性在所有策划案的攥写上都是最重要的一环。这包括非常多的要点，首先就是摘要写作。

相信各位高校学生在生产论文的途中对摘要写作都不陌生，我们要注意的是，即使是摘要创作，也分多个层次和方面。其中最重要的两个层次是“玩家视角”和“目的联系”，即这么两个问题：

1，玩家会怎么了解你所攥写的这一部分机制？

我们需要在设计细则前写一下整体思路和整体描述

如果是通过关卡来进行教程，我们需要将教学关卡中的场景和思路复述。

“玩家可以在空中跳跃来登上更高或者更远的平台”

而如果是通过文字教程，要把展示给玩家的教程在脑中模拟个大概

“元素攻击可以给敌人附加元素效果，而不同的元素效果施加在同一个敌人身上时会发生元素反应产生伤害，控制等多种效果。”

2，你写的机制和你的设计目的有什么关系

“我知道你写的这些什么意思，但是这有什么用呢？”

虽然听上去有点气人，但是传达我们的设计目的和设计之间的联系也是很重要的一环，通常描述为设计理由，玩家体验推演这两块，设计理由写在具体的设计的后面，而玩家通过体验推演则是一个整体的设计理由和设计细则的联系的描述。一切归于游戏体验。这也使得你的设计可以更加考虑周到。

【3】易读性：没图不看

图！图是摘要写作的好伙伴，十分简单的道理。使用大家都在使用的符号，使用已有的游戏界面或者要素。可以使得易读性上升一大截。我们通常会给出系统界面来催化其他人对于系统的想象。即使是系统规则的摘要，最好也要用图来表述一下——当然，这些图需要是可以修改的。请保留好源文件。

【4】易读性；这个东西是哪里来的？

这个问题其实包含两个含义，一个是术语解释，另一个是参考阐述。

为什么要术语解释？怎么解释？

我和你讲元素反应，可是你一不知道元素是什么，二不知道反应是什么，这怎么办？或许我在前文中的某一个角落里提到了，但是某位先生如果没有好好看，很容易错过。防止这一情况有多种办法，其中最简单粗暴的是列一个术语表，即你新提出的术语都放在一个表格中以供查询。而一种比较中庸的办法是在第一次提到这个术语时高亮并单独写一行定义。使用同样的颜色来高亮也是一种办法。总之有迹可循即可

而参考阐述有很多作用，相比起规避风险这样的老生常谈的优点，举一些大家都玩的游戏的例子，举一些已经有的玩法，别人更容易通过实际去观看演示来知道你做的设计到底是什么样的感觉。而实际上，几乎任何机制现在都可以找到参考，小众的游戏里的机制已经涵盖了几乎游戏的所有纸面上的可能性。

【5】利用和阻止惯性思维

第一人称射击游戏？那一定是左手键盘右手鼠标，wasd移动鼠标转动视角吧？

但，谁说的呢？

惯性思维在任何文案攥写中都很常见，就比如说我觉得大家都有一个老板但实际上也有自己在做游戏的人。我们在攥写系统概要和初步解释的时候，首先要利用惯性思维来将想法快速阐述清楚。例如说”圣遗物指的是一套五个的装备“，那么我们自然而然就会觉得角色有五个装备槽，并且五个装备在一起会有套装效果或者五个装备的效果类似。

而在后面进行详细阐述的时候，我们需要摒弃一些惯性思维来实现细节描述的完备性，甚至可以详细到你需要按下按钮，这个功能才会生效这样的事情。也就是说近乎细到程序落地的需求。当然，具体详细程度肯定是根据老板给你的时间来定的，时间多就写的细一点，时间短就粗一点，都可以的。