Go Down

### Topic: Simon Game programming (Read 4617 times)previous topic - next topic

#### johncc

#15
##### Jan 23, 2013, 04:57 am

slightly over 3s ? not less than 3s ?

Yes.

#### Vincent19

#16
##### Jan 23, 2013, 04:57 am
Mean the player has more than 3s before they fail ? LOL I thought less than 3s before they fail !

#### johncc

#17
##### Jan 23, 2013, 05:45 am
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.

#### Vincent19

#18
##### Jan 23, 2013, 05:50 am
I will record a video later on.

#### Vincent19

#19
##### Jan 23, 2013, 07:49 am

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

#20
##### Jan 23, 2013, 01:37 pmLast Edit: Jan 23, 2013, 01:44 pm by johncc Reason: 1

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.
Quote

Ok.  Nice video

Since counter is never reset (other than when you fail and start over), it means you have a total of (slightly over ) 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

#### johncc

#21
##### Jan 23, 2013, 01:45 pm
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

Code: [Select]
`         Serial.println("");   Serial.print("Turn: ");   Serial.println(turn);   Serial.print("Response time millisecond total: ");  // add these two   Serial.println(counter);`

#### Vincent19

#22
##### Jan 23, 2013, 01:49 pm

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.
Quote

Ok.  Nice video

Since counter is never reset (other than when you fail and start over), it means you have a total of (slightly over ) 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

#### johncc

#23
##### Jan 23, 2013, 01:53 pm

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

Did you build that from a kit or what?

John

#24
yes, a kit.