Alpha Beta Move searching started, still WIP.  Evaluation methods
changed to be relative to white, and then flipped if necessary.

The new Alpha Beta move search can handle depth of 5 pretty quickly, and
6 isn't terribly long.  A huge improvement over the previous Negamax
implementation.
-Changed alpha/beta initializations to correct values
-Added hasMoved attribute updating in alpha beta move processing so the game doesn't try special moves like double pawn moves/castling after having forfeited the ability to do so.
Alpha Beta Fixed

For the most part Alpha Beta move searching works now. There seem to be one or two edge case bugs left hidden somewhere that can come up and throw exceptions, and I haven't tracked them down yet.  The AI plays a very logical game though for the most part, and can search to a depth of 5 in 30 - 50 seconds.  It's still decently strong at depth 4. It does drop pieces here and there but I'm not sure if that's an Alpha Beta glitch or the horizon effect.

Issues:
-It's possible that some weird side effects could be introduced by the alpha beta search looking for moves when none exist (I.E. checkmate/stalemate), so some research should be done in that area.  For now I've added a check at the end that will set the score variable to an unfavorable value (very positive values for AlphaBetaMin, very negative for AlphaBetaMax) if there are no legal moves.
-Occasional exception gets thrown in the end game when there aren't many moves.  Not sure what causes this.

