過頭來看這幾年的熱門作品，多平臺早已不是一件很新鮮的事。無論是單機作品還是多人聯機游戲，都在嘗試把自己推廣給更廣泛的玩家群體。這不僅僅是在說登陸多個主機平臺和 PC，還有上線安卓、iOS，以及云平臺。
就比如上個月剛在 Switch 上線的《寶可夢大集結》，馬上就會推出它的手機版本，并且支持存檔共通和跨平臺對戰，隨時隨地就能來一把。
在本屆 ChinaJoy 期間，Unity 正式推出了“跨端移植服務”，希望憑借自身的經驗和技術，助力開發者更好地跨平臺開發游戲。
沒有這項服務之前，開發者不是照樣在做多平臺開發嗎？這項服務又能帶給開發者或廠商哪些便利？帶著這些疑問，我去采訪了 Unity 大中華區跨端移植技術負責人孫志鵬和 Unity 大中華區業務總經理肖蓓蓓，和他們聊了聊跨平臺移植這回事。
如果把時間放到十年以前，若是提到跨平臺移植，人們大多數的反應或許是游戲在幾個主機平臺和PC之間互相移植。畢竟幾個平臺的性能相對接近，玩家的體驗也能夠得到保證。
但很明顯伴隨著智能手機的興起，近幾年的風向有了變化，越來越多的開發者開始將移動平臺作為自己的選項之一，例如《爐石傳說》、《人類：一敗涂地》，甚至有不少游戲是先在移動平臺發布，再登陸主機/PC平臺，比如《帕斯卡契約》。
在訪問中，孫志鵬就表示移動平臺向主機/PC移植將會是未來非常重要的趨勢。
究其原因，首先是技術壁壘的打破，在手機與主機的性能逐漸縮小的情況下，跨平臺的限制只會越來越少；第二點是基于 IP 的考量，移動平臺成就了很多 IP，而為了打造 IP，觸達更多的玩家，最好的方式之一便是通過跨端，滿足消費者在各個平臺都能玩到的需求。
此外，次世代主機 PS5、Xbox Series X|S，以及云游戲平臺等等興起的新平臺都仍在初期階段，亟需足夠的內容來填充平臺的陣容。現在正是搶占先機的時候。
多平臺的好處是顯而易見的 —— 登陸的平臺越多，自然能觸達更多的玩家。誰不希望自家的游戲在全部的平臺都能掙上錢呢？盡管說得好聽，但要怎么實現，依舊是每位開發者需要反復思考的問題。
“一個游戲是否能（取得多平臺的）成功很大程度還是取決于本身的內容。”肖蓓蓓認為優秀的內容和創意的玩法不管是在高端的主機平臺還是移動平臺，都能給玩家帶來非常優質的游戲體驗，這樣才能夠收獲粉絲。
適配不同平臺的特性也非常重要。暫且不論諸如 PS5 的自適應扳機、次世代主機的高速 SSD 等差異化內容，單說交互方式的差異 —— 手柄、觸屏、鍵鼠，就意味著開發者在開發階段需要提前確定好多套操作邏輯。
一款豎屏操作的手游很明顯不能直接搬到主機和 PC 上。廠商肯定要有針對地進行適配，與之對應的 UI 也要與所屬平臺相匹配。《仁王2》PC 版就因為發售初期缺乏鍵鼠 UI 收到了不少差評，這應當給不少開發者/廠商敲醒警鐘。
想不想做，和能不能做，是兩個問題。
在采訪過程中，孫志鵬提到很多開發者都表達過跨平臺的想法，但最終又沒法做出這個決定。
一方面是人才的問題，國內主機平臺的人才畢竟還是太少了，另一方面是風險的考量，哪怕廠商能夠搭出這個團隊，投入了許多，結果還是可能收不回成本。對中小型團隊來說，這兩點尤為關鍵。
Unity 能做的，正是為游戲開發團隊提供專業的技術團隊，以及幫助他們降低成本。所以他們推出“跨端移植服務”，希望讓開發者有機會實現游戲的全平臺。
具體來說，Unity 會直接把自己的技術人員派到廠商那里，讓他們作為開發團隊的一部分，共同完成多平臺移植工作。
在協助移植的過程中，Unity 注重“授人以漁”，以一套“工業化、規范化、標準化的流程”，把缺乏技術和經驗的團隊帶上軌道，從而減少開發者本身的試錯成本。
我們（Unity）全新發布的跨端移植服務，是能夠在你（游戲開發者）想做但決心又沒有那么大的時候，為你提供嘗試的機會，因為和我們合作不僅成本比較低，我們做這件事也很專業。
相當于我們的專業團隊可以成為大家的開發者未來的主機團隊的雛形……也許當你考慮將來要不要自己搭一個主機團隊的時候？跟著我們做，說不定我們能幫助你帶出一些你的技術人才。
而在技術以外，Unity 憑借和幾家主機廠商的合作關系（以及像Steam這樣的商店），也能夠讓游戲在后續的測試、評審、上架審核少走一些彎路。
若游戲之前就是用 Unity 開發的，那這項服務自然是錦上添花。但倘若游戲最初并不是用 Unity 開發的，是不是意味著與 Unity 的跨平臺移植無緣了呢？
對此，孫志鵬表示 Unity 正在考慮支持更多的腳本語言，通過一些工具方便開發者將此前用其他第三方引擎開發的游戲移植到 Unity 中，甚至是實現自動化地一鍵轉換。這之后再借助 Unity 的跨平臺性能去做移植。
同時，他也聊了聊 Unity 和其他引擎在跨平臺移植上的優劣勢。孫志鵬強調 Unity 作為一款通用工具，會在兼容性和泛用性上更勝一籌。
在采訪過程中，孫志鵬沒有避諱推出這項服務的目的： “這樣子 Unity 的開發者就變多了”。工具是越用越好的 —— 隨著越來越多的開發者去迭代自己手中的開發工具，Unity 在跨平臺的適配性上就會越來越好。
也就是說 Unity 希望憑借這項服務，把自身的主要競爭力之一 —— 「方便且較低成本地跨平臺」推廣出去，也以此來不斷迭代 Unity 引擎本身。從這一點來看，無論是對開發者還是 Unity，這都是一項雙贏的服務。
于玩家的角度來說，能接觸到更多的游戲，能選擇適合自己游玩的平臺，多平臺的發展趨勢總歸是不錯的；于開發者的角度來說，如采訪所提到的，國內能做主機開發的人才畢竟還是太少了，Unity 提供一套行之有效的規范化開發流程，最起碼能讓部分開發者少經歷一些坑，更有機會實現自己的想法。
這些對整個游戲行業而言，都是好事。
GameLook 報道/
隨著 Unity“下載收費”烏龍越鬧越大，不少同行都已經在著手尋找替代引擎。那么，其他的選項到底好不好用呢？
最近，一位獨立游戲開發者在 GD 博客中分享了他將自己的游戲從 Unity 切換至 Godot 的引擎，并且表示整個過程只用了一個周末。
以下是 Gamelook 編譯 GD 的完整內容：
作為《Oni Hunters》、《Minimon》系列的創作者，我在過去十年里看到了游戲研發領域的急劇發展，從我們大多數人都有內部引擎的舊時代，到 Unity 成為獨立游戲領域引擎王者的現代，研發工具一直在變化。
周末的時候，我完成了一個具有挑戰性的任務，將我最新的游戲從 Unity 移植到了 Godot 引擎。接下來介紹一下其中的方法、原因，以及學到的經驗：
為什么要選擇 Godot？
多年來，Unity 對我們很多人都是很有幫助的。然而，他們最近決定追溯性地改變服務條款（TOS），尤其是早期做出與開發者對立的保證之后，嚴重侵蝕了包括我在內的許多開發者對他們的信任，迫使我們不得不尋求替代方案。
再來說 Godot，這是一個對 C# 語言支持很好的新星。作為一個完全的 Godot 新手，我非常好奇自己的 Unity 使用經驗如何能夠轉變過來。
快速移植背后的“魔法”
把一個完整的游戲只用一個周末的時間移植到另一個引擎上？看到這里，我可以想象到很多同行驚嘆的深呼吸聲。
尤其是考慮到《Oni Hunters》的規模，它有著 10 年的歷史，4GB 的龐大包體，包含近 3000 個資產（sprites、音頻、地圖等），以及 500 多個 C# 腳本。聽起來是不是幾乎不可能？但是，有一種方法可以解決這個幾乎算是瘋狂的問題，有一個“秘籍”使一切成為了可能。
這個秘密存在于引擎抽象層（abstraction layer）。在過去，我經常被棘手的移植經驗所折磨，我對《Oni Hunters》的未來持堅定態度。通過將 Unity 特定的 dependencies 限制為 3 個源文件和一個整潔的場景架構，就為無縫移植體驗奠定了基礎。這可能并不會對所有人適用，但對于像我這樣聚焦 2D 復古型游戲的開發者來說，簡直是一座省時間的潛在金礦。
如本質上講，我的策略主要是創造自己的 API，這是個位于我的游戲和引擎之間的保護層，使我的游戲邏輯與任何引擎的細節分隔開來。簡單地說，這就像是為你游戲的需求量身定制的一個自定義界面。以 2D RPG 游戲為例，這個 API 將包括簡單的 Methods，例如 LoadMap（）、CreateActor（）、StartBattle（）等等。
對于資產方面的事情，我使用 Tiled 在 Unity 之外制作地圖，使它不需要引擎調用。對于像 Sprite Sheet 這樣的東西，我確保每一個都遵循特定的尺寸習慣，這使得自動將它們分割成單獨的幀并使設置動畫變得簡單。
我看到這種方法在游戲研發圈子里有不同的名稱，比如“代碼驅動的研發”、“場景極簡主義”或者“Runtime 場景生成”。其要點是，保持 Unity 場景大部分為空，然后通過 C# 腳本驅動大部分游戲邏輯和內容。當你繼續利用 Unity 的核心功能時，重點將從編輯器稍微偏移。盡管如此，編輯器對于實時檢查和修改仍然是至關重要的。
雖然這個方法需要提前的時間和規劃投入，但它在長期范圍內帶來的靈活性和獨立性是無價的。無論一個引擎在行業內的嵌入有多深，只要有了對的抽象，我的游戲就可以保持自由和靈敏，我知道這不是一個適合所有人的方法。
深入了解 DIY 解決方案
現在，可能會有一些人反問，“Unity 給我們帶來的那些不錯的功能怎么辦？”我相信會有很多人問這個問題，接下來我們來談談。
碰撞檢測（Collision detection）？在 2D 游戲世界里，相交的線、圓和長方形背后的數學運算都非常直接簡單，除非你的游戲需要大量的物理模擬（否則是用不到這個功能的）。
粒子系統？在像素風游戲里，依賴手繪粒子效果很常見，它們由美術師創作，并且無縫集成到動畫幀當中。
尋路（Pathfinding）？像A*這樣的經典算法可以在大約 50 行 C# 簡潔腳本中快速生成。
GUI？很多大程度上取決于游戲，但很多獨立游戲對于真正復雜的 GUI 并沒有需求。另外，如果你已經做到了從引擎抽取 sprite，那么在此之上打造一個基礎的 GUI 也是可行的。
這個列表還可以很長。有些時候，獨立游戲開發者可能視為必備“引擎功能”的東西，通常都是可以被一系列的創意所取代的，而且往往比我們認為的更容易。如果你能確保代碼良好的抽象性，你可以繼續在未來所有的項目上使用。
Godot 指南：一個獨立游戲開發者的第一步
對于那些像我一樣的 Godot 新手，我們先拆解一些基礎東西：
場景與節點（Scenes & Nodes）：想象你的 Unity 場景充滿了游戲物體。在 Godot 中，主要是帶有節點的場景，尤其是 2D 游戲的 Node2D，這是非常相似的。
最重要的 Methods：_Ready 和_Process 相當于 Unity 的 Start 與 Update。
2D Sprites：Sprite2D 已經涵蓋了。
處理輸入：只要輸入_Input Method 即可。
音頻：AudioStreamPlayer 用起來非常簡單。
我遇到最主要的麻煩是程序化音頻，這是我使用很多的功能，既用于音樂合成播放，也用于隨機怪物音效。雖然 Unity 提供的 OnAudioFilterRead 深得我心，但 Godot 也提供了一個叫做 AudioStreamGenerator 的東西，雖然我在使用的時候遇遇到了一些問題，但對于尋找動態化音頻解決方案的人來說，它還是很好用的。
這個列表主要是根據我移植《Oni Hunters》的需求列出的，你自己的需求可能與上面的差別很大。
Godot 是很有前景的，但它也并不完美。我在 4.1 版本嘗試的 AudioStreamGenerator 就是證明。幸運的是，這時候我們可以用開源社區的能力。經過一番調查，我找到一個能解決該問題的 PR，打造了我的定制化 Godot 版本，隨后就再也沒有遇到音頻制作的問題了。想要告訴那些害怕從源頭打造移植版的人：它用起來比你想象的更簡單，只要嘗試一下 Godot 的資料文檔就行，他們對每一個必要步驟都有很好的資料文檔解釋。
總結
Godot 可以當做新的 Unity 嗎？目前還不太行，它有著自己的魅力和優勢，例如可以獲得完整源代碼。但也有一些需要追趕的地方。比如，Godot 的 Profiler 并不支持C#，即第三方 .NET 分析工具是必備的。可盡管有這些不方便，我也可以確定的說，Godot 正在成為獨立游戲開發者越來越靠譜的選擇。
而且，我還看到了性能方面的一些增強。這可能是因為 Godot 使用了 .NET 6，而 Unity 仍在使用 Mono 舊版本。
從 Unity 切換到 Godot 是一個具有啟發意義的過程，我很高興看到了 Godot 的未來走向。雖然它不可能成為所有人的 Unity 替換引擎，但至少對于那些愿意擁抱新事物的獨立開發者是令人興奮的，敬我們更多的嘗試和在充滿活力的獨立游戲開發者社區分享精神！