游戲開發(fā)到現(xiàn)今，已經(jīng)進(jìn)入到一種固定模式與創(chuàng)意掙扎的階段。Activision Blizzard 剛剛超過EA成為全球最大的游戲制造商，再看下我們周圍的這些所謂的大作，無非就是版本號(hào)更高一些，畫面更好一些，然后將其他游戲熱門的創(chuàng)意進(jìn)行大抄襲意外，幾乎依然保留著最初版本的痕跡和基本玩法。然后，有一些開發(fā)者，依然堅(jiān)持創(chuàng)建自己的游戲，按照自己的意圖去設(shè)計(jì)全新的游戲，獨(dú)立游戲概念就此出爐。

        說到獨(dú)立游戲，其實(shí)可以被稱作是“小游戲”，這些游戲?yàn)榱丝焖賹?shí)現(xiàn)游戲原型，一般都使用高級(jí)的游戲開發(fā)工具，比如說RPGMaker， GameMaker, ActionGameMaker等等。這些工具其實(shí)最早的鼻祖，在我認(rèn)為，莫過于星際爭霸的編輯器，一個(gè)完全不需要編程就可以實(shí)現(xiàn)游戲創(chuàng)意的工具。最近，星際爭霸2介紹游戲編輯器的視頻放了出來，世界瞬間震撼了。一個(gè)RTS游戲的編輯器，居然連射擊游戲都可以制作，雖然在魔獸爭霸3的編輯器中已經(jīng)可以實(shí)現(xiàn)類似于跑跑卡丁車這類游戲。

       依然游戲很多開發(fā)者認(rèn)為，那些開發(fā)工具都是為不會(huì)編程的玩家實(shí)現(xiàn)的。包括我在內(nèi)，也是這樣認(rèn)為的，因?yàn)槲覀冏非蟮哪繕?biāo)并不一樣，一個(gè)是追求游戲設(shè)計(jì)的樂趣，一個(gè)是追求代碼編寫的快樂以及高可定制性等。

       使用現(xiàn)成的游戲開發(fā)工具固然簡單，但是學(xué)習(xí)的過程以及這些工具的限制，更恐怖的莫過于這些工具的BUG（類似于GameMaker中浮點(diǎn)數(shù)的精度問題）都讓我重新考慮傳統(tǒng)游戲開發(fā)。但同樣我會(huì)面對(duì)更多的問題：

1. 一個(gè)好的基于Windows的引擎，最好是DX9硬件加速

2. 基于位圖的字體，帶編輯器的粒子，GUI以及控制系統(tǒng)組件

3. 軌跡控制，動(dòng)畫幀控制，可定制的多邊形碰撞系統(tǒng)

4. 能使用腳本，更有類似于Unreal系列的對(duì)象腳本技術(shù)，支持腳本暫停，并可調(diào)試

5. 一個(gè)非常棒的開發(fā)環(huán)境以及能讓所有組件都可以擴(kuò)展的系統(tǒng)

也許是我要求很高，至今為止，沒有哪個(gè)引擎能支持的那么好，又免費(fèi)。順便說下評(píng)價(jià)下幾個(gè)C++圖形引擎

HGE：

1. 使用DX8，很多DX9特性不能完全支持，例如很多DX9的API，HLSL等，雖然這些看似在2D里用處不大

2.低效的zip讀取機(jī)制。zip的文件讀取以及查找居然采用字符串比較，也就是attach的zip越多，查找速度越慢

3. 粒子系統(tǒng)帶有編輯器，這點(diǎn)很不錯(cuò)，而且效果也還可以

4. 字體要提出批評(píng)，這點(diǎn)做的太差了

5. 原始版不支持unicode，使用hge社區(qū)里某大俠提供的unicode版本后，做國際化方便多了

6. 純粹簡單游戲引擎，做下貓貓狗狗的差不多，做復(fù)雜的格斗的話，很費(fèi)力

SexFramework（Popcap游戲引擎）

1. 使用DDraw，古老而又穩(wěn)定的技術(shù)，在植物對(duì)僵尸的游戲里，明顯看到，當(dāng)物體過多時(shí)，渲染速度急劇下降。當(dāng)然這里我覺得應(yīng)該是這個(gè)游戲大量使用flash造成的吧（猜測）

2. 支持后臺(tái)加載，這點(diǎn)需要大量加分。看到很多Popcap游戲邊播放動(dòng)畫邊加載吧？

3. 支持專門的包讀取，api有點(diǎn)像c風(fēng)格io庫

4. 因?yàn)樯逃茫钥梢孕刨嚕瑒e忘記，還支持flash哦

IndieLib（可以在我的博客前面的文章找到）

1. 統(tǒng)一的C API，簡潔，漂亮，便于與.net結(jié)合做編輯器

2. 硬件DX9加速，比HGE好多了，而且數(shù)學(xué)庫清一色使用D3DX，更是快的一塌糊涂

3. 支持多邊形碰撞檢測，以及XML定制的動(dòng)畫幀

4.支持2d縮放，這個(gè)技術(shù)讓游戲可以變的很酷

5. 沒有支持壓縮包讀取，但是從代碼上看，加的話應(yīng)該不困難

6. 沒有粒子支持，即便有，也沒有編輯器支持，就這點(diǎn)就很嚴(yán)重了

各位如果有的2d引擎庫，也請推薦下

