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

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

       依然游戲很多開發者認為，那些開發工具都是為不會編程的玩家實現的。包括我在內，也是這樣認為的，因為我們追求的目標并不一樣，一個是追求游戲設計的樂趣，一個是追求代碼編寫的快樂以及高可定制性等。

       使用現成的游戲開發工具固然簡單，但是學習的過程以及這些工具的限制，更恐怖的莫過于這些工具的BUG（類似于GameMaker中浮點數的精度問題）都讓我重新考慮傳統游戲開發。但同樣我會面對更多的問題：

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

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

3. 軌跡控制，動畫幀控制，可定制的多邊形碰撞系統

4. 能使用腳本，更有類似于Unreal系列的對象腳本技術，支持腳本暫停，并可調試

5. 一個非常棒的開發環境以及能讓所有組件都可以擴展的系統

也許是我要求很高，至今為止，沒有哪個引擎能支持的那么好，又免費。順便說下評價下幾個C++圖形引擎

HGE：

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

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

3. 粒子系統帶有編輯器，這點很不錯，而且效果也還可以

4. 字體要提出批評，這點做的太差了

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

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

SexFramework（Popcap游戲引擎）

1. 使用DDraw，古老而又穩定的技術，在植物對僵尸的游戲里，明顯看到，當物體過多時，渲染速度急劇下降。當然這里我覺得應該是這個游戲大量使用flash造成的吧（猜測）

2. 支持后臺加載，這點需要大量加分?？吹胶芏郟opcap游戲邊播放動畫邊加載吧？

3. 支持專門的包讀取，api有點像c風格io庫

4. 因為商用，所以可以信賴，別忘記，還支持flash哦

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

1. 統一的C API，簡潔，漂亮，便于與.net結合做編輯器

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

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

4.支持2d縮放，這個技術讓游戲可以變的很酷

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

6. 沒有粒子支持，即便有，也沒有編輯器支持，就這點就很嚴重了

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

Game Virtual Machine

      之所以要提出這個概念，主要是建立在游戲的本質其實也是與網頁很接近的。

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

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

     我所設想的GameVirtualMachine是這樣的：

建立于游戲指令系統之上

       傳統的游戲都是建立在虛擬機基礎上，這樣做的好處就是很靈活。但同時這也造成了程序員為了實現一些游戲中的邏輯關系，硬生生的使用OO這種概念來模擬另外一個概念。這樣做導致了游戲代碼難于理解。

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

       這套指令系統有一些基本指令，這些基本指令類似于一個腳本系統基本的運算以及流程控制等等。

簡化游戲邏輯編寫

       建立在指令系統上的優點是很明顯的。指令系統底層運行著游戲虛擬機，其可以對指令的運行進行控制以便實現，讓精靈走到哪個位置，停一會再走到哪個位置的等一系列流程的操作。這些操作對于傳統裸寫游戲來說，不知道要寫多少次計數器，計時器。

直觀而簡單的調試

        因為不使用腳本語言，調試變的異常簡單，甚至于，玩家想知道游戲怎么運行的，只要打開一個GVM的調試器就可以看到諸如

              move_sprite_to   xxx, xxxx

              attack_enemy xxxx,xxx

可擴展性

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

      指令集著眼的是對象，流程以及邏輯控制。而指令集的實現就是與底層API的交互過程。

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

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

     創建指令的同時，你寫的指令代碼其實就是新的VM代碼。GVM系統會將你的VM代碼與其他VM代碼一起在游戲中運行

編輯器可實現性

       游戲不難做，難做的編輯器。編輯器里最直接的功能就是需要UNDO/REDO，這可以讓設計者在設計重新設計之間反復選擇。因為所有操作都是基于指令的。

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

跨平臺性

       VM的特性已經被廣為使用。從瀏覽器到Android手機操作系統，乃至OS。因此，GVM也是可以跨平臺的。只需要在每個平臺下實現一些平臺相關的模塊就可以