讓 Breakout DQN 從遊戲畫面走到瀏覽器

打磚塊的球拍會跟著畫面移動，模型也能替每個動作算出分數；但這還不足以說它已經學會玩。一次漂亮的分數可能來自有利的開局，而持續執行的程式也可能只是卡在等待畫面，沒有真的繼續遊戲。

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

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

模型得先看見同一款遊戲

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

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

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

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

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

後來的檢查也把「程式能執行」、「模型有在更新」和「遊戲表現有進步」分開處理。短程訓練可以確認資料流和更新機制接得起來，卻不能單獨回答模型是否會玩；比較學習方式時，則需要相同規則、相同起點和多次訓練。更多除錯過程收在從能跑到可信：DQN 為什麼看起來會玩，卻可能卡住？。

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

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

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

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

訓練好的模型可以轉成 ONNX 格式，交給其他執行環境讀取。轉換成功只表示檔案能載入；我們還要確認它面對相同畫面時，是否仍做出相同選擇。

在一批固定畫面上，ONNX Runtime 的 CPU 與 CUDA 執行方式都保留了 PyTorch 的動作選擇；TensorRT 在這組測試中降低了較慢端的推論時間。這些結果只描述當時的模型和設備，不代表其他硬體一定得到同樣速度。模型換了執行方式，DQN 還會做出相同選擇嗎？說明了比較方式與結果。

網站也有可以直接遊玩的 Breakout。模型和遊戲在瀏覽器中執行，能正常遊玩代表部署流程已經接通；它本身不能證明模型在所有電腦上都得到相同分數，也不能證明瀏覽器產生的每一張畫面都與訓練環境完全相同。瀏覽器端的檢查和限制整理在把 DQN 放進瀏覽器後，還能像訓練時一樣玩嗎？。

這條路還能繼續問什麼？

這些工作沒有宣稱 DQN 已經徹底解決打磚塊。它們建立的是一條可以繼續檢查的路徑：讓遊戲規則清楚，知道模型從畫面學到了什麼，再用多場測試判斷改動是否可靠，最後確認換了執行環境後決策仍然合理。

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