Skip to main content Link Menu Expand (external link) Document Search 复制 已复制

当我们的游戏报错了,或者游戏运行的实际效果出现了不符合我们的设想的情况,这种代码上的缺陷我们称之为 bug。而调试(debug)就是指发现,定位,解决 bug 的过程。

很遗憾的是,编程语言并非 AI,他无法参透使用者的意图,几乎不可能给出准确的 bug 原因。但是,任何一个 IDE,都或多或少提供了一些调试信息和调试手段,这将是我们定位和解决 bug 的重要途径。

看懂报错

如果我们的游戏出现了代码上的逻辑错误,例如非法的语法,不正确的参数量等,GM8 就会给我们一个 Error Messages,例如:

Error Messages

1
2
3
4
5
6
7
8
9
ERROR in
action number 2
of Create Event
for object objTest:

Error in code at line 2:
   if (a == b)
           ^
at position 10: Cannot compare arguments.

我们来一点一点地分析这个报错:

  1. 第四行 “for object objTest” 告诉我们,错误发生在对象 objTest 中。
  2. 第三行 “of Create Event” 进一步定位到 objTest 的创建事件。
  3. 第二行” action number 2” 表示出错的是第二个代码段:

    Code

  4. 第六行 “Error in code at line 2” 告诉我们,出错的代码是在第 2 行:

    Line

  5. 第七行 if (a == b) 是告诉我们出错的代码。
  6. 第八行有个 ^,他指示了错误发生的位置。
  7. 第九行的前半段 “at position 10” 和 ^ 作用相同,告诉我们错误发生的位置是从左数第 10 个字符处。注意空格也算字符。
  8. 第九行的后半段指示了错误发生的原因。在本例中,错误原因是 “Cannot compare arguments”,这个错误的发生原因是判等的两边类型不同,即 a 和 b 中有一个是实数,有一个是字符串,二者无法比较,因此会报此错误。

一些令人摸不着头脑的报错

位于事件 Trigger Event: <Deleted>

Trigger

这是 GM8 本身的一个 bug,所谓的 Trigger Event: <Deleted> 其实是 ICC(instance creation code)或者 RCC(room creation code)。

Error defining an external function

External

这是指的是 external_define 这个函数执行失败了。要么就是 exe 目录下缺少了 dll,要么就是 external_define 定义的函数与 dll 内实际函数不同。

Unexpected error occured when running the game

Unexpected

这种已经不是报错了,而是游戏崩溃了。通常来说,游戏崩溃的原因可能是使用了一个非常大的整数,超出了GM8能承受的界限。或者游戏使用了一张非常大的图像,导致游戏运行时没能成功加载图像。

了解调试信息窗口

通常,我们面临第二种 bug,即游戏运行的实际效果不符合设想的情况要远远多于报错的情况,并且调试难度高不少。要寻找代码可能出现问题的位置,我们需要学会如何使用调试信息窗口。

Debug Information

首先来看到最下方状态栏的 50 fps | 168 inst | mouse id: 10035450 fps 指的是游戏当前运行帧率为 50 帧,168 inst 指的是当前房间内一共有 168 个实例,mouse id: 100354 指的是鼠标位置上的实例的 id 为 100354。

其次我们来看窗口的主体部分,是一个监控表达式的列表。“Expression” 是要监控的表达式,“Value” 是该表达式当前步的值。你可以点击右上角的加号新增表达式,点击循环符号修改当前表达式,点击叉号删除当前表达式,最后一个按钮会清空监控列表。要注意的一个事实是,任意一个可以计算出值的表达式都可以作为 “Expression”。它可以是一个变量,比如 global.frozen;也可以是一个算式,比如 12 + 5;也可以是个函数,比如 power(2, 4),等等。另外,也可以通过鼠标寻找一个实例的 id,然后使用 (id).x 来监控特定实例的变量。

再来看到左边的那些按钮,它们分别是继续游戏,暂停游戏,向前一步,重启游戏,结束游戏。通过暂停游戏 + 向前一步,我们可以仔细地观察游戏每一步的状态。

