這東西我在 tmi2_v3_改 實驗過確認是可行的。 以炙蟻地獄區域為例，底下是該區域的其中一個房間的資料: > da here Object : 房間(/u/p/ppl/hiei/redant/010) exits : ([ "south" : "/u/p/ppl/hiei/redant/026", "west" : "/u/p/ppl/hiei/redant/009" ]) exits_color :"1;31m" light : 1 long : "洞穴十分狹小，你得屈著身體才能前進，嘎吱嘎吱的走動聲音 不\n時悠q洞穴的深處傳來，在洞穴裡久居的怪物，對於自己送上門來\n的食物想必 感到非常興奮吧『C\n\n" reborn_times :1463620349 room_file :"010" short : "炙蟻地穴-第一層" 以艾恩葛朗特的區域為例，因為預設其會有 100 層區域(實際 99 層)， 因此區域目錄的形式會如下圖: /u/s/sao/層數編號/區域編號/段數編號/ 例如起始城鎮的第一格房間檔: /u/s/sao/01/01/1/001.c 未來則會有個 區域名→編號編碼 的對照資料，因此實際上，該地圖資 料被儲存於玩家資料區的情況如下: maps : ([ "層數編號" : ([ "區域編號-段數編號" : "字串值", ]), ]); 區域有分段(層)的情況下，我是預設最多不會超過 512 個房間，因此， 假設最多 512 個房間，每個房間有無走過的情況用 0 與 1 來區別時: 11111111111111111001010010010101010000101..............01001010 長度共 512 取前八個 11111111 為例，如果假設它是一個二進制的東西時: (11111111) = 255 (三位數) 2 10 則上面的長度 512 的東西可拆解為 "255,......"，長度就變為: 512/8 = 64, 64x(3+1)-1 = 255 從上面大致可發現「取越長的段落來做 2→10 進位會越有利」。 比方我們取前 16 個 1111111111111111 (1111111111111111) = 65535 2 10 則上面的長度 512 的東西可拆解為 "65535,...."，長度就變為: 512/16 = 32, 32x(5+1)-1 = 191 那麼實務上的做法是如何呢？它首先會讀入該區域總共有幾格的資 料，會先得到一個 n，接著判斷玩家有沒有該區域資料字串值，沒 有的話就先產生出來: for(i=0;i<n;i++) str+="0"; 接著，假設玩家進去該區域的第一個房間編號是 k: str[k-1]='1'; 接著對這個 str 做拆解: for(i=0;i<n;i=i+16) { if(i+15>=n) tmp=str[i..n-1]; else tmp=str[i..i+15]; x=hex10(atoi(tmp)); new_str+=x+","; } 這樣 new_str 就是上面的 "65535,..." 這樣的形式。 拆解的方式很多，事實上我不認為這是最理想的，理論上應該有更 佳的做法，兼顧可容許的字串長度以及可負荷的換算複雜度。 (例如 "717277566556262511" 這樣的字串形式理論上也可行) 寫上面那些東西的目的在證明依目前聖殿現有的系統架構，就可以 實現變動式地圖資料及地圖分享，而不需從 tmi2_v3_改 調用。 (當然，我會把它侷限在只能使用於艾恩葛朗特) laechan --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.224.52.60 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/mud_sanc/M.1463624170.A.AC6.html