前言
第一節 場景管理器（world）
在pc中我們有著海量可以使用的資源，包括各種各樣的資源 ，要說有限制也是機器本身的限制。甚至裡面乙個小小的檔案都有可能比我們的j2me遊戲本身都大。於是乎在做pc遊戲的時候更多考慮的是遊戲的效果如何，執行速度如何，而我們也可以天馬行空的使用著各種我們可以使用的特效。於是渲染器成了引擎中的重頭戲，呵呵，誰不喜歡看自己的遊戲能玩出好多特別cool的效果來，反正我想。
唉，雖然為pc的遊戲興奮了半天可我們畢竟不是做pc遊戲的，我們做的是比pc遊戲更牛x的j2me遊戲。為什麼說更牛x呢，敢問那個pc遊戲可以在僅僅使用100k heap的情況下可以把《古墓麗影》《細胞**》這樣的遊戲做的爐火純青，玩家愛不釋手？100k heap，這是什麼概念？都學過計算機理論，知道那是多大。
在這種情況下我們引出第一次從天堂的墮落：場景管理器。我們仍然拿拍電影來做分析。第一章那個小片段中的場景是乙個狹窄的街道，中間要放好多道具，「導演」不停的要求「劇務」放這放那，那麼如果「劇務」足夠聰明的話他肯定要採取一種比較省時省力的辦法，而不是一趟一趟的往庫房跑。但是本身劇務可以放置道具的地方並不多，於是一次取多少道具以及道具的使用率就決定了「劇務」的勞動量。同理，我們可以把「劇務」可以控制的空間比作heap，「劇務」去庫房拿「道具」比作i/o操作。既要最大程度滿足「導演」的需求，又要保證「時間」不過多地浪費在去「庫房」的路上又不能超出當前所能控制的空間....其實這個真的很難！就像自己的女人要求天天跟她在一起，而自己又因為要掙錢奔波一樣^_^。
問題出來了，至於怎麼樣最省力我們仍然需要不斷的探索。乙個好辦法就是「劇務」首先掌握「庫房」中「道具」存放位置，等需要的時候一步到位拿出來即可，省去找尋的時間。至於怎麼滿足「導演」的需要那是另一碼事，咱們解決這個問題。我相信大家在學習過程中看**是最直接，最有效的方式，為了證明我的想法我找了乙個s40版的《細胞**》來學習研究一下。（如果大家已經看過我的msn 空間了，下面可以略過）
第一步從我們的分析中就可以看出應該是「掌握道具在庫房中的位置」，這個嘛和我們打的檔案包是有一定關係的，需要在檔案中加入一些附屬的資訊，下面是gameloft細胞**部分檔案操作**，**中有詳細說明。
在我的感覺中gameloft一定採用了什麼方法。我曾經大概猜測了一下，無非就是將檔案的一些資訊扔到乙個包裡然後在包裡記錄一些檔案的資料資訊，比如便移量什麼的。我的包就是那麼作的，但是缺點很明顯，必須要一次載入所有的資源，也不是必須，如果不那樣就每次根據需要
來搜尋資源位置就很費cpu資源了。
首先來看gameloft的第一段**：（反編譯後的）
private static final boolean b(string s1)
inputstream.close();
inputstream = null;
system.gc();
}catch(exception exception)
return true;
}這段**中並沒有反應出系統載入了乙個包，而是一些亂七八糟的東西，這段**也是一直困擾我的地方，明明是載入東西，可是卻載入了一
股子整數。
沒辦法，接著看吧，也許整合起來就知道做什麼用的了。
我最敏感的就是byte這個詞，於是我發現了這段**
private static final byte addrecord(int i1)
catch(exception exception)
system.gc();
return abyte0;
}從上面的**我們不難總結出，首先將所有的「道具」的大小和位置儲存下來有多麼大的好處。但是他也有它的限制，如果大家就這樣然後一味的生搬硬套到自己的專案中那你就慘了，如果「道具」比較大比如地圖資料之類的還好說，很長時間呼叫一回i/o，如果是一些小檔案光i/o操作就能搞死手機。所以我們因該想出更好的解決方案，就是讓那個addrecord可以接受乙個陣列，在不超出heap size的情況下調入多個檔案。**我就不給出了，有了上面的**大家很容易就可以做出來。或許比gameloft更好也說不定哦
呵呵，從理論到實踐，我們走出第一步。我並不主張大家就照本宣科的把人家的東西拿來就用，也許有人說，暈，這麼簡單，對！在你做出來之前都是困難的！只要用心，只有想不到沒有做不到！
上面的問題我們已經解決掉了，但是如何排程最快最省時間？這是個人者見人，妖者見妖的問題，一般要根據專案的需求來做，如果是乙個rpg遊戲，劇情節奏緩慢，就沒有必要把好多資源一起載入，僅把需要的載入即可。而乙個劇情發展迅速，對速度要求較高的空戰遊戲我們最好還是盡最大程度將「道具」資源載入較好。
從我的敘述中似乎對場景管理器的「管理」方面敘述不夠多，我也注意到了嘿嘿。其實場景管理器除了從庫房調入「道具」並加入自己的「道具」列表，更重要的乙個工作就是在合適的時候將道具放回庫房，釋放自己能控制的「空間」並從「道具」列表中刪除。那麼我們怎麼樣才可以實現呢？這個問題也比較撓頭，筆者曾經做過一些探索，但效果不甚理想。我的方案就是對當前「劇務」所能控制的每個道具進行使用頻率計算，使用過就+1,在一定頻率內沒有使用就-1,直到變成0就釋放掉，效果不是很理想。於是回歸原始，每段遊戲完畢後就將資源手動**一次，呵呵。這樣雖然有悖於引擎的宗旨，但的確是效率最好的。
汗！雖然本節講的是「場景管理器」，可更多的敘述了場景資源的排程，其實這麼講是有原因的。在j2me中所謂「管理」最有可能就是用陣列來實現的，所以管理方面顯得就比較薄弱，而資源的排程則可能是n個函式和變數組成。先前我也說過理論與實現的關聯和差距，但可以肯定地一點是由理論帶動實踐開發才是快速提高自身水平之路。理論不正確，方向就會錯誤，彎路就成不可避免的了。
j2me遊戲引擎程式結構
2004 11 17 唐良遊戲引擎的結構很多，不過基本上都是在乙個遊戲主迴圈內實現。程式裡面的主迴圈包含了程式框架的最主要的結構體。j2me 的程式一般都包含兩個 class 檔案，乙個是 midlet,乙個是displayable 一般我都是把遊戲的主要 放在 displayable 這個類裡面。...
J2ME遊戲引擎程式結構
遊戲引擎的結構很多，不過基本上都是在乙個遊戲主迴圈內實現。程式裡面的主迴圈包含了程式框架的最主要的結構體。j2me 的程式一般都包含兩個 class 檔案，乙個是 midlet,乙個是displayable 一般我都是把遊戲的主要 放在 displayable 這個類裡面。這個類是基於事件驅動的程式...
J2me遊戲中關於遊戲計分顯示
銷毀普通坦克記10分，打死發射子彈坦克記20分，打死快速移動坦克記30分，本次遊戲一共有15個敵人坦克，所以遊戲的總分數為 5 10 20 30 300,當分數為300時遊戲結束。遇到的問題 如何記錄分別打死不同型別的坦克記不同的分數，一開始我使用玩家坦克的子彈碰撞檢測是否碰到了敵人坦克，並且分別實...