兩年多前，Adobe 發布了一則引人關注的公告 —— 將在 2020 年 12 月 31 日終止支持 Flash，宣告了一個時代的結束。

一晃兩年過去了，Adobe 早已從官方網站中刪除了 Flash Player 早期版本的所有存檔，并阻止基于 Flash 的內容運行。微軟也已經終止對 Adobe Flash Player 的支持，并禁止其在任何 Microsoft 瀏覽器上運行。Adobe Flash Player 組件于 2021 年 7 月通過 Windows 更新永久刪除。

當 Flash 下架之后，在世界的某個角落，這位「老同志」卻仍在發揮余熱。

Hapland 是 2005 年推出的一款 Flash 解謎游戲，也是很多人的童年回憶。在游戲中，玩家需要通過爭取這個世界中的人們的幫助，找到打開關卡的方法，同時不要讓他們被怪物吃掉或被地雷炸死。

這款游戲的圖形要在 Flash 中繪制，代碼要在 Flash 中編寫，所有動畫都在 Flash 時間軸中完成。可以這么理解：這款游戲的「骨子里都帶著 Flash」。

作為游戲開發行業的一員，Robin Allen 發現，人們似乎特別喜歡 Hapland 游戲，所以他想對這款基于 Flash 的游戲的 Steam 版本進行一些修復，包括繪制更好的圖形、將幀速率提高到 60FPS，并添加一些額外的「秘密」等等。

這時候該怎么做？作者詳細講述了試驗過程。

一些失敗的經驗

失敗的嘗試 1:

我嘗試的第一件事是讓 Flash 將游戲導出為可執行文件，但失敗了，因為它的性能與 2005 年一樣糟糕。我想制作一個以當代幀速率運行的東西。我想擺脫 Flash Player。

失敗的嘗試 2:

其次，我花了太多時間擺弄 Adobe AIR（Flash 桌面 runtime）和 Starling（一個在 GPU 上繪制 Flash 場景的庫）。

最后我放棄了這個，部分原因是 AIR 有很多問題而且很糟糕，也是因為我不想在一切結束時得到一個奇怪的 Adobe 結果；我想擁有自己的東西，可以做我想做的事。例如，如果我想遷移到 Linux 怎么辦？

前進的道路是顯然的：我必須制作自己的 Flash 播放器。

計劃

以下是 Hapland 的運作方式。這里有一棵精靈樹，在 Flash 中，動畫精靈可以將代碼附加到某些幀，當播放箭頭到達那里時運行。Hapland 經常使用這一方式。游戲角色的行進路徑都是很長的時間軸動畫，角色經常有幀動作，比如門關了就打開，比如到了地雷區，如果還沒爆炸就會觸發。

時間軸中的小 “a” 是幀動作。

幸運的是，.fla 文件只是 XML。我只需要解析它，將相關數據導出為簡單的自定義格式并編寫一個播放器來讀取它、繪制場景、處理輸入并運行動畫。

Hapland 仍然是一個 Flash 項目，在 Flash 編輯器中編寫和維護；只有 Flash Player 會被替換。

光柵化矢量

Flash 確實支持光柵圖，但實際上是為矢量圖設計的。這就是 Flash 影片即使在撥號連接的情況下也能快速加載的原因。

所有 Hapland 圖形都是矢量圖。而 GPU 不太喜歡繪制矢量圖形，卻喜歡大批量的紋理三角形。所以，我需要將這些矢量光柵化。

我決定離線光柵化它們并將光柵文件打包到游戲中。在游戲運行時將它們光柵化并成為這個微小的可執行文件會很有趣，但我不想擁有那些額外的移動部件。我喜歡讓盡可能多的代碼在自己的開發機器上運行，這樣我就可以隨時關注到它。

Flash 以 XML 格式存儲矢量圖。你可能會說， XML 不是圖形數據的一種糟糕選擇，但你畢竟不是 Macromedia 的產品經理。看看這個：

在 .fla 文件中看到的矢量數據。

我不是在抱怨，這讓我的工作更輕松了。

