浅谈策划行业的工作内容-从零开始的游戏设计

浅谈策划行业的工作内容-从零开始的游戏设计

本文详细介绍了游戏策划行业的工作内容，从游戏立项到上线的整个开发流程，以及不同策划职位的具体工作内容和方法。文章内容专业且深入，对于想要了解游戏策划行业的人来说具有很高的参考价值。

立项-设计方向的摸索

在一款产品立项前的一段时间是产品的研讨尝试期，这个阶段一般团队只有以制作人为核心的几个骨干对产品的方向及思路进行研讨和简单的尝试，也就是所谓的立项DEMO。这期间的情况如下：

• 人员构成：以制作人为核心的最精简策划小组，通常为13人（主策及核心或执行策划）+12名核心程序人员+1~2人美术成员（也可能没有美术，素材靠公司中台库存或TB）。
• 工作内容：确定游戏的核心玩法并以核心玩法为基础撰写立项策划书。立项书是给公司高层看的，主要内容就是核心玩法的介绍以及预期可能设计的其他游戏模块、营收方式、收入预期、成本及规模的预估等等等等。并制作一个核心玩法的演示DEMO-0（或者干脆程序和美术凑一起搞个演示动画）。其核心目的就是说服高层认为你的项目方案落地后玩家能喜欢能挣钱.......然后投资你的项目进行开发。

当然，小厂没这一步，一般小厂老板自己就是制作人，说服自己就行了。最多咨询下其他公司的老板同行。不过同行之间什么关系懂的都懂。

开发step1-游戏的雏形

如果你的立项书成功立项了，那么恭喜你的项目走出了第一步。随后作为团队来讲需要干三件事。1写项目框架书，2扩编，3制作DEMO-1。我们一步一步来讲。

项目框架

首先项目框架，这个比较好理解，就是一部完整的整个游戏各个功能的框架介绍书。一个游戏里当然不会只有核心玩法，还会有以核心玩法为主的各种功能模块。以及围绕着玩法框架的文化框架。框架书就是写这个东西的，与立项书区别在于这个书是给开发团队看的，不是忽悠老板用的。

先简单讲讲一个游戏的玩法框架建构，在这里以最简单的铁三角构架为基础介绍，也就是“收集-养成-验证”三要素。当下的手游、网游和单机大部分都是以这个框架为核心。收集就是收集资源，例如mmo里刷装备和材料，卡牌手游里打关卡刷素材等等。养成就是把收集来的材料转化为实力的过程，所谓养成系统。验证就是把你养成的成果与关卡怪物进行比试验证。养成到位自然就验证成功，随后在新的起点继续收集-养成-验证，你会发现现今大部分游戏都是这么一套逻辑，一款游戏它就这么运转起来了。

当然，不同的游戏这三个部分的运行模式是不一样的。例如MMO一般是刷本升级然后去打更强的本刷更强的装升更高的级。不同的游戏也可能有多条这种显性的和隐性的铁三角。比如FPS游戏（CS），显性的是玩的是每一局的钱（收集），然后买枪（培养），去打同样买枪的敌人（验证），隐性的如你个人操作技术的收集（多玩攒个人经验），培养（玩多了转化为个人技术），验证（用更好的技术打更强的对手）。上述的MMO其实也多少包含这方面的内容。同样这种三角组合也会或长或短。例如单机游戏的铁三角验证通常贯穿整个游戏的生命周期，而类似dota这种游戏的铁三角基本就在一局之内完成（这也是这种游戏给玩家愉悦反馈又快又强的原因之一）。一款游戏的核心就这样由多个铁三角融洽的组合成为了玩家主要的游戏内容及动力。

在研发初期的项目框架书通常就是这样以玩法框架为核心的内容。铁三角分别是怎么玩的，围绕铁三角又会做哪些支撑分支系统。比如验证部分除了主线副本还有爬塔天梯竞技场会战等等等等。同时还需要预留接口以备未来的更新DLC等等等。除非制作人文案策划出身或者大厂有富裕的核心文案策划。否则在这个时期是不会有文化框架入场的。一是二游及MMO以外的项目文化内核一般都不受重视，二来文化框架是贴在玩法框架血肉骨骼上的皮，这张皮要想好看没点专业技术是做不到的。而且血肉骨骼没做好想蒙上文化这层皮也是无源之水。

框架书一般都是以主策为核心的初期策划组来完成，当框架书确定了就该招人把这框架书的内容实际做出来了，于是来到了扩招环节（当然有些不可能不要的职位早就提前开始招聘了）。

扩招

这部分很好理解，依照框架书里的内容招聘对应的人才去完成。复杂的内容在于一般老板不会让你随便招人，会卡你成本和人数。怎么招聘既能完成任务又能不超指标就是各个部门领导的技术了。

制作DEMO-1

