Focus on one thing at a time

While we're getting quite excited about our modular hex-based board game idea, there's still something nagging away at the back of the brain - a bit like having the spectre at a feast. It's great, but there's something sinister on the horizon!

That spectre, for us, is cost.

While we decided to "hang the cost" and go for a really cool and clever approach to our board game pieces, the truth is we've ended up with a compromise of what we originally set out to create - and a very costly compromise at that.

Originally we wanted to make a modular board game system which could be used for any number of games - chess, Cluedo, Monopoly etc. as well as the more complex fantasy-sports-games-with-loads-of-rules type games too. About a year ago we started a digital Blood Bowl game, but aborted that after problems with capacitive sensing. All of these games use a grid made up of squares which would be relatively easy to implement, using a couple of shift-registers to make up a 4x4 (16 square) module. Then we discovered the immensely popular KickStarter game DreadBall - like Blood Bowl but better, faster and more fun to play. This game uses hexagons which gave us other ideas...

After the LC-oscillator approach failed, the hall-sensor effect approach was still deemed costly but worth it - especially if we could introduce some LED coolness to our game.

So far we've costed up components, but haven't yet considered the full cost of actually producing loads of modules (we'll need about 40 to make a workable Dreadball board) - things like wire and copper board and press-n-peel and pin headers all cost pence individually, but soon add up to quite a few pounds when you multiply them up. Not to mention that with LED capabilities, each board will probably need it's own microcontroller and the costs soon start mounting up...

So once again, we've gone right back to the drawing board and drawn up a list of requirements.
This way, we can concentrate on what needs putting in and not worry about stuff for "future development" until such future time comes around. We quite like the look of DreadBall, so we're going to concentrate on making an awesome DreadBall board. But within a reasonable budget! (the modular route was going to end up costing �5-�6 per module, so 40x6 = �240. Ulp!)

First up, let's lose the modular approach.
So we're going to need a massive piece of copper clad board. Etching this is going to be a pain and the actual board is going to cost a fortune. So let's lose that. In fact, let's lose the idea of making a board which is really cool to look at in its individual pieces and get right back to basics: push buttons and a whole heap of wiring! SMT pushbuttons cost about �6 per thousand (from eBay/chinese suppliers) and enamel coated magnet wire is pretty cheap too. We've already loads of SMT resistors, and if we use wire, we don't need to make massive PCBs - superglue a component to some hardboard and tack on a couple of wires!

If we concentrate on just the input side of things for now, we can create a "resistor ladder" for handling multiple inputs through a single analogue pin on a PIC microcontroller. We don't need to worry about creating an R-2R network to uniquely identify combinations of button-presses, since the mcu can only decode what's going on if only one square at a time is activated anyway.

As it happens, there's a really useful PIC, the 16F1519 which has a massive 28 analogue-to-digital channels, plus serial/UART for easily sending data back and forth. (the 16F1517 is a reasonable substitute with similar i/o channels, just less RAM and ROM). So if we make our resistor ladders 12 squares long (see diagram above) we should be able to scan 22 analogue inputs and see which button(s) - if any - have been pressed. Practice will tell how long it takes to scan the entire board in case a player is moving a piece quickly, but here's where the next idea comes into play:

When a player presses down on a square, the input is detected by one PIC microcontroller and the current state of the board can be passed onto a "host" via serial/UART. We can then use another microcontroller to light up the squares as they are pressed (or rather, after they have been detected as pressed). This isn't as onerous as it sounds...

If we treat the board as four slightly-mis-aligned 8x8 LED matrices, we can use 4 x MAX7219 driver chips and a separate mcu. (why they are sooo expensive via Farnell - �8 each - compared to eBay - about ten for a tenner - is a mystery!) So when the board has been scanned and we've detected that a button has been pressed, we simply update the appropriate LED driver chip and the LED under the square on the board lights up. This allows for all kinds of scenarios:

If you don't know if your move has been recognised, simply hold the piece down until the square lights up (we need to test this in practice to see what the latency is like). But equally, we can now highlight squares, depending on what's happening in the game. Let's imagine that the ball has been thrown but missed it's target - the host MCU can simply tell the LED-mcu to flash a particular square on and off; the player presses the ball down into that square, which in turn tells the host mcu that the game state has updated and play can continue. If a player performs a "slam" and pushes an opponent backwards, the host controller can flash possible destination squares to help speed up the gameplay.

But these are terms and scenarios specific to DreadBall. While they could be incorporated into a generic digital board game system, to do so could ultimately be slow and cumbersome. So we're going to concentrate on one thing at a time for now. And for now, that means getting a working digital DreadBall board game working with pushbuttons, smt leds and lots of wiring!