盡管我無法訪問 spec，但光柵化這并不是一個難題。自 PostScript 以來，矢量圖形的貝茲曲線模型無處不在。所有這些 API 的工作方式都相同。經過反復試驗，我編寫了一個程序來解析這些形狀定義，并使用 Mac 的 CoreGraphics 庫將它們呈現為 PNG。

CoreGraphics 是一個值得懷疑的選擇。我選擇它是因為我使用 Mac 工作，依賴性很強。但這確實成功了，所以我總是不得不在 Mac 上光柵化圖形，即使是 Windows 版本也是如此。如果再一次做這件事，我可能會選擇一個跨平臺的庫。

渲染這些 PNG 后，導出器會將它們組裝成地圖集？并沒有，它只是按高度對所有內容進行排序，然后像文檔中的文本一樣逐行排列。這遠非最佳，但已經足夠了。

為簡單起見，圖集為 2048×2048 像素，這是 OpenGL 3.2 實現必須支持的最小紋理尺寸。

來自 Hapland 3 的圖例集。

光柵化形狀非常慢，所以為了保持合理的構建時間，我需要跳過渲染沒有改變的東西。Flash 使用的壓縮 XML 格式確實有每個文件的最后修改字段，但 Flash 似乎沒有正確使用它們，因此您不能依賴它們。

相反，我只是對每個形狀的 XML 進行哈希處理，并且只有在它發生變化時才進行重建。即使這樣也失敗了，因為 Flash 有時喜歡重新排列未更改的對象中的 XML 標記，但同樣，這已經足夠了。

用匯編程序編寫二進制文件

導出器將動畫數據寫入自定義二進制格式。它只是逐幀通過時間軸，并寫出每一幀的所有更改。

我在這里想到了寫入匯編列表而不是直接寫入二進制文件，我很喜歡這一點。沒有 CPU 指令，只有數據，這讓調試更容易，因為我可以查看匯編文件以查看生成的內容，而不是在十六進制編輯器中瀏覽字節。

輸出.bin

13 92 49 EC : BD 31 E8 FF
09 DD BE DE : C9 5A 1D 36
3F C0 4E 31 : 52 FD 41 C6
8B 5D C0 20 : 19 1F 5F 1F
54 97 8C 27 : 34 1F 30 EA
A9 A9 E0 55 : 40 29 A3 19
89 BC 5F 24 : 3A 98 FD B9
DE 15 F2 D4 : 2A B7 41 2C
4E 9D 37 D9 : E2 13 4B 01
36 3F 40 08 : AC 3C FF 84
E9 AE C5 2C : 11 2F 69 CF
63 CE 85 D1 : A7 CB B1 1A
5F 5B 60 1A : 77 99 71 B0
60 6E C4 C7 : 73 1F EA 1F
31 0D 0C 39 : B0 86 70 42

輸出.asm

; Left Side
timeline_132:; --- Left Side, Frame 0 ---
.frame_0:; --- Left Side, Frame 0, Layer 22 ---
db Quad
dd 0.152926, 0.162029, 0.184475, 1.000000 ; color
dd 799.599976, -20.950001dd 799.599976, 556.650024dd 46.000000, 556.650024dd 46.000000, -20.950001; --- Left Side, Frame 0, Layer 21 ---
; instance of shape [Left Side] [Wall Shadows] [Frame 0]
dd Shape
dw 1560

你更愿意調試哪個？

我本可以讓導出器將字節寫入一個文件，同時將單獨的文本列表寫入另一個文件，而不使用匯編程序，但我沒有這樣做，因為：

1) 匯編程序已經存在；

2) 我不是必須調試它們；

3) 它們支持標簽。

導出器的其余部分大多不夠有趣；它只是 walk the tree 并將變換矩陣、顏色效果等事物，然后繼續游戲程序本身。我選擇用 C++ 編寫這個，因為我已經知道它，并且新事物讓我害怕。

場景圖

Hapland 非常適合場景圖。這是 Flash 使用的模型，Hapland 就是圍繞它設計的，因此嘗試使用不同的模型是沒有意義的。

