================================================================================
DONE
================================================================================

* Maintaining game state
	The problem is, what_next is getting tweaked everywhere.  Everything
	that is supposed to be done when a state change might not be taking
	place everywhere.  Perhaps what I should do is set an API to tweak the
	state, perhaps set_state()/get_state() functions would be in order.

* Create themes capability.  Instead of having game pieces hard coded in the
	program, have various theme files for the user to choose from.  Make
	this selectable and changeable at runtime without hosing the game state.

* Where to store the .gamazons file
	I noticed gnome-chess stored the user config file in the .gnome
	directory.  Perhaps there's a standard location for gnome's config files
	that I can retreive via some gnome function call.

* Generate the moves made list
	I've got that nice fancy window taking up precious real estate.  I might
	as well use it for what it was for.

* Install icons and menu features when game is installed.  gnome chess created a
	desktop file in /usr/local/share/gnome/apps.  I'm not exactly sure how
	to put the item in the game menu yet.

* Redo board drawing method
	Instead of generating squares and filling them in with squares, lets use
	pngs of squares and place them on the board.  It might be useful to
	store pointers to each square img in an array to allow easy access.
	Once the tiles are placed on the board, then draw the grid on top of it.
	This will make things much easier to replace board colors at will.  I
	could make options that let people choose tiles & pieces.  Note: Created
	theme capability so people can load new board theme on demand.


* Keeping up with option/game changes
	Some options may change during the middle of the game.  For example, the
	autocomplete would make both players computer opponents.  The network
	stuff wouldn't be able to change.  Each time the back end has to use one
	of these changeable options, it should read it directly from the source.
	
	But if we had a setup mode, the user could switch off game playing, configure 
	the board, and reenter game mode.  To accomplish this, I'd need to change game 
	recognition from a linear model (W moved this queen here, so unmark the src 
	and mark the dest as the WQ), to a discover mode (look at all the squares on 
	the board and see what is on each).  That's not very efficient for most things,
       	so perhaps just making a " discover_board" function that can be called when 
	exiting setup mode.


* Create a help file
	Gnome uses HTML files for help stuff.  Make a nice page that explains
	the rules and what the buttons are for.  In general, they should be
	installed in /usr/local/share/gnome/help/gamazons/.  Or I maybe
	(PREFIX)/share/gnome/help/gamazons is more accurate.

* Redo
	This is completely useless.  If an undo has been done a couple of times,
	and a different move has been made, Redoing by moving up a state in the
	state array would completely void the different move that just took
	place.  If a user Undos once, he can just make the same move again if he
	really wants.  This just looks like it would create more bugs and not
	add any useful functionality.

* Undo/Redo menu
	There's already a convenient Undo button on the game board.  Having two
	separate ways to access this feature is unnecessary and bug-prone.  I'd
	have to make sure that whenever one is disabled, the other is disabled
	too.  Just dump the menu options, it's not very useful.

* Handling Interrupts 
	move_ai() should call a function to disable certain event handling instead of
       	just having a silly global variable.  For instance, it could gray out the
       	Auto Finish button so the user knows it's not going to do anything when he 
	presses it.  Perhaps the 'Force Move' button should be greyed out until the AI
       	is thinking, or since Force Move & Auto Finish are mutually exclusive, it would
       	be cool to have the button switch labels depending on the state of the game.

	gtk_button_set_label(GtkButton *button, const gchar *label);
	gtk_widget_set_sensitive (GtkWidget *widget, gboolean sensitive);
   	time = lookup_widget(PlayerSettingsWindow, "TimeSpinner");

* Have a popup declaring the winner
* Computer moving queens:  
	Instead of having the queens just pop around on the board when the
	computer is moving, the queen should slide so the human can see what
	piece is moving.  I should be able to do some kind of move, maybe one
	pixel at a time.  Just calculate the origin and the destination, and
	they _should_ just be straight diagonal (increment x coord by 1,
	increment y coord by 1, draw), or horiz or vert.  If moving by 1 is too
	slow, we could make it 2 or whatever.

* Remembering values:
	I need to store user options in a .gamazons file.  When the user presses
	OK in the player preferences, the values should be stored in this file
	as well as in the global options struct.  Then, init_engine() should read
	in the values from a file (if it exists).

* Website requirements:
	Explain how I verified that my program works
	Explain what it takes to compile and run the program
		Requires Gnome2
		tweak a header file to compile amazons instead of gamazons
	Post source code
		Include a copy of the GPL w/ the source
	Explain what it takes to run the program and how to use it

* Keeping the GUI & engine in sync
	Currently, amazons has a state stucture that is local to main and passed
	around wherever deemed necessary.  Gamazons needs access to this, so
	maybe I should make it global.  I can still make a pointer to the global
	and pass that around so I don't have to mess around with all the
	function prototypes.

	I need to create some coordinate conversion routines though, since 0,0
	is in the bottom left for amazons, and top left for gamazons.

	I also need to find a way to let the engine know when it's the AI's turn 
	to move.  I may need to take out it's ability to think during its
	opponent's turn for this to work properly.

	I currently keep track of game state on the GUI side as well as on the
	engine side.  Should I dump the gui state and focus on the engine state?
	Or is the convenience of not having to convert coordinates every time I
	need to use one worth the inconvenience of keeping both in sync during
	every change? -- Ugh, keep two, just keep them in sync.
	
