這篇提供一種不一樣的角度分析
基本上，"手滑一次" (以下簡稱 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 找"手滑"