在我的心目中,有些遊戲是很想做的,它們大多是動作遊戲,例如「 Final Spike 」的格鬥遊戲。
在前一陣子,我嘗試過一些簡單的 Networking 程式編寫,成功地將兩部 LAN 內的 PC 連線起來,各自控制自己的角色移動之餘,也看到對方在移動。在這個頗成功的試驗後良久,這幾天決定了,希望做一隻新的遊戲,名字方面暫時名為「 Grand Hunting 」。遊戲內容及 Game Play 也是一個動作遊戲,而且是 LAN 內連線遊玩 ( 我的 Ogng'3D Networking 部份還未支援 NAT 對外連線... )。
在剛剛過去的週末,在家中做 3D Model,不知道手腕是否有健康問題,做了一會兒 Model 後,手腕便感到痛楚,不能長時間做 Model 製作呢..... :-(
Monday, April 27, 2009
Saturday, April 25, 2009
技術性的選擇
大約一個月前,一位朋友所製作的遊戲推出了,幾天前和他在 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 完美及暢順地運作,相信在遊戲創作上,能夠有足夠的空間發揮。
在遊戲製作的實際情況上,技術性的選擇,往往都是順利與否的其中一個關鍵。以我自己的 Ogng'3D 及上面的 UI 情況為例子,一直想用 Sprite 功能來製作 UI,但 Sprite 的結構上,都是 Programmer 向的功能,除了 Hard Code 之外,完全沒有任何工具可以製作 Sprite 的。我自己是使用 MilkShape3D 來製作 3D Model 的,曾經想過在其中製作 Sprite,然後用這些 Sprite 製作 UI ,後來覺得在 Pipeline 上要牽涉的步驟過多,所以暫時擱置了。
要做就一個暢順的製作 Pipeline,在技術使用的選擇絕對不能馬虎,若能夠使製作 Pipeline 完美及暢順地運作,相信在遊戲創作上,能夠有足夠的空間發揮。
Thursday, April 16, 2009
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!
今時今日要找答案,或溫故知新,當然是到 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!
Monday, April 13, 2009
為什麼要有 Examples ?
其實應該在很早之前,便要為我的 Game Engine 「Ogng'3D」製作 Examples,但不知為何,總是提不起興趣來做。在這幾天的復活節假期,終於為她製作了幾個 Examples,及一個 Examples 的 Workspace。
為什麼要有 Examples 呢? Ogng'3D 只是我自己使用,應該不需要 Examples 來作為用家指引。但近來我發現了一個問題 ( 終於... :P ),就是 Ogng'3D 中有很多功能,自己忘記了怎樣使用,常常要看多兩眼才記起使用方法。就是這個情況下,我決定還是要用點時間,為她製作一些簡單的 Examples,作為自己參考的用途。而且,使用 Examples 作為測試平台,也是不錯的選擇。其實說到尾,我自己也是個用家啊,也會有需要用家指引的時候。
為什麼要有 Examples 呢? Ogng'3D 只是我自己使用,應該不需要 Examples 來作為用家指引。但近來我發現了一個問題 ( 終於... :P ),就是 Ogng'3D 中有很多功能,自己忘記了怎樣使用,常常要看多兩眼才記起使用方法。就是這個情況下,我決定還是要用點時間,為她製作一些簡單的 Examples,作為自己參考的用途。而且,使用 Examples 作為測試平台,也是不錯的選擇。其實說到尾,我自己也是個用家啊,也會有需要用家指引的時候。
Friday, April 10, 2009
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 變得系統化及易於管理。
前陣子再訪這個閣置了的 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 變得系統化及易於管理。
Monday, April 06, 2009
次世代遊戲的 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,在設計上令玩家們都很容易明白遊戲的進程,它沒有很獨特的圖像表現,但卻能夠令不少玩家對其心儀。
次世代,當然是指下一個新世代了,其實以現時的遊戲開發發展,好像已經沒有「次世代」了,因為技術層面上已經沒有了這個框架。回來說正題吧,上星期看了一本報導有關遊戲製造業界的雜誌,裡面翻譯了一篇由日本 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,在設計上令玩家們都很容易明白遊戲的進程,它沒有很獨特的圖像表現,但卻能夠令不少玩家對其心儀。
Subscribe to:
Posts (Atom)