Ngan Lo's Game Developing Blog

遊戲製作是甚麼 ?

2011-08-28T15:50:00.002+08:00

近來在遊戲製作的過程中，看到了很多失誤，當中牽涉到的，是橫跨了遊戲設計、美術設計和程式設計。認真一點的說（或者是不客氣的說），就是整個遊戲的製作上，由一開始已經是註定成為了 epic fail 的最佳例子。

其實遊戲製作是甚麼一回事？

從遊戲設計上說，遊戲製作其實並不困難，因為困難的並不是遊戲製作過程，而是遊戲設計上，對「創作」上有多少的覺悟，如果有志投身或現職遊戲設計的，應該要有這個覺悟，因為如果沒有這個覺悟的，你所遇到的，只會是失落與沮喪，到最後只是黯然離開。
我所說的覺悟是，不要認為遊戲設計是空想科學而已，請細心想一想；因為遊戲製作並不是「空想」而已，你不能只享受創作時的快感，也不能閉門造車，只有自己才明白整個遊戲的設計，要和 Team 內的組員多溝通，要所有組員明白遊戲的核心，同時也要顧及很多很多的因素及細節，例如遊戲的設計在表達上，和技術上的可行性，又甚至是界面上的實用性...等等，這些看上去都不太關於遊戲設計的範疇，但對遊戲製作上卻是非常重要的。

從美術人員的角度上說，做出遊戲設計上所有視覺效果，是最重要的職務。然而，在美術的表達上，也要和遊戲設計的主題互有交流，才能夠充分表達到遊戲的重點。同時在技術層面上，也要有多一點的認識，始終遊戲製作這個行業，與其他美術設計業不一樣，在創作上會是被科技的框架包圍著，多認識一點技術，多一點創作空間。

到了程式設計上，切忌一些堆砌、不必要的複雜及 hard-coded 的形式，例如：
int _column = _size_col % 3;
int _row = _size_row / 3;
以上的例子簡單地說明了「堆砌 + 複雜 + hard-coded」，這種程式，不便修改，不便除蟲，突顯出那是臨時堆砌出來的。
另外，對遊戲引擎工具的一知半解，也會令以上的問題劇烈化，成為了問題最基本的觸法點。

但到了最後，不得不說的，就是互信的問題，如果遊戲設計人員，美術人員及程式技術員，大家都互不信任，不互補長短的，要製作的遊戲到最後成為了 epic fail 的一員，也是必然的結果了。

在這樣看上去，我好像有點自以為是，只懂批評。

但正如爆漫中說的，成功的三項條件：自大，努力，運氣！（我有點自大，很努力，但沒運氣）

上一回的後來

2011-07-02T00:34:00.000+08:00

我已經放棄了, 甚麼 cross platform 的東西, 都不重要了.

在很久很久之後...

2011-06-27T23:43:00.001+08:00

終於, 將一個 Cross-Platform 的 Engine 封裝好, 能夠用到一點點, 就這一點點罷了... XD

我很懷念...

2011-06-01T00:27:00.001+08:00

不知為何的, 這幾天很懷念我的前度 "Ogng3D", 她雖然不漂亮, 但也不花巧, 而且很對我胃口, 除了缺乏平面視角, 和與 3DMax 來的廚具不咬弦外, 其實並沒有分手的理由...

既然事情已發生, 其實不應回頭看過去, 主動說分手的是我, 還是算了吧...

究竟... 有甚麼好玩 ?

2011-03-16T10:42:00.000+08:00

以下是一段 Prototype 2 的 trailer，片段中展示了丟人落街，但我不是想說其道德問題，而是，若那是一個要 Promo 的 Gameplay，那麼..... 「有甚麼好玩？」

對不起，我百思不得其解。

要放棄的時候就應該放棄

2011-03-03T16:53:00.000+08:00

在這些年來，用過不少有關遊戲開發的 Engine，近幾年都在用 OGRE，但相信是時候放棄它了。

自從 OGRE 推出 1.7 以來，我嘗試過幾次將自己的 Ogng3D Engine，從 OGRE 1.6 轉過去 1.7，但係每次都有點小問題令我停滯不前，由它加入 Boost 的小問題，到 .mesh 格式的改變... 等等，這些林林種種的小問題，真是煩瑣得很... 所以，就在此決定，不會再跟進 OGRE 作為我的遊戲開發 Engine 的一環了。

一直以來，OGRE 中的很多功能 ( 例如 Particle System )，都絕對不是一般的難用，只是我自己一直都找不到替代品，才一直硬著頭皮地用著它... 。到了近年，遊戲 Engine 都發展到一個沒法想像的地步了，而且不小 Engine 開始免費化了 ( 當然是有條件的... )，所以其實已經不愁沒有替代品。

最後也要說說，其實在使用 OGRE 配合自己的 Ogng3D 的這幾年間，因為 OGRE 的難以運用，確是從中學習到不少遊戲開發的事，雖然不能使用它來開發一個真正的遊戲 ( 其實曾經用過 Ogng3D 做過幾個遊戲 Prototype 呢... )，但也算是個不錯的經驗。

很多時候，人要在適當的時候放棄一些東西。這次使用 Engine 的事情，也不應再糾纏下去，狠心的切斷和 OGRE 的關係好了。

日系遊戲與歐美系遊戲

2010-11-27T23:27:00.000+08:00

多月前，看過 Capcom 將旗下的 Devil May Cry，給與一間名為 Ninja Theory 的開發商，製作最新的 DMC，很多人都稱這個新的 DMC 是個 reboot。很多人都不喜歡，玩家們的反應看來是差得一發不可收拾，而且加上 Capcom 美國分部更說，那個不像樣的 Dante 是用來激怒 Fans，希望帶來一些宣傳性迴響。但看這一次，Capcom 真的有點玩過火了。

今天，GameTrailers.com 中有一段新的 DmC (新開發版本的簡稱) 片段，而我關心的是那些 Comments。很有趣的是，在那大堆 Comments 裡，九成以上的人都反對 DMC 這個 "reboot"，更有的是質疑 NT 跟本沒能力處理 DMC。這些反對聲，令我想起了一個問題：日系遊戲應否改變，變得更有歐美特色！

就個人而言，完全反對日系遊戲變得歐美化。雖然我壓根兒是日系遊戲 Fans，但亦承認在某些遊戲上 ( 說實話... 只有 FPS...)，歐美確實是很精彩，但說到一些傳統的 Action game，尤其是 Fast-paced 的那種，歐美遊戲請靠邊站。其實，當連外國玩家們對著新 DmC，反應並不是那麼的正面，日系遊戲的製作公司要做的，並不是改以歐美的口味來包裝日系遊戲，而應該想想如何發展日系遊戲的本身的特點，例如 Gameplay、Control、Camera works 等等都是日系遊戲的強項。

網上一個討論區中的一編文章，論及 DmC 的 reboot 問題，值得一看。

Bayonetta Prototype 影像 (前編 + 後編)

2010-11-22T12:07:00.004+08:00

很難想像，到了這個質素的 Built，還說是 Prototype......

プロトタイプ映像（前編）

プロトタイプ映像（後編）

Gameplay Programmer part.II

2010-11-04T00:26:00.003+08:00

前話：這系列所說的內容，是假設大家也是懂得寫程式的，否則可能不太適合繼續閱讀。

上一次說過，如果沒有 Game Design / Tech Design 文件，做遊戲是很困難的。說實話，要在香港找到這類文件也是非常困難，如果有個人想自己做個遊戲出來，但他 ( 她 ) 只懂畫東西，又或者只懂編寫程式，怎樣可以做個遊戲出來？很多人、很多想做遊戲的人，也會為此墮進了一個迷思的情況。

那究竟要怎樣開始製作一個遊戲的 Game Play 部份？首先一定要搞清楚方向，甚麼是「方向」？說穿了，就是「想做甚麼遊戲？」

不要說「做甚麼遊戲也可以，就是說來聽聽。」這樣是行不通的，要開始製作一個遊戲，就先要決定做甚麼類型的遊戲。而且決定了之後，不要改主意，這是基本要做到的。補充說一下，古語有云：不熟不吃；選擇製作甚麼遊戲，也要以這個標準來決定，選擇一個自己喜歡的遊戲類型來開始，這樣做可以有助自己對製作中的遊戲保持熱忱。跟著下來，就是要說說，決定做甚麼類型的遊戲之後，要做甚麼準備。

決定了做甚麼遊戲後，就快快找個現有的遊戲為目標，模仿它做一個。但是先不要想著要做到一模一樣的，先選擇簡單或單一部份來開始，我用些例子來說說：
● 2D 射擊，製作主機控制和發射子彈
● 2D 動作，先做 Sprite 動畫系統和背景捲動
● RTS，製作 A-Star 尋路系統
● RPG / 育成，先處理 Script 及 Event 系統

以上所說的都是例子而已，每個遊戲要先製作那些部份，每個人的選擇也不一樣，但先由一些簡單或單一部份開始，是很適合初接觸 Game Play 製作的。要記著，選擇做個自己喜歡的遊戲類型，可以令自己沒那麼易放棄。還有的，就是要堅持下去啊！ :-D

在 Content creation 上的目標

2010-09-05T15:24:00.003+08:00

很久沒有在 Blog 中更新了，因為近來很忙碌，先是要搬屋，其後是搬屋後的煩瑣雜務，而且一個人住了，要處理的事比以往和家人住的時候要多，就這樣便忙了接近兩個月了。希望能在九月中前全部整頓好，因為在九月中我便要開學進修了，如果在那之前也還沒搞好，恐怕會進入混沌空間呢......

近來不僅是沒有寫 Blog，甚至是 Programming 及繪畫也小了很多。在 Programming 方面，曾經嘗試了一些東西，就是希望能夠在 Modeling 軟件 ( 例如 3DSMax ) 及 OGRE 中間，製作一個轉換工具，方便一些使用如 3DSMax 的 Artist 們，製作 OGRE mesh / skeleton，然後在我的 Ogng3D 引擎上使用。初時我選擇了 FBX 格式，那時候我在網上看到一些如何讀取 FBX 格式的 Source code，還以為不會很困難，但奈何發現原來比想像中困難很多。

其後經過多日嘗試，始終不能明白 Skeleton 及 Skinning 的部分，所以便暫時擱置 FBX 格式。然後經同事的介紹，便開始看一個叫做 POD 的格式。這個 POD 格式是來自 PowerVR 的，看它的原因，是它的 Exporter 工具有不斷更新，並沒有被棄置，其次時它的 API 是一套 C Language。但試作了幾天，又發現了它的格式很難控制，而且一些簡單的讀取 Vertex 資料上也錯了，比較 FBX 更難駕馭。

說到底，可能是自己的數學知識和 Programming 能力不夠，所以才對這些檔案格式運用上，出現老鼠拉龜的情況。看來我還是要回到 FBX 的格式上再嘗試，希望有一天能夠完成這個 FBX -> OGRE mesh / skeleton 的工具吧。

Gameplay Programmer part.I

2010-06-19T17:16:00.002+08:00

自己進入遊戲開發業界工作的時間，是 2006 年的夏天，在初入行的時候，並不是一位 Programmer，而是 Artist。完成了第一個 Project 的時候，也是轉職做 Programmer 的時候 ( 好像這說明了我在美術方面就是不及格... )，老闆說要我做一個 Gameplay Programmer，就這樣，便做了幾年 Programmer。

其實 Gameplay Programmer 和其他位置的 Programmer 有甚麼分別？我不是從正規的途徑，學習編寫遊戲程式的 ( 說到底，在香港這種編程就只有是自學的 )，所以不知道正確的遊戲編程是怎樣的，但經過了這幾年時間的洗禮後，發現了一個有趣的情況，就是 Gameplay Programmer 要做的事，很多時候是不能用常規編寫程式方法就可以完成的。因為在玩家玩遊戲的時候，遊戲規則及系統的千絲萬柳，與玩家之間的互動關係，並不能單純地依照常規就可以連繫起來的。

我幾年前曾經在 Blog 說過，覺得自己以往做有關 Game Engine ( 很不專業的說，可以做出遊戲就算了 ) 的時間太長了，應該往前走嘗試一下其他範疇，例如 Gameplay，所以便開始嘗試製作「 Final Spike 」。Gameplay 的製作，與 Game Engine 有著很大的不同，近十年來，Game Engine 在網上的世界裡隨時也可以找來幾個，而且有些還提供了 Source code 。但是看看有關 Gameplay 製作的資料，在網上就是很難找來一個適當的例子作參考 ( 那時候找到的，都是 Tetris 類的... ) 。如果你沒有有關方面的經驗，或者沒有一份完整的 Game Design / Tech Design 文件，想開始做 Gameplay 是很困難的。

Gameplay 製作中牽涉的認知，不是簡單地從課本中就能夠學到，例如沒有玩過動作遊戲，便不太明白「操控感」的重要性，沒玩過 RTS 遊戲，可能不太明白「遊戲平衡」的關鍵。在我初時進入遊戲製作行業時，有朋友問我，究竟在哪裡，或怎樣才可以學習到 Gameplay 製作？那時候的我，不太能夠說出答案，但是累積了一點經驗後的今天，有些心得可以說一說。

下回再續。

To Compromise 妥協的意義

2010-05-30T01:10:00.004+08:00

長久以來，很多人說，妥協是一種藝術，而在遊戲製作的過程中，妥協不只是藝術，也是認知。怎麼樣的認知？有關遊戲製作的認知：技術上，能力上，規模上，時間上。

技術：在甚麼平台上製作呢？Programming Language、2D、3D、Shader、Physics、A.I. 及 Network 等等，能夠做得到遊戲設計的要求嗎？要開發 iPhone 遊戲，懂得 Objective-C 嗎？2D 技術比較舊，Artist 及 Programmer 認識嗎？3D 及 Shader 技術上完整嗎？ Physics 能夠順利駕馭嗎？A.I. 可以滿足 GamePlay 的要求嗎？Network 技術有否足夠支援？遊戲製作的工具成熟嗎？

能力：是關於製作人員的能力為主，Programmer 能否做出遊戲設計的要求嗎？Artist 可以做出 2D Pixel artwork 嗎？3D Modeling 及 Shader 上，他們能夠清楚掌握嗎？

規模：製作人員數量能否應付製作所需的要求？過多人員或過少人員，都會對製作產品過程有不同的影響。

時間：有技術，有能力，規模恰當，但時間是否充裕？先不談論製作期間的任何改動導致的延誤，製作開始時所預計的時間是否恰當？

以上種種因素，其實也可以從「妥協」中找到出路，例如在 Wii 上不能做出 XBox360 / PS3 圖像質數，便要將圖像要求降低。亦不能要求在 iPhone / iPod 上，製作出一個超越 God of War 的 3D 動作遊戲。甚至不應該要求，在 2D Pixel 中，要表現出浮點數 ( floating point ) 的精確度。時間上不容許延誤，那麼可以嘗試刪減遊戲的內容，來縮短製作期。但可惜的是，剛剛所說的，也可以是完全沒用的，因為還有一個元素，令「妥協」變成不可取，令整個遊戲製作翻天覆地，那是甚麼？就是 Game Designer，一個對以上所說的都毫無認知的 Game Designer。

所以，Game Designer 不好做，做得好的 Game Designer 都不能「想當不想做」( 廣東話 : 恨撈唔恨做 )。

忽發奇想 - Timer

