【導讀】全新的手機游戲領(lǐng)域已逐漸聚焦了眾多軟件開發(fā)商的目光，游戲。開發(fā)者和游戲玩家將共同面臨這個振奮人心的游戲新境界。前已經(jīng)成為移動通訊設備的主流開發(fā)平臺?；贘2ME平臺能夠方便地利用各種。Java技術(shù)在手機上實現(xiàn)許多復雜的功能。逼真，用普通的臺式機的處理方法顯然是不行的。手機系統(tǒng)的整體性能，是游戲開發(fā)中需要解決的關(guān)鍵問題。本文的主要工作集中在:. 設計并實現(xiàn)了一款A-RPG手機游戲—楓際神話。法，實現(xiàn)對地圖模塊的優(yōu)化處理，使背景圖像形象逼真，提高了手機游戲的質(zhì)量。量和開發(fā)的效率。

　　

【正文】 的這么多。 這樣，也就是使我們改進了我們的方法，就是把顯示的區(qū)域直接畫到屏幕上。但是再看看這些區(qū)域，我們會發(fā)現(xiàn)一個問題。就是說不論怎樣更新，我們能看見的地方最多就比我們的屏幕大一個 Tile 的寬度！反 過來說，就是我們只需要比屏幕大一個 Tile 的圖片就能在上面展示我們所有的地圖場景了。但問題是怎樣做才能更省事呢？ 再來看看下面圖 44： 中山大學南方學院 2020屆本科生畢業(yè)設計 22 圖 44 卡馬克算法原理圖 到 2的情況的時候你會怎樣來更新呢 ？！ 整張 buffer重新畫一次？那樣做在 buffer上作畫的次數(shù)還是太多了。其實從上面我們可以看出，當我們的地圖從 1 移動到2 的情況時，我們的屏幕顯示的地圖是 B~F 這一段，可是我們預留下的 A 部分卻沒有用了，所以我們現(xiàn)在要把這個部分利用起來。把將要更新的 G 部分畫到 A去，在畫到屏幕上的時候，把 A 這個部分放到我們的屏幕 右邊。那這個就是我們這種算法的思想。在這里我們自己把他區(qū)分為更新區(qū)域和不更新的區(qū)域，把沒有看見的區(qū)域更新為即將展示的區(qū)域 ，過程參看圖 45 和圖 46。 圖 45 卡馬克算法原理圖 中山大學南方學院 2020屆本科生畢業(yè)設計 23 圖 46 卡馬克算法原理圖 圖 47 卡馬克算法原理圖 在初始化之后，我們的 buffer 雖然只顯示了屏幕大小，但是實際上是比屏幕大的，沒有顯示出來的部分就是我們移動后將要顯示的部分。我們紀錄屏幕位置的變量view_x,view_y 加上屏幕寬度 src_width 大于我們的 buffer_x+buffer_width 的時候，我們左邊就會有一個 tile_w 寬度的部分顯示不了，就把這部分更新為即將顯示的部分并把他畫到右邊 ，詳見圖 47。 這就是卡馬克算法的主要思想，這樣可以很大節(jié)約內(nèi)存開銷，繪制時間也充裕。此算法在本游戲中的具體做法我們再后面來詳細解釋。 優(yōu)化程序設計 J2ME 程序的優(yōu)化，一般來說與大多數(shù) JAVA 程序的優(yōu)化方式是相同的，但是由于支持 J2ME 的設備的限制，需要做出特別的優(yōu)化。程序員的經(jīng)典法則告訴我們：中山大學南方學院 2020屆本科生畢業(yè)設計 24 程序員往往用 80%的時間去運行 20%的代碼。因此，與其努力提高所有代碼的效率，不如找出代碼中 的瓶頸部分，使之更高效，這樣會得到更高的效益。 所謂優(yōu)化就是優(yōu)化程序的性能和執(zhí)行效率。所以程序的性能，主要包括： 1. 運算的性能，那一個算法的執(zhí)行性能最好。 2. 內(nèi)存的分配，程序需要分配多少內(nèi)存，運行時的效率和性能最高。 3. 啟動的時間，程序啟動需要多少時間。 4. 程序的大小，程序占據(jù)多少的存儲空間。 對象的生成和大小調(diào)整 充分利用 J2ME 提供的庫函數(shù)優(yōu)化程序，對 J2ME 程序的性能是非常重要的，關(guān)鍵點如下： 1. 盡可能地使用靜態(tài)變量。如 ： static World w = new World()。 2. 不要對已生成的對象作過多的改變。 對于一些類（如 String 類）來講，另可重新生成一個新的對象實例二步因該修改已經(jīng)生成的對象。 3. 生成對象時，要分配給它合理的時間和大小。 J2ME 中的很多類都有它的默認的空間分配大小。對于 StringBuffer 類來講，默認的分配空間大小是 16 個字符。如果在程序中使用 StringBuffer 的空間大小不是 16 個字符，那么就必須進行正確的初始化。 4. 避免生成不常使用或聲明周期短的對象或變量。 對于這種情況，應該 定一個對象緩沖池。因為管理一個對象緩沖池的“開銷”要比平繁地生成和回收對象的“開銷”小得多。 5. 只在對象作用范圍內(nèi)進行初始化。 JAVA 允許在代碼的任何地方定義和初始化對象。這樣就可以只在對象作用的范圍內(nèi)進行初始化。從而節(jié)約系統(tǒng)的開銷。 優(yōu)化內(nèi)存的使用 內(nèi)存優(yōu)化主要是為了防止內(nèi)存溢出導致程序崩潰，內(nèi)存優(yōu)化的主要目的是減小程序運行時的內(nèi)存。內(nèi)存優(yōu)化主要包括：代碼優(yōu)化和圖片優(yōu)化。 1. 代碼優(yōu)化 在游戲中經(jīng)常有不同場景的切換，如從游戲邏輯退到主菜單邏輯，對游戲邏輯對象的態(tài)度很多人 會選擇忘記等待垃圾回收器進行垃圾回收。實際上垃圾回收器并非是實時的。從某種角度上講在 J2ME 上所有的垃圾必須由手工釋放，因為除了單類型外所有對象都必須顯示置空。 2. 程序用到的基本類型的優(yōu)化 對于程序中用到的基本類型來說，盡量減小類型所占用的內(nèi)存，比如說 中山大學南方學院 2020屆本科生畢業(yè)設計 25 能用 byte 的就不用 int,能用 char 的地方，就不要用 int。 3. 圖片優(yōu)化 J2ME 的內(nèi)內(nèi)存殺手無疑非圖片莫屬，一張 3KB 的 PNG 圖片可以占用 20多 KB 的內(nèi)存。所以防止內(nèi)存溢出最直接的辦法就是從圖片入手 : （ 1） 圖片壓縮。這個方法是 最有效果，用 Photoshop 把 PNG 圖片存儲為 8 位色，本游戲 PNG 圖片是 16 位色。再使用 PngMate 壓縮圖片。 （ 2） 圖片合并。假如有多張規(guī)格一樣的圖片，可以把它做成一張長條圖片。有兩個原因： 其一 ， 這樣節(jié)省存儲空間和內(nèi)存空間； 其二 ， 10 張圖片需要 10 個 Image對象，進行 10 次 I/O 操作，浪費時間和內(nèi)存。 （ 3） 圖片分拆。對于單張的大圖片，可能單獨加載時，會發(fā)生內(nèi)存溢出，這時可以把圖片拆開分別加載。 45 度角 ARPG 游戲 的 實現(xiàn) 地圖 模塊 的實現(xiàn) 游戲中的效果的最直接表現(xiàn)就 是地圖，由了地圖，游戲的效果就出來了一半了。 因為考慮到游戲地圖很大，繪制整個地圖很耗時，所以我們使用卡馬克算法來繪制地圖，算法的基本思想在上章已說明 下面是地圖的繪制程序，關(guān)于程序的說明已在注釋中說明。 首先 World 類中的 Init()讀入 HotEdit 制作出來的 *.map 二進制文件，然后再根據(jù) *.map 中數(shù)據(jù)的順序依次讀出來。 如代碼 41 代碼 41 從 HotEdit 中讀取數(shù)據(jù) 然后寫出 更 新地圖的方法 ，下面是向右滾動時 ，其他方向滾 動原理 一樣。如代碼 42： 代碼 42 更新地圖 然后是 World 中的 updatamap()方法 。 我們把主角放在屏幕中間， 根據(jù) 主角的移動來更新地圖 。 如代碼 43： public void init(){DataInputStream data = new DataInputStream(.getClass(). getResourceAsStream(/hedy/))。//載入流 ,再讀取流 } private static void moveRight() { //地圖向右滾動 for (int i = 0。 i bufferH / tileH。 i++) //在緩沖繪制出更新的那部分 } 中山大學南方學院 2020屆本科生畢業(yè)設計 26 代碼 43 根據(jù)主角更新地圖 根據(jù)卡馬克算法原理，做 4 個方向 繪制 ，只繪制需要更新的地方，把在緩沖畫出來的 4 部分圖拼畫在屏幕上。 G 類 中的 paint()調(diào)用 World 類里的 drawMap()來實現(xiàn)地圖的繪制 。 效果如圖 47，代碼 44 所示： 圖 47 繪制地圖效果 代碼 44 繪制地圖 游戲動畫 模塊 的實現(xiàn) 除了地圖，給玩家最直觀的就是游戲中主角已經(jīng)敵人走動 和攻擊 的動畫 ，效果如圖 48 所示 。 圖 48 主角攻擊效果 Game_Action 類封裝了所有動畫的繪制。首先我們用 HotEdit 制作動畫，生成 *.ani二進制文件，前面我們已經(jīng)講到過。然后在 Game_Action 類中，將 *.ani 以流的形式讀入，再讀取出來，再繪制。主角 Game_Hero 類和敵人 Game_Enemy 類都是 Game_Action 的子類。 如代碼 45 所示： public static void updatamap() { //根據(jù)主角的移動來更新地圖 if (viewX + bufferX + bufferW) {//向右更新 } } public void drawMap(Graphics gr) { //畫地圖，平滑移動 int mX = mapX + bufferW / tileW。 //繪制屏幕中顯示地圖在緩沖的 X 位置 int mX = i px ? mapX + i + bufferH / tileH px : mapX + i px。//緩沖中的地圖 X位置更新。 } } 中山大學南方學院 2020屆本科生畢業(yè)設計 27 代碼 45 讀取并繪制動畫 游戲 碰撞檢測 模塊 的實現(xiàn) 游戲中很重要的一個地方式碰撞檢測，包括主角與地圖的碰撞判斷，主角與NPC 的碰撞，以及主角與任務觸發(fā)點的碰撞。可以歸納為兩類判斷，矩形碰撞和主角與地圖碰撞。 首先是 主角與 NPC 的矩形碰撞。 比如說，主角與 NPC 碰撞后對話，與任務觸發(fā)點碰撞。這些都是矩形碰撞來判斷。 效果如圖 49，代碼 46： 圖 49 與 NPC 碰撞效果 代碼 46 判斷是否與 NPC 碰撞 矩形碰撞是計算矩形大小 。都是使用到 GameCanvs 類中的 矩形碰撞方法。此方法是 用極限思想來判斷的，把兩個矩形不碰撞的結(jié)果取反。 如代碼 47: 代碼 47 取反 下面 介紹 主角與地圖碰撞的判斷。 我們在 Game_Canvas 類中用 boolean public class Game_Action{ loadAnimation(String Dpng, String Dani){ //讀入動畫流，讀出數(shù)據(jù) } } public boolean currentAnimation(byte Num){ //用來控制當前動畫 } public static boolean colliding(int aX, int aY, int aW, int aH, int bX,int bY, int bW, int bH) {//結(jié)果取反 } void GameLoop() { if (colliding(npcaX 4, npcaY + 20, , )) { //是否主角和NPC 碰撞 } } 中山大學南方學院 2020屆本科生畢業(yè)設計 28 unWalkableTiles(int ri, int le)來存儲地圖中不 可通過的地圖塊索引 。 如代碼 48 所示： 代碼 48 設置 tile 然后在 boolean unwalkable(int ri, int le, int x, int y)中判斷主角下一步是否 可以通過。 如代碼 49 所示： 代碼 49 判斷是否可以通過 在 Game_Canvas 類中的 heroAction()方法 中判斷 是否可以通過，如果下一步是可以通過的，坐標才允許改變。 如代碼 410 所示： 代碼 410 坐標改變 鍵控 模塊的 實現(xiàn) 在游戲中控制主角的動作都需要處理按鍵，其余敵人的動作是依賴線程循環(huán)的 。比如在 Game_Canvas 類里 ，如代碼 411： 代碼 411 設置線程 這里我做了用自定義鍵值來存設備的鍵。 首先在 Constance 接口中，把設備的每一個鍵值都用 一個 Int 按位來存儲。 如代碼 412： public static boolean unwalkable(int ri, int le, int x, int y) {//下一步將走的長度是否整除地圖塊 if (!(ri, le + i)) {//判斷在下一步長度中是否存在不可通過的地圖塊 } } public void heroAction() { if (isKeyHeld()) { //是否一直按數(shù)字鍵 6 向右走 (1)。 //設置主角當前動畫為向右走動畫 unwalkable(( + heroW) / tileW, ( + 16) / tileH)) { //主角下一步 } } case GameState_GameStory: //游戲故事背景 plashimg = null。 //釋放 LOGO 對象 if (isKeyPressed()) { //按數(shù)字鍵 8 向上移動 } static boolean unWalkableTiles(int ri, int le) { //地圖中不可能通過的 tile} 中山大學南方學院 2020屆本科生畢業(yè)設計 29 代碼 412 存儲鍵值 然后我們在 K 類里，將 Constance 里的鍵值轉(zhuǎn)換為自定義鍵。 如代碼 413： 代碼 413 轉(zhuǎn)換自定義鍵 最后我們在 G 類里，寫了 static void keyPressed(int code){}和 static void keyHeld(int code){}兩個方法。 如代碼 414： 代碼 414 傳入鍵值 這樣我們就可以處理 游戲中 一直按 鍵和按下鍵。 主角 模塊 的實現(xiàn) public interface Constance { //將 Canvas 的鍵值賦值給自定義的健值常量 public final static int KEY_CODE_NUM0 = 。 //自定義的健值常量進行移位 每個自定義的健值常量用每個 int 中的 0~21bit 表示 public final static int C_KEY_NUM0 = (10)。} public int getKeyMask(int keyCode) { switch (keyCode) { case KEY_CODE_NUM0: return C_KEY_NUM0。 } public void keyPress