一筆畫是圖論科普中一個著名的問題,它起源於柯尼斯堡七橋問題科普。數學家尤拉在他1736年發表的論文《柯尼斯堡的七橋》中不僅解決了七橋問題,也提出了一筆畫定理,順帶解決了一筆畫問題。用圖論的術語來說,對於一個給定的連通圖科普存在一條恰好包含所有線段並且沒有重複的路徑,這條路徑就是「一筆畫」。

尋找連通圖這條路徑的過程就是「一筆畫」的遊戲過程,如下:

一筆畫

遊戲的實現

「一筆畫」的實現不復雜,筆者把實現過程分成兩步:

  1. 底圖繪製
  2. 互動繪製

「底圖繪製」把連通圖以「點線」的形式顯示在畫布上,是遊戲最容易實現的部分;「互動繪製」是使用者繪製解題路徑的過程,這個過程會主要是處理點與點動態成線的邏輯。

底圖繪製

「一筆畫」是多關卡的遊戲模式,筆者決定把關卡(連通圖)的定製以一個配置介面的形式對外暴露。對外暴露關卡介面需要有一套描述連通圖形狀的規範,而在筆者面前有兩個選項:

  • 點記法
  • 線記法

舉個連通圖 —— 五角星為例來說一下這兩個選項。

五角星

點記法如下:

線記法如下:

「點記法」記錄關卡通關的一個答案,即端點要按一定的順序存放到陣列 coords中,它是有序性的記錄。「線記法」通過兩點描述連通圖的線段,它是無序的記錄。「點記法」最大的優勢是表現更簡潔,但它必須記錄一個通關答案,筆者只是關卡的搬運工不是關卡創造者,所以筆者最終選擇了「線記法」。:)

互動繪製

在畫布上繪製路徑,從視覺上說是「選擇或連線連通圖端點」的過程,這個過程需要解決2個問題:

  • 手指下是否有端點
  • 選中點到待選中點之間能否成線

收集連通圖端點的座標,再監聽手指滑過的座標可以知道「手指下是否有點」。以下虛擬碼是收集端點座標:

以下虛擬碼是監聽手指滑動:

在未繪製任何線段或端點之前,手指滑過的任意端點都會被視作「一筆畫」的起始點;在繪製了線段(或有選中點)後,手指滑過的端點能否與選中點串連成線段需要依據現有條件進行判斷。

示意圖

上圖,點A與點B可連線成線段,而點A與點C不能連線。筆者把「可以與指定端點連線成線段的端點稱作有效連線點」。連通圖端點的有效連線點從連通圖的線段中提取:

But…有效連線點只能判斷兩個點是否為底圖的線段,這只是一個靜態的參考,在實際的「互動繪製」中,會遇到以下情況:

AB成線
如上圖,AB已串連成線段,當前選中點B的有效連線點是 A 與 C。AB 已經連線成線,如果 BA 也串連成線段,那麼線段就重複了,所以此時 BA 不能成線,只有 AC 才能成線。

對選中點而言,它的有效連線點有兩種:

  • 與選中點「成線的有效連線點」
  • 與選中點「未成線的有效連線點」

其中「未成線的有效連線點」才能參與「互動繪製」,並且它是動態的。

未成線的有效連線點

回頭本節內容開頭提的兩個問題「手指下是否有端點」 與 「選中點到待選中點之間能否成線」,其實可合併為一個問題:手指下是否存在「未成線的有效連線點」。只須把監聽手指滑動遍歷的陣列由連通圖所有的端點座標 coords 替換為當前選中點的「未成線的有效連線點」即可。

至此「一筆畫」的主要功能已經實現。可以搶先體驗一下:

demo

https://leeenx.github.io/OneStroke/src/onestroke.html

自動識圖

筆者在錄入關卡配置時,發現一個7條邊以上的連通圖很容易錄錯或錄重線段。筆者在思考能否開發一個自動識別圖形的外掛,畢竟「一筆畫」的圖形是有規則的幾何圖形。

底圖

上面的關卡「底圖」,一眼就可以識出三個顏色:

  • 白底
  • 端點顏色
  • 線段顏色

並且這三種顏色在「底圖」的面積大小順序是:白底 > 線段顏色 > 端點顏色。底圖的「採集色值表演算法」很簡單,如下虛擬碼:

對於連通圖來說,只要把端點識別出來,連通圖的輪廓也就出來了。

端點識別

理論上,通過採集的「色值表」可以直接把端點的座標識別出來。筆者設計的「端點識別演算法」分以下2步:

  1. 按畫素掃描底圖直到遇到「端點顏色」的畫素,進入第二步
  2. 從底圖上清除端點並記錄它的座標,返回繼續第一步