有了方向有了人就要开始制作DEMO-1了。在这个阶段，研发部的三大组（程序、美术、策划）主要核心成员基本都会到位。策划会将框架书中确立的每一个模块转化为可执行的策划文档。程序则依照文档进行代码编写。美术依照文档中的UE及美术自身的开发计划进行第一版美术的设计（概念图、UI、模型、场景等）。这里着重说一下不同策划的分工及内容。

• 系统策划：这一阶段需要撰写全游戏所有框架模块的设计方案书，每个功能模块的功能结构、界面样式UE（如果有专门的UE策划会根据系统策划提供的UE进行优化）、交互逻辑等等。
• 战斗策划：这一阶段需要完成游戏核心铁三角的作战验证玩法的设计书，主要是这个游戏的战斗是怎么打的，玩家需要怎么操作、战斗流程和画面反馈会怎么呈现等等（部分特殊游戏没战斗就没这步，比如GAL）。
• 文案策划：如果是比较重视剧情世界观的游戏类型，核心文案也会在这个阶段入场，不过他们的主要工作在这个阶段是确立游戏的核心世界观及主轴故事线。通常情况下这是一个命题作文，而命题通常是制作人或者IP方已经定下的。
• 数值策划：这个阶段数值策划主要工作同样是确定整个游戏的数值体系框架，比如整个游戏需要产出多少种资源（金币、经验、素材、其他细分功能的代币），三种资源分别由哪些功能负责产出掉落，而每个资源在这些功能中的产出占比又是多少等等。然后随便给个能跑的数值让程序和其他策划在开发时能用就OK。

这个阶段的DEMO-1核心目标就是让做出一个能运转起来的游戏框架，能打能看能跑就是基本要求。当然，画面会很粗糙，UI使用时会有些别扭，特效和美图什么的更不要想。但是DEMO-1是“能玩的”，这一点非常重要。

验证

验证这部分工作在中大厂有专业的运营部门时会在游戏框架开始做的时候就同步进行。通常是发布图片或者PV验证美术风格和核心玩法是否受玩家喜欢。发布调查问卷等等形式。核心目的就是尽可能的确定项目不会做完就褒姒。

完成DEMO-1后通常会内部同行互相交流、大厂如有测试验证部门会进行一次人数不多的玩家测试（我一般叫秘密测试，因为不会宣传，游戏也没名字，玩家一般也不知道他们玩的是个啥）。如果测试结果良好就转入下一步，不好就回炉重做再来。因此这一段通常会重复不少次。DEMO1的成本一般不会太高，但是这个阶段时间非常重要。在公司高层提供的时限内过不了这一关的话，就可以宣告项目夭折了。当然如果是小厂可能项目组老大自己就是高层，这时候就会“自由心证”了，项目组自己觉得“没问题”，那就下一步。

开发step2-铺量、细化及首测

在这个阶段，整个研发组会在DEMO-1的基础上进行细化和调整。同时宣发也会开始启动，制作官网页、游戏宣发PV、各平台宣发什么诸如“代号XXXX”的预约等等。而策划会在这个阶段进行两件事，一是将DEMO-1在逻辑、表现、操作流程、提示反馈等等方面进行优化，从“能玩”尽可能优化到“可玩”。同时进一步的做后续研发的准备，除了核心内容的优化外，附属系统也会开始设计，诸如抽卡、工会、PVP、签到、月卡、通行证、充值等等。美术也会开始全力输出美术资源对项目进行全方位美化包装。程序会根据策划的优化书进行开发的同时对整个项目运行时的流畅性、加密防攻击、数据安全等等进行优化开发。同步的这个阶段会开始准备申请版号，提交一份审核版本。

随后就来到了首测，这一步的测试就会进行公开招募了，首测一般会根据预约测试用户的调查试卷进行筛选。因为每款游戏自有它的目标受众，你作为测试方如果招募的不是目标受众，在最终结论上就会出现偏差。首测或者说一测的目的就是你的产品对标的目标受众是否接受，什么扩圈什么下沉市场则是之后的事情。

一旦测试完成并且符合预期，就会进入一段常态化开发阶段，直到公测前的最后一次测试-付费测试。

开发step3-雕琢、付费测试及公测

在首测完成后，整个项目组就会进入常态开发阶段，进一步的打磨调优每一个功能，以及在数值、文化方向的深入化包装及调整。当完成一个大模块的打磨之后通常都会再进行一次对外测试，确定主轴没有偏，以及根据上次测试做出的调整是否得到了认可。整个这一阶段的目标就是把游戏从“可玩”进化到“好玩”，在里里外外方方面面都基本准备ok的情况下，就会进入最终的CB-付费测试。

这一次测试基本上需要把正式上线前能够预想到的所有问题都进行验证并通过，从玩家体验到基础-核心-扩展3类系统模块到新人指引到服务器到推广到付费等等等等。可以说近乎于高考前的最后一次模拟。一旦数据达标就会进入最终公测准备阶段，宣发会加大力度，游戏的打磨调试进入最终阶段。随后，就是公测了。