2010-05-03T23:57:00.003+08:00

在電腦裡，Timer 是一個很重要的部份，在 Hardware 和 Software 中也亦然。很多 Program 程式中也有 Timer 來作計算的用途，在遊戲程式中亦當然也很多用呢。

今晚忽發奇想，究竟 Timer 是否一個很費時的工具？想到這裡，我便想用 Ogng'3D 中的 Timer 工具做個小實驗。

建立 256 個 Timer，每個 Timer 設定的 Delay 都有不一樣，究竟程式在這麼多的 Timer 下，會否被拖垮呢？答案是：不會！

在 Ogng'3D 中，使用了 256 個 Timer 雖然會令程式變得慢了很多，足足慢了十倍之多，但要在 60 FPS 中運作，還卓卓有餘。

其實，Timer 並不是那麼恐怖的呢......。

Ogre on the iPhone

2010-05-02T15:45:00.003+08:00

昨天在 Ogre Forum 裡看到有位用家，在 iPhone 3GS 測試了 Ogre 的效能，結果很吸引的說：

150,000 triangles, 1 directional light, 1 texture at 30fps
140,000 triangles, lighting off, 2 textures (multitexture) at 30fps
100,000 triangles, 1 directional light, 1 texture, 25 batches at 30fps
16 1,400 triangle characters with 24 skinned bones and a 50,000 triangle, 25 batch static backdrop and 1 directional light at 30fps
32 of that same character playing the same animation using blend shapes at 30fp

以上的數據，顯示 Ogre 在 iPhone 3GS 中的表現很不錯，很適合做些小型遊戲。

[ Forum 原文 ]

可惡的GUID古董

2010-05-01T21:39:00.006+08:00

我自己很喜歡用 C 寫程式，所以我是用一個叫 PellesC 的工具，來編寫遊戲程式。

早在一年多前，PellesC 更新了新版本 ( 是個 Major release 呢 )，我很興奮地下載來用，但是惡夢開始了，因為用這個新版本 Compile 的時候，出現了一大堆如下的 Error：
......
xxxXXX_GUID is multiply defined - in YYY.obj and ZZZ.obj
yyyXXX_GUID is multiply defined - in YYY.obj and ZZZ.obj
zzzXXX_GUID is multiply defined - in YYY.obj and ZZZ.obj
......

我不知道是甚麼問題，完全不明白新的 PellesC 為何會出現這些 Error ( 舊的版本卻完全沒有以上的問題... )。上網查查看，一大堆不明所以，又或者不相關的搜尋結果，看得我頭也大了。這一大堆古怪的 Error，令我只能回到舊版本的 PellesC 中，直到今天。

雖然近月的工作超級忙，但也抽了丁點的時間做些 Ogng'3D 的改善工作，決心再在那堆 GUID 問題裡鑽一鑽。上網再細心地看那些不明所以的搜尋結果，發現了 INITGUID 這個東西，原來這個東西可以說是個古董 ( 有點誇張 ... )，心裡忽然想到可能和這個有關係，再回看 Ogng'3D 中的 Source code，搜查一下，發現我確實用了這個 INITGUID，這時忽然覺得曙光漸露，即時裝上那個 PellesC 新版本 ( 但已是一年多前了... )，刪除了那句 INITGUID，然後 Compile，成功了！

原來是 INITGUID 這個老古董，害我不能用 PellesC 新版本達一年多，很令我討厭的說！( 同時也覺得自己很戇居，超級的那種... )

2D, 2D, 2D

2010-03-21T21:33:00.004+08:00

在遊戲製作當中，其實 2D 是很重要的一環，絕對是一個不可忽略及忽視的技術層面。

我對 2D 技術一向都很重視，尤其是 Sprite 中的各種運用方法，絕對是屬於「非常固執」。用了 OGRE 這樣的長時間，一直對它極小 ( 差不多沒有 ) 的 2D 支援很不滿，但偏偏 OGRE 的開發團隊就是忽略這個範疇 ( 曾經想過為此而放棄 OGRE...... )。

所以在 Ogng'3D 中，我用了一個比較小用的方法做 2D，就是以 Billboard 加上 Orthogonal Matrix 來完成。這個方法當然不太好，因為如果 Billboard 使用 Vertex rotation ( 原設為 Texture rotation )，會有比例錯誤的問題，但在我所定下的「盡量不要碰 OGRE 擴展或 Source Code」的原則下，唯有妥協了。

其實上面的做法已經完成了一段時間，這兩天我花了大部份時間加以改善，現在已經可以在屬於 Sprite ( 2D ) 的 Scene 中，使用 Manual Object 及 Ribbon Trail 功能做一些 2D 的效果 ( 下圖 )。

提不起勁的近況

2010-03-04T00:06:00.004+08:00

近來因為工作的關係，放工後精神都提不起來，有時候精神不錯的，也不想再對著電腦寫程式，反而是對著電腦作畫。這種情況其實在兩年前已預計到了，因為工作上要寫程式，很正常就不想在工餘時也對著程式，唯有發展另一個興趣了。追看我這個 Blog 的朋友，可能會越來越失望了，因為我越來越小提及一些做遊戲的話題了。

雖說提不起勁在工餘時寫程式，但近日對 Ogng'3D 也有做了些小改動的。就是將當中的 Timer 功能，轉為使用 OGRE 的 Timer 功能，原因當然是因為多平台支援的原因了。

有時候會上網看一些遊戲的 Game-play 片段，每每看到有關「SpikeOut」的，心裡總是覺得不爽，因為自己總是將「Final Spike」擱在一旁，在去年還大膽地說想做個網路連線遊戲...... 寫程式的技術改進了，但自己想做的就只有那種下場。

閒來作－下畫，可以減壓，舒緩一下精神上的壓力。

遊戲音樂 - 主題曲

2010-02-14T23:11:00.009+08:00

從我一開始玩電視 / 電腦遊戲後不久，便已經喜歡上遊戲音樂這個領域，還記得以往紅白機 / 超任 / MegaDrive 年代，或是同期的 Arcade 遊戲機，都是一些簡單的電子音樂。後來到了用 CD 作為遊戲媒體後，遊戲音樂有了很大的變化，不再是些簡單的電子音樂，而是豐富的真樂器領域。

前幾天看到同事們在討論遊戲音樂，所說的是 Zone Of the Enders 2nd Runner 的開場曲，令我想起了一些很喜愛的遊戲主題曲。說實在的，遊戲的主題曲不是新鮮事，但是卻很小出現，近年最為 Gamers 所認識的，可能是美國遊戲「Portal」的 "Still Alive"。

但我最喜愛的，還是幾個日本遊戲的主題曲，它們除了音樂好聽外，歌詞也很好。

○ Zone of the Enders - 2nd Runner "Anubis" (Opening)

○ ICO - You were there (Ending)

○ Panzer Dragoon Orta - Anu Orta Veniya (Ending)

這樣的遊戲我才喜歡

2010-01-28T22:28:00.004+08:00

大約在半年前，買了一部 XBox360 回家遊玩，在這段時間中，我買的遊戲其實有限，而且有幾隻都是買特價版本 ( 推出了一段時間的遊戲，用優惠價再包裝推出的那種 ) 。到了近期很喜歡的「Bayonetta」，實際買來玩的遊戲可以說是寥寥可數。

複雜的遊戲，我一向都不在行，例如 Sony PlayStation 的 GT，或是一些 RPG 遊戲，只要是遊戲系統要花上多一點時間學習，往往我都不會接觸，如果接觸了，也很容易中途放下。有些遊戲，例如「Bayonetta」和「汪達與巨像」，雖然這兩個遊戲也不太相同，但都有一個很好的共通點，就是很容易入門，玩家可以很容易掌握到遊戲及其系統。雖說入門容易，但它們的設定都是頗為深入的，在玩得熟練一點後，都能夠發掘到另一個層次或新鮮事來挑戰。

總是在想，遊戲要「好玩」，就好像要讀好心理學一樣，從人的習性中，找到吸引人的東西，將其轉化為遊戲系統。

怎麼樣的遊戲才會好玩？或者先將範圍縮小一點，以我喜歡的「動作類遊戲」來說，怎樣才算好玩？先要從「爽快」處入手？然後在上面加入「多變」？之後再加上「難易度調整」？最後加入「特定挑戰」？

對於遊戲設計來說，我不是專業，所以上面說的都不能作準。近年好玩的遊戲真的可遇不可求，所以我在換新電腦後，也找來了辦法，重玩 2005 年的「汪達與巨像」，重溫一下好遊戲的感覺。

John McClane 的「游擊戰」

2010-01-17T22:29:00.004+08:00

我近來在 Facebook 上，很喜歡用「游擊戰」來比喻工作上的情況，有人問道何謂「游擊戰」？我所說的游擊戰，會是解說為：

就像電影「Die Hard」中的主角 John McClane，每次身邊甚麼也沒有，只得自己隨身的一把半自動手鎗，沒多沒少，但要處理的往往不是一件簡單的小偷案。

要是形容在現實中，工作的時候有如在參與游擊戰，就有如電影中的 John McClane，你沒有適當的工具，為了完成手上的工作，你只能夠用所僅有的知識，和身邊一些零碎的文具，來盡量地完成工作。過程是艱辛的，而且沒有任何保證，例如若工作要求有任何改變，往往得重頭開始。游擊戰很適合一些年輕的人，或剛進入社會工作的畢業生，因為每天所發生的情況也可以不同，感覺是刺激的，及充滿挑戰的，希望爭取每次學習經驗。

John McClane 不太享受當中的挑戰，每次也是逼不得已，他每次可以做的就只是自娛一番，然後用他認為最好的方法應對，遍體鱗傷地完成工作後，最後就連道謝也得不到。但至小他也有幸福的一刻，他的妻子。

p.s. 多月沒寫 Blog，新年一來就說些和 Game programming 沒關係的事......。祝大家在 2010 年有更好的發展！

另一個 Audio / Sound Engine

2009-11-12T22:51:00.002+08:00

一直以來，也在找一個可以代替現在使用的 Sound Engine，但是總是找不到一個合適，而又是價廉物美的 ( 還希望可以免費呢 )。前幾天找到了，這個就是 SFML 。

其實這個是一個 Multimedia library ( 就好像 SDL 般 )，當中包含了一個 Sound Engine 部份，而這部份可以無痛地加入到 Ogng'3D 中，另外它也支援 MinGW 及其他 Platform，不錯的說。因為我的 Ogng'3D 不是要用來開發如 RockBand 的音樂遊戲，所以我不需要使用一些 Effect 功能，所以便選擇了這個簡單輕便的 Library，其實自己早已知道這個 SFML 的存在，但總是找不到時間看看它，就在過去的週末時間，認真地用點時間看看，很快便已經將它裝進 Ogng'3D 了。

順帶一提，這套 Library 是使用了 zlib / png license 的。

一個使用 OGRE 的遊戲 : TorchLight

2009-11-07T21:30:00.009+08:00

被外界喻為 Mini Diablo 的遊戲：「 TorchLight 」剛剛推出了，吸引我的除了是她使用了 OGRE 作為 Rendering 部份外，還有另一個吸引我的地方。

前幾天有位同事介紹我看這遊戲的工具：「 TorchLight Preditor 」。看過這工具的系列 Video 後，便覺得這工具很有啟發性，尤其是對於我這種製作工具的初哥，當中確實有很多值得參考的功能。( 請大家不要，以太過自我保護的方向去看它，例如「這工具只適合做這類遊戲」之類，這樣會錯過了它的啟發性。)

最喜歡它的 Logic 部份，因為這部份可以由 Designers 完全控制，不需要任何的 Programmer 協助下，完成 Level Design，還可以即時試玩，起動亦很快速，簡單說：就是很好用！

雖然這個目標很...遙...遠...，但這工具真的很有參考價值。

資料：Youtube 的影片

閒來的 Ogng3D 工具更新

2009-10-26T18:34:00.005+08:00

之前說過，我重新製作 Ogng3D 的設定工具，但在那之後，發覺其他工具也衍生了一些小問題，例如 Render Window 大小錯了一點點。所以在這幾天的重陽節假期，整理了其他工具的一些小問題。

有趣的是，在整理工具的問題時，卻忽發奇想地想到了一些點子，從中亦改善了 Ogng3D 中的一些功能。例如將所有的 Plugins DLL 都放到一個 Folder 裡面，可以在 ResourceGroup 以外的地方讀除 .cfg 檔案，Event 系統中的單一 Event 可加入多個 Callbacks ...... 等等。這些一點點的功能改善，雖然不是甚麼大功能，但卻可以在使用 Ogng3D 時更方便。

點子不單單是在一些細節上，亦在新功能上有一些，那是甚麼？就是人物更換裝備了。這個點子幾個星期前已出現在腦裡的了，可是 OGRE 是那麼的複雜，總是很難找到適當的方向或答案，但在這兩天好像看到了方向，遲些要找些時間來實驗一下。

看看現在的 Ogng3D，發覺她已經有八百多個 Functions 了，DLL 的檔案大小是 990KB ( Release 版本 )，對於一個 Game Engine 來說，可能不是很大，但我總是覺得有點臃腫，可能是因為 OGRE 吧，臃腫的感覺就是揮之不去。

Bayonetta 的一些有趣資訊

2009-10-16T23:42:00.002+08:00

話說，新遊戲「 Bayonetta 」即將推出，我剛才便去一去官方網站看看，那裡其實有一個開發 Blog，良久之前到過一次，在她發售前去看個究竟。

當中有很多篇 Blog 也很不錯，其中有數段有趣的，和大家分享一下：

Prototype 影片：這片段看到遊戲初時的試驗。

Gameplay 影片：這片段有趣的地方是，當中沒加入任何 Effect

Source Code 影片：顯示了其中一個 Source code 檔案，內裡有 13000 行，而整個 Project 有約 1800000 行 Source code。

Generic Approach

2009-10-10T13:01:00.007+08:00

其實，一個遊戲引擎 ( Game Engine )，究竟能否用「 Generic Approach 」為方向呢？

為什麼要用 Generic Approach 呢？用這方案的好處，是比較容易組合配件，擴展性高而且靈活 ( 同事說，編程弱的也可容易做到，但我卻不懂... )。那麼究竟實際上是怎樣的呢？我個人的意見是，Generic Approach 是不適合用來製作 Game Engine 的。

電腦遊戲有很多很多的種類，尤其是 3D，是不太適合 Generic 化 Game Engine 及製作流程 ( 文檔處理不計算在內 )。適合 Generic 化的，只是 Graphic Engine、Audio Engine、Physics Engine 或 Script Engine。當所有東西組合成一個 Game Engine 時，需要的不是 Generic Approach，而是類似 middleware 的 API 或工具，Game Engine 的出現，就是可以提供這類 API 或工具。如果每一個遊戲，都是從那些單一 Engine 組成，那麼 Game Engine 的存在是怎麼樣的價值？

2D 或小型遊戲可能比較適合 Generic Approach ( 左圖 )，而 3D 遊戲就要適合的 Game Engine 工具來製作 ( 右圖 )。

最後補充一些，我想說的是不適合，不是絕對不可以。其實，甚麼事情也可以 Generic 化，只是看看最終出來的結果會是怎樣而已。

VirtualBox 下的 Ogng'3D

2009-10-01T19:49:00.004+08:00