虛擬碼如下:

But… 上面的演算法只能跑無損圖。筆者在使用了一張手機截圖做測試的時候發現,收集到的「色值表」長度為 5000+ !這直接導致端點和線段的色值無法直接獲得。

經過分析,可以發現「色值表」裡絕大多數色值都是相近的,也就是在原來的「採集色值表演算法」的基礎上新增一個近似顏色過濾即可以找出端點和線段的主色。虛擬碼實現如下:

取到端點的主色後,再跑一次「端點識別演算法」後居識別出 203 個端點!這是為什麼呢?

區域性

上圖是放大5倍後的底圖區域性,藍色端點的周圍和內部充斥著大量噪點(雜色塊)。事實上在「端點識別」過程中,由於噪點的存在,把原本的端點被分解成十幾個或數十個小端點了,以下是跑過「端點識別演算法」後的底圖:

識別後

通過上圖,可以直觀地得出一個結論:識別出來的小端點只在目標(大)端點上集中分佈,並且大端點範圍內的小端點疊加交錯。

如果把疊加交錯的小端點歸併成一個大端點,那麼這個大端點將十分接近目標端點。小端點的歸併虛擬碼如下:

加了小端點歸併演算法後,「端點識別」的準確度就上去了。經筆者本地測試已經可以 100% 識別有損的連通圖了。

線段識別

筆者分兩個步驟完成「線段識別」:

  1. 給定的兩個端點連線成線,並採集連線上N個「樣本點」;
  2. 遍歷樣本點畫素,如果畫素色值不等於線段色值則表示這兩個端點之間不存線上段

如何採集「樣式點」是個問題,太密集會影響效能;太疏鬆精準度不能保證。

在筆者面前有兩個選擇:N 是常量;N 是變數。
假設 N === 5。區域性提取「樣式點」如下:

區域性

上圖,會識別出三條線段:AB, BC 和 AC。而事實上,AC不能成線,它只是因為 AB 和 BC 視覺上共一線的結果。當然把 N 值向上提高可以解決這個問題,不過 N 作為常量的話,這個常量的取量需要靠經驗來判斷,果然放棄。

為了避免 AB 與 BC 同處一直線時 AC 被識別成線段,其實很簡單 —— 兩個「樣本點」的間隔小於或等於端點直徑
假設 N = S / (2 * R),S 表示兩點的距離,R 表示端點半徑。區域性提取「樣式點」如下:

區域性

如上圖,成功地繞過了 AC。「線段識別演算法」的虛擬碼實現如下:

效能優化

由於「自動識圖」需要對影象的的畫素點進行掃描,那麼效能確實是個需要關注的問題。筆者設計的「自動識圖演算法」,在識別影象的過程中需要對影象的畫素做兩次掃描:「採集色值表」 與 「採集端點」。在掃描次數上其實很難降低了,但是對於一張 750 * 1334 的底圖來說,「自動識圖演算法」需要遍歷兩次長度為 750 * 1334 * 4 = 4,002,000 的陣列,壓力還是會有的。筆者是從壓縮被掃描陣列的尺寸來提升效能的。

被掃描陣列的尺寸怎麼壓縮?
筆者直接通過縮小畫布的尺寸來達到縮小被掃描陣列尺寸的。虛擬碼如下:

把源圖片縮小4倍後,得到的圖片畫素陣列只有原來的 4^2 = 16倍。這在效能上是很大的提升。

使用「自動識圖」的建議

儘管筆者在本地測試的時候可以把所有的「底圖」識別出來,但是並不能保證其它開發者上傳的圖片能否被很好的識別出來。筆者建議,可以把「自動識圖」做為一個單獨的工具使用。

筆者寫了一個「自動識圖」的單獨工具頁面:https://leeenx.github.io/OneStroke/src/plugin.html
可以在這個頁面生成對應的關卡配置。

結語

下面是本文介紹的「一筆畫」的線上 DEMO 的二維碼:

demo

遊戲的原始碼託管在:https://github.com/leeenx/OneStroke
其中游戲實現的主體程式碼在:https://github.com/leeenx/OneStroke/blob/master/src/script/onestroke.es6
自動識圖的程式碼在:https://github.com/leeenx/OneStroke/blob/master/src/script/oneStrokePlugin.es6

感謝耐心閱讀完本文章的讀者。本文僅代表筆者的個人觀點,如有不妥之處請不吝賜教。

感謝您的閱讀,本文由 凹凸實驗室 版權所有。如若轉載,請註明出處:凹凸實驗室(https://aotu.io/notes/2017/11/02/onestroke/