Re: [資訊] 複賽賽後統計數據表

[doom8199 (～口卡口卡 修～)]

※ 引述《tadpole1 (蝌蚪)》之銘言：


    若想要統計一些數據，建議寫個程式來做事後統計

    不然用看的太累人了 = =ll, 也可以降低人為主觀因素參雜


    可以有兩種做法:


    <1> 請 top 的原作者看能不能提供一個 switch

        將遊戲過程的數據 dump 出來 (就像 FB上的 battle 那樣)

        再自己寫個 parser 拿出需要的 information 做後續分析

        這東西是一定存在的，只是要看作者本人願不願意提供XD



    <2> 寫個程式 (如 matlab), 直接從錄下來的影片檔建 database


        例如以遊戲中暫放 tetromino 的 queue 為標準

        只要 frame 與 frmae 之間的 queue 有變動

        就擷取  +- 0.x s 時的 frame (做為 current end 和 next start 的 pattern)



        有了這些 pattern，利用背景顏色判斷每個 frame 中的 20*10 window size

        已被佔去那些方塊，再取 per-frame difference 可以算出

        "每個 queue 變動時，玩家獲得的 grade"。



        一旦有了上述的 database, 就可以自己從中組合出自己想要的統計量。

        當然走這條路的建議是，錄製遊戲畫面的程式、以及錄出來的 size ratio

        要 unify, 以簡化程式的 programming。



=======


: http://ppt.cc/XtgM
: 1.Unforced Errors (非受迫性失誤)
: 只有單純記"手滑"的部份
: 隱形失誤大部份看不太到 記不了(EX:誤按hold、方愧堆疊不佳連帶妥協也不計)

    個人覺得這一項可以先拿掉，主要是因為定義的不夠 specific
    而且這東西也很難去訂出一個客觀的標準

    例如玩家A放了一個直立 S而造成空洞，而這個空洞是可以做出 T轉凹槽
    觀看者其實不能確定在這當下 玩家A是否真的手滑，只是後來發現可以做
    出T槽；抑或是真的故意鋪下T槽之路。這個行為是 depend on 玩家的思考，
    光靠畫面是很難 render 出玩家真正的思考邏輯


: 2.KO Points (KO點=勝點)
: 代表攻擊有致死的機會
: 但有時候用看的有點辛苦 大概會有誤差

    同上。若假設玩家 A 疊了 3w 14 lines, 他/她可能有機會將對方一次打掛；
    但同一個畫面下讓其他玩家 play, 你是沒辦法 guarantee 該玩家有 "機會"
    可以將對手頂上天XD 。這個統計量得牽涉到雙方的手速、攻擊力、以及
    解洞能力


: 3.KO (KO數=勝場數)
: 事實上也等於勝場

: 4.High Point (高點=危機次數)
: 高處定義:中央4排高度大於等於16行

    個人覺得 "危機" 用 "指數" 比用 "次數" 來詮釋會比較有意義
    主因是 "一次的危機" 可大可小。要 induce 大小概念，比較直觀
    的想法是 "玩家處在中央高度1x行越久，危機越大"。
    因此 "危機指數" 可以將時間納入考慮

    例如 玩家A 花了 48s 玩了一場 game
         其中有 3s 高度在 16 lines、 4s 高度在 17 lines
         那最簡單可以用加權平均  (3*X + 4*Y)/48,     (X、Y 為 cost)
         來代表 "危機指數"

         甚至也能改成:

             1    19
           ──   Σ  c(i)*t(i)  , 其中  c(i)  為中央四排高度 i 時的 cost
             T   i = 0                   t(i)  為中央四排高度 i 時的時間

                                              19
                                         T =  Σ   t(i)  代表一場遊戲的時間
                                             i = 0

    至於名稱可以叫 hazard,  crisis  之類的


: 5.Miss Per Game (平均每場(非受迫性)失誤次數)
: =非受迫性失誤次數/場數
: 6.KO Rate (KO成功率)
: =KO/(KO point)
: 表示致命一擊成功率
: 7.High Point Attack Rate (補刀率)
: =(KO point)/(High point)
: 對方在高點時進行(致死)攻擊的比率
: 8.High Point KO Rate
: =KO/(High point)
: 對方在高點時KO的比率

: 9.Lpm Apm Time
: total那行是指這幾場下來的(加權)平均Apm和Lpm，Time在total那行則是以分為單位
: APMfinal=sum(APMi*TIMEi)/sum(TIMEi)  i=1~n
: LPM亦同
: 目前只記了一場和一些部份
: 以上的詞可以的話幫我想帥一點的

