前言絮絮叨

大家好，这里是“风沙之遗”项目的主策千霖，同时也是一名疑似up主，游戏设计专业在学和行业策划实习在职。“风沙之遗”在原本的计划中是一个参加2024Booom Side Effect的参赛作品，但由于各种原因最终没能在时间内做完，上传的版本也是一个半成品版本，所以得奖和好评如潮估计是无望了，或许这就是所谓的失败是人生的主旋律吧（苦笑）。但这个项目姑且也是小组付出了众多心血的，而核心机制的点子我个人还是挺满意的，因此决定借这个机会，写一篇业余中的业余的策划个人经验分享，希望能给新手策划一些参考，也为这个未来可能会完成的项目招一下魂。

叠甲：以下全文完全是我的个人见解，且由于我没有长期的行业经验，因此没有任何的绝对正确性，请酌情相信和学习，如果你有不同的见解，那一定是你对，此外，我的文笔并不是很好，下文中可能会有不少的病句和错句，对可能造成的困扰提前道歉，最后欢迎在评论区提出和讨论。

正文

众所周知，策划是一个上限极高，下限也极低的职位，下到是个人，无论从什么行业来，只要有点子就可以成为策划，又上到能够决定一个游戏是否能够成功，所以怎么成为，并让别人相信你是一个值得信任的策划是一门学问。

首先先来定义策划吧，和游戏开发三巨头的另两头美术和程序一样，策划同样可以被细分出各种分支，如系统策划，关卡策划，战斗策划，数值策划。不同的地方在于，一个角色原画美术有可能完全不懂场景设计，但一个关卡策划很难对数值设计完全一窍不通，一个合格的策划是会在专精两到三个方向的同时，对其余的分支都起码稍微懂点，甚至可以兼职其他领域。因此，如果一个萌新来问我想要成为策划应该学习什么部分，我会说 “多看，多听，多想，少说。玩的游戏越多，懂的知识越多，学的技能越多，你就越能成为一个厉害的策划。”

扯了那么多，是时候进入这次的正题了。游戏设计文档，顾名思义就是关于一个游戏项目的一切，整合了机制解释，数值公式，设计示意图，剧情大纲等各种策划编写的东西。每个策划有自己文档排版风格，在我这里的话，我习惯性将设计文档分为两部分：引子与正文，前者给外人看，后者给自己人看。

引子

无论在什么时候，一个设计文档的前几页都是是用来给外人看的，无论是整体性概括，忽悠大佬加入制作还是和金主拉投资，它都需要让阅读者在2-5分钟内对游戏项目有一个大致的认识，从而get到游戏的核心可玩性和趣味，并愿意加入团队/给你投资，因此引子的第一要务就是清晰明了和突出重点。

我习惯做法是写一段总结性段落去陈述游戏项目定位与目标，再附加一个三段式表格，通过描述和配图将我认为的核心结构点列出，同时让引子的篇幅极可能的压缩在一页，最长不超过两页，因为这东西和简历一样，写长了别人不愿意看。如果拿空洞骑士来当例子的话，我版本的项目大概会长下图这样：

花15分钟写的不太严谨的空洞骑士项目大概

此外，项目大概的主要目的虽然是给外人解释项目，但同时也强迫了策划自己先搞清楚自己在设计的是一个什么东西，从而避免了“我有个天才点子，我们来开整吧”结果开始之后结构四面漏风导致反复修改底层设计的情况，毕竟如果连策划自己都没法给项目一个准确的定义，然后也不知道项目重心，他要怎么给其他成员分配任务和协调项目合作呢（笑）。

风沙之遗的第一版项目大概

正文

如果说引子的定位是极度精简的整体性概括，那正文的定位就是事无巨细的字典，将项目的设计和细节全部囊括在其中，以供组员在需要的时候查阅。当进入正文阶段后，内容就不需要精简浓缩了，因为它是给自己人看的，且大部分组员并不需要从头到尾把它读一遍（策划除外），只需要在需要的时候进入文档并查找对应部分就好，因此策划编写的时候只需要确保一件事：把需要的东西用尽可能详尽且清晰的方式传达给负责的组员。合理的排版也好，各种表格也好，草图也好，类似游戏的截图也好，任何你觉得可以帮助沟通的东西都可以塞入设计文档，只要合作组员完全理解了策划在讲什么和要什么，我们的目的便达到了。

