大量運行 Unity Headless Player 遭遇的坑

Unity 支援將專案輸出為 Linux 平台上以 Headless 模式運行的 Player。Headless 指的是沒有圖形環境 (Ex: 沒有執行 X-Server)、甚至沒有接螢幕的電腦。通常放在機房中代管的伺服器、或是雲端平台上租用的虛擬主機都是以 Headless 的方式來運行。Headless Player 在應用上除了可利用來製作簡單 Server 程式之外，也可以用來製作「特殊的」客戶端版本，例如開發線上陪玩的 BOT 機器人、或是功能測試機器人等等，這麼做的考量點通常是想最大程度地共用既有的客戶端程式碼。

當我試著要在一台 Linux 機器上大量跑 Headless Player 時，總會發現運行到 170 ~ 180 隻後，系統就會開始出現無法 fork 的錯誤訊息，甚至整個系統都被癱瘓無法做事。就算是空的 Unity 專案也會有這個現象，因此懷疑一部分的原因出在 Unity 本身。

免費且快速地搞定 HTTPS 環境 (非自簽憑證)

遊戲營運後端免不了要跟 Web API 打交道。呼叫第三方的 Web API 是最常見的，另有少數場合必需提供簡易的 Web API 接口讓第三方查詢營運數據、或是使用第三方服務必需提供的 Webhook等等。這幾年，尤其是在 Apple 帶頭打壓  iOS 裝置上的 HTTP 的使用後，感覺要求全面以 HTTPS 來溝通的第三方服務日漸增多。其中不乏也有跟 Apple 一樣，完全不接受「自簽署 (Self-Signed) 憑證」的情況。如果對於 URL 中的域名長相並不在意 (例如說只是要提供 Webhook)，這裡倒是可以分享一下怎麼快速的搞定這類需求。

C/C++ 靜態函式庫中的全域變數暗藏的陷阱

Windows 平台上使用靜態函式庫時，對比其它類 Unix 平台如 Linux, BSD, Mac 等，存在一個關鍵的差異: Windows 上一個靜態函式庫在同一個程序空間 (Process space) 被 N 個程序模組 (exe, dll) 引用時, 會產生 N 份獨立的全域變數空間。而同樣的情況在其它類 Unix 平台上則是會共用同一份。

處理阿拉伯文繪製的心得

先澄清一點，我本人對阿拉伯文是半點不懂的。

我參與的第一款手遊使用的是自製的成像引擎。內部使用了 FreeType2 來繪製 TTF 文字、實現勾邊/陰影等。開發初期只有考慮橫式由左至右書寫文字的排版方向。產品上線後不知誰給老闆進的讒言說中東地區的玩家所得高、含金量高，若遊戲內語言能支持阿拉伯文肯定有錢景。於是乎就有了以下的研究與實作，提供給大家參考。(註: 最終還是沒有在中東地區上架，因為接洽不到當地營運夥伴)

在桌機中準備 OpenGL ES 的開發環境

大約在 2013 年中，公司的產品方針由桌機網遊轉變為手遊。由於當時還是採用自製的呈像引擎所以立刻要處理的就是把 Render API 切換為手機上通用的 OpenGL ES 2.0。

雖說手機遊戲最終是運行在手機上，但是為了方便開發和測試，遊戲也必需能在一般的桌機上運行。這一點在現今 Unity 稱霸的時代已經是很基本的需求，但對於當時一切 DIY 的我們來說還算是一項考驗。那時負責呈像的同仁拋出了兩個方案 -- 一是只在手機上使用 OpenGL ES API、桌機環境上維持使用既有的 OpenGL API；二是無論如何都使用 OpenGL ES API，桌機環境上去找 OpenGL ES Emulator 來提供 OpenGL ES 的支持。最後考慮到維護成本採取的是後者，這樣只需要統一維護 OpenGL ES 的部分即可。

Emulator 與 Simulator 傻傻分不清楚

Emulator 跟 Simulator 這兩個詞，Google Translate 給出的中文翻譯都是「模擬器」。然而它們並不是同義詞，至少在資訊工程的領域不是。尤其是每當有新的硬體平台發表時，開發者們都會很關切一件事 -- 它對桌面環境的開發者提供的是「Emulator」還是「Simulator」? ? 這兩者帶開發者的痛苦程度不太相同。

「Emulator」通常意指的是「同質性的模擬」，而「Simulator」則是「表像上的模擬」，通常也暗示者「異質性的模擬」。有同時開發過 Android 與 iOS 平台的朋友們一定都知道是怎麼回事 -- Android 對開發者提供的 Virtual Device 就是「Emulator」，設定 Virtual Device 時可以選擇 ABI，如果選的是 ARM，那 Emulator 中就真的是跑 ARM 的指令集。反觀 iOS 對開發者只有提供「Simulator」，它實際上運行的是 x86 的指令集，跟真實的 iOS 裝置上使用的指令集完全無關，所以稱為「異質性的模擬」。

最近正在進行某 N 社平台的移植工程，該社的開發機供不應求有價無市，除此之外對開發者只提供「Simulator」 -- 而且與實機環境的差異還蠻大的。有感而發。

重拾筆頭

算一算離上次發表文章，竟已有四年半的時間了。回顧這幾年，大部分的時間都耗費在公司手遊的研發上，雖有陸續在日、港、全球上線營運，但成績始終未達預期。產品的細節礙於公司規定是不便多說的。但技術上積累了不少可分享的心得倒是想陸續發上來。

還記得 2012 年我剛從電子業轉換跑道進這行時，面試我的上司問我為什麼要轉行? 我那時候回答他，我認為遊戲產業是「最多種不同面向的技術同時交匯的產業」，所以我覺得這裡的挑戰最多元、身為資工出身的我能貢獻最多，並且也能學到最多東西。四年半之後回顧初衷，還真是一點也不錯，一路走來果真挑戰連連，常常得面臨一關闖不過就要鳥獸散的窘境。雖不敢說對某門技術功力很深，但盡力要求自己各項都要摸要懂，漸漸地也常感受到觸類旁通的領悟。

雖然遊戲開發會粗略分為 Client 與 Server 兩種人員，但小團隊裡通常壁壘不會這麼分明，反而是靠部分通才人員兩邊一起顧。我在開案時最初擔任的是 Server 的架構及開發，最終上架時已經要兼顧一部分 Client 的功能、Client 端第三方 SDK 串接，以及幾乎所有營運後台需要的工具了。試想像還有哪個行業會同時磨練你 3D呈像、美術製程、各種 mobile 平台、Socket Programming、RESTful WEB API、Database (SQL and NoSQL)、雲端平台的背景知識呢? 當時的產品 Client 端甚至還是採用自有的引擎而非 Unity，那陣子承受的壓力與成長幅度都是我人生中的高峰。

很感謝身邊幾位才華洋益的同伴一起打拼，有些驚險關卡想在回想起來還冒冷汗。但受用最多的還是網路上搜尋到的各種技術內容探討、心得分享。這也是我要求自己把心得發佈上來的主因。

敬請期待。