【正文】 機(jī)器。PNG格式圖片中包含許多定義其圖片特性的冗余部分(Chunks)。它包括了一系列自動(dòng)獲取了代號(hào)和位置的層，簡(jiǎn)化了各層加入游戲畫(huà)面的過(guò)程，提供了自動(dòng)排序和繪制的能力。Sprite類是繼承自Layer的用于存儲(chǔ)多楨的基本可視元素。參考點(diǎn)由defineReferencePixel函數(shù)確定未翻轉(zhuǎn)圖片狀態(tài)時(shí)的坐標(biāo)。多塊格可由大塊同時(shí)替換組合而模擬動(dòng)態(tài)的背景，這不需要逐塊替換所有的靜態(tài)圖象格而顯得非常方便。Image類提供了一個(gè)建立背景的靜態(tài)方法createImage(int width, int height)，再利用getGraphics()方法取得屬于這個(gè)背景的Graphics對(duì)象，所進(jìn)行的繪圖操作都會(huì)作用在背景上，等到全部的繪圖操作完成后，再調(diào)用drawImage()方法將背景的數(shù)據(jù)復(fù)制到實(shí)際顯示的屏幕上。同時(shí)，事件的執(zhí)行周期也并不一定適合游戲的場(chǎng)合，也許需要更高頻率執(zhí)行的按鍵卻只能在指定的周期內(nèi)規(guī)律的響應(yīng)。Sprite類中提供了collidesWith函數(shù)，用于判斷是否與某個(gè)TiledLayer、Sprite、Image的對(duì)象有圖象上的重合（即游戲中的碰撞）。敵人可以自動(dòng)行走，但是應(yīng)當(dāng)在以下適當(dāng)?shù)那闆r下轉(zhuǎn)向：首先是是否超出界面的邊界，其次是是否與地圖障礙物發(fā)生了碰撞，再次是是否與用戶坦克發(fā)生了碰撞。 子彈的運(yùn)行和控制每一個(gè)坦克都有他自己的一顆子彈，這顆子彈在任何一輛坦克被構(gòu)造時(shí)就一直存在，直至此坦克生命的結(jié)束，子彈的再次只是將屏幕上暫時(shí)掩蓋的圖象重新置于坦克炮筒才恰當(dāng)位置，并使其顯示出來(lái)，這與現(xiàn)實(shí)中每個(gè)子彈都是單獨(dú)的個(gè)體有所不同。玩家的子彈需要在每一步檢測(cè)所有敵人的子彈的運(yùn)行狀態(tài)。RMS包中包括RecordStore類。記錄是字節(jié)數(shù)組。符號(hào)不能和字段內(nèi)的數(shù)據(jù)相同的字符。在輸入記錄前，要求用戶在TextField框中寫(xiě)入他自己的名字。所有這些可以借助混淆器來(lái)幫助實(shí)現(xiàn)。如果不加以施行有效的措施，將造成嚴(yán)重的后果。 模擬器的相關(guān)調(diào)試 IDE整合的Wireless Tool Kit提供了許多在運(yùn)行時(shí)監(jiān)視運(yùn)行狀態(tài)的工具。具體算法的代碼實(shí)現(xiàn)和詳細(xì)流程將在下章介紹。在startApp()函數(shù)中，隨即調(diào)用了Displable的setCurrent()函數(shù)將當(dāng)前屏幕設(shè)置為startChoice。繼承了mandListener的類必須擁有mandAction()，以決定對(duì)按鍵采取什么樣的行為。它運(yùn)行在獨(dú)立的線程中，以恒定的頻率刷新畫(huà)面。因此，有必要在其中創(chuàng)立一個(gè)LayerManager的對(duì)象。每個(gè)整數(shù)代表一種障礙物。本程序設(shè)置為6。進(jìn)入下一關(guān)時(shí)，許多變量需要重新被初始化，如地圖的繪制、敵人出現(xiàn)位置的重置、敵人的數(shù)量、玩家坦克的當(dāng)前位置。如果玩家已經(jīng)死亡，就需要使用LayerManager的insert()將gameover字樣插入到最上層，以免被其他物體覆蓋。在每次刷新繪圖頁(yè)面時(shí)，應(yīng)使用GameCanvas的flushGraphics()將屏幕后臺(tái)的緩沖區(qū)內(nèi)的圖象刷新到前臺(tái)來(lái)。為了能提前預(yù)測(cè)碰撞，調(diào)用了defineCollisionRectangle(0,1,11,12)將碰撞矩形向前設(shè)置了一個(gè)象素，具體原理見(jiàn)第二章。當(dāng)開(kāi)炮時(shí)，調(diào)用BulletSprite的setLayerManager()將子彈與layerManager聯(lián)系起來(lái)。在玩家坦克發(fā)射的子彈中，就必須將攻擊對(duì)象設(shè)置為所有的敵人。canPass()檢測(cè)是否有障礙物及是否到邊界。當(dāng)然，在設(shè)置完成后，必須將將檢測(cè)區(qū)域設(shè)置回原先的狀態(tài)，否則敵人在往后自己的檢測(cè)中將發(fā)生錯(cuò)誤。開(kāi)始是否剛出現(xiàn)前進(jìn)Y可否開(kāi)炮開(kāi)炮可否前進(jìn)換向、取隨機(jī)移動(dòng)步數(shù)、隨機(jī)開(kāi)炮倒數(shù)記步數(shù)結(jié)束是否已死亡是否碰撞NYNYNYNN圖48 敵方坦克運(yùn)行流程圖getRandomDirection()以當(dāng)前系統(tǒng)時(shí)間作為種子，調(diào)用了Random類的nextInt()產(chǎn)生一個(gè)隨機(jī)的整數(shù)，此整數(shù)取除4的余數(shù)的絕對(duì)值作為隨機(jī)的方向。這樣就相當(dāng)于允許在某一個(gè)方向運(yùn)行0~3秒鐘的時(shí)間。因?yàn)椴恍枰M(jìn)行預(yù)先檢測(cè)。發(fā)炮后應(yīng)立即重新賦值給隨機(jī)發(fā)炮數(shù)，以便重新倒數(shù)計(jì)算。它標(biāo)識(shí)了該子彈是屬于玩家的，還是敵人的，這樣可以控制子彈在脫離坦克管束后的運(yùn)行狀態(tài)中的行為。 在線程的循環(huán)中while ( (x 155) amp。它們反映了象素級(jí)處理的技巧。如果擊中了某樣物體，那么checkHit自然會(huì)處理，子彈的生命周期結(jié)束，以break退出循環(huán)。只是用戶看不見(jiàn)而已。(score,true)創(chuàng)建一個(gè)名為“score”的數(shù)據(jù)庫(kù)。 圖49 分?jǐn)?shù)統(tǒng)計(jì)畫(huà)面insertRecord()可以將當(dāng)前剛剛得到的最高成績(jī)記錄到數(shù)據(jù)庫(kù)的指定位置，將最后一名排擠出局。時(shí)間將根據(jù)BattleCanvas中的beginTime的差除以1000后取整決定。這是低級(jí)繪圖屏幕與高級(jí)用戶界面相結(jié)合的一個(gè)應(yīng)用。本游戲程序?qū)τ诔跎娲祟I(lǐng)域的畢業(yè)設(shè)計(jì)課題來(lái)說(shuō)，尤其在開(kāi)始初期，感覺(jué)邏輯復(fù)雜，難以控制，因此至今還有一些未能解決的bug。已經(jīng)解決的重要Bug:1. 當(dāng)發(fā)出子彈到達(dá)邊界并同時(shí)還在草叢中時(shí)會(huì)拋出數(shù)組邊界異常。大學(xué)期間做過(guò)銀行取款機(jī)、圖書(shū)館管理程序等簡(jiǎn)單的數(shù)據(jù)庫(kù)管理系統(tǒng)的課程設(shè)計(jì)，思想大致相似，變化范圍有限，沒(méi)有太多自己可發(fā)揮的余地。在設(shè)計(jì)初期，為了畫(huà)出一個(gè)簡(jiǎn)單的圖形，需要花費(fèi)一天的時(shí)間，為了使圖形產(chǎn)生動(dòng)態(tài)效果又會(huì)花費(fèi)幾天的努力。我原以為這樣的速度將無(wú)法完成畢業(yè)設(shè)計(jì)，但當(dāng)掌握了大部分應(yīng)用技巧時(shí)，剩下的游戲思路的設(shè)計(jì)就顯得不是最大的障礙了。然而，回首。為了進(jìn)一步探索深層次的技巧，我花費(fèi)了大量時(shí)間在sun的Java主頁(yè)上，閱讀了幾十篇英文的技巧和代碼樣例。憑著探索新知識(shí)的熱情，我選擇了該設(shè)計(jì)題目。在數(shù)據(jù)庫(kù)、單片機(jī)、各種應(yīng)用軟件和游戲中，我仍覺(jué)得對(duì)游戲的設(shè)計(jì)有極大的熱情。 5. 最好有接寶物的設(shè)置，增強(qiáng)可玩性。但幾乎每一個(gè)計(jì)算機(jī)程序都會(huì)有這樣那樣的不足，尤其是未經(jīng)過(guò)精心維護(hù)的非商業(yè)軟件。效果如圖410，僅停留4秒種，供用戶快速參考后便會(huì)跳入下一關(guān)的起始畫(huà)面。由于ScoreScreen類繼承了Canvas，所以必須有paint()函數(shù)。() ，score=()將分別讀出用戶名和分?jǐn)?shù)，然而前者讀出后并不加以利用，因?yàn)樵诒容^分?jǐn)?shù)的過(guò)程中，并不需要用到用戶名。采用的是手機(jī)專用的一種簡(jiǎn)化的數(shù)據(jù)庫(kù)RMS。如果玩家生命已死亡殆盡，就需要在進(jìn)行以上操作的同時(shí)將玩家坦克的位置放置到屏幕外的部分。如果為真，就繼續(xù)檢測(cè)碰撞上了什么樣的物體。 (y 171))作為循環(huán)的條件可以控制子彈出界的范圍。擊中鋼筋時(shí)，將只產(chǎn)生爆炸效果。 子彈的運(yùn)行和控制 子彈繼承了Runnable，運(yùn)行在獨(dú)立的線程中。如果剛出現(xiàn)，就直接走一步，具體如何行走將在go()函數(shù)中決定，并且此go()與UserSprite中的有所區(qū)別。語(yǔ)句將避免檢測(cè)到自己，永遠(yuǎn)返回真。 return ((())%4)*50。 setEnemyShootCheck()函數(shù)與UserSprite中的一樣，設(shè)置了攻擊的對(duì)象，并且此函數(shù)將繼續(xù)把參數(shù)傳遞給自身的子彈，以便子彈可以識(shí)別攻擊對(duì)象。事實(shí)上，敵人坦克此時(shí)并沒(méi)有阻礙玩家前進(jìn)。amp。子彈一旦開(kāi)始運(yùn)行，就脫離了當(dāng)前坦克的控制，直到其生命周期終止。因?yàn)樗械恼系K物中只有草不會(huì)阻礙坦克的向前運(yùn)行。在transformDirection[]中定義了坦克四個(gè)方向分別應(yīng)將原始圖片旋轉(zhuǎn)的角度，分別為T(mén)RANS_NONE,TRANS_ROT90,TRANS_ROT180,TRANS_ROT270，以便在后來(lái)的setTransform()中將這些常量代入。并反復(fù)使用Graphics的drawLine()、drawImage()繪畫(huà)出一個(gè)三維的效果，增強(qiáng)視覺(jué)感。閃光位置設(shè)置了三處坐標(biāo)，由于敵人不能同時(shí)出現(xiàn)，便設(shè)置了enemyOutDelay的倒數(shù)計(jì)時(shí)，每次屏幕刷新會(huì)減少一次計(jì)數(shù)，直到為0時(shí)就準(zhǔn)備一輛坦克。接著調(diào)用setCurrent()顯示統(tǒng)計(jì)分?jǐn)?shù)的畫(huà)面，為了進(jìn)入下一關(guān)，統(tǒng)計(jì)畫(huà)面只是停留四秒，就重新轉(zhuǎn)回BattleCanvas畫(huà)面。為此，地圖必須首先載入。外部文件分別命名為level*.png，利用MIDP中唯一獲取外部文件為程序內(nèi)資源的getResourceAsStream()函數(shù)將地圖文件讀入程序。這兩個(gè)類均在BattleCanvas中建立了對(duì)象，以便進(jìn)行統(tǒng)一調(diào)度。其中，當(dāng)選擇第一項(xiàng)時(shí)將載入正式游戲畫(huà)面BattleCanvas類，第二項(xiàng)將顯示幫助信息(效果如圖43)，第三項(xiàng)則是重新顯示與作品和作者相關(guān)的logo畫(huà)面。效果如圖42所示。運(yùn)行畫(huà)面如圖41所示。圖34 內(nèi)存監(jiān)視器 本章小結(jié)： 第三章中介紹了程序的流程、相關(guān)技術(shù)的思想及其在本程序中的應(yīng)用。為了能與各種IDE集成，就像Java2 SDK一樣，混淆器采用命令行參數(shù)的形式，以便可被其調(diào)用。從而不能保護(hù)作者的知識(shí)成果。其方法有：第一，就是盡量縮短命名的長(zhǎng)度。一共可以存儲(chǔ)10條最高分。主要有兩種方法：1. 標(biāo)記法。RecordStore的API采用了時(shí)間戳的概念，其長(zhǎng)整型變量由System的currentTimeMillis()函數(shù)返回決定。微小的存儲(chǔ)空間也限制了它們的結(jié)構(gòu)不能過(guò)于復(fù)雜。其次，子彈之間需要檢測(cè)是否碰撞。這是允許的，但需要對(duì)他們標(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ā)生碰撞，則坦克應(yīng)當(dāng)選擇掉轉(zhuǎn)方向，此時(shí)，兩輛碰撞的坦克又因?yàn)槠渚匦螀^(qū)域不重合而不符合collidesWith的條件，就可以繼續(xù)正常運(yùn)行了。同時(shí)，這樣的機(jī)制也可檢測(cè)到幾個(gè)鍵同時(shí)按下的狀態(tài)，從而提供斜向運(yùn)行等相應(yīng)功能。這樣的機(jī)制并不適合某些游戲場(chǎng)合。 有關(guān)繪圖的一些技術(shù)，進(jìn)行游戲繪圖一般需要手動(dòng)編程使用雙緩沖。這項(xiàng)技術(shù)通常應(yīng)用在2D游戲平臺(tái)的滾動(dòng)背景的繪圖。在有些情況下，控制主角的翻轉(zhuǎn)，尤其是多幅圖片配合顯示的過(guò)程，如果將多圖的共享定位點(diǎn)設(shè)置在通常的左上角，將很不容易控制，因?yàn)樵S多翻轉(zhuǎn)都是以其他點(diǎn)為參考電的（比如，中心點(diǎn)）。本程序中所有的地圖、坦克都采用LM控制，敵方坦克的生成由附加一個(gè)EnemySprite對(duì)象得到。地圖繪制、主角的動(dòng)態(tài)顯示、按鍵的檢測(cè)、圖層的控制等游戲?qū)俚奶匦远嫉玫搅嗽谝苿?dòng)設(shè)備上最大的發(fā)揮。PNG格式提供透明背景的圖象，這對(duì)繪制游戲畫(huà)面和被操縱主角極有幫助。鍵盤(pán)事件由鍵代碼指定，但這樣控制游戲會(huì)導(dǎo)致缺乏通用性，并不是每個(gè)設(shè)備的鍵盤(pán)布局都適合游戲的操作。圖33 與主程序相關(guān)的類的UML視圖圖33是程序中類之間的UML分析圖。如：用戶坦克的生命是否已完全用盡，敵方坦克數(shù)是否已經(jīng)為零，屏幕上的坦克數(shù)量是否少于仍剩下的坦克數(shù)量等。這三種狀態(tài)的轉(zhuǎn)換關(guān)系如圖所示：本程序采用面向?qū)ο蟮脑O(shè)計(jì)模式，對(duì)游戲中的所有物體賦予對(duì)象的概念和屬性。其數(shù)據(jù)庫(kù)結(jié)構(gòu)較為簡(jiǎn)單，被稱之為RMS系統(tǒng)。良好的用戶界面更是吸引用戶的硬指標(biāo)，相關(guān)的美術(shù)構(gòu)圖也需要有一定的考慮。4. 對(duì)于雙方坦克發(fā)出的子彈的控制也需要對(duì)其跟蹤控制，子彈也需要處在獨(dú)立的線程中。存儲(chǔ)媒體手機(jī)內(nèi)建瀏覽器JavaAppicationManagerKVM描述檔圖示檔JAR檔Java ServletHTML網(wǎng)頁(yè)6．安裝應(yīng)用程序8．載入并執(zhí)行應(yīng)用程序使用者手機(jī)網(wǎng)站網(wǎng)絡(luò)1．瀏覽網(wǎng)頁(yè)圖21 JAM工作流程圖 本章小結(jié)：第二章介紹了Java語(yǔ)言的特點(diǎn)、本程序的開(kāi)發(fā)環(huán)境及其相關(guān)工具的原理和使用。當(dāng)兩年前還是JBuilder6時(shí)，現(xiàn)今已推出了10的版本。4. 分布式Java建立在TCP/IP網(wǎng)絡(luò)平臺(tái)上，提供了用HTTP和FTP協(xié)議傳送和接收信息的庫(kù)函數(shù)，使用其相關(guān)技術(shù)可以十分方便的構(gòu)建分布式應(yīng)用系統(tǒng)。 本章小結(jié)：引言和第一章中介紹了手機(jī)在無(wú)線應(yīng)用方向的當(dāng)今概況，并介紹了游戲業(yè)務(wù)在當(dāng)前社會(huì)的發(fā)展?jié)摿Α? 任天堂(Nintendo)的8位FC機(jī)器和Battle City背景介紹圖13 Battle City的界面　 FC(Family Computer)主機(jī)在歐美又稱Nintendo Entertainment System（可譯作任天堂娛樂(lè)平臺(tái)即NES）。對(duì)于一個(gè)基于訂閱的游戲，重要的是與別的玩家合作以增強(qiáng)所玩游戲的智力和隨機(jī)性。所以一個(gè)好的手機(jī)游戲應(yīng)該提供短時(shí)間的娛樂(lè)功能，并且允許用戶在游戲和工作模式之間順利切換。一個(gè)成功的手機(jī)游戲大多具有以下特征： 由于他們的創(chuàng)新天性，游戲不再是由大型采購(gòu)公司控制的技術(shù)產(chǎn)品——游戲領(lǐng)域總是有充足的空間給那些在這方面有天分的單個(gè)創(chuàng)新者。因?yàn)镴2ME應(yīng)用在不同設(shè)備上都是便攜式的，他們常?？稍诰W(wǎng)絡(luò)上下載和執(zhí)行。這個(gè)版本針對(duì)資源有限的電子消費(fèi)產(chǎn)品的需求精簡(jiǎn)核心類庫(kù)，并提供了模塊化的架構(gòu)讓不同類型產(chǎn)品能夠隨時(shí)增加支持的能力。但是傳統(tǒng)手機(jī)存在以下弊端：1. 傳統(tǒng)手機(jī)出廠時(shí)均由硬件廠商固化程序，程序不能增加、刪除，有了錯(cuò)誤也不能更新、修改，若要增加新功能必須另?yè)Q一部手機(jī)。繼短信、彩信等服務(wù)之后，中國(guó)移動(dòng)提供基于Java的百寶箱業(yè)務(wù)，應(yīng)用產(chǎn)品遍及商務(wù)應(yīng)用、信息獲取、英漢互譯、游戲娛樂(lè)等多媒體領(lǐng)域。本程序的界面和運(yùn)作方式繼承于日本任天堂公司在20世紀(jì)80年代開(kāi)發(fā)的Battle City游戲，將老少皆宜的經(jīng)典作品移植到手機(jī)上來(lái)，為更流行的硬件平臺(tái)提供應(yīng)用軟件。本論文著眼于J2ME技術(shù)的應(yīng)用，開(kāi)發(fā)一款可商用的手機(jī)游戲程序——坦克大戰(zhàn)。短短幾年內(nèi)，手機(jī)已經(jīng)升級(jí)了幾代產(chǎn)品，普及率逐年攀升，生產(chǎn)效率不斷上升，產(chǎn)品價(jià)格比個(gè)人電腦的摩爾定律有更驚人的下調(diào)，以至手機(jī)是大多是城市居民不可缺少的一件隨身設(shè)備。目 錄摘 要 I Abstract I 引　　言 2 第一章　 緒 論 3 手機(jī)軟件現(xiàn)狀 3 游戲業(yè)務(wù)及J2ME概況 3 任天堂(Nintendo)的8位FC機(jī)器和B