这篇提供一种不一样的角度分析
基本上，"手滑一次" (以下简称 oops XD) 的动作
对玩家本身而言应该会破坏到原本的 攻势/防守
所以一场游戏结束后，会反映的统计量可能是 lpm、apm、combo、b2b、...etc
因此，不妨假设 OOPS 是 (LPM, APM, COMBO, B2B, ...) 的函数
亦即 令 OOPS = f(LPM, APM, COMBO, B2B, ...)
所以接下来的工作是如何找到 函数 f
======
这个问题其实就是单纯的 estimation, 不过我还是整个讲过一次
<1> 准备 observation:
先玩过一轮游戏后，请"玩家本身"明确指出他在那些地方有手滑
所以每场游戏可以得到如下数据:
│LPM │APM │oops│ ...
─┼──┴──┴──┴
1│39.1 58.3 2 ...
─┤
2│46.6 63 1 ...
─┤
3│42.8 51.7 4 ...
─┤
... ... ...
<2> estimate model f() or oops[n]:
上面表格可以写成 oops[i] = f(lpm[i], apm[i], ...) , i = 1 to n
为游戏场次
接下来看你是要直接估出 model f
还是直是接估出 oops[n+1]
if (LPM, APM, ...) = (lpm[n+1], apm[n+1], ...)
两个做法上，估 model f 会困难许多
只是一旦估出来后，就能一直拿来用了 XD
后者作法就蛮多种，例如使用 kalman filter or particle filer
<3> validation:
估完后一定要做验证。例如有 30笔资料，那就 20笔拿来 training
剩下 10笔拿来做测试。 可以假设 performance function 如下:
30 ^
error = Σ │oops[i] - oops[i]│
i=21
若 error 大于某一个值，代表估出来的东西不能相信
那得回头分析为啥误差过大，然后不断的 fix, 直到 error 在容许范围
=====
这里的 input 可能尚须考虑到每个玩家的 "能力"
例如直接把 top 上的能力图也纳入考虑
因为一场游戏中，同样的失误率， 不同玩家的 lpm or apm 可能会天差地远
差不多是这样吧。要做到上述的步骤
网络上应该有不少的程式可以直接拿来用 (这些都算是研究所的小 proj. XD)
想要写个程式直接从影片判读 "手滑" 这件事情
我个人觉得这不是几个工作天就能完成
绕个路做或许轻松许多
毕竟若有上百个影片档，版大们应该没有太多时间来逐一观看 mv 找"手滑"