入伍之後一直擔心自己的技術會退步，所以其實有好幾個月的時間都很焦慮。 不過運氣不錯的是，所處的單位算是不錯的，現在的區隊長管理方式也讓我有不少時間可以充分利用。

這邊就簡單介紹一下到目前約八個月多所讀的書，大部分時間都是利用睡前跟午睡時間去讀的，一次大約十到二十分鐘，反而因為軍隊規律的生活變成每天讀書的習慣，意外讀了不少。

延續上一篇的內容，這篇文章要先來討論比較好懂的 Router 部分。

首先，在 Deis 的設計裡面，基本上所有的服務都是包成一個 Image 作為 Continaer 在 CoreOS 運行的。就這點來看，其實是非常符合 Mircoservice 架構的設計。同時我們也可以很輕鬆地將這些服務獨立出來使用，這篇文章討論的 Router 除了原本的用途外，也很適合用來學習透過 etcd 部署自動化更新設定檔的環境。

Deis 的原始碼都放在一起，其中 Router 部分是裡面的一個子目錄，那麼就讓我們開始了解運行的架構吧！

最近因為我們團隊將遠古神話上架到 Steam 上面的關係，收到不少歐美玩家表示需要英文語言的支援。 其實這方面也是當初考慮不周的問題，也剛好碰到了國軍的過年年假有比較多的時間可以處理。

原本預期是一天之內就解決這個問題，不過現實上倒是花了不少額外的功夫去處理。 這也是我們使用 Unreal Engine 4 一直以來的問題，雖然承襲了 UDK 眾多強大的功能，但是卻還未完全的成熟。 從約兩到三個月就會改版一次，而且加入大量功能的情況來看，還有許多需要解決的問題。

過去 Epic Games 自己使用也許沒什麼問題，但是當發布成一個工具的時候，就多了非常多細節要處理。

最近隨著 Container 技術的成熟，以及 CoreOS 等工具的出現。開始有一些 PaaS 的工具出現，而 Deis 就是其中一個。

Deis 本身是受到 Heroku 所啟發的開源 PaaS 專案，透過 Deis 可以輕鬆的建構 Heroku-like 的 PaaS 環境，若是有能夠管理伺服器的人員，其實可以考慮以這種方式部屬網站。相對 Heroku 來說，基本的 CoreOS Cluster 只要三台機器，以 Linode 2GB 的方案來看，甚至還比 Heroku 單個 2x dyno 還便宜呢！

關於 Deis 的架構，在官方的文件已經有做出說明，所以這系列的文章著重在閱讀原始碼以及探討關於 Deis 是如何實踐 Heroku-like 的 PaaS 環境。

我本身是 Heroku 的重度使用者，因為透過 git 管理以及豐富的 Addon 在開發時其實是非常方便的。 不過有時候還是會受到一些限制，這時候 Deis 就提供了很大的幫助。不過這類 PaaS 工具其實還不能說非常成熟，使用上還是會有不少問題，透過了解底層的機制來建構一個自己的版本，在某些情境反而更加容易控制跟維護。

去當國軍也快半年了，遊戲的專案幾乎沒什麼進展。 還一直覺得自己在退步，在多媒體、資訊這些變換快速的產業，要當國軍真的是很吃虧啊 XD

這次鼓起勇氣，去挑戰去年不敢嘗試看看的台北電玩展。 雖然不是面對大眾的 B2C 展區，畢竟我們的目標是去找合作機會跟拓展人脈。 不過這次的展出也算是收穫良多，至少有機會跟一些前輩好好聊天，也碰到許多不一樣的獨立遊戲開發者。 雖然廠商方面大多是提供開發者服務為面向的，但是至少也了解到不少關於亞洲地區業界的狀況。

今年我們團隊 Basaltic Studio 做了兩件事：

1. 參加 TpGS 2016
2. 在 Steam 釋出作品

釋出作品也是也是一個很大的挑戰，這邊就針對今年的計畫好好談談吧！

最近 Heroku 推出了 Docker 支援，也因此我馬上就去試玩了這個功能。

這篇文章會簡單介紹 Heroku Docker 的運作，以及可以運用的方式。

文章大致上會涵蓋這些內容：

• Heroku Docker Plugin 的運作
• 建構客製化環境的 Dockerfile
• 利用 Docker 製作 Buildpacks

最近幾年做測試似乎變成一個非常熱門的議題，而且也逐漸的被大多開發者了解到做測試的優點。不過，一般的軟體可以做測試倒是沒有什麼問題，那麼遊戲該怎麼做測試呢？

我自己認為這是一個很難探討的問題，大部份的遊戲就基於不確定性而變得有趣。在充滿不確定的情境下，要做測試就變得非常困難了。

