讓打磚塊 DQN 從遊戲畫面走到瀏覽器

讓 AI 玩打磚塊，需要把畫面整理成模型能讀取的資料，再透過遊戲回饋學習動作。這個專案從 DQN 訓練開始，一路做到模型比較、推論最佳化與瀏覽器遊戲，也在過程中發現模型掉命後卡在等待畫面的問題。

這個專案一路追問幾個更實際的問題：模型每次看見什麼？分數改變時，怎麼知道是模型變好，而不是遊戲規則變了？訓練好的模型放進瀏覽器後，還會做出原來的選擇嗎？

DQN 是一種用神經網路估計「眼前畫面下，各個動作未來可能帶來多少分」的方法。要讓這個估計有意義，遊戲、畫面和計分方式都得先說清楚；要知道它是否真的學會，還得觀察多場遊戲，而不是只挑最高分。

模型得先看見同一款遊戲

對人來說，打磚塊是一個連續畫面；對模型來說，遊戲必須把每一步整理成它能讀取的數字。單看一張畫面，不容易分辨球正往哪個方向移動，因此這個專案讓模型同時參考最近幾張畫面，再從中選擇不動、發球、往右或往左。

每次操作推進多少畫面、掉命後如何重新發球、遊戲何時算結束，都會改變模型看到的經歷。把這些規則固定，才能讓兩個版本從相近條件開始比較。這些入門概念和畫面處理方式，整理在從打磚塊畫面理解 Q-Learning。

分數高了，模型就真的學會了嗎？

早期測試中，DQN 平均得分 4.53，高於隨機選擇動作的 1.33。乍看之下，模型似乎已經學到一些東西；但逐局檢查後發現，15 局裡有 10 局其實是在時間上限到達時被迫停止。

原因不是模型在激烈比賽中撐得更久，而是它掉命後常常沒有按下發球鍵。遊戲停在等待畫面，模型卻繼續把球拍往右移。這提醒我們，平均分數和操作次數要連同每局實際發生的事一起看。

修正發球流程後，我把資料輸入、模型更新與逐局行為納入檢查，再以相同規則、起點和訓練長度比較模型。DQN 訓練與除錯篇記錄了這段過程。

更快訓練，或換一種模型，會有什麼代價？

同時跑兩場打磚塊，收集相同數量的遊戲操作約快 1.6 倍，但這次訓練出的模型分數沒有一起提高。比較不同 DQN 時，較複雜的版本在部分測試中得分較高，代價是更多計算；換到新的遊戲起點後，分數也低於挑選模型時看到的高分。

這些結果說明「訓練快」、「某一批分數高」和「面對新局面也穩定」是不同問題。並行訓練與模型比較的過程，可以從訓練更快，DQN 就更好嗎？繼續閱讀。

模型搬到另一台電腦或瀏覽器後，還是原來的模型嗎？

訓練好的模型可以轉成 ONNX 格式，交給其他執行環境讀取。我用相同遊戲畫面比較模型在不同執行方式下選出的動作。

在一批固定畫面上，ONNX Runtime 的 CPU 與 CUDA 執行方式都保留了 PyTorch 的動作選擇；TensorRT 在這組測試中降低了較慢端的推論時間。推論比較篇說明了測量方式與結果。

打磚塊網頁版在瀏覽器中執行模型與遊戲。部署時，我檢查了畫面處理、動作對應與模型轉換後的決策，詳細流程整理在瀏覽器部署篇。

這條路還能繼續問什麼？

專案將遊戲設定、模型訓練、逐局評估與瀏覽器部署接成一條完整流程。固定遊戲規則後，可以比較模型改動的得分與運算成本，再把選定的模型帶進可操作的展示。

核心文章依照這些問題重新安排閱讀順序；此外，還有一篇獨立實驗探討「失去一條命時多扣一分」是否能改善表現：球掉一條命時多扣一分，真的會讓 AI 玩得更好嗎？