关于BUG。
BUG,一般也叫漏洞或者缺陷,程序实际运行跟你的构思的需求存在较大差异的话我觉得这个也可以称为BUG。
不过定义是啥应该不需要太多纠结,反正做游戏的都知道是什么东西就对了。
不过BUG有一个很奇怪的地方就是……- -嗯,我又翻了一遍软件工程,确认了。
简单来说就是:程序员要避免测试自己的程序。
因为程序员是开发者,而测试员是验证开发出来的玩意儿正不正常。一般来说很难有人能把这两个角色同时扮演好。并且开发者自己测试的时候,很容易受到自己开发思路的影响,从而不能有效地跟踪和捕获某些BUG。
举个简单的例子,你设计剧情在A镇触发,那么你自己在测试时,受到开发思维的影响,你可能就直接径直走向A镇了。而如果是非开发人员测试这里,他就可能会东走走,西跑跑,从而发现可以到达B镇提前触发某段剧情使得A镇剧情被跳过。
当然还有原因是程序对需求解读的偏差导致与需求相差过大从而出现BUG,但一般我们做独立游戏的都是自己又做策划又写事件,所以一般不会出现这个情况,一般就是上面的这个情况较多,即:比较容易受到自己制作的思维而忽略掉某些BUG。解决办法也很简单,多找几个测试人员跑跑就行了。说起来多找几个测试人员测试,算是软件工程里的beta测试,也就是在开发者无法掌控的情况下模拟客户群体使用该产品的体验,换成游戏就是玩家们可能玩你的游戏就会是这个情况。
那么如何更好地测试自己的游戏,找出BUG呢?嗯……我个人觉得最主要的是:抛开你的开发思路。用尽你的一切可能操作去模拟玩家的操作。比如一个BOSS,你设计他你自然知道你设计打败的方法是什么,但你这时候如果试一下其他的方法,很可能那里埋着的一个BUG就被你挖出来了。而如果你是给其他工作室打工的,专门测试的呢?那就尽一切可能去寻找BUG吧。你甚至可以一个格子一个格子地去踩来确认他们没有BUG。
那么,终于发现BUG了之后呢?该干什么?
首先第一步是,读取最近的存档,然后尝试着重现这个BUG。因为有些BUG不是必现的,所以你要尝试着重现它来确认你到底做了什么才导致他发生。这个步骤可能要重复多次,直到你找到触发他的操作为止。这个操作可能只是一个单独的操作,也可能是多个操作结合起来才出现,这个无论如何都要确认好。当你确认完毕这个BUG是如何触发之后(也就是你使用这个操作方式必定会触发这个BUG,或者有较大几率触发这个BUG(因为有些BUG还受到其他不可控因素影响)),把BUG的表现,还有触发条件等等记录下来,然后交给程序……或者如果你自己就是开发者的话,那你就要开始定位这个BUG了。
第二步就是定位。查看BUG发生的地图上的事件,找出可能引发这个BUG的事件,然后一个可行的办法是新建一个空白事件页将原有事件覆盖住(RM数字较大的事件页会盖住较小的事件页),之后再测试看依照之前的触发机制,看看BUG是否发生。
如果BUG没有发生,就将原有的事件页中的指令从上往下一条一条地逐个加入空白事件页中,每加一条测试一次,直到找到有BUG发生的那一条为止。那么那一条语句就是导致BUG发生的地方,再对症下药即可。
而如果覆盖住了,BUG还在,那么说明人家是无辜的,赶紧放行。
而如果把当前地图的事件全部试了一遍毒,BUG还在的话,那就要开始考虑公共事件和脚本的问题了。公共事件也就是看看当前有什么公共事件在运行,关掉对应的开关看看就行。如果公共事件也没问题,那一般都是脚本的问题了,结合你触发BUG时的操作定位当前可能会执行的脚本来找BUG。一个可行的办法是走程序……嗯,我大学时学院副教授教我们的,也就是把你自己当做电脑,从脚本开头进入,然后一直执行到结尾,看看有没有问题。这招对事件一样有效。比较简单粗暴的办法就是回忆一下触发这个BUG之前你有没有打过什么补丁,改过什么代码,如果有的话,恢复原状然后再试试。这样不停地试直到试出问题所在。这个比较耗时间,但属于地毯式搜查,一般肯定能发现问题。
嗯,说个亲身经历过的事件,我曾经使用过修改佩戴武器的方法来做变身的特殊攻击动画,但后来因为换行原因导致这个写在公共事件供技能调用的脚本出现了BUG,然后体现在了一个跟他毫无关系地图里。我按图索骥,从事件到脚本一一排查,全部没有问题啊!最后开始回忆这个BUG最早是什么时候发现的,以及发现他之前正常的运行的时间点是什么时候,然后把这两个时间点之间打的所有补丁所有修改全部列出来,然后逐个删掉,最后才终于锁定了BUG就是换武器动画……
不过一般来说,对新人来说最常见的的脚本BUG就是冲突BUG。一般这时候就需要看看你是否打了会冲突的脚本,通常会冲突的脚本无外乎就是重写了同一个函数,或者刚好有什么变量重名了(几率很小)。通常这时候你结合这个BUG产生的地点(比如战斗),推断出可能是什么脚本出问题(战斗出BUG一般都是战斗脚本出问题),然后仔细筛查你打的所有战斗相关的脚本插件,是否有同名或者重写了同一个类或者方法的情况。(比较简单暴力就是把打过的脚本一个一个删掉再看看BUG还在不在,但比较累)
找到冲突之后,要么自己把他们重写的函数结合成一个函数,要么丢给大佬帮忙融合,要么舍弃掉其中一个,这就是常见的解决方式了。至于哪个更好,见仁见智吧。
说了半天好像发现说的都是自己怎么找BUG……
BUG,一般也叫漏洞或者缺陷,程序实际运行跟你的构思的需求存在较大差异的话我觉得这个也可以称为BUG。
不过定义是啥应该不需要太多纠结,反正做游戏的都知道是什么东西就对了。
不过BUG有一个很奇怪的地方就是……- -嗯,我又翻了一遍软件工程,确认了。
简单来说就是:程序员要避免测试自己的程序。
因为程序员是开发者,而测试员是验证开发出来的玩意儿正不正常。一般来说很难有人能把这两个角色同时扮演好。并且开发者自己测试的时候,很容易受到自己开发思路的影响,从而不能有效地跟踪和捕获某些BUG。
举个简单的例子,你设计剧情在A镇触发,那么你自己在测试时,受到开发思维的影响,你可能就直接径直走向A镇了。而如果是非开发人员测试这里,他就可能会东走走,西跑跑,从而发现可以到达B镇提前触发某段剧情使得A镇剧情被跳过。
当然还有原因是程序对需求解读的偏差导致与需求相差过大从而出现BUG,但一般我们做独立游戏的都是自己又做策划又写事件,所以一般不会出现这个情况,一般就是上面的这个情况较多,即:比较容易受到自己制作的思维而忽略掉某些BUG。解决办法也很简单,多找几个测试人员跑跑就行了。说起来多找几个测试人员测试,算是软件工程里的beta测试,也就是在开发者无法掌控的情况下模拟客户群体使用该产品的体验,换成游戏就是玩家们可能玩你的游戏就会是这个情况。
那么如何更好地测试自己的游戏,找出BUG呢?嗯……我个人觉得最主要的是:抛开你的开发思路。用尽你的一切可能操作去模拟玩家的操作。比如一个BOSS,你设计他你自然知道你设计打败的方法是什么,但你这时候如果试一下其他的方法,很可能那里埋着的一个BUG就被你挖出来了。而如果你是给其他工作室打工的,专门测试的呢?那就尽一切可能去寻找BUG吧。你甚至可以一个格子一个格子地去踩来确认他们没有BUG。
那么,终于发现BUG了之后呢?该干什么?
首先第一步是,读取最近的存档,然后尝试着重现这个BUG。因为有些BUG不是必现的,所以你要尝试着重现它来确认你到底做了什么才导致他发生。这个步骤可能要重复多次,直到你找到触发他的操作为止。这个操作可能只是一个单独的操作,也可能是多个操作结合起来才出现,这个无论如何都要确认好。当你确认完毕这个BUG是如何触发之后(也就是你使用这个操作方式必定会触发这个BUG,或者有较大几率触发这个BUG(因为有些BUG还受到其他不可控因素影响)),把BUG的表现,还有触发条件等等记录下来,然后交给程序……或者如果你自己就是开发者的话,那你就要开始定位这个BUG了。
第二步就是定位。查看BUG发生的地图上的事件,找出可能引发这个BUG的事件,然后一个可行的办法是新建一个空白事件页将原有事件覆盖住(RM数字较大的事件页会盖住较小的事件页),之后再测试看依照之前的触发机制,看看BUG是否发生。
如果BUG没有发生,就将原有的事件页中的指令从上往下一条一条地逐个加入空白事件页中,每加一条测试一次,直到找到有BUG发生的那一条为止。那么那一条语句就是导致BUG发生的地方,再对症下药即可。
而如果覆盖住了,BUG还在,那么说明人家是无辜的,赶紧放行。
而如果把当前地图的事件全部试了一遍毒,BUG还在的话,那就要开始考虑公共事件和脚本的问题了。公共事件也就是看看当前有什么公共事件在运行,关掉对应的开关看看就行。如果公共事件也没问题,那一般都是脚本的问题了,结合你触发BUG时的操作定位当前可能会执行的脚本来找BUG。一个可行的办法是走程序……嗯,我大学时学院副教授教我们的,也就是把你自己当做电脑,从脚本开头进入,然后一直执行到结尾,看看有没有问题。这招对事件一样有效。比较简单粗暴的办法就是回忆一下触发这个BUG之前你有没有打过什么补丁,改过什么代码,如果有的话,恢复原状然后再试试。这样不停地试直到试出问题所在。这个比较耗时间,但属于地毯式搜查,一般肯定能发现问题。
嗯,说个亲身经历过的事件,我曾经使用过修改佩戴武器的方法来做变身的特殊攻击动画,但后来因为换行原因导致这个写在公共事件供技能调用的脚本出现了BUG,然后体现在了一个跟他毫无关系地图里。我按图索骥,从事件到脚本一一排查,全部没有问题啊!最后开始回忆这个BUG最早是什么时候发现的,以及发现他之前正常的运行的时间点是什么时候,然后把这两个时间点之间打的所有补丁所有修改全部列出来,然后逐个删掉,最后才终于锁定了BUG就是换武器动画……
不过一般来说,对新人来说最常见的的脚本BUG就是冲突BUG。一般这时候就需要看看你是否打了会冲突的脚本,通常会冲突的脚本无外乎就是重写了同一个函数,或者刚好有什么变量重名了(几率很小)。通常这时候你结合这个BUG产生的地点(比如战斗),推断出可能是什么脚本出问题(战斗出BUG一般都是战斗脚本出问题),然后仔细筛查你打的所有战斗相关的脚本插件,是否有同名或者重写了同一个类或者方法的情况。(比较简单暴力就是把打过的脚本一个一个删掉再看看BUG还在不在,但比较累)
找到冲突之后,要么自己把他们重写的函数结合成一个函数,要么丢给大佬帮忙融合,要么舍弃掉其中一个,这就是常见的解决方式了。至于哪个更好,见仁见智吧。
说了半天好像发现说的都是自己怎么找BUG……