【文章內(nèi)容簡介】 號會(huì)作相應(yīng)的調(diào)整以保持整體的完整性。LM中的View Window控制著與LM相對坐標(biāo)的可視區(qū)域。改變View Window的位置可以制造出滾動(dòng)屏幕的效果。本程序中所有的地圖、坦克都采用LM控制，敵方坦克的生成由附加一個(gè)EnemySprite對象得到。唯有界面右側(cè)的計(jì)分欄由Graphics類繪制。Sprite類是繼承自Layer的用于存儲(chǔ)多楨的基本可視元素。不同的frame可交相顯示，構(gòu)成動(dòng)態(tài)的效果。圖片可翻轉(zhuǎn)、顛倒、由一個(gè)主角圖片就可以方便的得到所有方向的顯示狀態(tài)，相比原先只能使用Canvas繪圖，需要將所有方向的主角圖象都繪制在png圖象中簡化了許多。Sprite也可以從整合的圖象中讀圖，讀圖時(shí)將把大圖分解為若干等寬等高的小圖。每個(gè)小圖按照其排列順序有相應(yīng)的序號，在程序中調(diào)用其序號，就可以繪制出相應(yīng)的圖片。本程序中的雙方坦克、子彈都由Sprite繼承得到。在有些情況下，控制主角的翻轉(zhuǎn)，尤其是多幅圖片配合顯示的過程，如果將多圖的共享定位點(diǎn)設(shè)置在通常的左上角，將很不容易控制，因?yàn)樵S多翻轉(zhuǎn)都是以其他點(diǎn)為參考電的（比如，中心點(diǎn)）。由此，引入?yún)⒖键c(diǎn)的概念。參考點(diǎn)由defineReferencePixel函數(shù)確定未翻轉(zhuǎn)圖片狀態(tài)時(shí)的坐標(biāo)。默認(rèn)是(0,0)點(diǎn)，如果需要，可將參考點(diǎn)設(shè)置在畫面邊界之外。本程序中的坦克的參考點(diǎ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)背景的繪圖。一塊整圖可被分割成等大小的圖象格，每塊格有其對應(yīng)的序號，按照行列遞增。多塊格可由大塊同時(shí)替換組合而模擬動(dòng)態(tài)的背景，這不需要逐塊替換所有的靜態(tài)圖象格而顯得非常方便。本程序中的地圖即為游戲背景。每塊障礙物都有其響應(yīng)的代號，其中，用戶需保護(hù)的總部因?yàn)轶w積稍大，使用了四塊圖象格顯示。地圖背景分為20*22個(gè)圖象格，每個(gè)格使用一個(gè)字節(jié)表示其中的障礙物，圖象文件存儲(chǔ)在外部文件中，以16進(jìn)制的整數(shù)串表示，因此每個(gè)地圖的大小為固定的440字節(jié)。如果整塊地圖均由繪圖產(chǎn)生，將導(dǎo)致體積迅速增加，且對坦克與障礙物的碰撞也難以檢測。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對象，所進(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)行 。Canvas類中采取響應(yīng)鍵盤事件的方法，每次執(zhí)行周期時(shí)會(huì)讀取keyPressed函數(shù)中需執(zhí)行的代碼。這樣的機(jī)制并不適合某些游戲場合。在某些不支持keyRepeat功能的設(shè)備上，反復(fù)執(zhí)行的按鍵，比如發(fā)射子彈，將不能因?yàn)殚L時(shí)間按壓而自動(dòng)重復(fù)，這樣就需要用戶高頻率的手動(dòng)擊鍵，這在操縱空間非常有限的移動(dòng)設(shè)備上是非常困難的。同時(shí)，事件的執(zhí)行周期也并不一定適合游戲的場合，也許需要更高頻率執(zhí)行的按鍵卻只能在指定的周期內(nèi)規(guī)律的響應(yīng)。對此，針對游戲的開發(fā)，Game包提供的鍵盤狀態(tài)功能將顯得十分有效。 GameCanvas提供getKeyStates函數(shù)可獲取當(dāng)前鍵盤上的信息。將以位的形式返回鍵盤上所有鍵的按與釋放的狀態(tài)，當(dāng)bit為1時(shí)，鍵就是被按下的狀態(tài)，為0時(shí)則為釋放狀態(tài)。只需要此一個(gè)函數(shù)的返回值就可以返回所有鍵的狀態(tài)。這保證了快速的按鍵和釋放也會(huì)被循環(huán)所捕捉。同時(shí)，這樣的機(jī)制也可檢測到幾個(gè)鍵同時(shí)按下的狀態(tài)，從而提供斜向運(yùn)行等相應(yīng)功能。敵方按照規(guī)則不能和用戶坦克重合，則它每行走一步就需要把用戶坦克掃描一次，判斷其是否碰撞到了用戶的坦克。Sprite類中提供了collidesWith函數(shù)，用于判斷是否與某個(gè)TiledLayer、Sprite、Image的對象有圖象上的重合（即游戲中的碰撞）。然而不能僅僅將用戶坦克作為其Sprite參數(shù)傳遞給敵人的類進(jìn)行判斷。因?yàn)槿绻l(fā)生碰撞，collidesWith成立，則兩輛坦克已經(jīng)發(fā)生了圖象重合，違反了規(guī)則，甚至若再進(jìn)行collidesWith判斷的話，其結(jié)果將永為真。為了提前預(yù)知碰撞，可以將所有坦克的碰撞范圍設(shè)定為一個(gè)比坦克圖片稍大一些的矩形，此矩形僅在坦克前方比坦克圖形多出一個(gè)象素。在多出的11個(gè)象素中，按照每個(gè)象素依次檢查此象素是否于外界發(fā)生碰撞，如果不是按照象素檢查，則當(dāng)坦克與障礙物錯(cuò)位并同時(shí)與兩種物體接觸時(shí)將有可能忽略檢測其中的一樣物體。這樣，就可以提前一步判斷。如果發(fā)生碰撞，則坦克應(yīng)當(dāng)選擇掉轉(zhuǎn)方向，此時(shí)，兩輛碰撞的坦克又因?yàn)槠渚匦螀^(qū)域不重合而不符合collidesWith的條件，就可以繼續(xù)正常運(yùn)行了。敵方坦克由于需要具有一定的智能性，以便對玩家攻擊，使之具有一定的可玩性。敵人可以自動(dòng)行走，但是應(yīng)當(dāng)在以下適當(dāng)?shù)那闆r下轉(zhuǎn)向：首先是是否超出界面的邊界，其次是是否與地圖障礙物發(fā)生了碰撞，再次是是否與用戶坦克發(fā)生了碰撞。需要指出的是，當(dāng)發(fā)生阻礙不能在不變方向的情況下繼續(xù)行走時(shí)，并不一定立即需要采取轉(zhuǎn)向的對策。如果一定發(fā)生轉(zhuǎn)向，試想，當(dāng)敵方碰到玩家時(shí)，如果它立即轉(zhuǎn)向，將不會(huì)對玩家發(fā)射射向他的子彈，就不構(gòu)成任何威脅，當(dāng)然，也不能永遠(yuǎn)不轉(zhuǎn)向。本程序設(shè)置為：當(dāng)碰撞到障礙物或邊界時(shí)立即轉(zhuǎn)向，但碰到玩家坦克時(shí)需要有一個(gè)等待的時(shí)間，這個(gè)時(shí)間由碰撞前隨機(jī)取得的在某方向上的持續(xù)行走步數(shù)決定，當(dāng)發(fā)生坦克間碰撞時(shí)，此隨機(jī)數(shù)將在下一次循環(huán)前減少為原來的2/3，這樣就實(shí)現(xiàn)了加快轉(zhuǎn)向的時(shí)間，避免死鎖在一個(gè)方向上靜止的停留過長的時(shí)間。另外，坦克的發(fā)炮間隔和轉(zhuǎn)后的具體方向都由隨機(jī)數(shù)決定。坦克之間由以上道理也不會(huì)發(fā)生重疊，但當(dāng)某坦克正從上方生成而正巧有另一輛阻礙在其生成點(diǎn)處，這將導(dǎo)致不可避免的重合。這是允許的，但需要對他們標(biāo)注狀態(tài)，即當(dāng)坦克剛出現(xiàn)時(shí)暫時(shí)允許重合，一旦在某個(gè)時(shí)間他們脫離了重合狀態(tài)，就不能在允許重合，如果不設(shè)置這樣的判斷，剛出現(xiàn)的坦克將會(huì)因?yàn)槭艿阶枞肋h(yuǎn)不能前進(jìn)，坦克將混成一團(tuán)。本程序中并未使用過多復(fù)雜的人工智能算法，如有時(shí)間，將可能再此方面加以完善。 子彈的運(yùn)行和控制每一個(gè)坦克都有他自己的一顆子彈，這顆子彈在任何一輛坦克被構(gòu)造時(shí)就一直存在，直至此坦克生命的結(jié)束，子彈的再次只是將屏幕上暫時(shí)掩蓋的圖象重新置于坦克炮筒才恰當(dāng)位置，并使其顯示出來，這與現(xiàn)實(shí)中每個(gè)子彈都是單獨(dú)的個(gè)體有所不同。子彈所需要完成的任務(wù)有：它是一個(gè)繼承了Runnable虛類的可運(yùn)行單獨(dú)線程的對象。在其出現(xiàn)在屏幕上的運(yùn)行周期中，每一步都需要循環(huán)檢測以下條件：是否與某坦克發(fā)生了碰撞，即擊中了這輛坦克。子彈使用的是象素級的碰撞檢測，因?yàn)樽訌椀膱D片形狀不規(guī)則，如果使用矩形碰撞檢測，將有可能在子彈尚未接觸到物體時(shí)就已返回碰撞的真值。分為兩種情況，如果此子彈來自于敵方，將只檢測玩家坦克，因?yàn)閿撤街g的子彈必須允許可以透明的穿過，以保證不會(huì)在敵人之間發(fā)生子彈的消減。如果來自玩家，則每一步需掃描所有的敵方坦克，檢查是否發(fā)生碰撞，這可能會(huì)花費(fèi)不少的CPU時(shí)間。其次，子彈之間需要檢測是否碰撞。敵人之間顯然，如上已經(jīng)提過，不需要檢測，但敵人與玩家之間應(yīng)當(dāng)可以互相消除子彈，以便在狹窄的路口中仍有存活的機(jī)會(huì)。玩家的子彈需要在每一步檢測所有敵人的子彈的運(yùn)行狀態(tài)。這樣較多的運(yùn)算也將不可避免的耗費(fèi)大量CPU時(shí)間。子彈對不同障礙物將有不同的反映。對磚墻將有能力將其擊毀，使之在畫面上消失；對水泥鋼筋將不能發(fā)生作用，子彈也不能通過；對于河流，坦克不可以通過，但子彈可以；對于草叢，子彈和坦克都可以通過。 RMS數(shù)據(jù)庫系統(tǒng)MIDP為MIDlets提供了一種永久存儲(chǔ)和后來讀出數(shù)據(jù)的數(shù)據(jù)庫解決方案，被稱為Record Managerment System(RMS)，是一種類簡單的基于記錄的數(shù)據(jù)庫。很顯然，手機(jī)上的數(shù)據(jù)庫系統(tǒng)不可能有PC上的強(qiáng)大功能。微小的存儲(chǔ)空間也限制了它們的結(jié)構(gòu)不能過于復(fù)雜。RMS是專門針對移動(dòng)設(shè)備的服務(wù)的。RMS包中包括RecordStore類。在一個(gè)MIDlet suite包里的所有MIDlet都允許創(chuàng)建多個(gè)記錄集，只要它們賦有不同的名稱。當(dāng)MIDlet包從平臺(tái)中被移除后，所有與該包有關(guān)的的記錄集都同時(shí)會(huì)被移除。同一個(gè)包內(nèi)的MIDlets可以直接互相訪問它們的記錄集，不同包內(nèi)也可產(chǎn)生共享，但這需要有包的授權(quán)屬性決定。訪問模式會(huì)在準(zhǔn)備提供共享的RecordStore被建立時(shí)被創(chuàng)建。訪問模式允許私有使用或訪問。RecordStore的API采用了時(shí)間戳的概念，其長整型變量由System的currentTimeMillis()函數(shù)返回決定。Record store 每次被修改后都會(huì)自動(dòng)在其屬性上附加上時(shí)間戳，這為同步化引擎和程序的控制都極為有效。記錄是字節(jié)數(shù)組。開發(fā)者可以利用InputStream的派生類DataInputStream、DataOutputStream以及ByteArrayInputStream、ByteArrayOutputStream將不同種類的數(shù)據(jù)類型打包，以字節(jié)流的形式發(fā)送和接收。區(qū)別記錄的唯一標(biāo)記是他們的ID值，作為記錄集的主鍵。第一項(xiàng)記錄的ID是1，其后的每個(gè)記錄ID遞增。Record是以字節(jié)為基本單位來存放的，所以所有要寫入record的數(shù)據(jù)都必須先將其轉(zhuǎn)為字節(jié)才能寫入，從record所讀出來的數(shù)據(jù)也是字節(jié)，必須將其轉(zhuǎn)換為原先寫入時(shí)的數(shù)據(jù)類型才有意義。然而讀取或?qū)懭氲淖止?jié)數(shù)組都只能代表一個(gè)字段的信息，如果需要讀取或?qū)懭攵鄠€(gè)字段就必須要將數(shù)據(jù)轉(zhuǎn)換成字節(jié)信息，并且提供適當(dāng)?shù)臋C(jī)制來分隔這些信息。主要有兩種方法：1. 標(biāo)記法。將所有要存放的數(shù)據(jù)用字符串表示，但是在字段和字段之間以一個(gè)特殊的符號作為分隔。符號不能和字段內(nèi)的數(shù)據(jù)相同的字符。2．利用輸入/輸出流這一種方法較上一種復(fù)雜，但是較為實(shí)用。方法一中所有的字段只能以字符串的形式存儲(chǔ)，要對這些字段作進(jìn)一步的處理非常麻煩。利用輸入輸出流可以寫入及讀取不同數(shù)據(jù)類型的數(shù)據(jù)，做法是在寫入數(shù)據(jù)時(shí)先將一個(gè)DataOutputStream數(shù)據(jù)流對象串接到一個(gè)ByteArrayOutStream數(shù)據(jù)流對象，然后再依字段的數(shù)據(jù)類型用writeInt()、writeBoolean()等方法寫入，最后把ByteArrayOutputStream內(nèi)的元素?cái)?shù)據(jù)寫入record中。反之若要讀取數(shù)據(jù)，則先要串接一個(gè)DataInputStream對象和ByteArrayInputStream，依字段的數(shù)據(jù)類用readInt()、readBoolean()等方法讀取。 本程序中主要存放在永久區(qū)的內(nèi)容為用戶得到的最高分?jǐn)?shù)的記錄。一共可以存儲(chǔ)10條最高分。每次有新的更高的記錄就會(huì)插入進(jìn)相應(yīng)的位置，將最低一名排擠出記錄。在輸入記錄前，要求用戶在TextField框中寫入他自己的名字。返回的getString可以將名字輸送給字節(jié)流。因?yàn)槊總€(gè)記錄包括用戶名和分?jǐn)?shù)，因此需要使用多字段的方式編入。打印到屏幕上時(shí)，記錄ID號即為排名，因此將顯示三項(xiàng)數(shù)據(jù)。 內(nèi)存使用的最佳化通常在MIDP應(yīng)用程序的手機(jī)執(zhí)行環(huán)境中，所牽涉的內(nèi)存有下列三種：﹡應(yīng)用程序存儲(chǔ)內(nèi)存﹡RecordStore存儲(chǔ)內(nèi)存﹡執(zhí)行時(shí)期內(nèi)存(Java Heap)其中前兩種是持久性的內(nèi)存，關(guān)閉電源后還能保持?jǐn)?shù)據(jù)的正確性，通常這兩種內(nèi)存所能存儲(chǔ)的容量是合并計(jì)算的，這個(gè)上限對每種手機(jī)都不一樣，大部分在一兩百KB內(nèi)。在這樣的情況下需要在不影響原有功能的情況下適當(dāng)?shù)目s減JAR文件的大小，除了可以克服內(nèi)存空間的限制外，也能大幅度縮短下載的時(shí)間（費(fèi)用也降低了），勢必會(huì)有更多的人愿意下載所開發(fā)的程序。其方法有：第一，就是盡量縮短命名的長度。在應(yīng)用程序內(nèi)，對于所建立的類、接口、方法及變量名而言，都需要賦予一個(gè)識別的名稱，所命名的名稱每多一個(gè)字符就會(huì)在類文件內(nèi)多產(chǎn)生一個(gè)字節(jié)，對于一個(gè)較復(fù)雜的應(yīng)用程序而言就會(huì)增加為數(shù)不小的數(shù)據(jù)量。所有這些可以借助混淆器來幫助實(shí)現(xiàn)。第二是減少復(fù)雜的程序結(jié)構(gòu)，為一些共同的行為建立一個(gè)抽象類(Abstract Class) 來表示繼承的子類的共通性。第三是減少圖形數(shù)據(jù)的大小。將PNG格式的小分辨率圖象合并在一張大的高分辨率圖象中，由于減少了chunks，將比合并前的總大小減少許多。 混淆器(Obfuscator)的使用Java 語言并沒有完全編譯成二進(jìn)制可執(zhí)行文件，需要虛擬機(jī)來執(zhí)行。它包括了所有的信息。，從而不能保護(hù)作者的知識成果。目前流行的如decode,JAD等反編譯工具可以以很快的速度生成源文件。如果不加以施行有效的措施，將造成嚴(yán)重的后果。由此引入混淆器的概念?；煜鲗⒋a中的所有變量、函數(shù)、類的名稱變?yōu)楹喍痰挠⑽淖帜复?，如果缺乏相?yīng)的函數(shù)名指示和程序注釋，即使被反編譯，也將難以閱讀。 混淆器的作用不僅僅是保護(hù)代碼，它也有精簡編譯后程序大小的作用。由于以上介紹的減少變量、函數(shù)的命名長度的關(guān)系?；煜螅w積大約能減少25%，這對當(dāng)前費(fèi)用較貴的無線網(wǎng)絡(luò)傳輸是有一定意義的