分散式系統期未專題書面報告<<炸彈超人>>R89725010游景麟R89725012許家瑞R89725016黃耿典炸彈超人簡介炸彈超人是一個流行的遊戲，玩家可場景內任意的放置炸彈攻擊對手，同時也要小心對手的炸彈爆炸。當炸彈爆炸時，會有一定距離的火焰從炸彈射出，萬一被火焰碰到就算死一次。而遊戲勝負就由玩家的戰績決定，看誰炸死別人最多次，自己死最少次!因此遊戲進行中，玩家不但需要按空白鍵放炸彈，也需要按方向鍵閃避炸彈，十分刺激。另外，炸彈也可以用來炸開磚牆，在磚牆內可能會有各式的寶物，可以增強玩家的能力，如:增加火焰距離、踢炸彈，因此玩家也需要搶奪寶物。這個部分的困難主要在事件的同步，對全部的玩家對遊戲狀態的認知一致，如:移動、爆炸、搶寶物…。以爆炸為例，我們必須告知對手炸彈爆炸，並且要決定是否有對手被炸死，而這個同時對手是不斷在移動的!而搶寶物則是變型的mutualexclusion問題。因為我們採用peertopeer架構，使得問題比client-server架構難解決。遊戲一開始，玩家可選擇自己開始一場新遊戲，或選擇加入別人的遊戲中。若玩家可選擇自己開始一場新遊戲，他需要輸入一些資料，如:multicastaddress、port、玩家匿稱、遊戲代號，接著玩家就可以開始進行遊戲，不過當然只有自己玩，等著別人加入。玩家若選擇加入別人的遊戲中，則可先透過multicast得知目前所有的遊戲，再選擇其中一個加入。這個部分的困難主要在於reliable、causalordermulticast的實作，及View-synchronousgroupcommunication。不過，我們認為採用IPmulticast是最大的錯誤，因為IPmulticast太不可靠!!另外，一旦網路發生partition時，group會分成兩半，兩邊的玩家各自進行遊戲。而網路恢復後，兩邊的的遊戲狀態一定不相同，其中最大的問題在於地圖因炸彈的破壞而產生不一致。我們取法coda，由玩家自行解決地圖不一致的問題。利用MapEditor讓所有玩家在一定時間內一起修改地圖，再用這份地圖重新開始遊戲。接下來，我們簡述各部份的實作及架構，主要分為AtomicBomberman部分和MapEditor部分。AtomicBomberman部分：3D遊戲介面：以Sun所提供的Java3D作為3Dprogramming的介面，Java3D提供了一般3Dprogramming需要的基本功能，例如：3D物件的產生、設定，物件的transformation、rendering，讓做3Dprogrammer不需要從最基本的矩陣運算開始做起，而可以把注意力集中在比較高階的功能。在Java3D之中，thread的生成以及jobscheduling是系統自動做的，因此programmer只要將場景的hierarchy設定好，各個事件的引發條件為何便可。Java3D會將上層的動作中，OpenGL有支援的部分往底層呼叫，如果有OpenGL加速的硬體，就可以加速rendering的動作。遊戲音樂及音效：使用Java所提供的AudioClip播放，使用的聲音檔格式是Sun的.au檔，每播放一段clip便需要產生一支新的thread，才不會block住其他的動作，聲音撥完之後thread便自動消滅，但遊戲的背景音樂由於是不斷重複播放，因此會一直存在。若同時有數個聲音檔在播放中，底層的硬體會做混音的動作。遊戲流程與資料：共計：[場景管理]、[人物管理]、[炸彈管理]、[地圖管理]、[遠端事件管理]等五個主要部分：[場景管理]：處在一個整合的角色，負責各原件間的事件互動，並提供其他原件一個整合的介面。[人物管理]：負責維護人物各項資訊，且會有另一Thread來維護本身的時效性屬性。[炸彈管理]：負責管理炸彈的生成、移動、爆炸等事件，一樣會有Thread負責其自發性的改變。[地圖管理]：負責維護地圖資料，提供存取地圖資料的唯一途徑，避免因競爭造成的錯誤；另提供事件檢查機制，可提高事件發生的判斷效率。[遠端事件管理]：提供和管端系統雙向的溝通管道，處理的項目包括：人物、炸彈、地圖、聊天室資料的更新，死亡、踢炸彈事件的宣布，新增、移除玩家的機制，另外，為避免兩個玩家同時搶奪一個寶物，採用類似RicartandAgrawala的演算法來解決衝突（先利用地圖資料篩選可能的競爭者）。總計訊息的種類有十四種之多。IPMulticast:底層實作了reliable及causalorderIPMulticast。Causalorder主要利用vectortimestamp來達成。而reliable則是利用ack及nack，causalorder機制中的vect