June 5th, 2023
One of the major bugs that occurred while writing the code for the simulation, was the phenomenon of objects occasionally passing through the outside boundaries of the simulation. However, this bug only seemed to occur when the velocity of the object in question had a very large magnitude. The error itself is quite common in any kind of computer simulated motion, and the cause can actually be explained through a very well known example in the video game speed-running community, the backwards long-jump from Super Mario 64.
In the game, the player is gate-kept in progression through stars, which the player acquired by going through the various levels and completing the. The final of these gates requires the player to acquire 70 stars in order to gain access to the final level. The form of the gate itself, is a set of “infinite” stairs. What happens is when the player attempts to go up the stairs, they encounter an invisible area with a hit-box and upon touching the hit-box, the player is teleported back down the stairs giving the illusion of stairs that go on forever. However, a technique to bypass this gate would eventually be discovered. In the game's code, the long-jump mechanic is coded to multiply the user's velocity by a factor of 3/2. If the player manages to perform another long-jump before the drag brings the velocity back to its original state, it would instead continue to increase indefinitely. This would then be used in conjunction with how the game calculates position to teleport to the other side of the hit box.
Every second is split into frames, in which the game calculates the new position of the player using the velocity value, with there being 30 of these frames per second in this game in particular. However, if the value of velocity is great enough, the change in position between two frames can actually result in a large enough displacement to directly bypass an obstacle in-between. This occurs because the object's updated position is only determined and rendered in the subsequent frame, by which point it may have already penetrated the wall's hit box.
Now obviously this is not behavior that reflects the motion of this type of body in real life, and is something we needed to address. One possible method is to increase the frame-rate since having an additional frame in-between would allow the program to detect the collision of the hit-box; however, this would also increase the computing power necessary and slow down the program. Another option is to limit the velocity, which is actually what Super Mario 64 tried but failed to do. The long-jumps in the game are actually capped at 48 horizontal speed, but only in the forward direction. The opposite was actually left uncapped as it was never intended to be able to accelerate that direction.
The final of the simple solutions to this problem—which we ended up using—is simply increasing the size of the boundary. Because the maximum distance the user in our program can move the block in a single frame is from one corner of the simulation to the other, as long as the border-hit box was greater than the hypotenuse of the screen, the object would be detected in the hit box in the next frame since the speed would be capped by the size of the box.