Date: May 29, 2012
Time: 10:00 – 4:30
Today I delved back into the Java version of the game to tackle a few bugs and glitches that I have encountered. It’s a day to clean up code and get things ready to look nice. I will smooth over what I have done, and then I can move onto other areas that need fixing.
The bug I have been most bothered with is a glitch where if a user does a U-turn type of motion around a wall (so go up, right, and down, or some other combination), they can pull the path through the wall to practically make a square, and the game responds by removing the U-turn portion and acting as if the user had undone the turning portion of the solution. While in reality this is not a major bug, as it only makes it slightly faster to undo a U-turn, it allows users to cheat in some ways, and with a game such as this, where it is specifically meant to track motor skills and allow players to develop these skills, shortcuts such as these only hinder the game’s basic purpose.
After a little playing around with the code, I managed to fix this issue. It seems as though the code had an initial check to see if the block a user is moving to is reachable from some direction, and that that direction has a portion of the path connected to it. After that, it just tells the program to traverse through the maze, getting to that location in any way possible. Because technically it was reachable from a portion of the path, it was returning a false positive for this specific choice, and thus was traversing. In order to fix it, I decided that this initial check must also know in which direction the movement came from. If the user dragged left, but the connection is at the top, this is not what the user chose, and thus returns a negative. It took a little tweaking to not affect the other code, but it now appears to prohibit this movement.
Another thing that needs fixing is the “win screen.” When the user completes a maze, black text is thrown on the screen, saying that they won and giving them some statistics such as time and extra squares visited. This text is hard to read, and is very much obscured by the maze. In order to fix this, I have begun creating a new JPanel with a JTable in it, to organize and clean up the display of the stats. Right now all I have is a basic table popping up in a panel, although it is formatted rather nicely already. I will consider adding color and other effects to make it more eye-catching and appealing (after all, the user won, they should be rewarded to at the very least a cool-looking table).
Towards the end of this session, I ran into another bug that I have not quite fixed yet. My “Hint” function was designed to take the users to the last square that was on the correct path in the maze, and then show them the next square that they must move to. For some reason, in rare circumstances (usually when their location was close to where they needed to be, but blocked off by a wall) the program fails to draw the next correct movement, it only manages to take the user back. I am not exactly sure what is causing this, it appears to be either something wrong with my draw calls in these rare cases, or something is deactivating the squares of some ilk, causing the program to not be able to write onto them. Either way, this is an issue that I will need to tackle soon.
Tomorrow I may play with the Java code a bit more, we have our weekly meeting, and I will likely look at the Objective C code a little more.