20170306

Mastermind Game #4: Input flow done

ARDUINO: Contrary to originally planned, the random assignment of the solution and the routines to check the players guess towards it have been pushed to the next update. Before that get put in, it made sense to finish up the general flow of input and storing the history of guesses in a game.

And it was quite the little brain-teaser. I totally overthought the problem. Juggling an array-slice around for the editing part, and then push that to the history array. Which caused problems when browsing the history and deciding to go back to edit.

A little rethink later, and keeping with the adage that simpler is better, I decided to do the edits directly on the last entry of the main history array. A little fiddling about later, it was all working as intended. Mind you, all in all a good few hours went the way of the dodo before I got that far.

Github repo for this stage.

At this point I may as well go a bit into depth on how it is all controlled. Inside the state_t struct, you'll find there is a variable named mode which is defined earlier as an enum. This to make the later main gameLoop switch more intuitive. I could have just used a number from 0 to 2 to jump between modes, but having named values makes it so much more readable.

Out of the state_t struct I make an instance of which inside the loop() namespace called state for passing along to where it is needed. This to avoid using globals. Globals are by and large evil. Passing data by value or reference is much safer. That way, one can control which functions can only make local changes - and which can manipulate the data so it also effects other functions.

Further on - each mode got their own little function, that will run as long as the variable switchMode in the state instance remains false. Once the user do the action to proceed to another mode, this is set to true, and the game jumps to whatever mode is then set in the mode variable in the state instance.

What mode to go to will vary a bit depending on both what mode one is in, if it is the first turn or if it is the last turn. In edit mode, one can only go to browse mode - unless in first turn. In which case it makes no sense to browse the history, so one is taken directly to the commit mode. This is handled by this ternary expression:

s.mode = (s.tries > 0) ? browse : commit;

Which do the same as the more verbose:

if(s.tries > 0){
  s.mode = browse;
} else {
  s.mode = commit;
}


Likewise, in the commit mode if one is at turn one and try to go back to browse, it is denied since there is no history to browse. Come to think of it, I should add an else there (or do another ternary) to throw the player back to edit of the first turn. Though shouldn't matter. The first turn will be a wild-ass guess at any rate, as there are no clues to go by.

When in browse mode, one can go back and forth in the history. If pressing the select button whilst not at the most recent entry, one is taken back to edit-mode and can make a change to ones current guess. If pressing the select button whilst at ones most recent guess, one is taken to the commit mode.

In commit mode, one can confirm the turn by pressing select - or go back to browsing by pressing the go right button. It may be a bit superfluous, but I like the added confirmation or go back option this mode provides.

And that is as far as I've gotten. Still not at the stage of being playable - even through Serial-monitor. But now all of the basic structure and setup is complete. So next time, the random colours selection will be put in, and the routines to compare the guess to the solution and store the result in the history instance of the ledOut_t struct.

Maybe even start to breadboard up a few LEDs and hook up the Shift-Register - but I'm not promising anything :)