在兩個星期前，忽發奇想地想在其他電腦上測試 Ogng'3D，所以便找來了 VirtualBox 軟件來試試。

圖中我在 VirtualBox 中執行了一個 Demo (OpenGL)，再在我的電腦上執行同一個 Demo (DirectX)，我有點驚喜的，因為在 VirtualBox 中執行的 Demo，執行速度上也真的很不錯，雖然 Demo 中只得一個 Actor (Entity)，但感覺真的很有趣。

動作遊戲的下場

2009-09-27T20:04:00.005+08:00

製作動作遊戲，一直都是我的目標，雖然我踏出過一步，但距這目標還有很遠。

其實動作類遊戲在遊戲市場上，比起其他類型，佔的百分比一向都較高，但是在 3D 的遊戲世界中，你總是很難找到一隻「讚好」的動作遊戲。近來有多隻動作遊戲出現在遊戲市場中，例如：Mini Ninja ( PS3 / XBox360 / PC )、The Warriors: Street Brawl ( XBLA )。試過這兩隻遊戲，有點對現在的動作遊戲的感想想說說。

先說說 Mini Ninja，初時在試玩的時候，感覺也可以的，但總是感覺到一種不協調，但就是說不出來是甚麼不協調。後來和朋友討論這遊戲，朋友一語說中了我想不通的不協調感覺，那就是『悶』！Mini Ninja 一個很敗北的點子，就是用了非常大的地圖，而且有分支路可以回到起點處。一個動作遊戲，有機會令玩家在地圖上轉來轉去而到不了目的地，而且每每玩家走上超過 100 公尺，也沒事好做的，令遊戲變得不是一般的悶。

再說說 The Warriors : Street Brawl，玩過試玩版之後，我不太相信會有人給錢下載它，因為在遊戲設計上，實在是太爛了。玩家可以被僅僅三隻敵人圍堵不停打至倒地，完全不能有反擊，雖說可以用擋格來擋住敵人的攻擊，但是敵人跟本就是不停地攻擊。玩家可以用 Super Attack 作無敵反擊，但是此招式時間短，範圍細，用途跟本只有一個：就是用來逃命的！此遊戲的設計，跟本沒有動作遊戲應有的爽快感，有的是遲鈍及挫敗感。

一些小型動作遊戲製作公司 / 獨立製作人，雖然有不錯的遊戲系統，但總是不能成功推出市場。例如「 Hurricane X 2 」，遊戲系統看來也不錯，但是據資料表示，這遊戲多次參加了 XBox 的「 Dream、Build、Play 」比賽，但總是不能入圍，都了今年才能夠在 PAX 中出場。動作遊戲究竟要努力多少年，才能得到各發行商的關注？看來還是那一句：「距這目標還有很遠。」

Ogng'3D 的設定工具

2009-09-20T13:33:00.011+08:00

市場上有很多遊戲，都會有自己的一個遊戲啟動工具 ( Game Launcher )，當中大部份也會有一些遊戲引擎的設定功能，讓玩家在啟動遊戲前可以改動一下。

我亦有為 Ogng'3D 製作過一個遊戲設定工具，但是其中有些設定是 hard code 的，所以不是那麼「有用」。昨天決定用一些時間，特地為它的功能完善化，最基本的就是不用再 hard code 當中的設定資料。

首先運用 OGRE 的基本功能，啟動 Ogre::Root，再載入 DirectX 及 OpenGL 的 Plugin，從中套取可使用的畫面解像度。大約用了半天的時間，完成了這個功能，再用了少半天 Debug。

這工具的存在價值，在於 OGRE 的實時改動 Full-Screen 及 Windowed 模式，便會出現問題，為了解決這種難解的情況，最好的就是製作這個工具，讓玩家在啟動遊戲前可以做點改動。

CEDEC 2009 的一些話

2009-09-02T23:38:00.004+08:00

別要誤會，我沒有出席今年的 CEDEC 2009，我只是看了幾段有關遊戲製作的演講 Slide，有感而發，如果你也懂小小日文的，不妨去看看：

「Demon's Souls」的 Game Design
　　當中有幾點真的很有趣，說道近年遊戲製作的趨勢，及其中問題所在。Demon's Souls 的製作核心價值。Network 帶給 Game Play 的是甚麼。

導入物理引擎的製作探討
　　使用物理引擎來製作遊戲，是極麻煩的又一鐵証。

不知怎的，總是覺得那些來自日本的遊戲製作經驗談，都是特別動聽的。:-P

謎之 C::B + MingW + OGRE 問題 !

2009-08-30T22:33:00.007+08:00

在製作 Ogng'3D 的工具上，我會使用 Visual C++ Express，因為它是免費嘛，但因為它是 Express 版本，要 Deploy 的話，可以說是非常麻煩，所以，如果要用 Release 版本來 Deploy 給普通用家，我會使用 Code::Block + MingW 來完成。

這個形式一向都沒有問題的，但昨晚在測試 Release 版時，發現在計算 Quaternion 時出現了問題，如下面 [左圖] 般，而 [右圖] 的 Debug 版本 ( Visual C++ Express ) 卻一點問題也沒有。

最可惡的是，Visual C++ Express 的 Release 也沒有問題，究竟 MingW 有何問題了？

Character jumping style, game-play

2009-08-29T00:14:00.006+08:00

我很喜歡玩動作遊戲，但是歐美的遊戲都會令我卻步，為什麼呢？其實有很多原因，多數是一些「感覺」的差別，但那些差別很多人也不太明白，我在這裡希望能夠為大家說一說。

跳躍 (Jumping)，在動作遊戲中必然會有的，而跳躍亦是一項非常重要的「感覺差別」，我特地編寫了一個 Demo，從影片中顯示一下，日本式遊戲，和歐美式遊戲的差別：

片中看到的，是以垂直上跳躍為例，看過之後，覺得怎樣？會不會覺得很大差別？而你又比較喜歡那一種的跳躍呢？

在日本式的遊戲中，多數會分開垂直跳躍及向前跳躍兩種動作，而歐美遊戲就多數只用一種跳躍動作。

修復斷層 & 更新

2009-08-27T23:07:00.001+08:00

兩個月了，沒有說過有關遊戲 / 引擎的開發話，因為工作上有點忙，都沒有多少時間可以用於開發上。

早前曾經說過，Ogng'3D 開發 ( 再三 ) 支援 Animation BlendMask 之後，當中舊的 Animation 控制部份，和現有的 Actor 工具有點斷裂了，總是沒有時間來修復，這幾天榨取一點點時間來修復一下。因 Animation BlendMask 完全後，整個 Animation 控制同時支援 Blending，所以舊的 Animation 控制部份便可以除掉，全部都用上新的有 Blending 功能的 Animation 控制。而且今晚想到了一個新的點子，就是在 Animation Event 控制中，加入一個單純的自動跳到另一個 Animation 的功能 ( 可開 / 關 )，那麼一個簡單的 Animation transition，在 GamePlay 製作時便不用特地加入單一 Event Callback function 了。

同時，亦簡化了現有的 Event 系統，希望速度上能夠快一點點。但是，有關 Sprite 的製作工具方面，還未有一些進展，始終礙於 MilkShape3D 的功能限制，要做到不離開 MilkShape3D 而製作出可用的 Sprite，確實不是一件容易的事。

那是用家的軟件

2009-08-18T23:57:00.006+08:00

我所製作的 Ogng'3D 遊戲引擎，或是過去的一些簡單遊戲，都是自己獨力完全，因為身邊的朋友多是玩遊戲，對製作遊戲而言都沒有興趣 ( 多是幫忙試玩一下遊戲 ... )。這個方法有一個好處，就是可以隨心所欲，做自己喜歡做的工具，而且不需要聽取其他 Artist 的意見 ( 因為我就是當中唯一的 Artist )，只要做出想做的遊戲就行了。所以，Ogng'3D 遊戲引擎我用得很順暢，就如我之前說過的，用它來製作遊戲時，都覺得不像在編寫電腦程式。

愈接觸得多遊戲製作流程，就愈覺得工具是否好用的重要性。我所說的工具，不是只說 3DStudio Max、MAYA 又或是 XSI 等等，它們有多強大的功能也好，但是卻不能夠完全滿足於製作遊戲，因為電視 / 電腦遊戲中，可用的資源真的很有限。所以遊戲製作公司都會因應自己的遊戲引擎，製作一堆自家遊戲開發工具，來方便公司裡的員工製作遊戲的內容。

我這一種「閉門造車」的習慣，其實不是一件好事，因為跟本沒有任何用家反饋 ( User Feedback )，而好的用家反饋，就是開發工具的進步源頭。如果你是一名遊戲開發團隊中的 Artist，或是從事內容製作，那麼你有沒有對使用中的開發工具，作出任何用家反饋呢？記著，這個對於遊戲製作流程是很重要的，一個遊戲能否順利地製作完成，好的用家回饋是非常重要的。

p.s. 確實，有時候說出反饋時，感覺有點像對牛彈琴，最後只會被忽略，但只要是問心無愧，那何懼之有。

向成功學習

2009-07-12T14:10:00.002+08:00

我曾經是一個蘋果電腦的用家，家裡還有一部 Mac Mini，一向也很喜歡 Mac OS 的軟件，因為在很多方面，設計上都很人性化，及充滿了親和力。

What open source can learn from Apple

很多時候及情況下，向一些已成功的人或事學習，是讓自己得到成功的其中一個捷徑。我也準備，自己的遊戲引擎的工具，向 Unity 學習一下。

The best game dev. tool these years !

2009-06-20T17:59:00.003+08:00

近年最流行的開發工具：

Action Game, Combo design !

2009-06-20T13:31:00.007+08:00

說到 Action Game 動作遊戲，都是一連串連續攻擊，敵人被玩家打得招架不來，從而令玩家們得到極大樂趣。但是動作遊戲一向都是一個非常難的題目，只要有一點點搞不好，例如連續技 Combo 設計上，沒有吸引力的話，玩家就會離你而去。

之前任職 Capcom 遊戲 Devil May Cry 的製作人，離職後到了 Platinum Games 製作 Bayonetta，遊戲就像 DMC 的孿生兒，但在 Bayonetta 當中的 Combo action design，和 DMC 比較可說有過之而無不及。

Bayonetta Combo Megaton Gameplay (video)

日式動作遊戲是否已死？我說，還看日本遊戲製作商的取向，我這類自小被日本動作遊戲薰陶的玩家，對歐美的動作遊戲從來提不起興趣，但是日式動作遊戲，在 3D 遊戲世界中確實有點不濟，快點努力起來吧！

Animation BlendMask 再三造訪

2009-06-14T22:49:00.001+08:00

有時候，做完一個 Engine 功能之後，未實際使用過，始終也不能證實它有否問題。就像之前做的 Animation Blendmask 功能，初時以為完成了，但在實際使用時，又再次發現很多問題。

問題主要是，當程式要不停轉 Animation 時候，Blending 便會有機會出錯，又或是沒有作出任何 Blending。這些問題，多數是自己在處理 Animation 轉換時的一些邏輯錯誤，對於 Animation Blending 範疇，自己是個初哥，都是要實際使用才會發現問題的存在，這也是製作 Game Engine 有趣的地方。在這兩天的週末，都埋首在家中測試及修正 Animation Blendmask 的問題。

當然我也不能肯定，這個功能還有沒有問題，這個始終要在實際使用才會得知呢。

剛才又發現，因為 Animation Blending 的功能改動了，Actor 的製作工具又 Crash 掉了。對於這些不斷的重複重複又重複的修正，真的令人沮喪及洩氣，開始令我覺得煩厭了，看來我不應該再在 Ogng'3D 裡，將舊有的功能提昇或改動，因為不斷的修正，確是很煩擾的。

E3 2009 後的思維

2009-06-06T00:14:00.004+08:00

大家也看過 E3 2009 的各大新聞了吧，怎樣了？有些驚喜，有些失望，有些平淡？自己有點意見想表達一下。

● 微軟，今年妳真的很威風
● 老任，快點醒來吧
● 索尼，有總比沒有好

還有，Capcom 到現時還未有交代，今次會發表的兩個秘密遊戲是甚麼，看來多間遊戲開發商因為 H1N1 缺席 E3，索性也將發表新聞的動作也免卻了。

p.s. 人生有幾多個十年？

預測炒冷飯遊戲

2009-05-28T23:32:00.004+08:00

一年一度，又是 E3 的日子了，今年有一個題目吸引到我的注目，就是 Capcom 會在 E3 中宣佈兩款秘密作品。

外界有很多估計，當中很多人也說是 Devil May Cry 新作，但前幾天有消息指出，秘密遊戲牽涉幾個要點：
● 不是 Devil May Cry
● 是一個動作遊戲
● 是 Capcom 的老遊戲角色，但不是 Remake
● 屬原創角色

好了，不會是 DMC，那麼會是甚麼？有些人想會是「鬼武者」，我在這裡先說說我的估計，我估計新的秘密遊戲，將會是「 Strider 飛龍」。而我在看完這篇訪問後 ( 雖然這訪問很舊，但我之前是從未看過呢...... )，我有多一個估計，就是「 Captain Commando 」。

我們就看看，究竟我的估計是對還是錯吧！ :-D

Final Spike 重新 upload 供下載

2009-05-10T17:23:00.004+08:00

因為朋友的網站在兩年前停了，一直都沒有更新過「 Final Spike 」的下載連結，終於今天重新 upload 了，如果大家有興趣試試的，請到「 Final Spike 」的頁面看看。

Final Spike v1.0.0.1 Alpha
　

技術性的選擇 ( 2 )

2009-05-10T16:26:00.002+08:00

剛才到訪過 GameProducer.Net，看到了他早前的一篇文章，題目為「 Some Things Dead Wake Development Has Taught Me 」。文中說了他在製作遊戲時，學到的五個要點，當中四點都是牽涉到「選擇」。

選擇 Technology，不要用自己不在行的方法，這個真的很重要，因為這個和 Project 進度有很大的關連。如果要你用一個你不熟悉的環境工作，確實只會令你事倍功半。選擇 Engine，使用一個成熟的遊戲引擎，亦是很關鍵的事情，也和 Project 進度掛勾。工具的轉變，往往都會令工作重新開始，這會令製作人員士氣退減。選擇 2D 還是 3D，文中帶出一個很重要的問題，就是 3D 的 Art pipeline 是很費時的，尤其是 Animations，會令 Artist 和 Programmer 的工作增加。選擇聽取意見，不要聽一些沒建設性的意見，聽取意見後亦要思考其價值。我常常也會提醒自己，在提出意見之前，要有合理及建設性的理念做支持。

近來看過幾篇有關「選擇」的文章，確實令自己對 Production pipeline 的知識增加了不少，對於自己往後的 Project 也有很大的幫助。

假期中的病情

2009-05-03T17:46:00.003+08:00

剛剛過去的星期五勞動節，因為有點喉嚨痛，去看醫生了，同事們，明天回辦公室很驚慌吧？！ :D :D

除了有點小病之外，這個多星期也不停與傻記的寬頻服務周旋，因為過去的個多月內，它的寬頻 Modem 不時出現沒有訊號傳送，我九成時間不能上網，技術人員們上門維修好幾次，但他們走了後不久便再次沒有訊號，甚為懊惱。

