Electronic board game - SUCCESS!

It's been about ten days since the last meaningful blog update, which can only mean one thing - coding! Actually, it could mean that real life has been getting in the way of nerding about (it has: with the first few nice, sunny, days of 2014 there's been an awful lot more going out and spending time at the allotment than in recent weeks). It could also mean that work (real work, the sort that pays the rent) has been demanding more time (also true, learning two new languages to work on a web-based app is heavy going at times).

But, in terms of this blog and writing up the latest nerd-based developments, it generally means, we've been busy coding.

There's not really much you can blog about when you're coding. Here's a screenshot of an error. Here's a couple of screenshots showing how something's not quite working properly, but we can't work out why. Coding isn't much of a spectator sport - and, similarly, there's not really much to blog about while it's going on.

Making physical stuff - hardware, electronics, gadgets, is infinitely more rewarding from a blogging point of view - there's always something to show, some photos to illustrate the latest developments, or a video to show where things are up to. But with code, it's just, well, kind of boring.

But at BuildBrighton tonight, we were delighted to be able to demonstrate a working version of our electronic board game. All the hours of coding look like they're starting to pay off. So here's a video of a demonstration, showing where we're up to:

It's not 100% perfect, and there are a few things to iron out, but on the face of it, things are looking really promising. Firstly, the thing actually works: the software in the video is running on an Apple iPad Mini. We decided to demonstrate on this platform, to show that it would (should?) work on any other platform (since getting multi-platform stuff to work on Apple devices is often the most difficult). Data is being passed from the hardware (that bunch of wires the board game sections are plugged into) to the iPad, without resorting to hacks, dodgy hardware cables or jailbreaking - all the devices simply talk to each other by each connecting to the home hub router.

Also, we worked hard to make adding the board game sections as flexible as possible: rather than simply use a number of pre-defined board layouts, we wanted players to be able to mix-and-match their board game sections - and to add them at any time during the game.

The video demonstrates the app detecting when a new board section is added to the existing map. (the delay between the board being added and the app detecting the new piece is deliberate, to allow time for the piece to be lined up, the connector to get jiggled about a bit and so on - although perhaps 3 seconds is a bit long, on reflection).

When a new piece is detected, buttons on the controlling hardware can be pressed to rotate the piece, or - in the event of more than one potential destination on the board being available - locate the piece at the end of a different section of corridor or room entrance. This means that there is no need to poke at the tablet/smart device running the app to make any selections - something we feel might detract from the gameplay, during a boardgame.

The video also shows playing pieces being added to the board, and being correctly placed in the app. At the time of writing, it's not perfect, but it's a workable demonstration. Most of the problem stems from us using tiny 3mm magnets, which are not perfectly lined up in the centre of each playing piece.

Here's our robot playing piece. We're using the tiny 3mm magnets because we don't want one playing piece to affect more than one hall effect sensor at a time, as the pieces are moved around the board. It's important that a playing piece leaves one square before appearing in another - too large a magnet, and it's possible that one piece could influence two or more hall sensors at one time, and could lead to confusion.

But such tiny magnets mean they have to be right over the top of the hall effect sensor, to get it to detect the presence of the playing piece. This isn't really a problem, except we were a little "slap-dash" in gluing our magnets on the underside of the playing pieces.

The 28mm "slotta-bases" are made in such a way that when we glue a magnet to the underside, it's slightly off-centre. This is why, in the video, the robot playing piece is not immediately detected when placed on it's square: the playing piece is in the dead centre of the square, but the magnet is only close enough to activate the sensor as we lift the piece off. Were the magnet in the centre of the playing piece, this error would not have occurred.

When the app detects a new playing piece has been added to the board, the player is asked to choose which character this piece represents. Again, selection is made using the hardware buttons, rather than swiping (and potentially disturbing to position of) a touchscreen.

So we've managed to get the app to detect board sections as they are added to the map: these can be all done at the start of the game, or at any time during play. We've detected not only when new playing pieces are added, but also are able to track playing pieces as they are moved from square to square. All in all, a pretty good start!

We've already coded line of sight (for hidden movement and to keep the opposing player's pieces hidden until they can be seen by any one of your playing pieces) and firing weapons, so we're hoping to implement these very soon into our hardware-based version of the game - and then we won't actually be too far away from demonstrating our first board-game-based-Laser-Squad-a-like-y video!

(and hopefully Steve will finally relent and let us build a CNC machine for making the other board sections - but that's for another post!)