【文章內(nèi)容簡介】 要是繪制游戲中的場景，另一部分主要是繪制物理模擬模塊中的Body即建筑、精靈和道具。通過動畫的繪制操作才能讓游戲更真實更具有吸引力。(3) 聲音管理在支持混音的手機(jī)上根據(jù)玩家的輸入播放相應(yīng)的聲音。游戲開始后必須要有背景音樂，游戲開始頁面和游戲過程中玩家的操作要有提示音樂，英雄發(fā)射子彈后要播放發(fā)射子彈的聲音，英雄打光子彈以后要播放扣動扳機(jī)而沒有子彈的聲音，子彈碰撞墻壁等要有音效并且玩家可以設(shè)置是否播放音樂或音效。(4) 資源管理資源管理實現(xiàn)資源的加載和釋放。例如：動畫管理模塊需要圖片資源進(jìn)行繪制操作，資源管理模塊就會提供圖片。在動畫管理模塊不需要這個圖片時，資源管理模塊就將這個圖片的引用設(shè)為null，這樣虛擬機(jī)就能回收這塊內(nèi)存[7]。(5) 游戲狀態(tài)管理判斷游戲的狀態(tài)是繼續(xù)游戲、玩家勝利或是玩家失敗。根據(jù)游戲的狀態(tài)決定游戲的進(jìn)程。(6) RMS管理。游戲需要保存玩家通過每一關(guān)的信息如：玩家通過的關(guān)卡ID、玩家發(fā)射的子彈數(shù)目、玩家通過此關(guān)時共有多少子彈（最大子彈數(shù)）。關(guān)卡信息里還要保存關(guān)卡ID、關(guān)卡獎勵的子彈數(shù)。系統(tǒng)還可以保存游戲的狀態(tài)。 小結(jié)本章針對讓子彈飛這款益智游戲擬實現(xiàn)的功能，分析得出本游戲的操作流程。根據(jù)J2ME開發(fā)的特點和游戲策略得出該系統(tǒng)的功能需求，最后使用UML對系統(tǒng)進(jìn)行建模，得出了本系統(tǒng)的用例圖。414 系統(tǒng)總體設(shè)計 功能設(shè)計在需求分析階段獲取了系統(tǒng)擬實現(xiàn)的功能模塊后為了將所有的功能模塊組裝成一個系統(tǒng)，就需要一個模型即框架來組織這些模塊。所以，本小節(jié)將介紹傳統(tǒng)的基于J2ME的游戲框架和在傳統(tǒng)框架基礎(chǔ)上整合了Emini物理引擎的游戲框架。 游戲框架設(shè)計一般基于J2ME的手機(jī)應(yīng)用程序都必須是MIDlet的子類，并且子類必須重寫父類的startApp()、pauseApp()和destroyApp()。當(dāng)應(yīng)用程序運(yùn)行時首先調(diào)用startApp()，當(dāng)應(yīng)用程序運(yùn)行時發(fā)生暫停時（如來電話或者短信）pauseApp()可能被調(diào)用，這依靠手機(jī)的具體實現(xiàn)，MIDlet結(jié)束時或者玩家結(jié)束MIDlet程序時destroyApp()被調(diào)用。游戲類型的應(yīng)用程序還額外需要一個或者幾個畫布并重寫畫布類的paint()方法以便實現(xiàn)游戲的邏輯處理和繪制游戲中的場景、精靈、道具等游戲元素。同時游戲畫布類還要實現(xiàn)Runnable接口，通過run()控制游戲的運(yùn)行，除此之外游戲一般要和用戶交互。根據(jù)交互的方式不同可以選擇要實現(xiàn)CommandListener接口或者實現(xiàn)觸摸屏事件的響應(yīng)。通過實現(xiàn)mandAction()方法響應(yīng)玩家按鍵輸入。如果游戲還需要響應(yīng)玩家觸摸屏事件或者按鈕事件還必須根據(jù)系統(tǒng)和玩家的交互需求重寫畫布類keyPressed()、keyRepeated()、keyReleased()、pointerPressed()、pointerDragged()或pointerReleased()方法[8]。一般框架的總體實現(xiàn)類圖如圖41所示：圖41 一般框架的總體類圖由于本游戲要實現(xiàn)一些物理效果，所以要集成Emini物理引擎。這就讓本游戲的框架與傳統(tǒng)的框架有些不同。首先是加入了一個中間的“容器”。傳統(tǒng)框架中游戲中出現(xiàn)的角色比如精靈、怪獸、建筑物等是直接繪制在畫布的。而集成了Emini物理引擎的游戲框架，它的游戲場景需要直接在畫布中繪制，游戲中的馬匪、箱子、主角都是集中在GraphicWord類中。然后由這個GraphicWord類將所有元素繪制到畫布中。這種繪制方式屏蔽了底層的繪制細(xì)節(jié)，提高了繪制的效率，減少了繪制的編碼量。只需由所有元素的父類即Body類實現(xiàn)繪制方法。其次，游戲的邏輯控制實現(xiàn)要由畫布的paint()方法轉(zhuǎn)移到物理引擎的tick()方法。tick()方法的作用是在物理模擬的每一個周期內(nèi)，處理游戲的物理方面的邏輯請求和物理模擬請求。邏輯請求的一種情況是:子彈擊中了馬匪，馬匪應(yīng)該死亡即設(shè)置馬匪的isAlive屬性為false，同時子彈的生命值減去1。第二種情況是馬匪被道具砸中，本游戲中就認(rèn)為馬匪被砸死，所以要設(shè)置馬匪的isAlive屬性為false。物理請求的情況是指物理模擬的需要，為了實現(xiàn)這個請求，在GraphicWord類的tick()內(nèi)部，可以調(diào)用父類的tick()方法。最后，本系統(tǒng)將游戲分為四個層次。這四個層次依次是數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層、游戲控制層、游戲視圖層。數(shù)據(jù)訪問層有兩個模塊第一個是對使用RMS存儲的數(shù)據(jù)和對以文件形式存儲的游戲資源地管理。業(yè)務(wù)邏輯層主要是由兩個模塊組成，一個是聲音管理模塊另外一個是物理模擬模塊?？刂茖又饕怯捎螒驙顟B(tài)模塊組成，同時還要接受視圖層傳送的用戶輸入處理后返回處理結(jié)果。視圖層由動畫管理模塊組成。 功能模塊設(shè)計根據(jù)需求分析得出的系統(tǒng)擬實現(xiàn)的功能，可以進(jìn)而設(shè)計各個模塊中所包含的類。(1) 物理模擬模塊中涉及到的參與者有主角、馬匪，障礙物如箱子、鐵球還有主角的武器——子彈。根據(jù)面向?qū)ο蟮乃枷?，可以抽象出以上所有對象的共性符合Body類的屬性。所以，將所有對象的超類定義為Body。又因為主角、馬匪和子彈的特殊性，所以定義MySprite類和Bullet類為Body類的子類。Hero和Robber為MySprite類的子類。GraphicWord是Word類的子類，該類作為所有Body類的容器。GraphicShapeSet類管理所有Body類的Shape對象，該類作為將每個精靈的形狀和圖片連接在一起的橋梁。(2) 動畫管理模塊主要涉及到如何向用戶呈現(xiàn)出精彩的游戲畫面。所以本模塊主要是由Canvas類的子類StartCanvas、Index、Simulation、EndCanvas等畫布類來實現(xiàn)的。(3) 聲音管理模塊主要是管理背景音樂、前景音效的。所以，要用處理聲音播放業(yè)務(wù)的類Audio和實現(xiàn)背景音樂播放的BackMusic和ForeMusic。由于音樂播放服務(wù)具有同步性所以BackMusic和ForeMusic是Thread類的子類。(4) 資源管理模塊主要是對游戲中用到的圖片、聲音文件進(jìn)行管理。所以，涉及到文件的加載類LoadResource類。(5) 游戲狀態(tài)管理模塊主要是判斷游戲的狀態(tài)即游戲的輸贏、對用戶輸入的處理。主要由Main類完成此功能。(3) RMS管理即數(shù)據(jù)庫管理功能。為了完成對關(guān)卡數(shù)據(jù)的管理和游戲的保存操作結(jié)合RMS存儲格式的特殊性，數(shù)據(jù)庫操作的基類為BaseDao，Guan和SaveGame是它的子類。 數(shù)據(jù)庫設(shè)計 數(shù)據(jù)庫概念結(jié)構(gòu)設(shè)計根據(jù)需求分析可以得到游戲數(shù)據(jù)庫概念模型[9]即ER圖，如圖42所示：圖 42 ER圖 其中各個實體的屬性如下：關(guān)卡實體的屬性包括：關(guān)卡獎勵、關(guān)卡ID、默認(rèn)子彈數(shù)量，主鍵是關(guān)卡ID。玩家實體的屬性包括：最大子彈數(shù)、消耗的子彈數(shù)、關(guān)卡ID，主鍵是關(guān)卡ID。保存的游戲?qū)嶓w的屬性包括：關(guān)卡ID、地圖信息、消耗的子彈數(shù)，主鍵是關(guān)卡ID。保存的游戲是指，玩家正在玩一個游戲，因為某種原因（接電話、查看短信等）游戲中斷了，系統(tǒng)自動保存玩家現(xiàn)在的游戲狀態(tài)。 數(shù)據(jù)庫邏輯結(jié)構(gòu)設(shè)計(1) RMS原理MIDP提供了一種特殊的數(shù)據(jù)持久化機(jī)制——RMS（Records Managements System,記錄管理系統(tǒng)）。RMS本質(zhì)上就是一個小型數(shù)據(jù)庫管理系統(tǒng)，它以一種簡單的、類似于普通數(shù)據(jù)的表格的形式組織信息，并將信息持久化存儲，以供應(yīng)用程序在重新啟動以后繼續(xù)使用。但RMS存儲的不是字段而是字節(jié)數(shù)組，所以在數(shù)據(jù)存儲之前就需要編程者設(shè)計數(shù)據(jù)的格式。一個Records Stores存儲的數(shù)據(jù)，如表41所示：表41 Records Store 存儲數(shù)據(jù)Record ID數(shù) 據(jù)1字節(jié)數(shù)組2字節(jié)數(shù)組3字節(jié)數(shù)組(2) 數(shù)據(jù)存儲格式玩家通過某一關(guān)卡，需要保存通過此關(guān)卡的信息到RMS中。玩家RecordStore存儲數(shù)據(jù)的格式為：關(guān)卡ID、子彈數(shù)、最大子彈數(shù)。例如：“040810”表示第四關(guān)用了8發(fā)子彈，系統(tǒng)給玩家10發(fā)子彈。然后將字符串“040810”轉(zhuǎn)化為字節(jié)數(shù)組存入到RecordStore，同時返回加入的RecordID。關(guān)卡的數(shù)據(jù)格式為關(guān)卡ID獎勵子彈數(shù)，如“0101”，第一關(guān)獎勵一發(fā)子彈。存儲游戲的數(shù)據(jù)格式為：關(guān)卡數(shù)剩余子彈數(shù)最大子彈數(shù)shape對象的數(shù)量shape對象的內(nèi)容Body對象的數(shù)量Body對象的內(nèi)容，具體包含以下內(nèi)容關(guān)卡ID剩余子彈數(shù)最大子彈數(shù)ShapeID對應(yīng)的ImageID shapeCount ShapeID ShapeType w h Mass Elas(FX) Friction(FX) BodyCount x y ShapeID Dynamic(boolean) Gravity(boolean) canRation(boolean) RotionDef（FX）。說明：游戲的基本單位是Body(剛體)，而剛體的創(chuàng)建必須基于Shape（形狀）對象。所以Shape對象必須存入RMS。然后存儲Body對象。FX表示數(shù)據(jù)使用FixPoint數(shù)據(jù)類型存儲。 接口設(shè)計根據(jù)以上分析，新的游戲框架整合了Emini物理引擎并且將游戲的各個模塊組裝成了一個完整的游戲。本系統(tǒng)的總體類圖如圖43所示：圖43 本游戲框架的總體類圖下面主要介紹一下物理模擬模塊中的核心類Bullet類的設(shè)計。Bullet是子彈類，該類在主角發(fā)射子彈以后出現(xiàn)在畫布上。子彈出現(xiàn)的位置經(jīng)過計算以后可以得出，然后再根據(jù)此時子彈的射出方向計算出子彈的發(fā)射速度，子彈在飛行過程中要和建筑物、馬匪和地圖邊界碰撞。當(dāng)子彈發(fā)生碰撞以后，子彈的飛行方向發(fā)生適當(dāng)?shù)淖兓Ｗ訌椀呐鲎泊螖?shù)是一個定值10，當(dāng)碰撞次數(shù)小于10時，子彈可被顯示在畫布否則子彈消失。經(jīng)過以上描述，可以得出Bullet類是Body類的子類、具有Body類的所有屬性和方法，同時具有自身的特殊性例如：速度大小、速度方向、生命值屬性、是否顯示、位置屬性等屬性和改變速度方向、獲取子彈出現(xiàn)位置、改變速度大小、獲取子彈生命值等方法。因此，Bullet類的類圖如圖所示：圖44 Bullet類的類圖 小結(jié)本章在需求分析的基礎(chǔ)上，使用面向?qū)ο蟮木幊趟枷牒蚒ML建模語言[10]結(jié)合J2ME開發(fā)框架和Emini物理引擎的特點，將傳統(tǒng)游戲框架和物理引擎結(jié)合得出了游戲的框架設(shè)計和各個功能模塊的總體設(shè)計。本章還根據(jù)游戲的實際需要設(shè)計了系統(tǒng)數(shù)據(jù)庫的概念模型和邏輯模型。在以上分析的基礎(chǔ)上，進(jìn)行了系統(tǒng)類的設(shè)計。5 系統(tǒng)詳細(xì)設(shè)計與實現(xiàn) 功能模塊詳細(xì)設(shè)計 物理模擬模塊物理模擬模塊的實現(xiàn)主要是基于Emini物理引擎，通過調(diào)用、重寫或?qū)崿F(xiàn)新的方法完成碰撞檢測和處理、滿足動量定理的碰撞后的反應(yīng)、物體運(yùn)動過程中在摩擦力的作用下物體能靜止；物體在空中時能夠在重力作用下自由下落。同時，例如子彈還可以設(shè)置是否受到重力影響。上述需求都可以通過實現(xiàn)Emini物理引擎所提供的接口來實現(xiàn)。但是，由于游戲的特殊性，需要設(shè)置單獨處理子彈飛行的初始化工作和處理子彈碰撞后的反應(yīng)的算法即在Body類的基礎(chǔ)上適當(dāng)?shù)募尤胱宇惖奶厥夥椒āＪ紫冉榻B子彈飛行之前的初始化工作即確定子彈的出現(xiàn)位置和子彈的速度大小。圖51 子彈出現(xiàn)位置示意圖如圖所示：O點代表主角的肩部，直線代表主角的胳膊A點代表觸摸屏上玩家觸摸的點，C或者代表槍口。 表示子彈出現(xiàn)的位置和水平方向（逆時針）的角度。直線的方程，圓O的方程： 已知r=23，O點坐標(biāo)，A點坐標(biāo)。(1) 求直線 的斜率。(2) 聯(lián)立直線方程和圓O的方程。可求解出C和的坐標(biāo)。(3) 根據(jù)點A的位置確定子彈是在C或者出現(xiàn)。子彈的出現(xiàn)位置確定以后，下一步要確定子彈的初始速度，根據(jù)上一步求出的斜率k利用反正切方法可求解出的大小。則子彈的初始速度為： = = 根據(jù)以上分析子彈飛行的初始化工作已經(jīng)完成。在介紹子彈碰撞處理算法之前，首先定義方向向量：我們約定1表示X軸、Y軸正方向，1表示負(fù)方向。則方向向量可表示2D平面內(nèi)所有X軸和Y軸正負(fù)速度方向的組合。其次介紹子彈飛行過程中碰撞的處理算法。(1) 第一種情況較為簡單即子彈和MySprite類型的子類之一馬匪碰撞。通過設(shè)置子彈的彈性系數(shù)可使子彈進(jìn)行不改變運(yùn)動方向的（子彈穿過馬匪）碰撞，算法結(jié)束。否則執(zhí)行第2步。(2) 第二種情況是子彈和建筑層發(fā)生了碰撞，它要改變速度方向。首先判斷子彈和幾個物體發(fā)生了碰撞，具體情況如圖所示： 圖52 子彈的碰撞1 圖53 子彈的碰撞2 圖54 子彈的碰撞3圖52表示子彈在兩個Body的結(jié)合部位發(fā)生了碰撞，圖53表示子彈和一個物體發(fā)生了碰撞，圖54表示子彈在兩個物體的夾角部分發(fā)生了碰撞。若子彈發(fā)生碰撞的情況如圖52或者圖53所示，則執(zhí)行第3步。否則算法執(zhí)行第4步。(3) 判斷子彈和物體的相對位置如圖：Q(x5,y5)圖55 子彈和碰撞物體的相對位置示意圖E點表示子彈的位置，A、B、C、D四個點表示剛體的四個頂點。首先，根據(jù)A、B、C、D四點的坐標(biāo)求出直線、的方程，然后判斷E點和O點的相對位置。若，根據(jù)平面幾何知識，若E在內(nèi)部則E點的縱坐標(biāo)y1一定滿足，子彈的X軸方向系數(shù)x_d 改變?yōu)?。反之，若E在O左側(cè)即，子彈的X軸方向系數(shù)x_d 改變?yōu)?。若子彈既不在內(nèi)部也不在內(nèi)部則進(jìn)行下一步判斷若則子彈在P點出現(xiàn)，子彈的Y軸方向系數(shù)y_d變?yōu)?,反之子彈在Q點出現(xiàn)，Y軸方向系數(shù)y_d變?yōu)?。特殊的四種情況是子彈在直線或者直線上時，此處只列舉一種情況如圖56所示：圖56 子彈方向改變的特殊情況當(dāng)子彈無論是以方向向量還是方向向量所示的方向和剛體相撞，都沿著方向向量所指方向繼續(xù)飛行。算法結(jié)束。(4) 根據(jù)圖54提示可知子彈的前進(jìn)方向已經(jīng)不能通行，所以，子彈的Y軸方向系數(shù)y_d=1, X軸方向系數(shù)x_d=1。其它情況類似，這里不再敘述。算法結(jié)束。根據(jù)需求分析,物理模擬模塊的活動圖如圖57所示：圖57 物理模擬模塊的活