二 游戏策划入门科普文案和系统策划要做啥( 三 )


这个原型图是在写这篇文章的时候利用几分钟时间画出来的, 所以版面什么的没有经过细调, 这里图标均使用了有颜色的框表示, 实际的项目开发中, 如果美术已经提供了正式的图标, 可以在策划文档中用正式的UI框和图标来拼UI原型图 。
另外则是系统策划在设计的时候一定要注意各种元素在界面中是否有显示, 比如在购买界面中, 需要充值的道具是钻石, 那么一定则需要在购买界面中显示出当前钻石的数量, 否则就可能出现很多问题, 比如用户充值了一笔后, 并不知道是否实时到账了 。
原型图就是做满足用户需求设计的第一步, 这个需求你可以模仿, 也可以通过自己的经验来推测, 比如上图原型图中, 可能你会觉得用户还需要查看充值记录, 所以你可以顺带增加充值记录的功能 。 不过有一个要点是, 界面的功能数量一定要取舍, 少了会影响体验, 多了也会影响体验, 其实我是很反对那些在主屏幕上显示4-50个功能图标的游戏的 。
这里总结一下原型图的要点:
布局符合所在平台的操作规则, 尽量不要自行设计反用户习惯体验的操作;
需要的数据尽量显示在界面中, 忌讳让用户无法实时得知数据改变的情况;

二 游戏策划入门科普文案和系统策划要做啥

文章插图
让用户减少操作步骤, 能一次点击达到目的就别设计成多次点击(充值需扣钱让用户再次确认这种情况除外);
功能数量要取舍, 太少和太多都不好 。
第二步功能描述
原型图画好后, 第二步是需要进行功能描述 。
功能描述示意图
为了将功能描述的够清楚, 有时候会需要绘制多个原型图游戏策划文案, 所以这种时候最好的办法就是复制前面的图, 并在前图的基础上修改原型图 。
另外需要用文字描述出功能的细节, 这里的描述有个技巧, 那就是像任务列表一样的分条描述, 这样描述的好处在于程序拿到文档后就像得到了工作list一样, 可以根据描述逐条完成功能 。 (有很多策划会责怪程序看文档不仔细, 经常忘记制作某个功能条目, 其实这种情况下, 策划也分析一下自己的文档是不是文字描述长篇大论, 结构混乱, 分条不清晰)
策划描述细节的时候尽量做到完整, 当然也有很多时候策划无法做到一次性完整的描述功能, 这并不是问题, 遇到这种问题具体的解决方式在本文章最后验收阶段说明 。
这里顺带补充一下, 一个好的界面用户体验中
能在一个界面中完成的操作请不要切换多个界面
是和否的按钮能区分颜色当然是最好的, 试想一下如果外国玩家不认识汉字怎么让他上手
能用图像展示的部分一定要多用图像或者图像结合文字的方式来展示 。
第三步 设计配置数据
策划在设计系统的时候, 一定要合理的为程序减压, 尽量的把功能设计成数据表或者设计成可配置的条目, 不然在游戏后期维护中会出现很多尴尬的现象, 比如修改一个道具的价格也要找程序重新写功能, 程序会被你们累死的 。
配置数据案例

二 游戏策划入门科普文案和系统策划要做啥

文章插图
在策划中表明界面的哪些地方是可以通过数据表配置的, 一般来说所有的文字类内容都是可以配置的 。
关于配置表这块, 一般主程都有自己的想法, 所以在撰写时可以跟程序讨论, 最终决定需要配置的内容 。
上图这个策划案子可能部分初学者看不明白, 不理解具体要怎么配置, 这里可以举个例子 。
假如这个是数据库里的配置
上图配置了4个条目, ID为自动增加的编号, price就是策划配置规划中的价格(后面几个英文同理, 翻译一下你就知道)
将这样的表填好后, 导入数据库再清理一下缓存, 游戏中的购买界面就会出现4个条目了, 这样做的好处就是程序只用写好功能就可以了, 可以为程序减轻很多后期维护的精力 。
第四步与其他部门沟通可行性
一般来说, 在文档初期设计前策划内部都已经沟通过, 当然有时候在与其他部门沟通时主策划还会检查一下系统是否满足, 是否存在问题, 当主策划确定没有问题后, 才会进行会议 。
会议的主要目的就是让负责整个系统完成的程序、美术部门了解系统的功能, 以及了解所需要的技术是否满足, 如果技术不满足, 那么多半的情况是策划修改文档, 不过我也推荐策划修改文档, 对功能进行妥协, 否则后果就是整个项目的时间变长, 加班变得更多 。 (不过像一些基础功能, 比如点击一下弹个框程序都说无法实现的, 那我觉得这种程序可以失业了)

推荐阅读