ijj8799's blog

Date: June 12, 2012

Time: 10:00-3:00

As stated yesterday, today I had to be careful to make sure I didn’t cause any major catastrophe that would prevent my code from working as best it can during our demo tomorrow.  Therefore, today was mostly about making minor alterations and fixing up some things.  Most of the day was spent altering the GUI that appears after the user completes a maze.  For one thing, I managed to add some colors and borders around what already existed (much of this code was borrowed from a project I had formerly done involving GUI’s).  After a little tinkering, I also managed to have the new frame have two tables, so now the user can see their score, as well as the highest score set on the maze.  This will allow them to see how they are performing at all times, so that they can strive to improve and beat the high score.

A final feature added today was an option panel.  This panel will appear when a user completes a maze faster than the high score time had registered, and simply alerts the user that they have now set the new high score for the maze.  This hopefully makes the user feel a little more confident in their abilities as they see the sign and know that they are progressing.  It is a very minor feature, but I do believe that it helps.  Tomorrow is our demo, and then I will likely begin working on my next major feature, saving mazes.

Date: June 11, 2012

Time: 9:30-5

I began today by trying to finish up the timer for the maze.  It took some work to get the variables I needed from place to place, and the ActionListener acted a little funny for a bit due to minor errors (at one point my math was off, so the timer kept track of a unit much smaller than seconds, which overloaded the ActionListener and the game), but after a little tinkering I have managed to get the timer to both keep track of time properly, and to reset when a maze is restarted or a new maze is generated.

While I was messing with the timer, I found an interesting problem that I originally chalked up to an overload of information to the system.  I’ve noticed for some time now that in certain scenarios the game freezes for a moment, making the ghost jump several positions and stopping the player from moving.  This was most noticeable when the player was truly racing the ghost, especially in a small maze where a user can sometimes complete it in as little as two seconds.  I figured that between the ghost and the player drawing things all at once (especially on the same square), this was just an overload of information, and that there was little I could do besides restructuring the code to be more optimized.  However, as I was playing the maze, I noticed that this was especially bad when I registered a wall hit.

What I found was that when a wall hit was registered, a new thread is made to play a sound.  However, after the sound is played, the thread is paused (along with other threads) for 500 milliseconds, so that the user does not register several wall hits in a short amount of time because they accidentally held the mouse over the wall for a few milliseconds.  While this seemed appropriate when the maze was just a maze and a player, it wrecks havoc on the ghost, the timer, and other things when it is constantly freezing the game.  In order to alleviate this problem (while still keeping the general idea.  At one point I registered 22 wall hits for one accident when this was removed), I removed the thread pausing, and instead stored the time the last wall hit was registered.  If the system thinks a new wall hit should be registered, it checks back and makes sure that the last wall hit was at least 500 milliseconds before this wall hit.  If it was not, the new wall hit is thrown out.  Fixing this minor thing greatly improved the performance of the game.  Though the ghost still has minor hiccups when being raced at high speeds, it is now much closer to being perfect.

The last hour or so was spent talking with other computer science majors about the game and getting suggestions on how to improve it further.  I am not sure if any were particularly useful, but we will see in time.  Tomorrow will be an interesting day.  We give our first big demo to the lab on Wednesday, so whatever I do must be finished that day, to make sure the game is working properly for the demo.  I may simply make the results box prettier, and put more stats on the front screen.  I have an interest in creating save functions and profiles, but this will likely be too big of an undertaking for tomorrow.

Date: June 7, 2012

Time: 9:15-2:15

After analyzing the code for a bit and seeing what else could be added, I decided to begin changing the look of the game a little bit.  One thing that was brought to my attention by someone who was watching the game was that there is no way to see your statistics as you are going through the maze, specifically noting the lack of any sort of timer.  Therefore, my intention is to add a timer to the maze.

