之前大家为大伙带来了守望先锋地图工坊的新手教程，而今天，为大伙带来的是玩家泷涯撰写的守望先锋地图工坊进阶课程，一块儿看看吧。

推荐阅读：

守望先锋地图工坊菜鸟基础知识零基础入门教程

守望先锋地图工坊应用察看者模式思想课程

本文的目的对象，是已经有肯定地图工坊撰写经验的朋友。假如你并不熟知，建议你阅读其他课程。

引言​

相对于一门编程语言来讲，地图工坊的功能其实很基础。它没函数，更别提类了。不过，不了解你是不是注意到，持续事件有一个特质：它可以持续等待，直到条件为真。

编程里面有一个设计模式，叫做察看者模式。它的意思是：当一个对象变化时，会自动公告依靠它的对象。

看到这里，不了解你有没感觉，持续事件和察看者模式是有肯定相似之处的：它们都是在等一个东西。

简化规则

这个东西有哪些用？大家可以借此来简化规则的撰写。比如，大家要做一个等级系统，当经验达到100的时候就升一级，死亡的时候就掉50%经验，假如经验是负了，就掉一级。

大家的经验来源可能不止一种，比如在RPG模式里，大家击杀敌人可以获得经验，摧毁防御塔也可以获得经验。当大家用传统方法写规则的时候，大家就需要：

1.击杀敌人：增加经验，假如经验100，增加等级，修改等级BUFF

2.摧毁防御塔：增加经验，假如经验100，增加等级，修改等级BUFF

3.死亡：降低经验，假如经验0，降低等级，修改等级BUFF

你有没感觉，这是一个繁琐的过程？当你需要修改等级BUFF的时候，你需要修改不少条规则。

大家再剖析一下大家的逻辑：事实上，等级什么时间会增加，增加会有哪些成效，这并非大家的死亡事件该处置的。

正确的做法是：有一个东西在看着经验，当它大于100时，就代表升级了。当它小于100时，就代表降级了。大家将它解耦后，规则就变成了：

1.击杀敌人：增加经验

2.摧毁防御塔：增加经验

3.死亡：降低经验

4.察看者1：假如经验100，增加等级，修改等级BUFF

5.察看者2：假如经验0，降低等级，修改等级BUFF

换做游戏内规则，即是：(假设用玩家变量A表示等级，玩家变量B表示经验)

1.击杀敌人：修改玩家变量(事件玩家, B, 加, 50)

2.摧毁防御塔：修改玩家变量(事件玩家, B, 加, 30)

3.死亡：修改玩家变量(事件玩家, B, 减, 50)

察看者1

1.事件：持续 - 每名玩家

2.条件：玩家变量(事件玩家, B) = 100

3.动作：

修改玩家变量(事件玩家, B, 减, 100)

修改玩家变量(事件玩家, A, 加, 1)

// 这里写等级变化的逻辑

等待(0.016, 无视条件)

如条件为真则循环

察看者2

1.事件：持续 - 每名玩家

2.条件：玩家变量(事件玩家, B) 0

3.动作：

修改玩家变量(事件玩家, B, 加, 100)

修改玩家变量(事件玩家, A, 减, 1)

// 这里写等级变化的逻辑

等待(0.016, 无视条件)

如条件为真则循环

注意：

必须要注意逻辑设计上不可以存在死循环，比如上面的例子里，察看者2的条件不可以写玩家变量 = 0。由于当玩家经验=100时，察看者1会将它变为0，就会触发察看者2。而察看者2又会第三触发察看者1。这就致使了死循环的出现。

大家在两个察看者最后都加上了循环，目的是打破条件满足的状况。考虑这样的情况：当大家一次性给玩家增加300点经验时，按理来讲，应该让玩家升3级，但由于大家没循环，玩家升了一级就结束了，并且后续增加经验，也不会再触发升级。只有当条件满足被打破时，条件第三满足，才会第三触发该规则。

模拟函数调用

编程一直免不了函数，但现在为止OW中没函数。但，大家可以用上面的办法，来模拟函数。

还是用上面的例子。你会发现大家的等级变化逻辑还是写了两遍。大家能否再将它独立成一个规则？当然是可以的。大家变化的目的是玩家，因此大家需要用一个玩家变量，来标记大家需无需对此玩家实行等级变化逻辑。假设大家用玩家变量C。

第一，在游戏初始化的时候，将它设置为假。大家的规则就能变成：

察看者1

1.事件：持续 - 每名玩家

2.条件：玩家变量(事件玩家, B) = 100

3.动作：

修改玩家变量(事件玩家, B, 减, 100)

修改玩家变量(事件玩家, A, 加, 1)

等待(0.016, 无视条件)

如条件为真则循环

设置玩家变量(事件玩家, C, 真)

察看者2

1.事件：持续 - 每名玩家

2.条件：玩家变量(事件玩家, B) 0

3.动作：

修改玩家变量(事件玩家, B, 加, 100)

修改玩家变量(事件玩家, A, 减, 1)

等待(0.016, 无视条件)

如条件为真则循环

设置玩家变量(事件玩家, C, 真)

等级变化规则

1.事件：持续 - 每名玩家

2.条件：玩家变量(事件玩家, C) == 真

3.动作：

// 这里写等级变化的逻辑

设置玩家变量(事件玩家, C, 假)

注意：这里只不过模拟函数调用，但事实上它比函数还是少不少东西。因此，并非所有状况都合适如此写。

总结

本文其实并没用什么非常稀奇古怪的技术，但本文的难题是思路的转变：你需要将几个本来不相同的逻辑，找出他们的一同点，并巧妙的将它拆分成多个逻辑，然后用规则来达成。

到底需不需要用这种方法来设计规则？你需要考虑它的优势和弊端。

优点有：将重复的内容独立出来，降低工作量，便捷未来的修改(不只需要修改的地方少了，漏改的可能性也更小了)。

它也有缺点：增加了规则数目，增加了逻辑上的复杂度，运行效率稍低。

我认为，适合的用法这种思路来设计规则，可以降低你的工作量和维护困难程度。但并不是这种方法肯定就是最好的，你应当考虑你的实质状况。

Tags：