Not really an issue, but a good next step would be quiesence searching.  Alpha Beta is stopping purely at when it reaches a certain depth, which is conducive to the horizon effect.  Adding quiesence functionality after some refactoring would avoid this.
Principal Variation Move Ordering Implemented
-Restructured the GameTreeController to actually hold a living copy of the game tree that gets updated and keeps track of all legal moves explored.
-Updated the alpha beta recursive methods to use this instead of looking for legal moves all over again.
-Set up principal Variation move ordering (when a new alpha/beta value is found, that node gets moved to the front of the parent's children array, so that the next time it is visited, it will the the first to be examined).
-Removed a cloned method (processMove) in the controller, so that the AI method gets called directly, and the method for the user calls validation checking and then the AI method once the move is known to be valid.

Note: No notable performance gains from adding PV, so there's probably still some issues going on.  Need to go back to Alpha Beta without PV to record number of nodes visited and search time for comparison.
Iterative Deepening added, Principal Variation move ordering complete

-After adding Principal variation to the move ordering consideration, the amount of nodes visited increased dramatically. After more research I learned this is because PV is ususally used with Iterative Deepening, (so you scope your favorable nodes in the previous iteration, not the previous move all together.  ID brought the amount of nodes visited for 5,4, and 3 ply searches very close to the optimal values.

Note: The engine is searching to depth 5 quite quickly now, but it seems to be dropping more pieces.  I think is is because of the lack of quiesent searching, which is next on my TODO list. After that the engine should be stable and I'll refactor some of the structure of the program (multithreading for GUI/passive analysis, so the game doesn't seem to freeze while the AI is thinking. This would allow for a progress bar to reflect the status of the AI's progress, which doesn't currently work without multithreading).

The issue of the BoardController trying to set pieces outside of the board bounds (-1 or 8) is persisting, and seems to happen mostly with pawns.  This could be causing the engine to miss moves because it mistakenly tries to put it on the wrong end square (which isn't legal) and then thinks the real move is illegal because BoardController throws an error if it isn't a legal operation.  This will be addressed after QS.
Consolidated alphabetaMax and alphabetaMin into a NegaMax method. Fixed bug in iterative deepening loop (which was making it look like search had become fast, it's actually slower than before ID. Still a lot of tuning to do). Added capture prioritization in move ordering. Tried to optimize Positional Score evaluation, so it would generate the legal moves and store it back in the tree, or use them instead of finding them all over again if they had been calculated already.  Pretty much all of these changes ended up slowing down the engine, so they need to be fixed since apparently they weren't implemented correctly.
Move ordering fixed, Killer heuristic implemented, Iterative Deepening fixed, refactoring
-Refactored AI.ChooseMove so that it calls alphaBeta and alphaBeta keeps track of the best move so far, so that ChooseMove doesn't have to clone most of the alphaBeta method for the first ply. Also realized that the ID loop up to Constants.getDepth() -1 was there for a reason, since Choose Move used to check the first ply.  This helps, since I though the search was going one ply less deep than it was. TL;DR: Performance is good after all
-Fixed a bug where castling wasn't getting undone when it was simulated. Added named constants for all columns while I was at it, so there aren't as many raw ints floating around.
-Tweaked move ordering and PV/MVV-LVA weights so that it matches the chessprogramming wiki, and performance did improve accordingly.
-Added a menu item so users can choose a depth from [1,5].  Game still crashes when using a depth of 6, so I'll probably need a transposition table to go any deeper.

Engine is pretty stable now, and ply 4 searching is almost instant. Need to double check that all algorithms are helping (disable them, check nodes visited, enable and run again to see that they make a positive difference) and then I'll move forward.  It does look clear that horizon effect is detrimental to performance, especially on lower ply searches, so avoiding that is the next priority.
Added Quiescent search, refactored PV search
-Quiescent search now called at max depth, not eval.  Big boost in performance from this.
-Adjusted PV, seems to have better performance now
-Removed game tree from GUI and stopped maintaining it in the backend in an attempt to reduce memory footprint, since I don't need it anymore for development.  Will add a "Pieces captured" view in its place.
-Fixed bug that was trying to let pawns capture off the side of the board
-Modifed how the engine handles pawn promotions, as it was letting them move to the 1st or 8th rank and didn't know what to do that that point.  Now when a pawn moves to those ranks a PawnPromotion flag on the move is flipped, and the engine will consider it as a promotion to queen (will add promotion to other pieces soon, very easy to do).
-Added small reporting counters, such as branching factor.  Most are commented out but can be uncommented and are working.

Performance is still not where it needs to be.  Memory management is a huge issue, as ply 4 games often crash because the GC can't handle it anymore.  More research needs to be done on this so that the engine can look deeper.  Bit boards/transposition tables would help but will be a challenge to implement.  Null Move heuristic is another thing I need to implement, but still unsure of how it fits in with PVS/AlphaBeta/all the other algorithms.
Minor bug fixes
-Adjusted how game remembers gametree
-Added code to guarentee that the best move found so far is picked form the PV

AI still doesn't know what to do in the endgame, and memory leak prevents long games of 5 or 6 depth.
Captured Piece Panel added

The pieces that have been captured are now displayed with new half-sized images of the pieces, sorted by value.  This is where the analysis panel used to be, since it is more relevant for a user than all the branches that the computer considered.
Adjusted positional score weight and material score weight. The engine seems to drop material pretty often when the positional weight is 25% of it's consideration. Lots of tweaking to be done here.
Checkmate miss bug fixed
-Added check in Evaluate method to check for each side being checkmated, and to override the calculated value of the position if so.  This seems to have fixed the problem where an obvious checkmate is possible and the AI doesn't choose it.

TODO: Account for draws by 3 fold repition and stalemate.  I've seen the AI fall for these in a winning position in many games because it doesn't realize what is going on.

Also the AI seems to still be dropping pieces occasionally. It's hard to see what is causing that but I need to dig into that.
Started code to account for draw by stalemate and threefold repitition in eval method
-Both still need to be tested, the AI is missing one-move checkmates in some cases, and getting out of bounds exceptions on the 3fold repition method.
Fixed draw by three fold repetition bugs.

AI now detects 3 fold repetition correctly and will avoid it in a winning position, as well as stalemate.

AI does still miss some obvious checkmates, that's next on the list.
Weight adjustment menu, castling thru check bug fixed
-There's now a menu where you can tweak the weights the engine uses for material, position, and bonus scoring.
-Fixed a bug where the engine would try to castle through and into pawn checks, because the pawn didn't think it could attack the given square because the king wasn't on it yet.  Now the move to the inbetween squares and the final square are simulated so pawns will know if they can go to that square.
-Changed killer move arraylist to hold moves, not nodes, so that references to the nodes get released when the node does.
-Fixed bug where resetting the game doesn't reset the list of captured pieces, resulting in an accumulation of pieces for multiple games.
-Changed default weight of position to .1 and material to .8, since it seemed to drop pawns for better mobility.
Null Move Heuristic WIP
-Started Null Move Heuristic, still WIP. Issues with En passent since it depends on the move list to know which piece to remove, and when one side moves twice in a row that can disturb the traditional move sequence.
-Added evaluation of position after AI moves, to give an idea of what made it pick the move and how good it thinks the position is.
Updated documentation and minor refactoring

-Marked some old methods deprecated that are no longer needed
-Added named constants for checkmate scores and draw scores
-Added documentation on some new methods and moved around other methods for readibility.
Added logging, debugged the pawns getting added but not removed from the
piece lists.
-No clear fix yet. Still WIP
Extra pawn bug FIXED
-Apparently I left an if condition from some of my debugging over the null move search reduction but commented out the statement that went with it, so a line that removed pawns from the piece lists that should have been executed every time only got executed when the if clause allowed for it.  The if clause has been commented out with the code that went with it and extra pawns are no longer being added.
Null Move Search reduction fixed
-Forgot that pvSearch assumes a valid set of child nodes, so those had to be cached and a new set generated of the opposite color since the previous children were of the opposite color as their parent. Since we're looking at a null move they needed to be the same color.  After the search the real children are restored

Engine plays pretty quickly with this in place. It almost never looks farther than the 1st or 2nd branch, but hopefully that's a sign of good move ordering. Still getting some "king not found" exceptions in the end game, and the game crashed when I tried to bump it up to depth 6, but once that is working I think the engine will be quite strong.  It got Chess Titans to a rook + minor piece endgame and was 1 pawn up with black when it crashed on Level 7 at depth 5, so I'm ambitous about what it can do at higher depths now.