This article was last updated on <span id="expire-date"></span> days ago, the information described in the article may be outdated.
这几天看了Making a Turn Based Strategy Game in Unity的视频,打算尝试做一个回合制的游戏。这应该是我的第一款全程独立制作(指的是自己思考代码结构,而非照着视频抄写
游戏),因此预计会花上更长的时间去准备和沉淀,但是希望能够最终完成。我目前的想法是做成一个类似于陷阵之志的3D回合制策略游戏。虽然我原本的想法远非如此,但是考虑到自己的代码能力,还是决定不要眼高手低了。接下去我会记录下游戏开发中一些值得记录的点子,基本会按照开发的顺序来记录(可能在完成后会进行整理)。预计的开发时间(包括学习时间)在3个月左右。
A*算法
尽管此前已经写过A*算法了,但是实际创建的时候还是遇到了一些问题。我发现C#中居然没有自带的优先队列。由于不想过度优化(实际上是懒惰),我就放弃了手写一个的打算(希望日后能补上).由于原理不难,我就不贴代码了。还有一个发现就是有关带权A*算法的问题。做一个简单的总结.
1 | fScore[neighbour] = tentative_gScore + w * h_Manhattan(neighbour.x, neighbour.y, targetX, targetY); |
此时,当w = 0时,A*为dijkstra算法。当0 < w < 1时候,A*算法更像会不注重速度,而是在乎准确性。当w>1的时候,此时的最终路径则不一定是最优的。当w远大于h的时候,A*就会接近于BFS.
class重载==操作符遇到的怪事
当我试图给class重载==
以及!=
操作符遇到的一个奇怪的问题.在一开始, 我直接将代码写成如下形式:
1 | public static bool operator ==(Node left, Node right) |
但是这种写法,在我使用类似 node == null
进行判断的时候就会爆空引用。这是合理的,因为此时我的right必然是null。因此,我对原有代码稍作修改,如下所示:
1 | public static bool operator ==(Node left, Node right) |
写完后我立刻就发现了问题,显然left == null
这句会循环调用我定义的操作符==
,运行后也果然爆栈了。一番思索过后,我放弃了解决。不过我发现有人也遇到了我类似的问题一个解决方法,虽然使用equals的方法并不优美,但好像也只能这么做了。另一个解决方法是使用node is object
语句判定。因为所有的类型都继承自object,这种做法显然更加合理.
使用BFS显示移动范围
接下去我来介绍一下如何显示合理的移动范围.Node类的定义以及主要逻辑代码如下所示.
1 | public class Node |
1 | void showMovementRange(int x1, int y1) |
显示前进路线
在实现显示移动范围后,我还需要显示前进的路线,路线本身实际上就是已经实现的A*算法。但是如何可视化却花了我一个下午的时间。 。
我一开始的想法是使用3D模型来显示箭头和线段。但是在花了近一个小时看blender的教程后,我连最简单的箭头模型都无法构建出来,最终我放弃了这种做法,改为手绘箭头和线段,并将其作为材质附加到Unity的Cube模型中.我其实对中间的过程完全不了解,在尝试之前我甚至不知道这是可行的。实际上,只需要将shader中的rendering mode设置为Transparent,在一些我并不了解的功能的作用下,模型会根据材质变得部分透明。
我一共绘制了三类形状,分别是矩形、转角以及代表终点的箭头。我们可以通过旋转角度的方式来表示各个方向.这就是代码需要做到的事情了。
为了代码的复用性,我直接使用了此前的A*方法的输出作为新方法的输入。为了解耦,我将此前的UI的显示单独放在一个类中。该方法会在tile被点击的时候被调用。
1 | public List<Node> generatePathWithSelectedUnit(int x, int y) |
在显示新的路线前,我们需要先移除此前生成的路线。随后,我们遍历路线。很容易想到,决定某个点是使用矩形、拐角和箭头图形的方向,只取决于该点、该点的上一点以及该点的下一点的相对位置关系。因此,我首先获得了last、cur以及next点.(在我的设计中,起始点不绘制在路线中,终点只可能出现箭头图案,因此单独考虑).为了表示点之间的位置关系,我将后点减去前点,并将结果normalized.通过这种方式得到的向量,我们只需要关注它在x还是y轴是否存在值,以及值的正负情况即可。这是需要一点时间总结的,我大部分的时间就在思考点与点的相互关系上了。按照关系画图应该有助于更快得出结果. 显然,在我的实现里,我先区别图形(即是矩形、拐角还是箭头),具体来说,当cur与last的方向与next与cur的方向一致的话,cur应该被画成矩形。当他们不一致的时候,则应该是拐角。路径的终点是箭头。对于方向来说,我们需要先确定模型在Unity中的初始方向,然后根据三个点的相对关系即可得到旋转的角度。最终,我们依次实例化这些预制件,即可得到效果.
1 | public void showPathUI(List<Node> list) |
角色按照前进的路线进行移动
在完成之前的所有步骤后,我们就可以实现角色的移动了。对于角色移动,我希望角色能够按照此前实现的前进路线移动,而非直接跳转。这就需要我们将路线传递给角色。同时,由于回合制的关系,我个人觉得如果update中使用类似于flag的形式决定角色的移动是浪费的,因为在某个确定的时间段,几乎只会有一个角色在进行移动。因此,我参考了塞巴的Unity入门教程中有关协程的部分,使用协程来对角色进行移动。值得注意的是我们需要使用两个协程方法来处理拥有多个点的路线的移动。即一个协程用来依次调用路线中的所有节点,另一个则单纯处理点到点之间的移动。我们还需要注意及时终止重复的协程,不然的话就会导致角色卡住或者乱动。以下代码写在Unit类中,该脚本负载在角色上。整个调用流程如下:我们点击一个tile,tile识别鼠标点击,并调用Map类中的移动方法。该移动方法由tile调用,因此知晓了其目的地,随后,该方法会根据绑定在Map类中的selectedUnit属性,即当前选中的角色,调用该角色中的Move方法如下所示。为了获取移动后的结果,我在这使用了Unity的Action方法。即EventSystem类中的EndMovement()
方法,传递了终点信息。该方法会通知Map进行一系列必要的操作,包括移动后进行移动力结算,重新绘制移动范围等。
1 | public void Move(List<Node> list) |
Unit命令的回退以及命令模式
在我们实现了角色的移动后,我们还需要实现角色动作的回退。显然,对某时的后悔之心会出现在任何事情上,自然也包括游戏。因此,为了方便的实现对于操作的回退,我们这里需要使用命令模式.《游戏编程模式》这本书里介绍了一些常见设计模式在游戏开发中的用法,对我来说非常实用。因为写出一个勉强能跑的程序是毫无成就感的事情,而高贵而繁复的设计模式能够让我有种我也是资深程序员的错觉。总之,让我们开始吧。
为了实现命令模式,我们需要先定义一个command
接口。该接口规定了两个方法,分别是execute()
以及undo()
。不言自明的,前者用于执行,后者用于回退。
1 | public interface Command |
接下去,让我们为目前唯一可行的操作——移动创建一个移动命令。目前来看,一个移动命令需要三个参数。分别是需要移动的_unit
、移动的_route
以及本次移动的花费mobilityCost
.因此,我们需要在构造函数中加入这三个参数。然后我们需要实例化实现接口定义的execute()
和undo()
.逻辑很简单,先让_unit
按照_route
进行移动操作,然后根据花费更新_unit
的行动力movementAbility
即可。回退操作即使反过来,先将_route
反转,再进行移动以及行动力的更新操作。
1 | public class MoveToTileCommand : Command |
在定义完我们所需要的命令后,我们还需要创建一个用于管理命令的类UnitCommands
.这个类的主体就是一个栈,用于保存和回溯命令。在入栈的同时执行命令的execute()
,在出栈时执行undo()
.
1 | public class UnitsMovements |
在做完以上所有的前置工作后,我们终于能够使用命令模式让角色进行移动了。我们先清空所有的UI,再实例化我们的MoveToTileCommand
类,并将该对象加入_unitCommands
中。
1 | public void selectUnitMove(List<Node> route, float mobility) |
由于我们还没有完成我们的游戏UI,因此在这里我简单地用一个按钮进行回退命令的执行,来看看效果.如果说命令模式有什么缺陷的话,那就是它往往需要定义许多的类来满足各类操作的需求,这往往会造成冗余。至于解决方法,以我的水平来说难以想到,实际上,我还没有因为类的冗余而困惑过。