【文章內(nèi)容簡介】 的線程中。敵方子彈僅需要掃描用戶坦克，而用戶坦克需要在每一步掃描所有的敵方坦克。這需要對所有的對象有較好的控制。另外，子彈在運行過程中也需要實時掃描是否 碰撞到了相關障礙物或屏幕邊界。如此過多的線程同時在本來效率就不高的 KVM 虛擬機上運行，也許會導致程序的緩慢。 5. 雙方的坦克在前進時也需要考慮到是否碰撞到相關物體或對方坦克，以免重疊運行，造成許多物理上不可能的情況，缺乏真實感。每一次刷新頁面、每前進一步都需要將所有的周圍環(huán)境都進行掃描。 6. 游戲的結束、開始、動態(tài)信息畫面作為構成一個完美程序都是必不可少的重要部分。良好的用戶界面更是吸引用戶的硬指標，相關的美術構圖也需要有一定的考慮。 7. 游戲的地圖不可能通過繪圖來解決。否則，不僅難于控制和處理 過多的元素，也會因過多的大型圖片而不能限制程序的大小，失去手機上程序的原則和Java 的優(yōu)勢。同時，地圖關卡不宜保存在手機有限的內(nèi)存中，而最好采取外部文件的讀入讀出方法。 8. 用戶運行游戲時需要有分數(shù)記錄的可能。如何采用合理的記分標準，需要進行適當?shù)脑O計。記錄分數(shù)的存儲方式也需要有較好的解決方案。手機中由于處理器和內(nèi)存空間、存儲空間都十分有限，其數(shù)據(jù)庫系統(tǒng)與普通 PC大相徑庭。其數(shù)據(jù)庫結構較為簡單，被稱之為 RMS 系統(tǒng)。 9. Java 是基于虛擬機的半解釋型編譯系統(tǒng)，其執(zhí)行效率較 C++等完全編譯后的程序會低 很多，程序如果不進行精簡和優(yōu)化，將可能導致運行的不流暢。除開發(fā)過程中對結構上的控制、變量的使用、算法的優(yōu)化等優(yōu)化外，還可以使用混淆器 (Obfuscator)進行程序打包后的優(yōu)化。 以上相關技術細節(jié)和整體流程將分別在以下小節(jié)闡述。 程序流程 MIDlet suite 是 MIDP 應用程序的最小單位， JAM 負責將手機內(nèi)的 MIDlet suite 以圖形化的方式呈現(xiàn)，讓用戶能夠選取欲執(zhí)行的 MIDlet suite，一旦選取了某個 MIDlet suite，操作系統(tǒng)就會激活 KVM 執(zhí)行里面的 MIDlet。 MIDlet 及相關的支持類組成了 MIDP 應用程序的實際內(nèi)容。 每個 MIDlet 都必須繼承 這個抽象類。在 MIDP 規(guī)格中定義了 MIDlet 的生命周期，以及可以存在的三種狀態(tài)，包括Paused、 Active 以及 Destroyed，每一個 MIDlet 在任何時刻只可能處于其中的一個狀態(tài)。這三種狀態(tài)的轉換關系如圖所示： 本程序采用面向對象的設計模式，對游戲中的所有物體賦予對象的概念和屬性。運行程序后允許用戶選擇執(zhí)行選項菜單，在開始游戲后將先從外部文件載入地 圖文件，對背景的所有物體進行繪圖。在主程序運行的線程中，畫面刷新將以一定的頻率采用雙緩沖技術對屏幕重繪，實時反映整個游戲的進行狀態(tài)。用戶控制的坦克運行在主線程中，隨屏幕刷新的頻率而步進。敵方坦克將在游戲開始時逐漸新增線程，每增加一個敵方對象就新增加一條線程，一旦線程數(shù)滿到最大值（本程序暫設置為 6），就不允許敵人再繼續(xù)出現(xiàn)。用戶坦克自誕生之時起將擁有一發(fā)子彈，子彈雖然開在單獨的線程中，但運行結束后（比如撞到相關物體或敵方坦克時）并不結束子彈對象，只是將其線程終止。用戶再次發(fā)射子彈時只是將終止的線程再次激活。在 屏幕重繪的主程序中，將在每次的循環(huán)中判斷若干事件。如：用戶坦克的生命是否已完全用盡，敵方坦克數(shù)是否已經(jīng)為零，屏幕上的消減狀態(tài) (Destroyed) 停止狀態(tài) (Paused) 運行狀態(tài) (Active) StartApp() DestroyApp() 呼叫 MIDlet的構造函數(shù) DestroyApp() PauseApp() 圖 31 MIDlet 的流程 坦克數(shù)量是否少于仍剩下的坦克數(shù)量等。以便程序進入相關的分支執(zhí)行相關的反應代碼，結束游戲或統(tǒng)計分數(shù)等。主程序流程如圖 32所示： 程序為需要完成獨立功能的需顯示的模塊設置了單獨的類。TankMain 類是繼承自 MIDlet 的控制主程序啟動的首先被載入系統(tǒng)的部分。載入程序后首先啟動的是程序介紹的信息畫面。閃過后載入StartChoice 類，為用戶提供可選擇的選項。在選擇開始后，將運行BattleCanvas 類中的總流程控制。它決定了游戲何時該結束，何時分配敵人數(shù)量， GameOver 字樣的閃現(xiàn)規(guī)則，地圖的繪制及整個游戲的調(diào)度。 圖 33是程序中類之間的 UML 分析圖。敵方坦克與用戶坦克的相關功能和具體行為分別定義在 EnemySprite 和 UserSprite 類中，它們都繼承自 TankSprite圖 33 與主程序相關的類的 UML 視圖 Logo 畫面 選項畫面 主程序 屏幕繪圖 本關記分統(tǒng)計 顯示GameOver 顯示歷史記分表 About 開始 敵方需要出 坦克時，生成坦克 初始化參數(shù) 死亡時 符合結束條件時 圖 32 本程序的主流程圖 公共類，以簡化程序的代碼、理清結構。 在每關的結束或死亡后都將載入 ScoreScreen 類，統(tǒng)計當前的分數(shù)。如果已死亡或完成所有的關數(shù)，程序將用戶所得的分數(shù)記載到 RMS 數(shù)據(jù)庫中，進行永久性保存。載入過程中將 對所得分數(shù)與以往歷史比較，放置到合適的位置中，形成排序。 繪圖與 新增的 GameCanvas 包 提供低級繪制的 Canvas 類 為了能有程序開發(fā)人員控制接口的外觀和行為，需要使用大量的初級用戶接口類，尤其在游戲程序中，幾乎完全依賴的就是 Canvas 抽象類進行繪圖。從程序開發(fā)的觀點看， Canvas 類可與高級 Screen 類交互，程序可在需要時在 Canvas中摻入高級類的組件。 Canvas 提供了鍵盤事件、指點桿事件（如果設備支持），并定義了允許將鍵盤按鍵映射為游戲控制鍵 的函數(shù) 。鍵盤事件由鍵代碼指定，但這樣控制游戲會導致缺乏通用性，并不是每個設備的鍵盤布局都適合游戲的操作。應當將鍵代碼轉換為游戲鍵的代碼，以便硬件開發(fā)商能定義他們自己的游戲鍵布局。本程序中，操縱用戶坦克運行的按鍵都定義為游戲控制鍵，這樣便能適應所有的機器。 Graphics 類 Graphics 類提供了簡單的 2D 繪圖功能。它具有 24 位深度色彩的繪制能力，以三原色分別各占一個字節(jié)表示其顏色。程序只能在 paint()函數(shù)中使用Graphics 繪制， GameCanvas 可調(diào)用 getGraphics()函數(shù)直接繪制在緩沖區(qū)上，可以在任何時間請求傳輸?shù)角芭_。其對象會被傳給 Canvas 的 paint()函數(shù)，以便最終顯示。 PNG 格式 PNG(Portable Network Graphics)格式是 MIDlet 唯一支持的圖象格式， PNG具體格式由 PNG Specification,Version 定義的。 PNG格式提供透明背景的圖象，這對繪制游戲畫面和被操縱主角極有幫助。坦克之間或與障礙物碰撞時就不會因為背景有特定的顏色，顯示出的效果像貼上的圖片而缺乏真實感，物體之間輕微重疊時最 上層圖片也不會覆蓋超過其有效象素外的部分。 PNG 格式圖片中包含許多定義其圖片特性的冗余部分 (Chunks)。這些代碼包含在每一個單獨的 png 格式圖象中，然而如果將多個 png 圖象合并在一張幅面稍大一些的整圖中，多個 chunks 就可以得到精簡，圖片的大小可以得到控制。使用 Image 類中的 createImage 函數(shù)可從整圖中分割出所需要的元素。在 Game 包中的 TiledLayer 和 Sprite 類都整合了這樣的功能。本程序中的地圖元素都集成在一張 圖片中，實現(xiàn)了方便的管理和程序體積的精簡。 Game 包中的新功能 MIDP 自 以后新增了 Game 包，為游戲的開發(fā)帶來了極大的便利。地圖繪制、主角的動態(tài)顯示、按鍵的檢測、圖層的控制等游戲專屬的特性都得到了在移動設備上最大的發(fā)揮。 LayerManager（以下簡稱 LM）提供控制整體畫面層的控制。它包括了一系列自動獲取了代號和位置的層，簡化了各層加入游戲畫面的過程，提供了自動排序和繪制的能力。 LM 存儲了一個層的列表，新的層可以用 append 函數(shù)附加、刪除和插入。層的序號相當于坐標的 Z軸， 0層表示最接近用戶視覺，層數(shù) 越高，離用戶越遠。層號總是連續(xù)的，即使有中間的層被移除，其他層的序號會作相應的調(diào)整以保持整體的完整性。 LM 中的 View Window 控制著與 LM 相對坐標的可視區(qū)域。改變 View Window 的位置可以制造出滾動屏幕的效果。 本程序中所有的地圖、坦克都采用 LM控制，敵方坦克的生成由附加一個EnemySprite 對象得到。唯有界面右側的計分欄由 Graphics 類繪制。 Sprite 類是繼承自 Layer 的用于存儲多楨的基本可視元素。不同的 frame 可交相顯示，構成動態(tài)的效果。圖片可翻轉、顛倒、由一個主角圖片就可以 方便的得到所有方向的顯示狀態(tài)，相比原先只能使用 Canvas 繪圖，需要將所有方向的主角圖象都繪制在 png 圖象中簡化了許多。 Sprite 也可以從整合的圖象中讀圖，讀圖時將把大圖分解為若干等寬等高的小圖。每個小圖按照其排列順序有相應的序號，在程序中調(diào)用其序號，就可以繪制出相應的圖片。本程序中的雙方坦克、子彈都由 Sprite 繼承得到。在有些情況下，控制主角的翻轉，尤其是多幅圖片配合顯示的過程，如果將多圖的共享定位點設置在通常的左上角，將很不容易控制，因為許多翻轉都是以其他點為參考電的（比如，中心點）。由此，引入?yún)⒖?點的概念。參考點由 defineReferencePixel 函數(shù)確定 未翻轉圖片狀態(tài)時的坐標。默認是 (0,0)點，如果需要，可將參考點設置在畫面邊界之外。本程序中的坦克的參考點定義在圖片正中，以便簡便的實現(xiàn)轉向等功能。子彈的參考點設置在子彈底部的中心，因為子彈一出炮筒的時候緊挨著坦克的象素就是其底部中心。 TiledLayer 是有一組圖象格元素 (grid of cells)組成的整塊虛擬圖象。該類使不需要高分辨率的圖象就能創(chuàng)建大幅圖面成為可能。這項技術通常應用在2D游戲平臺的滾動背景的繪圖。一塊整圖可被分割成等 大小的圖象格，每塊格有其對應的序號，按照行列遞增。多塊格可由大塊同時替換組合而模擬動態(tài)的背景，這不需要逐塊替換所有的靜態(tài)圖象格而顯得非常方便。 本程序中的地圖即為游戲背景。每塊障礙物都有其響應的代號，其中，用戶需保護的總部因為體積稍大，使用了四塊圖象格顯示。地圖背景分為 20*22 個圖象格，每個格使用一個字節(jié)表示其中的障礙物，圖象文件存儲在外部文件中，以16進制的整數(shù)串表示，因此每個地圖的大小為固定的 440 字節(jié)。如果整塊地圖均由繪圖產(chǎn)生，將導致體積迅速增加，且對坦克與障礙物的碰撞也難以檢測。 J2ME中并沒有 J2SE 中的 File 類，獲取外部文件的手段很有限，僅僅在 Class 類中提供了一個 getResourceAsStream 函數(shù)，將外部文件獲取為輸入流，再由InputStream 的繼承類讀出。 有關繪圖的一些技術 在沒有 前，進行游戲繪圖一般需要手動編程使用雙緩沖。需要在paint()方法內(nèi)所想要畫的圖形畫在一張預先準備好的背景，等所有繪圖操作都完成后再將背景的數(shù)據(jù)拷貝到實際的屏幕上。 Image 類提供了一個建立背景的靜態(tài)方法 createImage(int width, int height)，再利用 getGraphics()方法取得屬于這個背景的 Graphics 對象，所進行的繪圖操作都會作用在背景上，等到全部的繪圖操作完成后，再調(diào)用 drawImage()方法將背景的數(shù)據(jù)復制到實際顯示的屏幕上。 這樣的技術在繪制動畫時特別有用。繪制動畫時經(jīng)常需要不斷地更新畫面，而更新畫面的操作就是先將屏幕以 fillRect()的方式清除，再將下一張圖片畫在屏幕上，然而反復的清除及重繪會造成屏幕的閃爍現(xiàn)象（ flicker），因此使用雙重緩沖的好處就是在背景進行這個清除及重繪的操作，再將完成的繪圖拷貝到屏幕上，由于用戶看不到清除的操作，因此就不會出現(xiàn)閃爍的現(xiàn)象了。不過在某些 MIDP 的實現(xiàn)上已經(jīng)加上了雙重緩沖的支持，因此在處理前應先利用 Canvas 類的 isDoubleBuffer()方法來判斷。 坦克的控制和敵方的智能運行 GameCanvas 中提供了與以往 不同的鍵盤采樣功能。 Canvas 類中采取響應鍵盤事件的方法，每次執(zhí)行周期時會讀取 keyPressed 函數(shù)中需執(zhí)行的代碼。這樣的機制并不適合某些游戲場合。在某些不支持 keyRepeat 功能的設備上，反復執(zhí)行的 按鍵，比如發(fā)射子彈，將不能因為長時間按壓而自動重復，這樣就需要用戶高頻率的手動擊鍵，這在操縱空間非常有限的移動設備上是非常困難的。同時，事件的執(zhí)行周期也并不一定適合游戲的場合，也許需要更高頻率執(zhí)行的按鍵卻只能在指定的周期內(nèi)規(guī)律的響應。對此，針對游戲的開發(fā)，Game 包提供的鍵盤狀態(tài)功能將顯得十分有效。 GameCa