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

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

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

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

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

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

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

一些失敗的經(jīng)驗

失敗的嘗試 1:

我嘗試的第一件事是讓 Flash 將游戲?qū)С鰹榭蓤?zhí)行文件，但失敗了，因為它的性能與 2005 年一樣糟糕。我想制作一個以當代幀速率運行的東西。我想擺脫 Flash Player。

失敗的嘗試 2:

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

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

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

計劃

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

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

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

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

光柵化矢量

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

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

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

Flash 以 XML 格式存儲矢量圖。你可能會說， XML 不是圖形數(shù)據(jù)的一種糟糕選擇，但你畢竟不是 Macromedia 的產(chǎn)品經(jīng)理?？纯催@個：

在 .fla 文件中看到的矢量數(shù)據(jù)。

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

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

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

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

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

來自 Hapland 3 的圖例集。

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

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

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

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

我在這里想到了寫入?yún)R編列表而不是直接寫入二進制文件，我很喜歡這一點。沒有 CPU 指令，只有數(shù)據(jù)，這讓調(diào)試更容易，因為我可以查看匯編文件以查看生成的內(nèi)容，而不是在十六進制編輯器中瀏覽字節(jié)。

輸出.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

你更愿意調(diào)試哪個？

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

1) 匯編程序已經(jīng)存在；

2) 我不是必須調(diào)試它們；

3) 它們支持標簽。

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

場景圖

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

我將場景存儲在內(nèi)存中，作為一棵節(jié)點樹，每個節(jié)點都有一個變換，可以自行繪制并接受鼠標點擊。每個具有自己行為的游戲?qū)ο蠖际瞧渥约侯惖膶嵗?，派生?Node.js?！该嫦?qū)ο蟆鼓壳霸谟螒蜷_發(fā)圈子里并不流行，但我使用的是 Flash，所以顯然不關(guān)心這個問題。

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

框架腳本

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

一個簡單的幀動作。

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

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

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

需要指出的最后一件事是腳本系統(tǒng)最終是某種靜態(tài)類型的，這有點難受。游戲輸出的最終游戲?qū)ο笕缦滤荆?/span>

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

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

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

縱橫比

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

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

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

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

色彩空間的問題

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

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

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

這完全不是一回事！

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

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

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

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

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

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

變成了比較顏色的問題。

幀率

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

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

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

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

及時保存

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

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

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

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

重復關(guān)卡

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

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

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

這是什么魔法？

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

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

Hapland 3。

Hapland 3 的 Second Quest。

音樂

在 BGM 方面，我使用自己硬盤里的內(nèi)容，并額外制作了一些音樂，為每款游戲制作了快速的環(huán)境配樂。有一次在日本度假時，我無緣無故地在山頂上進行了一次野外錄音，能夠?qū)⑵溆糜谀承┦虑檎媸翘昧恕Ｎ覐幕ヂ?lián)網(wǎng)上找到了一位音樂家來做標題屏幕音樂，并自己錄制了一些吉他和弦作為片尾字幕，它們淹沒在效果中，所以你不能說我吉他學得不好。

在工具上，我根據(jù)音樂使用 Logic 或 Live。我發(fā)現(xiàn) Logic 更適合錄音，而 Live 更適合聲音設(shè)計。

成就系統(tǒng)

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

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

看起來，如果你是一家重要的大型游戲工作室，你就不必忍受這一點，他們?yōu)槟闾峁┝艘粋€批量上傳工具，但我顯然不是其中之一。所以我查看了它構(gòu)建的 HTTP 調(diào)用，保存了我的登陸 cookie，并編寫了我自己的文件。

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

Steamworks UI 下的成就系統(tǒng)。

Notarization 的問題

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

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

使用的庫

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

• Steam SDK
• cute_sound
• stb_vorbis
• stb_image

結(jié)語

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