魔卡幻想吧 关注:130,464贴子:3,867,898
  • 9回复贴,共1

大发现!魔卡果然会圈钱

取消只看楼主收藏回复

今天过5-8的时候,发现电脑冰弹的发动概率几乎是100%
于是特意记了一下每一回合战斗顺序,和每次电脑发动冰弹的几率
结果发现两遍尝试过关每一回合动作完全一样
第一遍,我方刷出的第一张牌是狮鹫,第二张精灵法师,对方头两张牌是梦魇,堕落精灵法师,堕落精灵法师第一次冰弹冻住了狮鹫,第二次两张牌都冻住了,后面几乎每一回合我方都有两三张牌被冻住
所以我当时就不甘心,因为只要对面冰弹几率正常,和摸牌运气再好一点,我是能过关的
于是再过了其他几关普通困难难度之后,我又试了一遍5-8
结果头一张牌又是狮鹫,第二张又是精灵法师,对方头两张牌也还是梦魇,堕落精灵法师,后面就一模一样了,每一回合被冻的牌也都一样
这就说明一个问题
第一次过关运算过后,服务器就储存了这一步骤,下一次还这么来,大部分玩家出牌习惯不变,于是两次对战结果及每一回合动作都一样,这样一来可以减少服务器运算负荷,但还有更重要的原因
也就是说,我两次尝试通关,服务器一开始就没打算让我过,所以特意把我的“运气”变得很差。
简单地说,魔卡想让你过关你就能过,不想让你过,你试几次都不成。
所以有很多人发帖说电脑的控制技能成功率接近100%,自己用就不是那么回事了。
通过这种方法,服务器每天通过控制你的“运气”来控制你过关卡的数量,让你既不能很快通关,也不至于总过不了关而放弃这款游戏,时间一长,就有玩家受不了冲动去充人民币买行动力或者买魔幻包,运营商圈钱的目的就达到了


