上一次參加鐵人賽已經是兩年前，這幾年雖然一直都有在找適合的題目。不過都在開賽前認為內容不夠寫完三十天就一直沒有繼續挑戰。不過這次剛好遇到很難得的遊戲專案開源，而且還是連線遊戲類型的。雖然在網路上可以找到一些線上遊戲的私服實作程式碼，不過實際上遊戲公司是怎樣處理的還是一個很有趣的問題。

在 COSCUP 的分享也臨時調整成跟 Unlight 有關的題目，裡面討論的是關於從開源到分析如何把專案跑起來、容器化以及除錯，還有一步一步調整成能夠搭配現有的雲端服務使用的狀況。到這個階段基本上已經對於 Unlight 有一定程度的了解，評估之後就決定來寫這個主題。

最初是想要做一個原始碼的導讀，因此整個大綱都是基於遊戲的幾個重要系統去規劃。不過在試寫過幾次前面幾天的內容後，還是覺得可能會出現兩種狀況。第一種是內容太過分散需要講得非常細節，讀起來會相對的枯燥，而且要花上很多時間在考據。另一種則是每一種技巧跟觀察的的應用都提到一些，但是很破碎分散。

因此最後的選擇變成將設計連線遊戲的主要機制抽出來討論，再搭配上實作來加深印象。原本預計大概 30 天就能寫完的內容最後還是硬多出幾天，而且已經是簡化過的版本。在準備前面的原始碼閱讀時也同時在測試哪些工具適合用來做實作，從選擇使用 RPG Maker 到實作出來其實已經略為複雜。實際上文章示範的實作版本還是相對簡化過的，不過可惜的是因為簡化缺少了一部分東西反而讓後面幾篇文章有一些錯誤出現。

整體來說這次的鐵人賽讓我再次對「連線遊戲」的核心機制有所了解，從文章中應該可以發現有很多在其他類型的應用上也會使用到的技巧，這跟學習設計模式是很類似的。只要一個觀念有了解的話，就能夠延伸出來應用在其他類型的軟體開發上，然後再慢慢的改善設計跟架構，讓自己在設計軟體的技巧上更加進步。

實際上我第一次看到「指令模式」是在一本叫做 Game Programming Pattern 的書裡面，我認為是一本非常適合入門的書。我們不太需要對遊戲開發很熟悉，但是卻可以透過這本書了解到遊戲在面對各種類型的情境下會使用怎樣的技巧去處理，就跟我們很熟悉用 MVC 的方式去劃分跟開發網站應用，遊戲也是有一些常用的解決方案可以拿出來使用。

後來在中間有跟朋友用 Golang 是做了一款連線對戰遊戲，因為某些原因是用一週的時間硬拚出來的成品，因此很多檢查都沒有做。只是單純地將雙方玩家的資訊發送過去，也因此出現了很多異常行為（例如自己宣告勝利、兩邊玩家的畫面跟血量不一致等等）

而到這次從 Unlight 的原始碼讓我又對整個遊戲在應用指令系統上更加熟悉，同時也對一個語言的應用有新的想法。一般來說我們會很習慣的定義物件、方法去開發，不過 Unlight 使用了一些 Ruby 語言的特性自動的生成不少語法，這種 Code Generate 的方式也許是一個新的方向，讓我們能夠透過一些設定檔的方式來加速某些特定情況的程式開發。

說到 Code Generate 我通常會馬上想到 Google 的 SDK 因為那真的是基於某個文件或者設定產生的，因此對 Ruby 開發者來說是一個非常難搞的工具，很多 Ruby 語言的習慣都完全不遵守而讓人無法預測呼叫下去會發生什麼事情。

總而言之，希望明年還有辦法擠出時間來寫鐵人賽。今年的參加人數已經是兩年前的好幾倍，而我自己的時間也隨著工作時間越來越長，要負擔的責任越來越多以及挖的坑變得更大更廣，反而越來越少了。

順帶一提，最近的時間都花在 Open Unlight 的 HTML5 版本開發上。目前正嘗試用 TypeScript 去搭建一個簡化版本的 Unity3D ECS 系統，最終的目標是能有一個可以在 Electron.js 上面提供用 Ruby 寫 Mod 的獨立客戶端，以及能直接在網頁上游玩遊戲的純 JavaScript 客戶端。

大概會是一個很漫長的開發過程，後續的更新會在 Open Unlight 的技術部落格和我的個人網誌（弦而時習之）繼續更新，明年的預定大概會是投稿 RubyKaigi 分享 Node.js 與 mruby 的整合，以及在台北遊戲開發者論壇分享營運遊戲的生存報告跟仿製 Unity3D ECS 系統的經驗。

範例原始碼：https://github.com/elct9620/ironman2020
使用的是我是做的原型，會比文章中再稍微完整一些。不過有些功能還沒來得及做完 XD