之前我们给大家带来的是守望先锋地图工坊的零基础入门教程，而今天给大家带来的是玩家 龙牙 写守望先锋地图工坊进阶教程。让我们看一看。
推荐阅读:
守望先锋地图工坊零基础入门教程
守望先锋地图工作坊观察者模式应用教程
本文的目标对象是有一定地图工作坊编制经验的朋友。如果不熟悉，建议你看其他教程。
介绍
相比一门编程语言，地图工坊的功能其实是很基础的。它没有函数，更不用说类了。然而，我不知道你是否注意到了，持久事件有一个特征:它可以等到条件为真。
编程中有一个 设计模式；，名为 观察者模式 。这意味着当一个对象改变时，它会自动通知依赖它的对象。
看到这里，我不知道你是否认为持续事件和观察者模式有一些相似之处:它们都在 等等 一件事。
简化规则
这东西有什么用？我们可以用这个来简化规则的编译。比如我们要做一个等级制度。经验达到100，就升一级；当我们死的时候，我们会失去50%的经验；如果我们的经验是负面的，我们将失去一个层次。
我们经验的来源可能不止一个。比如在RPG模式下，我们可以通过击杀敌人和摧毁防御塔来获得经验。当我们以传统方式编写规则时，我们需要:
1.杀敌:增加经验，如果经验>:00，增加等级，修改等级BUFF。
2.摧毁防御塔:增加经验，如果经验>:00，增加等级，修改等级BUFF。
3.死亡:减少经验，如果经验
你觉得这是一个繁琐的过程吗？当你需要修改等级BUFF的时候，你需要修改很多规则。
再来分析一下我们的逻辑:其实水平什么时候提高，有什么效果都不是我们的 死亡 此事件的。
正确的做法是:有东西在 看看 经验，大于100的时候，意味着升级。当它小于100时，意味着退化。在我们分离它之后，规则变成:
1.杀敌:增加经验。
2.摧毁防御塔:增加经验
3.死亡:减少经验
4.观察者1:如果经验>:00，增加等级，修改等级BUFF。
5.观察者2:如果经验值< 0，降低等级，修改等级BUFF。
换做游戏内规则，即是：(假设用玩家变量A表示等级，玩家变量B表示经验) 1。杀死敌人:修改玩家变量(事件玩家，B，plus，50)2.摧毁防御塔:修改玩家变量(事件玩家，B，plus，30)
3.死亡:修改玩家变量(事件玩家，B，减50)
1名观察员
1.事件:连续-每个玩家
2.条件:玩家变量(事件玩家，B) >: = 100
3.行动:
修改玩家变量(事件玩家，B，负，100)
修改玩家变量(事件玩家，A，加号，1)
//这里写等级变化的逻辑
等待(0.016，不考虑条件)
如果条件是 True 然后循环
2名观察员
1.事件:连续-每个玩家
2.条件:玩家变量(事件玩家，b) < 0
3.行动:
修改玩家变量(事件玩家，B，plus，100)
修改玩家变量(事件玩家，A，minus，1)
//这里写等级变化的逻辑
等待(0.016，不考虑条件)
如果条件是 True 然后循环
注意:
必须注意，逻辑设计不能有死循环。例如，在上面的例子中，观察者2的条件不能写成 玩家变量
为了打破满意的条件，我们在两个观察者的末尾添加了一个循环。考虑这种情况:当我们一次性给玩家增加300点经验，让玩家升到3级是合理的，但是因为我们没有循环，玩家升到1级就结束了，后续增加的经验不会再次触发升级。只有当条件满足被打破，再次满足条件时，才会再次触发规则。
模拟函数调用编程总是会涉及到函数，但是到目前为止OW里还没有函数。但是，我们可以使用上述方法来模拟函数。
还是用上面的例子。你会发现我们的层次变化逻辑写了两遍。我们能再把它变成一条规则吗？是的，当然。我们改变的目标是玩家，所以我们需要使用一个玩家变量来标记我们是否需要为这个玩家执行等级改变逻辑。假设我们使用了玩家变量c。
首先，当游戏初始化时，它被设置为false。我们的规则可以变成:
1名观察员
1.事件:连续-每个玩家
2.条件:玩家变量(事件玩家，B) >: = 100
3.行动:
修改玩家变量(事件玩家，B，负，100)
修改玩家变量(事件玩家，A，加号，1)
等待(0.016，不考虑条件)
如果条件是 True 然后循环
设置播放器变量(事件播放器，C，true)
2名观察员
1.事件:连续-每个玩家
2.条件:玩家变量(事件玩家，b) < 0
3.行动:
修改玩家变量(事件玩家，B，plus，100)
修改玩家变量(事件玩家，A，minus，1)
等待(0.016，不考虑条件)
如果条件是 True 然后循环
设置播放器变量(事件播放器，C，true)
更改规则
1.事件:连续-每个玩家
2.条件:玩家变量(事件玩家，C) ==真
3.行动:
//这里写等级变化的逻辑
设置玩家变量(事件玩家，C，false)
注意:这只是一个模拟函数调用，实际上还是比函数少很多。所以，并不是所有的情况都适合这样写。
摘要
其实这篇文章并没有使用什么奇怪的技术，但是这篇文章的难点在于思路的变化:你需要找出几种不同逻辑的共同点，并巧妙地拆分成多个逻辑，然后用规则实现。
要不要这样设计规则？你需要考虑它的利弊。
优点:把重复的内容分离出来，减少工作量，方便以后修改(不仅修改的地方少，漏改的可能性也更小)。
它也有缺点:增加了规则的数量，增加了逻辑的复杂度，运行效率略低。
个人认为，恰当地运用这种思想来设计规则，可以减少你的工作量和维护难度。但不代表这种方法就一定是最好的。你要考虑自己的实际情况。
