弦而時習之

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

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

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

注意事項:

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

那麼,就開始吧!

將遊戲場景帶入網頁

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

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

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

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

主要的目標大致上有:

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

Container Summit 2014:未來的雲端

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

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

螢幕快照 2014-12-12 下午11.26.55.png

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

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

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

TGDF 2014:重燃的遊戲夢

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

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

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

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

那麼,就來看看今年的議程吧!

PHPConf 2014 會後心得

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

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

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

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

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

那麼,來談談今年 PHPConf 的議程吧!

JSDC 2014 會後心得

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

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

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

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

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

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

Unreal Engine 4 - 用 C++ 自訂 Pawn 物件

雖然 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 都能做到,很難用這點來說是一種缺點⋯⋯

MRuby in C# - 因 RPG Maker 的慘劇(二)

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

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

Zigfu 跨平台的 Kinect SDK

之前和系上老師借了一個多學期的 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 的介紹,可以參考這篇文章

使用 Zigfu 的骨架功能

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

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