替 Endless Space (萬艦穿星) 做的繁中漢化

最近一個月都沉浸在 Endless Space 2 的世界裡無法自拔。二代的遊戲內容已全面支援繁體中文，遊玩上的帶入感確實比起一代強烈得多。

一代雖然也有由玩家社群貢獻的中文漢化補丁，但簡體中文的部分比較完整，至於繁體中文的部分目前似乎只有一個 codebay.in 的繁中漢化包，而且只支援主程式，並不支援資料片 Disharmony。

上上週末突發異想，干脆自己跳進去嘗試補完一代繁中漢化的部分。雖然我還沒有任何遊戲漢化的經驗，但我知道 Endless Space 是用 Unity 開發的，這引擎我倒算熟悉。於是乎報紙捲一捲我就上山打虎去了。

原本預想的很單純 -- Endless Space 內的所有字串表都是以 XML 的格式獨立存放在遊戲目錄下，未有任何保護。而 Unity 自 3.x 版本起就已支援動態文字繪製 (Dynamic Font)，所以我預期只要把遊戲中使用的 TTF/OTF 字型換成能支援繁中的開源字型 (DroidSans，思源或文泉驛等等) 然後把字串表都改成繁中內容就搞定了。沒想到馬上就體認到理想與現實的差距，原本預估一個週末完工的時程也膨脹到一個多禮拜...。以下開始血淚分享其中步驟。

我覺得 premake 做對的事

premake 是一個用途如同 cmake、meson 之類，幫忙你「產出指定編譯工具的專案檔」的自動工具。

假設你有一個自行開發的跨平台軟體專案，需要能被 Windows MSVC / Linux Make / MacOSX XCode 三個編譯平台所編譯。最直覺的作法就是分別建立三個編譯工台的專案檔，也就是 MSVC 的 solution 檔案、Makefile、以及 XCode 用的 workspace 檔案。這個作法在維護上會有一個大問題 -- 每當你新增了原始碼檔案、或是變更了某個編譯設定，你必須要記得同時去更新另外兩個平台的專案檔，否則下次有人在另一個平台上工作時就會氣急敗壞地嚷嚷著編譯失敗。

而 premake / cmake / meson (以及其它族繁不及備載) 這類工具，就是試圖解決這個問題。通常它們的作法是: 你必須改按照它們的方式來編寫專案設定檔，然後透過這份專案設定檔來一次生成所有目標編譯工具 (MSVC / XCode / Make ...) 的專案檔。

簡易台股過濾器 - 初試 Google Cloud AppEngine、Datastore

起念是想在「不負擔任何費用」的前提之下，建立能有動態內容、提供可互動 WEB API 的網頁伺服環境，即 Server 端必需能支援 CGI。在各大雲端平台上一陣走馬看花之後，最後看上了 Google Cloud AppEngine、以及用作 Database 的 Google Cloud Datastore。兩者皆有常態性地低用量免費方案，只要用量不超過某限額，是不用付錢的，很適合作為個人練兵場、或驗證一些概念性的想法。

於是乎我把自己平時為了方便選擇存股目標而寫的台股過濾器，移植到 AppEngine 中，提供了簡易的網頁前端以方便操作。

台灣上市股票過濾器

原始碼部分
台股歷年股利、最近成交價爬蟲 (爬出數據塞進 Datastore 中)

置於 AppEngine 中的部分 (含網頁前端內容、後端 WEB API 實作)

在網頁上測試 C++11 Regex -- 初試 emscripten

最近在摸熟 C++11 導入的 Regex 函式庫中使用的 regular expression 語法。C++11 Regex 預設是採用 ECMAScript (也就是 JavaScript) 中定義的 regular expression 規格 (詳見 spec)，而該語法並不完全相容於我比較熟悉的 awk/egrep 中所使用的 regular expression 語法。

最快摸熟的方式當然是實際去試試看。最先是很快地寫一個簡單的 C++ 命令列程式，反覆餵它一些資料然後觀察運作結果。幾次後發現這樣的土法煉鋼法，最好還是配合 GUI 程式比較
便於操作。正準備要動工時，腦袋中突然閃過前陣子在 SlideShare 上看到的一個簡介 emscripten 的投影片。透過 emscripten 的協助，我大可直接把原本那個 C++ 命令列程式轉譯成 asm.js 嵌入網頁中，再小改一下輸入輸出的部分，最終得到一個網頁 GUI 的版本。

C/C++ 如何實現 coroutine (fiber)?

近幾年不論在 Lua 、或 Unity C# 中，都能看到大量 coroutine 的應用範例。一旦了解 coroutine 的工作原理，很難不愛上它。C/C++ 中其實也可以實現 coroutine，但不知為何很少看到大規模應用，也或許是因為 multi-threading 的提倡而被冷落。結果反倒是在 Lua、Unity 等等以 single thread 應用為主的場合才又重新獲得關注。

C/C++ 伺服器藉由 FastCGI 快速提供 RESTful Web API

我負責的遊戲伺服器是以 C/C++ 開發的。而現今這年頭無論是跟哪家營運商合作，無可避免要提供 RESTful Web API 方便讓營運後台對伺服器進行動態的設定或提取即時資訊。我原本對 Web 後端技術所知不算多，不過整個流程摸索過一次之後，發現也沒想像中那麼複雜。以下說說心得。

首先你要知道 CGI 跟 FastCGI 是什麼東西。

說說 C/C++ 網路伺服器使用的各種多工器 (Multiplexer)

若想單單只靠作業系統提供的 API 來實作 C/C++ 網路伺服器程序，首先面臨的問題就是該怎麼設計連線的多工處理 -- 同時間與伺服器建立的連線可能成千上萬，怎麼有效地查覺誰送了資料過來需要回應? 在通訊和資訊網路的領域裡，像這樣「把眾多輸入訊號合併匯集後循序處理」的過程稱為「多工」(Multiplexing，大陸譯為「多路復用」)。因此，由作業系統提供，判斷現有連線中是否有待處理事件的 API ，即稱為「多工器」(Multiplexer)。

我在學校裡只學到一種最基本的多工器，就是 select()。踏入業界幾經歷練，才又陸續接觸到 poll(), epoll(), kqueue(), IOCP 等等的多工器。麻煩的地方在於每個作業系統支援的多工器種類都不一致。就算是以現今 2017 年來看，也只有最古老的 select() 幾乎能保證被各作業系統支援。因此，如果跨平台運行是伺服器的一個主要考量點，那麼伺服器端通常都還要自行開發一層網路事件分派層來統整各平台上多工器的使用差異，或著直接利用現用的第三方函式庫如 boost.asio 或 ACE 等。

我雖能力一般水平有限，但對於想一窺全貌但不知何處入門的同好們，提供一點走馬看花式的導覽，還是可勝任的。