最后,来看到 Tools 下提供的工具:

Tools

Execute Code

立刻执行一段代码。这是一个非常好用的功能,能够随时随地执行任意代码,如果有语法错误,只是提示 “Compile Error”,并不会终止游戏。

这里介绍给大家一种很好用的思路:

如果我们想知道实例 inst1 是否与另一个实例 inst2 发生了碰撞,我们想要监控 place_meeting(x, y, inst2) 是不可能的,监控列表并不知道这个函数要交给谁来执行。因此一种实现方式是,通过 Execute Code 执行 with (inst1) isCollided = place_meeting(x, y, inst2);,然后再监控 inst1.isCollided 即可。不过缺陷是不会自动刷新,需要再次 Execute Code 才会刷新值,因此更适合暂停游戏下使用。当然,这里只是提供一种可行的思路,希望各位能举一反三,发掘出更多用途。

Set Speed

设置游戏运行帧率。

Show Global Variables

显示所有的全局变量及其值。

Show Local Varivales

显示某个实例所有的变量及其值。

Show Instances

显示所有实例的 id 及其对象名。

Show Messages

如果你在代码中使用 show_debug_message(str),那么 str 就会出现在 Show Messages 打开的窗口中。与 show_messages(str) 不同,show_debug_message(str) 不会主动弹窗阻拦游戏进程,因此更适合 debug 下使用。

if (debug_mode)

debug_mode 是 GM8 内置的常量,它在 Debug 模式下为 true,在普通游戏时为 false。因此我们可以通过 if (debug_mode) 增加许多调试工具,例如无敌模式,无限跳跃,鼠标移动角色位置,绘制判定域,等等,任何可能有助于调试的代码都可以考虑加在 if (debug_mode) 下,未来发布的时候也不用删除,直接发布就行,玩家那边是不会触发的。

注释调试法

当你无法定位一个 bug 的所在位置时,最好的办法莫过于注释调试法。即将大部分代码都注释掉,仅留下一部分代码,运行检测其正确性,如果没问题,就从注释中解除一部分代码,继续测试其正确性,以此类推,直到找到不正确的位置。

资源重名

资源重名会引起串位,我们知道,GM8 中任何资源名其本质就是一个整数,如果一个精灵和一个对象重名,那么在 instance_create 时,传递给函数的很可能就是精灵的索引而不是对象的索引,这样 instance_create 就会去找另一个相同索引的对象,造成一些莫名其妙的 bug。要检测工程内是否有重名资源,可以使用脚本->检查资源名称

Scripts

资源重名还有另一种情况,就是资源名和变量名重名。由于资源名有绝对的优先级,因此 GM8 不会将其视为变量。不过这个 bug 很好找,资源名都是黄色的,你看到变量里有个黄色的变量那肯定是重名了。

未初始化

我们知道,资源索引都是从 0 开始的。而 GM8 提供一个功能,将未初始化的变量赋值为 0,他可以关闭,但是由于 GM8 的设计缺陷我们很难不使用这个功能。

由此会引发另一种看起来很莫名其妙的 bug。假如你代码中有类似于:speed = inst.speed,但是此时实例并没有初始化 inst 这个值,那么 GM8 会给 inst 赋值为 0,这句代码就成了 speed = (0).speed,也就是将索引为 0 的对象的速度赋值到当前实例的速度,再比如 sprite_index = spr,但是 spr 未初始化,那么实例就会以索引为 0 的精灵作为其精灵。当然,不仅仅是赋值,任何一个使用资源索引的地方都可能会出现这个问题。通常,我们不会不去初始化一个变量,但是我们可能会被 GM8 的事件顺序坑,也就是我们原本以为是赋值再调用,但是 GM8 实际的运行逻辑可能就是先调用再赋值了。

良好的编程习惯

良好的编程习惯一方面(缩进,换行,空格等)有助于提高代码的阅读性,让你能快速看懂每个部分是在做什么,另一方面(高内聚,低耦合等)有助于快速定位 bug 的所在位置。