我將場景存儲在內存中，作為一棵節點樹，每個節點都有一個變換，可以自行繪制并接受鼠標點擊。每個具有自己行為的游戲對象都是其自己類的實例，派生自 Node.js。「面向對象」目前在游戲開發圈子里并不流行，但我使用的是 Flash，所以顯然不關心這個問題。

Hapland 使用的 Flash 功能，如顏色變換和遮罩，都是存在的。不過我沒有像 Flash 那樣實現任意遮罩，只是實現了矩形剪輯并編輯了我所有的圖形，所以所有的遮罩都是矩形。

框架腳本

幾乎所有的 Hapland 邏輯都包含在附加到時間軸幀的 ActionScript 中。要如何導出所有這些東西？我可不想在我的游戲中包含 ActionScript 解釋器。

一個簡單的幀動作。

最后，我們使用了一些技巧，我的導出器從每一幀讀取 ActionScript 并應用大量正則表達式以嘗試將其轉換為 C++。例如，crate.lid.play () 可能會變成 crate ()→lid ()→play ();。這兩種語言在句法上非常相似，這對于許多更簡單的框架動作來說效果很好，但它仍然留下了相當多的錯誤代碼，除了手動重寫所有剩余的框架動作之外別無他法。

對于 C++ 中的所有框架腳本，它們在構建時被提取并成為每個符號的 Node 子類上的方法。還會生成一個調度方法以在正確的時間調用，看起來像這樣：

void tick() override {
 switch (currentFrame) {
 case 1: _frame_1(); break;
 case 45: _frame_45(); break;
 case 200: _frame_200(); break;
 }
}

需要指出的最后一件事是腳本系統最終是某種靜態類型的，這有點難受。游戲輸出的最終游戲對象如下所示：

struct BigCrate: Node {
 BigCrateLid *lid() { return (BigCrateLid *)getChild("lid"); }
 BigCrateLabel *label() { return (BigCrateLabel *)getChild("label"); }

 void swingOpen() { ... }
 void snapShut() { ... }
 void burnAway() { ... }
};

因此，即使一切仍然是大量的自動字符串名稱查找，類型安全的單板會阻止你在錯誤的對象上調用錯誤的函數，從而使你免于在動態語言中遇到的那類煩人的 bug。

縱橫比

HD 重置版游戲都會遇到畫面拉伸的問題，最初的 Flash 游戲很多是頁游，甚至沒有全屏運行的能力，所以它們只是使用設計者喜歡的寬高比，大多是 3:2 左右。

如今最常見的縱橫比似乎是 16:9，16:10 在筆記本電腦上也很流行。我希望游戲在其中任何一個方面看起來都不錯，沒有任何黑條或拉伸。要做到這一點的唯一方法是從原件上切掉一些部分，或者在上面添加一些部分。

所以，我為游戲畫面畫了兩個矩形，一個比例為 16:9，另一個比例為 16:10。然后游戲根據屏幕的寬高比在它們之間進行插值，并使用插值矩形作為視圖邊界。只要所有重要的游戲元素都在這些矩形的交叉點內，并且它們的公共邊界矩形不超出場景邊緣，就可以很好地工作。

Hapland 2 的 16:10 和 16:9 框，與原來的 3:2 不同。

色彩空間的問題

經過一些測試后，我發現 Flash 在感知空間而不是線性空間中進行 alpha 混合和顏色變換。這在數學上是可疑的，但另一方面我們也該知道，很多繪圖程序都是這樣工作的，你希望你的消費級工具按照人們期望的方式工作，雖然這對于數學家來說是一種冒犯。但是從根本上來看，這是錯誤的！它會導致諸如抗鋸齒之類的問題。

當你光柵化矢量圖形并要求抗鋸齒輸出時，光柵器將輸出 alpha 值，即所謂的「覆蓋值」。這意味著如果給定像素被矢量形狀半覆蓋，則該像素將以 alpha = 0.5 輸出。

但在 Flash 中，當某些東西的 alpha 為 0.5 時，這意味著它在感知上處于前景色和背景色之間的中間位置。

