我沒用 OGRE3D 了

近來發現，有朋友以為我仍然在用OGRE3D，其實在約一年前已經沒有用了，現在用的是「Irrlicht」。

為何呢？因為OGRE3D實在太難用了，雖然它有很多不錯的功能，例如 Animation blending，但仍不足彌補其它的缺點，而且OGRE3D始終只是個Rendering engine。

當然，Irrlicht 也有不足的地方，例如沒有 Animation blending ( 哈... :-P )，但 Irrlicht 的其它功能卻很不錯，其中幾點也頗重要的，Source code 看得懂，內置基本Collision功能，GUI功能，iOS / XCode workspace 容易搞。重要的是，它真的是個 Game engine。 我比較喜歡一些簡單的Game engine，而且有限制的Graphics輸出，也是另一種學問，因為做出有限制的遊戲圖像，而擁有令玩家投入遊戲的氣氛感覺，才是一種遊戲製作的藝術！

p.s. 突然想起了一點，John Carmack曾經說過，(0 == strcmp(str1, str2)) = true，這句程式很有誤導性，他會建議：stringMatched(str1, str2)；我實在不能再同意更多。

Simply the best ?!

昨天我坐在一部電腦前面, 那部電腦的硬件配置一般, 運行著Windows 7(64bit), Intel i3 CPU + Intel Graphics. 同時也看到自己的遊戲 Final Spike 的 Zip 檔案, 忽發奇想 : 九年前製作的電腦遊戲, 能不能在現今的電腦上執行 ?

要證實那個想法, 辦法很簡單, 就是執行一下. 結果是, 很順利地運行著, 完全沒問題, 而且效果聲和背景音樂也是響亮的 !

好了, 到了這裡, 先說一說 Final Spike 是用怎樣的一個電腦程式. 它是個Windows(32bit)遊戲, 使用的 Game engine 是我自己製作的, 用純粹的 C Language 和 DirectX 7, 用了幾個 3rd party 的 DLL 工具. 遊戲也是用純 C Language 編寫, 所有美術, 3D Model, Animations 等等也是我自己一手包辦.

那是九年前的作品, 最後的一個 執行Build 也是九年前的了, 一直以來也沒再 Compile 過. 其實我也想說, 現在究竟有那一個 Game engine 可以做到這個 ? 九年後的 64bit Windows 7 也能夠執行那麼舊的遊戲 ?

那會是 純C Language程式的美麗, 那會是設計簡單的美麗, 也會是結構簡單的美麗 !

近年很少寫Blog嗎？

在過去一年多來，這裡都很小有更新，為什麼呢？

其實我大約會在一、兩個月間寫一篇 blog，但是在過去寫好沒有發佈的 blog 文，內容也不再是說技術或資料的事情，變成了以遊戲製作來發洩不愉快的途徑。每一次寫完 blog 文後，再看一遍時發覺出現這種情況，都只會 save 下而不發佈。

積下了一大堆 blog 文，它們都是充滿著負能量的。

遊戲製作流程, 圖解化 ?!

在 2012 年初時寫的，忘了在這裡發，這幾天看到它的存在，所以將它放上來。



( 下載來看好像比較好 :-P )

尋回 OGRE 的心情

近月在重整自家 Game Engine 工具的過程中，赫然重新發覺，原來自家的 Game Engine 是很容易用的。

我所說的易用，和「習慣」不太有關係，而是在於功能夠齊全。例如最基本的 String 工具，Event 系統，以致 Animation Blending 的控制等功能都有，加上之前製作好的 Actor Editor，Material Editor 等等，用之製作遊戲 Prototype 可以有很高的效率。

而且 OGRE 自身有多種支援工具，以及 Community 有不少的貢獻，令 Production 或是 Assets pipeline 上也不會存在太特別的斷層問題。所以在整體上，OGRE 其實是一個不錯的選擇，尤其是我這一類，自己一人或二、三人的製作 Team，很適合的說。

我的 Game Engine 重新出發

大約在一年前，我說我會離開 OGRE，現在我要說，我要回到 OGRE 的懷抱了。

在過去的一年間，除了在日間工作外，晚上也在進修，所以比較忙，沒空閒去製作自己想做的遊戲，曾經想在有限的空間裡，嘗試一些 OGRE 以外的 Game Engine，但可惜的是，可能是年齡的問題，在知識和習慣上的束縛，和以前的我不一樣了。近日可以靜一靜地在想，其實我的想法很簡單，只是想做遊戲，而不只是想編寫電腦程式，所以我決定回到 OGRE 的身邊了。

重新的面對著 OGRE，它新的版本是 1.7.4 ( 暫時不會用 1.8.0 RC )，令我想起在拋棄它之前曾經試過，但那時候總是 Compile 不能。這次重新嘗試，不知怎的卻很順利，用了不到兩天的時間便可以用到了一年前的基本功能了。( 但現在卡在了一個地方，就是 Overlay 的 Text Element 看不到字形... )

除了面對新的 OGRE 版本外，一些以前的工具也要更新，雖然只是 OGRE 的更新，但也要作一些配合，工具例如：Actor Editor、Material Editor、Mesh / Animation exporter、Viewer... 等等都要逐一更新，看上去好像很多功夫要做，但仍是值得的，因為「我可以製作遊戲」!

遊戲製作是甚麼 ?

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

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

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

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

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

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


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

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

上一回的後來

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

在很久很久之後...

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

我很懷念...

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

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

究竟... 有甚麼好玩 ?

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



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

要放棄的時候就應該放棄

在這些年來，用過不少有關遊戲開發的 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 的關係好了。

日系遊戲與歐美系遊戲

多月前，看過 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 影像 (前編 + 後編)

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

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


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

Gameplay Programmer part.II

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

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

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

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

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

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

在 Content creation 上的目標

很久沒有在 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

自己進入遊戲開發業界工作的時間，是 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 妥協的意義

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

技術：在甚麼平台上製作呢？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

在電腦裡，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

昨天在 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 原文 ]