告訴別人「我用遊戲引擎做影片」的時候，對方通常會問「你在做遊戲？」。不是。我沒有在做遊戲，我只是需要一個東西幫我把畫面一張一張畫出來，而遊戲引擎剛好是全世界最會做這件事的軟體。它們每秒畫六十張圖畫了三十年，只是通常沒有人叫它們把圖存下來。
用程式自動產生影片，最後總要有東西把畫面畫出來、再把畫面編成檔案。我用的是 Godot 4.7 和 FFmpeg 9.0。Godot 是 MIT 授權的遊戲引擎，它的 Movie Maker 模式可以以固定的幀率逐幀輸出圖片，不受即時效能影響；FFmpeg 是幾乎所有影音工具底下都有的那個編碼器，你手機裡的剪輯 app 很可能就是它在工作。兩個都放在專案目錄裡的可攜版，沒有安裝程式，沒有動系統 PATH。
為什麼是遊戲引擎
一開始我試過用瀏覽器畫，也試過用 Python 的繪圖函式庫一張一張畫。都可以，但都少了一些東西：場景樹、相機、圖層、動畫曲線，這些遊戲引擎裡理所當然的東西，在別的工具裡要自己搭。Godot 給你一整套，而且它的 2D 系統是認真做的，不是 3D 引擎順便附的。
Movie Maker 模式是關鍵。一般遊戲引擎為了即時，畫不完的那一幀會跳過；Movie Maker 模式反過來，每一幀都等它畫完才存，所以慢的電腦只是花更久，不會掉幀。輸出是確定的，同樣的場景跑兩次，逐幀相同。
下載時驗雜湊，Godot 還驗簽章
Godot 的 GitHub release 提供每個檔案的 digest，Windows 的執行檔另外帶程式碼簽章，可以用 PowerShell 的 Get-AuthenticodeSignature 檢查。FFmpeg 官方不提供 Windows 建置，常見的是 Gyan 或 BtbN 的建置，前者公布 SHA-256。把雜湊釘在下載腳本裡，既有檔案不符就停止，不覆蓋。
驗證不只是檔案對得上。Godot 要能匯入專案並算一幀，FFmpeg 要能用 libx264 編碼、ffprobe 要能讀、整支影片要能完整解碼。第一次安裝跑完這一輪，之後每次換版本再跑一次。這有點像新買的鞋要先在家裡走兩圈，確定不會磨腳才穿出門。
Movie Maker 會無視你的解析度
這個坑我一定要講，因為它讓我懷疑自己眼睛壞掉。
Godot 的視窗大小是專案層級的設定，Movie Maker 輸出的解析度跟著它走。你在命令列或腳本裡指定的尺寸不一定生效，我碰過要 1280×720 卻拿到 1920×1080 的情況。檔案打開，畫面是對的，內容是對的，就是尺寸不對，而我的驗證程式很盡責地拒收。我把參數改了三次，每次都一樣，開始懷疑是不是 FFmpeg 偷偷放大了。
可靠的做法是每個算繪工作一份私有的專案設定，把視窗尺寸覆寫進去。輸出完用 ffprobe 驗一次尺寸和幀率，不要相信自己的參數。參數是你的願望，ffprobe 是現實。
可攜模式的兩個目錄
Godot 執行檔旁邊放一個 _sc_ 檔案就進入可攜模式，編輯器設定留在自己的目錄。但 Windows 上的 user:// 另外要由環境變數導向你指定的位置，否則它會寫到使用者設定檔底下的 AppData。第一次匯入專案時它仍然會在那裡留下一個快取，之後就不再寫入。「可攜」在 Windows 上永遠是一個相對的概念，總會有什麼東西想住進 AppData。
算繪通常不是瓶頸
幾百幀的 1080p 片段，Godot 算繪是幾十秒的事。加上三層視差背景之後時間幾乎不變。在一條有語音合成的流程裡，真正慢的是配音，算繪可以忽略。這件事讓我對「效能優化」有了新的認識：先量哪裡慢，再決定優化哪裡，不然你會花一個週末把一個佔 3% 時間的東西快了一倍。
Godot 也能拿來烘焙東西。自製的粒子特效先在 Godot 的相容模式算繪器裡播放一次，逐幀讀回成圖片序列，之後依時間表合成到各段畫面上。只要特效的亂數種子固定，三次烘焙逐幀相同。
小劇場：那你會做遊戲嗎
「所以你學會 Godot 了，會做遊戲嗎？」
「不會。我只用了它的 2D 場景和 Movie Maker，遊戲需要的輸入、物理、UI 我一樣都沒碰。」
「這不是很浪費嗎？學了一個遊戲引擎只用一小塊。」
「用電鍋煮飯也只用了它的一小塊功能，沒有人會說浪費。」
「電鍋沒有那麼多功能。」
「你沒看過說明書。」
FFmpeg 的角色刻意很小
FFmpeg 只做兩件事：把畫格序列和音軌編成影片，以及在驗收時解碼整支影片確認沒有壞幀。它能做的事多到可以寫一本書，但我只用兩個指令，而且那兩個指令抄在便條紙上。
授權要看建置：FFmpeg 本身是 LGPL，帶 x264 的建置是 GPL。在本機用它產出影片，成片不受影響；哪天要散布這個執行檔或整套工具，才要處理它的授權。有些動畫工具自帶影片輸出器，會多帶一份 FFmpeg 進來，我一律讓它們只輸出圖片，編碼統一交給同一份 FFmpeg，少一個要查授權的二進位，也少一個「兩份 FFmpeg 版本不同編出來的檔案不一樣」的靈異事件。
為什麼是 Godot
我需要一個能用程式控制、能無頭執行、輸出確定性畫格、授權乾淨的算繪器。Godot 是 MIT，這些條件都符合。它的 2D 能力對動態漫畫、圖解、紙偶和場景視差夠用，我沒有用到它的 3D 和物理。工具比需求大很多，不用的部分不會妨礙你。
至於「你在做遊戲？」這個問題，我現在的回答是「算是在做一種只有一個結局、玩家不能操作的遊戲」。對方通常會笑，然後不再追問，這樣就夠了。
兩個工具的來歷
Godot 的名字來自貝克特的荒謬劇《等待果陀》，兩位作者 Juan Linietsky 和 Ariel Manzur 說，引擎永遠在等待某個功能完成，就像劇裡那兩個人永遠在等果陀。他們在阿根廷做了很多年的商業引擎，2014 年決定以 MIT 授權開源。2023 年的 4.0 版換了新的算繪器，4.x 系列之後的進步速度很快，現在有自己的基金會，不隸屬於任何公司。這一點對它的長期可靠性很重要：沒有一間公司可以某天決定改授權。
FFmpeg 是 Fabrice Bellard 在 2000 年開始的，這個人是軟體圈的傳奇，QEMU 也是他寫的，還有一個小到不可思議的 C 編譯器，還曾經用桌機算圓周率破過世界紀錄。FFmpeg 現在幾乎是所有影音處理的地基：你用的剪輯軟體、串流平台、影片轉檔網站，底下多半是它。它的命令列參數多到嚇人，ffmpeg -h full 印出來有幾千行，但日常用的就那幾個。
常見的三個誤會
第一個誤會是「Godot 只能做遊戲」。它是一個場景圖加算繪器加腳本語言，做什麼都行。有人拿它做 UI 工具、做視覺化、做互動裝置。做影片只是其中一種不太常見的用法。
第二個誤會是「FFmpeg 很難」。它的參數很多，但 90% 的情況只要記三個：輸入、編碼器、輸出。ffmpeg -framerate 24 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p out.mp4 這一行可以應付大部分「圖片序列變影片」的需求。難的是那 10% 的情況，而那 10% 你可以查。
第三個誤會是「用 GPL 的 FFmpeg 編出來的影片有授權問題」。沒有。GPL 管的是程式，不是程式的輸出。你用 GPL 的 GIMP 修的照片、GPL 的 Blender 算的影片、GPL 建置的 FFmpeg 編的檔案，都是你的。要注意的只有散布那個程式本身的時候。
一個週末可以試的小練習
下載 Godot 4 的可攜版，建一個空專案，放一個 Label 節點寫幾個字，加一個 Tween 讓它從左邊滑到右邊。存檔。然後不要在編輯器裡按播放，改用命令列：godot --headless --path 專案目錄 --write-movie out.png --fixed-fps 24 主場景.tscn，跑幾秒後 Ctrl+C。你會得到一堆編號的 PNG。
接著用 FFmpeg 把它們編成影片，就是上面那一行。用 ffprobe out.mp4 看尺寸、幀率、時長。這一小時你就走完了整條鏈：場景、逐幀輸出、編碼、驗證。如果你想體驗那個解析度的坑，去專案設定把視窗尺寸改掉，再跑一次，看輸出的 PNG 有沒有跟著變。
後記
「一種只有一個結局、玩家不能操作的遊戲」這個說法，我後來越想越覺得準確。影片本來就是這樣，觀眾沒有選擇，只能看你決定的那條路。用遊戲引擎做影片的好處是，你在做的過程中隨時可以「玩」它，改一個參數、跑一次、看結果，那種即時的回饋是傳統剪輯軟體給不了的。至於等待果陀，我每次等算繪的時候都會想起這個名字，然後覺得取得真好。
留言（0）
還沒有留言。讀完有想法，歡迎留下第一則。