Netduino + WP8: Real life Maze game

Tweet about this on TwitterShare on FacebookShare on RedditShare on Google+Email this to someonePin on Pinterest

When I was young my parents bought me a wooden maze game. I loved that thing. I don’t think I ever cared much for the actual maze element – but the mechanism to tilt the stage was intriguing, and very simple.

When I remembered it the other day I managed to both find it online, and actually find my original one in an old cupboard from storage.

Moving on a decade or two, we now have hundreds of these ball games on smartphones using their accelerometers (like this one – a random one from the WP store), but their graphics leave a lot to be desired. Which is why I’ve made a photorealistic one 😉

The objective was to make a maze game that was a merge between the old-school and new-school ones. So the phone is used as a tilt controller to control the physical maze via Bluetooth with a Netduino. The maze is a simple model printed on my 3D printer and is tilted by using two servos. Bonus points for adding a switch mechanism to report back to the phone when the player gets to the end.

What you need:

  • 2 fairly strong servos. I used Turnigy metal-gear ones from HobbyKing.
  • Bluetooth module
  • Netduino
  • Small square maze-like object
  • 10K ohm resistor
  • 4.8V battery pack
  • Conductive ball-bearing/marble


The mechanism:

Before going into the technical stuff you should probably understand the actual tilting mechanism. The description that follows will likely confuse you because it’s hard to explain. So, when adequately confused, proceed to the images that will clear things up.

The usual way to create tilt on two axes is similar to how the wooden game does it – where a servo will be attached to the inner object, and then an outer servo will be attached to that whole enclosure (notice how there are 3 boxes within each other in the wooden maze picture at the top). The way I did it is the same theory, but much easier to make. The downside is that both of the axes will not be directly horizontal to the maze, so the maze will essentially be rotating around an offset inner pivot.

So you basically have two servos at 90 degrees to each other. The first one will rotate the second one. And the second one will rotate the supporting bracket attached to the actual maze. Here are two renders I made to illustrate

servo1                servo2



And to make it even clearer, see it in action:


To attach the servos together I just used an elastic band wound tightly. The lower servo is on an old servo mount I had, glued to a flat base.


The maze:

This probably took longer than all the other parts combined because my 3D printer’s extruder nozzle jammed up rather solidly. And even when I did eventually get it to print, the result was pretty terrible. However, the actual maze model at the end of this post is perfect and will print fine on your printer if you have one. I printed it 9CM x 9CM because that is about the biggest my Makerbot Thing-O-Matic can print.


To make the model, I first went to and generated a 9X9 maze. Then imported the result into SketchUp, traced out the lines, and extruded the walls up. I only made the walls high enough to steer the ball – not encase it.




The electronics aren’t terribly complicated. I’ve Fritzinged (that should totally be a word) the layout:


Note: The ground wires are laid out like that to make it clearer.

Bluetooth module:

This is connected just like in previous posts. The code is also exactly the same as those were so I won’t go into that. Go read these:



I started this off with the servos connected directly to the Netduino power pin. Of course that isn’t actually recommended because it pulls too much power, but for a proof of concept it should be OK. However I found another problem besides the power draw – as soon as the servos moved the Bluetooth module would disconnect. It makes sense due to noise/interference, but I’ve never seen it effect another component so much.

So these are connected to the 4.8V battery pack. Something to remember is that you need to tie the ground of the battery and the Netduino together. The signal wires go to PWM pins.



To make the end-point contacts, I cut up a thin strip of metal into two and put one flat, and the other vertical with a small gap in-between. When the conductive ball gets to the end it closes the gap between the two and essentially flicks the switch.


This is then wired up much like a normal switch would be.



After putting in the Bluetooth code (links above) the rest is pretty straight forward.

First we setup both servos, the BT module, and the end point “switch”. For more details on why/how a switch works on the Netduino check this out. Then I adjust the servos to make the maze flat. In an ideal world that wasn’t held together with hopes and dreams elastic bands, both of those values would be 90 degrees.  The nice little servo class is from here.

Next, the code in the event handler for the switch interrupt will run when the ball joins the contacts. But because we don’t want that firing over and over, we make sure that there is a current game running (with the isRunning bool). If there is a game running and the event is fired then we write “done|” to the BT module. As in previous articles, “|” represents the end of a message.

The final part of the Netduino code is handling the messages from the phone.

When the user presses the GO button on the phone it sends “start” over BT. So we set the bool to true to indicate there is a game going on.

If the message isn’t a start message then we know it’s the accelerometer values. As you will see in the phone solution, we send those values through as X,Y. So this code splits it up, makes sure there are 2 values, then converts them to int’s and sets the servos. As mentioned above I’m adding some offset because my servos aren’t perfectly level.



The phone code is very basic. Here is the basic functions it serves:

-Send through “start” when GO button is pressed
-Display a timer
-Send through X and Y accelerometer values
-Display final game time when “done” is received

And here is the code for each of those:

Send through “start” when GO button is pressed and display a timer

It should be noted that using a DispatcherTimer with such a high frequency probably isn’t a good idea – and really shouldn’t be used except when absolutely necessary.

Send through X and Y accelerometer values

Those of you who have used MathHelper.Clamp in XNA will recognize the functionality. It basically just stops a value from going above or below certain limits. The code inside the Dispatcher just does some visual stuff to show the angle in the UI.

Display final game time when “done” is received

And that’s about it! Checkout the source to see the BT stuff and the UI.



This zip contains the Netduino Solution, the WP8 Solution, and the STL model to print.


If you’ve got question you can ask me here or on the Twitter machine: @roguecode

Tweet about this on TwitterShare on FacebookShare on RedditShare on Google+Email this to someonePin on Pinterest