微妙的 Unreal Engine 4 語言偵測機制

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

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

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

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

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) 的教學有時候還挺混亂的!

mRuby on Web

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

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

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

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

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

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

注意事項:

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

那麼,就開始吧!

Open Frameworks 與 MRuby

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

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

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

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

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