【導讀】獨立進行研究所取得的成果。畢業(yè)論文中凡引用他人已經(jīng)發(fā)表或未發(fā)。表的成果、數(shù)據(jù)、觀點等，均已明確注明出處。對本文的研究成果做出重要貢獻的個人和集體，均已在文中以明。本聲明的法律責任由本人承擔。識產(chǎn)權(quán)歸屬平頂山學院。本人完全了解平頂山學院有關(guān)保存、使用畢。何復制手段保存和匯編本畢業(yè)論文。導教師同意，且第一署名單位為平頂山學院。本人離校后使用畢業(yè)論。由于手機已經(jīng)成為大眾生活的必需品，適用于手機的應用程序，尤其是游戲，越來越受到人們的關(guān)注和喜愛。益智游戲是指那些通過一定的邏輯推理或是數(shù)。學，物理，化學知識，甚至是游戲設計者設定的原理來完成一定任務的小游戲。一般會比較有意思，需要適當?shù)乃伎?。益智游戲的游戲目標要清晰地呈現(xiàn)給玩家，游戲的邏輯要淺顯易懂，這樣才能讓玩家容易接受。程、操作方法基本相同。一款游戲可以適用于采用不同平臺，相同開發(fā)標準的手機。然后，針對游戲的需求分析制訂了詳細的測試計劃對游戲進行了單

　　

