When designing a project like this, I like to revert back to my tried and trusted pencil and paper to draw flowcharts and after a couple of iterations I came up with this.
Whilst the process depicted above is basically correct, as it stands it’s highlighted some problems.
The diagram shows that some branches have been included to make processing simpler. Steps 17 and 12 both link to step 13 for an example, and this is going to be problematic as it would require the Sequence Counter value be updated and this is something that I don’t want to do.
There is also another problem that needs to be addressed; does the human move first or not.
This clearly requires processing to continue at different parts in the sequence depending on what the outcome is.
The diagram also implies that some steps are separate. The “Light player Win LED” implies that it’s a completely separate action from the “Has player won” rule, which it isn’t.
To make the electronics simpler, some rules will need to be repeated and this will eliminate the need for changing the Sequence Counter value, with one exception.
Who moves first
At first glance this seemed like a real pain to implement.
There would be a step in the sequence that might need to be ignored (that of asking the player to make their move), but only once. Once the machine had made it’s move then the play would definitely need to make their move. Maybe. I did say that one of the requirements was that the machine could play itself.