Simon Game programming

But is it true that every turn I have 3s of timeout time ? But it seems to me not on hardware ><

Well, procedures so means once it done execute the output code, then it will automatically go to input code ? Flow according to the code ?

Thanks

Vincent19:
Does that means that we need to respond faster as the counter increases ?

///////////////////////////////////////////////////////////////////////////
// Slowly cranks up the pressure
void increaseSpeed()
{
  if (turn == band)
  {
    beepdelay = 170;
    pausedelay = 80;
    return;
  }
  if (turn == band * 2)
  {
    beepdelay = 150;
    pausedelay = 60;
    return;
  }

  if (turn == band*3)
  {
    beepdelay = 120;
    pausedelay = 40;
  }
}

///////////////////////////////////////////////////////////////////////////
void loop()
{
 for (int y = 0; y < WINSTATE; y++)
 {
   output();
   input();
   increaseSpeed();  // <---------------------------------- THIS is the part that makes it go faster as the game proceeds
 }                                                               It calls the procedure "increaseSpeed" defined above
 
 win();
 
}

in the "for" loop above, until the player either wins or loses, the output code is executed, then the input code is executed, then increasespeed, and then back to output, etc.

John

Ok, the speeed of the output goes faster. However, based on the full coding, does it means that the time I need to respond also getting faster ? Cause I seems to feel it when playing it ><

Ok, so either the player win or lose, it will follow the sequence : output > input > increase speed. And the final win(); is for what ?

Thanks

Vincent19:
Ok, the speeed of the output goes faster. However, based on the full coding, does it means that the time I need to respond also getting faster ? Cause I seems to feel it when playing it ><

I don't think so, because RESPONSETIME is a defined constant and doesn't get changed.

Ok, so either the player win or lose, it will follow the sequence : output > input > increase speed. And the final win(); is for what ?

Up above is the definition of the win() "procedure". Looks like it beeps a certain way and flashes all the lights.

The loop() procedure at the bottom of the code is called over and over by the Arduino framework code. Therefore, win or lose, the player gets to keep going (but I think the score is reset once you lose). loop() - Arduino Reference

The loop() procedure "high-level" code being at the bottom is typical of c and c++ coding style, with the definitions of the procedures/functions/subroutines above.

Note I am answering these questions from quick, cursory examination of the code because it is well organized, factored, and very good names for the variables. (But I could have missed something :slight_smile: )

Have you programmed in any other languages? If so, what?

No..just arduino languages. So , win() will only be call once the for loop finish executing in void loop() ?

Vincent19:
No..just arduino languages. So , win() will only be call once the for loop finish executing in void loop() ?

Yes, it will be called after y<WINSTATE becomes false. WINSTATE is defined as 32 so it appears that the for-loop will loop 32 times.

I am very curious and dont understand for the part if(counter> RESPONSETIME)

How is that ? the counter will increase in every loop, so in every loop it is getting closer to exceed RESPONSETIME isnt ?

Vincent19:
I am very curious and dont understand for the part if(counter> RESPONSETIME)

How is that ? the counter will increase in every loop, so in every loop it is getting closer to exceed RESPONSETIME isnt ?

Yes. It looks like the player has something slightly over 3 seconds (RESPONSETIME=3000) to push the buttons in proper sequence, or else he fail().

slightly over 3s ? not less than 3s ?

Vincent19:
slightly over 3s ? not less than 3s ?

Yes.

Mean the player has more than 3s before they fail ? LOL I thought less than 3s before they fail !

It could be under 3s depending on the accuracy of your particular Arduino crystal or resonator. Why don't you devise a way to measure it against an atomic clock reference standard and get back to us with the results.

I will record a video later on. :smiley:

johncc:
It could be under 3s depending on the accuracy of your particular Arduino crystal or resonator. Why don't you devise a way to measure it against an atomic clock reference standard and get back to us with the results.

This is the video. You can observe that the timeout is quite fast sometimes..LOL

johncc:

Vincent19:
Ok, the speeed of the output goes faster. However, based on the full coding, does it means that the time I need to respond also getting faster ? Cause I seems to feel it when playing it ><

I don't think so, because RESPONSETIME is a defined constant and doesn't get changed.

Ok. Nice video :slight_smile:

Since counter is never reset (other than when you fail and start over), it means you have a total of (slightly over :slight_smile: ) 3 seconds of "decision time" through the whole game (the variable "counter" represents accumulated player response time through the entire "game").

So it's not that you need to speed up your input as the game goes on, rather it means that your input needs to be as fast as possible the whole time!

Have you tried increasing RESPONSETIME to a more reasonable value (say, 10000)?

Cheers,
John

You would be able to see this happening if you put a print statement in the output function as below and then watch on your Serial Monitor

   Serial.println("");
   Serial.print("Turn: ");
   Serial.println(turn);

   Serial.print("Response time millisecond total: ");  // add these two
   Serial.println(counter);

johncc:

johncc:

Vincent19:
Ok, the speeed of the output goes faster. However, based on the full coding, does it means that the time I need to respond also getting faster ? Cause I seems to feel it when playing it ><

I don't think so, because RESPONSETIME is a defined constant and doesn't get changed.

Ok. Nice video :slight_smile:

Since counter is never reset (other than when you fail and start over), it means you have a total of (slightly over :slight_smile: ) 3 seconds of "decision time" through the whole game (the variable "counter" represents accumulated player response time through the entire "game").

So it's not that you need to speed up your input as the game goes on, rather it means that your input needs to be as fast as possible the whole time!

Have you tried increasing RESPONSETIME to a more reasonable value (say, 10000)?

Cheers,
John

Okay, I think I get you ! TOTAL ACCUMULATED of delay time before the user input throughout the game which will cause sometimes the game to be game over very fast ? Is it correct ?

Thanks.

Vincent

Vincent19:
Okay, I think I get you ! TOTAL ACCUMULATED of delay time before the user input throughout the game which will cause sometimes the game to be game over very fast ? Is it correct ?

Thanks.
Vincent

Yeah, that's the way I am reading it :slight_smile:

Did you build that from a kit or what?

John

yes, a kit.

Link : Make: Projects