9/20  - posted initial assignment on geeq boards
9/27  - decided to create my own game under the same guidelines for comparison
      - spent about 2 hours thinking over design and process issues
      - decided on overall process, consisting of several documents
      - documents to include : requirements, design, user guide, developers guide, development log
      - created a directory, populated with empty named text files for each document
      - brought logfile up to date
      - spent about 1½ hours filling out requirements and design document to include everything I'd thought up
      - found some artwork and playable emulators of the original pac-man for reference
9/28  - struck with conceptual breakdown of the game while falling asleep
9/29  - put last night's brainstorm into the design document
      - more late-night contemplation on data structure for game state
9/30  - finished design of game state element
10/3  - although happy with the work so far, starting to think I might need to speed up the process
      - had an idea regarding design of barriers, fiddle around in mspaint for about 45 minutes exploring it
      - spent several hours with mspaint figuring out graphical layout of basic game components
10/10 - didn't do a single thing on the project for a week
      - realized that I'm merging design with implementation too much, resolved to refocus in the document
      - spewed a bunch of design material into the document, most of it right off the top of my head
10/11 - took a couple of minutes to add a few paragraphs to the design doc
10/12 - decided to start implementation and return to clean up design doc later
      - looking up pac-man on wikipedia led me to name the game pakupaku, at least preliminarily.
      - problem #1 : I was going to start with a simple input reader - a function that you could call 
        to get the last byte of input from stdin, ignoring all previous input (allowing a player to, 
        for example, hit a directional key and then change their mind before the corner came up, etc)
        However, this apparently can't be done in java from the console, because the shell doesn't send
        the input into the stream until you hit enter. A quick search of the java forums says that it can
        be done in swing, since it bypasses the shell.
      - problem #2 : It occurs to me that even if this implementation worked, it wouldn't be good enough.
        To properly imitate the functionality of the original pac-man, it needs to check and see what key
        is being pressed at the specific moment of decision. I seem to recall something about this in the
        Game Development in Java book, using keyup, keydown, and keypressed events, or something along
        those lines. I'll have to look it up.
10/14 - Copied Animation.java from the java game developmen book, made minor tweaks to conform to java 1.5
10/17 - Created Element.java abstract class, mostly just type identifiers and javadoc at this point. Figured 
        in the design document to have an abstract class or interface for this, a quick search showed that 
        abstract class fit the design better, and it made sense to create this first because it will allow 
        me to reference elements of the game in other code objects (like the game state) without actually 
        having to implement all of them first.
      - Thought of creating daily archives for historical purposes, created a few directories and dumped files into em.
      - Created State.java class, basically just a container for the grid (2D Element array) right now.
      - Started messing around with a level configuration file, readable by the game. Loaded up a snapshot
        of the original game to design it from, realized that a few Element types might be irrelevant - vacant
        elements dont really exist, they are just a trick of the wall display. And bonus elements aren't 
        actually elements of the game, they are kind of like characters. I might take those out. Oh. Except
        empty might refer to an pellet that's been eaten. Hmm. More thought required on these.
10/19 - organized game state data into GridElement objects, each of which representing the state of the "terrain" at
        a particular point. Also started work on the Character object, to represent all the movable characters. Implemented
        basic grid generation capability, based on using character strings to represent each row of the grid. Put
        in a default grid to match the original pac-man maze. Intent is to allow user-created maze config files.
10/21 - created TestUI, tweaked a few other classes, just to make sure I could generate basic graphics.
10/26 - made some placeholder icons for characters, tweaked source a little to add characters to state and display
      - spent about a half hour researching audio for java. found one working sample program that plays .wav files, 
        and the home page of the Java Media Framework which seems to be the standard for this kind of thing.
10/27 - did some research on a different display option - the 2-dimensional array of JLabels with icons worked fine, but
        it made transitions difficult - i.e. moving a character from one grid location to another. Looked into the
        possibility of layering the interface, with the gameboard on the bottom and the characters on top, letting me
        "glide" them over the board without worrying about misplacing any of the elements already in place. Found the
        JLayeredPane object, which seems to be exactly what I was looking for. Took the sample code from the "how to use"
        page for the object, tweaked it until I got what I needed, and ended up with a pretty good looking starting
        screen sample, complete with characters slightly off-center from the elements of the board.