The first thing I had to do was figure out where to place the timer.  It cannot be anywhere in the maze portion of the panel, as I do not want to obstruct the user’s view in any way.  Therefore, for now, I wish to place it somewhere near the bottom right corner of the panel.  I made some initial errors when trying to create this timer.  My initial thought was to somehow draw or paint a new number every time a second passed.  Of course, I soon learned that this would only work in the maze portion of the screen, so it was attempting to draw in the maze portion, in an area that was out of bounds.  Therefore, I needed a new way to show this feature.  The next option I found was to add a new JLabel.

The JLabel has now been put in place, relatively where I need it to be.  However, getting the actual time to display will take a little more work.  It will require a thread to run in the background, as it will constantly need to compare times to verify when to change.  It will also need to either reset or be destroyed and regenerated when the user chooses a new maze or resets the maze.  I have a very basic outline of how this will work, and the next time I look at the code, this will be my first priority.  After adding the timer, I may look into showing more statistics, or I may look into other things that need addressing.

Date: June 6, 2012

Time: 9:00-2:00

Today has mainly been used to clean up various aspects of the ghost, and to make sure it is working like I want it to.  The first major fix was getting the ghost to distinguish between a blank square and a square that had a path on it.  I had to look around the code a little to figure out how I made this distinction in the past.  I keep forgetting that there are two major 2D arrays in the code, maze[][] and path[][] (note to self).  Once I remembered this, it was a relatively easy fix.  Now the ghost makes the distinction, and will stop eating parts of the path.

My next move was to make the ghost generate on its own.  Up until now, I have had to hit the Restart button to restart the maze (and the time), and then had to quickly hit the Ghost button to run that portion of the code.  If I hit it late, it would skip a step or two (because it is all based on move-to-timer comparisons).  This was a relatively easy system to code, but was inefficient and ultimately frustrating.  After a bit of playing with the code, I transitioned to an on-off switch.  If the user hits the JButton, the next time the user starts the maze (thus matches the timer up), as long as a high score has been registered (thus meaning the user completed that maze), the ghost will spawn.  I am still not quite satisfied with the way this appears, as it is hard to tell if the Ghost Mode is on or off, but for now it will work.

The ghost as of now appears to be functioning as it should, for the most part.  There are a few minor glitches that seem to exist, but they are rare and may simply be the result of how much I am asking the game to do.  While the ghost is jumpy by nature, as it has to move as fast as the user moved originally, every once in a while it can get bogged down and the game gets a little slow.  This is usually not long enough to be overly noticeable, but it occasionally can impede the user’s progress for a moment.  I am attempting to perhaps make the priority of the ghost lower, to help this problem, but I cannot confirm if this has worked yet.  The ghost also occasionally fails to erase a square when it moves forward.  This is an extremely rare circumstance as of now, but it does occur.  Realistically it does nothing to alter the game, and it is erased the second a player goes over it or the ghost comes back, but it is there.  Issues such as these do exist, but they are very minor, and do not detract from the game in any way.  Thus, they are low on the priority queue.

Tomorrow I will likely finish cleaning the ghost functions a bit, perhaps change the JButton to something more to my liking, and take a look at the rest of the game.  This is a major landmark for the game, and I will need to think a bit before making my next big alteration.

Date: June 5, 2012

Time: 10:30-3:30

As specified yesterday, my first goal was to get a thread working that would allow for the ghost to coexist with the player.  Apparently, threads are not too complicated to work with.  I may have made some basic errors that will be seen later, but so far the thread seems to be working just as I need it to.

After completing the thread, the next step I took was to get the thread to run the functions correctly.  I needed to keep the thread in a loop, constantly painting new squares when needed, while the user continues to play.  Again, after a little bit of tinkering, this was mostly finished.  I did run into some issues however.  The ghost was originally supposed to make its own dotted-line path, that would be written over if a user went over it, but which would continue to exist otherwise.  However, if the ghost had to track backwards, it would erase that portion of its path, similar to how the actual user does.  I attempted to overwrite the color of the square with the original white color, but occasionally a square would be missed, causing random areas to be left on the grid, disjoint from the rest of the path.

