Deis 架構分析(一)

最近隨著 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 工具其實還不能說非常成熟,使用上還是會有不少問題,透過了解底層的機制來建構一個自己的版本,在某些情境反而更加容易控制跟維護。

在 TpGS 2016 展出後的計劃

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

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

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

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

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

Heroku Cedar 14 - 用 Docker 客製化環境

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

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

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

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

Unreal Engine 4 的自動化測試

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

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

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

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

SDL 筆記:產生視窗與繪製圖像

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

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

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

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

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

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

說好的 Modern Web 2015 心得

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

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

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

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

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

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

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

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

2015 新一代感想

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

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

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

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

mRuby on Web

忙裡偷閒玩了一下 Emscripten 將 mRuby 拉到 Web 上面運行。

最初是看到 WebRuby 這個專案的應用 Webirb 才決定要挑戰將 mruby 丟到 Web 上面跑。

其實這個過程中 WebRuby 給我很多參考方向,才讓我得以順利完成 mruby on Web 的挑戰。

在 SITCON 2015 之後

昨天(03/07)是 SITCON 2015 也是我在 SITCON 擔任工作人員的最後一年。
明年就要畢業了,算是終於退休了⋯⋯(大概會被自動升級成顧問)

這篇文章應該不會寫太長,我還要去填坑 XD

React.js + Parse 實做簡易留言板

前一陣子 SITCON 文創組冬季訓練最後一天,我安排了這個課程給我們的新成員。
雖然 SITCON 文創組看似是個需要「技術」的團隊,不過現實上我們倒是花很多時間在思考跟設計上,沒辦法找到設計相關科系的新成員稍稍遺憾。

不過因為有製作網站的需求,因此安排了這個課程,透過學習 React.js 以及結合 Parse 去熟悉一些基本的前端技巧。

注意事項:

  1. 文中的範例全部都以 CoffeeScript 撰寫
  2. 本文不會提及 Browserify 的配置與應用(當天有介紹過,練習時是使用我配置好的 gulp task)
  3. 這是在不考慮 UI/UX 以及美術的前提下製作的
  4. 文中不會解釋太多 React.js / Flux 的基本概念(請上官網 or ReactJS.tw 社團學習)

那麼,就開始吧!