背景
初学Cocos Creator游戏开发，实现一款飞行棋游戏。走棋交互一开始用的是方案一，测试过程中发现，棋子聚集场景下走棋困难。
如下图箭头指向处所示：
方案一
每颗棋子监听TOUCH_START事件，判断是我方可走棋子时，触发走棋动作。
缺点：棋子聚集场景下走棋困难，处于后方的蓝色棋子因为层级没有前方绿色的高，导致无法点击触发事件。
方案二
针对方案一缺点，参考js事件委托思想，改为在棋盘监听TOUCH_START事件。调用getLocation方法获取点击位置的坐标(x,y)，找到具体的棋格，进一步找出棋格中我方的棋子，触发走棋动作。
缺点：虽然能解决方案一的问题，但基于棋子“头重脚轻”的特点，当用户点击棋子头部进行走棋时，容易判断成是上一格的棋子，导致走棋交互不顺畅。
方案三
既然方案一和二都有不足的地方，灵机一动结合一和二。在棋盘监听TOUCH_START事件，但先根据e.target判断是不是我方棋子，是则走棋，否再根据坐标找到棋格找到棋子走棋。
缺点：虽能解决上面方案的问题，但假如聚集的都是我方的棋子时，存在容易误走前面层级高的棋子的问题。
原因：前面层级较高的棋子，点击区域不止可视范围，还包括了周围的空白区域（如下图红框所示），以至于用户想走后面蓝色棋子时，e.target其实是前面蓝色棋子的，导致误走了前面的棋子。
方案四
方案三的问题在于，想走的棋子点击区域不够大（同一棋格有多颗棋子时，每颗棋子都被缩小了），而前面层级高的棋子点击区域比较大。 基于上述原因，方案四将可走棋子的大小恢复到原来的1倍（即使同一棋格中有多颗棋子），同时增加了一个透明node来规定棋子的点击区域（即除去空白区域的干扰）。
原先的棋子点击区域（蓝框部分）：
新增透明node的点击区域（蓝框部分）：
结果
一步步改进到方案四的版本，最终解决了聚集时走棋不顺畅的问题。