在小病及沒寬頻的假期，便只有乖乖地呆在家裡。這樣也有好處，沒有其他的引誘，能夠專注地整理一下 Ogng'3D 的工具，因為在前陣子在 Ogng'3D 中加入的 Animation Group ( Animation Blending ) 功能，令 Actor 部份功能出現斷層情況，令 Actor Editor 工具不能正常運作，這幾天便可以好好地坐下來，完成功能斷層的修補工作。

Project 「 Grand Hunting 」

2009-04-27T23:17:00.003+08:00

在我的心目中，有些遊戲是很想做的，它們大多是動作遊戲，例如「 Final Spike 」的格鬥遊戲。

在前一陣子，我嘗試過一些簡單的 Networking 程式編寫，成功地將兩部 LAN 內的 PC 連線起來，各自控制自己的角色移動之餘，也看到對方在移動。在這個頗成功的試驗後良久，這幾天決定了，希望做一隻新的遊戲，名字方面暫時名為「 Grand Hunting 」。遊戲內容及 Game Play 也是一個動作遊戲，而且是 LAN 內連線遊玩 ( 我的 Ogng'3D Networking 部份還未支援 NAT 對外連線... )。

在剛剛過去的週末，在家中做 3D Model，不知道手腕是否有健康問題，做了一會兒 Model 後，手腕便感到痛楚，不能長時間做 Model 製作呢..... :-(

技術性的選擇

2009-04-25T13:53:00.002+08:00

大約一個月前，一位朋友所製作的遊戲推出了，幾天前和他在 MSN 上聊聊，我很好奇地問他，在製作這個遊戲的時候，是用甚麼方法來設定每一個 Level 的資料，他說道，初時都想做好自己的製作工具，如 Scene Builder、Model Viewer、UI Editor 等等。但是後來他說，他們最後沒有製作所說的工具，反而是使用在購入的 Game Engine 中帶有的 Scene Builder 來製作。他說在製作後期學會一樣事情，就是與其自己製作工具，倒不如買個工具回來用，他給了一個例子，就是初時開始做 UI 的時候，處處都是不順利，到了製作後期，決定轉用 SCALEFORM，而這個決定就讓他們從 UI 地獄中逃出來。

在遊戲製作的實際情況上，技術性的選擇，往往都是順利與否的其中一個關鍵。以我自己的 Ogng'3D 及上面的 UI 情況為例子，一直想用 Sprite 功能來製作 UI，但 Sprite 的結構上，都是 Programmer 向的功能，除了 Hard Code 之外，完全沒有任何工具可以製作 Sprite 的。我自己是使用 MilkShape3D 來製作 3D Model 的，曾經想過在其中製作 Sprite，然後用這些 Sprite 製作 UI ，後來覺得在 Pipeline 上要牽涉的步驟過多，所以暫時擱置了。

要做就一個暢順的製作 Pipeline，在技術使用的選擇絕對不能馬虎，若能夠使製作 Pipeline 完美及暢順地運作，相信在遊戲創作上，能夠有足夠的空間發揮。

Game Engine ？

2009-04-16T00:32:00.004+08:00

剛才在網上看到，一個頗出名的 Game Engine 「 Gamebryo 」，推出了新的版本，名為「 Gamebryo LIGHTSPEED 」( 名字很響亮呢 ) ，看過她的功能介紹後 ( 其實也真的頗充實的... :P )，突然興緻到來，想起一個問題，這個問題相信有很多人問過，或者很多人想知道：「 Game Engine 是甚麼？」

今時今日要找答案，或溫故知新，當然是到 Wikipedia 看看了。在 Wiki 中看到 Game Engine 的定義說明，當中在 Overview 一項內一段比較有趣的說明：

〝Some game engines only provide real-time 3D rendering capabilities instead of the wide range of functionality required by games. These engines rely upon the game developer to implement the rest of this functionality or assemble it from other game middleware components. These types of engines are generally referred to as a "graphics engine," "rendering engine," or "3D engine" instead of the more encompassing term "game engine." However, this terminology is inconsistently used as many full-featured 3D game engines are referred to simply as "3D engines." 〞

我回來看看，自己的 Ogng'3D 是不是一個 Game Engine？用 OGRE 作為 Rendering / Scene Management / Animation，用 IrrKlang 作為 Sound System，以 Newton Game Dynamics 為 Physics / Collision，及以 enet 為 Networking。

看來有一點點像 Game Engine，功能看上去也不錯，而且還切合 Cross Platform 需要 ( 部件都有 Windows、Linux 及 Mac OSX 平台支援 )。但跟據 Wiki 的說明，還要有 Scripting、A.I.、Memory Management、Streaming 及 Threading，看來距離 Game Engine 還有一段路要走。

怎說也好，最重要的：Happy Game Making！

為什麼要有 Examples ？

2009-04-13T16:49:00.004+08:00

其實應該在很早之前，便要為我的 Game Engine 「Ogng'3D」製作 Examples，但不知為何，總是提不起興趣來做。在這幾天的復活節假期，終於為她製作了幾個 Examples，及一個 Examples 的 Workspace。

為什麼要有 Examples 呢？ Ogng'3D 只是我自己使用，應該不需要 Examples 來作為用家指引。但近來我發現了一個問題 ( 終於... :P )，就是 Ogng'3D 中有很多功能，自己忘記了怎樣使用，常常要看多兩眼才記起使用方法。就是這個情況下，我決定還是要用點時間，為她製作一些簡單的 Examples，作為自己參考的用途。而且，使用 Examples 作為測試平台，也是不錯的選擇。其實說到尾，我自己也是個用家啊，也會有需要用家指引的時候。

Animation BlendMask 的再訪 ( Revisited )

2009-04-10T18:11:00.004+08:00

早前曾經說過，我試驗過 OGRE 中的新功能「 Animation BlendMask 」，那時候我說過，在試驗的期間，很不容易才看到一點點成績。雖然是有成績，但是在整合上有很多問題未解決，所以便放下了一段短時間。

前陣子再訪這個閣置了的 Animation BlendMask，在初時，愈是試驗的多，就愈是覺得之前所試驗的方法是錯誤的。後來用了兩天的時間，以另外一種方法來試驗 BlendMask，而這樣亦證實了，我之前的認知確是錯誤的。我之前所用的方法，是改邊 BlendMask 的數值，這個方法使我困在兩難中，第一是由 Animation A blend 到 B 中，都要每個 Bone 設定 BlendMask 數值，第二是由 Animation B blend 回 A 時，但當中的設定卻要用不一樣的數值，變得非常不協調及不能系統化的問題。

後來我忽然想到，其實我要改變的數值不是 BlendMask，而應該是 Animation State 本身的 Weight 數值。就是這個想法，便成功地系統化了 BlendMask 功能，然後將其套入一個名為 Animation Group 的 Helper 中，將個別的 Bone 都歸入指定 Animation Group，而每個 Animation Group 都有一套 BlendMask 資料，當要播放 Animation 時，便將 Animation State 放入 Animation Group 中，同時改變 Group 中的各個 Bones 的數值，然後 Playback 這個 Animation State，成功地將 Animation Blending 變得系統化及易於管理。

次世代遊戲的 GamePlay 問題

2009-04-06T21:45:00.004+08:00

次世代，是指下一個新世代，還是次一級的舊世代？中文字有趣的，就是可以隨時改變演繹方法。

次世代，當然是指下一個新世代了，其實以現時的遊戲開發發展，好像已經沒有「次世代」了，因為技術層面上已經沒有了這個框架。回來說正題吧，上星期看了一本報導有關遊戲製造業界的雜誌，裡面翻譯了一篇由日本 Konami 的惡魔城開發隊的演講，當中提及了 2D 和 3D 在遊戲設計上的問題，而且問題都和 GamePlay 有很大的關係。

文章中說道，3D 遊戲最大的問題是「距離感」，在 2D 遊戲中，玩家很容易地看到主角身處的位置，從而直觀地感到和地圖中的其他人物，和物件的「距離感」，但是 3D 遊戲就是不能夠輕易地做到。這個同時亦解答了，為什麼 2D 遊戲，現在仍有一大班忠實擁躉的原因。確實，3D 遊戲中，玩家們對主角和其他人和物的距離感是很矇糊的，唯一較容易的方法，就是以人和物之間的影子來判斷距離。

另一個問題，就是 Camera 了。還記得在 3D 遊戲出現的初期（ SEGA Saturn / Sony PlayStation 年代），我已經飽受不協調的 Camera 所虐待，有些遊戲的設計本是很好的，但因為這種 Camera 的問題，而被很多玩家評擊致體無完膚（這亦是我為什麼對 Camera 系統很執著的原因）。而 2D 遊戲就是沒有這種 Camera 問題，純粹的 X 及 Y 的畫面捲動，跟本就不會有不協調 Camera 問題存在。

比 2D 多了一個 Z 軸的 3D，在遊戲設計上不只是多了一個問題，而是多了數不完的問題。還看一些 3D 遊戲，簡潔及讓人容易明白的設計，都會有很好的評價和銷量，例如 Call of Duty 4，在設計上令玩家們都很容易明白遊戲的進程，它沒有很獨特的圖像表現，但卻能夠令不少玩家對其心儀。

改做背景地圖的架構

2009-03-22T00:45:00.003+08:00

在上次的 SceneNode 測試中，得出了一個結果，就是在 OGRE 中如果有很多 SceneNode 的話，速度便會快速地下降。後來我想想，我的 Ogng'3D 中的背景地圖的 Portal 處理，每個背景物件都使用了一個 SceneNode，這樣便用了很多 SceneNode 來定義 Sectors，就以那個「多 SceneNode 便慢下來」的情況下，我便決定重新去想想，如何改善現在的 Portal 地圖架構，改變處理方法來減少 SceneNode 使用量。

改動已有的系統需要不少工程，因為從 Load 入 Portal、載入每個背景物件的 3D 資料，以致測試 Portals / Sectors 的等等步驟都牽涉到。

在今天 ( 星期六 )，用了一整天的時間 ( 真的超過 12 個小時呢 ... )，從兩晚前草草訂下的計劃中，完成了改造。改造後的背景地圖仍以 Portals / Sectors 為主，在背景地圖組成方面就改了「以 Material 來做組別」，使用同一個 Material 的背景物件，都用同一個 SceneNode 及 Entity 組合起來，就是說 SceneNode 數量和 Material 數量掛勾，而每一個背景物件就是一個 SubEntity。因為在我設計的地圖的資料中，已有各個背景物件的資料，在測試 Portals / Sectors 方面的改動，只是在測試後，改變相關 SubEntity 的 Visible 值便可。

這樣使用 SceneNode 量便可以減少，從而可減少 OGRE 中的 Drawcall 數量，增加 Render 背景地圖的速度。希望這個改動工程真的有效吧，因為我還未有一個有很多背景物件做測試的地圖 ......。

目標 : Vertex Animation 功能

2009-03-14T19:36:00.007+08:00

對了，Vertex Animation 會是我下一個目標。

Vertex Animation 是個很久遠的技術，在早期的 3D 遊戲中已有使用，那時候 3D 角色的動畫全部都是用 Vertex Animation 做的。後來 Skeleton Animation 的興起，便代替了這個技術，但它並未就此被忘掉。

其實在現時的 3D 遊戲中，Vertex Animation 的用途在哪裡呢？主要是 Facial Animation。而我想開始做 Vertex Animation 的原因，就是因為想在 Ogng'3D 中，加進 Facial Animation 的功能。

還可以做一大堆的手部動作，代替手部大量 Skeleton 動畫。正在努力中，謝謝。

OGRE 的 SceneNode 挑戰

2009-03-13T00:20:00.008+08:00

究竟 OGRE 這個 3D 圖像引擎，是慢還是快呢？這個沒有確實的定論，因為每一個圖像引擎都有它的特點 ( 牆頭草言論 :D )。

今天聽到同事們說，OGRE 中的 SceneNode 在更新方面未盡善盡美，一多起來便會很慢。我也不知道當中的問題在哪裡，因為我從來沒有了解過她的內部運作。今晚回家後，便想試試如果 SceneNode 真的有很多，那麼會慢了多少？

下圖是我用了之前測試新 Sprite 系統的 Demo，轉為直接每個 Sprite 都用一個 SceneNode 來控制，總共有 256 個 Sprites，同時在畫面中從左到右不停的移動，而且還用了我新加入的 SpriteGroup 系統，另外再畫出 500 個 Sprites ( 只用一個 SceneNode，但很難看得到，因為前面說的 256 個 Sprites 已經很密集 )。

Demo 的整體速度當然是下降了，但在百分點上，大約是慢了 30%。我不太清楚這個數字是不是很差，但在於我來說，它能夠保持在 60 Frames per second 的速度，已經很不錯的了。

Animation Blend Mask 測試

2009-02-26T17:19:00.006+08:00

昨天說過，會嘗試用用 OGRE3D v1.6 中的 Animation Blend Mask，並整合到我的 Ogng'3D 遊戲引擎中。我用了大約 10 個小時，有了一點點的成果，看上去真的很利害 ( 這個是很重要的 f(^_^') )，當然要給大家看看了。

這個還是在測試中，大家看到片段中，從 Single-Animation 轉到 Multi-Animation，或 Multi-Animation 轉回 Single Animation 時會有 smooth transition，但這功能很難搞，仍有不少問題，還要努力測試。

自己的假期

2009-02-25T22:38:00.003+08:00

明天開始，便會放幾天大假，但沒有甚麼出遊計劃，那麼做些甚麼好呢？還未有決定，但相信還是會待在家中，寫一點程式。

其中有一樣技術一直想試驗一下，在 OGRE 1.6 開始，新增了一個 Animation BlendMask 功能，透過這個新功能，一個 Entity 中的動畫可以重疊使用，例如上身在用鎗射擊，下半身在跑著。總是覺得，動作遊戲有這些多重動畫結合，真的很有用。

另外，看到自己的 Ogng3D 中，Actor ( 角色控件 ) 物件方面太多 Functions 集中在一起，看上去真的很巨形，自己希望嘗試將這部份分拆成小件，做點 Refactoring。加上上面說的試驗 Animation BlendMask，這個自己的假期也算是充實吧。

Billboards 與 2D Sprites

2009-02-20T00:04:00.014+08:00

在兩個星期前，我嘗試重新製作 Ogng3D 遊戲引擎中，用 OGRE 中的 Billboard 來做 2D Sprite 的方案，未改做前的 2D Sprite 是充滿著問題，而且還不能控制 Z-Order。這個重新製作用了不到一天時間便完成了，因為在測試期中發覺只需改一些地方，便能夠做到控制 Z-Order 的方法，對於 2D Sprite 系統來說，控制 Z-Order 是非常重要的事情。

今晚決定要試一試這個新的 2D Sprite 系統的速度上會是如何，我的家中有兩部電腦，它們的硬件是：
● AMD Athlon XP 1600+ 及 NVidia 6600 LE (AGP)
● Intel Pentium 4 3Ghz HT 及 NVidia 7600 GT (PCI-E)

我的測試是，Demo 會從畫面的正中央，不停地放出一個已隨機 Rotate 了的 Sprite，移動到畫面邊緣會停下來，不會刪除掉，總共放出 1024 個 ( 或而上 )，看看會不會出現明顯慢下來的情況。下面左圖是 AMD 的測試畫面 ( 以 Fullscreen 測試 )，右圖是 Intel P4 的畫面 ( 以 Windowed 測試 )，兩部電腦的測試速度上對我來說確實是很高，感覺不到速度有被拖慢。

