【正文】 合用在嵌入式系統(tǒng)之中。 2. 傳統(tǒng)手機(jī)訪問互聯(lián)網(wǎng)是通過 WAP(Wireless Application Protocal)，所有網(wǎng)絡(luò)資源必須接通網(wǎng)絡(luò)才能在線訪問，非常耗時(shí)、費(fèi)用亦很高。本文可算是對(duì)新技術(shù)的一些嘗試，代表對(duì)無線平臺(tái)應(yīng)用程序推廣的一些努力。 根據(jù)官方公布的統(tǒng)計(jì)數(shù)據(jù)，我國移動(dòng)電話用戶已突破 3 億。這種架構(gòu)對(duì)于消費(fèi)性電子產(chǎn)品而言是具有革命性的，因?yàn)樵谙M(fèi)性電子產(chǎn)品中的處理器及操作系統(tǒng)各不相同，要在這些平臺(tái)上開發(fā)程序必須要了解各個(gè)平臺(tái)的特性，以及其提供的API 使用方式，分別開發(fā)不同的版本才能執(zhí)行，影響應(yīng)用程序的普及性。本論文著眼于 J2ME 技術(shù)的應(yīng)用，開 發(fā)一款可商用的手機(jī)游戲程序 —— 坦克大戰(zhàn)。 I 摘 要 J2ME(Java 2 Micro Edition) 是近年來隨著各種不同設(shè)備，尤其是移動(dòng)通信設(shè)備的飛速發(fā)展而誕生的一項(xiàng)新的開發(fā)技術(shù)。本程序的界面和運(yùn)作方式繼承于日本任天堂公司在 20 世紀(jì) 80 年代開發(fā)的 Battle City 游戲，將老少皆宜的經(jīng)典作品移植到手機(jī)上來，為更流行的硬件平臺(tái)提供應(yīng)用軟件。 近幾年，由于微處理器性能的大幅提升，加上無線通訊技術(shù)的突破，手持式移動(dòng)設(shè)備開始受到大眾的青睞。依托這樣的市場(chǎng)，一旦無線 Java 應(yīng)用大規(guī)模開展起來，將會(huì)創(chuàng)造出比短信業(yè)務(wù)更為驚人的利潤(rùn) 。 本論文中第一章介紹游戲機(jī)軟硬件歷史、 Java 語言、 J2ME 及其相關(guān)技術(shù)； 第二章介紹了開發(fā)工具和相關(guān)軟硬件環(huán)境的背景； 第三章分析該作品設(shè)計(jì)的思想和流程，介紹總體結(jié)構(gòu)； 第四章并詳細(xì)闡述有關(guān)重點(diǎn)實(shí)現(xiàn)細(xì)節(jié)； 第五章提及了開發(fā)過程、心得體會(huì)、經(jīng)驗(yàn)和感想。 而 Java 技術(shù)在無線應(yīng)用方面的優(yōu)勢(shì)非常明顯： 1. 應(yīng)用程序可按需下載，而不是購買由硬件商提供的套件，可升級(jí)空間大。 Java 平臺(tái)演進(jìn)到 Java2后， Java 平臺(tái)分別針對(duì)不同領(lǐng)域的需求被分成四個(gè)版本，亦即 J2EE、 J2SE、 J2ME 以及JavaCard(其結(jié)構(gòu)示意圖見圖 11)。 J2ME 在設(shè)計(jì)其規(guī)格的時(shí)候，遵循著“對(duì) 各種不同的裝置而造出一個(gè)單 一的開發(fā)系統(tǒng)是沒有意義的事” 這個(gè)基本原則。 J2ME 平臺(tái)被認(rèn)為是最杰出的手機(jī)游戲平臺(tái)，它為開發(fā)者、設(shè)備制造商、網(wǎng)絡(luò)通信公司和消費(fèi)者廣泛接受。幸運(yùn)的是， Java 被設(shè)計(jì)成一種安全的語言。計(jì)算機(jī)游戲者渴望更加強(qiáng)大的硬件計(jì)算能力；渴望不受不同的軟件的限制 —— 無論是將圖形強(qiáng)制在人工智能（ AI）上 還是網(wǎng)絡(luò)安全性。手機(jī)已經(jīng)與現(xiàn)代生活方式緊緊地結(jié)合在一起。但是，對(duì)于開發(fā)者來說，將控制臺(tái)游戲遷移到手機(jī)游戲工程很大 。消費(fèi)者不會(huì)花幾個(gè)小時(shí)去研究一個(gè) 3 元的手動(dòng)操作的游戲。手機(jī)用 戶常常在任務(wù)（如等一個(gè)電子郵件或者等車）之間有一小段時(shí)間?；谟嗛啠菏謾C(jī)游戲的盈利成功取決于他們巨大的使用量。 這款主機(jī)的性能比當(dāng)時(shí)的多數(shù)主機(jī)都要 強(qiáng)大，而價(jià)格上卻便宜得多。 Battle City 是其發(fā)售卡帶中的一款力作 ，設(shè)置了 35 個(gè)關(guān)卡， 可以雙人操縱，畫面設(shè)置了若干種類的建筑物和阻擋物 ，以消滅所有敵人為通關(guān)條件，并有接寶物等增加游戲效果的設(shè)置， 畫面精 美，音效杰出， 在 PC機(jī)的 80386 處理器仍未面世的當(dāng)時(shí)，能在硬件上運(yùn)行這樣的 2D 程序不得不 令人驚嘆，難怪常有人說游戲 程序 是最大限度發(fā)揮硬件水平的載體。 圖 12 80 年代中期的 FC 機(jī)器 圖 13 Battle City 的界面 6 第二章 開發(fā)環(huán)境及相關(guān)技術(shù)的介紹 開發(fā)環(huán)境 操作系統(tǒng)： Microsoft Windows XP 程序語言： Java 2 開發(fā)包： Java(TM) 2 Standard Edition (build ) Sun Micro. J2ME Wireless Tool Kit IDE: Borland Jbuilder 9 Java 語言的特點(diǎn) 1. 平臺(tái)無關(guān)性 Java 引進(jìn)虛擬機(jī)原理，并運(yùn)行于虛擬機(jī)，實(shí)現(xiàn)不同平臺(tái)之間的 Java 接口。它提供了安全管理器，防止程序的非法訪問。 Java 取消了 C 語言的結(jié)構(gòu)、指針、 define 語句、多重繼承、goto 語句、操作符、重載等不易被掌握的特性，提供垃圾收集器自動(dòng)回收不用的內(nèi)存空間。 JBuilder 集成了 Borland 公司開發(fā)工具系列的優(yōu)秀特性，使得使用過 C++Builder,Delphi 的程序員很容易的過度到JBuilder 的開發(fā)環(huán)境當(dāng)中。它通用性高，開發(fā)出的應(yīng)用程序可保證能運(yùn)行在大部分設(shè)備上，而不像專用廠商具有一定的不兼容性。 Java Application Manager 會(huì) 從網(wǎng)絡(luò) 上 下載 代表 該 Application Suite 的 JAR 檔 ，接 著 在手 機(jī) 上安裝此 MIDlet Suite， 然后 在手 機(jī)開 始 執(zhí)行該應(yīng)用程序 。一個(gè)實(shí)時(shí)運(yùn)行的 最終作品，每秒都會(huì)運(yùn)行成千上萬行程序，繪圖事件、 鍵盤事件都會(huì)以極高的頻率在后臺(tái)等待響應(yīng)，若有絲毫的差別都將很容易導(dǎo)致程序在運(yùn)行不久后可能出現(xiàn)嚴(yán)重錯(cuò)誤，甚至死循環(huán)。 Java 的多線程能力為實(shí)現(xiàn)這樣的游戲提供了可能。這需要對(duì)所有的對(duì)象有較好的控制。每一次刷新頁面、每前進(jìn)一步都需要將所有的周圍環(huán)境都進(jìn)行掃描。否則，不僅難于控制和處理過多的元素，也會(huì)因過多的大型圖片而不能限制程序的大小，失去手機(jī)上程序的原則和Java 的優(yōu)勢(shì)。記錄分?jǐn)?shù)的存儲(chǔ)方式也需要有較好的解決方案。除開發(fā)過程中對(duì)結(jié)構(gòu)上的控制、變量的使用、 算法的優(yōu)化等優(yōu)化外，還可以使用混淆器 (Obfuscator)進(jìn)行程序打包后的優(yōu)化。 每個(gè) MIDlet 都必須繼承 這個(gè)抽象類。在主程序運(yùn)行的線程中，畫面刷新將以一定的頻率采用雙緩沖技術(shù) 對(duì)屏幕重 繪，實(shí)時(shí)反映整個(gè)游戲的進(jìn)行狀態(tài)。用戶再次發(fā)射子彈 時(shí)只是將終止的線程再次激活。 主程序流程如圖 32所示： 程序?yàn)樾枰瓿瑟?dú)立功能的需顯示的模塊設(shè)置了單獨(dú)的類。在選擇開始后，將運(yùn)行BattleCanvas 類中的總流程控制。 在每關(guān)的結(jié)束或死亡后都將載入 ScoreScreen 類，統(tǒng)計(jì)當(dāng)前的分?jǐn)?shù)。 從程序開發(fā)的觀點(diǎn)看， Canvas 類可與高級(jí) Screen 類交互，程序可在需要時(shí)在 Canvas中摻入高級(jí)類的組件。本程序中，操縱用戶坦克運(yùn)行的按鍵都定義為游戲控制鍵，這樣便能適應(yīng)所有的機(jī)器。 其對(duì)象會(huì)被傳給 Canvas 的 paint()函數(shù)，以便 最終顯示。 PNG 格式圖片中包含許多定義其圖片特性的冗余部分 (Chunks)。本程序中的地圖元素都集成在一張 圖片中 ，實(shí)現(xiàn)了方便的管理和程序體積的精簡(jiǎn) 。 它包括了一系列自動(dòng)獲取了代號(hào)和位置的層，簡(jiǎn)化了各層加入游戲畫面的過程，提供了自動(dòng)排序和繪制的能力。 LM 中的 View Window 控制著與 LM 相對(duì)坐標(biāo)的可視區(qū)域。 Sprite 類是繼承自 Layer 的用于存儲(chǔ)多楨 的基本可視元素。每個(gè)小圖按照其排列順序有相應(yīng)的序號(hào)，在程序中調(diào)用其序號(hào)，就可以繪制出相應(yīng)的圖片。參考點(diǎn)由 defineReferencePixel 函數(shù)確定 未翻轉(zhuǎn)圖片狀態(tài)時(shí)的坐標(biāo)。 TiledLayer 是有一組圖象格元素 (grid of cells)組成的整塊虛擬圖象。多塊格可由大塊同時(shí)替換組合而模擬動(dòng)態(tài)的背 13 景，這不需要逐塊替換所有的靜 態(tài)圖象格而顯得非常方便。如果整塊地圖均由繪圖產(chǎn)生，將導(dǎo)致體積迅速增加，且對(duì)坦克與障礙物的碰撞也難以檢測(cè)。 Image 類提供了一個(gè)建立背景的靜態(tài)方法 createImage(int width, int height)，再利用 getGraphics()方法取得屬于這個(gè)背景的 Graphics 對(duì)象 ， 所進(jìn)行的繪圖操作都會(huì)作用在背景上 ，等到全部的繪圖操作完成后，再調(diào)用 drawImage()方法將背景的數(shù)據(jù)復(fù)制到實(shí)際顯示的屏幕上。 坦克的控制和敵方的智能運(yùn)行 GameCanvas 中提供了與以往 不同的鍵盤采樣功能。同時(shí)，事件的執(zhí)行周期也并不一定適合游戲的場(chǎng)合，也許需要更高頻率執(zhí)行的按鍵卻只能在指定的周期內(nèi)規(guī)律的響應(yīng)。只需要此一個(gè)函數(shù)的返回值就可以返回所有鍵的狀態(tài)。 Sprite 類中提供了 collidesWith 函數(shù)，用于判斷是否與某個(gè) TiledLayer、 Sprite、 Image 的對(duì)象有圖象上的重合（即游戲中的碰撞）。 在多出的 11個(gè)象素中，按照每個(gè)象素依次檢查此象素是否于外界發(fā)生碰撞，如果不是按照象素檢查，則當(dāng)坦克與障礙物錯(cuò)位并同時(shí)與兩種物體接觸時(shí)將有可能忽略檢測(cè)其中的一樣物體。敵人 可以自動(dòng)行走，但是應(yīng)當(dāng)在以下適當(dāng)?shù)那闆r下轉(zhuǎn)向：首先是是否超出界面的邊界，其次是是否與地圖障礙物發(fā)生了碰撞 ，再次是是否與用戶坦克發(fā)生了碰撞。 另外，坦克的發(fā)炮間隔和轉(zhuǎn)后的具體方向都由隨機(jī)數(shù)決定。 子彈的運(yùn)行和控制 15 每一個(gè)坦克都有他自己的一顆子彈，這顆子彈在任何一輛坦克被構(gòu)造時(shí)就一直存在，直至此坦克生命的結(jié)束，子彈的再次只是將屏幕上暫時(shí)掩蓋的圖象重新置于坦克炮筒才恰當(dāng)位置，并使其顯示出來，這與現(xiàn)實(shí)中每個(gè)子彈都是單獨(dú)的個(gè)體有所不同。 分為兩種情況，如果此子彈來自于敵方，將只檢測(cè)玩家坦克，因?yàn)閿撤街g的子彈必須允許可以透明的穿過，以保證不會(huì)在敵人之間發(fā)生子彈的消減。 玩家的子彈需要在每一步檢測(cè)所有敵人的子彈的 運(yùn)行狀態(tài)。 RMS 數(shù)據(jù)庫系統(tǒng) MIDP 為 MIDlets 提供了一種永久存儲(chǔ)和后來讀出數(shù)據(jù)的數(shù)據(jù)庫解決方案，被稱為 Record Managerment System(RMS)，是一種類簡(jiǎn)單的基于記錄的數(shù)據(jù)庫。 RMS 包中包括 RecordStore 類。 訪問模式會(huì)在準(zhǔn)備提供共享的 RecordStore 被建立時(shí)被創(chuàng)建。 記錄是字節(jié)數(shù)組。 Record 是以字節(jié)為基本單位來存放的，所以所有要寫入 record 的數(shù)據(jù)都必須先將其轉(zhuǎn)為字節(jié)才能寫入，從 record 所讀出來的數(shù)據(jù)也是字節(jié)，必須將其轉(zhuǎn)換為原先寫入時(shí)的數(shù)據(jù)類型才有意義。符號(hào) 不能和 字段內(nèi)的數(shù)據(jù)相同的字符 。反之若要 讀取數(shù)據(jù)，則先要串接一個(gè) DataInputStream 對(duì)象和 ByteArrayInputStream，依字段的數(shù)據(jù)類用 readInt()、 readBoolean()等方法讀取。 在輸入記錄前，要求用戶 在 TextField 框中 寫入他自己的名字 。 內(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è)上限對(duì)每種手機(jī)都不一樣，大部分在一兩百 KB 內(nèi)。 所有這些可以借助混淆器來幫助實(shí)現(xiàn)。 混淆器 (Obfuscator)的使用 Java 語言并沒有完全編譯成二進(jìn)制可執(zhí)行文件，編譯出的 .class 文件是一種介于源程序和二進(jìn)制之間的一中基于半解釋的 字節(jié)碼，需要虛擬機(jī)來執(zhí)行。如果不加以施行有效的措施，將造成嚴(yán)重的后果。 由于以上介紹的減少變量、函數(shù)的命名長(zhǎng)度的關(guān)系 ，編譯后也會(huì)從 .class 文件中減少這些冗余的信息。 模擬器的相關(guān)調(diào)試 IDE 整合的 Wireless Tool Kit 提供了許多在運(yùn)行時(shí)監(jiān)視運(yùn)行狀態(tài)的工具。由于 Java 語言中，不像許多其他的如 C++語言，不需要指定回收函數(shù)中特定不使用的資源，資源回收機(jī)制將自動(dòng)清空無效變量占用的 空間 。具體算法的代碼實(shí)現(xiàn)和詳細(xì)流程將在下章介紹。）、結(jié)束的函數(shù)。在 startApp()函數(shù)中 ， 隨即調(diào)用了 Displable的 setCurrent()函數(shù)將當(dāng)前屏幕設(shè)置為startChoice。但是當(dāng)顯示的畫面元素超過一屏大小時(shí)，將自動(dòng)轉(zhuǎn)換為永久狀態(tài)。 繼承了 mandListener 的類必須擁有 mandAction()，以決定對(duì)按鍵采取什么樣的行為。 startChoice 繼承了 List 類，用于顯示列表選項(xiàng)，使用其 append()函數(shù)可將選項(xiàng)加入到列表中。 它運(yùn)行在獨(dú)立的線程中，以恒定的頻率刷新畫面。 程序中建立了另外的兩個(gè)類，分別表述了敵人坦克和玩家 坦克的功能。因此，有必要在其中創(chuàng)立一個(gè) LayerManager 的對(duì)象。地圖實(shí)際即為TiledLayer 的一個(gè)對(duì)象，可調(diào)用 setCell 設(shè)置其具體的圖象格內(nèi)容。每個(gè)整數(shù)代表一種障礙物。這是很有必要的。本程序設(shè)置為 6。每次循環(huán)中將檢測(cè)是否死亡，屏幕上坦克的數(shù)量，是否該過關(guān)統(tǒng)計(jì)分?jǐn)?shù)，檢測(cè)用戶輸入的按鍵、重繪整個(gè)屏幕及回收垃圾內(nèi)存 (Garbage Collection)。 進(jìn)入下一關(guān)時(shí)，許多變量需要重新被初始化，如地圖的繪制、敵人出現(xiàn)位置的重置、敵人的數(shù)量、玩家坦克的當(dāng)前位置。當(dāng)它閃光完畢后，敵人就會(huì)從閃光位置出現(xiàn)。 如果玩家已經(jīng)死亡，就需要使用 LayerManager的 insert()將 gameover 字樣插 入到最上層，以免被其他物體覆蓋。 效果如圖 46所示 。 在每次刷新繪圖頁面時(shí)，應(yīng)使用 GameCanvas的 flushGraphics()將屏 幕后臺(tái)的緩沖區(qū)