【心灵实验室】如何降低开发风险？

spy

策划A:

    最近一直在思考一个问题，如何降低开发风险？记得2年前一个星期的新游戏大概也就5个左右，现在一个星期的新游戏在15个左右。现在是否还是当年做出一款就能赚到钱的时代？开发也许面临着巨大的风险。但是很多游戏扔出去，几个广告下来进来一批人，但是因为产品质量各方面的因素，直接就面临着高流失、低付费；也许直接就是死亡。我在想是否可以通过以下的方式来解决开发风险问题？

    有没有一种可能，当开发出最小可玩版本就扔到市面上去，前期一直通过最小成本拉用户进来控制在有限的人数下；不断根据数据调试修改和开发新版本，直到流失等各种数据都达到一种良好的状况，再进行大规模宣传。从而降低开发风险？

策划B   
    这样当然没有错，问题是老板都希望有一个好的版本再发布。

策划A
    这不见得……咱先不考虑老板怎么想 只考虑这个方案本身是否有可行性，而非是否有执行的可能性。

策划C
    这不就是“封测”吗？

策划D
    降低风险，现在主要使用的方式就是“抄”……不过毕竟不是长久之计……我这里比较赞同策划A上述的思路。可以将这种方式看作是一个模块化的开发。可以在设计底层的时候，尽量的时期具有较高的灵活性，然后对游戏的基础设计进行开发。然后放出一个可以进行基础游戏的版本，可以不考虑收费问题。然后逐步推出新的系统进行补充，那样可以达到一定的玩家基数，同时也可以获得一些有用的数据
    不过这种开发方式的难点在于底层设计，也就是说一开始就决定了成败。
    案例：《魔兽世界》中，游戏设计者早期便把副本服务器、聊天服务器等进行单独架设。这些架构在游戏早期中并没有显现出优势。但在之后的游戏内容填补时。则开始出现了跨服战场、跨服副本甚至在CTM版本的资料片中可以实现跨服组队和跨服聊天等设定。

策划C   
    功能内容不完整、人数有限的测试，这不就是CloseAlpha的定义吗？这应该是必须要做的事情。
    问题是发现问题之后如何修改、程序架构是否允许方便快捷的修改。
    我现在的项目就在做类似的事情，通过把模块和逻辑分离的办法，提高模块重用率，降低重构成本。可以参考Cry2引擎的FlowGraph系统

策划A  
    还有一种想法……在功能结构相似的情况下，两种数值关系，产品最终表现出来玩起来的感受完全不一样。
    那么是否有可能同时推多个版本？然后根据数据反馈做决策？

策划E
    个人感觉，在功能不全的情况下测试的局限性还是很大的，一个简单的小功能也可能对用户体验造成很大影响。这样反馈的数据就不一定能反应真实情况。
    至少要出这样一个版本也应该是功能已经相对完整，比如wow的跨服战场，初期可以没有，后期加入。但是之前的副本玩法已经非常完整。
    总结下来还是提高开发效率，培养成熟的设计团队比较靠谱。

策划A  
    就以之前说的WOW举例：
    其实我认为可以按照如下顺序拆分来依次测试：
    一.角色战斗底层、技能设定、怪物AI及分布。
    二.生产整合到之前的版本之中。
    三.任务整合到之前的版本之中。
    四.低级副本整合到其中。
    五.天赋和大型多人副本整合到其中。
    每一次测试都测如下内容：
    1.是否符合设计预期。
    2.设计预期是否合理。
    3.新的版本内容是否整合到之前设定的内容之中？
    4.是否出现其中某些内容，没有用户玩的情况？

策划A
    这里提一下，我为什么会想到这种最小集的测试方法：
    其实MMO在市场上能否生存
    绝对不是公司内部30个人能测出来的
    MMO首先是一个社会
    那就要在一个小社会的范畴内测试才会有意义
    比如：平均500—1000人在线的一个小服务器