IP属地:安徽1楼2013-01-12 20:12回复
    补充一下,连续两次试同一关大概不会出现这样的现象
    我在第一遍尝试之后大概过了二十分钟再去试第二遍的
    这么长时间大部分人都不会记得第一次出牌的顺序和每一回合的战局变化
    这次凑巧我特意去记了战斗脚本,因为觉得电脑冰弹控制率高的惊人,要不也发现不了


    IP属地:安徽2楼2013-01-12 20:17
    回复
      2026-02-14 20:53:42
      广告
      不感兴趣
      开通SVIP免广告
      我本来还觉得魔卡做得比较好
      这样一想就觉得没必要玩这款游戏了,什么卡牌搭配,什么战术,都是假的
      还不如去玩一些即时网络对战游戏,比如混沌与秩序之英雄战歌,弹弹岛战记什么的,只要技术好,赢面就大


      IP属地:安徽4楼2013-01-12 20:26
      回复
        我发现很多朋友都对服务器进行如此运算的承受能力表示怀疑,这里简单分析一下这种方案是否可行。
        第一点,服务器终端干预玩家单机过关过程的证据
        细心的玩家可能发现了,即使在我们单人过关的时候,不联网也是不行的,而且在每一关的战斗中,会时不时的出现Loading的字样,也就是“(数据)加载中”的意思。
        大家又没有想过,既然是单机过程,而且我们的设备上有了所有的双方卡牌,游戏规则,事件概率等种种数据,完全可以在我们的设备上演算游戏进程,而没有必要和终端联接,反之如果每一步的运算都由服务器来进行,那样服务器才真正会受不了。
        那么可以推断每次加载的信息和游戏的演算无关,这样的数据就是终端给我们的设备下达的命令,让设备操纵对战结果,根据开发商对玩家心理的把握(可以通过收集之前玩家在线,消费的数据来推测玩家类型),来决定是否让玩家过关。


        IP属地:安徽15楼2013-01-13 11:34
        收起回复
          接下来是大家最关心的第二点,
          开发商是否有能力做到这一点而又不导致服务器崩溃
          也就是大家提问两个问题焦点
          1,这样的技术是不是太神了?
          2,普通网游的服务器能不能胜任这样的运算?
          在此我做出回答,
          1,这种技术不神奇,甚至可以说在网游中已广泛使用
          2,这点运算对于现代计算机根本不算什么,况且魔卡运营团队已经用了很多手段来缓解服务器压力
          下面请容我一一道来


          IP属地:安徽16楼2013-01-13 11:42
          回复
            首先是第一个焦点,
            这样的技术是不是太神了?
            这种技术运用很普遍,我不认识任何魔卡团队的成员,但是我可以保证,假设我是魔卡运营的主要负责人,如果老板让我设计一个方案左右玩家的胜负,我会相对轻松地完成这个方案,并且保证我的程序员能完全领会我的意图并轻松地写出这样的脚本。
            我会设计出如下方案
            1,分段数据运算
            所谓分段数据运算,就是不用实时监控玩家的每一回合动作,而是在特定的时候把玩家设备上的数据收集过来,进行运算后再对玩家设备发出指令,减小运算负荷。
            为了让大家更好理解,这里举一个例子,(前提:系统让玩家输)
            玩家门都会这样的战术,让英雄先扛,等当适当的时机再出牌,让自己MT顶在前面,DPS和奶妈在后增加胜算,不过有时候没算好英雄会先挂。而一旦服务器已经算到这一步,不管玩家后续怎么出牌,英雄都会先挂(再次强调一下计算机的运算能力远远胜于人类,玩家有时算不好,但这点运算对于服务器根本不算什么),那服务器就可以停止对这台设备的监控和数据传输,而让设备按客户端游戏文件内置的数据和规则演算,这样服务器减小了负担。反正怎么样这个玩家都赢不了。


            IP属地:安徽17楼2013-01-13 12:03
            收起回复
              2,“一边倒”战术+分段数据运算
              此策略也建立在分段数据运算的基础上
              还是刚才的例子,只不过我们转换一下玩家策略,如果这一次玩家正确的计算了英雄血量,正确出牌并不会导致因英雄血量耗尽而失败,那么这场对战不到最后就不知道结果,因为有概率事件在里面。
              那么如果系统还想让玩家输,同时又要减小运算负担,怎么办?很简单,采取“一边倒”的方法
              让我们先看几个回复本帖朋友的悲惨遭遇:
              “有次打9-6-3,月兽40%的闪避次次MISS,九头+大象都做不掉她。。。
              ”——BY gwuh163
              “对面各种脸好miss,群控,我这边群控就控不到人。。。”——BY 苍冰V子路
              其实这就是服务器给我们的设备下达了命令,把对电脑有利的技能发动成功几率调高,把对玩家有利的技能发动成功几率调低,使玩家在前几个回合就落下风,迅速丧失战斗力,而一旦玩家战斗力损失到一定程度,就会产生滚雪球效应(前排站不住,后排一个个被秒),电脑的优势将越来越大,直到完全“一边倒”,即玩家再怎么出牌,双方技能成功率再怎么变化,玩家都赢不了,服务器就可以停止监控,让设备自行演算,反正玩家赢不了(回归到分段数据运算这一方法)
              后面几个方法等会再打,其实说到这里大家也能自己猜到一些了吧


              IP属地:安徽18楼2013-01-13 12:23
              回复
                下面说出第三种方法的名字:
                重复演绎法
                大家猜一猜原理是什么
                提示:是不是感觉卡关时好几次死法都一样?


                IP属地:安徽19楼2013-01-13 12:31
                回复
                  2026-02-14 20:47:42
                  广告
                  不感兴趣
                  开通SVIP免广告
                  这里再补充一些减少服务器负荷的方法,同样大家自己想一想原理
                  1,为什么排名战一天只有十五次机会,而且打完一场要等十分钟?
                  2,为什么会有行动力的限制,而且过关时不能Skip(略过)?而刷迷宫时,自由对战,排名战时就能跳过?
                  3,为什么魔神战要等两分多钟才可以打下一次?
                  其中固然有鼓励玩家消费晶钻购买行动力或时间冷却的原因,也有让玩家想玩却玩不了,吊胃口维持玩家游戏时长的原因,但更重要的,也是在减小服务器负荷


                  IP属地:安徽20楼2013-01-13 12:37
                  回复
                    通过这些分析我们可以得到一个启示
                    “透过现象看本质”
                    其实在万千玩家屏幕上纷繁复杂,变幻无穷的战局后面,流动的无外乎是横跨空间的一串串冰冷无情,甚至是被动过手脚数据,还有商人那永无止境的贪欲罢了。


                    IP属地:安徽21楼2013-01-13 12:45
                    回复