程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> J2ME >> 合金彈頭技術文案

合金彈頭技術文案

編輯:J2ME

合金彈頭技術文案

平台:
利用System.getProperty("microedition.platform")來判斷平台類型

I/O
建立流連接的方式很奇怪,經過討論初步猜測是遇到了什麼技術問題因而寫出了這麼亂七八糟的代碼(源引Gameloft Lyman)
  protected final InputStream stream_create(String filename){
    InputStream in = getClass().getResourceAsStream(filename);
    while(in == null) in = getClass().getResourceAsStream(filename);
    return in;
  }

圖片利用GIF89a這種文件格式,下列代碼說明一定有圖片數據轉換工具可以隨意轉換圖片格式
      byte[] gifdata = new byte[readWord(in)];
      in.read(gifdata, 6, gifdata.length - 6);
      System.arraycopy("GIF89a".getBytes(), 0, gifdata, 0, 6);
      tank_face = Image.createImage(gifdata,0, gifdata.length);

動畫:
已經有了動作,幀和Module的概念,也有了碰撞盒子和攻擊盒子,但Module數量是寫死的,看來動畫工具還不夠完善

架構
process_set用來關閉狀態,轉狀態和初始化狀態,而且調用靈活,這種方式不錯
refresh分散在各函數調用,使得游戲結構分散不統一
按鍵處理在keyPressed直接處理,造成程序結構中有三處switch狀態處理,結構比較臃腫。有了key_Statuse把按鍵部分提出的做法,但還不徹底
mainmenu_execute的命名不錯,過去我都寫作chooseMenu,呵呵
沒有引擎類做支持
process_lock用來控制paint和run是否處理,CoCoMo認為沒有這個必要

聲音:
諾基亞的聲音,處理方式一般

游戲部分:
圖像動畫:
drawFace是游戲的主要圖像顯示函數,用alpha_draw裡用drawPixels來做淡入淡出是圖像顯示的亮點
已經有了hero_setaction的概念,但是因為架構在數組上的緣故,所以無法完全將所有Actor統一為setAction接口
在游戲中經常直接操作幀數據,未將動畫層完全分離
利用movi_create來創建動畫播放是一個比較好的做法

背景:
三層卷動,未用緩沖。back_draw用來畫天空背景,fact_draw_back用來畫底層地表Tile,fact_draw_fore用做遮擋主角的那部分Tile

關卡
游戲中人為將關卡分段,用plat_next來判斷讀取存儲在plat.bin中的關卡數據,這樣可以有效的降低內存占用量

碰撞檢測:
與地形的碰撞主要是采用grid_cellvalue函數來獲得,然後做判定、調整,例如:
    if(((grid_cellvalue(x, y - 1) ==  1) || (grid_cellvalue(x, y - 1) == 2)) &&
       (grid_cellvalue(x, y - 2) == 0)) hero_pos_y -= 8;
主角未與敵人做碰撞檢測,敵人間也可以互相穿梭,未作碰撞檢測,大大降低了游戲復雜度和碰撞檢測的花費
與道具的碰撞可能是為了加快速度,游戲中未使用統一碰撞函數,而是直接寫在各函數內,比如
      if((prop[PROP_POS_X] + (PROP_POS_W >> 1) > hero_pos_x - hero_frectw) &&
         (prop[PROP_POS_Y] > hero_pos_y - hero_frectt) &&
         (hero_pos_x + hero_frectw > prop[PROP_POS_X] - (PROP_POS_W >> 1)) &&
         (hero_pos_y + 11 > prop[PROP_POS_Y] - PROP_POS_H))
利用hero_nexus來做主角於子彈的碰撞檢測(為什麼不做統一碰撞檢測函數)
將各種類Actor分類寫在各Vector裡可以有效減少碰撞判定次數

AI:
敵人根據預先設好的模式屬性來做相應的AI,有主角靠近逃跑模式,來回移動等待攻擊模式,來回飛行攻擊模式等。根據自身模式屬性,大體依據與主角距離來產生相應動作。模式是游戲AI較常使用的方式。

技巧:
主角狀態常數,分兩部分,字節低位大狀態,高位字節小狀態。然後用&來與大狀態做運算,取小狀態的做法比較新穎
changeCRC和updateCRC用來計算圖片CRC校驗碼的方式比較實用

架構:
整個架構架構在數組之上,使用常量做標識,各個Actor更像是C語言裡的結構類型。

總的來講合金彈頭這個游戲寫的還是不錯的,注釋清楚,各狀態轉換明確,代碼層次結構清晰。但是由於主角未與敵人做碰撞檢測,敵人自身也未做碰撞檢測,游戲復雜度不高.與彩虹六號、第一滴血、帝國時代等差距相當明顯。目前國內的開發水平也可窺見一斑。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved