用投资和收益方式来选择功能

spy

大家都知道，一个系统内不是细节越多越好，不是功能越全越好，不是UI越细越好，那么如何来取舍游戏设计中的功能子项呢？

有的同学会说，用WBS树和SWOT分析的来做评估。这没错，但是对所有功能都做WBS的话会累死，就像进行任何运算都要操作计算器一样。当需要口算的时候，可以试试以下这个简单的思路：

【用投资的角度来评估你的功能】

每一次选择都是投资，当我们明白得到的和需要投入付出的都是些什么，选择就会相对容易，也就是做出正确的选择。

而做选择前，了解的信息越多越真实，选择也就越容易。

比如某策划面临一个功能，主策划需要一个功能来丰富战斗系统，而这里有一个功能叫“仇恨列表”，有好的案例wow，但是我们没有做过。是否要做仇恨？我们要做出选择。

选择的左侧是我们要获得的，也就是“收益”：

仇恨系统我很熟悉，因为我玩过wow；

其方便理解，很好拿wow来举例。

很好玩，可以用其配合怪物ai做出丰富度很高的动作。

该功能普及率很高，很多游戏都抄了这个功能做到自己的游戏里。我们也能做，又不差钱。
.
.
.
        选择的右侧是我们要付出的，也就是“投资”：

        我认为：开发仇恨需要在每个怪物身上做一个数据列表，因为我游戏是打怪游戏，一张地图上有1000只以上的怪物，这就需要1000个数据。

        我游戏内倾向玩家组队为6人，而仇恨我希望是跨越一个队伍生效的，所以至少要记录10名对象。也就是1000X10，为10000行。

        程序说，10000行数据的即时读写基本浪费了一台地图服务器的40%资源。

        为了满足仇恨列表的丰富性，所有怪物都要有比较细腻的ai来起到更好的作用，类似wow那样多变的生物习性我估计着要做他300种以上的判断。

        脚本策划告诉我，这是不可能的，我们的怪物行动逻辑只有10条。（很多游戏实际上还不到这个数量）

        我们的游戏似乎没有必要做这么复杂的战斗，因为基本上玩家都是在挂机打怪。
.
.
.
综合：投资大于受益，不选择。

当我们清楚我们的投资和收益的时候进行选择，其实是一个好的开始，我们会更注意自己的投资的投入，比如某个功能的开发是我们必须的投资，否则就没有回报，我们的培养也就变得更容易，否则很多人会认为开发该功能会成为一个包袱，最后沦为鸡肋。

合适的选择不一定有好的结果，但是至少是一个好的开始，稀里糊涂的选择往往会成为一个坏的开始，噩梦的开始。

提升自己的选择和判断能力，是走向成功的基本要素。

理性的选择会让你失去很多投机的机会（失去的机会是你的投资），同样你获得的是长远而稳定的成长和平稳的心态（这些是你的收益）。  
.
.
.
Blog原文请点击：这里
.
.
.

czqwayne

说白了 就是性价比咯？

spy

其实就是S和W优劣势分析，只不过用直白的例子便于理解

czqwayne

嗯 只是这里的S特指收益 W特指投资
很好很直白
===
原创2字太过显眼 去掉了更和谐 [em19]

sjinny

我认为：开发仇恨需要在每个怪物身上做一个数据列表，因为我游戏是打怪游戏，一张地图上有1000只以上的怪物，这就需要1000个数据。

我游戏内倾向玩家组队为6人，而仇恨我希望是跨越一个队伍生效的，所以至少要记录10名对象。也就是1000X10，为10000行。

程序说，10000行数据的即时读写基本浪费了一台地图服务器的40%资源。

程序的结论貌似是根据策划对程序实现的推测做出的……这时应该做的是直接把原始问题交给程序，而不是问他“10000行数据的即时读写”会耗费多少资源……要么这个案例只是YY，要么就是这个作者在实际工作的时候也宁愿YY而不去直接问程序……
一张地图上有n只怪，不代表有n只怪在战斗状态，而没有战斗的怪是不需要仇恨列表的……即使在战斗状态中的怪，也并不总是要记录m个人的仇恨，如果这只怪这次战斗只与一个人相关（玩家solo的情况），那么仇恨列表里只会有一个人……最后……仇恨列表也不是每时每刻都在操作的，因为玩家的技能使用有cd，怪物的ai更新频率也是可以限制的……
而那个程序的结论……本来对于这么模糊的问题是不可能在测量之前就给出“40%”这样的数字的，甚至连这是不是个瓶颈都不那么好判断……所以要么作者被程序忽悠了，要么作者在忽悠读者……

nofear

按经济学的观点，一个理性人在完全信息的情况下，任何时候做的任何事情都是边际上利润最高的事情，何况做游戏。

之所以做游戏的时候没有做利润最高的事情，无非3种原因：
1，非理性
2，非完全信息
3，成员之间利益冲突

大武

在做选择时，进行理性分析，思路不错~

spy

sjinny: Re:用投资和收益方式来选择功能


程序的结论貌似是根据策划对程序实现的推测做出的……这时应该做的是直接把原始问题交给程序，而不是问他...

随便扯了一个案例而已嘛，何必当真呢 [em12]

我前面有前提了，该公司没有人做过该功能，所以对可行性分析和技术优化自然不会想太多。如果真的做了技术分析就不叫口算草估了 [em9]

sjinny

如果这个案例是真实的……那就说明那个策划是在用自己业余的YY来代替团队合作……作为程序，最讨厌这种脱离实际的YY……

spy

策划做一个新功能，先yy再分析是很正常的。交给程序的东西一般是分析、验证和细化后的东西，不在此例范围内。这个故事的应用范围是如何区分有效的yy和无意义的yy