新的 Sprite 系統是用了 BillboardSet + SceneNode 完成，初時還以為有這麼多的 Billboard，可能會令遊戲引擎慢下來，但結果是慢下來的情況非常低，甚至有點感覺不到 ( 相信是 3D card 還夠強勁 )。這次成功的改做了 Sprite 系統，那麼便可以真正地在 MilkShape3D 上，製作對應 Sprite 工具了，而且還可以嘗試製作 GUI 工具呢。

Street Fighter IV

2009-02-14T18:53:00.003+08:00

雞巴 4，繼 1998 年的雞巴 3 之後，最新的正統續作。

還記得在 2008 年初次看到那個 Teaser 片段時，打從心底裡說「 Capcom，我不要 3D！」；後來驚訝遊戲真的是 3D ，失望了一段短時間，後來看多了 Capcom 不斷發放的遊戲相關資料後，覺得越看越順眼。在數日前公司有同事買來了 PS3 版本，就馬上的要試試了。

因為之前一直也沒玩過 Arcade 版本，所以還是不懂得用 Saving Attack，只好用老舊的技術玩玩。確實還真的佩服了 Capcom，遊戲性和 2D 的遊戲沒分別，而且表現方法在感覺上也很自然，3D 和 2D 融合得非常的好，Capcom 真有一手，GamePlay 萬歲。順帶一提，Zangief 的「立 Screw 」超容易使出，信心大大回復。

p.s. 「立 Screw 」一詞源自日文，立為日文漢字站立的意思，Screw 為 Zangief 的絕招 Screw-Pile Driver 的簡稱，意指在地上站著不跳躍使出 Screw-Pile Driver 絕招。

九型人格，我 ... 人格分裂？

九型人格分析
第九型	和平型、和平者、和諧型、維持和諧者 15%
第五型	智慧型、觀察者、思想型、理性分析者、思考型 14%
第四型	藝術型、浪漫者、自我型、憑感覺者 14%
第七型	快樂主義型、豐富型、活躍型、創造可能者、享樂型 13%
第六型	忠誠型、忠誠型、尋找安全者、謹慎型 10%
第八型	領袖型、能力型、挑戰者、保護者、權威型 9%
第一型	完美主義者、完美型、改革者、改進型、秩序大使 9%
第二型	助人者、全愛型、助人型、成就他人者、博愛型 8%
第三型	成就者、事業型、成就型、實踐型 8%

我的九型人格分析？

看來我還是做個藝術家比較好。XD

玩遊戲的迷思

2009-01-31T15:20:00.002+08:00

在 2D 遊戲的時代，遊戲都是簡單的操控：十字掣移動，A按鈕是跳躍，B按鈕是攻擊；關卡設計也是簡單的，在設計上就是要你不停地做出指定動作，如果玩家做不到，只是他不夠熟練，一旦玩家熟練後就可以駕輕就熟地完成。Sprite 也是充滿想像空間的，因為記憶體不足的問題，背景或是人物的 Animation 往往都是有限的，但這種有限也給與了玩家的想像空間。整個遊戲除了給玩家遊玩之外，也做就了玩家的一些正面心智成長。

在現今 3D 遊戲設計的道路上，已經很難看到一些和以前 2D 相比的例子。曾經和同事們討論過，究竟為什麼會有這種情況出現？那些簡單但令人中毒很深的遊戲，現在的 3D 遊戲中真的很難找到些例子，究竟問題出在哪裡？有同事的意見是，我年齡增長了，見識和玩過的遊戲也增多了，在要求上變了，但是我卻不太完全同意。

我喜愛玩的遊戲的模式，其實是很簡單的，我做的事情就是：攻擊 ( 連續攻擊 )、跳躍 ( 雙重跳 )、跳躍攻擊、抓住敵人再攻擊 ... 等等。加一點點攻擊或武器的強化工具，遊戲的進程速度爽快，變化慢慢增加 ( 不是難度 )。

想一想，玩遊戲就是想跳出現實，玩樂一會兒，但是歐美大型 3D 遊戲卻以「真實」作為賣點，在玩遊戲的時候要跳入另一個「( 偽 ) 真實環境」，究竟哪裡能帶來一些正面的心智成長？

相關網頁：
● Opinion: How Mega Man 9 Resembles… Real Life ?
● 那些洛克人教我們的事

Retained 和 Immediate Mode 程式編寫

2009-01-28T20:29:00.004+08:00

這幾天農曆新年假期，都沒有特別編寫程式，只是將 Ogng3D 由 Ogre 1.4.9 正式轉到 1.6.1。今天反而想說說一個程式編寫的念頭，就是 Retained 及 Immediate Mode 程式編寫的題目。

就電腦程式編寫方面，很多時都會看到 Retained Mode 的程式，例如 Windows 的程式就是最好的例子，每個程式都是以 Messages 及 Callback 形式執行，這樣的做的原因，在我的理解上，是要 De-couple 程式之間的關係，令程式與程式之間互相不需要倚賴，也能夠完成工作。但是 Immediate Mode 的程式就剛剛相反，程式在需要的時候直接地呼叫另一個程式來完成一個小工作，之間的倚賴性是很強的，如果分開了它們，程式便不能夠完成工作，甚至連 Compile 也不可以呢。

但是兩者之間，除了上面所說的編程風格外，還有甚麼其他分別呢？就我自己而言，是「難度」的分別：Retained Mode 比 Immediate Mode 困難。

在製作遊戲方面呢，會不會有特別的分別？有的，遊戲的設計及前期工作上，就是最主要的分別。以歐美及日本市場為例，歐美喜歡一邊製作同時一邊更新及改善遊戲設計 ( 更甚者會改變設計 )，而日本就很不一樣，很多時候一開始便已經有了遊戲的定案，製作上只要依設計定案完成便可。歐美的情況用 Retained Mode 就會比較好，因為程式設計都是分開的，遊戲設計需要改動的話，換個程式便可以 ( 但卻很花時間 )。後者就多以 Immediate Mode 製作了，因為遊戲設計是不會大改的，所以程式都不太需要重寫。

以上所說的，是以 Game Play 編程為背景，在 Game Engine 方面，其實是沒有特別設定了，為什麼呢？原因是製作 Game Play 的編程員，多是不需要理會 Game Engine 的架構，只要 Game Engine 方便使用，速度高便可以的了。

恭喜發財，萬事勝意

2009-01-25T19:49:00.001+08:00

Network 遊戲的學習進展

2009-01-10T20:37:00.003+08:00

上週末努力試過使用 network library，成功地將兩部 PC 連上了 ( 只是以 LAN 形式 )，這幾天用了點時間，繼續在嘗試。

這一次我在一部 PC 上，運行兩個單一 Program 來完成連線 ( 這個太普通了吧 ... )。然後便嘗試在一個遊戲軟件中，實現 P2P 的連線遊玩，其實我的目標是，先製作一個簡單的「一對一」連線遊戲。

流程大致完成了，現在的情況會是：
● 進入 Splash Screen 及 Main Menu 畫面
● 選擇 Connect to ( Client ) 或 Start Host ( Server )
● 進入 Game Room 畫面：
　○ Client 需要玩家輸入 Host 的 IP 或名字
　○ Server 只需等待另一玩家連線
● 成功連線後，Server 回傳訊息確認連線
● 確認後，Server / Client 同時進入 Game Play

在 Game Play 中的資料傳送方面，使用了一個 Timer 加入 Callback 控制，定時傳送 / 接收資料，因為都是以 Local Host / LAN 作為試驗，所以更新資料次數可以來得比較多 ( 每秒十次或以上，packet size 為 29 byte )。Game Play 方面可說是最麻煩的，所以還未完成，現時只是成功進入 Game Play ，及傳送接收資料而已。

我在用 C 編寫遊戲嗎 ?

2009-01-08T23:46:00.005+08:00

有看過我的 Blog 的朋友都知道，我是很喜歡用 C Language 寫程式的，除了製作 Ogng3D 引擎是用 C++ 外，自己的遊戲或 Demo 都是用 C 編寫的。

前幾天正在用 C 編寫程式，來試驗 Network 連線時，突然有一點感受，就是我完全感覺不到自己在編寫 C 程式。那一刻的我覺得自己，就好像在編寫 Script 程式一樣，感覺很神奇。為什麼會有這種感覺呢？後來我想了一天，終於想到了，就是因為我在用 C 寫遊戲時，已經不需要再考慮遊戲引擎的問題，可以很專注地對付 Game Play 的程式設計。

雖然 Ogng3D 引擎是用 OGRE 及 C++ 製作，但是在設計上，已經不需要直接使用 OGRE 的任何部件，而且引擎是用 C 及 DLL 做接口，基本上用任何程式語言也可以使用。就好像一些遊戲引擎支援 Python 或 LUA 一樣，製作遊戲的人員是不需要理會遊戲引擎內部運作，可以專注地製作遊戲內容。

現在的我，可以用一句經典說話形容：
「 Write Games, Not Engines ! 」

那當然了，若果在引擎方面真的需要新功能，才能夠完成某些工作的，加強 Ogng3D 還是免不了的。

Happy Net Year

2009-01-05T00:48:00.002+08:00

在 2008 年，曾經將一個免費的 network library "ENet" 套入到 Ogng3D 中，那時候也是初接觸 network library 及程式編寫，但是並沒有再深入地研究下去。而這個沒有繼續的工作，在這兩天便投入了時間去繼續了。

ENet 是一個提供一種銜接層面的 network library，當中一些 network 中的管理還是要自己做的。在這兩天週末的時間，就是嘗試製作一些 network 資料的管理 Functions，例如：起動 Server、起動 Client、那個 Client 已連接上 Server 及 Server / Client 之間的資料傳送。其中最令我煩惱的，可以說是 memory 管理，因為在 network 之間的資料傳送，通常都是很嚴格的，最好沒有一個 Byte 是浪費的。而且 ENet 只是一個銜接層，沒有限制使用哪種方案，就是說用家要自訂 Protocol 及 Data 等資料型態，這些都是我的弱項，到了剛才 ( 踏入零晨時分 ) 才可以說是暫時測試完成。

Network 程式編寫確實是很煩瑣，為什麼會這樣的呢？

祝大家 2009 年比 2008 年更開心、更健康。

Technical Artist ?

2008-12-28T23:02:00.005+08:00

大家有沒有看過這個職銜呢？Technical Artist，中文直譯的就是「技術美術員」，那究竟這個職位是做甚麼的呢？

在兩年前，認識了一位在美國遊戲業工作的人員，他的職銜就是 Technical Artist。雖然說是 Artist，但是他卻一點畫作也不懂，他每每也會開動 MAYA 來做一些測試，他曾經說過，他的工作是非常困難和獨特的，那時候有點令我摸不著頭腦。昨天我在閱讀一本有關遊戲製作的雜誌，其中一篇文章講述了這個職位的工作範疇。

在那文章初，說了一個有趣的情況：製作遊戲時，Artist 都會向 Programmer 要求工具支援，過一會兒後，Artist 就會收到 Programmer 做好的工具，但是對 Artist 來說，這些工具都是不容易使用的。另外在製作後期，因為 Artist 做出來的東西，令遊戲運行速度表現差，Artist 和 Programmer 在這時候又會開始一場拉鋸戰了。

Technical Artist 的職位就在這個情況下出現的了。在遊戲製作整個過程中，不斷在 Artist 及 Programmer 中周旋，抓取一個在他們之間的平衡點，不失遊戲的運行速度，而又可達到 Artist 要求的效果，並與以執行。

我所閱讀的雜誌：程序員遊戲創造 ( 2008 年 12 月下 )

IMGUI

2008-12-15T00:07:00.004+08:00

在 2008 年期間，因為要做製作遊戲的工具，所以接觸了很多有關 Win32 API 的資料，它雖然很強大，但在實際製作工具的時候，仍覺得它頗為麻煩的，常常要處理一些 Message，而且沒有一個好用的 GUI Design 工具 ( 或是可以自訂 Skin 的工具 )，對我來說寫這類 Program 時感覺就是不太順暢。

今天閒來在 Web Surfing 時候，發現了一個 GUI 的 Concept：「 IMGUI 」( Immediate-Mode Graphical User Interfaces )，看了一些簡介之後，頓時發覺這個就是我想做的東西，所以便開始看多一點這方面的資料。IMGUI 很簡單，不需要處理煩瑣的 Messages 及 States，只需要處理 UI Context 及 Widgets 便可以。在數個月前我確實想過類似的東西，只是在開始上出了點問題未能解決而放下了，那時候還未得知這個 IMGUI 的存在。

這個 IMGUI 方案，我覺得很適合在遊戲製作上使用，而下是幾個有關這個方案的資料：

p.s. 其實可能很多 GUI 的方案都是使用這個 Concept 的，只是沒有說明罷了，而上面的資料卻引起了我的輕趣及注目呢，而且 ... IMGUI 的設計上是 Anti-OOP 的，我喜歡！ :D :D

聖誕節的願望

2008-12-13T14:58:00.001+08:00

在 2008 年期間，有個遊戲一直都想玩的，但是因為日本的保護主意 ( 我覺得是我國某些 Online game 玩家的行為引致的 )，令我不能正常地體驗，那遊戲就是熱烈的「 Monster Hunter Frontier 」( PC 版本的 Monster Hunter )。能夠玩到這遊戲，可能是我在今年聖誕節中的願望。

從未試過有一隻 online game 是可以「如此」吸引我的，以前曾經覺得「 Phantasy Star Online 」是好玩的，但 Monster Hunter 的 Action 度卻是比 PSO 高很多。以往曾玩過 PS2 版本的 Monster Hunter，但那時候未有 Online 或合作模式版本，所以覺得不太好玩，但有了 Online 及合作模式後卻變得吸引我了。

以前曾經想在家中，能夠玩到類似「 SpikeOut 」的遊戲，但 SEGA 一直都沒有移值這遊戲到 Console 機或電腦上 ( 很多年後才在 XBox 上出現 )，所以我才搞一個「 Final Spike 」出來給自己玩。那麼我可能要自己搞一個叫做「 Behemoth Slayer 」，來滿足自己對 Monster Hunter 的興趣了。

工具製作，2008 回顧

2008-12-05T23:17:00.013+08:00

一年容易又到年尾了，在今年年初時，決意要製作一些遊戲製作工具，在這裡要回看一下，究竟做了些甚麼出來。

Material Editor (1) (2)
雖然 OGRE 有一個很不錯的資源管理系統，但要用於製作工具時卻是非常困難的，而 Material 的管理是其中的致命傷。因為那個 Material 是以一個 Script 來儲存的，要製作好一個 Material script 和觀察它在 OGRE 中的表現是頗為困難的。這個工具可以製作一些簡單的 Material script，亦同時可以看到在 OGRE 中的表現。

Character Editor (1) (2) (3)
在 2007 年尾時開始接觸 Event / Data driven 的編程技術，從中學懂了一些相關的理念，所以就利用製作這工具的機會同時實踐 Event 系統。工具主要的功能是管理 Animation 的速度和 Event 的發放，這個工具只要配合 MilkShape3D Animation Splitter 工具及 OGRE Mesh Exporter 就能順利完成相關工作。

OLM MilkShape3D Plugin
這個是從朋友的 OLM ( Open Light Mapper ) 工具衍生出來的，因為覺得它的功能強大而且易用，所以便在一個短時間內，將我常用的 MilkShape3D 及 OLM 整合起來。

雖然只是製作了三個工具，但功能上絕對是紮實的，而且 Bugs 量更是極少 ( :-P )。其實在我的心目中，有一個工具一直都很想做的，就是一個類似 Scene Builder 的工具，之前在製作 OLM MilkShape3D Plugin 時學懂了一點東西，希望能夠在 MilkShape3D 中，完成類似的功能，而這個 Scene Builder，可能是最後一個需要製作的工具呢。

經濟衰退的遊戲

2008-12-02T22:27:00.004+08:00

經濟又再進入衰退，香港在十年間遇過數次經濟危機，可以說是難得一見，所以我也來發發牙痕。

有人說，電影業與遊戲業在經濟衰推時，多數都不會受影響，因為現實上很不高興，人們都會到電影院或待在家中看電影，又或者慳來不出外用晚餐的洗費，換來一隻電子遊戲留在家中遊玩。

以上所說的，都好像確切地出現過，每每所謂的經濟衰退，都不太聽過遊戲業受牽連，但究竟事實是否如此？多年前日本曾經試過一次頗利害的經濟衰退，日本是其中一個遊戲業界大國，當年有多個遊戲業界新聞，說某某遊戲公司裁員，某某遊戲公司結業，其實如今的一間遊戲母公司，拆散做多間子公司，就是在那時候出現的。簡化架構，精簡人手，就是要做到減省開支，而不失質量。

這次的經濟危機乃全球性問題，而現時的次世代遊戲，往往開發時間長及成本龐大，相信對遊戲製作公司有一定的壓力。而日本作為其中一個遊戲業界大國，近幾年各大遊戲商都將遊戲「國際化」，但同時卻犧牲了日本遊戲獨有的遊戲性，回看 PS One 或 SEGA Saturn 時期的遊戲，比現時 PS3 或 XBox360 的遊戲更好玩更好賣，難怪日本業界近年只專注於「炒冷飯」或「Remake」。

經濟衰退不是一年半載能夠輕易復甦，近年歐洲是個新興的遊戲發展市場，究竟下一年這市場能否保持著那分熱鬧，就要看看到時的國際環境變成如何了。

Move to MinGW + Code::Blocks

2008-11-09T17:19:00.002+08:00

常常看到網上的 Programmer 說道 M$ DLL Hell，雖然我對 DLL 一向都沒有好感，但總是沒有特別的機會體驗一下，終於在上星期遇到過了，情況就是我用 Ogng3D 做好的一個小遊戲，不能在其他電腦上執行，因為 M$ 的 VC Runtime DLL 問題，原因是 Ogng3D 是用 VC++ 2005 Express 製作的，其所用的 VC Runtime 是要超複雜的工序才可以 Deploy 的。

沒錯這個 DLL 問題是可以用 VC++ 2005 Pro 解決，我想要保持著「低成本」的原則，決不採用這個昂貴的方案，所以我便將注意力方在 MinGW + Code::Blocks 上。安裝 MinGW + Code::Blocks 不是件難事，因為 Code::Blocks 的裝件已經簡化了整個過程，下載回來執行安裝便可以。在這時候旅程才只是剛剛開始，我下載 OGRE3D 的 MinGW 的套件，安裝後發現裡面沒有 .a 檔案，初時以為要自己重新 Compile，但看看那些 Sample 後才發現，原來 MinGW 可以直接拿 DLL 來 Import 的。

安頓好 Code::Blocks、MinGW 及 OGRE3D 之後，當然就是要在 Code::Blocks 中 compile 我的 Ogng3D 了，過程也頗順利，沒有特別的問題便成功做好了 MinGW 版本的 Ogng3D，再將其用 PellesC 的工具 dump 出 LIB，嘗試用 PellesC 的遊戲程式 Link 來用，成功了！

在 Code::Blocks 上 Debug 絕對不是一件容易事，因為它用上了 GDB，試過了數次也不能成功啟動 Debugger，後來改動 Workspace 的架構和用較新版本的 GDB，才能夠成功在 GBD 中啟動 Ogng3D 來 Debug。就這樣，兩天的週末時間就沒了三分之二了。

後記：世上沒有免費午餐，免費的東西就要付出時間和努力，要駕馭 MinGW + Code::Blocks 也是一樣，同時 3rd Party 的 DLL 也多了，但總比其他電腦不能執行較好。雖然成功地建立了 MinGW 版本的 Ogng3D，VC++ Express 版本仍是會同步使用的，主要原因是因為 MilkShape3D 的 Plugin 是一定要用 VC++ 來製作的，這點比較可惜。

後記二：終於有機會在一部不能執行的那個小遊戲的電腦上試過了，遊戲成功啟動及運作，真的很感動，而且很高興有辦法逃離 M$ DLL Hell。(11-Nov-2008)

MilkShape3D + Open Light Mapper

2008-10-11T13:46:00.004+08:00

今天要介紹一個工具，這個工具是專門做 Lightmap 的「 Open Light Mapper 」( OLM )。這個工具的好處是，它是個 Open Source 的 Project，而且能夠同時建立 Lightmap 及 Ambient Occlusion Map。OLM 是個 command-line 程式，用法就是先將 Geometry 及燈光等資料，寫做一個 OLM 格式檔案，然後執行 OLM，予以之前寫出的檔案，它就會自動建立一個 Lightmap 圖像檔案。

在大約一個月前，試過這個工具在 3DS MAX 中的表現後，就決定做個 MilkShape3D ( MS3D ) 的 Plugin 版本。但首先要解決的是，我需要一個能夠自動完成 Texture UV Unwrap 的工具，試過多個 Unwrap 工具後，便決定試用 RoadKill ( 因為只有它能夠將做好的 UV，完好地 import 到 MS3D )。經過一輪 GUI 程式編寫後，大約完成了 70%，現在的工序大約是：
● MS3D 做好 3D model
● 放到 RoadKill 中 Unwrap Texture UV
● Import 回到 MS3D
● 在 MS3D 中啟動及執行 OLM Plugin 工具

下面有兩幅在 MS3D 中執行 OLM 工具，及建立好的 Lightmap 和 AO 的效果 ( 看上去好像有點問題，那是因為 RoadKill Unwrap UV 之間空間太少，這個要再想辦法 ..... )，第三幅圖是在 Ogng3D 測試 Demo 畫面。

Open Light Mapper 很強的呢！ ( 因為我認識它的創作人嘛 :-D )

新. Animation Split 工具 Plugin

2008-10-05T17:59:00.004+08:00

在今年一月時，做了個「 MilkShape3D Ogre Animation Split plugin 」工具，那時候覺得應該夠用，所以便不再加以強化給美化。但在兩星期前，看到一個 Game Scene 工具 ( 忘了網址在哪 ... )，給了我一點啟發，決定重新做一個新的版本。

經過了幾天的努力，有了一點的成果，大家可以看看下圖。與舊版本最大的分別是，加入了互動功能，用家 ( 我 ) 可以用一個 Slider 來查看整個 Animation ( 能夠在左面的 Render View 看到 )，然後桉「 Set Start 」或者「 Set End 」，來設定一個獨立的 Animation 的開始及完結，用家更可以按上/下 Button 來設定 Start / End 的細節 ...... 等等。每一個獨立的 Animation 都會在下面的 Animation List 中列出，列表中的 Animation 當然可以修改了，Animation List 亦會 Save 出來給 Ogre3D Mesh Exporter 使用。

一如以往，此工具是個 Plugin，所以是不需要離開 MilkShape3D 便可以使用，暫時開發進度為 50%，仍在努力開發，完善功能中。

程式語言及遊戲引擎的定位

2008-09-28T19:23:00.003+08:00

其實我已經一段時間，沒有接觸 Game Engine 的 Low-Level 層面的開發 ( 例如：Vertex Buffer 或是 Skeleton Animation 等的資料管理 ) 。

在 OGRE 還是在 1.2.X 的階段時，她使用了不小的外加元件 ( Dependencies )，有很多個不同的 DLL 檔案。我一向都不喜歡這樣的遊戲引擎，那時候我還不太清楚為什麼不喜歡，只是直覺的想「這樣會變得很麻煩」，就和我以前說過頗類似的感覺：「小寫一些 code，Bug 的出現也會減少」。但是近來有了一點點啟發，明白到一些減少用外加元件的好處。主要的啟發是來自 Microsoft Windows，那個 VC runtime distribution，可以說是 DLL 的災難。

那些惱人的外加元件，因為它們各自用的 Runtime 版本可能不一樣，為了歸一化，很多時候也要由 Source code 開始從新 Build 一次。這些問題雖然可以解決，但也不是一件容易事。而最大的一個問題，就是要從一個開發平台，轉到另一個時 ( 例如：從 Windows 轉到 Linux ) ，這下可不是說笑的。

但是說了這麼多問題，那究竟要怎樣做才可以呢？說實話，我不是資深的軟件工程師，不太適合處理這種複雜的情況。但我一直堅持著用 C Language 的主要原因，或多或少也是因為上面所說的問題。

p.s. 回想 Ngan-GINE'3D，其實也是一個全 C Language ( + DirectX ) 的遊戲引擎。如果我能力夠的話，亦希望繼續用 C Language 做一個全面的 Game Engine。可惜的是，自己的能力不太夠罷了。

Loading Progress Bar

2008-09-23T23:19:00.005+08:00

我一直以來，都想做一個 Loading screen 的，因為玩家 ( 包括我 ) 都喜歡看「究竟遊戲 Loading 進度如何？」的顯示。

所以我便用了差不多整個週末的時間，做了一個 Loading screen 功能，用上了 OGRE 中的 ResourceGroupListener 功能，當有 Resource 會 Load 時，便會發出 Event，這時便可以在已設定的 Listener 中，做一些 Loading 進度的表現。

這個 ResourceGroupListener，在使用之前要做些工作，就是首先要把準備 Load 的物件名字 declare 進去，OGRE 才能夠正確地發出 Event。幸運的是，我的 Ogng3D 引擎只需要修改一點點便可以，否則也不能夠在兩天完成這個新功能呢。

Multi-Thread Programming 的小體會

2008-09-21T16:57:00.003+08:00

前幾天看過一些文章，說 Multi-Thread / Multi-Core 的程式技術，會是現時及未來的趨勢，剛好這幾天有些時間，便做一些這類的編程嘗試。初時看一些有關於 Multi-Thread 的概念文章，希望搞清楚一點才開始，但是看了一天後仍是有點不太明白，所以後來索性編寫一些東西出來試試。

首先很簡單地做一個測試，Function A 在主 Thread 中運行，Function B 被指派到另一個 Thread 中運行，然後 Function A 會問 Function B 拿一個在 Function B 中的數字。真的超級簡單，因為 Function A 只是讀取 Function B 的資料，所以運作很順利。但後來同事們也一起來討論，他們對這方面的認識比我深入很多，其中一個同事更改了我的簡單程式，變成互相在一個 Linked-list 中讀寫資料，就這樣，最基本的 Multi-Thread 問題出現了，就是讀寫同一個資料的動作，有機會在同一時間發生，導致資料錯誤，或是資料損毀的問題。

再深入一點地試了兩天，最後我還是放棄了，Multi-Thread 編程這些工作，還是留給對它有認識的人負責好了，自己還是回到 Event / Data Driven，及 GamePlay 的編程中努力吧。

p.s. 雖然 Multi-Thread 編程令我卻步，但是在當中學到了一些寫程式的技巧，雖然不是甚麼大發現，但卻令我在製作 Ogng3D 上很有幫助。另外亦想到，為什麼現時電腦科技這麼發達，還要為這些超級複雜的難題懊惱？！

精神食糧電視劇

2008-09-15T21:02:00.003+08:00

近幾年來，不知為何的，已經很小看日本或其他外國的電視劇集。

在這幾個星期日，偶爾地看到一套日本電視劇「 Bambino 」( 無記電視台譯 "料理新鮮人" )，感覺很好看，其實她的情節很簡單，就是一個年青人追尋夢想的故事 ( 日劇就是這樣的了 )。

雖然這些情節看來好像不太實際，但有時間我們需要的，就是這種「精神上的食糧」。而不是那些每晚都鬧哄哄的拖拉情節 ...

棄用收費 3rd party LIB

2008-08-22T13:51:00.005+08:00

一直以來，我都是用一些免費，或者價錢便宜的工具來做遊戲，雖然那些工具看起來都不是很專業，但確切地實用就已經足夠。

自從開始製作 Ogng'3D 引擎，我一直都在找一個便宜的聲效 LIB，本已找到一個叫做 irrKlang，但後來這個 LIB 要收費了，所以近來都在找代替品。後來在 OGRE3D 的 forum 裡，看到有個叫做 cAudio 的東西，是個 OpenSource 的聲效 LIB ( 使用了 OpenAL )，便拿來看看。

因為這個 cAudio 本身是給 Linux 使用的，我要自己將它轉為 Windows 平台，經過同事們的幫忙下，成功地將它轉為 Windows 的 DLL 了，現在正努力將它的功能完善化。

[ 更新 2008-08-27 ]
經過幾天的測試，發現其實 cAudio 中的資源管理比較薄弱，但整個架構是個很好的例子。看來還是要自己努力一點，重新做個稱心的聲音 / 音樂播放功能，放進 Ogng'3D 引擎了。

Game play 加 Control 仍是一切嗎 ?

2008-08-13T22:05:00.005+08:00

當美國 SEGA 公佈，她們的 iPhone 遊戲「 Super Monkey Ball 」，在 20 天內在網上 App Store 賣出 30 萬套的驚人銷量 ( US$ 9.99 一套，總銷售額 US$ 2,997,000 )，令我更加相信，Game Play 及 Control ( Input ) 就是黃金組合。

曾經看過一篇文章，說現在的遊戲就是不停地「炒冷飯」，很冷很久的飯也會拿出來炒，又或者是不停地重複續作，加上超級美麗的圖像，就會拿出來賣。就這樣，不好玩但畫面美麗的遊戲滿街都是，這做就了現在一批遊戲玩家，只用畫面的美麗程度來判斷遊戲的好與壞。

沒了 Game Play，也沒了 Control 的配合，再好看的遊戲也是有缺憾的，更可笑的是，那裡丁點缺憾美也沒有。

很懷念以前 Super Nintendo 及 SEGA MegaDrive 年代 ( 及同時期的街機遊戲 )，好遊戲盡在那些時候。

久違了的工具

2008-08-03T22:39:00.002+08:00

還記得在今年年初說過，會先專注做一些遊戲製作的工具，所以那時便做了個「 Actor 及 Event 工具」，也做了個完成度只有 10% 的 Map Viewer。在過去數月，因工作比較忙，也沒有再著手改善或完成未做好的工具。近日我在白天的工作剛剛完了一個忙碌期，希望能夠在短期內重拾工具開發。

說到製作工具，因為 MilkShape3D 內的 Animation 部份，是沒有 Scale Keyframe 這一項的，我希望能夠在 Actor 工具中，加入 Scale Keyframe 這一個功能。另外在未完成的 Map Viewer，我想將它由 Viewer 變成一個 Tool，當中我最希望加入的，就是能夠改變 Vertex Color 的功能。其實說到底，用 MilkShape3D 來製作遊戲用的資料，確實是有點兒綁手綁腳，一直想看看 Blender3D 的用法，但可能是因為自己的數學能力比較弱，總是覺得這類大型軟件難以理解。