10/28 - I dont remember what I did this day, but some files have this timestamp...so check the archive I guess
10/31 - Resized the paku image, since the characters were smaller than I anticipated.
      - Managed to speed up the animation, now get to deal with the problem of characters and board elements positions
        not being on the same scale.
      - Got a basic movement effect in place, fast enough but not smooth. Should probably use a thread to update.
11/01 - Thinking about timing issues. Real-time animation is a bitch. Separate thread to handle general timing would be
        useful. Tossed a basic UserInterface interface (just one function - update) together, for the thread to reference,
        with the general thought that different GUIs could be implemented for the game without affecting the actual play.
        If that's fully implemented though, might have to add some restrictions to the command the GUI can send...set up
        a communication protocol between the game logic and the GUI. Which reminds me...I haven't even started the game
        logic code yet.
11/07 - Did a buttload of work and changed focus a bit.
      - Decided to start archiving the entire source tree instead of picking out individual files. Best way to see the
        changes made each day is to use a utility like winmerge on the whole directory. I recommend it.
      - Got noticably sloppier in how I implemented stuff. I've broken several object-oriented rules by tossing functions
        wherever they work, rather than where they belong. I justify this with the fact that I plan to rewrite all these
        functions anyway, and probably restructure the whole program at least once. But I'm well aware that I may not
        get around to that before the "release date". Whatever - worst case, it works but the code is ugly. I don't intend
        to stop after the initial release anyway.
      - Very excited - implemented movement control, wall detection, and pellet "eating". Verified the ability to check if
        the board is "cleared". It's starting to actually *feel* like a game instead of just looking like a familiar one.
      - Next steps, as I see them : ghost AI and movement, sound effects, then basic game logic (winning/losing, points...)
11/09 - Another busy day. Worked mostly on ghost movement.
      - Added a new abstract class called Motivation, which is used as a kind of AI for controlling Characters. Basically, you
        subclass Motivation and overwrite the getCommand(State, Character) function so that it returns the Command that
        Character should perform in the given State.
      - Wrote several sample Motivation subclasses and started putting common utilities into the main Motivation abstract
        class, simplifying generation of random movement or determining what legal moves are available (by checking for
        nearby walls) and so forth. The results are most acceptable.
11/10 - Thought of a general format for text file based Motivations, added to design document, along with a few others.
      - More work on Motivations, changed and added some. Have a pretty good base set right now, although nothing that
        represents any kind of purpose or values yet. Still, I can make the ghosts wander in relatively sensible ways,
        like not arbitrarily reversing direction, jittering back and forth. I guess the point is, they look like they
        are wandering aimlessly rather than simply at random.
      - Implemented warps, because I got tired of the game crashing whenever a character touched one.
      - Colorized the ghosts - needed to tell them apart for debugging purposes anyway, now that they move.
      - Very pleased with the NearsightedMindlessPursuitMotivation implementation at first glance. It combines very well
        the aspects of actually pursuing pakupaku and making mistakes so that all the ghosts don't act as a single unit.
        I'll test it more later on, but it seems like my first actually competetive Motivation that I could use in a
        serious level, possibly with some tweaks. A few others, like the ErraticMotivation and AimlessMotivation, are too
        simple to be much of a challenge but would make pretty good practice or tutorial levels. And the regular
        MindlessPursuitMotivation is just no fun to play against...it feels like you're up against the computer on its
        own terms, you can't win and you both know it. Must remember to use that one as a punishment or something :)
      - Noticed that I'm continuing to make very fast progress, but using horrible coding practices. I'm going to have to go
        in and clean all this stuff up, and it's going to take some time. But it's great to know that I actually can do it.
        I think that, especially when dealing with something new and difficult, I need the freedom to experiment without
        worrying too much about if what I'm doing actually *belongs* where I'm putting it or whatnot. That kind of technique
        can wait until I'm sure I can actually make it work and have built some confidence.
12/18 - Final cleanup to prepare for "archival" release...fixed icon loading to work within jar, set JFrame.EXIT_ON_CLOSE so
        the VM wouldn't sit around doing nothing after closing the window (oops). Although far from complete, I consider the
        game to be "tagged" at this point to indicate its state at the kickoff party, plus some vital bugfixes and packaging
        implementations to make it possible for people to download and examine.
12/21 - Realized that even though the jar file is tagged and ready, I should still prepare javadoc and other reference
        materials for presentation.