Move to MinGW + Code::Blocks

常常看到網上的 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

今天要介紹一個工具，這個工具是專門做 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

在今年一月時，做了個「 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%，仍在努力開發，完善功能中。

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

其實我已經一段時間，沒有接觸 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

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

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

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

Multi-Thread Programming 的小體會

前幾天看過一些文章，說 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 上很有幫助。另外亦想到，為什麼現時電腦科技這麼發達，還要為這些超級複雜的難題懊惱？！

精神食糧電視劇

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

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

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

棄用收費 3rd party LIB

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

自從開始製作 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 仍是一切嗎 ?

當美國 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 年代 ( 及同時期的街機遊戲 )，好遊戲盡在那些時候。

久違了的工具

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

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

碰撞測試的簡化

早前我試將 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 也可能有不同，看來這一點就很難加以簡化了。

硬派動作遊戲

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

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

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

學習做遊戲製作的迷思

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

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