* User input while the AI is thinking...
	I should set a flag at the beginning of move_ai() that sez the computer
	is thinking.  Then at the beginning of all callbacks, I should check to
	see if the AI is preparing to move and ignore all user input until it's
	safe.  While I'm at it, I should also make a check that if it is a human
	player who's turn it is to move, that the human is moving his own
	pieces.  ie, if it's white's turn, he shouldn't be able to pick up black
	pieces.

* Playing the game
	Once the board is drawn and all the signals are registered, call a
	function that checks if the first player is the AI or human.  If it's
	the AI, start the searching process for the next move.  If it's a human,
	just fall out of the function and don't do anything until the human
	makes the first move (or maybe I could start the thinking process while
	the human thinks also.  However, that may be more complicated and I
	should start small and work into that one).  Then at the end of
	processing the move signal (perhaps at the end of the fire_arrow
	callback), I could check if the next move is done by human or AI.

	I'll probably have two different functions for processing human moves
	and AI moves, so I'd better make sure both work.

* Text mode vs GUI mode
	I would like to maintain both versions, as each one has its place.
	Everything that's text dependent should be bracketed with 
	#ifndef GAMAZONS, and stuff that's GUI dependent should be bracketed
	with #ifdef GAMAZONS.  

* handling options:
	Instead of having several dozen global variables, each covering a
	different option, I could make one big structure, covering all options.
	Then I can create sub structs for network, players, etc...

* Drawing the board
   	it looks like I can use gnome_canvas_item_move to move a queen already placed
       	on the board.  Perhaps I should draw the board initially, registering all the
       	callbacks with them, etc... and then just use that to move them.  But then what
       	does the draw_board function do?  gnome-chess called it all the time. 

	looks like gnome chess just used board_update to see if any pieces were taken
       	and deletes them if they are.  I don't know if I need to draw the board after
       	the initial draw.

* Text looks messed up with custom fonts & fixed game board size	
	On Michael's computer, the game looked pretty screwy.  I dunno what
	font settings he used, but it made it look pretty messed up.
	Unfortunately, my board is designed to be precisely the size it is.  The
	user doesn't have the ability to resize the game, board or pieces.
	Unfortunately, this means people with high resolutions can't make the
	board any bigger and people with low resolutions can't make it any
	smaller.  To change this, I'd need to learn how to scale the pieces, the
	game board, and redo all the calculations which determine where pieces
	are and where to move them to.  If this were fixed, people with
	different fonts could resize the board so it looked normal to them.
	NOTE: Possibly fixed by just making more space for text

================================================================================
TODO
================================================================================
* Showing the latest square fired on:
  	The square the AI (or human) fired it's arrow on could be a different color 
	or shade until the next move starts.

* Undo
	Instead of having a straight state struct, maybe I should have an array
	of 100 of them.  Then I could include a current move state and a max move
	state so I could skip forward and backward.  

	Hmm, should I keep 100 of both states? or just keep all those states on
	the engine side, and use the GUI state only for the current state of the
	board?  I'm currently inclined to just have the array on the engine
	side.

	What should Undo do?  If a human player has moved a piece but not fired
	yet, undo should just move the piece back.  In this case, the engine
	wouldn't need to be notified because the move isn't registered to the
	engine until the arrow is fired.  If the human is playing an AI, the
	Undo should go back to the last human opponent.  

	When can Undo be used?  Once autofinish has started, Undo won't be able
	to find a human opponent.  So it should be disabled once autofinish
	starts.  I don't want the AI interrupted by Undo once it has started
	moving, so it should be disabled once move_ai() starts, and can be
	renabled at the end.

* Have AI verify legality of Human move?  Have GUI verify legality of  AI move
	Would it be useful to, when registering a human move w/ AI for it to 
	verify the move was legal?  How about the GUI verifying an AI move is
	legal?  Having these checks might catch inconsistencies in the game
	design, and perhaps end the game gracefully, warning the user a bug has
	just occured.  When this happens, I could dump the GUI state & AI state
	to a text file, along with the offending move attempt to enhance
	debugging.

* Different difficulty levels & Separate AI settings for each player
	I want to create different difficulty levels for the AI player.
	Starting with 0 = random and moving up to 10 or so, adding one more
	heuristic at each level.  

	But then I'd like to separate the AI level, time, width, and TT.  That
	way I can pit one player up against the other without them "cheating" by
	knowing what the other player will do.  

* Have a preview pane for different themes.
* Make option to just see game board



================================================================================
FIXED BUGS
================================================================================
Black was set for a long run.  I shortened the think time.  Then I hit force
move.   I think on black's next move he gained an extra queen and walked right
over a queen & wall.  RESULT: Black suddenly had 5 amazons instead of 4.
SOLUTION: when hitting 'OK', it called move_ai().  I added a global flag 
' moving_ai' that it checks to see if move_ai() is already running.  If so, it 
doesn't call it.