策划F  
    我们目前就处于这种情况。算是几千人的测试。不过游戏品质还是很跟不上的。
    其实就是因为资金原因有的地方忽略了这些。。。
    或者第一次上市，感觉不好就直接放弃掉项目了。其实这些都是帮助游戏测试，游戏才刚刚开始。
    WOW开始的时候不都是荣誉系统都没有的么。

策划G
    一些通用性比较强的功能文档，做出来没有办法出彩但是不做不行的功能，可以在一个公司内统一设计，例如邮件系统、系统公告、背包栏、聊天等。各个游戏只需要设计自己游戏中的核心功能玩法，其余的模块全部复用，这麽做可以降低成本，也会降低一些风险。


策划H
    to 策划G
    但是你所说的绝大部分系统是外围系统，玩家不太会因为邮件系统不好、系统公告太多而去放弃游戏。归根结底还是需要看的是玩家最核心接触到的游戏内容。

    个人比较同意成熟团队的观点，一个成熟的团队在立项初期就能很好的定义游戏底层功能需求，并预见这个功能的可扩展性。还是wow举例，独立的聊天服务器，副本服务器在国内一些团队中如果你提出来了所得到的回答可能就是成本太高不做一类的吧。

策划I
    这个思路是可以的，但问题也很多。
    首先，最小可玩版本是怎么把握，如果只是个先期测试服务器，那没什么说的，已经有人在那么做了。
    这里要解决的，只是研发公司和运营商的协从问题。
    恩，基本上，研发和运营如果是两个公司，就没戏（一个公司，都很悬）。

    其次，要弄来一个少数人的游戏，通过十分精确的计算成本和收益，兴许能达到玩家愿意付费的要求，但游戏维护成本会大增的（或者在这段时间内，干脆就是亏本的）。
    需要有远见卓识，不急功近利的老板+资金，才能支持。

    最后，把游戏维持在少数人的境地，到最后很可能会被人选择毙掉


-------------------------------------------------

Spy：我想试试看用一些已有讨论思路的文章来引导一下本论坛的讨论气氛，所以和群主男秘商量了一下，用这篇文章做做实验，如果效果好的话以后我会经常把论坛内的好帖转发到这里供大家学习和讨论

官方代发，请勿转载。转载请保留原文完整性，并通知作者，谢谢。大家可在下面继续讨论。


简介：心灵实验室是一个关于游戏设计的讨论群，我们通过群论坛作为载体讨论游戏设计。通过一人提问，多人回答的方式，共同探索游戏设计之道。以下是某个讨论内容的整理，分享给大家。

BLOG地址：

http://thesoullab.blog.sohu.com/

-----------------------------------------------------

地球人你们好

我只看 不说话- -...

狂澜萧萧

“有没有一种可能，当开发出最小可玩版本就扔到市面上去，前期一直通过最小成本拉用户进来控制在有限的人数下；不断根据数据调试修改和开发新版本，直到流失等各种数据都达到一种良好的状况，再进行大规模宣传。从而降低开发风险？”

个人不建议用这种方式，现在市面上的游戏虽然同质化严重，但是另一方面玩家的挑选余地也很大，这就决定了玩家不可能很有耐心等着你慢慢去完善你的游戏，过一阵玩不到新内容，人就跑了。

很多篇幅在讨论WOW的设计，没错，WOW一开始推出，45级封顶，但是这只是游戏的情节内容而已，从玩法上来说，除了战场、团队副本，还有什么是玩家在45级封顶的时候还没见过的？

后期的跨服战场之类的，也是在技术上可行之后，对玩家的一种便利性扩展，并非玩法上的扩展。

开发上的功能模块化倒是一个很好的思路，也有不少公司在这么做，这是个好趋势，对于降低开发风险和开发成本，以及后期的功能扩展，都很有好处。比如服务器进程按照功能进行划分，而不是按照地图区块进行划分。

bal