【正文】 所示： M I D l e tM a i n S i m u l a t i o n G r a p h i c W o r l dG r a p h i c S h a p e S e tC a n v a sW o r l d 接 口 R u n n a b l e 接 口 C o m m a n d L i s t e n e rE n d C a n v a sS t a r t C a n v a sI n d e xB o d yB u l l e t M y S p r i t eH e r o R o b b e rB a s e D a oS a v e G a m eG u a nL o a d R e s o u r c eA u d i oB a c k M u s i cF o r e M u s i cT h r e a d 圖 43 本 游戲框架 的總體類圖 下面主要介紹一 下物理模擬模塊中的核心類 Bullet類的設計。 Bullet是子彈類，該類在主角發(fā)射子彈以后出現(xiàn)在畫布上。子彈出現(xiàn)的位置經(jīng)過計算以后可以得出，然后再根據(jù)此時子彈的射出方向計算出子彈的發(fā)射速度，子彈在飛行過程中要和建筑物、馬匪和地圖邊界碰撞。當子彈發(fā)生碰撞以后，子彈的飛行方向發(fā)生適當?shù)淖兓?。子彈的碰撞次?shù)是一個定值 10，當碰撞次數(shù)小于 10時，子彈可被顯示在畫布否則子彈消失。經(jīng)過以上描述，可以得出 Bullet類是 Body類的子類、具有 Body類的所有屬性和方法，同時具有自身的特殊性例如：速度大小、速度方向、基于 J2ME 的益智游戲的設計 18 生命值屬性、是否顯示、位置屬性等 屬性和改變速度方向、獲取子彈出現(xiàn)位置、改變速度大小、獲取子彈生命值等方法。因此， Bullet類的類圖如圖所示： 圖 44 Bullet 類的類 圖 小結(jié) 本章在需求分析的基礎上，使用面向?qū)ο蟮木幊趟枷牒?UML 建模語言 [10]結(jié)合 J2ME 開發(fā)框架和 Emini 物理引擎的特點，將傳統(tǒng)游戲框架和物理引擎結(jié)合得出了游戲的框架設計和各個功能模塊的總體設計。本章還根據(jù)游戲的實際需要設計了系統(tǒng)數(shù)據(jù)庫的概念模型和邏輯模型。在以上分析的基礎上，進行了系統(tǒng)類的設計。 19 5 系統(tǒng)詳細設計與實現(xiàn) 功能模塊 詳細 設計 物理模擬模塊 物理模擬模塊的實現(xiàn)主要是基于 Emini物理引擎，通過調(diào)用、重寫或?qū)崿F(xiàn)新的方法完成碰撞檢測和處理、滿足動量定理的碰撞后的反應、物體運動過程中在摩擦力的作用下物體能靜止；物體在空中時能夠在重力作用下自由下落。同時，例如子彈還可以設置是否受到重力影響。上述需求都可以通過實現(xiàn) Emini物理引擎所提供的接口來實現(xiàn)。但是，由于游戲的特殊性，需要設置單獨處理子彈飛行的初始化工作和處理子彈碰撞后的反應的算法即在 Body類的基礎上適當?shù)募尤胱宇惖奶厥夥椒ā? 首先介紹子彈飛行之前的初始化工作即確定子 彈的出現(xiàn)位置和子彈的速度大小。 圖 51 子彈出現(xiàn)位置示意圖 如圖所示： O點代表主角的肩部，直線 OA代表主角的胳膊 A點代表觸摸屏上玩家觸摸的點， C或者 C? 代表槍口。 AOB? 表示子彈出現(xiàn)的位置和水平方向（逆時 針 ） 的 角 度 。 直 線 OA 的方程 ()ooy k x x y? ? ? ?，圓 O 的方程：22( ) ( )oox x y y r? ? ? ? 已知 r=23， O點坐標 ? ?00,yx ， A 點坐標 ? ?Ayx,A 。 (1) 求直線 OA 的斜率 ( ) / ( )A o A ok x x y y? ? ?。 (2) 聯(lián)立直線 OA方程和圓 O 的方程?？汕蠼獬?C 和 C? 的坐標。 (3) 根據(jù)點 A的位置確定子彈是在 C 或者 C? 出現(xiàn)。 子彈的出現(xiàn)位置確定以后，下一步要確定子彈的初始速度，根據(jù)上一步求出的斜率 k 利用反正切方法可求解出 AOB? 的大小。則子彈的初始速度為： xV = 0 sinV AOB?? yV = 0 cosV AOB?? 根據(jù)以上分析子彈飛行的初始化工作已經(jīng)完成。在介紹子彈碰撞處理算法之基于 J2ME 的益智游戲的設計 20 前，首先定義方向向量：我們約定 1表示 X 軸、 Y 軸正方向， 1表示負方向。則方向向量 (1 , 1 ) , (1 , 1 ) , ( 1 , 1 ) , ( 1 , 1 )i j m n? ? ? ? ? ? ? ?可表 示 2D平面內(nèi)所有 X軸和 Y軸正負速度方向的組合。 其次 介紹子彈飛行過程中碰撞的處理算法。 (1) 第一種情況較為簡單即子彈和 MySprite 類型的子類之一馬匪碰撞。通過設置子彈的彈性系數(shù)可使子彈進行不改變運動方向的（子彈穿過馬匪）碰撞，算法結(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) 判斷子彈和物體的相對位置如圖 ： 圖 55 子彈和碰撞物體的相對位置示意圖 E點表示子彈的位置， A、 B、 C、 D 四個點表示剛體的四個頂點。首先，根據(jù)A、 B、 C、 D 四點的坐標求出直線 AC 、 BD 的方程 ，然后判斷 E 點和 O 點的相對位置。若 10xx? ，根據(jù)平面幾何知識，若 E 在 AOD? 內(nèi)部則 E 點的縱坐標 y1 一定滿足 213y y y??，子彈的 X 軸方向系數(shù) x_d 改變?yōu)?1。反之，若 E 在 O 左側(cè)即 n ，213y y y??，子彈的 X 軸方向系數(shù) x_d 改變?yōu)?1。若子彈既不在 AOD? 內(nèi)部也不在 BOC? 內(nèi)部則進行下一步判斷若 10yy? 則子彈在 P 點出現(xiàn)，子彈的 Y 軸方向系數(shù) y_d 變?yōu)?1,反之子彈在 Q 點出現(xiàn)， Y 軸 方向系數(shù) y_d 變?yōu)?1。特殊的四種情況Q(x5,y5) 21 是子彈在直線 AC 或者直線 BD 上時 ， 此處只列舉一種情況如圖 56所示： 圖 56 子彈方向改變的特殊情況 當子彈無論是以方向向量 m 還是方向向量 j 所示的方向和剛體相撞，都沿著方向向量 n 所指方向繼續(xù)飛行。算法結(jié)束。 (4) 根據(jù)圖 54 提示可知子彈的前進方向已經(jīng)不能通行，所以，子彈的 Y 軸方向系數(shù) y_d=1, X 軸方向系數(shù) x_d=1。其它情況類似，這里不再敘述。算法結(jié)束。 根據(jù)需求分析 ,物理模擬模塊的活動圖如圖 57所示： 圖 57 物理模擬模塊的活動圖 基于 J2ME 的益智游戲的設計 22 資源管理 資源管理實現(xiàn)資源的加載和釋放。資源的加載主要分為圖片資源、地圖文件、音樂文件。資源加載必須保證游戲的流暢性，所以，在資源被使用前就必須被加載到內(nèi)存中。若該資源不再被使用就必須釋放該資源所占用的內(nèi)存，提高內(nèi)存的利用效率。為了實現(xiàn)以上目的、資 源的加載分步驟進行： (1) 加載首頁中的圖片、音樂資源。 (2) 根據(jù)玩家選擇的選項菜單，決定是加載游戲的地圖、圖片等文件還是加載其它畫布的圖片。 (3)若游戲退出則釋放游戲中用到的資源如背景圖片、聲音文件、地圖中所用到的圖片等資源。 游戲狀態(tài)管理 游戲的狀態(tài)是繼續(xù)游戲、玩家勝利或玩家失敗。游戲狀態(tài)的判斷條件有： (1) 主角死亡。 (2) 主角還有子彈。 (3) 馬匪被全部被消滅 。 這三個條件組合起來就決定了游戲不同的狀態(tài)，在每一個游戲周期中，游戲狀態(tài)管理就會調(diào)用 checkGame()方法， 檢測游戲的狀態(tài)，然后再根據(jù)不同的狀態(tài)，調(diào)用 handleEvent()方法產(chǎn)生游戲狀態(tài)碼即三個整型變量 0,1,2。在程序中這三個整型變量分別用 Game_Continue， Game_Over、 Game_Success 表示。視圖層根據(jù)狀態(tài)碼響應不同的事件。當玩家勝利時，顯示勝利畫面即由 Simulation 畫布轉(zhuǎn)向EndCanvas 畫布并顯示勝利的對話框。在該對話框上，玩家可以選擇是繼續(xù)游戲、再玩一次或者選擇關(guān)卡。當玩家闖關(guān)失敗時，顯示 EndCanvas 畫布并顯示失敗的對話框。通過該對話框，玩家可以選擇重玩一次或者 選擇關(guān)卡。 動畫管理 動畫管理模塊負責將游戲中的場景、精靈、道具繪制到畫布中。由于手機內(nèi)存的限制和手機運算能力的限制，若游戲中大量使用空間較大的圖片就很有可能造成應用程序大于手機支持的應用程序最大內(nèi)存限制而不能在手機上安裝或運行，或者由于應用程序運行期間的內(nèi)存峰值大于手機的最大內(nèi)存限制，也會造成程序運行異常。所以，本系統(tǒng)采用關(guān)鍵幀方法實現(xiàn)動畫管理。 (1) 繪制原理 首先，將圖片整體讀入內(nèi)存。然后按照游戲需要繪制某一幀或某幾幀的圖片。 23 如圖 58 所示： 圖 58 馬匪圖片 在圖片進入內(nèi)存后每 一個圖片對應一個 Body類的對象或者 Body類的子類對象， Body 對象有位置信息即橫坐標 x，縱坐標 y，這兩個坐標確定圖片的位置。馬匪或者主角對象有是否或者的屬性，這個屬性確定圖片是否翻轉(zhuǎn)。所有圖片還會對應一個圖片數(shù)組，該數(shù)組依次保存圖片的大小，幀數(shù)，利用這個數(shù)組可以確定如何切割圖片即確定每一幀圖片。 繪制圖 片的時候要首先判斷馬匪的狀態(tài)，若馬匪的 isAlive 屬性為 true 則馬匪是活著的然后就繪制第一幀，若馬匪死亡，就根據(jù)馬匪是如何死亡的繪制第二幀圖片。例如：馬匪是被左邊的子彈擊中則馬匪就要向右側(cè)倒下，第二幀 圖片就要順時針旋轉(zhuǎn) 90度。最終要實現(xiàn)的效果如圖 59 所示： 圖 59 繪制靜止和死亡的精靈效果 (2) 繪制場景 綜合考慮關(guān)鍵幀繪制法和手機內(nèi)存和游戲資源的大小的限制。游戲中的一些圖片資源按照圖 58 所示的方式，進行了合并。圖片合并的方式是將同一個對象要用到的圖片，整合到一張圖片上，這樣就可以縮小圖片的總大小。 游戲中的場景分為三層：建筑層、道具層、精靈層。建筑層主要由墻壁和邊界這兩種對象組成。精靈層主要由馬匪和主角組成、道具層就要依據(jù)各個關(guān)卡的情況而定。主要的道具有鐵球、小木箱、大木箱等。繪制 這三層時必須協(xié)調(diào)才能完成場景的搭建。 這建筑層效果如圖 510 所示： 圖 510 建筑層的效果 第一幀 第二幀 基于 J2ME 的益智游戲的設計 24 精靈層如圖 511 所示： 圖 511 精靈層的效果 道具層的效果如圖 512 所示： 圖 512 道具層的效果 游戲主畫布會將這三層按照，建筑層、精靈層、道具層的順序進行繪制。首先，將加載完成的圖片對象有資源管理模塊傳遞給動畫管理模塊，然后該模塊使用 Graphic 類的實例調(diào)用 piant()方法將圖片繪制到畫布，這樣建筑層就繪制完成了。然后再依次繪制精靈層和道具層。最終完成游戲 場景的創(chuàng)建。這樣就滿足了根據(jù)游戲狀態(tài)繪制特定的圖片需求。游戲中還需要相應的字符提示玩家游戲的狀態(tài)。比如：現(xiàn)在游戲進行到第幾關(guān)、玩家還有幾發(fā)子彈。這些信息可以幫助玩家游戲。綜上，繪制完成的地圖效果如 圖 513 所示： 圖 513 第 2 關(guān)地圖效果 聲音管理 在 支持混音的手機上根據(jù)玩家的輸入播放相應的聲音。同時，手機也能播放背景音樂 。由于， MMAPI 各個產(chǎn)商實現(xiàn)的方式不同而且同一個產(chǎn)商如諾基亞， 25 實現(xiàn) MMAPI 的方式就不完全一 樣。所以，聲音管理是針對某一機型而言的。本游戲的聲音管理模塊 針對的是支持混音格式的手機 。 (1) 音樂播放原理 在 Java ME 里，聲音的處理是交給接口 Player 來處理的。 Player 把整個聲 音的播放過程看作是幾個狀態(tài)之間的變化 [11]如圖 514 所示： 圖 514 Player 狀態(tài)模型 當一個 Player 接口被創(chuàng)建時，處于 UNREALIZED 狀態(tài)，狀態(tài)之間可以通過消息改變。但是，有些手機的 Player 接口沒有實現(xiàn)全部的狀態(tài)。所以， Player 接口的具體實現(xiàn)是需要針對機型進行開發(fā)的。本游戲中首先判斷 Player 的狀態(tài)，然后再根據(jù)狀態(tài)模型決定如何改變 Player 的狀態(tài)，最終播放音樂。 播放前景音樂的活動圖如圖 515 所示： 圖 515 播放前景音樂的活動圖 基于 J2ME 的益智游戲的設計 26 播放背景音樂的活動圖如圖 516 所示： 圖 516 播放背景音樂的活動圖 游戲的實現(xiàn) 游戲框架的組織 (1) 加載資源 在游戲各 個模塊實現(xiàn)的 基礎上，就需要編寫 MI