被正确使用的轮子才是好轮子——使用Construct2制作游戏的一点感想

自负

---

  老师最初布置这个作业的时候，我是对此不以为然的，因为自己有一定的Canvas基础，并且曾经制作过魔兽争霸3的地图，对于这种对象-事件触发的机制也还算熟悉，因此，当时的我认为，利用这样一个引擎，要仿制一个和坦克大战一样的游戏，应该只需要两个小时。

  然而事实上，这份作业花费了我超过三个下午的时间，由于不了解许多功能，导致许多预期的效果只能通过繁琐的方法实现，而对于内部运行机制的不了解更是雪上加霜，大量的冗余事件堆满了事件表，不仅未能实现预期的效果，还极大地拖累了作品的运行速度。

  在整个作品的制作过程中，这种可怕的狂妄自大几乎是致命的，它使得我没有认真阅读过Construct2的文档便开始工作，这使得我的制作一度陷入巨大的困境。

困境

---

  最初我的设想是：由于坦克、砖块、基地是正方形的，那么就可以将地图表示为一个m*n的二维数组，数组的位置对应对象在地图上的对应位置，数组的内容为该位置的对象类型（砖块、坦克、森林、基地），然后再根据数组与地图的对应关系，将单位渲染到地图上。并依据这个数组中的信息，进行坦克的移动，击毁等判定。

  这个想法看上去有点像Canvas中的绘制：先决定好颜色、线段等信息，再进行填充或者绘制。看上去这似乎有利于我进行各种判定，但事实上这种想法却略显多余：许多用Construct2制作游戏的人都知道，地图信息可以通过位置选择、碰撞判定、视野判定等多种方法获得。更何况，坦克在移动过程中的位置不可能总是恰好对应到数组上，在这种情况下，数组的很多计算无法正常进行。

  但这并不是主要的麻烦，更主要的麻烦是：利用数组进行的多种计算忽略了引擎本身就具有的功能，导致需要大量的事件，但如果不采用这些方法，数组所带来的计算上的直观性的优势就会荡然无存（事实上，如果采用了引擎自带的功能，在数组上进行的大多数计算是没有任何必要的）。

  但大量的事件在很多情况下会带来诸多麻烦：一是和庞大的代码一样，大量的事件使得游戏本身极难易维护；二是老师推荐使用Construct2社区版，并且我也不希望为一份作业付费，而社区版只允许使用100个事件，这是我后来放弃地图数组这一想法的最主要原因。

重构

---

  在浪费了很长一段时间在大量事件中的挣扎过后，我找到了Scirr a上的手册，在进行粗略的阅读过后，我又去看了几份自带的样例，我选择放弃最初的想法，使用了另一个方案：

• 首先，在判定碰撞方面，给砖块和坦克添加Solid行为，避免一些了莫名其妙的动画重叠。
• 在地图生成上，放弃使用并查集判断随机生成的地图的连通性，转而使用PathFinding行为进行计算，从而进行判定。
• ……

  这个方案被验证为是行之有效的，因为它将我的事件表简化到了只有70个左右的事件，并且在实现效果上不亚于原本的上百个事件。

反思

---

  这次的作业让我重新反思了之前的许多观点：比如使用轮子一定比没使用轮子来得好，或者是软件的说明书和样例不如直接Google方便等，这些观点曾经影响了我很长一段时间，而我竟对此带来的不便浑然不觉。

  这次的作业给我带来的触动非常深刻，它让我重新反思了过去的作为，并总结出了以下的经验：

• 在使用一种工具之前，要先浏览该工具的文档和案例，避免重复造轮子。
• 在尝试使用一种功能之前，要先查看该功能的详细说明，不可轻信搜索引擎带来的结果，这极有可能是你陷入某种困境。
• 不要总是使用以往的观点看待某样工具，每个工具都有其设计者的思想包含在其中，先理解这些思想，再进行设计，会为你带来众多设计上的便利，反之，则会使你的构想的实现辑为复杂。