Office Hours

  Well this was the first week of School for our kids and the quiet has been appreciated.  I finally got the attack flow lines working correctly on the screen.  Colors flow down the line attacking the next square as requested by the user.  Sounds simple, but once I switched from the previous (single touch attack) method, I realized I had a bit more redesign to get it working the new way.  Of course, the stuff I ripped out was running the A.I. opponent moves, so those have to be reworked.  The A.I. opponent engine needs lots more smarts anyway, so this work was expected.  On the plus side, it is really easy to kill the A.I. for the user...
    Although this was a short week, I did find a lot of good design/discovery/coding was accomplished in the 4-6 hour window of time when I had the house to myself.  Sometimes your brain just needs a bit of uninterrupted time to properly analyze a problem and find a solution.  This week has given me a few of those periods to really dig into the code and refactor* the problem parts.   Sometimes when you are looking at multiple files and parts of the code you find yourself 'code juggling'.  This juggling of ideas and things to do can keep you from getting the work done.  Its distracting.  You either get serious tunnel vision to fix an issue or eventually drop the balls and go do something else entirely.  You usually need to fix one issue to reduce the number of items juggled.   I find that if I can get a few hours on my own, I can juggle a few more balls and get stuff fixed.
    Where am I going with this?  I guess I am thankful to get back to work on a more consistent basis and grateful for those occasional distraction-free periods.  It is good to "be back".  Now onto those A.I. flow lines...


 
   * In programmer language, we call this revamping of the code as "refactoring".  I use the term a bit generally, because true refactoring is a series of steps to clean up poorly designed or maintained code.  You start by setting up some tests to prove the code works the proper way.  Then, you redesign the code to shrink the problem areas and hopefully make the area more clean and understandable for the next programmer.  Lastly, you run the original tests to insure you did not wreck the original purpose of the code.