After hitting Force Move, at the end of the game I pop open the player settings.
It has both opponents set as AI (note, I should probably _always_ read in values
from the .gamazons file instead of the widget's current values).  I hit ok,
which saves those values to my .gamazons file, and then new game.  At this
point, both players should be AI, but it insists on waiting for the human to
move the AI.  Also when the game starts up in this state, it insists on waiting
for the human to start.

If both players are set to AI, and I have 'while(move_ai)' call in my main init
function, the board doesn't have a chance to get drawn until the game is over.
SOLUTION: Don't call 'while(move_ai)' from init_game_board().  If the user
really wants the AIs to play against each other right away, he'll have to select
New from the menu.

ugh, now when I autofinish & select New game, I can't move my piece.  SOLUTION:
move_ai() only changed the what_next variable if an AI player actually moved.
Since New Game initialized what_next to WAIT_FOR_AI before calling move_ai() and
White was set as a human player, we were stuck in WAIT_FOR_AI mode and couldn't
move any pieces.  To solve this, I move the code that updated what_next outside
of the "if AI is moving" block.

If you hit 'autofinish' after the game has ended, selecting 'new game' doesn't
start the game in a useable state.  It's white's turn to move, it's set as
human, but what_next = MOVE_AI.  SOLUTION: Disable Autofinish & Force move at
end of game.

A4-C6, A7, undo moves the white piece on top of the black piece.  Solution: the
new gui state machine only updates the to/from values when a legal move occurs.

if you make a move, then change the theme, and press undo, the thing totally wigs 
out. SOLUTION: Disable 'Settings' menu inbetween moving a piece and firing an
arrow.

move d1-d10, as it slides back, move a4-g10.  it freezes momentarily, now  move 
j4 quickly to a7 and now x is dead or your window mgr freezes.  SOLUTION: Don't
allow other game pieces to be picked up when another piece is sliding.

search time = 1, max depth=0, max width = 0, white = AI, black = AI, press ok.
You get a bazillion error messages and the pieces don't play.  SOLUTION: set the
minimum max-depth value to be 1.

After setting both players to AI, completing a game, selecting white as human
and starting a new game, I can't pick up the white pieces.  SOLUTION: new board
state machine fixed this.

Playing with setting both players to AI, w/ time = 1, depth=1, width=0.  trying various
combinations of depth=0/1 and width=0/1.  Sometimes I can't get the game to start w/
both as AI, and switching to white=human, I can't pick up the pieces.  SOLUTION:
new board state machine fixed this.

settings->theme, press OK w/o selecting a theme.  Program quits w/ error, cannot
open theme *.theme.  SOLUTION: have load theme from file return FALSE if it
can't open the file, then handle the problem gracefully instead of trying to
process it.

Ack!  isearch() returns a move struct.  Not a pointer to a move struct.  Note: 
the data holding this move struct is located in isearch(), and once this function
returns, its value is no longer guaranteed to be valid!  It just _usually_ is. 
This is the most likely cause of the repeated FORCE MOVE button coming back with
wacked out moves.  I'm getting moves like: 50. g-6375-g-6408, d-6318 and 
a1-g-6377, b-6358  SOLUTION: make sure isearch returns a valid move struct

================================================================================
BUGS
================================================================================

Anca somehow managed to lose a queen in the middle of the game when it was moved
to the right edge of the screen.  She was more inclined to miss her target
square & hit undo, but so far I haven't been able to replicate it.

When restarting a game, I should free the malloc'ed board struct.
destroy_board() would probably be a good place for this.

0.81 bugs:

Have theme window open, press autofinish.  Select theme.  It's not autofinishing
anymore, and the settings menu is blocked out.  Also, if the theme changes while
a piece is in midmove, it wigs out. 

Changing themes as a piece is moving makes it wig out.  

If you have a settings window open, then make a partial move you can then change
any settings and muck up the game. 

Pressing undo again as the piece is sliding back loses a queen.

dragging a queen off the board miscalculates its location: ie A4-D3 but further
off to the right, the queen slides back to A2, during which time you can press
undo and totally muck it up. 

Set white=AI, black=HUMAN.  New Game.  White moves, change black to AI.  Black
moves, white never moves again. 

Move history is screwed up.  G1-G7, D7: history shows d10-g7, d7

0.82 Todo

when a window is open, ignore all clicks on the board.  This will keep people
from opening settings windows, then making partial moves etc...
	- What about only being able to open a single window?  Ie - if I have
    two windows open, and I close one, the open_window count is set to false and
    it doesn't know there are other windows open.  Instead of having TRUE/FALSE,
    values, inc/dec the counter, and when it's zero it's safe to reenable
    buttons.
X Disable certain interrupts when a piece is sliding (ie theme changes, undo, etc)

X Do error checking on board location.  If a piece is out of bounds, it's not a
valid move.

X Fix history window for human moves

X Fix state machine processing of player setting changes.
