【正文】 它返回一個 boolean 值，提供給 go()函數(shù)，做進一步的判斷。 構造函數(shù)中創(chuàng)建了每個坦克必須擁有的一顆子彈，這些子彈就將只跟隨自己的坦克調(diào)動。 游戲 的最終運行狀態(tài)如圖 47所示。該三維欄的上方為白色，下方為黑色，就創(chuàng)造了立體感。 在出現(xiàn)正式畫面前設置了一個 loading state*字樣的單獨屏幕，調(diào)用了 loadinglevel()函數(shù)，并停滯了 圖 46 裝載中的畫面 22 1500 毫秒，提示用戶做好準備。 本程序設置的兩次坦克出現(xiàn)的最小間隔為 2秒。 以在兩秒鐘內(nèi)反復閃現(xiàn)兩次為一個生命周期。當然，如果當前已是最后一關，就不會再轉回。 在構造函數(shù)自己調(diào)用了線程的 start 后，程序將開始循環(huán)運行，直至跳出while 的循環(huán)。 由于敵人將依次出現(xiàn)在屏幕上，同時出現(xiàn)的數(shù)量應當受到 控制。 開始 敵人數(shù)量小于 0 嗎？ 顯示記分畫面 最后一關或死亡了嗎？ 進入下一關 敵人數(shù)量大于屏幕上的數(shù)量嗎？ 增加一個敵人 玩家是否死亡 顯示 GameOver 重繪屏幕 內(nèi)存回收 結束 Y N Y N N Y Y N 圖 44 BattleCanvas 類主要關系流程圖 21 圖 45 游戲結束的畫面 繪出地圖后，可用 LayerManager 的 append()將地圖放置在第一層。在創(chuàng)建了 InputStream 類的 map 對象后，使用 read()函數(shù)可將流中的下一個字節(jié)讀出，并返回此字節(jié)代表的整數(shù)。 構造函數(shù)中，需初始化地圖。BattleCanvas 包括了 LayerManager，這樣所有靜態(tài)和動態(tài)的圖象都不需要手動刷新，只需要在LayerManager 中加入所有的需控制的元素，再統(tǒng)一由 LayerManager 刷新即可。 其主邏輯如圖 44所示。 主游戲 邏輯 及其涉及到的若干類 BattleCanvas 主管著所有類之間的協(xié)調(diào)，決定何時死亡，何時分配新的敵人，及控制敵人出現(xiàn)處的閃光圖標、游戲結束后的動態(tài) Gameover 字樣。 鍵盤事件中，可用 getCommandType()返回的 Command 類型來確定選擇的是什么按鈕。 startChoice 繼承了接口 mandListener，這樣，就可以使用高級界面的 Command 按鈕。 當將 FOREVER 作為 Alert的參數(shù)時，將永久顯示，直到用戶點擊相應按鈕 手動結束。 因此，在 TankMain 的構造函數(shù)中分配了 StartChoice 類，即選項畫面的內(nèi)存空間 。該類中擁有可以管理程序的創(chuàng)建、開始、 暫停（手機中很可能有正在運行程序卻突然來電的情況，這時應進入暫停狀態(tài)。分別對繪圖、數(shù)據(jù)庫、游戲基本算法等做了詳細敘述。其中，允許 強制 垃圾回收 (Garbage Collection)。 目前流行的 Obfuscator 有 RetroGuard 等。 混淆器的作用不僅僅是保護代碼，它也有精簡編譯后程序大小的作用。目前流行的如 decode,JAD 等反編譯工具可以以很快的速度生成源文件。 將 PNG格式的小分辨率圖象合并在一張大的高分辨率圖象中，由于減少了 chunks，將比合并前的總大小減少許多。在應用程序內(nèi)，對于所建立的類、接口、方法及變量名而言，都需要賦予一個識別的名稱，所命名的名稱每多一個字符就會在類文件內(nèi)多產(chǎn)生一個字節(jié)， 對于一個較復雜的應用程序而言就會增加為數(shù)不小的數(shù)據(jù)量。打印到 屏幕上時，記錄 ID號即為排名 ，因此將顯示三項數(shù)據(jù)。每次有新的更高的記錄就會插入進相應的位置，將最低一名排擠出記錄。利用輸入輸出流可以寫入及讀取不同數(shù)據(jù)類型的數(shù)據(jù)，做法是在寫入數(shù)據(jù)時先將一個 DataOutputStream數(shù)據(jù)流對象串接到一個 ByteArrayOutStream 數(shù)據(jù)流對象，然后再依 字段的數(shù)據(jù)類型用 writeInt()、 writeBoolean()等方法寫入，最后把ByteArrayOutputStream 內(nèi)的元素數(shù)據(jù)寫入 record 中。 將所有要存放的數(shù)據(jù)用字符串表示，但是在字段和字段之間以一個特殊的符號 作為分隔。第一項記錄的 ID是 1，其后的每個記錄 ID遞增。 Record store 每次被修改后都會自動在其屬性上附加上時間戳，這為同步化引擎和程序的控制都極為有效。 同一個包內(nèi)的 MIDlets 可以直接互相訪問它們的記錄集，不同包內(nèi)也可產(chǎn)生共享，但這需要有包的授權屬性決定。 RMS 是專門針對移動設備的服務的。對磚墻將有能力將其擊毀， 使之在畫面上消失；對水泥鋼筋將不能發(fā)生作用，子彈也不能通過； 對于河流，坦克不可以通過，但子彈可以；對于草叢，子彈和坦克都可以通過。敵人之間顯然，如上已經(jīng)提過，不需要檢測，但敵人與玩家之間應當可以互相消除子彈，以便在狹窄的路口中仍有存活的機會。子彈使用的是象素級的碰撞檢測 ，因為子彈的圖片形狀不規(guī)則，如果使用矩形碰撞檢測，將有可能在子彈尚未接觸到物體時就已返回碰撞的真值。 本程序中并未使用過多復雜的人工 智能算法，如有時間，將可能再此方面加以完善。本程序設置為：當碰撞到障礙物或邊界時立即轉向，但 碰到玩家坦克時需要有一個等待的時 間，這個時間由碰撞前隨機取得的在某方向上的持續(xù)行走步數(shù)決定，當發(fā)生坦克間碰 撞時，此隨機數(shù)將在下一次循環(huán)前減少為原來的 2/3，這樣就實現(xiàn)了加快轉向的時間，避免死鎖在一個方向上靜止的停留過長的時間。 敵方坦克由于需要具有一定的智能性，以便對玩家攻擊，使之具有一定的可玩性。為了提前預知碰撞， 可以將所有坦克的碰撞范圍設定為一個比坦克圖片稍大一些的矩形， 此矩形僅在坦克前方比坦克圖形多出一個象素。 敵方按照規(guī)則不能和用戶坦克重合，則它每行走一步就需要把用戶坦克掃描一次，判斷其是否碰 撞到了用戶的坦克。將以位的形式返回鍵盤上所有鍵的按與釋放的狀態(tài) ，當 bit 為 1時，鍵就是被按下的狀態(tài)，為 0 時則為釋放狀態(tài) 。在某些不支持 keyRepeat 功能的設備上，反復執(zhí)行的按鍵，比如發(fā)射子彈，將不能因為長時間按壓而自動重復，這樣就需要用戶高頻率的手動擊鍵，這在操縱空間非常有限的移動設備上是非常困難的 。不過在某些 MIDP 的實現(xiàn)上已經(jīng)加上了雙重緩沖的支持，因此在處 理前應先利用 Canvas 類的 isDoubleBuffer()方法來判斷。需要在paint()方法內(nèi)所想要畫的圖形畫在一張預先準備好的背景，等所有繪圖操作都完成后再將背景的數(shù)據(jù)拷貝到實際的屏幕上。地圖背景分為 20*22 個圖象格，每個格使用一個字節(jié)表示其中的障礙物，圖象文件存儲在外部文件中，以16進制的整數(shù)串表示，因此每個地圖的大小為固定的 440 字節(jié)。 一塊整圖可被分割成等大小的圖象格，每塊格有其對應的序號，按照行列遞增。子彈的參考點設置在子彈底部的中心，因為子彈一出炮筒的時候緊挨著坦克的象素就是其底部中心。由此， 引入?yún)⒖键c的概念。 Sprite 也可以從整合的圖象中讀圖，讀圖時將把大圖分解為若干等寬等高的小圖。唯有界面右側的計分欄由 Graphics 類繪制。層號總是連續(xù)的，即使有中間的層被移除，其他層的序號會作相應的調(diào)整以保持整體的完整性。 LayerManager（以下簡稱 LM） 提供控制整體畫面層的控制。在 Game 包中的 TiledLayer 和 Sprite 類都整合了這樣的功能。坦克之間或與障礙物碰撞時就不會因為背景有特定的顏色，顯示出的效果像貼上的圖片而缺乏真實感，物體之間輕微重疊時最上層圖片也不會覆蓋超過其有效象素外的部分。 程序只能在 paint()函數(shù)中使用Graphics 繪制， GameCanvas 可 調(diào)用 getGraphics()函數(shù) 直接繪制在緩沖區(qū)上，可以在任何時間請求傳輸?shù)角芭_。應 當將鍵代碼轉換為游戲鍵的代碼，以便硬件開發(fā)商能定義他們自己的游戲鍵布局。 繪圖與 新增的 GameCanvas 包 提供低級繪制的 Canvas 類 為了能有程序開發(fā)人員控制接口的外觀和行為，需要使用大量的初級用戶接口類，尤其在游戲程序中，幾乎完全依賴的就是 Canvas 抽象類進行繪圖。 敵方坦克與用戶坦克的相關功能和具體行為分別圖 33 與主程序相關的類的 UML 視圖 Logo 畫面 選項畫面 主程序 屏幕繪圖 本關記分統(tǒng)計 顯示GameOver 顯示歷史記分表 About 開始 敵方需要出坦克時，生成坦克 初始化參數(shù) 死亡時 符合結束條件時 圖 32 本程序的主流程圖 11 定義在 EnemySprite 和 UserSprite 類中，它們都繼承自 TankSprite 公共類，以簡化程序的代碼、理清結構。閃過后載入 StartChoice 類，為用戶提供可選擇的選項。以便程序進入相關的分支執(zhí)行相關的反應代碼，結束游戲或統(tǒng)計分數(shù)等。用戶坦克自誕生之時起將擁有一發(fā)子彈， 子彈雖然開在單獨的線程中，但運行結束后（比如撞到相關物體或敵方坦克時）并不結束子彈對象，只是將其線程終止。 運行程序后允許用戶選擇執(zhí)行選項菜單，在開始游戲后將先從外部文件載入地圖文件，對背景的所有物體進行繪圖。 MIDlet 及相關的支持類組成了 MIDP 應用程序的實際內(nèi)容。 9. Java 是基于虛擬機的半解釋型編譯系統(tǒng)，其執(zhí)行效率較 C++等完全編譯 9 后的程序會低很多，程序如果不進行精簡和優(yōu)化，將可能導致運行的不流暢。如何采用合理的記分標準，需要進行適當?shù)脑O計。 7. 游戲的地圖不可能通過繪圖來解決。 5. 雙方的坦克在前進時也需要考慮到是否碰撞到相關物體或對方坦克，以免重疊運行，造成許多物理上不可能的情況，缺乏真實感。敵方子彈僅需要掃描用戶坦克，而用戶坦克需要在每一步掃描所有的敵方坦克。 3. 己方坦克的運行可以通過鍵盤響應事件控制，但敵方則因為是自動運行，就需要有一定其一定的智能性；同時，出現(xiàn)在屏幕 上的敵方可能會有較多的數(shù)量，這需要為每個敵方開辟一個線程以便能讓其獨立運行。 存儲 媒體 手機 內(nèi)建瀏覽器 Java Appication Manager KVM 描述檔 圖示檔 JAR 檔 Java Servlet HTML 網(wǎng)頁 6．安裝應用程序 8．載入并執(zhí)行應用程序 使用者手機 網(wǎng)站 網(wǎng)絡 1．瀏覽網(wǎng)頁 JAR 檔 圖 21 JAM 工作流程圖 8 第三章 程序結構、思想和相關技術 本程序需解決的有關技術問題 1. 游戲程序是一項精度要求很高的程序系統(tǒng)，因為其代碼利用率很高。它 所使用的 傳輸媒體 可以是 紅外線 、 網(wǎng)絡、以及其他可用來傳輸 的 媒體 。 關于 Wireless Tool Kit WTK(Wireless Tool Kit)是 Sun 公司針對 J2ME 推出的用于手機和 Palm 等移動設備的開發(fā)包，是除手機廠商的專用開發(fā)包外唯 一的手機模擬器開發(fā)包。 Jbuilder 是一種處于市場領先地位的跨平臺環(huán)境，主要用于構建具有行業(yè)實力的企業(yè) Java 應用程序。 5. 健壯性 Java 致力與檢查程序在編譯和運行時的錯誤，并自動回收內(nèi)存，減少了 內(nèi)存出錯的可能性。 2. 安全性 Java 的編程類似 C++,但舍棄了 C++的指針對存儲 器地址的直接操作，程序運行時，內(nèi)存由操作系統(tǒng)分配，這樣可以避免病毒通過指針入侵系統(tǒng)。分析了 J2ME 在手機軟件開發(fā)中起的重要作用，描述了本論文的相關背景。 6502 芯片 cpu 主頻 為 8 bit，12 MHz， 內(nèi)存 8k， 畫面 52 色 ， 同屏最多顯示其中的 13色 ， 聲音 2 個矩波 ,1個三角波， 1個雜音， 1個 PCM 音頻 (見圖 12)。 FC 主機在游戲業(yè)界造成的巨大沖擊眾所周知，這款主機在當時事實上幾乎占領了世界各地多個國家的整個游戲市場，并使得逐漸 沒落的北美游戲市場再度復蘇。好的手機游戲應該利用那些更新的設備特征和網(wǎng)絡基礎設備的優(yōu)點。在今天紛繁復雜的多玩家游戲中具有豐富社會交互的游戲證明是成功的?；谟嗛喌挠螒蚴遣粩喈a(chǎn)生收入的最好方法。 可中斷性 : 多任務處理是手機生活方式的基本特征。易于學習 : 既然手機游戲面向的是普通消費者而不是計算機專家 ，那么他們不可能深入的學習游戲技巧。盡管每個手機游戲都不貴，但是巨大的使用量（如：每人每星期一個新游戲）將使得這個市場商機無限。 手機游戲的盈利主要是由于它們的涉及面很廣。 縱觀 IT 產(chǎn)業(yè)的歷史， 就像軍事的發(fā)展時常推動計算機的演化一樣， 計算機游戲已經(jīng)成為技術創(chuàng)新背后的動力之一 。如果沒有正確的防范，它則為用戶和無線通信公司冒著無數(shù)個安全的風險。也就是說， J2ME 先把所有的嵌入式裝置利用Configuration 的概念區(qū)隔成兩種抽象的型態(tài)。這個版本的應用層面相當廣泛，會是未來 Java 平臺發(fā)展的重點項目。 游戲業(yè)務 及 J2ME 概況 雖然 Java 已經(jīng)被用到許多企業(yè)級軟體上，可是其實骨子里面還是非常適