I edited the code multiple times, but for some reason I could not get rid of these random squares, so I altered the way the ghost would maneuver.  Instead of a line, the ghost simply is shown at the square it is at at the current time.  As soon as it moves, the old square is erased, and the new one is placed.  It can be seen over the user path, which may actually may things better, as now the ghost is always visible.  With this new system in place, the ghost is almost complete.

One last issue I am facing, which shouldn’t take long to fix: the ghost right now cannot distinguish between being on the user’s current path and being on a blank square.  If the ghost paints white to blend in with blank squares, it will make Swiss cheese out of the user path if it rolls over it.  If it paints yellow to blend to the user path, the rest of the maze has yellow squares strewn everywhere.  I need to make sure the ghost can distinguish between the two.

The next step I need to take is making the ghost mode turn on a bit easier to work with, as right now it’s a bit of a rush to get it working.  Once that is done, I will likely spend some time cleaning code, and then I can look at what else needs work.

Date: June 4, 2012

Time: 12:30 – 5:30

Today was mainly spent further preparing the Java game to handle the ghost mode that I intend to implement.  I first began by making a function and a new JButton to control the new function.  These are completely temporary and will be removed in the future, but I need a way of confirming what works and what doesn’t.  Currently, as long as there is a high score in the system (so as long as the maze has been won once), once the user hits the Ghost button, the program runs through a while loop until the time matches a time that corresponds with an activation of a square in the maze.  If hit too late, this creates an infinite loop, but again, this is only a very basic temporary solution.  I have gotten the maze to draw the square that was activated, so at the very least I have a start to the process.

While playing around with this, I ran into a very strange bug that may need fixing in the future.  When the maze panel is maximized, the maze runs as it should.  but if it is in a minimized pane, for some reason the very first time a maze is won, the panel to display stats opens many times, until either a button is hit on the option panel or the entire program is killed.  This may go back to an issue I was having with panel size and missing options at the very beginning of this project, but that is just broad speculation on my part.  It appears that if I slow down the code by debugging with strategically placed breakpoints, this error does not occur, so it seems as if the program is almost running over itself.  For now I have a temporary fix where I do not make the stat panel visible more than once with the use of a boolean value, but I cannot say if this is a fix or if I am just putting a bandage over the situation.

I am now at the point where I will likely progress slower for a while.  My ability to test if the code works is limited at this point, because the while loop is required to get the ghost function to work, or else the code runs too fast to be of any use.  However, this will override any other code that needs to execute in order to allow the user to actually play the game.  This will call, I believe, for the creation of a new thread.  I have no experience in thread management and creation, so I will need to learn a bit about this before I delve too deep into it.  My next step will be to get this thread working.

Date: June 1, 2012

Time: 10:30 – 4:30

Today was mostly about adding code that will allow me to store data about the path a user took.  As a user works through a maze, an ArrayList stores which squares were used by the user, thus eliminating squares from the list that will never be used in the ghost function.  In addition, two ArrayLists that exist in every square that let their square know when the square was activated and deactivated.  When a user finishes the maze, if the time was better than the previous time, or if this is the first play through of a maze, the new stats are recorded, and the usedSquares ArrayList is stored within the HighScores class.

There were some issues that I had to fix in order to get this to work.  For one thing, it appears that in some instances squares were activated by the code that in fact were never touched by the user, thus leading to incorrect data that would mess up the ghost.  I had to pass in extra parameters to make sure that if the square was activated but actually never used, that when it was deactivate it would be removed from the list.  I was also having trouble handling backtracking, but I appear to have solved this issue as well.

My next step will be to get a function working that can sort through this data and actually use it.

Date: May 30, 2012

Time: 9:30 – 4:00

