Game Structure
The Mill Program Structure
A program like the Mill is fairly complex and requires a fair amount of planning if you don't want to spend mode time that necessary on writing it. Here are a few tips on how I structured it myself. This kind of schema is beyond the OS or API that the program is designed for. If you write it well to begin with, then a good part of it can be translated directly into a different language and all you need is to work on the interface elements.
This kind of program can be described pretty well by a Finite State Machine (FSM). Basically an object in the game or the game itself can be in a finite number of states. From each state there are a given number of other states it can transition to based on actions being taken or anything else that happens. The Mill game can be described by three FSMs: one for the table itself, one for the the table cells individually, and one for the tokens that are being placed on the table.
Table FSM
This FSM is translated into the program as a state attribute added to the Table class combined with a function NextStep. In this function I test what the current state the table is in, take some required action appropriate for that state, then move the state to wherever it needs to be transitioned.
Token FSM
This FSM is significantly simpler. The program has a Button class handling these tokens. Its functionality is closely related to the mouse clicks, so the mouse click callback function checks the state of the button and calls a different function for each possibility. Each of these functions takes some action and then transitions the button state to whatever it needs to become.
Table Cell FSM
This last FSM is not explicitly in the program, but it can still be useful to write it down.