What have you found for these years?

2008-07-14

完整的遊戲開發工具?

(btw, 真的是虛弱到一種程度了,本來想好好寫的,)
(現在只想打混過去... 也才忽然發現前幾個月有一篇寫一半的...)

以 cubeat 的經驗和一些希望的改善與強化的話:

library dependency:
* 3d engine (irrlicht, zlib license)
* sound library (irrklang, free for non-commercial)
* scripting (ruby, ruby license)
* scripting c++ binding (rice/swig, bsd/bsd license)
* database (sqlite, PUBLIC DOMAIN!!!)
* orm (data-mapper, mit license)
* beyond the c++ standard library (boost, boost license)

development dependency:
* standard compliant c++ compiler (g++, gnu public license)
* building automation (cmake, bsd license)
* task automation (rake, mit license)
* source code management (git, gnu public license)
* issue tracker (redmine, gnu public license)
* code generator (erubis, mit license)

其中主要 cubeat 沒用到的是 database 和 orm.
當然,cubeat 本身應該是沒有必要引入這兩樣東西。
只是我總覺得,如果遊戲本身複雜度不斷成長的話,
有一個 database 能用會少掉很多麻煩。而 orm 則是
理所當然一定要用的,不然用 sql 會死人的。

理想上就是只有核心是用 c++ 寫成,其餘的操作,
例如遊戲流程、操作流程等等,這些東西需要修改的可能性極高,
用 ruby 撰寫真是再方便也不過了。
如此一來,引入 data mapper, 則可以使得 ruby object
具有 persistent 的特性。當然,用 marshal 應該也不是不行,
不過用 data mapper 比較 once and for all.

比方說,可以對現在的遊戲狀況做 snapshot,
例如 RTS 的戰場儲存。比 yaml 或 zzml 更方便的
config 能力,preload RPG 的 weapon, unit,
skill, 以 spellbook 來說,spell 資訊,character,
item, 這些全部能以方便的方式儲存,也能夠有方便的方式編輯。
say, rails scaffold? 用 browser 當 map editor,
unit editor, weapon editor, etc...

由於使用了 database 當底層,也可以進行一些 search,
sorting 等動作。當然這可能比較沒必要啦...
一般來說,除非 MMOG, 不然應該不會有超大量的資料需要搜尋。
所以我也一直在想,這樣是否 overkill 了?

不過還是很想試試看可能性,畢竟 data mapper 看起來滿好用的。
希望 1.0 時真的能取代掉 active record + migration combo...

剛剛也有看到有人在 ruby-core 上抱怨 rails 擴充 test/unit 的
手法太過暴力 :o 既然這麼多人在開發,希望以後 rails 程式可以漂亮些。
不然我還真的滿想換一個 framework, 只是大部份都不夠成熟罷了。

4 retries:

波卡 said...

irrlicht好用嗎?O_o?

老林 said...

我在 Cubeat project 中負責比較多和 graphic library 打交道的工作,我想我來說明一下好了。

基本上,因為這個遊戲的前身,是用 Virtools SDK 打造的,所以無寧說是任何 graphic library 相對起來都好用太多了 orz ..................

好,回到主題。Irrlicht 是一個還算輕量,且不是很完整穩定的 graphic library,但重點是很好上手,因為我們 Team 裡面的人對 3D Engine 與底層 DX / OGL 之類的東西,還有電腦圖學,可以說是弱到不行,因此好上手這點加分加很多,當然不少小缺點在日後的使用上陸陸續續地曝露出來,但因為自己還算有能力應付,library source 也隨便我改,所以上手後才遇到的問題反而就還好了。在一面看 library source 與修修補補的過程中,我倒是還一面學到不少 3D API 的概念 orz ...

我是覺得以之前沒碰過 3D Engine 的人想上手,Irrlicht 是一個很適合的 lib,但如果你已經用其他的 lib 用多了,譬如,Ogre 好了,就沒必要回過頭看 Irrlicht 了。Cubeat 本身的 framework 中,本來有一部份是打算可以銜接不同 graphic lib 的,所以也曾經拿 Ogre 來看,看過之後覺得實在不能把這兩個 lib 放在同一個基準上比較,能力跟複雜度都差上一個層次。

Irrlicht 有許多先進功能沒有包裝,譬如說 shader 好了,Ogre 裡有內建的許多 Composition 可以用,Irrlicht 就要在那邊刻可憐的 shader code + Shader Material,內建的 shader 只有 normal map 和 parallax map (雖然有這兩個也很不錯了啦),而且不同的 shader 就只能自己想辦法串起來,我做過一些實驗還蠻辛苦的,從某個 contributor 那邊拿到 shader code A,另一處拿到 shader code B,再另一處拿到 C.. 然後自己想辦法硬幹湊在一起。
Ogre 的 shader composition 就方便多了。

然後 Irrlicht 的跨平台也是有一點點問題,至少 godfat 那邊跑 Mac aqua 或 x11 都曾經遇到小問題就是了。

所以 ...好不好用其實就看從什麼觀點去看啦,撇開先進功能不足,還有一些小問題之外,還算是蠻不錯的輕量 graphic lib,支持者也不算少,他們 forum/community 也算是相當 active 的。另外就是有些配合的套件吧,如 irrKlang、irrEdit、irrXML 之類的 ...雖然 irrEdit 一直到很最近很最近才有完全相容於最新版 irrlicht 的版本,然後 irrKlang 沒有 open source ... XML 則是完全不想碰。

Plumm said...

不過一般商業公司大多還是會用商用的 3d engine。

> spellbook 來說,spell 資訊,character, item, 這些全部能以方便的方式儲存,也能夠有方便的方式編輯。
spellbook 要作動了嘛 :QQ

> 希望以後 rails 程式可以漂亮些。
> 不然我還真的滿想換一個 framework, 只是大部份都不夠成熟罷了。
或是弄個 godfails :QQ

波卡 said...

感謝! <(_ _)>

聽起來真是不錯阿(手癢

Post a Comment

All texts are licensed under CC Attribution 3.0