Solving more game bugs

This week I played more of the game and solved the bugs I encountered.  

First, I worked on the sound issues I talked about at the end of the last blog. To expand the brief description I gave: at the end of the first major level, some rocks are spawned by the level script and pushed in various directions, the problem was that after the rocks hit the ground, the scraping sound would play on repeat until the player left the level. After a while I discovered that it was a specific rock that caused the issue. More debugging also revealed that the problem was caused only if the player went some distance away from the spawning rocks. At one point, before knowing that distance mattered, I had a couple of sessions where, after setting breakpoints and resuming the game, the issue would disappear, which was very confusing. Now I’m confident that the problem is caused by two operations that are supposed to be done in a different order. One of these is fading out the sound, which is done by physics callback presumably when the item stops rolling, while the second stops the sound if it’s too far from the player. If the first is done before the second, the sound is stopped twice, but not removed from the update list that starts it again as soon as the player is again in range. In the opposite order, when the call to fade out the sound is made, seeing that the sound was already stopped, it’s immediately removed from the update list. To fix the problem, I added removed the sound from the update list after checking that it’s too far for the player to hear and that the sound is already fading. 

Going further in the game, I noticed that an important interaction did not work. I tracked it down to physics’ ray-casting system, for which I think the problem is that the version of the physics library the game used originally returned negative distances if the player was inside an interactable object, while now they are clamped to 0. Adding the check for equality with 0 fixed it.  

Next, I found a problem in the level where the player controls a crane, with the issue being that the crane didn’t move when it should have. The way the movement is implemented is by moving the minimum and maximum limits of the joints that control the crane arm, and looking into the code, I found that the problem is with the physics callback, that was not getting called and consequently, the updated values were not getting used. I think the reason is that if the body doesn’t move, the callback is not called. To solve this, I added some code to move the crate attached to the crane in the SetMaxDistance method of the PhysicsJointSliderNewton class.  

After that, I investigated a door that was not getting created, with something still blocking the room’s entrance. I tracked the problem down to an optimization option in the creation of the wall collider, that removed the door hole and caused the door to go missing. To fix it I removed the optimization code, since it’s the solution that was also used in HPL2.  

I’ve ended the week working on a door that fails to open when it should. Since the script is calling an animation function, that’s where I’ll start debugging next week. I am at about more that two thirds of the way through the game and hopefully I will be able to get to the end, so I can start working on removing the STL containers.  

Thanks for reading. 

Leave a Reply

Your email address will not be published. Required fields are marked *