最近微信的跳一跳小程序火了一把，所以前天也更新了微信玩了幾盤，最多手動(dòng)到200左右就不行了。
后來準(zhǔn)備用代碼寫個(gè)輔助工具，上Github一查，已經(jīng)有人做出來了，17年12月29號的項(xiàng)目，不到5天差不多5K的stars，以后還會更多，簡直可怕。
github.com/wangshub/we…
具體思路都差不多：
- 用adb調(diào)試手機(jī)，獲取截圖；
- 從截圖中識別棋子和目標(biāo)塊的中心點(diǎn)位置；
- 根據(jù)距離計(jì)算長按時(shí)間，系數(shù)和屏幕分辨率相關(guān)；
- 用adb模擬長按，完成跳躍。
唉，多么可惜，錯(cuò)過了一個(gè)好項(xiàng)目。
既然別人已經(jīng)實(shí)現(xiàn)了，那就嘗試點(diǎn)不一樣的，用 深度學(xué)習(xí) 解決一下。
基本思路
基本流程類似，唯一的區(qū)別在于如何獲取棋子和目標(biāo)塊的中心位置。
假如長按時(shí)間只取決于棋子和目標(biāo)塊的水平位置，那么只需要知道它們水平方向上的坐標(biāo)即可。
可以看作一個(gè) 物體檢測 問題，檢測出截圖中的棋子等物體，這里假設(shè)共包含七類物體：
- 棋子：chess
- 彩蛋塊：包括污水 waste、魔方 magic、商店 shop、音樂盒 music
- 普通塊：包括矩形塊 rect、圓形塊 circle
模型實(shí)現(xiàn)
我手動(dòng)標(biāo)注了500張截圖，基于ssd_mobilenet_v1_coco模型和TensorFlow物體檢測API，訓(xùn)練好的模型跑起來是這么個(gè)結(jié)果。
可以看到截圖中的棋子、魔方、矩形塊、圓形塊都被檢測了出來，每個(gè)檢測結(jié)果包括三部分內(nèi)容：
- 物體位置，用矩形標(biāo)注，對應(yīng)四元組 ymin、xmin、ymax、xmax；
- 物體類別，為以上七類中的一種；
- 檢測置信度，越高說明模型對檢測結(jié)果越有把握。
這不僅僅是簡單的規(guī)則檢測，而是 真正看到了截圖中共有哪幾個(gè)物體，以及每個(gè)物體分別是什么。
所以接下來，就只需從檢測結(jié)果中取出棋子的位置，以及最上面一個(gè)非棋子物體，即目標(biāo)塊的位置。
有了物體的邊界輪廓，取中點(diǎn)即可得到棋子和目標(biāo)塊的水平坐標(biāo)，這里進(jìn)行了歸一化，即屏幕寬度為1，距離在0至1之間。然后將距離乘以一個(gè)系數(shù)，作為長按時(shí)間并模擬執(zhí)行即可。
運(yùn)行結(jié)果
看起來很不錯(cuò)，實(shí)際跑分結(jié)果如何呢？
大概只能達(dá)到幾百分，問題出在哪？
主要是標(biāo)注數(shù)據(jù)太少，模型訓(xùn)練得不夠充分，所以檢測結(jié)果不夠準(zhǔn)確，有時(shí)候檢測不出棋子和目標(biāo)塊，而一旦出現(xiàn)這類問題，分?jǐn)?shù)必然就斷了。
嘗試了以下方法，將一張截圖朝不同的方向平移，從而得到九張截圖，希望提高檢測結(jié)果的召回率，但仍然有檢測不出來的情況，也許只有靠更多的標(biāo)注數(shù)據(jù)才能解決這一問題。
規(guī)則檢測
模型訓(xùn)練了20W輪，依舊存在檢測不出來的情況，郁悶得很，干脆也寫一個(gè)基于規(guī)則的 簡單版代碼 好了。
花了不到20分鐘寫完代碼，用OpenCV提取邊緣，然后檢測棋子和目標(biāo)塊的水平中心位置，結(jié)果看起來像這樣。
事實(shí)證明，最后跑出來的分?jǐn)?shù)，比之前的模型要高多了……
說好的深度學(xué)習(xí)呢？
總結(jié)
面對以下情況時(shí)，基于人工經(jīng)驗(yàn)定義規(guī)則，比用深度學(xué)習(xí)訓(xùn)練模型要省力、有效很多：
- 問題本身比較簡單，不需要復(fù)雜的抽象；
- 標(biāo)注數(shù)據(jù)比較有限，難以充分訓(xùn)練模型；
- 錯(cuò)誤懲罰很高，對錯(cuò)誤不能容忍。即便模型在99%的情況下能完美運(yùn)行，1%的錯(cuò)誤立馬讓游戲直接結(jié)束了，此時(shí)反而不如hard code的規(guī)則靠譜。
當(dāng)然，如果大家能一起努力，多弄些標(biāo)注數(shù)據(jù)出來，說不定還有些希望。
代碼在Github上：github.com/Honlan/wech…
不說了，我繼續(xù)刷分去了，用后面寫的不到一百行的代碼……
