开发日志 5-18

 　　Be honest rather clever.

      ...........  * *  *...................... *  *  *....................................

     

      1） 解决问题：

 　　（1）碰撞：

       设想：如果能够分清，人物和碰撞物体之间的方向关系就可以解决。比如人物向左运动，碰到了一个物体，停下来，转换动作，两个范围框交叉在了一起。然后如果人物继续朝着障碍物的方向运动，当然会碰撞。如果是朝相反的方向，就不检测碰撞。这样就不会黏在一起了。

　　 以前为了解决物体的左右翻转这个问题，曾经设计了一个布尔型的变量 facing,现在或许可以让他继续起作用。这么做存在一个问题：在游戏系统中，左右（东西）是一个绝对值（absolute），而facing是根据游戏人物的原始图是面向左还是面向右的，是一个相对值（relative）。这里需要引入一个新的值来表示人物前行的方向，上下（南北）被忽略了，只有向左向右（或者说向东向西）。如果所有的图片的朝向都是一样的，这当然是最好了；但如果不是，那么就需要自定义了。

　　更深入一些，不但需要了解碰撞的发生，而且需要了解碰撞的方向，这在踩虫子的游戏中很常见，从上面“踩”中虫子会把虫子踩死，但如果你“碰”上了虫子，那么只好安息了。这里的踩，实际上是玩家对虫子的碰撞方向为自上而下，碰撞面为底边，而对于虫子，这次碰撞是自下而上的（相当于跳跃），碰撞面为上边。

 　　这里我需要提醒一句：实际上游戏的过程并不是连续的，并非一个像素一个像素的移动，所以有可能产生，上一个时刻两个物体尚未发生碰撞，下一个时刻，两个物体已经碰撞过来而且分开了，那么检测仍然认为他们没有碰撞，这就是一个Bug，而且这个Bug还不容易寻找，这在物体步进速度很大，而且物体较小的时候有可能发生；还有一种可能就是下一个时刻，一个物体正好嵌进另一个物体里面了，稍不注意，会造成很奇怪的结果。继续讨论下去，会发现，碰撞还有一个前检测碰撞和后检测碰撞，前者是检测下一时刻会不会发生碰撞，后者是检测这一时刻是不是发生了碰撞。后者有可能发生陷到墙里面的情况，原因就是前面提到的游戏过程不是连续的。在这个游戏中，采取的是后检测的方法。   

       修改碰撞函数bool[] CheckBump（），在碰撞发生后返回一个bool[],【0】：是否发生碰撞【1】：碰撞在左边/右边发生 【2】：碰撞在上边/下边发生，这样在检测碰撞的时候，同时检测碰撞发生在那一边上和游戏人物前进的方向，发生了碰撞，而且前进的方向和障碍物所处位置一致，则真正发生碰撞反应（比如速度为零）。   

       （2）测试：

　　　原来以为，一个人物运动以后，另一个人物的速度总为零，是因为键盘KeyUp后恢复 idle引起的，经过试验，注释掉这条语句，发现仍然这样，可见这个问题还有更深的原因。

       （3）思考：

　　 现在采取的数据存储方式，是在处理逻辑的模板类中，放了一个 静态的 List<>,在这里存放着一个个同模板的游戏人物数据，这么做虽然麻烦，但避免了装箱拆箱。但在实验的过程中，发现装拆箱的代价似乎没有那么高。有没有必要改进一下目前的做法呢？