Yes! Thank you Mike. It does seem so simple when you get to it. Three wheel increments calling up three rounds of the spin function. By making wheel[j] = spin(j), the j gets passed along. That takes care of this advice:
"The idea is that you have a for loop in the loop function to call up each wheel in the spin function,
and you pass the loop index to the spin function.
Then you can use that passed value to pick the right wheel. wheel[0]
Will now have a variable in those brackets not a constant.
At this stage it is not immediately obvious what the wheel array is doing, perhaps we could have just incremented the spin function directly... but later on the spin function is passed this variable j like so:
int spin(int wheelToUse) { // need to tell spin to accept a symbol and then that j value becomes the index to the symbols matrix in this line;
flash(600, 200, symbols[wheelToUse][spinCount]); // quick flash for each moving symbol
The first [j] term indexing the matrix row and the [spincount] term indexing the column.
When I run the code now the serial monitor confirms that rows advance with each spin but the spinCount is uninterrupted by each spin, the rows change but columns just keep ticking along.
So that leaves this bit of advice:
Also the spin count variable should now be an array so each wheel has its own counter.
That means it will remember where that wheel was when it last moved.
Again use the same variable passed to the spin function."...
And that is what I am now pondering...
BTW - a complete aside, but at one stage I had two sets of print.ln commands, one inside the nested for loops calling up spin(j) and one in the spin function calling the flash variable... and this altered the game, such that each row was called twice, making six spins to complete the game. And I had one row decrement on one occasion. That was fun. I thought that the print.ln command was a silent observer but seems it can be an active player too.