Jeopardy Style Game control

Kevin_Pace

I finally got my school division to install Blockly Prop after several months of a long battle! YEAH!

So I have just started tinkering in Blockly Prop and started a student challenge to build a jeopardy style game running on a personally designed board similar to the Prop Activity Board. My boards have access to pins 5 - 27. (Other pins are tied to specific robot control aspects like xbee etc)

Essentially I want 3 buttons which each control their own LED. When any one button is pushed, the Led Lights up and Locks all the rest of the players out until the Teacher pushes a 4th (separate Button to reset the code)

I have the code for the button and the lockout going which didn't take long.

However, I have spent several hours trying all kinds of arrangements to "reset" or (Clear all the prior commands) so that the LED's go out and all push-buttons are ready to trigger their LED for the next question. I don't want the instructor to have to cut the board off and on every time a new question is asked.

QUESTION: IS THERE A WAY TO "RESET" ALL THE PUSHBUTTONS in an IF ...ELSEIF loop in Blockly when each button is assigned the "break"command when pressed?

Thanks for any light anyone can shed on this.


My code is in the link below.

http://blockly.parallax.com/blockly/projectlink?id=31158&key=3765acb7-ddf1-475c-8045-a6b2c6657f0e

twm47099

I was not able to get to your code (is it shared or private?), but I wrote an example.

After the default break (exiting the switch/case) Just wait until the teacher button is pressed (repeat until teacher pin is high and teacher variable is true).
Tom M

The_Master

That would be handled in five lines of Basic.
This structured thing is out of control. It's so 90's.

Kevin_Pace

Thanks Tom for the example. I will give this a try right away!
Kind regards,
Kevin

Kevin_Pace

Tom, You are the man! It worked perfectly. Your example certainly gave me a bit more insight on the use of the Switch/Case command.
I know the students are going to have fun with this!

Thanks again!
Kevin

David Betz

twm47099 wrote: »

I was not able to get to your code (is it shared or private?), but I wrote an example.

After the default break (exiting the switch/case) Just wait until the teacher button is pressed (repeat until teacher pin is high and teacher variable is true).
Tom M

Won't this code have a problem if two buttons are pressed at exactly the same time? I don't think it will match either since the value will be a combination button values.

Ken Gracey

Another idea is to put the button-checking into it's own processor. The case..do statement could evaluate multiple button conditions.

Ken Gracey

twm47099

David Betz wrote: »

Won't this code have a problem if two buttons are pressed at exactly the same time? I don't think it will match either since the value will be a combination button values.

Since the loop only has a couple of statements, I think that it will be quick enough that it will enter the case statement quickly enough to prevent 2 buttons from registering. If it does it will drop to the default. I not sure what will happen with switch bounces though.
Tom

twm47099

I got interrupted on my last post, but although I think the loop should be fast enough to prevent combinations of buttons, the OP should check for that. If the code is unreliable and gets multiple button presses, adding some code in the default case to indicate an illegal tie (turn on all 3 leds) and pass control back to the teacher could work (unless there are too many ties.)

In C using SimpleIDE, I use the "waitpne" command instead of looping to test for button presses which would be faster. I don't think that exists in Blockly.

Tom

twm47099

I thought of another problem. On the TV show sometimes no contestant will press their button. As written the program above will just not do anything until a student presses their button. So I decided to allow the teacher to control things by pressing their button.

In the "repeat until students" block I allow the teacher button (pin 8 ) to be part of the variable "students". If the teacher presses their button, or if there is a student tie, the value of "students" doesn't equal any of the cases, so the program goes to the default case. All 3 LEDs turn on, and there is a 1/2 sec delay. Then the program moves to the teacher reset section.
Tom M

twm47099

Just for the heck of it, I rewrote the program without using the switch-case statement and uses bitwise arithmetic instead.
Normal operation -
1. program clears LEDs and zeros the 2 variables.
2. waits (in a loop) until a student presses their button
3. lights the LED corresponding with the student who pressed the button ("students" bitwise and 0b111)
4. waits (in loop) for teacher to press their button
5. loops back to 1.

Error operation -
1. program clears LEDs and zeros the 2 variables.
2. waits (in a loop) until a student presses their button
3a. If 2 or 3 students tie, lights all the LEDs corresponding with the students who tied ("students" bitwise and 0b111) means error
3.b If no student presses a button, teacher presses button & all LEDs light (if "students" bitwise and 0b1000) then pause 1/2 second
4. waits (in loop) for teacher to press their button
5. loops back to 1.

JonnyMac

Ken Gracey wrote: »

Another idea is to put the button-checking into it's own processor. The case..do statement could evaluate multiple button conditions.
Ken Gracey

That would also allow button debouncing. In many of my Spin projects (some are being ported to Blockly), I run a background loop every 1ms; this lets me handle thinks like background buttons, a global timer, etc. very easily.

twm47099

I finally got around to trying the program in the post of March 8. I had to change pin numbers because I was using a QuickStart Board that had a few other things connected. The pins are shown in the comment of the blocks shown below. I also had to set the individual LED pins high and low using separate blocks, because of how I had the LEDs wired. Those caused some changes in the case statements.

The program works but I found a couple of issues.

1. When the host (Alex or the teacher) presses the button to clear the LEDs, if the button is held too long, the program will pass through the "until students" loop (the teacher button pin will be high) and all 3 LEDs will light showing the error condition, so the teacher has to be quick on and off the button.

2. The sneaky contestant (student) could keep pressing their button while the teacher resets the LEDs, that would also pass through the "until students" loop (student button pin is high), and show their LED on.

The correction for both of these issues is to add a "while students" loop after setting the LED pins LOW, and before setting "student = 0". That stalls the program until all the buttons are released; then it proceeds to wait until a button is pressed. If the teacher presses their button to declare an error and holds it longer than 1/2 second, the LEDs will all light and then go out. But on a normal press/release the error will stay lit until the teacher button is pressed again. There is a pause block currently set for 500 ms, if longer or shorter delay is desired before the error LEDs go out if the button is held, just change that value.

The blocks are in: blockly.parallax.com/blockly/editor/blocklyc.jsp?project=34018#


Tom M.

erco

The_Master wrote: »

That would be handled in five lines of Basic.

You and I think alike, Master! I love me some short, crunchy Basic code.

twm47099

erco wrote: »

The_Master wrote: »

That would be handled in five lines of Basic.

You and I think alike, Master! I love me some short, crunchy Basic code.

Actually if looking for concise & crunchy, Peter could probably handle it in 1 (or maybe 2) lines of Tachyon, but I don't think that is the point of early educational programming. Simple examples are usually not very code efficient.

I miss my old Basic programmed computer (Compucolor 2), where simple (and not so simple) programs could be interactive, concise, and still readable. And it's one of the reasons, I enjoy programming in forth (ok, maybe not so readable, but the ability to redefine the language as you go was a good tradeoff).

Tom M.