======


    battle 跟最初的 tetris game 最大差異主要有幾個:

    <1> combo   <2> SRS   <3> B2B   <4> hard drop


    所以目前我想到的統計量大概跟上述有關

    例如:   (a) 單場平均發動一次 combo 的個數
                (combo times per snapshot)

            (b) 單場平均發動一次 combo/b2b 的攻擊力
                (combo/b2b power per snapshot)

            (c) 單場平均一分鐘發動 "幾次" combo/b2b
                (combo/b2b times per min)

            (d) 單場平均一分鐘 soft drop 的秒數
                (soft drop utilization per min)



    其實 top 的能力圖也有將上述的資訊展現出來 (可惜是總平均)

    若能每場都分析這些數據，再搭配 lpm 和 apm，

    我是覺得可以約略定位出該玩家的攻擊模式與能力水平 for every game period

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 175.98.124.34
推 Rentch      :厲害!
推 Rentch      :二可能有很多細節太難 像手速夠快的 大概不是每步
推 Rentch      :都看得到 一亂可能整場都亂掉了
推 Rentch      :對了 像TOP這種程式容許作多大程度的更改呢?
→ doom8199    :若以 sprint 40 line 20s 的速度來看，平均一個方塊
→ doom8199    :只需要 0.2s. 所以我覺得影片的 sampling rate
→ doom8199    :取 10Hz 一定夠
推 Rentch      :可是TOP偶發的停頓也是這種情形之一...
→ doom8199    :只是這樣做的缺點是 data redundancy 太多
→ doom8199    :所以我前面才說要以 "tetromino 的 queue 為標準"
→ doom8199    :只要 queue 的圖案有變動，就 sample 前後約 0.x s
→ doom8199    :的 frame
→ doom8199    :若遊戲畫面本身就會停頓，那就是 input data 本身的
→ doom8199    :問題。 我個人覺得不該自己寫程式來修復它 XD
→ doom8199    :另外不是很懂版主大 4F的問題 @@''
推 tadpole1    :看到不一樣的人出來回 還真是有點感動QQ
推 Rentch      :像改獲勝條件 或是改成真實旋轉放置方塊等等
推 Rentch      :是不是會超過遊戲本身的設計?
推 Rentch      :就是幾乎不能改的部分 我沒念過程設 講起來亂七八糟
推 Rentch      :改了就要大改而且會有很多問題的那種
推 Rentch      :危機指數的部分有種快接近核心的感覺XD
推 Rentch      :請問cost要設多少合理呢？直接行高?
推 Rentch      :不過T的部分改成T*20(lines)好像可以normalize?
→ doom8199    :改獲勝條件感覺應該只要改幾行 code 就夠了
→ doom8199    :至於改 SRS, 演算法應該是用查表法, 所以改map就好了
推 Rentch      :如果是單次KO不死改成垃圾塊歸零 多個無法消的垃圾塊
→ doom8199    :不過還是得看 source code 才能定論XD
推 Rentch      :這種條件 是不是太難?
推 Rentch      :像#1GXLYNL2這篇說的對戰法這樣~
推 liu2007     :花了一天只挖到sprint replay的內容，看來找出1on1的
→ liu2007     :replay是沒什麼希望了
推 Rentch      :Neo這招不錯耶 如果挖到就有真實旋轉跟無lag記錄了
推 liu2007     :問題點有三個：
→ liu2007     :1.1on1對戰系統是否真的有記錄下來
→ liu2007     :2.假設第二點通過，接下來就是該場rp的seq是多少
→ liu2007     :3.假設有seq，那該檔案又放在哪裡
→ liu2007     :三點都很難...
推 Rentch      :感覺1就沒有了 但是玩家自行去按會有記錄?
推 Rentch      :因為TOP資料夾裡面有replay資料夾
推 liu2007     :原來有這東西= =，看來我方向錯了...
推 liu2007     :ㄜ....那個資料夾的內容是single play的rp
→ liu2007     :你可以試看看，如果是你自己玩的single play
→ liu2007     :會有一個LastReplay.xml
→ liu2007     :如果你去點右邊的排行榜的rp play的話，會先下載該
→ liu2007     :rp在播放
→ liu2007     :multi play的話....目前好像還沒看到
推 liu2007     :通常sprint的大小是17k左右，上百K是馬拉松，上千K
→ liu2007     :說錯，上百K是chelleng，上千才是馬拉松
推 Rentch      :嗯嗯 感覺也像singleplay的檔 我原本還好奇是甚麼