昨晚公開了畢業製作的官網「遠古神話 - The Lost Mythologies」並且使用了「全景攝影技術」在網站上。

喜歡我們的話請到粉絲專頁幫我們按個讚 XD

沒想到反應還蠻熱烈的，雖然官網目前也只有全景預覽以及 LOGO 而已，不過似乎造成了一點點話題。

那麼，這個效果到底是如何做出來的呢？這篇文章就會簡單的說明。

主要的目標大致上有：

• 順暢的瀏覽
• 清晰的畫面
• 全景圖片的製作

其實原本沒有打算參加的，不過最後還是禁不起誘惑選擇參加這場活動。

主要是因為有兩場議程是我希望在近期解決的問題，因此現場聽講肯定會是一個比較好的方法。

實際上，我其實算是蠻早接觸 Docker 的使用者，不過當時除了建建 Container 之外也不能做些什麼，因此很自然的就沒有多加在意了（現在使用起來發現 Docker 多了不少功能和改進⋯⋯）

之後也有 Docker.Taipei 的活動，不過也沒有深入接觸，算是蠻可惜的⋯⋯

不過，這次活動結束之後我認為善用 Docker 應該會成為一個很有利的技術。

心得文沒有趁熱寫果然很容易忘記，這次來嘗試使用炫砲的標題來開始這篇文章。

這次會參加 TGDF（台北遊戲開發者論壇）其實是因為到了大三確定要做遊戲，卻每次都因為這類活動都在上課日，礙於請假問題而沒有去參加（組員都不太喜歡請假）現在大四課比較少，就跟老師請個假去參加了！

雖然是擔任志工，不過基本上規劃還算不錯，人力需求非常的低有蠻多時間可以去聽演講。

關於這部分，一方面是餐飲的部分由參加者自行處理，另一方面是協辦單位也有提供人力支援。再加上場地永遠只會有兩道門可以進出，讓志工人數的需求減少到非常低。

那麼，就來看看今年的議程吧！

這次參加 PHPConf 不是以會眾的身份，而是以講師的身份參加。回想起來，三年前左右因為朋友的推薦參加了 COSCUP 接著得知了 PHPConf 然後就開始陸陸續續的參加各種社群的活動。

三年前左右，剛好是我升上大學的時候。那時其實已經經歷過好幾次的瓶頸，光靠自學其實是很難學好一項技能的。除了老師之外，我想就是社群這種平行交流的地方可以獲取「書本」跟「文字資料」以外的知識，很多東西真的要靠交談、人與人之間的友情，才能夠得到一些「特別的經驗」或者「特別的方法」

當了三年多的聽眾，我在這短短的時間內透過每一個 Conference 獲得了各種不同的技能與技巧，在今年的 PHPConf 我了解到我已經從一個「接收者」變成一個「分享者」的角色，正好也是在我即將從大學畢業的這個階段。

正因為我是受到「社群的恩惠」而成長，所以我想在之後我還是會繼續投入社群的活動。以一個工作人員，或者是講師的角色來做這件事情，即使不是每一個人都能透過這種方式成長，但是在未來，讓 Conference 繼續經營下去、舉辦的更好，都有可能多幫助到一個像我這樣受到社群滋潤而成長的人，這也是我從 SITCON 擔任工作人員的經驗，還有從 COSCUP、PHPConf、RubyConf、JSDC、WebConf 這些活動所體會到的。

總而言之，我會盡可能以工作人員的身份來參與未來幾年的社群活動，是時候該回饋給社群了 XD

那麼，來談談今年 PHPConf 的議程吧！

總覺得因為大四忙著畢業製作反而沒有太多時間寫文章，不過參加 Conference 總是會習慣寫篇心得記錄一下今年發生的事情，反而讓網誌充滿了心得啊 XDD

我快要變成寫心得高手拉！！

今年的 JSDC 有很大的轉變，其實我覺得這是一件「非常有勇氣」的事情。自從我接觸社群、Conference 到現在也有四年多，正好在這段時間台灣的社群活動也越來越熱烈，從剛開始一年只會參加兩三次活動，到今年我平均一周大概就有一天會到臺北。就可以看到社群的發展，以及許多人熱血的在付出。

不過，從規模、參與者、活動品質個個面相來看，社群也開始面臨一些需要轉變的問題。跟三、四年前不同，我們也很多地方已經無法用過去小規模的方式去舉辦，而國外講者的比例也逐漸地增加，某一方面而言是這些活動已經有一定的知名度，已經逐漸無法用過去的方式來舉辦（這也是最近我們 SITCON 籌備團隊少數幾位組長開始在爭辯的問題，我們該何去何從、該如何改變以繼續發展下去等等⋯⋯）

所以，就這一點而言我認為 JSDC 非常勇敢的幫大家做一次嘗試，嘗試用國際等級的票價、嘗試讓議程更加的國際化（除了 JSDC 之外，我只有在 RubyConf 碰過這麼多國外講者）、嘗試讓活動的品質提高。

簡單來說，要踩雷的話，總有一個人先去踩看看，這個人就是 JSDC 的籌備團隊。

雖然 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# 的程式碼。

之前和系上老師借了一個多學期的 Kinect 卻只有做完用 Mac 連接 Kinect 並且搭配 Unity3D 的功課，就一直沒有成果。 暑假也即將結束，緊接而來的就是全力投入在畢業製作，不過在此之前，還是得先把答應老師的功課做完。

雖然時間不足以製作一款遊戲，但是將 Zigfu 這款非常好用的工具使用介紹完整的說明，我想多少也算是能夠完成一部份的任務了！

Zigfu 基本上是設計給 Web 使用的，因此目前支援是 JavaScript 和 Unity3D 兩款（Flash 過了半年依舊開發中⋯⋯） 不過 Zigfu 卻替 Mac 使用者解決了一個問題，就是 OpenNI / OpenNI2 的安裝，沒有驅動就無法使用 Kinect 是 Mac 用戶的痛。

不過很可惜的是，目前最新的 Mac 驅動只能順利與 Kinect 溝通一分鐘左右，之後就是當機。 也因此，這系列的文章都是針對 Windows 所說明的，但是成品對 Mac 的支援是確定的，即使會當掉⋯⋯

至於 Zigfu 大致上做了什麼呢？ 將驅動程式包裝起來，協助使用者安裝（Windows 使用者需要自己安裝驅動）並且提供 ZDK (SDK) 讓開發者可以用統一的界面，存取 Kinect（官方）、OpenNI、OpenNI2 的 Middleware。

關於 OpenNI / OpenNI 2 的介紹，可以參考這篇文章。

接續上一篇文章的介紹，這一篇文章會針對 Kinect 在遊戲類型應用上最為重要的功能「骨架」來做討論。

在 Zigfu 中，已經提供了 ZigTrackedUser.Skeleton 這個物件讓我們可以存取骨架，與前一篇文章不同的地方在於，我們會用 Zig_UpdateUser 這個方法存取骨架。

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

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

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