Game Virtual Machine

      之所以要提出這個(gè)概念，主要是建立在游戲的本質(zhì)其實(shí)也是與網(wǎng)頁很接近的。

       縱覽網(wǎng)頁的開發(fā)模型，不難看出這部分已經(jīng)是很成熟的了。例如：ASP可以自動(dòng)將你的標(biāo)記過的代碼編譯成客戶端或者服務(wù)器的版本。自動(dòng)排版引擎的概念徹底推翻了微軟以左上角像素的對(duì)象顯示方式。一個(gè)網(wǎng)頁，支持各種腳本擴(kuò)展以及Flash這種RIA應(yīng)用

      游戲，如果僅僅按照類型來做限定時(shí)，GameMaker，RPGMaker這類工具已經(jīng)能將游戲開發(fā)的概念抽象成一些步驟以及參數(shù)。但問題是，要使用這些工具來制作一些并不常見的游戲類型時(shí)，可能見變得非常難，當(dāng)然這點(diǎn)上，GameMaker要做的好一些，這個(gè)工具使用了很多類似于腳本圖形化技術(shù)，說白了，底層仍然是它的腳本，只不過經(jīng)過一層圖形化工具的封裝后給你使用而已。

     我所設(shè)想的GameVirtualMachine是這樣的：

建立于游戲指令系統(tǒng)之上

       傳統(tǒng)的游戲都是建立在虛擬機(jī)基礎(chǔ)上，這樣做的好處就是很靈活。但同時(shí)這也造成了程序員為了實(shí)現(xiàn)一些游戲中的邏輯關(guān)系，硬生生的使用OO這種概念來模擬另外一個(gè)概念。這樣做導(dǎo)致了游戲代碼難于理解。

        很現(xiàn)實(shí)的一個(gè)例子就是C++的反射問題。C#中將反射做到了編譯器以及Runtime層，這讓開發(fā)者們一門心思的進(jìn)行程序設(shè)計(jì)，雖然有一些性能損失，但是對(duì)于很多C++項(xiàng)目不停不停的造反射這個(gè)輪子來說明顯是值得的。

       這套指令系統(tǒng)有一些基本指令，這些基本指令類似于一個(gè)腳本系統(tǒng)基本的運(yùn)算以及流程控制等等。

簡化游戲邏輯編寫

       建立在指令系統(tǒng)上的優(yōu)點(diǎn)是很明顯的。指令系統(tǒng)底層運(yùn)行著游戲虛擬機(jī)，其可以對(duì)指令的運(yùn)行進(jìn)行控制以便實(shí)現(xiàn)，讓精靈走到哪個(gè)位置，停一會(huì)再走到哪個(gè)位置的等一系列流程的操作。這些操作對(duì)于傳統(tǒng)裸寫游戲來說，不知道要寫多少次計(jì)數(shù)器，計(jì)時(shí)器。

直觀而簡單的調(diào)試

        因?yàn)椴皇褂媚_本語言，調(diào)試變的異常簡單，甚至于，玩家想知道游戲怎么運(yùn)行的，只要打開一個(gè)GVM的調(diào)試器就可以看到諸如

              move_sprite_to   xxx, xxxx

              attack_enemy xxxx,xxx

可擴(kuò)展性

      為了制作通用游戲，這套指令是可以被擴(kuò)展的。例如精靈控制子集，地圖控制子集等等

      指令集著眼的是對(duì)象，流程以及邏輯控制。而指令集的實(shí)現(xiàn)就是與底層API的交互過程。

      如果你說現(xiàn)在編輯器不能實(shí)現(xiàn)一個(gè)飛龍隨機(jī)飛舞并由玩家控制吐火的邏輯時(shí)，你便可為這個(gè)游戲編寫一些隨機(jī)飛舞，吐火的指令，底層實(shí)現(xiàn)完全依賴于一些API。

      創(chuàng)建指令的目的，就是讓游戲的操作變成一種組件開發(fā)的接口創(chuàng)建工程。讓更多的玩家可以為游戲邏輯互相編寫，共享代碼

     創(chuàng)建指令的同時(shí)，你寫的指令代碼其實(shí)就是新的VM代碼。GVM系統(tǒng)會(huì)將你的VM代碼與其他VM代碼一起在游戲中運(yùn)行

編輯器可實(shí)現(xiàn)性

       游戲不難做，難做的編輯器。編輯器里最直接的功能就是需要UNDO/REDO，這可以讓設(shè)計(jì)者在設(shè)計(jì)重新設(shè)計(jì)之間反復(fù)選擇。因?yàn)樗胁僮鞫际腔谥噶畹摹?/p>

     其實(shí)所謂的編輯器，也就是一個(gè)腳本生成器。諸多的按鈕，ComboBox等等其實(shí)都是低效的，但是對(duì)于不會(huì)編程，或者需要快速開發(fā)的玩家來說，GUI是唯一的選擇。當(dāng)然，如果在某些部分需要特殊邏輯時(shí)，就可以與指令混合編寫

跨平臺(tái)性

       VM的特性已經(jīng)被廣為使用。從瀏覽器到Android手機(jī)操作系統(tǒng)，乃至OS。因此，GVM也是可以跨平臺(tái)的。只需要在每個(gè)平臺(tái)下實(shí)現(xiàn)一些平臺(tái)相關(guān)的模塊就可以