另一個 Audio / Sound Engine

一直以來，也在找一個可以代替現在使用的 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

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

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

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

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

資料：Youtube 的影片

閒來的 Ogng3D 工具更新

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

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

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

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

Bayonetta 的一些有趣資訊

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

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

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


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


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

Generic Approach

其實，一個遊戲引擎 ( 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

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

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

動作遊戲的下場

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

其實動作類遊戲在遊戲市場上，比起其他類型，佔的百分比一向都較高，但是在 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 中出場。動作遊戲究竟要努力多少年，才能得到各發行商的關注？看來還是那一句：「 距這目標還有很遠。」

最新的 MinGW + OGRE 好像沒事了

在不久前，因為不知名的問題，用 MinGW + OGRE 做出來的 Release / Debug 版本，在計算 Quaternion 時會出錯，這個問題纏繞一陣子之後，好像解決了。解決的辦法就是更新 MinGW，使用新的版本 5.1.4。

雖然新版本的 MinGW 中解決了計算 Quaternion 的問題，但是又衍生了其他小問題，就是一些不同的 Compiler 有不同的 Compile / Linking 處理。例如 Visual C++ 可以這樣的：

quat.ToAngleAxis( rad, Ogre::Vector3::UNIT_X );

但是在新版本的 MinGW 下會報 Error，就改成這樣做：

Ogre::Vector3 v = Ogre::Vector3::UNIT_X;
quat.ToAngleAxis( rad, v );

剛才說的小問題雖然簡單，但是感覺有點莫名的古怪，這種「基本的處理」也有不同，怎樣要人適應呢？而且 MinGW 報的 Error 就是看不明白，更令人摸不著端倪。

Ogng'3D 的 設定工具

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

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

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

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

CEDEC 2009 的一些話

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

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

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

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

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

在製作 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

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

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

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

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

修復斷層 & 更新

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

早前曾經說過，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 的速度，已經很不錯的了。

Animation Blend Mask 測試

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

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

自己的假期

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

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

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

Billboards 與 2D Sprites

在兩個星期前，我嘗試重新製作 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

雞巴 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

玩遊戲的迷思

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

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

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

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

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

Retained 和 Immediate Mode 程式編寫

這幾天農曆新年假期，都沒有特別編寫程式，只是將 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 方便使用，速度高便可以的了。

恭喜發財，萬事勝意

Network 遊戲的學習進展

上週末努力試過使用 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 編寫遊戲嗎 ?

有看過我的 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

在 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 年更開心、更健康。