前些日子还在和之前的一位技术出身的前辈讨论过相关事情，当时的论题是：现今的开发方式是否已不再适应网络游戏的开发需求。
我个人的观点是——目前的开发方式仍然沿用着以整体框架+内容的方式，而现今的网络游戏早已发展到A所讲的由一个基础玩点无限扩展，随玩家需求和反馈不断变化的走向（尤其运营加入后往往已经不再按照策划最开始的构想在做游戏）。这就要求开发必须要不停地对框架进行修改、甚至重构，充分体现了现有开发方式已经严重落伍。

从理论上讲，我是同意A的做法的，事实上也的确有不少类似的团队是这样做的，但这样的团队有个很明显的特征，是人员通常很少，而且大多没有资本层面的压力（说白了就是没什么项目进度压力），举例比如Mount&Blade的夫妻店曾经运转了两三年，才在1.0即将来到之时扩充到两位数团队。应该说，在这种毫无压力的爱好型创业基础上发展起来的团队，使用A所讲的研发方式能将风险降到最低。

而从游戏公司的角度来说，现在大趋势是上游大佬们拼命提高门槛，来阻挡下方成群的小狼崽子，所以动辄百人团队几年的研发，几百个人物模型，动辄几千万的推广费用，“用钱砸死你”这个逻辑在此时显得无懈可击。同时这也是最适合大佬们、风险最低的研发方式

对于小狼崽子们来说，拼命地山寨，快节奏出牌，紧抓市场热点和时机则是目前主流的研发方式，同时，也一样是对于他们来说风险最低的。

所以，在没有资本层面压力注入的前提下，我支持A的看法。而从现实角度出发，选择最适合自己的路线才是王道。

52MARY

作为一个在小公司的打工者深刻的体会到，技术积累是多么重要。

上述方法个人觉得均需要成熟的技术基础做为支持；

我们现在的方式就是先做“原型”然后在此基础上进行扩展；

而实际情况是技术部分进入了迭代开发（策划希望是螺旋式的），策划提出的需求都会导致技术部分推倒从新开始。

开发周期长 资源消耗大~  [em4]

Ross

增强概念阶段的重要性...
以工程原理作规划设计...
敢于对游戏的设计框架负责...
敢于对后续伤筋动骨的需求改动说不...
必须的,也是必要的,同时更是高难度的...

狂澜萧萧

后续的改动也未必就是伤筋动骨，看前期的架构设计了，够灵活的话，仅仅是靠前期的东西进行组合搭配就可以产生很多新的功能出来。

现有的开发模式，很多时候缺乏规划，进而导致缺乏预见性，现有的东西是可以很好的完成了，但是可扩展性非常差，这种隐性的风险才是最大的问题。

Ross

话说某版主带的项目就差不多是用A的方式做的...
或者他就是A....
恩= =0
哇哈哈....
好策划很多都在尝试做这样的一些事情了...
理念的更新啊~~

看过了太多开发做了大半,却没有设计预期的项目...

Ross

狂澜萧萧: Re:【心灵实验室】如何降低开发风险？

后续的改动也未必就是伤筋动骨，看前期的架构设计了，够灵活的话，仅仅是靠前期的东西进行组合搭配就可以产...

我又没说后续改动一定是伤筋动骨的....
伤筋动骨是定语= =0

就因为这个原因所以才说要加强概念设计阶段啊...
概念设计阶段就应该把会影响程序架构,底层模块的需求定死...
同时也应该把影响美术工件规约的东西定死...
其实这些东西有公司在做的...
例如腾X内部有一个项目询问表...
当然,他们有了这个表用得并不好
毕竟有了表填表质量如何,还得看是谁来填....

Ross

不久前才听说成都某公司开了个新项目
两个小策划拿了一本陈忾模版的策划案忽悠忽悠开的...
项目经理是一个对技术\美术没任何了解的策划...
DEMO做了两个月后,没形成任何有效的可执行程序
策划规划档没有任何变更增加
空做了一堆技术测试
所有需求仅一句话--请参照之前他们带来的洋洋洒洒数万字的策划案....
相当有喜感...