引言 各位作家創作時可能會覺得，他x的60X70或是100X42的地圖都太迷你了，不夠用啊。 與其去煩小哈，不如自己動手解決吧。無限地圖的槪念由此而生... ______________________________________________________________________________________________ 基本槪念 在同一個地圖上不斷移除和放置靜態地圖物件，以此塑造無限地圖的效果 (但這招不可用作地形如高山、窪地、河流) 除非你用一些特殊方法啦，如底下放木箱，上面的物件調成地版或調整色調等______________________________________________________________________________________________ 進階槪念-多人無限地圖(鷹眼的龍之旅) 就是當做放置4個單人的無限地圖在 一個任務裡面，不過要注意就是假如有玩家們前往了同一處地圖就要把他們放在一起。 ______________________________________________________________________________________________ 進階槪念 - 一事件載入地圖 - 極低容量弄無限地圖 邏輯一 - 地圖格網 這個邏輯在載入地圖時可能需要一點時間，同人陣推二維陣列不算快，碰上電腦性能較差的更GG (某FK相信真正推出市場的game都是這樣載入地圖的) 先弄N個二維的boolean (N=地圖物件類別的總數，n=地圖物件編號，mp=地圖編號) tile.{x}.{y}.{mp}.{n}=1即是在編號為mp的地圖上，座標為(x,y)上，有地圖物件n，0即是沒有 //建立資料庫 讀取地圖mp於區域z時則翻出[tile.{x}.{y}.{mp}.{n}]=>tn (需要n個檢查來儲存) //讀取資料庫，但四個{}真的很XX 地圖 locl.0=rubbish bin 地圖 locl.1=目標座標(如 loc.{x}.{y}.{z}) 放地圖物件n於 locl.{tn} //一事件多向輸出 x++; y+=x/width; x%=width; 例： 設：編號1的地圖物件是草、編號2的地圖物件是石 設地圖一的大小為10x10，輸出結束於座標：(0~9,0~9) 事件-地圖一資訊 //解說 1!=[null]=>tile.3.4.1.1 //宣告地圖一的(3,4)要放草 1!=[null]=>tile.6.9.1.2 //宣告地圖一的(6,9)要放石 1!=[null]=>tile.9.7.1.1 //宣告地圖一的(9,7)要放草 1!=[null]=>tile.9.7.1.2 //宣告地圖一的(9,7)同時要放石 事件-召喚載入 [call.map.push]==0 //檢查現在非載入地圖狀態 x=0 //重置x y=0 //重置y call.map.push=1 //標示目前為載入地圖狀態 call.map.push.id=1 //宣告載入的地圖為編號一，此處宜靈活變通~ 事件-地圖載入 [call.map.push]==1 //檢查現在是載入地圖狀態 [y]<10 //即是檢查現在地圖未載入完成 [call.map.push.id]!=[null]=>事件/mp //儲存載入的地圖編號 [tile.{x}.{y}.{mp}.1]!=[null]=>事件/tn1 //儲存(x,y)是否要放草 [tile.{x}.{y}.{mp}.2]!=[null]=>事件/tn2 //儲存(x,y)是否要放石 loc.0=堆填區 //一事件多向輸出，定義負輸出目標位置 loc.1="%{x}%,%{y}%" //一事件多向輸出，定義正輸出目標位置為(x,y)，請用字串執行本動作 放草於 loc.{tn1} //一事件多向輸出 放石於 loc.{tn2} //一事件多向輸出 x=x+1; //地圖陣列演算法 y.plus=x/10; //地圖陣列演算法 y=y+y.plus //地圖陣列演算法 x=x%10; //地圖陣列演算法 事件-載入結束 [call.map.push]==1 //檢查現在是載入地圖狀態 [y]>=10 //即是檢查現在地圖已載入完成 call.map.push=0 //標示目前非載入地圖狀態 ____________________________________________________________________________________________ 邏輯二 - 物件陣列 這個邏輯雖然載入會較快，但就會比較辛苦作者 先用一些事件儲存各地圖的靜態地圖物件的座標、種類為陣列 再順序讀取陣列 光說也說不清= =，給個例子吧，與上面一樣的 例： 定義loc.1=堆填 區；loc.2=堆填區 事件-地圖一資訊 4!=[null]=>map.1.itemSum //地圖一的地圖物件總數被儲存為4 3!=[null]=>map.1.item.1.x //儲存第一個地圖物件的x座標為3。 4!=[null]=>map.1.item.1.y //儲存第一個地圖物件的y座標為4。 1!=[null]=>map.1.item.1.type //儲存第一個地圖物件的種類為草 6!=[null]=>map.1.item.2.x //儲存第二個地圖物件的x座標為6。 9!=[null]=>map.1.item.2.y //儲存第二個地圖物件的y座標為9。 2!=[null]=>map.1.item.2.type //儲存第二個地圖物件的種類為石 9!=[null]=>map.1.item.3.x //儲存第三個地圖物件的x座標為9。 7!=[null]=>map.1.item.3.y //儲存第三個地圖物件的y座標為7。 1!=[null]=>map.1.item.3.type //儲存第三個地圖物件的種類為草 9!=[null]=>map.1.item.4.x //儲存第四個地圖物件的x座標為9。 7!=[null]=>map.1.item.4.y //儲存第四個地圖物件的y座標為7。 2!=[null]=>map.1.item.4.type //儲存第四個地圖物件的種類為石 事件-召喚載入 [call.map.push]==0 //檢查現在非載入地圖狀態 call.map.push=1 //標示目前為載入地圖狀態，下面順道拿來讀取地圖物件 call.map.push.id=1 //宣告載入的地圖為編號一，此處宜靈活變通~ 事件-地圖載入 [call.map.push]!=0 //檢查現在是載入地圖狀態 [call.map.push.id]!=[null]=>事件/mp //儲存載入的地圖編號 [call.map.push]<=[map.{mp}.itemSum]=>事件/n //檢查現在地圖未載入完成，順道儲存目前讀取的編號 [map.{mp}.item.{n}.x]!=[null]=>任務/x //讀取並儲存地圖物件的x座標為x [map.{mp}.item.{n}.y]!=[null]=>任務/y //讀取並儲存地圖物件的y座標為y [map.{mp}.item.{n}.type]!=[null]=>事件/tn //讀取並儲存地圖物件的種類座標為tn loc.{tn}="%{x}%,%{y}%" 放草於 loc.1 //一事件多向輸出 放石於 loc.2 //一事件多向輸出 loc.{tn}=堆填區 call.map.push=call.map .push+1 事件-載入結束 [call.map.push]!=0 //檢查現在是載入地圖狀態 [call.map.push]>[map.{mp}.itemSum] //即是檢查現在地圖已載入完成 call.map.push=0 //標示目前非載入地圖狀態 _______________________________________________________________________________________________ 兩個邏輯的比較 很明顯，在定義時，邏輯2所花的精力明顯比較多，容量也會花得比較多(雖然每30項定義才1容量) 不過，在上面的例子中，邏輯1要運算100次才運算完成，但邏輯2只需4次 (所以某FK會用邏輯二，同時讓電腦自行隨機繪畫地圖，省時又省力) 各位自行斟酌採納吧 _______________________________________________________________________________________________ 隨機地圖(Random Map) |
地圖 >