碰撞測試的簡化

2008-06-22T23:14:00.002+08:00

早前我試將 Game Engine 中 Collision 部份，轉為使用 NGD ( Newton Game Dynamics ) 的手動 Collision，便出現了問題：「怎樣可以簡化兩個物件互相碰撞的方法？」

一如以往，我都是先設定好一些限制，才開始製作。因為 NGD 能夠建立一些基本的 Collision Primitives，例如 Box、Sphere、Capsule ... 等，我便由這些基本的 Primitives 著手。在試作的初時，用了些比較笨的方案，就是每一次要做碰撞測試，都要自己調用 NGD 的 CollisionCollide 功能，後來覺得這個很費時，因為每個物件做每一次碰撞測試，也要編寫一次程式，而且還要同時做 Collision Response。

想了兩、三天後，才醒覺自己的 Game Engine 內的 Frame 架構，是可以加入一些功能，用作記下碰撞測試後的資料，基本上不需要每一次也編寫一大堆重複的程式，所以最後便改成了而下的步驟：
● 用 AABB 測試物件-A 及物件-B 是否需要碰撞測試
● 如需碰撞測試，便調用 NGD 的 CollisionCollide 功能
● 如有任何碰撞，將碰撞後的資料寫入物件 ( A / B ) 相對應的 Frame 中
● 同時回傳一個非零的資料，表示產生了碰撞

以上的步驟都是在 Game Engine 內部做好，在我編寫 Game Play 的時候，先調用 Engine 中的碰撞測試功能，若產生了碰撞，我只需要在相關的 Frame 中取回碰撞後的資料，便可以做 Collision Response 的調整。但因為每一種 Game 物件的 Collision Response 也可能有不同，看來這一點就很難加以簡化了。

硬派動作遊戲

2008-06-14T23:08:00.000+08:00

玩遊戲很多年了，我還是一個硬派動作遊戲迷，為什麼呢？因為很多動作遊戲的基本設定都頗為單純：跑、跳、斬、射、拳及腳。很多出色的硬派動作遊戲，都是出自日本遊戲開發商的，動作遊戲不易做，要做硬派動作遊戲更加不易，再加上要做得好就更難。

說到硬派動作遊戲，當然要說說 CAPCOM 這位老大哥了。CAPCOM 的動作遊戲，由 Final Fight，吞食天地 2，到現在的 Devil May Cry 系列等等，都是一眾動作遊戲迷的選擇。其實還有很多日本的硬派動作遊戲也是很出色的，例如：SpikeOut 系列 ( SEGA )，Zone of the Enders 系列 ( Konami ) ... 等等。

說到自己在遊戲製作上，最想做的都是這類硬派動作遊戲，而且心裡的幾個遊戲主意也是這類型的，但是自己的 Game Play 程式的編寫技術，看上去好像還未足夠，似乎要多加練習了。

學習做遊戲製作的迷思

2008-05-24T13:13:00.001+08:00

之前我曾經說過，製作遊戲不難，只要對自己的要求不要過高便可以，例如不要一開始便製作如「Final Fantasy」或「Metal Gear Solid」系列的東西。做一些像 Casual Game 之類的遊戲作為開始，所獲得的相關技術和知識，也可以慢慢地步向成熟。又或者，做一些簡單遊戲的 Clone 版本，來實踐一下自己的技術及知識，也是一個很不錯的選擇。

做遊戲的 Clone 版本，其實也是一個遊戲製作的重要科題，當中要瞭解的事情也不小：
● 原遊戲的操作系統
● 原遊戲的 Game Play 系統
● 原遊戲的 Game Flow
● 所需的技術自己能否做到 ( Engine, Artwork ... etc )
● 自己所擁有的技術及資源是否充足

若然選擇要製作一個遊戲的 Clone 版本，以上相信為最基本要做到的，應該視為最基本的目標，加以實行。而且有一點我覺得是很重要的，那就是能夠學習到，在有限的資源下，做到一模一樣的東西出來。

我們有時候也想要加入自己的想法，覺得原遊戲應該要有這個 Feature 或那個 Game Play 的，那麼開始製作的時候便加到自己的 Clone 裡。其實這個是很壞的學習及實踐步伐，為什麼呢？其實原因就是，因為是「有它的原因的」。每一個遊戲在製作的過程，總會有些原因，會將一些 Game Play 或 Feature 刪減。這些原因我們多數也是不會知道的，除非是直接和開發人員工作，或是直接問他們 ( 例如一些雜誌的訪問 )。如果硬要將一些自己的 Idea 加到製作 Clone 裡面，到最後可能會遇到一些難題解決不了，那樣只會令你覺得沮喪而想放棄的了。

所以結論就是，如果要做遊戲 Clone 來作為鍛鍊及實踐技術的話，首先要做的，就是要做到和原遊戲一樣的東西。如果連這個最基本的條件也做不好的，那麼你便要想想，製作 Clone 遊戲的方法是否適合你了。

GUI

2008-05-20T22:28:00.007+08:00

「 GUI 」是甚麼呢？Graphic User Interface 是也，但我想說的不是 Graphic User Interface，而是「 Game User Interface 」。

在做遊戲的時候，免不了要做的，就是一些遊戲選項的版面，例如：Main Menu、Option Menu、Profile Menu ... 等等，但是我不太同意那些遊戲選項版面，用 Graphic User Interface 來表達，我覺得 Game User Interface 會比較適合。我近日開始製作一些 GUI 的功能，一如以往，我都會先訂立好一些限制及可行性，才開始製作這個 GUI 功能。GUI 的 Rendering 方面是以現有的 Sprite 功能為基礎，先來定義一個 Window，我會以一張 Texture 作為背景及設定 Window 的大小，在這個 Window 內可以加入不同式 Buttons，這些 Buttons 可以設定好一個 Callback function ，只要有關的 Event 出現，便會執行那個 Button 的 Callback function。

就這樣，一個超級簡單的 GUI 功能便策劃好了 ( :D )，功能方面希望最小能做到 Window Dragging，預計將可以從一個設定檔案中讀取資料，來建立一個 Window 及其功能，只要是簡單使用便可以的了。

上星期的四川大地震，確實很令人傷感，希望內地災民早日平復心情，面對光明未來。

以前都喜歡間中在 Blog 中寫點工作感受，但近一年來也盡量不寫了，因為當你知道你老闆會看你的 Blog 時，便會盡量小說這些事的了....

怎樣才是 Indie 製作 ?

2008-05-11T20:38:00.003+08:00

曾經有人問過我，覺得怎樣才是一個理想的遊戲開發 Pipeline，我想了一想，回答說：「我覺得是以 Indie 形式做遊戲，是比較理想的。」

那麼 Indie 形式的定義為何呢？就我個人而言，就是以「簡單」為主的製作 Pipeline：Game Engine 容易使用，程式編寫及設計要簡潔，製作 Assets 工具 / 軟件容易使用。以上三點是重點，因為如果能夠做到這三點，整個遊戲製作的時間會大為縮短。

Game Engine易用：
以我的 Ogng3D 為例，我用的 Render Engine 是 OGRE 3D，因我不想每一個 Game Object，也要分別處理一大堆 SceneNode、Entity 及 Animation ，那我便在 Ogng3D 中加入了 Frame 及 Actor 概念，將常用的 SceneNode / Entity / Animation 簡化，以及將其 C Language 化，令我能夠簡快及舒適地使用。

程式設計簡潔：
我常覺得 C++ 語言很複雜 ( 只是我不儘瞭解 C++ 吧了 )，如果我不能夠看明白的，我就總是覺得不簡潔。而且我是一個比較「 Old School 」的 Programmer，相信 Code 量越小，出現 Bug 的機會就會越小，運行速度亦會越快 ( 注意：和懶惰是無關的 )。

製作 Assets 工具 / 軟件易用：
一個遊戲無論大與小，都需要 Load 入 Assets ( 遊戲使用的資料及圖像 )，那麼製作這些 Assets 都要用工具。Artist 要對這些工具掌握純熟，可以有效率地工作，程式亦能夠簡單地 Load 入 Artist 所製作的 Assets 也很重要。

以上三點說來容易，但實行上確實是不簡單的，最困難的就是，要有遊戲製作經驗，才能夠順利融合上面三點。最後，除了上面三個重點外，還有最後一個 Indie 製作最終重點，就是「便宜」。又以我的 Ogng3D 為例： PellesC Compiler、MilkShape3D、OGRE 3D、Visual Studio Express ... 等等，都是免費 / 便宜的製作工具。

昨日, 今日, 明日

2008-04-26T13:57:00.002+08:00

昨日的我：精神緊張，腸胃病，頭痛
今日的我：放鬆心情，出發
明日的我：樂在東京

重新認識 Newton Game Dynamics

2008-04-24T22:19:00.006+08:00

我在製作「 Final Spike 」的時候，因為自己一直做的 Collision Detect 做得不好，所以後來用了一個可以在 C Compiler 下使用的 Newton Game Dynamics (NGD)，那時候對她的認知真的是不足夠，很多時候用一些比較奇怪的方法來達到效果。

近來有機會再細研一下 NGD，有關於不使用 Dynamic 部份，而只用其 Collision Detection 的功能，對她的認識多了，便開始發覺她確實是越來越易用，而且比起其他 Physics engine 更容易理解。對我來說，Physics engine 都是很難理解的，因為對於當中牽涉到的數學技術，我完全不明白，我只懂得一個最基本的認知：萬有引力。

自己在五、六年前也試過做 3D Collision Detection，難度真的很高，而且我的數學根底不好，所以特別吃力，就是因為做了一段時間也沒有進展，才會選擇用 Physics engine 來代勞。到了現在用多了 NGD，就覺得她的 Collision Detection 部份其實也很簡單易明，所以看來自己往後的 Ogng'3D 的遊戲引擎，也會用上 NGD 的這個部份了。

玩遊戲是奢侈品

2008-04-11T00:39:00.005+08:00

近日在想，其實自己有一段很長的時間，沒有對遊戲投入感情，曾經問過自己，是不是太過挑剔，還是對玩遊戲的感情變淡了，自己的答案是「因為時間太少了」。其實在現今的香港大環境，那有一個人是不忙得不可開交的？

在時間不多的情況下，往往就連自己的嗜好也會放到一旁。放工後多數晚上九時後才回到家，吃過晚飯及整理一下自己的瑣事後，已差不多晚上十一時多了。這時候，便是決擇的時候了，究竟是看看自己做的遊戲製作工具，有甚麼功能缺乏？還是要再改善 OGNG'3D 引擎來配合製作工具需要？寫一篇 Blog 嗎 ( 今晚的時間就這樣過了 ) ？抑或是玩一玩遊戲？但到最後我也不會選擇玩遊戲的。

我希望會出現有一些動作遊戲，是遊戲時間比較短及節奏明快的，不需要坐下來便要一個多小時。玩 15 ~ 30 分鐘的，Save 下來便可，待有時間可以再繼續玩。但是我環顧四周，卻沒發現有遊戲是時間短而節奏明快，但又合我口味的遊戲。

p.s. 近來因為電視節目重播關係，發覺有一首歌的歌詞也不錯：「人生太短，出手要更大，旁觀者不需理解。贏得風光，豪得精彩，自己偏偏感覺失敗。自尊心都可以出賣，忘記我也是無壞。連夢想灑一地再任人踩，依然笑得爽快。」

把工作還給 Artist 和 Game Designer

2008-04-05T19:12:00.004+08:00

在製作遊戲的時候，會常常出現一個情況，就是遊戲需要作一些調整，如果遊戲是獨自一個人開發 ( 像我一樣 )，這情況做成的問題不甚明顯，但當遊戲製作是一個團隊 ( 成員為二位或以上 )，那麼情況就會變成一個大問題，因為 Programmer 絕對不想因為一些輕微的調整，而經常要重新 Compile 遊戲程式，這樣只會是浪費時間和消磨鬥志，所以分工是必須的。

對於 Game Designer 要經常調整的情況，可以將遊戲程式轉為「 Data Driven 」形式，將一些需要調整的資料，以外加檔案形式 Load 入到遊戲程式，Programmer 只需要加入一個 Reload 資料的功能便可，將遊戲的調整工作完全交給 Game Designer。

另外一個比較難的方法，就是將遊戲物件 ( Game Object )，以「 Event Driven 」形式製作 ( 如果遊戲引擎支援會比較輕鬆 ) 。例如：主角在行走時，左右腳踏地時要發出聲音或出現塵埃，只要在主角的動畫資料中，分別在左右腳踏地動畫中設定一個 Event ，遊戲程式只要在遊戲開始前，設定好一個監聽「左右腳踏地 Event」的 Function，那麼主角在行走時，動畫便會觸發那些 Event 了，遊戲程式亦會自動執行，踏地聲音或塵埃效果了，而且要不要有這些效果，完全由 Artist / Game Designer 決定，將遊戲的設定工作還給他們。

相信開發過遊戲的朋友，對以上所說的都不會陌生，但是對一些業餘的開發者可能有用，其實我也是在前陣子，接觸過 Flash Action Script 後學到的，近來我積極地製作工具，也是希望能夠做到 Event Driven 這個方案。

製作遊戲很難的嗎？

2008-04-03T00:58:00.002+08:00

經常都會有人問，製作遊戲難嗎？製作遊戲引擎難嗎？製作格鬥遊戲難嗎？製作 2D 射擊遊戲難嗎？...... 等等，但是，究竟製作遊戲是不是很難？老套的說，答案確實因人而異，但是我今天看到以下的一個遊戲，我可以很明確的說：「要做這樣的一個遊戲，不難！」。( 建議到以下連結，看看遊戲的片段 )

http://www.nombz.com/media.html

那麼，製作一個遊戲真的很難嗎？我雖然說「不難」，但現實卻不是如此，因為不是每個人的想法都和我一樣簡單。

對 C Language 的體會

2008-04-01T21:34:00.005+08:00

很多朋友都知道，我是個 C Programmer，對 C++ 的認識確實是「有限公司」。同事們也知道我是 C 的 Fans，所以有同事今天建議我去看看 GLib，他們說 GLib 使用 C 真的用得很美麗，而且很絕妙，所以我就去看了一些，在看過一丁點後，有了一些深刻的體會。

最深的一個體會是，感覺自己有點被 C++ 薰陶了一點點，為什麼呢？我以前曾經想過做一個和 GLib 裡的 GObject 一樣的東西，那時候我的想法和 GLib 一樣，Define 好全部的 Data Type，但是想到這工程也頗大，所以總是提不起開始的步伐。到後來因為要用 C++ 來做自己的 Ogng'3D 引擎，加上工作上也要用 C++，便出現了「User 可以使用自己定義的 Data Type 才好」的想法。

但是今天看過了一丁點的 GLib Source code ，及其 Tutorial 之後，令自己對 C Language 的體會就更深入了，而這個體會令我更喜歡 C 呢。

