Hello everyone.

This week, I released a new version of the demo on Steam, containing mechanics and fixes accumulated over several months. I have already started working on the next gameplay system, which will most likely take more than one week to complete. Every few days, I try to take a break from it and switch to a small feature improvement or bug fix from my TODO list.

A few days ago, I ran into a small bug related to the character’s movement across the map. Normally, nobody pays any attention to movement when everything works correctly. It seems very simple: press a button, and the character moves to the next tile. The animation and sounds play as well. But it was during this movement between tiles that the bug appeared, even though it had never shown itself during normal gameplay before.

I designed the IRSEN map as a grid. Logically, the character, or rather its in-world model, is always located on a specific tile. Visually, however, movement does not teleport the model from the center of one tile to another. After a directional key is pressed, the game checks the neighboring tile, takes its center as the new target, and begins smoothly moving the 3D model toward it. Once the target is reached, the new tile is marked as occupied and the previous one as free. The step is considered complete, and the game waits for the next command.

When a button is held down, movement continues automatically until it is released. Holding Shift enables fast movement. The logic stays the same, but the speed increases. Because of this, the system cannot simply move the character model forward. It has to determine the exact moment when the model reaches the center of the tile, finish the current step, and only then begin the next one.

I introduced a small distance threshold that was checked while the model was moving. Every frame, the character’s position changed by a distance calculated from the direction, speed, and frame duration. A step was considered complete when the remaining distance to the target became smaller than this threshold.

With a stable frame rate, this worked almost all the time. At least, I occasionally noticed small jerks, but I blamed them on the fact that I do not have a desktop PC and do all development on a laptop with integrated graphics. During each frame, the character moves a short distance and gradually approaches the center of the tile. The length of that movement depends on the FPS. The longer a frame takes, the farther the model moves during a single update. At a sufficiently low or unstable frame rate, the character could overshoot the point it was moving toward.

On the next frame, the direction would then reverse. The character would overshoot the center of the tile again, change direction once more, and continue doing this in a loop. Internally, the game still considered the character to be moving, and the animation continued to play, but visually the model simply jerked back and forth almost in place. Fast movement with Shift held down increased the size of each step and made the problem even more noticeable.

I did not discover this during a normal test run. It happened while I was recording the game through OBS to prepare a gameplay video of the new demo for YouTube. At one point, the character began running in place with sudden jerking movements. Without recording, the bug almost never appeared, so my first thought was that the problem was related to video capture or the camera.

But OBS only helped expose the problem. Recording lowered and destabilized the frame rate, while the actual error was in the movement logic itself. To reproduce the bug, I artificially limited the frame rate in Godot to 20 FPS. After that, the old movement implementation began getting stuck consistently even during normal movement. With Shift held down, the model stopped moving altogether and only jerked back and forth in place.

The fix itself was small. I changed one line of code, and the character now moves toward the target using a method that does not allow it to overshoot that point. If the remaining distance during the current frame is smaller than the calculated step, the model is placed directly in the exact center of the tile. I also changed the order in which movement is processed. The position is updated first, and only then does the game check whether the target has been reached. When a direction is held, the next step now starts without an unnecessary pause. I also adjusted the handling of released keys to prevent movement from becoming stuck in rare cases.

After making these changes, I tested movement again with OBS, without recording, at normal speed, with Shift held down, and with an artificial 20 FPS limit. The character no longer overshoots the center of a tile or jerks in place.

This is a small change that most players are unlikely to notice on its own. However, even this minor bug took me several hours to reproduce, fix, and test. Hopefully, movement will now remain equally stable during normal gameplay and during frame-rate drops.