Technical Artist ?

大家有沒有看過這個職銜呢？Technical Artist，中文直譯的就是「 技術美術員 」，那究竟這個職位是做甚麼的呢？

在兩年前，認識了一位在美國遊戲業工作的人員，他的職銜就是 Technical Artist。雖然說是 Artist，但是他卻一點畫作也不懂，他每每也會開動 MAYA 來做一些測試，他曾經說過，他的工作是非常困難和獨特的，那時候有點令我摸不著頭腦。昨天我在閱讀一本有關遊戲製作的雜誌，其中一篇文章講述了這個職位的工作範疇。

在那文章初，說了一個有趣的情況：製作遊戲時，Artist 都會向 Programmer 要求工具支援，過一會兒後，Artist 就會收到 Programmer 做好的工具，但是對 Artist 來說，這些工具都是不容易使用的。另外在製作後期，因為 Artist 做出來的東西，令遊戲運行速度表現差，Artist 和 Programmer 在這時候又會開始一場拉鋸戰了。

Technical Artist 的職位就在這個情況下出現的了。在遊戲製作整個過程中，不斷在 Artist 及 Programmer 中周旋，抓取一個在他們之間的平衡點，不失遊戲的運行速度，而又可達到 Artist 要求的效果，並與以執行。

我所閱讀的雜誌：程序員 遊戲創造 ( 2008 年 12 月下 )

IMGUI

在 2008 年期間，因為要做製作遊戲的工具，所以接觸了很多有關 Win32 API 的資料，它雖然很強大，但在實際製作工具的時候，仍覺得它頗為麻煩的，常常要處理一些 Message，而且沒有一個好用的 GUI Design 工具 ( 或是可以自訂 Skin 的工具 )，對我來說寫這類 Program 時感覺就是不太順暢。

今天閒來在 Web Surfing 時候，發現了一個 GUI 的 Concept：「 IMGUI 」( Immediate-Mode Graphical User Interfaces )，看了一些簡介之後，頓時發覺這個就是我想做的東西，所以便開始看多一點這方面的資料。IMGUI 很簡單，不需要處理煩瑣的 Messages 及 States，只需要處理 UI Context 及 Widgets 便可以。在數個月前我確實想過類似的東西，只是在開始上出了點問題未能解決而放下了，那時候還未得知這個 IMGUI 的存在。

這個 IMGUI 方案，我覺得很適合在遊戲製作上使用，而下是幾個有關這個方案的資料：

• IMGUI seminar with Jetro Lauha at Assembly 2007 Summer
• Immediate-Mode Graphical User Interfaces (Video)
• Sol on Immediate Mode GUIs (IMGUI)

p.s. 其實可能很多 GUI 的方案都是使用這個 Concept 的，只是沒有說明罷了，而上面的資料卻引起了我的輕趣及注目呢，而且 ... IMGUI 的設計上是 Anti-OOP 的，我喜歡！ :D :D

聖誕節的願望

在 2008 年期間，有個遊戲一直都想玩的，但是因為日本的保護主意 ( 我覺得是我國某些 Online game 玩家的行為引致的 )，令我不能正常地體驗，那遊戲就是熱烈的「 Monster Hunter Frontier 」( PC 版本的 Monster Hunter )。能夠玩到這遊戲，可能是我在今年聖誕節中的願望。

從未試過有一隻 online game 是可以「如此」吸引我的，以前曾經覺得「 Phantasy Star Online 」是好玩的，但 Monster Hunter 的 Action 度卻是比 PSO 高很多。以往曾玩過 PS2 版本的 Monster Hunter，但那時候未有 Online 或合作模式版本，所以覺得不太好玩，但有了 Online 及合作模式後卻變得吸引我了。

以前曾經想在家中，能夠玩到類似「 SpikeOut 」的遊戲，但 SEGA 一直都沒有移值這遊戲到 Console 機或電腦上 ( 很多年後才在 XBox 上出現 )，所以我才搞一個「 Final Spike 」出來給自己玩。那麼我可能要自己搞一個叫做「 Behemoth Slayer 」，來滿足自己對 Monster Hunter 的興趣了。

工具製作，2008 回顧

一年容易又到年尾了，在今年年初時，決意要製作一些遊戲製作工具，在這裡要回看一下，究竟做了些甚麼出來。

Material Editor (1) (2)
雖然 OGRE 有一個很不錯的資源管理系統，但要用於製作工具時卻是非常困難的，而 Material 的管理是其中的致命傷。因為那個 Material 是以一個 Script 來儲存的，要製作好一個 Material script 和觀察它在 OGRE 中的表現是頗為困難的。這個工具可以製作一些簡單的 Material script，亦同時可以看到在 OGRE 中的表現。

Character Editor (1) (2) (3)
在 2007 年尾時開始接觸 Event / Data driven 的編程技術，從中學懂了一些相關的理念，所以就利用製作這工具的機會同時實踐 Event 系統。工具主要的功能是管理 Animation 的速度和 Event 的發放，這個工具只要配合 MilkShape3D Animation Splitter 工具及 OGRE Mesh Exporter 就能順利完成相關工作。

OLM MilkShape3D Plugin
這個是從朋友的 OLM ( Open Light Mapper ) 工具衍生出來的，因為覺得它的功能強大而且易用，所以便在一個短時間內，將我常用的 MilkShape3D 及 OLM 整合起來。


雖然只是製作了三個工具，但功能上絕對是紮實的，而且 Bugs 量更是極少 ( :-P )。其實在我的心目中，有一個工具一直都很想做的，就是一個類似 Scene Builder 的工具，之前在製作 OLM MilkShape3D Plugin 時學懂了一點東西，希望能夠在 MilkShape3D 中，完成類似的功能，而這個 Scene Builder，可能是最後一個需要製作的工具呢。

經濟衰退的遊戲

經濟又再進入衰退，香港在十年間遇過數次經濟危機，可以說是難得一見，所以我也來發發牙痕。

有人說，電影業與遊戲業在經濟衰推時，多數都不會受影響，因為現實上很不高興，人們都會到電影院或待在家中看電影，又或者慳來不出外用晚餐的洗費，換來一隻電子遊戲留在家中遊玩。

以上所說的，都好像確切地出現過，每每所謂的經濟衰退，都不太聽過遊戲業受牽連，但究竟事實是否如此？多年前日本曾經試過一次頗利害的經濟衰退，日本是其中一個遊戲業界大國，當年有多個遊戲業界新聞，說某某遊戲公司裁員，某某遊戲公司結業，其實如今的一間遊戲母公司，拆散做多間子公司，就是在那時候出現的。簡化架構，精簡人手，就是要做到減省開支，而不失質量。

這次的經濟危機乃全球性問題，而現時的次世代遊戲，往往開發時間長及成本龐大，相信對遊戲製作公司有一定的壓力。而日本作為其中一個遊戲業界大國，近幾年各大遊戲商都將遊戲「國際化」，但同時卻犧牲了日本遊戲獨有的遊戲性，回看 PS One 或 SEGA Saturn 時期的遊戲，比現時 PS3 或 XBox360 的遊戲更好玩更好賣，難怪日本業界近年只專注於「炒冷飯」或「Remake」。

經濟衰退不是一年半載能夠輕易復甦，近年歐洲是個新興的遊戲發展市場，究竟下一年這市場能否保持著那分熱鬧，就要看看到時的國際環境變成如何了。

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 ... 等等，都是免費 / 便宜的製作工具。