這完全不是一回事！

在不透明黑色像素之上繪制的半覆蓋白色像素不應是感知的 50% 灰色。這不是光的工作原理，也不是矢量光柵化的工作原理。光柵器不能在不知道背景顏色的情況下說「這個像素應該在背景和前景顏色之間感知 xx%」。

在感知 (sRGB) 空間中完成的混合。頂部：黑色透明白色；中間：白底透明黑色；底部：灰色在線性（物理上準確）空間中完成的相同混合。請注意，50% 的覆蓋率看起來與 50% 的灰色不同。

因此，我們的抗鋸齒光柵化形狀使用一種 alpha 定義，而我們的 Flash 導出的 alpha 透明度、漸變和顏色變換使用另一種定義。但是我們的渲染管道中只有一個 alpha 通道。那么渲染器應該如何解釋 alpha 值呢？如果它將它們解釋為感知混合因素，則半透明對象看起來是正確的，但一切的抗鋸齒邊緣看起來都是錯誤的。如果它將它們解釋為覆蓋率值，則反之亦然。有些東西總是看起來不對勁！

在此，我認為只有兩個嚴謹的解決方案：1) 設定兩個 alpha 通道，一個用于覆蓋，一個用于感知混合；2) 在沒有 AA 的情況下光柵化所有形狀，將所有內容繪制到一個非常大的幀緩沖區，然后通過過濾將其縮小。

我必須承認，這些設想都沒有獲得實踐。這些半透明的東西在 Flash 和游戲中看起來不對勁，我只是逐漸調整圖形直到游戲看起來沒問題。在 Flash 中的透明對象永遠不會完全符合我設計他們的初衷，但它們并不多，這也不是什么大問題。

為了確保其他一切都正確，我制作了一個「顏色測試」圖形，其中包含一堆不同強度的顏色、色調旋轉效果 10 等等，讓游戲顯示它，并確保它在 Flash 中運行正確。

變成了比較顏色的問題。

幀率

原始的 Flash 游戲標稱幀率是 24FPS，但實際上它們以 Flash Player 想要的任何幀速率運行。使用 Flash，你可能要求 24FPS 并得到 15FPS，或者要求 30FPS 突然得到 24FPS，這看起來一點也不嚴謹。

我想要把游戲重制成 60FPS，這意味著要在 Hapland 創作時期望以大約 24FPS 的速度播放這一事實動些手腳。Flash 的動畫工具基于離散的幀，而不是連續的時間。

我首先讓導出器將所有幀加倍，對于每個時間軸幀導出兩個幀，這就直接地把 24FPS 提高到了 48FPS，但仍然不是 60，需要的動畫仍然要快 25%。解決方法是老式的手工活：完整遍歷游戲，然后手動將額外的幀添加到現在看起來太快的動畫中。

至此，我們已對 Hapland 游戲進行了相當不錯的 C++ 轉換，肯定可以在現代計算機上運行至少再過一兩年。但我就是無法擺脫應該嘗試提供一些額外價值的感覺，所以加新活在所難免。除了重新繪制大量舊圖形和動畫外，我還進行了一些重大更改。

及時保存

我認為需要讓 Hapland 3 不那么讓人不知所措。這個游戲的關卡很長，有很多地方死掉了又得重新再來，也許這在 2006 年很有趣，但我們現在是成年人了，我們沒有時間這樣做。

保存狀態是模擬器該有的功能，如果你按下「保存狀態」，它會通過將控制臺的內存轉儲到文件中來記錄當前游戲的整個狀態。然后，如果你搞砸了，按下「加載狀態」，你就會回到要重試的地方附近。

在原始 Flash 游戲中實現保存狀態是不可行的，因為 Flash 不讓程序員訪問其整個狀態。但由于這次我使用的都是自己的代碼，所以這是可能的。

