【开发者日志】一个人做游戏-bug是修不完的

随着游戏内容的增多，bug往往伴随而生，任何追加的设计与功能需求，都会为后期的崩溃埋下祸患的种子。

我们的程序糕手半只阿柴此时仍在与bug们持续战斗，这是一场异常艰难的战斗，也是的独属于他一人的战斗，面对如此凶险恶敌，他会战胜对手吗？

各位观众朋友们好，原计划本期节目要采访的半只阿柴(神志不清版)未能抵达节目现场，看样子已是遭遇不测，让我们为他默，呃，让我们开怀大笑他一会儿。

就聊聊目前开发遇到的一个bug，设计到一些数学知识，我尽可能给大家讲清楚。

背景：游戏中部分组件可以旋转，处理旋转用的是欧拉角的z值来表示旋转。

bug是怎么诞生的呢，大家知道，表示旋转度数的范围是无限的，但实际有意义的，可以提炼为0~360这一个大小范围[0,360度)，因此，对于任意输入的可能角度，我们都将最终输入值处理为0~360范围内同意义的度数，每个组件的可旋转范围，是以其初始旋转朝向，根据顺逆时针加减范围，加减后的范围，可能超出[0,360)的区间。举例，假定初始朝向是60，如果设定组件可以顺时针30度，逆时针30度，实际范围是[30,90]度，没有问题。

但如果，不是30度，而是90度，那么范围就变成了[-30,150]度，诶，bug来啦，当玩家试图朝向的方向为350度(-10度)，因为输入被限定在0~360内，那么他就会判定超出的设定最大角度150度，直接视为超范围，设置为最大角度150，反映到实际游戏中就是玩家始终无法旋转到-30~0度这一区间，显然，我们既要保证输入值的表示是唯一的，又不能出现，玩家输入的是350也是-10，这种情况只会让用于判断的代码段需要考虑更多的情景，进而让事情变得更加麻烦。

怎么解决：诶，我有一个点子，将-30~0区间转换到到330~360不就ok了吗？那怎么判断涉及的区间不在0~360范围需要转换呢?左界限比右界限大，就说明发生了转换，再写一套处理不就ok了嘛。随后的问题，就是如果玩家试图朝向范围外的地方，应该如何矫正，那就是下一个要解决的bug了。

-------我是分割线------------------------------

听起来好像不复杂，然而，真正花费时间的地方不在于解决思路的实现，而在于弄明白bug诞生，并针对性的矫正、修复。在最开始遇到bug时，其表现仅是，旋转到一定角度，组件会不受控制地飘到另一侧，要从bug的表现发掘到bug具体出在哪里，如何造成这种现象，挨个debug重现并分析数据才是最花时间的，bug修了，因bug卡掉的进度与时间确实实打实的没了。

所以，要做不完啦~#聚光灯gamejam开发者日志 #TapTap聚光灯独立游戏