修復斷層 & 更新

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

早前曾經說過，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，確實不是一件容易的事。

那是用家的軟件

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

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

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

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

向成功學習

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

What open source can learn from Apple

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

The best game dev. tool these years !

近年最流行的開發工具：

Action Game, Combo design !

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

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

Bayonetta Combo Megaton Gameplay (video)


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

Animation BlendMask 再三造訪

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

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

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

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

E3 2009 後的思維

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

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

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

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

預測炒冷飯遊戲

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

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

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

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

Final Spike 重新 upload 供下載

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

Final Spike v1.0.0.1 Alpha
　

技術性的選擇 ( 2 )

剛才到訪過 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 也有很大的幫助。

假期中的病情

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

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

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

Project 「 Grand Hunting 」

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

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

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

技術性的選擇

大約一個月前，一位朋友所製作的遊戲推出了，幾天前和他在 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 ？

剛才在網上看到，一個頗出名的 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 ？

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

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

Animation BlendMask 的再訪 ( Revisited )

早前曾經說過，我試驗過 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 問題

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

次世代，當然是指下一個新世代了，其實以現時的遊戲開發發展，好像已經沒有「次世代」了，因為技術層面上已經沒有了這個框架。回來說正題吧，上星期看了一本報導有關遊戲製造業界的雜誌，裡面翻譯了一篇由日本 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，在設計上令玩家們都很容易明白遊戲的進程，它沒有很獨特的圖像表現，但卻能夠令不少玩家對其心儀。

改做背景地圖的架構

在上次的 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 功能

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

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

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


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

OGRE 的 SceneNode 挑戰

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

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

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

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