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