關於 #筆記 的內容

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

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

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

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

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

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

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

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

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

自從畢製開始與同學開發遊戲後，我就開始喜歡嘗試運用一些工具如 HTML5、Mono、Processing 等來製作一些屬於自己的「遊戲框架」

自從上次嘗試使用 Mono 與 mruby 結合後，這次在與朋友的閒聊中回想起了 Open Frameworks 這套工具。 Open Frameworks 基本上被稱為是 C++ 版本的 Processing 就各方面來說比 Processing 改進不少，至少就我這幾天的體驗來看，以我目前的實力已經可以純熟運用了！

過去曾有一段時間嘗試玩過，但是因為沒有 Project Generator 輔助建構專案，再加上與 C++ 其實不是那麼的熟悉，因而放棄。這次透過 Unreal Engine 的經驗，以及上次 mruby 的整合讓我順利的開始使用 Open Frameworks。

這篇文章主要會分享我使用 Open Frameworks 開啟一個 Ruby 檔案，並且執行裡面的方法在介面中繪製圖像的做法。 目前我認為這個方法其實還不太完善，不過作為初次的嘗試可以算是一個不錯的成果。

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

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

注意事項：

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

那麼，就開始吧！

雖然 mruby in C# 系列暫時沒辦法繼續撰寫，但是 Unreal Engine 4 系列大概會在畢業製作完成之前，陸陸續續地以筆記的形式更新出來。

實際上，用 Unreal Engine 4 開發遊戲是不太需要用 C++ 來處理的，內建的 Blueprints 功能就具備非常優質的設計，也算是整個引擎中不論美術、程式都會經常接觸的功能。其特色就是人人都能懂，美術可以用來控制動畫、程式可以用來設計 AI 跟遊戲，上手的難度也非常低。

那麼，會遭遇使用 C++ 來處理的情況是什麼呢？

基本上可以分成兩種，第一種就是效能問題，目前還沒有碰過，不過以 C++ 撰寫的程式碼肯定會比較順暢（雖然我很懷疑 Blueprints 所編譯的成品就能產生接近 C++ 等級的效能）

第二種則是 Unreal Engine 初期沒有考慮到，或者還未支援的的部分。像是在 4.5 的 UMG (Unreal Motion Graphics) 功能推出之前，需要用到 Slate UI 來輔助建構遊戲界面，就勢必得用 C++ 才能解決。

總而言之，這篇文章在討論的就是第二種情況，我們需要的功能還未在 Unreal Engine 4 上面「好好的」運作。

註：程式結構太複雜這點，原本想算進去。不過因為 Blueprints 不論註解還是開 Functions 都能做到，很難用這點來說是一種缺點⋯⋯

前一篇文章討論了關於 C# 執行一段 Ruby 程式碼並且取得執行結果（字串）的做法。 不過，光是這樣在 C# 使用 mruby 的意義並不大，我們需要結合 Ruby 的 DSL 特性，讓自製的 RPG Maker 可以更加簡單的被用於製作遊戲（最終目的）

也因此，我們需要能夠讓 C# 中的一些 API 可以在 Ruby 中被呼叫以及使用。 那麼，能夠從 C# 定義 Ruby 的 Module / Class 和 Method 就非常的重要，因為如果無法這樣做，那麼就無法讓 Ruby 執行 C# 的程式碼。

最近看到朋友提起 RPG Maker 又勾起我在 Mac 上使用 RPG Maker 的野心，雖然之前用 Wine 順利跑了起來，不過既然能寫 Ruby 當然要用各種奇怪的方式去玩弄。

結果，當我發現內建的 Library 要做到我想做的事情很困難的時候，腦抽的我決定自己做一個！

不過，這年頭不跨平台其實還蠻空虛的，所以就從能夠跨平台來做選擇，至於為何會選 Mono 和 C# 大概就是受到 Unity3D 跟 Unreal Engine 4 兩個目前都是非常有名的遊戲引擎影響吧！ （上述兩個引擎都有使用 Mono 來協助實踐跨平台的功能）

之前寫過一篇關於 Vagrant + Capistrano + GitLab 的自動化部署介紹。

不過當時因為一些問題，卡著沒有繼續完成測試。 最近因為某些原因，需要一個 Nightly-like (不一定會每日更新，取決于 commit) 的環境，所以只好硬著頭皮把全部的問題解決了⋯⋯

最近收到一個 Issue 是關於我製作的 Heroku Buildpacks 有問題，沒辦法使用 Travis CI 的 Deploy 功能。

因為寫 Test 的習慣養成挺困難的，再加上獨自開發與大多是半遊玩性質的關係，其實幾乎沒有使用 Travis CI 的習慣，不過這次因為這個 Issue 我稍微研究了 Travis CI 的功能以及 Deploy 功能。

這算是一個很方便的功能，尤其是網站專案來說，如果在 Deploy 後馬上就發生問題，也是非常不方便。那麼，一般 Git 的專案來說，我們通常都是直接進行 Deploy 即使在本機事先做過一次測試，但是總是會有忘記的時候。

此時，透過持續整合服務的自動 Deploy 功能來協助，就可以在確保所有測試都沒問題的狀況下才進行 Deploy 也比較能夠自動化。

這標題超級長的說（崩潰

最近因為有實習生要來，所以把老爸公司設定好 GitLab 和 Gitlba-CI 來作為內部的版本本控制和自動化測試環境。 不過原本規劃的 Staging 環境也是在這檯主機上（當初就很淡定把記憶體和處理器加高，因為我會狂開 VM XD）但是會有 SSH 權限上的問題，原本想利用 Git 的 Hook 之類的來處理，但是感覺似乎不太好。

剛好這次看到 GitLab / GitLab CI 的介紹文，我又再次嘗試安裝，過程上順利、簡單很多。 不過上次不順利肯定是我把整個環境裝在 NAS 裡面的關係 XDD

從我建好 GitLab / GitLab CI 到設定 Capistrano 到自動部署，其實花費不少時間，而且有很多「差點忘記」的部分，因此決定來寫一篇文章做筆記！