我有一個叫做 Zone 的東西，它只是一個分配器，將其所有內存分配到一個固定大小的塊中。所有場景節點都分配在當前區域內。為了實現保存和恢復，我只需要兩個區域，活動區域和一個單獨的「保存狀態區域」。為了保存狀態，我將活動區域 memcpy 到保存狀態區域。要加載狀態，我會以另一種方式返回 memcpy。

重復關卡

Hapland 的游戲時間并不是特別長，雖然一共有三個，但我們總是希望再想多給玩家幾個小時的游戲時間。因此我決定給每個游戲一個「Second Quest」—— 原關卡修改版，布局和謎題略有不同。制作這樣一個 Second Quest 比制作一個全新的游戲要省力，但仍能帶來一些額外的價值。

創建 Second Quest 意味著我需要在大約 15 年來第一次重新開始 Flash 解謎游戲開發，老實說，這感覺不錯。復古的 Flash 用戶界面很棒，按鈕都有邊緣，圖標是實物風格，空間也得到了充分的利用。

使用舊時代的 UI 讓我感覺自己就像一位考古學家，正在發現某種被遺忘的羅馬技術。失落的 UI 設計藝術，很整潔。

這是什么魔法？

盡管 Flash 的 bug 很多，速度也慢，還缺少一些極其基本的功能，但我基本上不討厭使用它，當然使用現代應用程序是更順手的。

為了防止第二個任務看起來與第一個任務太相似，它們需要有新的背景，整個場景也被水平翻轉了。

Hapland 3。

Hapland 3 的 Second Quest。

音樂

在 BGM 方面，我使用自己硬盤里的內容，并額外制作了一些音樂，為每款游戲制作了快速的環境配樂。有一次在日本度假時，我無緣無故地在山頂上進行了一次野外錄音，能夠將其用于某些事情真是太好了。我從互聯網上找到了一位音樂家來做標題屏幕音樂，并自己錄制了一些吉他和弦作為片尾字幕，它們淹沒在效果中，所以你不能說我吉他學得不好。

在工具上，我根據音樂使用 Logic 或 Live。我發現 Logic 更適合錄音，而 Live 更適合聲音設計。

成就系統

在 Steam 上，玩家總喜歡看成就，這一點不太好辦，成就的設置取決于游戲設計師的思路，但其實也沒什么大不了的。

把成就系統上傳到 Steam 是一件痛苦的事情，你不能只定義一個列表并將其提供給他們的命令行工具，而是必須費力地點擊 Steam 合作伙伴網站緩慢、令人困惑的 PHP 框架，然后將它們一個一個添加進去。

看起來，如果你是一家重要的大型游戲工作室，你就不必忍受這一點，他們為你提供了一個批量上傳工具，但我顯然不是其中之一。所以我查看了它構建的 HTTP 調用，保存了我的登陸 cookie，并編寫了我自己的文件。

幾次修改之后，我選擇了一組適度的成就：一個用于完成每個 Hapland 游戲，一個用于每個 Second Quest，還有兩個是解鎖更大的秘密。任何沒人能發現的愚蠢、晦澀的秘密都沒有成就，你一定要對發生的事情感到滿意。

Steamworks UI 下的成就系統。

Notarization 的問題

雖然我主要是在自己的 Mac 上開發游戲，但在開發的過程中蘋果發明了「Notarization」，如果你在新版本的 MacOS 上運行任何應用程序，它會向蘋果發出網絡請求，詢問應用程序的開發者是否向蘋果支付年費。如果開發者不支付年費，MacOS 會彈出一個對話框，強烈暗示該應用程序是壞的并拒絕啟動。

因此，Windows 將是該游戲的第一個，也許是唯一的發布平臺。

使用的庫

對于最終交付給最終用戶的軟件，我們通常希望將依賴性保持在最低限度，但使用一些高質量的軟件也是必要的。除了 OpenGL 和標準操作系統之外，這是 Hapland Trilogy 可執行文件最終鏈接到的完整庫列表：

• Steam SDK
• cute_sound
• stb_vorbis
• stb_image

結語

就是這樣，如果你把技術做對了，人們在打游戲時根本不會注意到背后是什么，所以有時候這會讓你想說：嘿，看看我做到了什么！