學習做遊戲製作的迷思

之前我曾經說過，製作遊戲不難，只要對自己的要求不要過高便可以，例如不要一開始便製作如「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

「 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 製作 ?

曾經有人問過我，覺得怎樣才是一個理想的遊戲開發 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 ... 等等，都是免費 / 便宜的製作工具。

昨日, 今日, 明日

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

重新認識 Newton Game Dynamics

我在製作「 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 的這個部份了。

玩遊戲是奢侈品

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

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

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

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

把工作還給 Artist 和 Game Designer

在製作遊戲的時候，會常常出現一個情況，就是遊戲需要作一些調整，如果遊戲是獨自一個人開發 ( 像我一樣 )，這情況做成的問題不甚明顯，但當遊戲製作是一個團隊 ( 成員為二位或以上 )，那麼情況就會變成一個大問題，因為 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 這個方案。

製作遊戲很難的嗎？

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

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

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

對 C Language 的體會

很多朋友都知道，我是個 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)

完成 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 ?

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

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

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

Actor Setup 工具 (WIP #2)

作戰了數天時間，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 !

近日朋友介紹我玩一個軟件，這軟件叫做「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)

前陣子有機會接觸 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

剛剛用了兩、三天的時間，做了個 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 完成

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

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

製作 OGRE 的 Material 工具

一個多星期前，我開始製作一個 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 工具，仍是一個不二之選。

新一年的開始

近日我在 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 呢 )，那麼對於我製作動作遊戲便更加得心應手了。

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

聖誕節快樂

一年一度，聖誕節又到。

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

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

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

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

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

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

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

要做還是不要做

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

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

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

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