为了上下文，我使用Construct 3来开发，虽然它有一个很像代码的编程系统，但也包括了可以在项目中轻松使用的预建行为和对象类型。

我正在开发一个游戏叫做Tandem，游戏玩家控制两个球，一球红色，一球蓝色，使用相同的输入进行控制。他们驾驭这些球通过各种迷宫和谜题来匹配门户，这些门户需要同时到达才能完成关卡（如Fireboy和Watergirl）。最近，我实现了可以推动的，其颜色代码区块，可以只由匹配颜色的玩家推动，使用实物碰撞过滤和自己的瓦片移动行为来控制它们对玩家移动的反应。

但是，在测试之后，我发现它们有一种奇怪问题，会在推向实物对象时卡住，并在似乎是随机的时间内快速振荡，然后才正确地定位。没有什么让我明白是什么原因，但它对我正在制作的关卡做得很有破坏性，所以在两个星期的尝试之后，和我朋友打了个Discord电话，为了获得一些帮助，在Construct 3论坛上询问一些帮助。在那之间，我正在摸索。

当我创建了这些推动块的时候，我给它们自己的TilMovement行为，因为我只有一个尺寸。通过发现碰撞过滤并让它们实际工作的过程是一个折磨，但我最终成功地克服了它，所以我决定添加一个大型的推动块大小的第二个版本，使用该TilMovement行为。对于一致性，为了共享的行为，让我将这两种类型推动块都放到一个类型中，这样它们可以共享一些特性。 I 添加了TilMovement到该类型中，以便在块类型之间进行更好的同步，允许它们从类型中继承行为，但我害怕移除其中的原生TilMovement，害怕会破坏其中的逻辑，在重新定义从头开始前。

当实际的运动逻辑还没有写好的时候，这个过程发生了。一旦奇怪的问题首次出现，我就不知道是什么原因了，试了无数种解决方法。

但是在昨晚，实际上是在10分钟内我在论坛上发帖之后，我点来摸索，看看如果我仅仅关闭这种老的TilMovement行为会发生什么。事实上，它现在不必用于任何什么，只是简单的点一下关闭的按钮然后测试了游戏，结果：问题就解决了。

我根据我猜测的，它的原因可能在于因为推动块实际上有两个相同的（但不同的）TilMove行为，但底层逻辑只有一个，它们的碰撞问题就导致了这样一个回路，使得它们卡在此处的振荡和延迟定位的这种延迟的情况。

我坐在那里一脸惊呆，自已一点都不太确定的事实很简单很明显的惊讶。我只想要记录一个bug的视频，并在谷歌驱动中分享这个项目文件，只是为了分享它，并询问一下帮助。结果，答案很快就几乎被一个错误的推算了。

我想故事的道德是，有时候你应该单单出于科学目的，按几个随机的按钮，偶尔会让问题变得明白。

我猜另一个故事的道德是，你不应该将对象包含在另一个行为上，做同一件事情😅