• 注册
  • BBS 守望先锋 关注:0 内容:769

    《守望先锋》地图工坊教程

  • 查看作者
  • 打赏作者
  • 拉黑名单
  • 当前位置: UTGamer游戏论坛 > 守望先锋 > 正文

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

    注意:这里只是模拟函数调用,但实际上它比函数还是少很多东西。因此,并不是所有情况都适合这样写。

    总结

    本文其实并没有用什么很稀奇古怪的技术,但本文的难点是思路的转变:你需要将几个本来不相同的逻辑,找出他们的共同点,并巧妙的将其拆分成多个逻辑,然后用规则来实现。

    到底要不要使用这种方式来设计规则?你需要考虑它的优缺点。它的优点有:

    将重复的内容独立出来,减少工作量。

    方便以后的修改(不仅需要修改的地方少了,漏改的可能性也更小了)

    它也有缺点:

    增加了规则数量。

    增加了逻辑上的复杂度。

    运行效率稍低。

    个人认为,适当的使用这种思路来设计规则,可以减少你的工作量和维护难度。但并不代表这种方式一定就是最好的,你应当考虑你的实际情况。

    请登录之后再进行评论

    登录
  • 做任务
  • 实时动态
  • 返回顶部