CAGD 377 - Slippin Away Sprint #5

  During Kickoff, we had a clear objective of what we needed to do during this sprint. Since a couple of Sprints, we planned to add a new puzzle consisting of rotating pipes and water flowing. Out of all the puzzles, we decided this would be the best to develop since our game takes place in the sewers. After that, the rest of the objectives did more minor fixes, and we also had a build scheduled for this sprint.

I’d never done a puzzle like this before and thought it would be more straightforward. However, I soon found out that it was an illusion. There were various complications when developing this system, starting with the logic. At first, I knew I needed to lay down the bare necessities: an origin, a rotating piece, and an end. I knew beforehand that the rotating piece would be the most challenging part. Despite having multiple pipe pieces, I aimed to make the rotating pipes a single script. I started by making the pipe interpolate its rotation to a target degree; the pipe will rotate to the following degree in the array. If the pipe reaches the end, then it will loop back to the beginning. I made it as easy as possible for the designer to assign:

Next, I started making a click event in which, if the player clicked on the pipe, the pipe would execute the previously implemented rotating method.

After I had the basics of the pipe, it was time to think about the connecting logic. I made various prototypes of the pipe connection system; however, they all had inconsistencies. My first theory was that the raycasting was getting the pipe model instead of the entire pipe piece, so I added ray cast layers and fixed the ray cast start position. However, I still needed some consistency when checking the connections. After having a few failed attempts at fixing this problem, I decided that it was time to take a further look at what data was being stored, and after using the Unity Debugger, I found exactly what the problem was. The code checked for multiples of 90, and because rotation interpolation is not perfect, I was left with a value like (89.9994), which, as much as It was close to 90, was not exactly 90. So, to fix this, I made a rounding-up method, which rounded whatever number used to be rounded to the nearest multiple of 90. This completely fixed the problem, and now I have a proper way of checking the pipe connections. Another issue I encountered was that the pipes were connecting to other pipes that already had a flow in them, generating an infinite loop. I tackled this problem by adding a check to see if the pipe already had a flow direction and prevent adding a new flow if one already exists.

The last thing to add for the pipe puzzle basics was adding a start and an end. This was simple to do since the code was modular, so the source pipe would check if the flow has a pipe in front, and for the end pipe, all the pipes that have a flow will check if they are reaching the end pipe.

One of the last things I tackled during this sprint was fixing some of the camera bugs in the levels and huge errors that prevented players from being able to keep playing. When Guppy reaches a corner, he is locked, and the system will seem as if it is still flying. To fix this, I made it have another check to see what its total velocity is, and if it's not moving for a couple of seconds, then it will stick to the ground. I also took the chance to clean up all of Guppy’s control code. Finally, I was able to pull my team's progress into a build and ship it for further playtesting.

Overall, this Sprint went pretty well; I had some hard time with the puzzle logic since it was something new I was trying, and also something that I’m going to start using more often when dealing with errors is the Unity Debugger since it can give you an accurate value being stored. My team made significant progress, and I’m proud of how this game turns out; I’m hoping that in the following sprints, I can improve my performance more.