※ [本文轉錄自 mud 看板 #1Jg2SBt1 ]
作者: laechan (小太保) 看板: mud
標題: Re: [閒聊] tmi2-mudlib 的更改
時間: Mon Jun 23 21:09:27 2014
聊一下 map 跟一些東西。
> data me
map : ({ })
map_record : ([ "redant" :
"7680,992,7,0,1020,3,7936,384,254,7,7936,510,31,7168,0,0,0,0
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0" ])
me->query("map_record/redant") 是一個字串，將它做 htoa:
write(htoa(me->query("map_record/redant"))+"\n");
4-1=11
8-1=111
.
.
8192-1=1111111111111 13個1
1111000000000 = 2^12+2^11+2^10+2^9 = 4096+2048+1024+512 = 7680
拆到最後不足 13 格的房間就自動把不足的當成 0
這樣 52 格以內的區域只需要 xxxx,xxxx,xxxx,xxxx 四組數，就能
存該玩家是否有在該地圖的什麼房間走過。
我上面的做法則應該是把 redant 當成一個大區域，它會自動判斷
數組幾到幾是第一層，幾到幾是地二層，etc...實際上自動判斷是
必然的，因為假設我第一層房間編號是001-135，第二層就是136開
始，雖然地圖有三張，實際上編號是連續的。
========== 程式執行區 ==========
111100000000000011111000000000000000111000000000000000011111
111000000000000011111110000000000001100000000000011111110000
000000011111111000000000000111111110000000001111111100000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000
========== 程式執行區 ==========
上面字串的長度共 475，「剛好」炙蟻地獄也是 001.c～475.c。
"1" 就是代表玩家有走過那格，"0" 就是代表玩家還沒走過那格。
所以看到前面四個 1，就代表玩家走過 001.c～004.c。
那麼就取字串前面幾個 01 為例，底下假設兩位玩家
A 玩家: 1111010011110101011010...
B 玩家: 0100100001010101010101...
則當 A 玩家將他的地圖 share 給 B 玩家時，B 玩家就變成底下
A 玩家: 1111010011110101011010...
B 玩家: 0100100001010101010101...
===================================
B 玩家: 1111110011110101011111...
也就是說當 A 玩家某一格有走過、而 B 玩家該格沒走過時，則當
A 玩家將自己的地圖 share 給 B 玩家時，B 玩家該格經過 0 與
1 的 OR 運算後就會變成 1。
那麼，當字串變成 "111111........111" 也就是全部都是 1 時呢
，這時會做底下兩件事:
me->delete("map_record/redant");
me->add("map",({"redant"}));
也就是說，玩家已經不再需要做「走過該地圖哪些點的紀錄」，因
此就把 map_record 刪掉，接著，玩家等於得到了完整的地圖，因
此就把 "redant" add 到 map 裡面。
假設 A 玩家已得到該張地圖，則:
A 玩家 share 地圖給 B 玩家 => B 玩家也是做上述兩件事
B 玩家 share 地圖給 A 玩家 => 什麼事也不會發生
我做這項設計，我最重要的目的，就是想賦予遊戲遊玩性。因為地
圖是可以改的，比方底下的圖
起-x x-終 起-x-x 終
| | | |
x-x x-x → x x x-x
| | | | |
x-x-x-x x-x-x-x
格數完全一樣，起點也一樣，終點也一樣，路線卻不同，我說過管
理者要修改 mapx 的圖很容易，修改後透過 trans，就能依修改過
的圖重新產生出區域，這時候原先公布在 BBS、公布在網路上的所
謂「這個區域這一層的地圖」馬上作廢。
可是對實際進行遊戲的玩家來說:
已攻略完這張地圖的玩家 → 沒影響，map 一按新地圖就出來
未攻略完這張地圖的玩家 → 已攻略的格子數量沒變
甚至起點一樣，但是終點變換也是可以的。實際開過 mapx 圖出來
看過的人應該知道，要變換路線只要動動手指非常簡單就能辦到，
然後可能尚未攻略完成的玩家，他的機器人就得重寫這類的。
這樣對已攻略完該地圖的玩家來說，他就會認為他「永久擁有」著
一些獨特的東西，而且這東西是可以隨自己的心情看要不要 share
給尚未擁有這東西的人的，然後他越用心就能擁有越多，甚至他還
可以把目標放在完全攻略上。
遊戲性在哪裡呢？比方攻略組要找出 BOSS 房間在哪，這時有個玩
家在攻略一個七層的迷宮的最底部時，終於被他發現了 BOSS 房間
的標記，他用 chat 大喊說恁北找到 BOSS 房間了！
這時他的這份地圖就是所謂「最有價值的地圖」。
以上是我的想法。
使用者不必然要照我的想法，例如我自己在 sanc 所做的設計，就
是把圖全開給玩家看，我也鼓勵玩家多多寫 sanc 的相關攻略。
我下一階段要做的就是弄出「城村鎮區域生產組合」，它一樣會透
過 x-x、一樣會透過 area_room.X 及 script_X 這六個元素去做，
城村鎮區域的地圖就不是上述的做法，而會採取我新寫好的 map，
也只有城村鎮的地圖我會讓它一直維持固定。
因為城村鎮是冒險途中拿來休息用的，而不是拿來攻略的，不過，
城村鎮會有些任務，是必然的，這也是下一階段要釋出的重點，也
就是任務腳本系統，然後跟地圖系統一樣，任務腳本也是網路隨便
搜就一大堆給你看，於是:
當網路能搜到一堆地圖 -> x-x 化 -> 變成 mud 內的區域
當網路能搜到一堆任務 -> 腳本化 -> 變成 mud 內的任務
當網路能搜到一堆○○ -> OOXX化 -> 變成 mud 內的東西
這就是 tmi2_v3_改 想要達成的理想，在達到這個理想之前，我都
會一直改下去。