守望先鋒地圖工坊教程，地圖工坊怎麼用

守望先鋒是一款非常火爆的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, 假)

注意：這裏只是模擬函數調用，但實際上它比函數還是少很多東西。因此，並不是所有情況都適合這樣寫。

總結

本文其實並沒有用什麼很稀奇古怪的技術，但本文的難點是思路的轉變：你需要將幾個本來不相同的邏輯，找出他們的共同點，並巧妙的將其拆分成多個邏輯，然後用規則來實現。

到底要不要使用這種方式來設計規則？你需要考慮它的優缺點。它的優點有：

將重複的內容獨立出來，減少工作量。

方便以後的修改(不僅需要修改的地方少了，漏改的可能性也更小了)

它也有缺點：

增加了規則數量。

增加了邏輯上的複雜度。

執行效率稍低。

個人認爲，適當的使用這種思路來設計規則，可以減少你的工作量和維護難度。但並不代表這種方式一定就是最好的，你應當考慮你的實際情況。