為拯救童年回憶,開發者決定採用古法程式設計:用Flash高畫質重製了一款遊戲

實踐證明,Flash 實在太糟糕了,為了重製遊戲甚至要重寫一個 Flash 播放器。

兩年多前,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」 是幀動作

時間軸中的小 「a」 是幀動作。

幸運的是,.fla 檔案只是 XML。我只需要解析它,將相關資料匯出為簡單的自定義格式並編寫一個播放器來讀取它、繪製場景、處理輸入並運行動畫。

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

光柵化向量

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

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

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

Flash 以 XML 格式儲存向量圖。你可能會說, XML 不是圖形資料的一種糟糕選擇,但你畢竟不是 Macromedia 的產品經理。看看這個:

在 .fla 檔案中看到的向量資料

在 .fla 檔案中看到的向量資料。

我不是在抱怨,這讓我的工作更輕鬆了。

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

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

渲染這些 PNG 後,匯出器會將它們組裝成地圖集?並沒有,它只是按高度對所有內容進行排序,然後像文件中的文字一樣逐行排列。這遠非最佳,但已經足夠了。

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

來自 Hapland 3 的圖例集

來自 Hapland 3 的圖例集。

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

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

用匯程式設計序編寫二進位制檔案

匯出器將動畫資料寫入自定義二進位制格式。它只是逐幀通過時間軸,並寫出每一幀的所有更改。

我在這裡想到了寫入彙編列表而不是直接寫入二進位制檔案,我很喜歡這一點。沒有 CPU 指令,只有資料,這讓調試更容易,因為我可以查看彙編檔案以查看生成的內容,而不是在十六進位制編輯器中瀏覽位元組。

輸出.bin

13 92 49 EC : BD 31 E8 FF09 DD BE DE : C9 5A 1D 363F C0 4E 31 : 52 FD 41 C68B 5D C0 20 : 19 1F 5F 1F54 97 8C 27 : 34 1F 30 EAA9 A9 E0 55 : 40 29 A3 1989 BC 5F 24 : 3A 98 FD B9DE 15 F2 D4 : 2A B7 41 2C4E 9D 37 D9 : E2 13 4B 0136 3F 40 08 : AC 3C FF 84E9 AE C5 2C : 11 2F 69 CF63 CE 85 D1 : A7 CB B1 1A5F 5B 60 1A : 77 99 71 B060 6E C4 C7 : 73 1F EA 1F31 0D 0C 39 : B0 86 70 42

輸出.asm

; Left Sidetimeline_132:; --- Left Side, Frame 0 ---.frame_0:; --- Left Side, Frame 0, Layer 22 ---db Quaddd 0.152926, 0.162029, 0.184475, 1.000000 ; colordd 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 Shapedw 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。

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

結語

就是這樣,如果你把技術做對了,人們在打遊戲時根本不會注意到背後是什麼,所以有時候這會讓你想說:嘿,看看我做到了什麼!

參考原文:

https://foon.uk/how-flash-2022/

https://news.ycombinator.com/item?id=34079543

相關文章

Adobe 公司將終止支援 Flash

Adobe 公司將終止支援 Flash

今天機哥要講一件大事:Adobe 公司今天宣佈,將於2020年12月31日,正式終止支援 Flash 。 簡單來說,陪伴我們走過 24 個年...

福布斯:2022 區塊鏈 50 強榜單

福布斯:2022 區塊鏈 50 強榜單

區塊鏈已經走了很長一段路了!自 2019 年首次發佈區塊鏈 50 強以來,福布斯年度榜單上的十億美元級公司 (按銷售額或市值計算至少是十億美...