开发者日志：关于BUG的维修护理

    如图，因为队伍里程序员含量为零，所以关于BUG上的问题，这几天我们可是吃尽了苦头。

    是的，我们的制作队伍里一个程序员也没有，但游戏好歹是拼拼凑凑七零八拐地拼完了，感觉还不错（帮我们测试游戏的程序员朋友们如此说道）。

    伴随着游戏进入测试阶段，我们从各个平台和身边的亲朋好友那里招募了一些对我们的游戏有兴趣的测试员（没想到里面的程序员成分比队伍里要高），对我们游戏的各个方面上进行了测试。

    首先便是游戏流程上的BUG，这个问题主要在我这里。我总是在改完这个后就落掉这个，改完那个后又忘记让内容显示。还有一些在于游戏自己内部的冲突，比如说镇楼，在思考完不是我个人因素导致的之后，我就只能把原因归到我们不算了解的程序部分上了（如果有程序员愿意来指导一下的话我们感激不尽）。

    接着是游戏引导，我和美术朋友总是会在这上面吵起来，因为我觉得她所思考的引导太保姆（我个人觉得把饭直接嚼碎喂到玩家嘴里有点呃呃），而她则抱怨我的引导跟没有一样（有时候得承认，我有时确实会忘记放明显引导，只会让NPC隐晦提示）。最终因为我们都是中国人，所以我们选择了中国人最喜欢的方式：折中。我强化了每个任务的引导线索，并一票否决了玩家去到相应的地方任务就直接触发的方式（最重要的是要搞这样的话，就需要整体大修改，会有更多BUG出现，而我们只剩不到一周的时间）。

    然后是游戏画面，因为环境的灰暗，敌人的血条模糊不清，测试人员没有分辨出他们面前的是怪物，好几次死于非命。我不得不放弃一些氛围感上的塑造，调亮一些地区的亮度，并调暗另一些地区的亮度（那些地方被投诉太亮了），然后修改敌人血条颜色、高度还有长度日志 ，这才减少了测试人员的初期暴死率（也可能是他们开始变得熟练了）。

    最后是修BUG的部分，我逐渐理解了当初玩手游的时候，手游公告栏里写的一大长串的修复报告。光是我们这一天一次的更新，大大小小的BUG就能攒上十位数，而当为了更好的体验而修改的时候，BUG更是只多不少（特指我在调整一个任务的触发的时候，调整完发去测试有人卡死在那个任务里了，打开一看是我在其中一条分歧里漏了一步操作，导致那个剧情不断循环触发）。

    到结尾，我们的测试也进行到一半了，这让我总结出不少经验，比如说在测试人员排出一个BUG的时候，不仅要解决那一个BUG，还要检查同类型的操作里，有没有出现同样的BUG。

    先写这些，因为字数限制，就不再多说了。#聚光灯gamejam开发者日志