由于懂的都懂的原因，在国内公测其实和正式上线几乎没差。在之后就是常态化运营及运营期间的迭代开发了。与上线前的开发区别最大在于，运营期的开发时间节点基本上会成为绝对的死线，因为你不可能和玩家说“对不起我们没开发完，原计划这个月的活动就长草了，下个月再说。”这样会死的很难看...

到此一款游戏从0到上线的内容基本就结束了。当然，这里写的主要是以策划视角为主，实际开发时每一步每一阶段都如履薄冰。国内的开发环境来讲，每一百款立项成功的产品，能够经过调研开发测试的周期直到最终上线盈利的不会超过一手之数。这其实也能回答一个问题“为什么一款上市游戏它的购买量和价格远远超出了它开发的成本”。除了最基本的想赚钱以外，还有的问题就是在公司层面，成功的游戏需要覆盖过去失败的尸体的开销。以及可预期的在未来会前仆后继褒姒的其他产品的安葬费。

杂谈-策划案的撰写

策划案的撰写还是比较简单的，它本质上是一份给制作者的说明书。在这里我们以系统策划的策划案为基础简单说明下。

第一部分-综述

策划案的开头你首先需要概括下你写的这个策划案是做什么用的，会起到什么效果，最终目的是什么。这部分内容不要废话，简单、直接、明确非常重要。

比如你想写一个系统内部的商店系统，如果这个商店没有什么复杂的嵌套逻辑和引申含义的话，简单直接一句话：“本文档将详细叙述游戏内各种商店的使用方法和配置方式，满足玩家对于游戏内商店类功能的使用需求”即可。

第二部分-详细设计

这里就需要详细描述你的设计了，作为系统策划案来讲，重点需要写清，你的系统逻辑、UE操作、使用流程等等设计结构。针对比较复杂的系统来说，我个人推荐从使用逻辑的顺序一一写明。还是用商店举例：

• 首先入口在哪，你得能先能进商店才行。那么根据它的重要性、常用度等等是放在主界面还是某个集合菜单的内部子按钮，按钮需要什么标志等，描述出来。必要时贴参考图。
  
• 然后从入口进入了商店的主页，它的结构是什么样子？列表吗？左右滑动还是上下滑动？是否根据售卖内容以及消耗的货币不同给出多个标签页分页展示？列表内每一个商品栏都展示些什么？限制购买数量吗？点击购买后的二次确认弹窗长什么样？购买数量用尽、钻石金币不足时怎么展示和提示？买完了怎么展示和反馈？这些都需要一一说明，你需要写明所有可能会发生的情况并给出反应方式。遗漏任何一个细节都有可能会造成可怕的后果。打个比方：如果购买时点击减少购买数量可以减到负数呢？会不会反而给我钱？这是之前某款游戏的实际案例，在圈里一时成为笑料。
• 最后则是一些规则和系统背面逻辑的描述，比如商店内的售卖内容是否绑定玩家的练度，玩家练度越高售卖的东西就越高级（低级的东西在后期用不到了）。商品的随机刷新规则，手动付费刷新规则等等。

总之在详细描述这部分，你需要将整个系统的样式、结构、逻辑、规则巨细无遗写清。需要参考图、结构图、流程图要给全。漏了一点等开发完再找补的时候就会非常的麻烦。

第三部分-查缺补漏

这里其实相当于对第二部分的补充，有些较为独立的要点在这里补上就好。还有些你认为比较重要的根据你过往设计经验需要着重认真处理的要点在这里也可以再次着重说明。至此一篇设计文档就基本完成了。

配置与配置表

有的朋友问过，什么是配置表？它是做什么用的？什么时候用？这里简单说下。配置表是用来处理那些一定会经常修改的参数的表格。程序在开发时如果需要用到这类参数就会直接从这些表格转化的lua文件中提取。这样就不用修改一次参数就重写一次代码了。

举个栗子，上面写到的商店，每一个商品的价格、内容、折扣、售卖数量等等就是需要配置表来承载的参数。通常会有一张名为“shop”的表格记录这些数据。这样策划想要修改的时候改表就行，不需要麻烦程序去改代码。类似的比如技能的数值、道具的参数、剧情的文本等等，这种一旦不通过表格承载就会没完没了去麻烦程序员的数据，都会放到配置表中。

除了这类参数外，游戏中的文字通常也会使用配置表来调用，赋予每一句文字一个ID，然后代码会根据这个ID去对应的表中提取文字并展示，它的好处在于1处理丢人的错别字的时候不需要找程序改代码，2当你的产品出国海外的时候只要调取一张ID相同但是国外文字的表就行，做全球化多语言会十分方便。

配置表的结构一般会在你与程序员沟通完方案会后与程序合作进行设计，当然如果你有一定的程序设计能力自行设计再找程序沟通调整会更便捷。