游戲開發(fā)到現(xiàn)今，已經(jīng)進入到一種固定模式與創(chuàng)意掙扎的階段。Activision Blizzard 剛剛超過EA成為全球最大的游戲制造商，再看下我們周圍的這些所謂的大作，無非就是版本號更高一些，畫面更好一些，然后將其他游戲熱門的創(chuàng)意進行大抄襲意外，幾乎依然保留著最初版本的痕跡和基本玩法。然后，有一些開發(fā)者，依然堅持創(chuàng)建自己的游戲，按照自己的意圖去設計全新的游戲，獨立游戲概念就此出爐。
說到獨立游戲，其實可以被稱作是“小游戲”，這些游戲為了快速實現(xiàn)游戲原型，一般都使用高級的游戲開發(fā)工具，比如說RPGMaker， GameMaker, ActionGameMaker等等。這些工具其實最早的鼻祖，在我認為，莫過于星際爭霸的編輯器，一個完全不需要編程就可以實現(xiàn)游戲創(chuàng)意的工具。最近，星際爭霸2介紹游戲編輯器的視頻放了出來，世界瞬間震撼了。一個RTS游戲的編輯器，居然連射擊游戲都可以制作，雖然在魔獸爭霸3的編輯器中已經(jīng)可以實現(xiàn)類似于跑跑卡丁車這類游戲。
依然游戲很多開發(fā)者認為，那些開發(fā)工具都是為不會編程的玩家實現(xiàn)的。包括我在內(nèi)，也是這樣認為的，因為我們追求的目標并不一樣，一個是追求游戲設計的樂趣，一個是追求代碼編寫的快樂以及高可定制性等。
使用現(xiàn)成的游戲開發(fā)工具固然簡單，但是學習的過程以及這些工具的限制，更恐怖的莫過于這些工具的BUG（類似于GameMaker中浮點數(shù)的精度問題）都讓我重新考慮傳統(tǒng)游戲開發(fā)。但同樣我會面對更多的問題：
1. 一個好的基于Windows的引擎，最好是DX9硬件加速
2. 基于位圖的字體，帶編輯器的粒子，GUI以及控制系統(tǒng)組件
3. 軌跡控制，動畫幀控制，可定制的多邊形碰撞系統(tǒng)
4. 能使用腳本，更有類似于Unreal系列的對象腳本技術，支持腳本暫停，并可調(diào)試
5. 一個非常棒的開發(fā)環(huán)境以及能讓所有組件都可以擴展的系統(tǒng)
也許是我要求很高，至今為止，沒有哪個引擎能支持的那么好，又免費。順便說下評價下幾個C++圖形引擎
HGE：
1. 使用DX8，很多DX9特性不能完全支持，例如很多DX9的API，HLSL等，雖然這些看似在2D里用處不大
2.低效的zip讀取機制。zip的文件讀取以及查找居然采用字符串比較，也就是attach的zip越多，查找速度越慢
3. 粒子系統(tǒng)帶有編輯器，這點很不錯，而且效果也還可以
4. 字體要提出批評，這點做的太差了
5. 原始版不支持unicode，使用hge社區(qū)里某大俠提供的unicode版本后，做國際化方便多了
6. 純粹簡單游戲引擎，做下貓貓狗狗的差不多，做復雜的格斗的話，很費力
SexFramework（Popcap游戲引擎）
1. 使用DDraw，古老而又穩(wěn)定的技術，在植物對僵尸的游戲里，明顯看到，當物體過多時，渲染速度急劇下降。當然這里我覺得應該是這個游戲大量使用flash造成的吧（猜測）
2. 支持后臺加載，這點需要大量加分。看到很多Popcap游戲邊播放動畫邊加載吧？
3. 支持專門的包讀取，api有點像c風格io庫
4. 因為商用，所以可以信賴，別忘記，還支持flash哦
IndieLib（可以在我的博客前面的文章找到）
1. 統(tǒng)一的C API，簡潔，漂亮，便于與.net結合做編輯器
2. 硬件DX9加速，比HGE好多了，而且數(shù)學庫清一色使用D3DX，更是快的一塌糊涂
3. 支持多邊形碰撞檢測，以及XML定制的動畫幀
4.支持2d縮放，這個技術讓游戲可以變的很酷
5. 沒有支持壓縮包讀取，但是從代碼上看，加的話應該不困難
6. 沒有粒子支持，即便有，也沒有編輯器支持，就這點就很嚴重了
各位如果有的2d引擎庫，也請推薦下
Game Virtual Machine
之所以要提出這個概念，主要是建立在游戲的本質其實也是與網(wǎng)頁很接近的。
縱覽網(wǎng)頁的開發(fā)模型，不難看出這部分已經(jīng)是很成熟的了。例如：ASP可以自動將你的標記過的代碼編譯成客戶端或者服務器的版本。自動排版引擎的概念徹底推翻了微軟以左上角像素的對象顯示方式。一個網(wǎng)頁，支持各種腳本擴展以及Flash這種RIA應用
游戲，如果僅僅按照類型來做限定時，GameMaker，RPGMaker這類工具已經(jīng)能將游戲開發(fā)的概念抽象成一些步驟以及參數(shù)。但問題是，要使用這些工具來制作一些并不常見的游戲類型時，可能見變得非常難，當然這點上，GameMaker要做的好一些，這個工具使用了很多類似于腳本圖形化技術，說白了，底層仍然是它的腳本，只不過經(jīng)過一層圖形化工具的封裝后給你使用而已。
我所設想的GameVirtualMachine是這樣的：
建立于游戲指令系統(tǒng)之上
傳統(tǒng)的游戲都是建立在虛擬機基礎上，這樣做的好處就是很靈活。但同時這也造成了程序員為了實現(xiàn)一些游戲中的邏輯關系，硬生生的使用OO這種概念來模擬另外一個概念。這樣做導致了游戲代碼難于理解。
很現(xiàn)實的一個例子就是C++的反射問題。C#中將反射做到了編譯器以及Runtime層，這讓開發(fā)者們一門心思的進行程序設計，雖然有一些性能損失，但是對于很多C++項目不停不停的造反射這個輪子來說明顯是值得的。
這套指令系統(tǒng)有一些基本指令，這些基本指令類似于一個腳本系統(tǒng)基本的運算以及流程控制等等。
簡化游戲邏輯編寫
建立在指令系統(tǒng)上的優(yōu)點是很明顯的。指令系統(tǒng)底層運行著游戲虛擬機，其可以對指令的運行進行控制以便實現(xiàn)，讓精靈走到哪個位置，停一會再走到哪個位置的等一系列流程的操作。這些操作對于傳統(tǒng)裸寫游戲來說，不知道要寫多少次計數(shù)器，計時器。
直觀而簡單的調(diào)試
因為不使用腳本語言，調(diào)試變的異常簡單，甚至于，玩家想知道游戲怎么運行的，只要打開一個GVM的調(diào)試器就可以看到諸如
move_sprite_to xxx, xxxx
attack_enemy xxxx,xxx
可擴展性
為了制作通用游戲，這套指令是可以被擴展的。例如精靈控制子集，地圖控制子集等等
指令集著眼的是對象，流程以及邏輯控制。而指令集的實現(xiàn)就是與底層API的交互過程。
如果你說現(xiàn)在編輯器不能實現(xiàn)一個飛龍隨機飛舞并由玩家控制吐火的邏輯時，你便可為這個游戲編寫一些隨機飛舞，吐火的指令，底層實現(xiàn)完全依賴于一些API。
創(chuàng)建指令的目的，就是讓游戲的操作變成一種組件開發(fā)的接口創(chuàng)建工程。讓更多的玩家可以為游戲邏輯互相編寫，共享代碼
創(chuàng)建指令的同時，你寫的指令代碼其實就是新的VM代碼。GVM系統(tǒng)會將你的VM代碼與其他VM代碼一起在游戲中運行
編輯器可實現(xiàn)性
游戲不難做，難做的編輯器。編輯器里最直接的功能就是需要UNDO/REDO，這可以讓設計者在設計重新設計之間反復選擇。因為所有操作都是基于指令的。
其實所謂的編輯器，也就是一個腳本生成器。諸多的按鈕，ComboBox等等其實都是低效的，但是對于不會編程，或者需要快速開發(fā)的玩家來說，GUI是唯一的選擇。當然，如果在某些部分需要特殊邏輯時，就可以與指令混合編寫
跨平臺性
VM的特性已經(jīng)被廣為使用。從瀏覽器到Android手機操作系統(tǒng)，乃至OS。因此，GVM也是可以跨平臺的。只需要在每個平臺下實現(xiàn)一些平臺相關的模塊就可以