地圖工坊怎麼用 - 守望先鋒地圖工坊教程
守望先鋒是一款非常火爆的FPS加MOBA的結合類遊戲,遊戲的人物設定精美,玩法緊張刺激,同時售價也不高,一經推出就收到了非常大的歡迎。很多玩家不知道守望先鋒地圖工坊教程,來看看地圖工坊怎麼用。
《守望先鋒》地圖工坊教程
本文的目標物件,是已經有一定地圖工坊編寫經驗的朋友。如果你並不熟悉,建議你閱讀其他教程。例如:
[零基礎入門教程]
[在地圖工坊中從零開始創造“生化模式”]
引言
相對於一門程式語言來說,地圖工坊的功能其實非常基礎。它沒有函式,更別提類了。不過,不知道你是否注意到,持續事件有一個特性:它可以持續等待,直到條件為真。
程式設計裡面有一個“設計模式”,叫做“觀察者模式”。它的意思是:當一個物件變化時,會自動通知依賴它的物件。
看到這裡,不知道你有沒有覺得,持續事件和觀察者模式是有一定相似之處的:它們都是在“等”一個東西。
簡化規則
這個東西有什麼用?我們可以藉此來簡化規則的編寫。例如,我們要做一個等級系統,當經驗達到100的時候就升一級,死亡的時候就掉50%經驗,如果經驗是負了,就掉一級。
我們的經驗來源可能不止一種,例如在RPG模式裡,我們擊殺敵人可以獲得經驗,摧毀防禦塔也可以獲得經驗。當我們用傳統辦法寫規則的時候,我們就需要:
擊殺敵人:增加經驗,如果經驗>100,增加等級,修改等級BUFF
摧毀防禦塔:增加經驗,如果經驗>100,增加等級,修改等級BUFF
死亡:減少經驗,如果經驗<0,減少等級,修改等級BUFF
你有沒有覺得,這是一個繁瑣的過程?當你需要修改等級BUFF的時候,你需要修改很多條規則。
我們再分析一下我們的邏輯:實際上,等級什麼時候會增加,增加會有什麼效果,這並不是我們的“死亡”事件該處理的。
正確的做法是:有一個東西在“看著”經驗,當它大於100時,就代表升級了。當它小於100時,就代表降級了。我們將其解耦後,規則就變成了:
擊殺敵人:增加經驗
摧毀防禦塔:增加經驗
死亡:減少經驗
觀察者1:如果經驗>100,增加等級,修改等級BUFF
觀察者2:如果經驗<0,減少等級,修改等級BUFF
換做遊戲內規則,即是:(假設用玩家變數A表示等級,玩家變數B表示經驗)
擊殺敵人:修改玩家變數(事件玩家, B, 加, 50)
摧毀防禦塔:修改玩家變數(事件玩家, B, 加, 30)
死亡:修改玩家變數(事件玩家, B, 減, 50)
觀察者1
事件:持續 - 每名玩家
條件:玩家變數(事件玩家, B) >= 100
動作:
修改玩家變數(事件玩家, B, 減, 100)
修改玩家變數(事件玩家, A, 加, 1)
// 這裡寫等級變化的邏輯
等待(0.016, 無視條件)
如條件為“真”則迴圈
觀察者2
事件:持續 - 每名玩家
條件:玩家變數(事件玩家, B) < 0
動作:
修改玩家變數(事件玩家, B, 加, 100)
修改玩家變數(事件玩家, A, 減, 1)
// 這裡寫等級變化的邏輯
等待(0.016, 無視條件)
如條件為“真”則迴圈
注意:
一定要注意邏輯設計上不能存在無窮迴圈,例如上面的例子裡,觀察者2的條件不能寫“玩家變數 <= 0”。因為當玩家經驗=100時,觀察者1會將其變為0,就會觸發觀察者2。而觀察者2又會再次觸發觀察者1。這就導致了無窮迴圈的出現。
我們在兩個觀察者最後都加上了迴圈,目的是打破條件滿足的情況。考慮這種情況:當我們一次性給玩家增加300點經驗時,按理來說,應該讓玩家升3級,但因為我們沒有迴圈,玩家升了一級就結束了,並且後續增加經驗,也不會再觸發升級。只有當條件滿足被打破時,條件再次滿足,才會再次觸發該規則。
模擬函式呼叫
程式設計總是免不了函式,但目前為止OW中沒有函式。但是,我們可以使用上面的方法,來模擬函式。
還是用上面的例子。你會發現我們的等級變化邏輯還是寫了兩遍。我們能不能再將其獨立成一個規則?當然是可以的。我們變化的目標是玩家,因此我們需要使用一個玩家變數,來標記我們需不需要對此玩家執行等級變化邏輯。假設我們使用玩家變數C。
首先,在遊戲初始化的時候,將其設定為假。我們的規則就可以變成:
觀察者1
事件:持續 - 每名玩家
條件:玩家變數(事件玩家, B) >= 100
動作:
修改玩家變數(事件玩家, B, 減, 100)
修改玩家變數(事件玩家, A, 加, 1)
等待(0.016, 無視條件)
如條件為“真”則迴圈
設定玩家變數(事件玩家, C, 真)
觀察者2
事件:持續 - 每名玩家
條件:玩家變數(事件玩家, B) < 0
動作:
修改玩家變數(事件玩家, B, 加, 100)
修改玩家變數(事件玩家, A, 減, 1)
等待(0.016, 無視條件)
如條件為“真”則迴圈
設定玩家變數(事件玩家, C, 真)
等級變化規則
事件:持續 - 每名玩家
條件:玩家變數(事件玩家, C) == 真
動作:
// 這裡寫等級變化的邏輯
設定玩家變數(事件玩家, C, 假)
注意:這裡只是模擬函式呼叫,但實際上它比函式還是少很多東西。因此,並不是所有情況都適合這樣寫。
總結
本文其實並沒有用什麼很稀奇古怪的技術,但本文的難點是思路的轉變:你需要將幾個本來不相同的邏輯,找出他們的共同點,並巧妙的將其拆分成多個邏輯,然後用規則來實現。
到底要不要使用這種方式來設計規則?你需要考慮它的優缺點。它的優點有:
將重複的內容獨立出來,減少工作量。
方便以後的修改(不僅需要修改的地方少了,漏改的可能性也更小了)
它也有缺點:
增加了規則數量。
增加了邏輯上的複雜度。
執行效率稍低。
個人認為,適當的使用這種思路來設計規則,可以減少你的工作量和維護難度。但並不代表這種方式一定就是最好的,你應當考慮你的實際情況。