Binary Puzzle

I said we'd take a little detour to make a fully functional puzzle using our two buttons and two lights and so I present to you, a Binary Puzzle. I have made two binary style puzzles before, one was purely mechanical, and the other one used a cabinet lock and a series of switches to activate it (but no blog post). Both of these are simpler ways of making the same puzzle so we need this to be different somehow. Since we have the full power of a microcontroller why not make the codes change over time. Every time you fail to enter the code correctly it will change the code, so let's dig into the system.

Hardware wise it's a bit ugly, all of the information required to solve the puzzle is contained on the front of the panel which could be mounted in a box or in a wall. The reverse is just enough hardware to hold everything in place and some basic soldering to recreate everything on the previous prototype board. Two switches connected to D5 and D6 using the internal pull up resistors and two LEDs connected to D1 and D2 which are wired in an Active low configuration.

For the game play, the system is going to flash a binary code to the player that matches one of the codes on the left hand side of the panel. The player is then required to input the corresponding binary code from the right hand side of the panel as indicated by the arrows. The system should repeat the code so that the player has multiple chances to confirm which code is being used. The player should have one opportunity to input the correct code, the system should indicate if the code is correct or incorrect and if it is incorrect the system should randomly select a new code and let the player try again. This allows us to define some initial states or operation. We also need to define a list of the different codes and answers.

	// Define the different states of the game
	enum class gameStates { DisplayCode,
	InputCode,
	CheckCode };
	gameStates gameState = gameStates::DisplayCode;
	// Define a number of codes and answers
	const uint8_t numCodes = 10;
	const uint8_t code[][2] = { { 0b10101001, 0b00111001 },
	{ 0b11100010, 0b00000111 },
	{ 0b00100111, 0b01111000 },
	{ 0b00000111, 0b10101110 },
	{ 0b11010000, 0b10001011 },
	{ 0b00111111, 0b01001000 },
	{ 0b01110011, 0b00010110 },
	{ 0b01100001, 0b00010101 },
	{ 0b10111000, 0b00010001 },
	{ 0b01110001, 0b11001101 } };
	uint8_t codeNo = 0;

view raw 6-BinaryGame1.ino hosted with ❤ by GitHub

The code in the previous tutorials is set up in a way to control the inputs and outputs and this framework is great for this game. We need to add some code that actually controls the game, this is done after all the inputs have been read and before the outputs are controlled. The code to flash the LEDs has some specific timing requirements so it's best to extract that to its own function rather than keeping it in the switch code block. The system has a 25ms loop time which is far to quick for the player to see a flashing LED so we need to keep the LED on for multiple loops, we also loop through all eight bits within the byte and there needs to be a delay before the pattern repeats so the player can work out which bit is the start of the byte.

	uint32_t displayCount = 0;
	void displayCode() {
	const uint8_t bitDelay = 24; // A delay between bits
	const uint8_t byteDelay = 12; // Wait for half a byte before repeating
	// Work out which bit to display
	uint8_t bitNo = displayCount / bitDelay;
	// Turn off both LEDs before working out which one to turn back on
	ledMode[0] = ledModes::Off;
	ledMode[1] = ledModes::Off;
	// Only update the LED for the first eight bits
	if (bitNo < 8) {
	// Turn the LED on for the last 3/4 of the cycle, this creates a blink between bits.
	if (displayCount % bitDelay > bitDelay / 4) {
	// Work out if the new bit is a 0 or 1
	// Read the bits from left to right
	uint8_t bitValue = (code[codeNo][0] >> (7 - bitNo)) & 1;
	ledMode[bitValue] = ledModes::On;
	}
	}
	// Add to the count and loop
	displayCount++;
	displayCount %= bitDelay * byteDelay;
	}

view raw 6-BinaryGame2.ino hosted with ❤ by GitHub

The displayCode function makes use of a global counter, displayCount, to keep track of timing and which bit should be display next. It also creates all the gaps between the bits and bytes being displayed. At any point during this flash sequence the player could push a button and interrupt the process as they try and input the solution. A button push should trigger a switch to the next game state but we should also record the button because it will be the first bit of their answer.

	// If either button is pushed then immediately jump to the input state
	for (uint8_t i = 0; i < numBtns; i++) {
	if (btnDown(i)) {
	gameState = gameStates::InputCode;
	// Record this as the first button pushed
	input = i;
	bitCount = 1;
	}
	}
	break;
	// Record the next eight button pushes, flashing the leds as the buttons are pushed
	case gameStates::InputCode:
	for (uint8_t i = 0; i < numBtns; i++) {
	// If either button is pushed then record the value and increment the bitCount
	if (btnDown(i)) {
	input = (input << 1) + i;
	bitCount++;
	}
	// Turn on the corresponding LED while the button is held down.
	if (btnCurValue[i]) {
	ledMode[i] = ledModes::Off;
	} else {
	ledMode[i] = ledModes::On;
	}
	}
	// When eight buttons have been pushed move to the next state to check the code and display the result
	if (bitCount == 8) {
	gameState = gameStates::CheckCode;
	bitCount = 0;
	}

view raw 6-BinaryGame3.ino hosted with ❤ by GitHub

As each new button is pressed the value should be recorded and added to the answer but it's also really important to provide some kind of feed back to the player that the button push has been acknowledged so in this case the code flashes the LED next to the button for as long as the player holds the button down. This doesn't work during the initial press when the game changes states but human response times mean that the button will be held down for more than one loop so the button will still be down when the game switches to this new state. Once the player has input eight button presses the game needs to switch to the next state and check the code.

	case gameStates::CheckCode:
	// If the code is correct then switch the LEDs into a fading cycle
	if (input == code[codeNo][1]) {
	for (uint8_t i = 0; i < numLeds; i++)
	ledMode[i] = ledModes::Fade;
	}
	// If the code is incorrect, flicker the LED's for a duration
	// Select a new code and reset the system to start over again
	else {
	if (displayCount < 40) {
	for (uint8_t i = 0; i < numLeds; i++)
	ledMode[i] = ledModes::Flicker;
	} else if (displayCount < 80) {
	for (uint8_t i = 0; i < numLeds; i++)
	ledMode[i] = ledModes::Off;
	} else {
	gameState = gameStates::DisplayCode;
	resetGame();
	}
	displayCount++;
	}
	break;

view raw 6-BinaryGame4.ino hosted with ❤ by GitHub

The code checking and response is actually quite simple because we already built the framework to display different states on the LED. If the code is correct we can fade the LEDs, the smooth animation makes it look like the system is functioning correctly. If the code is incorrect we can flicker the LEDs which make it look like there's a problem with the system. The only minor issue is that we need to dwell in these states to allow the user time to acknowledge them before resetting the system. The global displayCount variable can be used again create these delays. Finally we can reset the system, this function just resets all of the global variables but it also switches to a new code. It selects a new code randomly but it checks it against the current code and if it randomly picked the same code, it will try again. This ensures that it doesn't go back to the same code again.

Making this 'simple' puzzle reminded me of the importance of play testing everything. While trying to figure out what to do, my wife only pushed four buttons, stopped to think about it and then tried to put all eight digits in. Of course it reset halfway through the second input sequence. The solution is to add a timeout to the InputCode section, if the use starts to press buttons but stops for more than 5 seconds the system should timeout, move onto the next section where the code will be incorrect and the system will display this to the player before resetting. It's a simple change but also vital for the player interaction. 

The full code for this can be found on my github repository
https://github.com/msraynsford/Puzzling/