關於 #遊戲 的內容

最近剛好被人問到使用 Ruby on Rails 應該如何開發遊戲，因為是個很有趣的題目所以就利用週末的時間來簡單討論一下這個問題。雖然是以 Ruby on Rails 作為案例，不過這些經驗大致上是適用於所有程式語言的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

之前和系上老師借了一個多學期的 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 這個方法存取骨架。

這幾年來 3D 遊戲的門檻隨著 Unity3D 的出現，從原本 Open Source 的 Ogre Engine 等，層次一口氣提高到了「商業運用」的等級，支付一定的費用給引擎公司，也許就可以用到 3A 遊戲等級的引擎。只要有付費，許多問題與麻煩都可以交給引擎公司，相較 Open Source 的形式，某種意義上也是更加容易的製作遊戲（至少不會有問題找不到解法，大絕就是呼叫客服）

自從 UE3 開放免費下載（抽成形式）後，這次的 UE4 稍微改了模式，月費制加抽成（5%）並且在最近公佈下載與付費的方式。

而我的同學長久以來就有著要用 Unreal Engine 的怨念，但因為我一直以「在 Mac 上不方便」為理由，讓他乖乖選擇 Unity3D 不過 UE4 來勢洶洶的支援了 Mac 我也不得不認命⋯⋯