I began the day by addressing the issue with not showing the blue line after hitting the hint button in certain situations.  I am not entirely sure what was causing the problem, but after playing around with it for some time, I decided to take another approach.  I made the hint system work so that the “next proper step” shows up only if the user was already on the right path.  If they are going a wrong direction, the hint system will still pull them back to the correct destination, but it will not show the next step unless the button is hit again.  This makes the hint system a little more punishing, thus not giving away the solution too easily.  So instead of fixing the issue, I curtailed the feature to work with it, and this appears to be working successfully.

Next we had our weekly meeting.  Not much to say here, I announced my successes so far and got some info from others about what else may be lurking in the code that I have not fully figured out yet.  After we finished this, I began my next portion of the project, trying to incorporate these “ghost” characters in the game.  The first step would be to have the ability to reset a maze, without creating a new maze.  In other words, keep the generated maze the same, just wipe out any user input from that session.  It took a while to figure out what was needed and what was not (there already exist ways to clear some of this data in the code, but these are intertwined with code to generate a new maze), but it appears that this feature now works, so that a user can reset the mazes.

The end of the day was spent starting to form a new class, that will store data regarding the high score for a player.  If the user wants to race against the ghost, the program needs to know which run through was the best, so that it knows when to store info for the ghost and what to pull back up.  There are two ways in which I can deal with a high score system.  The first way would be to make the best score be completely related to time, so that the fastest run through would be the best.  The other way I can do things would be to generate an algorithm to factor other things into the score.  For instance, I could take the time at face value.  Extra squares would add 3 seconds each, wall hits 5 seconds each, and hints 10 seconds each.  Whichever resulting time ended up being the lowest, the information for this session would be stored.  For now, I will go with a purely time-based score, but I could consider the other option at some point.

For now, the score system seems to be storing and working properly, but it is very basic, so I will need to flesh it out a little bit.  The next step will be having the maze squares store data, as the ghost profile will need to know when to enter and exit square.  Because a user can enter these multiple times, I cannot make these a single value, and I will likely need to use an ArrayList to work with these.  This will likely be my main project tomorrow.

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.

Date: May 28, 2012

TIme: 7:45 – 11:45

Today is Memorial Day, so I came in extra early to fix a few things.  Today was mostly about moving towards the Objective C version of the game, and testing it in various ways.  I have only a very basic understanding of Objective C, so it may take a bit more work to figure things out in this code.

I have found the game to be incredibly broken so far.  For one thing, in almost every game I played, I glitched though at least one wall.  And this is not limited to the inner walls, I managed to actually break out of the maze and float around outside, and I also managed to get stuck inside of a wall.  Fortunately, the game is kind enough to usually let me break through the walls again, meaning I can return to the maze.  Sometimes, however, it will get stuck here, and oftentimes the game will get hung up even when I just hit the wall, and I was stuck for a decent amount of time before I was finally able to move.  In other words, the maze allows for breaking through walls, and I have managed to crush the computer’s best path by exploiting this.

This has become even more of an issue because there does not appear to me a pause menu, or any way to actually exit the game without going into the iPad’s running app panel and killing the entire application.  It is very annoying to get stuck in a game-ending glitch and to not have a quick way to at least return to the root menu.  The game also has poor restrictions regarding with touches are acceptable.  Initially, it appears that the user must touch the cursor icon to start the ball rolling.  However, after the first touch, I have found that simply touching and holding a spot on the screen will cause the cursor to move towards it, as long as there is no wall in the way (and even this comes into question, as mentioned above).  Therefore, on long straightaways and certain other scenarios, instead of dragging the icon, I just have to hold a location at the other end of the maze.  If the game is meant to test children’s motor skills, then this problem seems to have reduced it to a series of touches, rather than involving dragging and other movements.

I’m sure there may be other issues with the game, but these are the problems that I have run into so far.  I’m hoping to spend this week getting familiar with the code, and figuring out where the problems exist at.  The game needs some major work, but I am determined to get it running properly.