后使用快捷导航没有帐号？
查看: 29025|回复: 94
新人欢迎积分0 阅读权限50积分1182精华0UID6771200帖子金钱1357 威望0
Lv.5, 积分 1182, 距离下一级还需 1318 积分
UID6771200帖子威望0 多玩草10 草
坦克世界王道 死蹲& && && & 效率胜率不涨你来找我
坦克世界进攻不利谁都知道
1 天道 真正战争进攻方起码三倍人数，坦克世界15v15没有人数差异。不符战争准则。战争就是牛刀杀鸡，以强博弱。
2 地利 防守方以有掩体有草打没掩体没草。并且容易形成交叉火力。
3 人和 进攻方绝对不能齐心，重坦进攻，头车上了被集火死了，后边人黑枪，中坦给重坦拉炮线，重坦不上，中坦死了被卖，必然的。
坦克世界最重要的事实是，如果双方实力相当，先进攻者必败。进攻者必然劣势，进攻死的人多了，就被守方反攻输掉。比如同样1000效率的2个查涤纶，肯定守方先手开炮，必胜。
如果效率差距大的话，就不一定谁胜谁败。
而所有的翻盘局全是这样的流程，我方进攻，被干掉一半人，我方劣势，我方转为防守，对方转而无脑全军进攻，我方防守给力，交叉火力或者埋伏掉对面，胜利。
而有时候会出线平均700打掉平均1000的也是因为700效率的一方龟缩防守，1000效率的主动进攻不利各怀鬼胎输掉。1000的如果防守的话没有任何可能输掉。
为什么大部分局都是高效率的活到最后在打残局，1000以下幸存都比较低。最根本的原因是低效率的蹲不住。
我这里做两个名词解释
1 点灯， 不是开场直冲对方基地，那叫肉侦。点灯的原则是我不亮对面亮（静默），我亮对面打不到我。能打到我打不穿我（卖头点），能打穿我打不死我。
2 黑枪，不是蹲基地圈里，不是火炮旁边。黑枪是以不亮打点亮（有草打旷野），有掩体打没有掩体。我能打你不能有效反击为都可以认为是黑枪。
我们既然知道进攻劣势，那我们就防守，所谓防守，就是黑枪，就是我能打你而你打不了我。
我们为什么不点亮，主要2点原因。
1 心情问题。谁都不想开局1分钟被打死，玩游戏被虐杀谁都不开心
2 收益问题。点亮危险大，死的快，死的快就没有输出，没有输出经验和钱都少，赔修车费。便宜别人的事情少做，要做也要绝对安全的点。
3 小贴士，无论盒子效率还是xvm，点亮伤害几乎不计入效率，即使10000点亮也完全不长多少效率。所以让别人点灯去吧。但是游戏经验钱还是给的。
我们为什么要黑枪
1 心情问题。即使输了你打出成吨输出，最后一个死掉或者幸存，心情也未必不好。我们心情不好玩往是因为输出少了，没有打爽，而绝对不是输掉。
2 收益问题&&黑枪收益高，输出越高收益越高，还不受伤，打出过万输出一点不掉血，必然爽。
所以蹲坑王道，黑枪有理，即使是不悔有你去拉斯威利中间点灯也是1分钟死掉。所以大部分时候他们开中坦偷枪，黑枪，队友抗炮，他们弹夹车桡侧后。但人总有心情不好冲动是魔鬼的时候，所有偶尔他们也会去扛一次半次，不需要以此反驳我。
游戏就是这样，黑枪黑的好，就是火力支援，卖队友者卖的好就是大神。没有队友买自己，只有自己卖自己，觉得自己在孤单第一线了，就撤吧，有危险了就跑就是。
点灯多了就容易上火，人一上火就容易缺心眼，玩坦克世界啊，过去啊我一直缺心眼，自从我学会了黑枪，嘿，我变机灵了，效率也高了，胜率也涨了，一口气干到1500了，真灵。
逻辑关系，
1蹲得住你就活的久，活得久你就输出高，输出高心情收益都好，何乐而不为。
2对面的蹲不住进攻，进攻方劣势，对方人数劣势大了的话，我们才可以进攻，人数多进攻才能成功，才能赢。
3对面如果也蹲得住，你也不能进攻，你要比对面更有耐心，否则你进攻死了，导致我方劣势，你就会输，何必去送死，不死还有胜利的可能性，如果死了指望队友帮你赢吗，呵呵呵
&&况且蹲着就算平局也不亏修车费，也不会影响心情。
所以蹲者王道。蹲者胜道，点灯你觉得自己nb就去，谁蹲不住就会输。为了胜率和效率和游戏心情，放心大胆不要上，死蹲到底。至于
抗炮扛线拉炮线，省省吧小白，谁乐意谁去吧，被卖几次就知道怎么做了，说我不对的，你玩多了就知道我说的对不对了，非要喷我的我希望你游戏里和你说的一样生猛。
如果觉得接受不了，看下边的
克世界王道&&耐心 （ 学会等待&&等待对方犯错）。& && && & 效率胜率不涨你来找我
SZ说了蹲在后边一定不会死吗？这不一定，但是冲在前面一定死的快，你以为2个3个的击杀环怎么来的
昨天有好多人说我教大家黑枪，和死蹲，我今天把死蹲改成耐心，黑枪改成火力支援的 我觉得我的心得立马高大上了&&
坦克世界进攻不利谁都知道
1 天道 真正战争进攻方起码三倍人数，坦克世界15v15没有人数差异。不符战争准则。战争就是牛刀杀鸡，以强博弱。
2 地利 防守方以有掩体有草打没掩体没草。并且容易形成交叉火力。
3 人和 进攻方绝对不能齐心，重坦进攻，头车上了被集火死了，后边人黑枪，中坦给重坦拉炮线，重坦不上，中坦死了被卖，必然的。
坦克世界最重要的事实是，如果双方实力相当，先进攻者必败。进攻者必然劣势，进攻死的人多了，就被守方反攻输掉。比如同样1000效率的2个查涤纶，肯定守方先手开炮，必胜。
如果效率差距大的话，就不一定谁胜谁败。
而所有的翻盘局全是这样的流程，我方进攻，被干掉一半人，我方劣势，我方转为防守，对方转而无脑全军进攻，我方防守给力，交叉火力或者埋伏掉对面，胜利。
而有时候会出现平均<font color="#ff打掉平均1000的也是因为700效率的一方龟缩防守，1000效率的主动进攻不利各怀鬼胎输掉。1000的如果防守的话没有任何可能输掉。
为什么大部分局都是高效率的活到最后在打残局，1000以下幸存都比较低。最根本的原因是低效率的不够耐心。
我这里做两个名词解释
1 点灯， 不是开场直冲对方基地，那叫肉侦。点灯的原则是我不亮对面亮（静默），我亮对面打不到我。能打到我打不穿我（卖头点），能打穿我打不死我。
2 火力支援，不是蹲基地圈里，不是火炮旁边。火力支援是以不亮打点亮（有草打旷野），有掩体打没有掩体。我能打你不能有效反击为都可以认为是火力支援。
我们既然知道进攻劣势，那我们就防守，所谓防守，就是黑枪，就是我能打你而你打不了我。
我们为什么不点亮，主要2点原因。
1 心情问题。谁都不想开局1分钟被打死，玩游戏被虐杀谁都不开心
2 收益问题。点亮危险大，死的快，死的快就没有输出，没有输出经验和钱都少，赔修车费。便宜别人的事情少做，要做也要绝对安全的点。
3 小贴士，无论盒子效率还是xvm，点亮伤害几乎不计入效率，即使10000点亮也完全不长多少效率。所以让别人点灯去吧。但是游戏经验钱还是给的。
我们为什么要火力支援
1 心情问题。即使输了你打出成吨输出，最后一个死掉或者幸存，心情也未必不好。我们心情不好玩往是因为输出少了，没有打爽，而绝对不是输掉。
2 收益问题 火力支援收益高，输出越高收益越高，还不受伤，打出过万输出一点不掉血，必然爽。
所以耐心王道，黑枪有理，即使是不悔有你去拉斯威利中间点灯也是1分钟死掉。所以大部分时候他们开中坦偷枪，黑枪，队友抗炮，他们弹夹车桡侧后。但人总有心情不好冲动是魔鬼的时候，所有偶尔他们也会去扛一次半次，不需要以此反驳我。
游戏就是这样，火力支援的好就是大神。只能你配合队友，不能指望队友配合你。队友如果上了，你就帮他火力支援，队友如果不上，你耐心等待队友转场抱团后配合进攻，或者等待对面进攻发错， 就行了。
点灯多了就容易上火，人一上火就容易缺心眼，玩坦克世界啊，过去啊我一直缺心眼，自从我学会了火力支援，嘿，我变机灵了，效率也高了，胜率也涨了，一口气干到1500了，真灵。
逻辑关系，
1 耐心你就活的久，活得久你就输出高，输出高心情收益都好，何乐而不为。
2对面的耐心不够进攻，进攻方劣势，对方人数劣势大了的话，我们才可以进攻，人数多进攻才能成功，才能赢。
3 对面如果也耐心够，你也不能进攻，你要比对面更有耐心，否则你进攻死了，导致我方劣势，你就会输，何必去送死，不死还有胜利的可能性，如果死了指望队友帮你赢吗，呵呵呵
&&况且蹲着就算平局也不亏修车费，也不会影响心情。
所以耐心王道。耐心胜道，点灯你觉得自己nb就去，谁耐心不够就会输。为了胜率和效率和游戏心情，放心大胆不要上，耐心到底。至于
抗炮扛线拉炮线，高手去做，凡人水平不到，不要模仿。
实力相当的情况下大部分地图都是进攻者败，普罗霍洛夫卡的山，埃勒斯堡的桥，埃里哈罗夫的水，斯特拉特福全图，拉斯威利的城，荒漠小镇全图，迷雾小镇，阿拉曼机场，雅尔塔小镇，鲁别克外围，齐格飞防线外围，想想就知道对不对。
本帖最后由 udsaga 于
11:06 编辑
&我觉得说的非常正确 ！！！ 特别是那些特别地图&
&楼主 智商 拙计&
&已举报 谁那么快，没意思！lz一看就是无脑动物&
&多次132点灯发现对面偷偷推进，队友半天不开火，回头看队友和火炮斗地主呢&
：比较喜欢单野，偶尔组队，《美军的错误》北区&
&蹲也没用。。。有草比不过别人车组成员技能高。。。蹲草里别人能亮你他自己不亮。。。一样被黑死。。。&
&所谓进阶的站场意思不外乎 该蹲蹲该冲冲
现在就是要么无脑冲要么无脑蹲 拦都拦不住&
作者被禁止或删除 内容自动屏蔽
作者被禁止或删除 内容自动屏蔽
新人欢迎积分1 阅读权限30积分80精华0UID帖子金钱272 威望0
Lv.3, 积分 80, 距离下一级还需 170 积分
UID帖子威望0 多玩草0 草
你又写了一遍啊。。。
新人欢迎积分1 阅读权限30积分80精华0UID帖子金钱272 威望0
Lv.3, 积分 80, 距离下一级还需 170 积分
UID帖子威望0 多玩草0 草
进攻真的是有很多理解的，微观和宏观。你开炮就是进攻，前进杀敌还是进攻。坦克世界的进攻的要领就是以最小代价歼灭对方。该做的还是要做，微观的进攻和宏观的进攻都要做好。
新人欢迎积分1 阅读权限40积分422精华0UID帖子金钱3316 威望0
Lv.4, 积分 422, 距离下一级还需 578 积分
UID帖子威望0 多玩草0 草
太多了不看，反正觉得你说的不对，虽然在野队来看，蹲的胜率是很高，但是不代表进攻不会赢，野队进攻不怎赢的原因就是没配合，入过一个房间里有多人组队，而且都想打进攻，那效果肯定不一样，而且蹲是看图的，有的图你死蹲只会让对面一个一个点亮被集火打死。
&所以你现在效率胜率很低，还是认真看完帖子吧&
填不完的大坑
新人欢迎积分1 阅读权限50积分2259精华0UID帖子金钱6881 威望0
Lv.5, 积分 2259, 距离下一级还需 241 积分
UID帖子威望0 多玩草0 草
& && && && && && && && && && &我是无所谓&&一起蹲！
时间飞快！
新人欢迎积分1 阅读权限60积分2605精华0UID帖子金钱11687 威望0
Lv.6, 积分 2605, 距离下一级还需 2395 积分
UID帖子威望0 多玩草0 草
省省吧，大叔，上了年纪就别带坏小孩行不。我们都是年轻人，年轻人就需要刚性和激情。这只是个游戏，在游戏里你才能黑枪，那么在乎效率干什么。（历史上真正的坦克大战，都是冲锋绞杀在一线，一击毙敌）。最好的防守就是进攻，我说的不是那种无脑送，掩体都不会找的那种。你蹲的再深，把你揪出来灭掉，那感觉才爽。
：并不是所有人都和你一样超神。以大家的水平，打进攻效率高于蹲。&
：狗屁正道&
&你想死就死去，我教大家正道&
新人欢迎积分0 阅读权限50积分2349精华0UID帖子金钱8923 威望0
Lv.5, 积分 2349, 距离下一级还需 151 积分
UID帖子威望0 多玩草100 草
都是平等的，谁又想被当成九连呢，
那些年我们一起遇到的大（xiao）神(xue)啊(sheng)
新人欢迎积分1 阅读权限60积分2900精华0UID帖子金钱3496 威望-2
Lv.6, 积分 2900, 距离下一级还需 2100 积分
UID帖子威望-2 多玩草0 草
野队正确！所以我去玩飞机了。
组队不正确！所以我现在只打联队了。
新人欢迎积分1 阅读权限60积分2900精华0UID帖子金钱3496 威望-2
Lv.6, 积分 2900, 距离下一级还需 2100 积分
UID帖子威望-2 多玩草0 草
说明你还没玩透这游戏，野队和联队完全是二个不同的游戏。
本帖最后由 frankfan888 于
16:58 编辑
新人欢迎积分0 阅读权限70积分9170精华0UID4103802帖子金钱6727 威望1
Lv.7, 积分 9170, 距离下一级还需 830 积分
UID4103802帖子威望1 多玩草140 草
大神10级车组队可以保证胜率 同时大神一般输出会比另外两个队友高一些&&那么有了胜率也有了输出 去点亮也有队友能照应 不像野队眼车
“为领导服务”
新人欢迎积分1 阅读权限99积分48453精华0UID帖子金钱91401 威望0
火炮穿抹胸内裤可以出三级标识！
Lv.10, 积分 48453, 距离下一级还需 6547 积分
UID帖子威望0 多玩草340 草
lz& &hehe!!!!
新人欢迎积分1 阅读权限70积分5754精华0UID帖子金钱25492 威望0
Lv.7, 积分 5754, 距离下一级还需 4246 积分
UID帖子威望0 多玩草100 草
1进攻 局部或某条线可以有三倍人数优势
2蹲在家里掩体隐蔽有限 视野局限 在占领了地图四分之三以后 进攻方的交叉火力更好打
3防守方一样不齐心 更有因为人拥挤导致td蹭菊挡炮线
单挑伸缩 被利用延迟反而是防守的无利 参见短伸缩 不会的话当然是防守的抢先手
进攻和送是两回事 防守和蹲又是两回事。送有个人送有一波战略送，蹲有个人蹲有一波战略蹲。防守和进攻是灵活的 前线也可以防守，家里也可以进攻。
大神的蹲是找个好地方，＂保存血量＂，把队友＂卖个好价钱＂。只说蹲就是无脑 。人人都蹲大神还怎么打数据，都只能打一个人血量了那哪里还有1300效率的。
不是大神 不会蹲的 蹲不出价值的 就老老实实照打，尽量不开局送 有机会配合就不要错过，脑子不发热不要贪炮送命 胜率就高了，纯蹲会比送逼的48 49高，但是全局的蹲坑胜率有51也不错了。
如果此文是教你怎么从一个49胜率的送逼提升到51胜率的 那还是很有指导意义的。
：但是如果我组队进攻就可以到59.组队防守大概能53.&
：你牛逼的。我只有51因为我手残。以我的手残我蹲也最多52.&
&至少我蹲出59胜率，不知道你进攻出多少胜率&
牺牲，在所难免
新人欢迎积分1 阅读权限99积分40680精华0UID帖子金钱47593 威望1
Lv.10, 积分 40680, 距离下一级还需 14320 积分
UID帖子威望1 多玩草1834 草
楼主最主要的几点：想赢就蹲！高效率的都是黑枪黑出来的。呵呵，摆明了自己进攻无脑送，非说自己被卖。过几天黑枪只剩自己一个被对面轮了，有该骂蹲比了
吾之荣耀即忠诚
新人欢迎积分1 阅读权限70积分9327精华0UID帖子金钱79568 威望1
Lv.7, 积分 9327, 距离下一级还需 673 积分
UID帖子威望1 多玩草1404 草
发表自UC浏览器
楼主效率多少？
：敢问LZ，你有X车玩的多还是V车玩的多？？？？？&
：这么牛逼 暴ID让我等战五渣来瞻仰一下吧&
：出战等级？&
新人欢迎积分1 阅读权限50积分2172精华0UID帖子金钱8679 威望0
Lv.5, 积分 2172, 距离下一级还需 328 积分
UID帖子威望0 多玩草0 草
手机论坛勋章
APP发帖双倍积分，登陆即送勋章！
马年新春勋章
手机APP马年迎春，马上有钱！
365天！天天有你
连续签到1年即可获得
需要金钱：1100
手机盒子客户端点击或扫描下载
Powered by后使用快捷导航没有帐号？
查看: 836|回复: 14
新人欢迎积分1 阅读权限150积分8704精华0UID帖子金钱44420 威望17
发射后不管
UID帖子威望17 多玩草13013 草
1. 效率值；
我觉得吧这个东西还是基本客观的。
效率值是根据坦克世界里可以查询到的玩家数据计算而成的，并不存在侵犯隐私问题。你在同意空中网的用户协议的时候已经默认了你的战斗数据可以被查询，就是这样。丢人就不要想找地洞钻，要么就删号。
效率值是一个抽象概念的具体化，将玩家的水平量化考量。这是在统计学上是有意义的。
关于效率值吐槽最多的就是
我效率低但是我不坑
首先先不驳斥这一说法，毕竟的确有可能：
一、偶尔一两场跟上了节奏，不坑了
二、肉侦挂机的老司机故意拖低效率降低仇恨
那么新版效率大概就很好解决这样的争议了。千场和百场数据让挂机狗有机会洗白，或者说让潜伏的老司机无所遁形（400效率打还拿拉德利，说你是新手谁信啊）。该坑还是坑，一目了然。
其实也就是样本大小的问题。全体场次的效率反应的太笼统，并不精确，而30场甚至150场的效率样本容量又太小，误差很大。1000场甚至1500场，可能会是相对精确的区间，毕竟1000场，水平应该也有所提升了。
比如我1000场效率1000+，旧版效率900+，某一天我特别特别背，开啥啥飞头，打谁谁不穿，那么我30场效率值肯定特别低，胜率肯定也很低，但是30场相对于1000场而言又是很小的一部分，1000场效率并不会受到太多影响。我ELC打了3场，然后挂机挂到查查，那我旧版效率肯定很低很低，但是如果我憋出了查查之后我认真打，那么还是能看出来的。
效率值真的没什么好喷的，他们几个苦逼码农已经做的很好了，我做调查统计的我就明白整这些有多枯燥多辛苦。众口难调，又对牛弹琴。
不能理解都好，体谅一下吧。
2. 控制胜率
某个帖子已经说明了Wargaming申请了调整玩家胜率的算法专利，我也不多赘述了。要看的自己在论坛里搜关键字“专利”即可。
有就是有，没有问题。但是，并没有你想象的那么夸张，而且，这个东西并不像你想象的那么坏。
不要一口一个控制胜率，先看看你胜率是不是高到需要控制再说。
我不要脸，大家可以搜我，没关系。以我为例，我重坦玩得相当菜，57，215b，-4几个胜率都是51 52 53上下的样子，我真的不敢说我开这些车会被控制胜率，因为我打的真的就是很一般，我承认。我天蝎胜率60，之前还高达66，地狱猫59，A43胜率60，这种，才是丢黑名单池子里等待平衡的候选人。
况且，平衡的手段也不是将你跟谁安排在一起，而是调整你玩的车的分房而已。
效果就是，我开-6，连赢胜率逼近55临界值，服务器开始慢慢多讲我放进9级房让我打不穿人。我开KV1各种连跪，服务器为了保护我（手动滑稽），把我分到5级房当班长（然而仍然是要被T67突突突突突）。
胜率低于50的，偷着乐吧，这个算法是保护你们的游戏乐趣的。你们对于这个游戏的运营商很重要，他们想要照顾你们，帮助你们熬过新手期，同时又避免对老玩家太刻薄。
将心比心，真的很难做的。这个游戏学问太多，对新手不友好，这是不争的事实，控制胜率对维持这个用户生态而言是良性的东西。高水平玩家互殴发生在要塞和领土战就够了，这个游戏仍然需要玩家保持多样化、需要新鲜血液涌入。不然你以为2雷频频给药费降价是为什么？
说的以后不出分房保护的金币车最关键的原因就是不利于用调整分房等级来调整胜率。当初出于游戏平衡考虑，金币车的性能相对于银币车都要更弱，有分房保护的则更甚，但是这就造成了恶性循环。一部分胜率过高的金币车玩家，无法被现有的算法有效调整胜率。
说白了，重点就是在于保护低胜率的玩家，而不是打压高胜率玩家。
然而不管我怎么做，我山猫的胜率还是过不了50。谜之诅咒。
点灯是不可能点灯的 这辈子不可能点灯的
黑枪又不会 就是靠肉侦 才能维持的了生活这样子
进了论坛感觉像回家一样&&在论坛里的感觉比游戏里感觉好多了&&里面个个都是人才 说话又好听 我超喜欢里面的
新人欢迎积分1 阅读权限150积分8704精华0UID帖子金钱44420 威望17
发射后不管
UID帖子威望17 多玩草13013 草
＠峫魔↓天使Ψ&&＠魏先森_BL ＠皇昂流 ＠呢喃的细雨&&&&＠虚幽末 ＠刪除於終點&&& && &&&
本帖最后由 没事挊一炮挺好 于
10:32 编辑
：第一次在论坛被人召唤哎&
&召唤术不及格..&
点灯是不可能点灯的 这辈子不可能点灯的
黑枪又不会 就是靠肉侦 才能维持的了生活这样子
进了论坛感觉像回家一样&&在论坛里的感觉比游戏里感觉好多了&&里面个个都是人才 说话又好听 我超喜欢里面的
新人欢迎积分0 阅读权限50积分1396精华0UID帖子金钱2058 威望0
Lv.5, 积分 1396, 距离下一级还需 1104 积分
UID帖子威望0 多玩草0 草
没有认真研究过是否存在胜率控制，但你提到的控制应该不会起效果，比如天蝎60%胜率扔到9级10级房，受影响的是输出不是胜率，因为胜率受10级9级车影响的概率更高，同样，KV1连跪十几次，扔个班长给你也不能保证不继续连跪。
不灵不要钱
新人欢迎积分1 阅读权限80积分15619精华0UID帖子金钱37207 威望4
给钱也不灵
Lv.8, 积分 15619, 距离下一级还需 4381 积分
UID帖子威望4 多玩草1289 草
控制胜率无线接近50%.
新人欢迎积分1 阅读权限150积分8704精华0UID帖子金钱44420 威望17
发射后不管
UID帖子威望17 多玩草13013 草
Nirvana0321 发表于
没有认真研究过是否存在胜率控制，但你提到的控制应该不会起效果，比如天蝎60%胜率扔到9级10级房，受影响的 ...
你这段话有毛病啊，或者是你我的话误导了你。
恰恰就是因为胜率受高级车影响更大，小车翻盘几率小，所以通过调整分房等级来实现控制胜率才有意义。
对我而言，我并不是特别惧怕10级房，8级房反而没肉吃。
&另外，10级车的胜率怎么控制？这种方式肯定不行吧…还有就是逆向控制的问题，你KV1连跪十几局，让你做班长，你玩的溜赢面大了，我是个坑，我跪的更多了…手机码字累死了，搬砖去了… &
&当然了，如果非要说这种控制不会过于影响游戏体验（相对于通过车型或个人等级来控制），你天蝎玩的太溜，8级房赢面太大，扔9级10级去，把胜率交给别人来决定，随机大样本条件下，被控制的局数整体胜率接近50%，同时 &
&问题是，你天蝎60%受控制了，扔到10级房，这一局的胜利与否，更多是受你的10级9级队友以及对方的10级9级车影响，所以通过这种方式控制，本身逻辑就有问题，这是很明显的。 &
点灯是不可能点灯的 这辈子不可能点灯的
黑枪又不会 就是靠肉侦 才能维持的了生活这样子
进了论坛感觉像回家一样&&在论坛里的感觉比游戏里感觉好多了&&里面个个都是人才 说话又好听 我超喜欢里面的
新人欢迎积分1 阅读权限60积分3136精华0UID帖子金钱29466 威望0
Lv.6, 积分 3136, 距离下一级还需 1864 积分
UID帖子威望0 多玩草200 草
没事挊一炮挺好 发表于
1. 效率值；&&我觉得吧这个东西还是基本客观的。 效率值是根据坦克世界里可以查询到的玩家数据计算而成的， ...
说的有点道理。。。的确分房存在这种高低房现象。。。
轻坦不侦查，如鹰蒙其眼；中坦不支援，如狼断其腿；重坦不抗线，如熊去其骨；TD不移位，如虎拔其牙；火炮不予瞄，如蝎折其尾。
新人欢迎积分1 阅读权限40积分702精华0UID帖子金钱5407 威望0
Lv.4, 积分 702, 距离下一级还需 298 积分
UID帖子威望0 多玩草80 草
楼主说的不错，但是这是15个人的游戏，确实不是服务器在控制胜率，而是14个队友控制了你。
低效无人权
新人欢迎积分0 阅读权限70积分6315精华0UID帖子金钱11778 威望0
【深藏不露】【一黑到底】
Lv.7, 积分 6315, 距离下一级还需 3685 积分
UID帖子威望0 多玩草320 草
我E25玩了5000场，前面2000场70%去了7级房；后面的3000+场80%去了8级房~然后很多人喷我用有分房保护的E25屠幼刷效率了~哇~我真心建议大家也用这个有分房保护的车扛个6级小水管炮去8级房单野几千场屠杀对面的王总 -3 解放军涨涨效率~
——————————————————————————————————————█三级战绩标识档案█25X█
8█JPZ4-5█
7█E25█猎豹█SU-122-44█斯太尔█AT15A█
6█SU-100█大麦克斯█犀牛█IV号坦克歼击车█Ikv65AII█—█VK3001(D)█—█T37█
5█V-IV号█IV坦克H型█T-34█M7█
5█III号突击炮G型█IV号突击炮█SU-85█S35CA█T67█
5█霞飞█AMX ELC█十字军█
新人欢迎积分1 阅读权限40积分830精华0UID帖子金钱4631 威望0
Lv.4, 积分 830, 距离下一级还需 170 积分
UID帖子威望0 多玩草30 草
为了水晶燕，已经没节操了
新人欢迎积分1 阅读权限50积分1388精华0UID帖子金钱3734 威望0
Lv.5, 积分 1388, 距离下一级还需 1112 积分
UID帖子威望0 多玩草0 草
这还真是控制胜率的方法。跟什么控制散布，控制队友战斗力，控制击穿力等等说法相比，这个是确实存在的。
所以，服控在这里，其他的服控真算了。
新人欢迎积分1 阅读权限99积分42011精华0UID1524072帖子金钱122820 威望1
Lv.10, 积分 42011, 距离下一级还需 12989 积分
UID1524072帖子威望1 多玩草735 草
又是拿所谓专利说事儿的，麻烦看个全文，别放着段首的according to another aspect当没看见
Dynamic battle session matchmaking in a multiplayer game
Methods and systems for performing smart matchmaking in a massive multiplayer online game are described herein. A video game such as a vehicle-based combat game may include multiple types of vehicles, where each type of vehicle may progress through increasing tier levels. Different types of vehicles within the same tier may have different capabilities, strengths, and weaknesses. When performing matchmaking for a game session, a matchmaking server may use a battle level table defining permissible tiers of each type of vehicle allowed within a particular battle level, and may also limit the number of a specific type of vehicle allowed in any one game session. The battle table may provide an advantage to premium vehicles by limiting the tiers of other vehicles against which a similarly tiered premium vehicle may compete. Battle level difficulty may be adjusted by adjusting the ranges of permissible vehicles in each battle level.
Aspects of the disclosure relate to computer systems, computer software, and video games. More particularly, aspects of the disclosure relate to video game software, administering massive multiplayer online games, matching players in multiplayer online games based on player experience level, character experience level, and/or vehicle experience levels, and playing video games.
BACKGROUND
Video games are increasingly popular. Online multiplayer video games have become particularly popular due, at least in part, to the ability of players to compete with multiple other human players.
Popular genres of multiplayer games include the first-person-shooter (FPS) and the third-person shooter genres. In FPS games, the player's on-screen view simulates the view of the character or vehicle cont that is, the first-person view. The object of many FPS games is to accomplish a goal within a game. Common goals include killing other game characters that represent other players, capturing flags that represent opponents' territory, assaulting another team's base, and the like. Third person shooter games often have similar goals but differ in the perspective of the player. In third person shooters, the player views the game world from above or behind the character or vehicle controlled by the player.
Because online multiplayer games have become increasingly common, there is substantial competition between the offered games regarding obtaining and retaining consumers. Repetitive play can often lead to players becoming bored with a particular game. In addition, if a player finds a game too hard or too easy, the player may become frustrated or bored, and cease playing prematurely.
The following presents a simplified summary of various aspects described herein. This summary is not an extensive overview, and is not intended to identify key or critical elements or to delineate the scope of the claims. The following summary merely presents some concepts in a simplified form as an introductory prelude to the more detailed description provided below.
To overcome limitations in the prior art described above, and to overcome other limitations that will be apparent upon reading and understanding the present specification, the present invention is directed to methods and systems for performing matchmaking in a multiplayer online video game. According to an aspect, matchmaking may be performed by receiving at a matchmaking server a battle session request from each of a plurality of client devices, where each battle session request identifies a vehicle to be used in the game. Each vehicle has a vehicle type and vehicle tier. The game may include a plurality of different vehicle types, and a plurality of different hierarchical vehicle tiers. Matchmaking may further include assigning each vehicle to a battle session based on a battle level table defining a permissible range of battle levels for each vehicle based on vehicle type and vehicle tier, and then initiating the battle session with each of the assigned vehicles.
The method may be performed based on instructions stored on a statutory computer readable medium, or executed by a matchmaking server configured to perform as described herein.
According to various aspects, a first vehicle type of a first tier may be associated with a first range of battle levels, and a second vehicle type of the first tier may be associated with a second range of battle levels different from the first range of battle levels.
According to other aspects, each vehicle may be one of a standard vehicle and a premium vehicle, where a first premium vehicle is associated with a lower range of battle levels than a first standard vehicle of a same tier and/or type as the first premium vehicle.
In some aspects, assigning may include calculating the permissible range of battle levels as a function of a number of battle sessions previously played using the vehicle. In one specific aspect, the calculating may be performed by determining a current maximum permissible battle level C based on the following: For B&N: C=L+(B-1)((M-L-1)/N); For B≧N: C=M, where L represents a lowest battle level defined the battle level table for the vehicle type and vehicle tier of the vehicle, M represents the maximum battle level defined the battle level table for the vehicle type and vehicle tier of the vehicle, B represents the number of battles previously played using the vehicle, rounding to a nearest integer value.
These and other aspects will be apparent upon reading the detailed description below.
BRIEF DESCRIPTION OF THE DRAWINGS
A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description in consideration of the accompanying drawings, in which like reference numbers indicate like features, and wherein:
FIG. 1 is an illustrative network environment in which one or more aspects described herein may be used.
FIG. 2 is a block diagram illustrating an example virtual world client according to one or more aspects described herein.
FIG. 3 is a block diagram illustrating an example virtual world server according to one or more aspects described herein.
FIG. 4 illustrates a block architecture diagram of software modules that may be used to implement various features described herein.
FIG. 5A illustrates an instance of a character object according to various features described herein.
FIG. 5B illustrates an instance of a vehicle object according to various features described herein.
FIG. 6A illustrates a screenshot of a video game implementing one or more illustrative aspects described herein.
FIG. 6B illustrates a screenshot of a video game implementing one or more illustrative aspects described herein.
FIG. 7 illustrates a screenshot of a video game implementing one or more illustrative aspects described herein.
FIG. 8 illustrates battle level table according to an illustrative embodiment described herein.
FIG. 9 illustrates a flowchart for a method of performing smart matchmaking according to an illustrative embodiment described herein.
DETAILED DESCRIPTION
In the following description of the various aspects, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration how various features described herein may be practiced. It is understood that other embodiments may be used and structural and functional modifications may be made.
FIG. 1 illustrates a network environment in which clients 101 may interact with virtual world servers 105 to provide a virtual world for users to access. Clients101 may include a variety of devices including generic data processing device101 a, personal computer (PC) 101 b, laptop, portable, or netbook computer 101c, personal data assistant, mobile phone or device 101 d, a tablet device (not shown) and the like. Each of clients 101 may have a network adapter that allows clients 101 to connect to virtual world servers 105 through network 100. In one example, network 100 may include an Internet Protocol (IP) based network, e.g., the Internet. Other networks may include cellular networks, cable networks, fiber optic networks, wireless networks, wired network and/or combinations thereof. Network 100 may further include one or more sub-networks such as wired or wireless local area networks (LANs), wide area networks (WANs), and the like.
In one or more arrangements, virtual world servers 105 may be included in a virtual world server system 103 that includes multiple linked physical and/or logical servers 105. Using such a distributed system, servers 105 may be able to distribute load across each of server 105. For example, if server 105 a is experienced high loads, some of the operations may be passed to either server105 b or 105 c or both. Load may further be distributed based on user geography or on other predetermined bases. Alternatively, the virtual world may be hosted on a single server, e.g., virtual world server 105 a. Each of servers 105 may collectively generate and manage a single instance of the virtual world, or each server 105 a, 105 b and 105 c may provide independent instances of the world. An instance of a virtual world, as used herein, describes a stand-alone instance of the virtual world that does not interact with or depend on other instances of the virtual world. Depending on the processing load, a virtual world server system103 may divide a plurality of users among multiple instances of the virtual world, to reduce or alleviate overloading on a single server or prevent overpopulation. Each server 105 may be logical or physical, e.g., multiple logical servers may reside and be running on the same physical computing device/server, or servers may be physically separate devices.
The network environment of FIG. 1 may also associate with one or more matchmaking servers 106. As used herein, a matchmaking server 106 may determine what set of players to assign to a same instance of the virtual world to ensure that all players meet predefined criteria for that instance of the virtual world. That is, if extremely experienced players are paired with complete novices, the experienced players may quickly become bored, while the novice players may quickly become frustrated, causing each of them to stop playing the game altogether. Thus, the matchmaking server(s) 106 determine how to assign players to an instance of a virtual world so that every player is challenged, without getting frustrated. Specific algorithms and techniques used for matchmaking are described in more detail below.
FIG. 2 illustrates an example client device 200 such as PC 101 b (FIG. 1) that may be used to access and interact with a virtual world provided by a virtual world server such as server 105 a of FIG. 1. Client device 200 may include a variety of components and modules including a processor 217, random access memory (RAM) 215, read only memory (ROM) 213, databases 201 and 203, client software 205, output adapter 211, input interface 209 and communication interface 207. Software, databases, operating systems, and the like may be stored in nonvolatile memory 206 (e.g., a magnetic disk or solid state hard drive, or equivalent). Object database 201 may be configured to store data defining and otherwise associated with an object used by a user of device 200 to explore and interact with the virtual world. World database 203, on the other hand, may be configured to store data for defining and generating the environment in which the objects exist. For example, world database 203 may store texture maps for rendering a floor or ground, walls, a sky and the like. In another example, world database 203 may store simulated environments, buildings, trees and other data defining animate or inanimate objects existing in the world, data defining computer controlled characters and the like. Each of database 201, 203 may or may not be a conventional database, and instead may refer to data stored in a memory, accessed as needed by the client software. Data associated with an object or the virtual world may be communicated between client device 200 and a virtual world server using communication interface 207. For example, object positions, attributes and status may be updated or environments may be changed by communicating such data through interface 207.
The world and the objects may be graphically rendered by client software 205and subsequently sent to output adapter 211 and display 219. The client software205 may, in one or more arrangements, be configured to generated three dimensional (3-D) models of the virtual world and components thereof as well as the object corresponding to a user. A user may control the object and interact with the world through input interface 209 using various types of input devices including keyboard 223 and mouse 225. Other types of input devices may include a microphone (e.g., for voice communications over the network), joysticks, motion sensing devices and/or combinations thereof. In one or more arrangements, music or other audio such as speech may be included as part of the virtual world. In such instances, the audio may be outputted through speaker221.
Client software 205, computer executable instructions, and other data used by processor 217 and other components of client device 200 may be stored RAM215, ROM 213, nonvolatile memory 206 or a combination thereof. Other types of memory may also be used, including both volatile and nonvolatile memory. Software 205 may provide instructions to processor 217 such that when the instructions are executed, processor 217, client device 200 and/or other components thereof are caused to perform functions and methods described herein. In one example, instructions for generating a user interface for interfacing with the virtual world server may be stored in RAM 215, ROM 213 and/or nonvolatile memory 206. Client software 205 may include both applications and operating system software, and may include code segments, instructions, applets, pre-compiled code, compiled code, computer programs, program modules, engines, program logic, and combinations thereof. Computer executable instructions and data may further be stored on some physical form of computer readable storage media (referred to herein as “computer memory”) including, e.g., electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, DVD or other optical disk storage, magnetic cassettes, magnetic tape, magnetic storage and the like.
Referring now to FIG. 3, a virtual world server 300 (e.g., an instance of server 105) may be configured to generate and operate a massive multiplayer online game, such as virtual world or the like. Server 300 may include processor 301, ROM303, RAM 305, communication interface 307, object position database 309, world database 311, user database 313, server software 317, and a statistics database 312. Object position database 309 may be configured to store position information for each object (e.g., based on commands to move a vehicle received from each client). The statistics database 312 may be configured to store and/or transfer statistics relevant to game operation, including, for example, tracking player achievement and general game server performance.
A world database 311 may store rules, algorithms and other data for interactions that are available in the world. For example, a manner in which a computer controller character moves or otherwise behaves may be defined in data stored in world database 311. Additionally, item information may be defined in world database 311 so that items may not be modified by each client. In another example, world database 311 may store location information for non-object items and components. User database 313, on the other hand, may be configured to store information describing a user controlling an object. For example, user database 313 may include account information, user preferences, one or more classes of user experience points and/or levels, payment information, user identification information, character definitions, state tables, and the like. Each of databases 309, 311, 312, 313 may or may not be a conventional database, and instead may refer to data stored in a memory, accessed as needed by the server software. For example, user database 313 may in fact be a collection of multiple databases or database tables.
Features described herein may be used with or in a variety of video games, including but not limited to, WORLD OF TANKS by Wargaming.net. Aspects described herein may also be used with other video games and are not limited to any one genre or implementation. Aspects described herein may be implemented in video game application software stored on a computer readable medium, e.g., storage 201, 203, 205, 206, 213, 215, 309, 311 312, and/or 313, and executable by a data processing device.
Various aspects of the disclosure provide features and capabilities that enhance game play by providing options through which users can develop strategies to play the video game. According to various aspects described herein, a video game may provide a graphically stimulated virtual world or virtual environment, in which the game takes place, referred to herein interchangeably as a virtual world and as a simulated environment of the video game. The simulated environment may have features similar to actual geographic locations or may have fictional, science fiction or fantasy-themed environments.
According to various aspects, the game may involve multi-player combat-based tournaments combined with an experience-based reward system. As users accomplish predefined tasks or achievements within the game, the player may be given one or more types of reward points or experience points. Reward points may subsequently be exchanged for in-game items, goods, features, etc., or otherwise used in accordance with one or more aspects described herein. In one example, reward points may be used to initiate or perform “research” to unlock more powerful, stronger, or otherwise more desirable elements within the game. The discussion below indicates various features and items that may be researched and used, as a player develops a character or vehicle within the game. As players research and purchase more advanced technologies, those players advance in skill and ability, which also affects how those players should be matched against other players in the game by matchmaking server 106.
FIG. 4 illustrates a block diagram of a video game software application 401. Each block in FIG. 4 illustrates a logical software module or function that performs an action, provides a capability or feature, implements an object, or performs some other aspect of the video game. When the video game software 401 executes on a data processing system such as a PC or game console, the modules operate collectively to provide a video game experience to a player. The modules illustrated in FIG. 4 are illustrative only, and additional or different modules may be used. The same, additional or different modules may be executed in tandem on a server with which each client device is connected.
Video game software 401 may include, e.g., a game manager module 402, which manages the overall operation of the video game and may be the initial module launched when the video game is executed. Video game software 401 may also include a network module 403, which manages network games sessions and communication with one or more game servers. A network game session may include e.g., a co-operative campaign with other networked players, or other compartmentalized periods of game play involving players located at discrete network locations. A memory manager module 409 performs memory management during execution of the video game 401. An input module 404 may receive and interpret user input via a game controller, keyboard, mouse, and the like, and provide the interpreted commands to game manager 402, network module 403, or other applicable module. UI module 405 may manage and control the user interface, including the display displayed on the video output device, interpreting input via the input module 404, and providing audio output via audio module 408.
Various software modules may operate with one or more classes or objects defined and used in the video game 401. The classes and objects may be defined with reference to an object module 410, and may include portions of executable software code and/or one or more data structures, depending on the object. Each object may be rendered and simulated in the virtual world in accordance with a physics engine 407. Video game software 401 may include other software modules411 as needed. FIG. 4 illustrates one possible software architecture. Others may be used. Each module depicted in FIG. 4may communicate directly or indirectly with each other module, e.g., by passing objects, data, parameters, input, and output, etc.
A first class of in-game objects may define characters in the video game. Characters may be defined by various attributes associated with the character, e.g., name, physical appearance, skills, etc. Skills may be defined based on a character's genre or task, e.g., gunners, tank commanders, and drivers in the present example. A gunner may have skills such as aiming accuracy and aiming speed, a tank commander may have skills that regulate the overall efficiency of the tank crew, a driver may have skills that determine the vehicle speed or precision of direction. Additional character attributes may include one or more other skills that can improve performance of the character or vehicle so as to enhance the strategic gaming experience such as firefighting skills, the ability to repair vehicles, the ability to camouflage vehicles, and the like.
A second class of in-game objects may define vehicles in the video game. A vehicle may be defined as any simulated inanimate object directly or indirectly controllable by or dependent on an in-game character or user/player. Illustrative vehicles may include tanks, airplanes, ships (and/or submarines), and the like. Vehicles may have various attributes and functions that provide advantageous qualities to the vehicle during combat. For example, some vehicles might be fast with minimal firepower, whereas other vehicles may be slower but extremely powerful. Infinite variations of strength, speed, defense, and any other attribute are possible.
Object module 410 may provide an array of vehicles, vehicle components, characters and other equipment. Vehicles, vehicle components, characters and other equipment may be defined by one or more objects and instantiated during the game. Each object may have various attributes and functions and provide advantages and disadvantages based thereon. A vehicle component may refer to an upgradeable component of a vehicle, e.g., armor plating, engine, guns, etc.
FIG. 5A illustrates a block diagram of an instance 501 of a character object. Object instance 501 has an object class 505(Character). Instance 501 may acquire one or more attributes from the object class. Attributes 507, when examined, define a state of the instance. In this example, the Character has the following attributes: Name 511, Qualification 512, Training Level 513, and Competence 514. A character may also have additional skill types 509. Additional skill types may include Repair Skills 515, Firefighting skills 516, and Camouflage skills 517. Other skill types, attributes, etc., may also or alternatively be used.
Each attribute may have a particular value. The attribute may have a default value inherited from the Qualification type 512. For some attributes, a player may increase attribute value by allocating experience points, gained during gameplay, to the character. Increased attribute value enhances gameplay by improving performance of the vehicle containing the characters. For example, by allocating experience points to the gunner of a tank, the Training Level 513 may be increased resulting in more accurate gun pointing by a vehicle containing that character, leading to improved vehicle performance during battle. Similarly, the effectiveness of the additional skill types is increased in accordance with the value of the skill. Thus, for example, a Firefighting skill 516 value of 100% is proportionally more effective than a value of 50%. Increased firefighting effectiveness results in reduced damage to the vehicle in the event of a fire. By staffing a vehicle with characters having improved attributes and skills, vehicle performance is maximized allowing for a more effective performance during game play.
In some embodiments, attributes might not be able to be changed. Qualification 512 for example, a driver may not be retrained as a gunner. A character's Competence attribute 514 refers to their ability to operate a s for example a specific type of tank such as the M3 Stuart tank. Competence 514 may be changed by retraining the character to operate the same Qualification 512 on a different vehicle. Changing Competence 514 may result in a decreased Training Level 513 in the new vehicle. Additional experience points may be used to raise the Training Level 513 in the new vehicle. A character may eventually be associated with multiple competence attributes—one per vehicle the character has been associated with.
FIG. 5B illustrates a block diagram of an instance 551 of a vehicle object. Object instance 551 has an object class 555(Vehicle). Instance 551 may acquire one or more attributes 557 from the object class. Attributes 557, when examined, define a state of the instance. In this example, object instance 551 is a Liechttraktor Tank and has attributes associated with tank properties. Exemplary attributes include Name 561, Hit Points 563, Weight/Load limit 564, Engine Power (h.p.) 565, Speed Limit 566, Hull Armor 567, Turret Armor 568, Standard Shell Damage 569, Standard Shell Penetration 570, Rate of Fire 571, Turret Traverse Speed 572, View Range 573, and Signal Range 574. These attribute contribute to the vehicle's effectiveness in combat. Attribute types may also have an attribute value, which determines the effectiveness of the attribute function. For example, the Speed Limit attribute 566 has a value of 46 km/h, which indicates how fast the vehicle can travel. One or more of the attributes, alone or in combination, may be used to assign the vehicle to a subclass. In this example, vehicle 551 may be in a subclass of tanks referred to as “Light Tanks” based on hit points, speed, armor, etc. Other classes of tanks may include medium tanks and heavy tanks, among others. Subclass may be used to quickly identify to a user a general approximation of attributes associated with a vehicle without requiring the user to review each attribute in detail.
Aspects of the disclosure involve altering object attributes in response to experience obtained within the game. Altering attributes provides for enhancing the skills of the character and enhancing properties of vehicle and vehicle components. Altered attributes provides the game player with vehicle and characters able to compete more effectively against other players.
Using Modules to Upgrade Vehicle Attributes
Vehicle attributes may be altered by adding or upgrading modules associated with a vehicle. A vehicle contains modules classes 559. Each module class may contain one of a variety of module types appropriate to the module class. In one example, module classes may include Gun 575, Turret 576, Engine 577, Suspension 578, and Radio 579. Additional 580modules may be added to provide additional functions or otherwise modify vehicle attributes 557. Within each class, a vehicle may be outfitted with one module type that falls within the class. For example, five increasingly powerful gun types may be available within the gun class. Similarly, there may be multiple radio types within the radio class. Adding or changing a module type alters vehicle attributes 557 based on the effectiveness of the newly installed module type. Thus, for example, if the Radio module 579 type SCR 209 is replaced by a more advanced module the Signal Range 574 attribute value may increase based on a signal range value associated with the more advanced module. An increased Signal Range value, in turn, may allow the vehicle to detect enemies at greater distances during game play, making the player more competitive against opponents and resulting in an enhanced gameplay experience for that player.
Experience Points and Research
During game play (e.g., between game sessions), new vehicles and new modules for vehicles may be unlocked by a player in exchange for experience points. In some embodiments, a user might gain points for a single experience class. In other embodiments, points may be earned for two or more different experience classes. Different experience classes may be used to gain access to different features in the game. For example, points earned in a first experience class may be used to allow a user access to a first set of game objects (e.g. vehicles and/or vehicle modules) but not a second, different set of game objects. Points earned in the second experience class may be used to allow a user access to a different set of game objects than the first experience class. The first and second sets may share some objects in common, or may instead be completely distinct.
In one example, where the first experience class is battle experience, battle experience may be used to unlock any object in the same tech tree as the vehicle in which the battle experience was earned, but may not be used to unlock objects not in the same tech tree as the vehicle in which the experience was earned. In this example, where the second experience is free experience, the free experience may be used to unlock any object in any tech tree, regardless of the vehicle in which the free experience was earned.
Collectively, the experience classes may be referred to herein as the “Primary Currency” of the game. Primary Currency is the main route for players to acquire upgraded vehicles, modules, and personnel. A second type of currency, defined herein as “Alternative Currency” may be provided to a player in exchange for alternative compensation, e.g., by completing secondary in-game tasks, completing objectives, or in exchange for the payment of money. In some embodiments, the software may allow some or all of a first experience class to be converted into one or more of the different experience classes. In some aspects, such conversion may only be permitted when a predetermined condition is met. Various predetermined conditions may be imposed. For example, the software may prevent conversion until a vehicle has been upgraded to a particular status. For example, all objects in the same tech tree as a vehicle might be required to be unlocked before conversion from the first experience class to the second experience class is permitted. Such a vehicle is said to be an “elite” vehicle or having acquired elite status. A cost may be imposed on the user for conversion (e.g., Alternative Currency).
In other aspects, players may have the option to convert Battle experience to Free experience under different conditions. For example, “Premium” vehicles may be available to a player in exchange for Alternative Currency. A Premium vehicle may refer to a vehicle similar to an elite vehicle in that the vehicle includes all possible module upgrades and vehicles within the same tech tree family, however, the Premium vehicle may be purchased for the alternative currency whereas the elite vehicle was unlocked using one or more classes of experience through gameplay. Players who purchase Premium vehicles may be permitted to convert Battle experience to Free experience without first achieving any predetermined condition in the Premium Vehicle. In other aspects, predetermined conditions imposed on Premium vehicles might be different from those imposed on non-Premium vehicles.
FIG. 6A shows a screenshot of an example tech tree (also known as a game progress tech tree) for a Medium Tank object KV-13. All modules and available tanks (e.g. T-43) present in the tech tree have been unlocked and are available for player use. FIG. 6B shows a screenshot of a tank tech tree that may be researched for a T1 Cunningham tank object. FIG. 7 is an example of a main screen of an illustrative game.
Dynamic Matchmaking
Based on the ability of players to increase the attributes of their respective characters and/or objects (in this example, tanks), players will each have different capabilities to use in game sessions. Some players may have more advanced tanks than others, resulting in a weak tank being targeted by a very strong and powerful tank, while other plays may have more advances characters than others, resulting in perhaps more accuracy or speed in a particular tank than another player using the same tank with less experienced characters acting as the crew for that tank. Based on the near infinite combination of character attributes as used with various types and strengths of vehicles, it becomes difficult to match players for a gaming session so that each player is challenged without becoming bored or frustrated.
According to an aspect, there may be five primary types of tank vehicles: Self Propelled Guns (SPG, or artillery), Light Tanks, Medium Tanks, Heavy Tanks, and Tank Destroyers. Each vehicle may also be assigned a tier rating. The higher the tier, the more powerful the vehicle is considered to be. Vehicles of tier 1 may be entry level or novice vehicles, whereas vehicles of tier 10 (or higher) may represent well armored vehicles, very fast vehicles, vehicles with powerful ammunition, etc. If a player using a tier 1 vehicle were to compete against a player using a tier 10 vehicle, the player using the tier 1 vehicle has virtually no chance of winning the game session. However, a player using a tier 4 or above vehicle may be able to compete against some tier 10 vehicles. Thus, it is important to match players against other players using characters and/or vehicles of comparable quality, while still providing a challenging game experience without being overly difficult. This is a very fine line to walk.
FIG. 8 illustrates a matchmaking table 801 that may be used according to one or more illustrative aspects described herein. A game session may be referred to as a battle session. A game session/battle session refers to any discrete round of a game, e.g., a round of eliminate all enemies, capture the flag, hold the ball, and/or any other multiplayer variant of a game. In the WORLD OF TANKS brand of multiplayer game, a game session/battle session refers to two teams of 15 tanks fighting until 1) only one team has any tanks remaining, or 2) one team captures the other team's base.
Each battle session is assigned a battle level. Each battle level is used to limit participating vehicles to predefined tiers that are included in that battle session, thereby providing a unique method of creating a balanced battle session in an MMO game. As players progress and advance in experience, the player (or vehicle) will gradually be moved into higher battle levels based on the experience, attributes, and capabilities of each player's characters and/or vehicles.
Use of battle levels is based on the premise of gradual advancement through the tech tree starting with a first tier vehicle and unlocking more powerful vehicles by means of gaining battle experience or purchasing a premium vehicle. The game engine (e.g., as performed by matchmaking server) uses battle levels to manage the difficulty of each battle session. According to one aspect, the level of difficulty of a battle level is not identified or revealed in the game, and players might not be offered any option to choose a difficulty level within a battle session. However, as a matter of practice, players will typically want to obtain further upgrades by being constantly challenged, while not overloaded, in sequential game sessions.
Referring again to FIG. 8, there may be five (5) classes of vehicles in the game: Light Tank, Medium Tank, Heavy Tank, SPG and Tank Destroyer. Each class of vehicle possesses specific characteristics and a tier number. Generally, the higher the tier number is the more powerful the vehicles. Premium vehicles additionally have one or more of their own advantages. Each vehicle may be assigned a range of accessible battle levels. Vehicles of the same tier belonging to different classes may differ in their accessible battle levels ranges (e.g., Tier 4: Light vehicle has an access range to battle levels from 4 to 10; Medium—from 4 to 8; Heavy—from 4 to 5; SPG—from 6 to 10; Tank Destroyers—from 5 to 8; Premium USSR vehicle Valentine—from 4 to 5). When forming a line-up for a battle session of a certain level, appropriate vehicles with matching accessible battle levels are chosen.
The battle of a specified level (e.g., a level 6 battle session) may combine only those players whose vehicles permit access to this battle level within their range (Tier 3: all classes, Tier 4: Light, Medium, SPG and Tank Destroyers, Tier 5: Medium, Heavy, Tank Destroyers, and specified premium vehicles).
In addition to providing balanced battle sessions, the use of tier-limited battle levels provides the ability to control difficulty levels of the battle so that players of all skill levels remain challenged and wanting to play more. Players with higher tier vehicles have no access to lower battle levels, likewise lower tier vehicles are not allowed into higher battle levels. However, with one and the same vehicle players can happen to get into battle sessions of different levels within their accessibility range. By putting players into battles of varying level, the players experience a variety of game play while experiencing both wins and losses. According to one aspect, a player may be placed randomly or sequentially in any suitable battle level. However, according to another aspect, players who have just acquired a new higher tier vehicle are encouraged by being placed into battle sessions near the lower boundary of that vehicle's accessibility range, which allows the player feel more comfortable in the game. With time, the balancing system starts putting them into higher levels battle sessions, which creates a challenge of playing with more upgraded opponent vehicles. Details regarding how this aspect is performed are provided below, based on the use of the variable Nin table 801.
Premium vehicles typically have advanced capabilities compared to other vehicles of similar tiers, and may be allowed only into a lower range of battle levels than standard vehicles of a similar tier level, thereby encouraging users to obtain premium vehicles. For example, in one embedment, Tier 8 standard Heavy vehicles are allowed in battle levels from 9 to 12, while Tier 8 Heavy premium vehicles get into levels 9-10 and 9-11, thereby avoiding battle level 12. As a result, players are more likely to feel superior, and have a better chance of success in game using premium vehicles because they will never play against as difficult opponents as standard vehicles may face.
According to an aspect, the average level of difficulty in each battle can be adjusted by changing the bounds of access ranges for specified vehicles types (e.g., battle level 9 implies a certain difficulty level, which can be made easier by increasing the values of the bounds for vehicles including Tier 3 SPG, Tier 4 Medium and Tank Destroyers, or increasing the value for the lower bound of Tier 6 Light vehicles. Likewise each level 9 battle session may be increased in difficulty by decreasing the ranges for Tier 6 SPG, Tier 7 Light, Tier 9 Heavy and Tank Destroyers, and decrease the values of the bounds for Tier 5 Medium and Tank Destroyers vehicles.
Using battle levels as described herein, matchmaking servers can assign players to sessions to provide players with varied gaming experiences without frustrating or boring the player. Battle sessions are balanced while the difficulty levels of the battle session for each player are controlled.
FIG. 9 illustrates a method of performing matchmaking according to an aspect described herein. Initially in step 901, a battle level table such as table 801. Table 801 may be stored in a database, an array, a lookup table, or any other data structure usable for querying the data stored therein. Step 901 may be performed only once, and then table 801 may be reused as needed, or until table 801 is modified or replaced, e.g., to adjust difficulty of battle levels, add or remove specific vehicles, etc.
In step 903 matchmaking server 106 receives a battle session request from each of a plurality of clients, and queues the requests for allocation to a future battle session. When enough battle session requests have been received, e.g., based on a predefined minimum number of vehicles per battle session, then in step 905 matchmaking server 106 creates a battle session having a determined battle level. The battle level can be determined based on the vehicles in the queue (e.g., a battle level into which a majority of the queue is eligible), based on a sequential process of creating battle sessions of incrementing (or decrementing) battle levels, or based on any other desired criteria. The method of selecting the battle level is secondary to the assignment of a battle level to a particular battle session.
Once the battle level is selected, then in step 907 matchmaking server 106 identifies a particular vehicle in the queue that is eligible to participate in the battle session having the determined battle level, based on the information stored in battle level table 801. Step 907 may also include confirming a vehicle's eligibility based on additional criteria other than battle level. In one embodiment, matchmaking server 106 selects tanks so that a total weight of vehicles from two teams within the battle session are equal or near equal. In another embodiment matchmaking server 106 selects tanks so that a total weight of each type of vehicle on two teams is equal or near equal. In another embodiment, where each vehicle is associated with a number of player or NPC personnel required to operate the vehicle, the matchmaking server 106 may select vehicles so that the number of personnel on each of two teams is equal or near equal. In yet another embodiment, matchmaking server 106may confirm that, when sorting each of two team's vehicles by weight in decreasing order, the weight of the first member of each team is equal or near equal.
In step 909 matchmaking server 106 adds the identified vehicle to the particular battle session, e.g., by updating a data structure or database associated with storing battle session information. In step 911, matchmaking server 106 determines whether there is room remaining in the battle session for additional vehicles. If so, matchmaking server 106 returns to step907. If not, matchmaking server starts the battle session, e.g., by assigning the battle session to a particular game server105, and instructing each client machine associated with a vehicle in the battle session to contact the assigned game server105. Other ways of starting the game session are also possible, and are not limited by the example provided herein.
The method described with respect to FIG. 9 is illustrative only, and various modifications may be made. For example, matchmaking server 106 may also limit the number of a specific type of vehicle that is permitted in each battle session. Thus, even if there is room left in the battle session, and there are only vehicles of type Heavy Tank in the queue, matchmaking server might instead wait for a different vehicle type to be placed in the queue when the number of heavy tanks already in the battle session meets a predefined threshold or limit. As another example, the weight comparisons described above may be performed iteratively throughout the method as vehicles are added, and not necessarily performed at a single point in time. That is, matchmaking server 106 may select multiple vehicles at a time to add to a battle session, e.g., selecting vehicles in pairs where one vehicle of the pair is allotted to each of two teams in a battle session. Matchmaking server 106 may confirm one or more equal weights, pairs, personnel, vehicle, etc., at any time prior to starting the battle session.
In another example, even if there is room remaining in the battle session, matchmaking server 106 might proceed to start the battle session in step 913 when there are no vehicles in the queue, or no eligible vehicles in the queue, provided there are at least a predefined minimum number of vehicles assigned to the battle session. In yet another example, steps may be performed concurrently or in differing orders, such as steps 903 and 905, which may occur concurrently. Indeed, step 903may be performed continuously while all other steps are being performed. In addition, multiple instances of the method shown in FIG. 9 may be performed concurrently to assign vehicles to different battle sessions, e.g., when there is a large backlog in the queue.
As indicated above, vehicles may be placed in a battle session having a particular battle level using a variety of techniques. In one aspect, a vehicle may be placed randomly into any battle level acceptable based on the battle level table 801. In another aspect, a vehicle may be placed sequentially in increasing battle levels based on table 801. For example, when a use acquires a new tier 4 light tank, the first time the user plays a game with that tier 4 light tank the matchmaking server might force the vehicle to be assigned to a battle session of battle level 4. When the player plays a second game session using the same tier 4 light tank, the matchmaking server might force the vehicle to be assigned to a battle session of battle level 5. The third game session, battle level 6, the fourth game session, battle level 7, and so forth until the seventh battle session where the vehicle is in battle level 10. After that, the matchmaking server might start over at battle level 4. Alternatively the sequence might proceed in decreasing battle level order, and/or might start in the middle of the appl}