俗话说一白遮百丑，这句话在设计文档上同样适用，一个整洁有序的文档是一切的基础，因此请养成排版的好习惯.jpg 我常用的方法是目录+按大领域分类，将大部分的内容分类到“系统与机制”、“美术”和“叙事”三个类，再按照具体情况，通过大小标题和段落进行分区。此外，设计文档在软件的使用上并没有行业标准，纯粹看顺手和适配尽可能多的设备类型，个人的常用组合是飞书文档（功能齐全，缺点是不好导出文件）或云文档+Miro做图。

从正文开始，写法就变得比较自由了，各位策划可以根据自己的能力与项目偏向来决定在各个部分中花费的时间。如策划+美术职位的人可以在美术部分的整体风格，UI布局，演出渲染等部分做更多的笔墨，而策划+程序的人则可以更专注于机制的运行逻辑，角色的行为树，数值的计算公式等。你并不需要在不熟悉或没有想法的地方强行写设计，适当留白将部分交给其他成员来自由发挥或许会让项目变得更好，毕竟项目不只是你的项目，也是大家的。

系统和机制部分

如果要列举我认为我为数不多从游戏设计专业学到的东西的话，我会说做图真的很有用。相比口述或写大段解释，图像是一个高效的多的多得多的形式，因此如果你有一点画画经验，尝试用ps或平板画草图并附加注释，不要因为自己的画工烂而害怕，因为只要美术懂了，你画的再烂的抽象草图都能变成实力好图，下方例子为“风沙之遗”中的战前准备模式UI草图和美术成果图：

我画的准备模式草图，包含了功能和大概的布局

经过美术老师包装后

当然不是每个人都会画画，对于画画苦手来说，与其为难自己不如选择更便利的方法：做图软件（Miro，飞书画板，ps等），把你的剧情流程也好，攻略逻辑树也好，某个页面的UI也好，用抽象图像加注释的形式给做出来，还是那句话，你别管自己弄的抽不抽象，美术能懂就行。

直接用飞书画板拼的风沙之遗联网系统UI

美术和叙事部分

在这两个部分我其实并没有太多能分享的东西，但这是有原因的。在过往的项目中，我基本上都只是定下项目的基本视角类型和美术偏向，然后就把整体的美术设计全权交给了美术老师去自由发挥，我自己则是去做玩法设计和与程序对接，这么做一方面是因为运气都很好找到了实力很强的美术老师，另一方面则是因为美术和程序在策划需求量上完全不同。在开发过程中，美术部分基本在得到了总体的大方向后就可以自行推进了，但程序则会在各种系统和功能上需要策划去做决断。比如说风沙之遗中的棋子部分，我只需要告诉美术组“我想要的是类似高级战争的感觉，需要待命，移动和攻击三种状态的动画”，剩下的诸如帧数和像素尺寸的事情他们就可以自己讨论了，但到程序这边我则需要给出各种的表格和设定：如棋子需要有的属性，棋子动画的播放行为树，棋子的行动逻辑，玩家的操作顺序等，而这些细节程序是无法独立做决定的，他们必须询问策划或等策划出案子。

风沙之遗的棋子行动行为树

以上情况虽然普遍，但发生的原因其实与项目的定位有关，由于我的前几个项目都是玩法比较特别的项目，所以我会需要花很多笔墨在玩法上。但同样的，如果我下一个项目想做重剧情或者重美术的项目，那这时候情况很有可能便会变成我大手一挥告诉程序“帮我做一个和Gris一样的横版跳跃玩法”然后把精力全部放到和美术讨论美术风格，渲染方法或编写剧情上。因此大家若是遇到了相似的情况也不必慌张，将你的精力放到项目最重要的部分上即可。

最后总结

写到这里感觉把能想到的都写了，再继续的话本质上也只是把前文重新细化一遍（甚至感觉已经干了），既然如此就干脆用一段唠唠叨叨作为这篇的结尾吧。如果有人看到了这句话，那我就假定你是从头读到尾了，非常感谢你能愿意为这篇东西浪费的宝贵时间，希望这篇东西给予你了一些微小的帮助C:。如果有困惑或者觉得讲的不够清楚的地方，欢迎你在评论中提出，我可能大概或许会尽快的补充并更新（），如果有兴趣，也欢迎赏脸查阅风沙之遗的设计文档：项目——风沙之遗

走上这条路后，不得不感叹想要当好策划真的不容易，当Jam的主策也好，当在研项目的策划也好，真的只有很少数的幸运儿能够处女作便大获成功，失败是人生的主旋律，但正是因为失败的经验会成为成功的基石。希望我自己能继续努力，争取能在不远的未来完整的呈现一部jam作品，甚至成功上架的游戏，也希望这篇个人总结能够给刚刚踏上策划之路的大家一点方向（也有可能把大伙都带进坑了）。