我觉得有必要分享下自己处理方格运动的方式。这绝非终结模式，只是现在它能够带来令人满意的结果。
在我制作的所有游戏中，我通过基本方框方式进行触碰测试。在节奏合理的街机游戏中，精灵通常会填充方框，所以这不是个问题，因为玩家不会注意到有几个像素出现错误。除此之外，我总是在恰当时候突出有利于玩家的触碰路径。
在迷宫游戏中，我通过不同方式判定玩家精灵是否需要同迷宫墙触碰。
游戏呈现于32 x 32像素区块的10 x 15方格。区块其实就是精灵，因为我想要激活它们（游戏邦注：例如在动画框架中循环，移动至关卡加载位置，在游戏中调整尺寸及进行移动）。但和其他游戏精灵不同，我不会采用标准的触碰路径。在既定游戏时刻，玩家或a）处在能够转化成网格坐标的准确位置；b）或在两个网格坐标间移动。这是我墙面触碰模式的关键要素。
a & b上述图像清楚说明这些观点。在插图中，b）玩家通过点击屏幕激活移动操作。游戏意识到这一情况：玩家精灵目前没有移动（m.player.moving = false），因此我们做出相应清除，试图激活移动操作。但首先我们通过将玩家精灵的x,y坐标转移到网格坐标中展开测试工作。
e.g. m.player.x = 128, m.player.y = 192 = the player sprite is sat at grid reference 4 , 6 (128/32, 192/32)
我们现在可以判定玩家期望精灵如何移动，然后测试对应网格坐标点，查看墙面是否挡在通道中。我们可以基于存储于墙面位置中的leveldata数组进行这一测试。所以就目前来说，这些都是基本操作。若墙面挡在通道中，那么移动请求就会遭到拒绝。
sprite move blocked c玩家精灵位于方格4, 1。他想要移动至5, 1。通过快速查看leveldata数组，我们发现，数组元素1的位置5有个“+”，如下：
var leveldata = [];
leveldata[0] = [
"+,+,+,+,+,+,+,+,+,+",
"+, , , , ,+,+, , ,+",
"+, , , , , , , , ,+",
"+, ,+,+,+,+,+,+, ,+",
"+, , , , , , , , ,+",
"+,+,+, ,+,+, ,+,+,+",
"+, , , , , , , , ,+",
"+, , , , , , , , ,+",
"+, , , , , , , , ,+",
"+,+,+,+, , ,+,+,+,+",
"+, , , , , , , , ,+",
"+, , , , , , , , ,+",
"+,+,+,+,+,+,+,+,+,+",
"+,+,+,+,+,+,+,+,+,+",
"+,+,+,+,+,+,+,+,+,+"
];
趣味点源自于在精灵运转后处理新的方向请求。
这里我们需要完成些许事项。首先我需要让玩家精灵持续运动，直到墙面被击中。
为完成这一目标，我规定精灵在穿过方格时，只有在其坐标轴顺利分解成成网格坐标的情况下才能够通过测试函数。
我的精灵以8个像素增量进行行走，这样从方格位置A移到方格位置B需要经过4个步骤。我们故意缩短网格点间的时段。在我看来，玩家能够基于预期的下个方向点击屏幕，进而实现经常登录非常重要。
sprite move intended d预期的下个方向已存储起来，当玩家精灵出现在下个网格坐标时，我会测试这一新方向，而不是实际方向。若新方向进展不顺，精灵会继续遵照自己的预期路径，直到a）收到新方向请求，或b）击中墙面。
当然在任何移动位置里，玩家都能够自由“旋转他的精灵”。没有什么能够阻止这一操作（游戏邦注：因为游戏会探测准确地点，精灵会退回到先前的网格位置）。
所以，我们可以简单概括游戏其他物件发生什么情况。怪兽会遵循玩家精灵的代码路径。当它们击中墙面时，它们会基于自己的定义做决定。在多数情况下，怪兽会“搜寻”玩家，因为这就是挑战的所在。但在某些情况下，我会将此随机分配，这样怪兽就会高兴地重新迈出自己的步伐。游戏应该融入足够的混合元素，方能让玩家发挥想象。
宝石、升级道具、奖金及魔法武器等实体物件的放置位置将由leveldata[]定义决定，但我们会通过标准触碰程序测试它们同玩家的触碰情况。这样我就能够在迷宫中随意移动精灵。
via：gamerboom
