最近在给《猪头三大冒险》加新的机制，顺便梳理一下对这个问题对理解

游戏系统分析就像象棋开局一样，虽然以后还能改，但是对整个过程和结果关系重大

下面是一些曾经看到过的前人经验

一、CDPR的功能矩阵（列表分析）

几年前CDPR的一次分享中，分享过他们是怎么决定一些新的功能要不要开发的

https://www.youtube.com/watch?v=moW8-MXjivs&feature=emb_logo（第一次看到这个分享是来自奶牛站 @囧囧囧囧 同学的搬运）当然要对具体情况独立思考，这里面的思考方式值得很多开始做游戏就想一出是一出的人学习（比如我自己）

搞不搞

可以先从两个大维度分析一个功能点的开发价值

价值 和 成本

    价值又分为 产品价值、系统价值、趣味性、

            产品价值：简单理解就是这个东西做了以后能不能吸引玩家买我们的游戏

            系统价值：这个功能对整个游戏系统是不是很有帮助，会不会让玩家操作更便利什么的

            趣味性：这个设计是不是让游戏变得更有趣更新奇了（我觉得使命召唤多人模式的“光荣弹”就相当趣味）

    成本又分为 时间成本、费用成本、开发风险

            时间成本：一般开发成本，内部员工的人月这种

            费用成本：需要外部资源的内容（比如配音剧情、外包美术啥的），大概吧

            开发风险：会不会和其他系统耦合，开发难度，会不会开发一半出问题之类的

最后（也不用非这么算，太功力了）

总价值-总成本=功能价值

或者直接基于这些分数进行分析，再结合一些无法量化的因素

这个方法其实还是凭感觉的，大公司用来开会挺有用的，但是一些特殊情况可能忽略很多决定性的因素，不是所有东西都是可以用数字来代替的。

搞了会怎么样

如果要开发的功能是建立在既定系统上的话，就需要考虑另一个问题，耦合后带来的问题

这个问题在这个功能没有开发出来之前是很难想清楚的，CDPR的方法是列一个功能表

依据这个表来研究系统之间的关系，然后再看要不要 改功能、加功能、删功能。

所有需要一起分析的功能都列在横轴和纵轴中，交叉点写出他们对对方的作用，然后来对他们进行分析。具体分析啥，不用纠结他们在分析啥，看自己具体遇到啥问题吧

二、游戏系统导图（误）

之后我看到Indienova的一位大佬分享的文章中用了一个游戏系统导图（我起的简化名字）的方法，受用至今，比CDPR那个功能表更形象一点

不过当系统比较庞大的时候，还是CDPR那个比较好

https://indienova.com/indie-game-development/the-introduction-of-gsml/

猪头三大冒险的新功能系统分析，为了保证游戏能有点惊喜，细节就打丑丑的码了。虽然有点乱，但是用来分析具体问题的时候还是能通过整理这张图逐渐想明白问题的。这个图是在分析黄色圈中的机制对整个系统到底有多大价值，会有什么新趣味。

题头是随便找的一个系统，没什么实际的意义。不过看了一发现，如果骑马与砍杀的指令集中有针对地形的指令会比较有趣，比如：步兵坚守高地、弓弩手坚守山腰、包围那个建筑之类的。（可能人家本来就有）

无论什么办法，一定要结合自己的游戏好好感受，对方法本身做出一些思考，甚至做出一些调整改进