Actor Setup 工具 (WIP #3)

2008-03-09T22:37:00.005+08:00

完成 AEF 格式的定案後，進展也頗為順利，在上星期的進度之後，這個星期也完成了一點工作，就是暫定了一個 Actor 的格式。這個 Actor 的格式很簡單，只是有 Actor 的名字、Mesh 的檔案名、Skeleton 檔案名及 AEF 檔案名，然而格式暫定後，Actor 工具的 UI 也要加入些新元素呢。Actor 工具程式 Load 入一個 Actor 檔案後，就能夠自動 Load 入 Mesh、Skeleton 及 AEF 資料，但是暫時有一個問題，就是還未有實際應用機會，不知道這樣的設定能否令遊戲製作更為簡便，所以看來下一個工作應該是應用測試了。

現在我的 Actor 製作工序大約是：
一 ) MilkShape3D 製作 3D 角色模型及動畫
二 ) 在 MilkShape3D 中用 Animation Split tool 為 Export 做準備
三 ) 從 MilkShape3D 中 Export 出 OGRE 的 Mesh 及 Skeleton 檔案
四 ) 用 Actor Setup 工具製作 Actor 檔案 ( 製作 AEF 資料 )
五 ) Pack 好所有檔案給 Game Program 使用

上面的工序好像也不錯，希望在應用測試時能夠找出不順暢的地方，再作改善。

Super Mario Galaxy Rendering ?

2008-03-08T21:00:00.006+08:00

任天堂在 Wii 中發售的 Super Mario Galaxy 是個很好的遊戲，畫面非常地豐富，而這遊戲的 Rendering 方法也很有趣，是用了一種像是「背光效果」的表現方式。

很多人都說過，這種 Rendering 是用 Shader 做出來的，沒錯，Shader 確實是可以做到這個效果。我經常到處找一些能夠在 fixed-function pipeline 中，做到和 Shader 差不多效果的方法，有時候也會找到一些，和 Shader 效果很接近的做法，而今天我在網上找到了一個方法，可以做到類似 Super Mario Galaxy 的 Rendering，但是只需使用 fixed-function pipeline 功能。

附圖就是用這個方法做出來的，效果也確實是很接近呢。

Actor Setup 工具 (WIP #2)

2008-03-01T22:06:00.003+08:00

作戰了數天時間，Actor Setup 工具 ( 終於 ) 有點新進展了，首先是資料格式定下了，暫時名為 " Animation Event File ( AEF ) "。

現階段都是在測試，現存的功能是否實用，如在每個 Animation 中的每個 Keyframe 記下資料，例如：Dispatch Event 字句、 Goto 另一個 Animation、正確處理 AEF 及 Skeleton 之間的資料互動。下一步的工作應該會是測試，如何將另一組 Skeleton Animation 套入目前的 Actor 中，以及將新的 Skeleton 加入現時的 AEF 中。而現時的資料其實是不足夠的，因為這個 AEF 資料，只是單一 Actor 儲存 Keyframe 的額外資料，但其實是應該儲存一個 Actor 所用的 Mesh、Skeleton、AEF ......等等的資料，這個方向應該會是再下一個階段的了，因為這需要設計另一個自訂資料儲存起來呢。

製作工具確實很麻煩，但是卻令我更加認識 OGRE 3D 的性格。

Toy ? Gadget ? Fun !

2008-02-17T17:39:00.006+08:00

近日朋友介紹我玩一個軟件，這軟件叫做「RocketDock」，這是甚麼來的呢？它是一個 Docking 軟件，就和 Application Launcher 一樣，是放我常用的軟件在裡面，方便我一 Click 便可以開啟的，而這個 RocketDock 的外表只是和 Apple Mac OSX 內的 Dock 一樣而已。我自己是半個 Max OSX 的 Fans，一向很喜歡 OSX 的界面，這個 RocketDock 就令我很高興，不其然地玩了差不多一整天，而它最有趣的，就是和 OSX Leopard 的 Dock 一樣，有 Stacks 功能呢。下面一幅圖就是從我的電腦直接 Capture 出來的，你看看是不是很像 OSX 呢？

後來我又發現，原來 Microsoft 在 Windows XP 中的 PowerToy 工具中，有個叫做「Virtual Desktop Manager」，就是可以令你的 Windows XP 擁有四個獨自的 Desktop，就好像有四個 Monitor 一樣，就正如 OSX Leopard 中的 SPACES 功能，有多個 Desktop 供使用。

再在網上瀏覽多一回兒後，又發現了另一個軟件，這軟件是仿照 OSX Leopard 中的 Media Viewer 工具，由一個 3D 的 Viewport 為基本，每個 Movie 或圖片都是由一個 3D Polygon 表達，用家可以簡單地瀏覽各個 Movie 或圖片，雖然這軟件還在 WIP 中，但效果也是很不錯的，以下一張圖是從我的電腦直接 Capture 出來的。

這些各式各樣的 Toy / Gadget 等的小工具，便讓我的 Windows XP 彷彿變成了 Mac OSX 一樣呢，最好的是，這些小工具的速度快，而體積亦很小呢。

Actor Setup 工具 (WIP #1)

2008-02-03T22:37:00.001+08:00

前陣子有機會接觸 Flash 及 Action Script 3.0，用過後發覺 Flash 和 Action Script 之間，就好像 Game Artist 和 Game Programmer 一樣，但是 Flash 和 Action Script 卻融洽非常，我用過她們後吸收了一點點經驗，希望用這些經驗做個工具，一個簡化 Artist 和 Programmer 之間溝通和工作的工具。Action Script 本身就是一個 Event Driven 的工具，在 Flash 中使用 Event 來與 Action Script 溝通，這個是她們融洽的主要原因，所以我先要做的，就是做個 Event System 出來給自己的 Ogng 3D 使用，當然是一個很簡單的版本了，但是也算是可以使用的了，當完成了這個超簡單版的 Event System 後，就要開始做工具了。

我暫時叫這工具做 Actor Setup Tool，這個工具是做甚麼的呢？最主要就是在一個 Character 內做一些 Event 發放的設定，例如：一個 Character 的其中一個 Animation，playback 其間或完成後發放一個 Event，那麼 Game Programmer 只需要做個程序來處理這 Event 便可以，工具就是希望做到，在一個 Animation 中的指定時間上，加入一個發放 Event 的點。現在進行的階段還沒有多大的進展，其中一些記錄 Event 時間、類型、名稱等等資料，都要另外儲存，但資料格式還未敲定呢...... 暫時就如附圖一樣，只是一些基本軟件外表，就和我之前所說，這個工具會是比較大型的，相信還要做一段時間呢。

明天是年廿八，再過幾天就是新年了，在此先恭祝大家：

心想事成、萬事勝意

Animation Split 工具 Plugin

2008-01-27T20:10:00.000+08:00

剛剛用了兩、三天的時間，做了個 MilkShape3D 的 Plugin Tool，叫做 Animation Split Tool，為什麼要做個這樣的工具呢？因為 OGRE 的 MilkShape3D exporter 中，可以 Load 入一個資料檔案，當中會有這樣的內容：1, 3, Walk; 4, 12, Run .... 如此類推。這些資料是用來將一段長的 Skeleton Animation，按照資料的內容，分成一段段獨立的 Animation，再 Export 成 Skeleton 檔案。但是要製作這個資料檔案，都是要用一些如 Notepad 的工具做，感覺非常的單調，那麼我便想做一個比較視覺化的工具來代替，就這樣 Animation Split Tool 便出現了。

用法也頗為直觀性，在 MilkShape3D 中 Load 入 Model 後，便可以在 Animate 選項中啟動這個 Animtion Split Tool，這工具可以重新製作、Load 入已有的資料檔案及 Save 更改過的檔案，可以加入或散除檔案中的 Animation 資料，這工具最方便的就是，用家不需要在兩個軟件之間切換，可以一邊看著開啟 Model 的 Animation，一邊輸入資料，減少資料輸入錯誤。用這個工具製作完一個資料檔及 Save 之後，便可以隨即將 Model Export 出來一個 OGRE 檔案，而這個 OGRE 檔案已經將 Animation 分切好了。

完全了這個小工具後，下一個要做的應該就是 Character Setup 工具，這工具將會是比較大型的工作，因為要即時看到 Character 的 Animation 資料，加入或修改一些 Custom Data 及儲存起來，這些 Custom Data 會在製作遊戲的時候，比較容易地製作 Model 的 Animation 調控，從而減少這方面的工作量，因為這類 Animation 的調控工作量確實是很多的。

Ogng3D Material Tool 完成

2008-01-18T00:23:00.000+08:00

完成度達 80%，餘下的 20% 是屬於試用多一點，如發現 Bug 就做一些修正工作。說實話，這個 Tool 用起來也不錯，自己就覺得頗為方便呢 ( 在自吹自擂中 ...... ) 。

下一個 Tool 會是甚麼呢？還未想到，可能會是 Character Setup Tool，也可能是個 2D Sprite Setup Tool ...... 未決定呢 ......

製作 OGRE 的 Material 工具

2008-01-13T16:41:00.000+08:00

一個多星期前，我開始製作一個 OGRE 的 Material 工具，我預先設計好一個「可設定資料量」，例如：每次只能夠製作一個 Material，每個 Material 只會有一個 Pass 和三層 Texture Layer，以及一些如 Alpha Blend、Depth Check 或 Receive Shadows 等等的選項。初時只是做一些 Win32 API 的程式，還是頗為順利的，但後來牽涉到要讀取 OGRE 中已存在的 Material 時候，就令我更覺得 OGRE 本身的冗長。我建立了一個 ResourceGroup，加進了現時的 Directory 後叫 OGRE 讀入這個 ResourceGroup，便以為可以簡單知道已讀進那些 Material，但是我卻找了很久才知道怎樣才可以找回那些資料。OGRE 的 Material 中基本分別有 Technique、Pass、TextureUnitState，當中很多資料都在 TextureUnitState 裡，看到這些一大堆的資料，我又需要再加入一堆自訂資料，將設定資料記下來給 Material 工具顯示出來，同時亦要將這些資料作改動後，Save 起來做一個 Material Script，工序可以說是甚為煩瑣。

雖說工序是甚為煩瑣，但一想到在 MilkShape3D 中設定的 Material 資料過於基本，而自己也不想「編寫 Material Script 」且不能方便地看其效果，所以一個可設定簡單 Material 資料 ( 限制於可設定資料量 )，及可以即時看到效果的 Material 工具，仍是一個不二之選。

新一年的開始

2007-12-30T19:58:00.000+08:00

近日我在 MilkShape3D 中製作 OGRE 的 Plugin 工具，其中一個 Plugin 就是做個 Level Viewer 出來，但是我用的是自己的一套 Level Model 資料，要做個「一按即看」的 Viewer 工具很複雜，還好的是，先 Export 然後再按 Viewer 也不會破壞「不離開 MilkShape3D 便做完所有工序」的條件，所以便選擇了用 Viewer 看 Level 之前要完成 Export。

要用 OGRE 來製作一些工具是很麻煩的，最不好的事情是，它不時因為有重複名字的物件 ( 例如：SceneNode、Material ... 等 )，而出現 Exception 令程式 Crash 掉，很令人洩氣 ( 為何不設定為不理會重複的物件呢？ )。而我擺放 Model 的資料夾內，會有很多其他的 Model，或 Material script 等的資料，會出現很多重複物件的問題，我後來想到了一個方法來解決，就是要用 Viewer 時候，在 MilkShape3D 的程式資料夾下，建立一個臨時的資料夾，然後將 Viewer 要用的所有資料 ( 如 Level 檔案、Material script、Texture ... 等等 )，都複製一份到臨時資料夾，用完 Viewer 之後便將這個臨時資料夾刪除掉，這樣便不需要理會重複物件的問題。

在 2008 年，我先會致力於 MilkShape3D 的 Plugin 工具製作，在完善 Level Viewer 後，亦會研究 Character Model 及 Animation Viewer，甚至是 Character Setup 工具，我希望令 MilkShape3D 能夠處理大部份製作工序 ( 當然是除了 Programming 呢 )，那麼對於我製作動作遊戲便更加得心應手了。

順道在這裡祝大家下一年做遊戲也一樣順利。

聖誕節快樂

2007-12-24T23:56:00.000+08:00

一年一度，聖誕節又到。

● 對一樣事物有期望，有時候換來的只有失望，例如早前期待的遊戲 Kane and Lynch。

● 雖然是預期中的事情，但是 Call of Duty 4 還是非常非常地好玩。

● 決定了，聖誕節還是給自己一份聖誕節禮物吧。

● 之前看到一個有趣的網頁，一種心靈的慰藉。

● 有時候 OGRE3D 也會給我一點甜頭，很簡單地完成了加 / 減物件到骨骼上 ( 例如：手中加入武器 )。

● 近來因工作關係，接觸過 Flash 的 Action Script，意外地從中學懂了一些 Coding 的技巧。

● 以往曾經在 MilkShape3D 中做過的一些 Plugin 工具，因為暫停了 Final Spike 的開發，而沒有隨 MilkShape3D 而更新，這兩天的假期節目，就是要重建這些 Plugin 工具了 ( 為了準備重新啟動開發 )，又是 Win32 API 呢。

要做還是不要做

2007-12-18T00:06:00.000+08:00

今天在 GameProducer.com 中看到一篇文章，這文章主要是一位 game producer 給 GameProducer.com 的 Email，內容提及的是一些遊戲製作的經驗談，非常值得看看。

當中講及一些話題：Risk Management、3D vs 2D ..... 等。其中不乏說的的當然是有沒有足夠資金，各方層面的營運，以及要不要做 3D 遊戲，我看完之後亦有點得著，而且亦想到一些自己的論點。在外國的遊戲業界中，技術層面是遊戲製作的主要方向，這點原本是好的，但先進技術是要用人材建構的，這樣便會令一間遊戲製作公司負擔沉重。但回看香港這片土地上，有足夠技術的人材究竟有多少呢？

看看眼下遊戲製作業界中，很多都是「追技術」的人，而且在 Production 工序方面多是很複雜，導致製作緩慢而令遊戲難產。但到底甚麼是簡易，甚麼是複雜？當然每間製作公司的計算都不一樣，例如就我個人的遊戲「 Final Spike 」而言，很多人說這遊戲是個中型遊戲製作規模，但在我眼中，她卻是個小型遊戲的規模，因為她的製作工序不複雜，我只是用 MilkShape3D 和幾個免費工具，一個人慢慢地做出來的。

遊戲製作的工序上是複雜還是簡單，對我來說就是遊戲製作上的 Risk Management，只要這方面控制得好，製作遊戲開支就會相對自然地減低了，那麼遊戲製作公司就有更多的機會，製作不同種類的遊戲推出市場了。

重整 OGRE 的工具

2007-11-26T00:23:00.000+08:00

支援 OGRE 的工具一向都很多，主要的 3D Content Software 都有 Exporter 可以使用，我常用的 MilkShape3D 也有 Exporter。近日我想整理一下 MilkShape3D 的 Exporter，因為改用 OGRE 以來，Exporter 中對於導出 material 檔案的功能是缺乏的，所以要加進這個功能，就這樣我的週末節目就是製作 Exporter 了。

初時用 OGRE 的功能來導出 material 資料，但很不順利，因為 exporter 不時就會 crash，追查了半天時間才發現是 Release runtime 問題。Runtime 用對了後又發現，OGRE 的 Material Serializer 生成的 material 檔案，有些設定是不能導出的，後來要自己用寫入 Text 檔案方法來完成，又沒有了半天時間。

雖然進度慢了一點，但暫時在 export 出來的 material 檔案中，都可以有基本的資料了，下一部就是加一個 Dialog Box，加一些可設定的資料 ( 又是 Win32 的 API )，再 export 出 material 檔案，計劃好像很完美呢 .....