要理解这些问题,我们要首先理解战神服务器处理贸易的方式.
战神服务器处理贸易的方式:
设计过/写过服务器程序的朋友都知道,怎么提供稳定的服务给更多用户是首要的设计目标之一.
对于战神服务器程序中处理贸易的这部分功能, 有两种可能的设计方法
设计一: 每一秒钟检查所有正在进行中的贸易, 如果这个贸易时间已经到达,增加卖家的银币数量,增加买家的货物数量.
设计二: 每N秒钟检查所有正在进行中的贸易, 如果这个贸易时间已经到达,增加卖家的银币数量,增加买家的货物数量.
比较设计一与设计二,
同样多的时间内,设计二比设计一少做N次的比较.节省了处理器运算时间.
每次更变买卖双方的状态都需要进行数据库操作,可能需要读写磁盘.设计二与设计一相比,给数据库带来的压力更小.
如果用一个特定的进程处理贸易,设计二与设计一相比,进程转换的次数少了N倍.
所以可以看出,设计二远远好于设计一.
(如果我是老板,而战神的程序员使用设计一的话,一定让他明天就回家.)
然后再回头看看数据,很容易发现,目前战神是每 180 秒 处理一次贸易.
这就决定了同样两座城之间的两次贸易的商队的时间,最多会有3分钟的区别.
数据拟合:
影响商队的时间的变量包括距离,贸易等级(通过小实验可以看出只有买方的贸易等级影响商队的时间)
一开始,我们并不能确定距离,贸易等级和商队的时间三者之间的关系是否是线性的.
而拟合含有三个变量的非线性方程需要大量的数据,而这要花费太多的时间.
所以,我采用的方法是,通过固定距离把问题转化为两个变量(贸易等级和商队的时间)的方程.
而且直观上,贸易等级越高,商队时间越短
这个关系可以表示为 商队的时间 = 参数1 / ( (贸易等级 * 参数2 + 参数3) ^ 参数4) + 参数5 ;
根据贸易中心的描述,我们可以知道 参数2 = 10%;
参数3 = 1 或者 0.9
参数3等于1的时候, 贸易9的速度是贸易1的1.9倍
参数3等于0.9的时候, 贸易9的速度是贸易1的1.8/1.1 ~= 1.72 倍
所以我们得到
公式一) 商队的时间 = 参数1 / ( (贸易等级 * 10% + 0.9 ) ^ 参数4) + 参数5 ;
公式二) 商队的时间 = 参数1 / ( (贸易等级 * 10% + 1 ) ^ 参数4) + 参数5 ;
然后带入一组(商队的时间,贸易等级) 的数据-- 笔者用了大约20对数据.
可以推导出 参数1 ,参数4,和参数5的值.
同时,在 "参数4是个整数" 的猜想下, 我倾向于选择公式二.
通过类似的方法可以在固定贸易等级的情况下推出距离和商队的时间的关系.
如何处理误差:
由于系统每3分钟处理一次贸易的运行方式,我们很难得到精确的数据. 所以我们推出的公式一定存在误差.
1) 但是, 使用更多的数据来拟合公式能够减小误差.
2) 同时,这种每3分钟一次的运行方式也给与了我们容忍误差的能力.
比如说系统在 :02:58 :05:58 :08:58 .... :59:58 处理贸易.
根据公式我们推出, 某次贸易在 03:34 完成, 而实际上贸易在 04:58 完成.
但是只要掠夺军队在 :04:59 到达,我们就能达到目的.
系统的处理节奏:
可以看出,得知系统的处理节奏是达到完美追商的重要环节.
正如上面的例子, 通过得知":02:58 :05:58 :08:58 .... :59:58 " 我们才能准确地派出掠夺军队.
其实,获得系统的处理节奏很简单. 只要通过进行一次购买就能得到.
假如说某次购买的交易达成时间是 :11:58, 我们就能推出 ":02:58 :05:58 :08:58 .... :59:58 "是系统的处理节奏.
根据笔者的观察,系统的处理节奏比较稳定.一般同一个节奏会维持几个小时.
备注:
所有试验数据都是在同一时间,两座城之间只有一项贸易正在进行中的情况下收集的.
结论:
1) 商队的时间和买方的贸易等级的一次方成反比。
2) 商队的时间和距离的一次方成正比。
3) 具体交易时间向后推迟到下一次3分钟一次的系统处理贸易的时刻.
4) 其他常数项可以用单变量一次函数拟和得到.
