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

看板tetris (俄羅斯方塊 - Tetris)作者 (~口卡口卡 修~)時間11年前 (2013/03/09 23:27), 編輯推噓25(25024)
留言49則, 4人參與, 最新討論串3/4 (看更多)
※ 引述《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

03/10 00:16, , 1F
厲害!
03/10 00:16, 1F

03/10 00:18, , 2F
二可能有很多細節太難 像手速夠快的 大概不是每步
03/10 00:18, 2F

03/10 00:18, , 3F
都看得到 一亂可能整場都亂掉了
03/10 00:18, 3F

03/10 00:20, , 4F
對了 像TOP這種程式容許作多大程度的更改呢?
03/10 00:20, 4F

03/10 00:26, , 5F
若以 sprint 40 line 20s 的速度來看,平均一個方塊
03/10 00:26, 5F

03/10 00:28, , 6F
只需要 0.2s. 所以我覺得影片的 sampling rate
03/10 00:28, 6F

03/10 00:29, , 7F
取 10Hz 一定夠
03/10 00:29, 7F

03/10 00:29, , 8F
可是TOP偶發的停頓也是這種情形之一...
03/10 00:29, 8F

03/10 00:30, , 9F
只是這樣做的缺點是 data redundancy 太多
03/10 00:30, 9F

03/10 00:30, , 10F
所以我前面才說要以 "tetromino 的 queue 為標準"
03/10 00:30, 10F

03/10 00:31, , 11F
只要 queue 的圖案有變動,就 sample 前後約 0.x s
03/10 00:31, 11F

03/10 00:31, , 12F
的 frame
03/10 00:31, 12F

03/10 00:34, , 13F
若遊戲畫面本身就會停頓,那就是 input data 本身的
03/10 00:34, 13F

03/10 00:34, , 14F
問題。 我個人覺得不該自己寫程式來修復它 XD
03/10 00:34, 14F

03/10 00:38, , 15F
另外不是很懂版主大 4F的問題 @@''
03/10 00:38, 15F

03/10 00:49, , 16F
看到不一樣的人出來回 還真是有點感動QQ
03/10 00:49, 16F

03/10 00:51, , 17F
像改獲勝條件 或是改成真實旋轉放置方塊等等
03/10 00:51, 17F

03/10 00:52, , 18F
是不是會超過遊戲本身的設計?
03/10 00:52, 18F

03/10 00:56, , 19F
就是幾乎不能改的部分 我沒念過程設 講起來亂七八糟
03/10 00:56, 19F

03/10 00:57, , 20F
改了就要大改而且會有很多問題的那種
03/10 00:57, 20F

03/10 01:01, , 21F
危機指數的部分有種快接近核心的感覺XD
03/10 01:01, 21F

03/10 01:01, , 22F
請問cost要設多少合理呢?直接行高?
03/10 01:01, 22F

03/10 01:06, , 23F
不過T的部分改成T*20(lines)好像可以normalize?
03/10 01:06, 23F

03/10 01:07, , 24F
改獲勝條件感覺應該只要改幾行 code 就夠了
03/10 01:07, 24F

03/10 01:08, , 25F
至於改 SRS, 演算法應該是用查表法, 所以改map就好了
03/10 01:08, 25F

03/10 01:08, , 26F
如果是單次KO不死改成垃圾塊歸零 多個無法消的垃圾塊
03/10 01:08, 26F

03/10 01:08, , 27F
不過還是得看 source code 才能定論XD
03/10 01:08, 27F

03/10 01:09, , 28F
這種條件 是不是太難?
03/10 01:09, 28F

03/10 01:11, , 29F
#1GXLYNL2這篇說的對戰法這樣~
03/10 01:11, 29F

03/11 01:31, , 30F
花了一天只挖到sprint replay的內容,看來找出1on1的
03/11 01:31, 30F

03/11 01:32, , 31F
replay是沒什麼希望了
03/11 01:32, 31F

03/11 11:50, , 32F
Neo這招不錯耶 如果挖到就有真實旋轉跟無lag記錄了
03/11 11:50, 32F

03/11 12:15, , 33F
問題點有三個:
03/11 12:15, 33F

03/11 12:15, , 34F
1.1on1對戰系統是否真的有記錄下來
03/11 12:15, 34F

03/11 12:16, , 35F
2.假設第二點通過,接下來就是該場rp的seq是多少
03/11 12:16, 35F

03/11 12:16, , 36F
3.假設有seq,那該檔案又放在哪裡
03/11 12:16, 36F

03/11 12:17, , 37F
三點都很難...
03/11 12:17, 37F

03/11 12:23, , 38F
感覺1就沒有了 但是玩家自行去按會有記錄?
03/11 12:23, 38F

03/11 12:23, , 39F
因為TOP資料夾裡面有replay資料夾
03/11 12:23, 39F

03/11 13:11, , 40F
原來有這東西= =,看來我方向錯了...
03/11 13:11, 40F

03/11 13:19, , 41F
ㄜ....那個資料夾的內容是single play的rp
03/11 13:19, 41F

03/11 13:19, , 42F
你可以試看看,如果是你自己玩的single play
03/11 13:19, 42F

03/11 13:19, , 43F
會有一個LastReplay.xml
03/11 13:19, 43F

03/11 13:20, , 44F
如果你去點右邊的排行榜的rp play的話,會先下載該
03/11 13:20, 44F

03/11 13:20, , 45F
rp在播放
03/11 13:20, 45F

03/11 13:21, , 46F
multi play的話....目前好像還沒看到
03/11 13:21, 46F

03/11 13:24, , 47F
通常sprint的大小是17k左右,上百K是馬拉松,上千K
03/11 13:24, 47F

03/11 13:25, , 48F
說錯,上百K是chelleng,上千才是馬拉松
03/11 13:25, 48F

03/11 14:49, , 49F
嗯嗯 感覺也像singleplay的檔 我原本還好奇是甚麼
03/11 14:49, 49F
文章代碼(AID): #1HErJhvb (tetris)
討論串 (同標題文章)
文章代碼(AID): #1HErJhvb (tetris)