不過，還是有像是基本的公式計算、數值檢查等等可以做基本的檢查，雖然無法完全的對遊玩上做完整的測試。但是至少可以確保功能上與數值上是以正確的數值做計算。

那麼，就來談談 Unreal Engien 4 的自動化測試工具 Automation Tools 吧！

沒有想到最後還是走上了遊戲開發這條路，同學給我的影響真的很大，而且大家都有一個共同的目標和夢想的感覺很不錯。 雖然讓我下定決心的是因為和同學在合作上太過於順利，讓我們不禁懷疑「正常的團隊運作是這樣嗎？」才讓我決定要跟他們一起做遊戲。

雖然現在有 Unity3D 跟我們團隊使用的 Unreal Engine 4 但是程式自學，又是受設計教育的我在技術上總是會差人一截，最好的方法莫過於從一些基礎的東西去練習，然後了解底層的運作方式。

做 Web 的時候常常會有人在爭辯到底該先學 Framework 還是先學手刻網站這個問題，我認為是「成就感」跟「個人特質」的問題，以我自己來說我建立成就感的個人特質是「先有成果」所以就很適合從 Framework (Game Engine) 學起，當我熟練之後自然會想補足之前缺漏的知識（因此要看個性，有些人就是要 Hardcode 才能有成就感啊！）

知道 SDL 的時間點已經忘記了，印象中只記得國中的時候買過幾本遊戲開發的書卻因為讀不來而沒有繼續學下去。

印象中 SDL 應該就是當時在書上看到的，不過書名實在想不起來。只知道是一本綠色封面的書，日本人寫的。

關於入門的學習 Willusher 這個網站的 SDL 入門教學來開始學習，畢竟 SDL2 的文字教學（個人不是很喜歡看影片）似乎不好找，又充斥著 SDL(SDL1) 的教學有時候還挺混亂的！

今年原本以為沒有機會參加，不過運氣很好的在申請學生專案的時候順利通過審核。

這次的活動由 iThome 主辦，相較過去社群主導舉辦的研討會有許多地方變得不錯，但也有許多地方變得更差。 變得好的地方大概就是行前通知蠻勤勞的（雖然捷運出口寫錯 XD）還有會有工作人員協助安排位置這幾點都是很不錯的，不過相較於過去社群主導的情況，我認為還是社群比較有經驗應該多多跟社群合作去處理這些問題。

至於變差的部分，單純覺得是「想學社群的模式卻沒有學好」的感覺，今年我雖然有感受到一點點社群的感覺但是整理來說還是很企業的，雖然沒有什麼不好，不過工作人員的選用讓我覺得有點微妙。司儀跟主持人都很生疏而且咬字不清，有餘剩的時間也沒有幫忙講者確認是否有人想提問跟控制時間。

另外一個算是心願吧，希望活動能像社群活動一樣是快樂的！開場的時候有說到「來參加這個活動是來休息的」如果單純地聽演講其實沒有太大休息的效果，今年可能是會眾組成的關係所以大家都不太能放開的笑（社群場很常見，也許只是剛好今年講者都不搞笑）另一方面也許是 iThome 的活動本身有濃厚的企業場次味道，大家不敢笑（以前參加過一次微軟的 Hackathon 大家也都不敢笑，下面一排微軟主管壓力很大 XD）

整體來說不算太差，只是我真的蠻糾結主持人不會主持的問題啊 XD （介紹時講點有趣的東西可以幫助講者舒緩心情，結束的時候配合講者善用時間就夠拉～）

另外就是有朋友聊到，議程安排都是把「同類型」放同一時間，據說不少人因為只聽得懂某一類（Ex. 前端、設計）結果變成聽完一個時段後就不知道能聽什麼，選要聽哪個的時候也很難決定（都想聽，仔細想想我也是這樣 XD）

然後正文開始，糾結這個好像沒用 XD

我今年就回家發正念祈禱 iThome 下次會導入社群的團隊幫忙他們辦吧！

參加完新一代就差不多是要等畢業了（茶

文章開始之前，一定要先靠北一下新一代，呼籲大家在該死的投票時不要因為去參加新一代很方便就不選自己辦校外展，辦校外展雖然比較累但是至少還可以學個策展的經驗，也不會被人規劃超小的場地繳根本沒有減半一樣的場地費，還不用把門票錢送給人家，也不用因為贊助商獎項很多變成當人家充場面的工具人，傻傻等那只有 8% 比例的獎項頒完。

不過你們沒被陰過，不懂這感覺。沒關係，參加一次就懂了！反正是最後一次麻⋯⋯ 是說評審的評分標準，最好還是送個不會入圍的 DEMO 去，自己另外曝光還比較賺喔～～

看到這行就是我要開始寫了拉 XD