Dreadball like Blood Bowl but better?

It's been many years (about twenty more than we'd care to admit) since any of us played Blood Bowl. But always seemed like a nice idea for a game - even if the mechanics of playing it got a bit lumpy with all the rules and look-up tables. It's what originally inspired us to look into making a digital board game, just over a year ago; to take a complex set of rules and have a microcontroller do all the clever stuff, and leave us to concentrate on actually playing the game.

It'd also mean having a hobby that meant turning off the computer(s) for a while, and actually making and painting something - getting back to the arts and crafts side of making, rather than being engulfed in coding and electronics all the time!

While looking for ideas to resurrect the Digital Blood Bowl idea, the ever-helpful Mr Google turned up a relatively new game that launched recently thanks to some massive KickStarter support: it's called DreadBall and, while the author is keen to state that it's NOT Blood Bowl set in the future, on first glance it look like a perfect game to try to convert.

It's a two-player, futuristic, football-come-rugby-come-speedball type game, set in the future. The author - and subsequent players of the game - reckon it's easier and faster to play than Blood Bowl. In fact, all the reviews say it like Blood Bowl but better.

Now being set in the future, with Tron-like armour and shiny futuristic materials, this game lends itself really well to being converted into a digital board game - not least of all because the underlying technology won't need to be "hidden" behind a fantasy, olde-worlde facade, but actually enhances the playing environment. Some early fans have already taken the next logical step of creating custom boards - with LED backlights to reinforce the glowing-edges Tron-style look-and-feel:

In fact, players of the game are keen to exploit this futuristic look-and-feel. They're even painting it into the miniatures used for the playing pieces. The game ships with miniatures that have clear acrylic bases, so that they are less obtrusive on the board. But some players are making the hexagonal bases a major part of the model, painting them to look like they also have glowing edges:

(note the Tron-like glowing edges painted onto the model bases)

This has given us an idea for our hex-based modular board game system. More details (with schematics once drawn) to follow....

A new approach to digital boardgames

So far, we've been trying to build a digital boardgame to a budget. The idea being that keeping costs down makes the idea accessible to more people (not everyone can afford to drop a hundred pounds on a hobby project, but lots more people can find twenty or thirty quid for a one-off project).

This is why we were keen to pursue the LC oscillator idea for detecting board game pieces. It's already been suggested that hall-effect sensors would be a much simpler and more robust solution - simply place a magnet in the base of each playing piece and query each hall sensor on the board to see if it's been activated.

So far we'd ruled these out because they are relatively expensive. In truth, they're about 20p each when bought in bulk from somewhere like Farnell. But if you're building a board game with 390 of them on there, that's getting on for £80, which is a big amount to find to try out on an idea that a bunch of nerds posted on a website somewhere and which you still need to solder up and make yourself and still not know if it'll work 'til you've made it.

So we thought about this and came up with a different approach: a modular hexagon-based electronic game board. The idea is to make individual modules which can be plugged together to make a pretty-much any-sized gaming board for pretty much any board game. Provided it doesn't use squares ;-)

Each module could be a group of seven hexagons. Each module has a hall effect sensor in the centre of each "square", an 8-bit parallel in/serial out (PISO) shift register, a wired plug and a pin-socket which allows multiple squares to be connected together.

The idea is that the shift registers are "daisy-chained", with the hall effect pattern copied from the parallel interface (we're only actually using 7 of the 8 available bits) onto the serial output. As the microcontroller sends a clock signal to the first module in the "chain", the status of each square in each module is shifted out of the last module in the chain. Send enough clock pulses and the you get a massive binary pattery back, indicating the status of every square on the board. Provided every board is oriented the correct way around, we should be able to work out whether each square on the board has a playing piece immediately above it.

Now each individual module is going to be more expensive to manufacture than an entire board made from cheaper components - but the upside is that the same modules can be used for lots of different board games by simply unplugging them and re-connecting them in a different configuration for a different mcu!

Other than cost, the downside of this approach is that to create a rectangular playing area, there are quite a few unused squares across multiple modules:

Here's an example of a rectangular-ish board made up from hexagons - it's from a BloodBowl-esque game called DreadBall:

It uses up to 40 hex-based pads (including those with unused squares) which - if we go down the hall-effect sensor route - makes the total construction cost quite expensive. But already that's something that's already been queried by a few people...

After all, a brand new copy of Blood Bowl costs about £50 new. And that's made up of a cardboard playing surface and some plastic miniatures which most players replace almost as soon as they can afford to! If each module costs, say, £2 to make, a full DreadBall sized board would cost about £80. That's a lot to shell out in one go - but it's quite affordable (and much more realistic) to make up, say, 10 modules at a time. With only 10 modules, they can still be plugged together and used to confirm that everything works, but without the one-off massive cost of nearly a hundred pounds all in one go.

There's no guarantee that we'll ever make enough modules to complete a full-sized Blood Bowl board, but - like the LC oscillator - there's an idea that needs investigating. So we've got a load of components on order from Farnell to try out over the coming few days....

Metal detecting for board game inputs

It's nearly the end of February and there's been very little coming out of Nerd Towers of late. Strictly speaking, that's not true, since we've been coding like the proverbial 1,000 monkeys at 1,000 typewriters (the output has been pretty similar of late too!). But software coding just doesn't feel like "making stuff" so we're determined to put that right.

While browsing the 'net the other day, looking for information about inductors (what they are, what they do, what they're used for) I stumbled upon this interesting animation. They say a picture speaks a thousand words; this one explained inductors and LC oscillators beautifully:

It came from this website: http://www.talkingelectronics.com/projects/Inductor/Inductor-2.html
Now in itself this demonstrates a fascinating property of inductors and capacitors when connected together. But then we came across this - http://www.schoenbuch-electronic.de/index.php?id=145
Which suggests that placing a metal object near an inductor affects the magnetic field and causes the frequency of the oscillator to change. Now that got us thinking:

If instead of the blue wire we connected the LC oscillator to a PIC i/o pin, we could set the pin to output mode and "charge" the circuit. After a delay, we could turn the pin to an input and set a timer running. When the input on the pin changes from low-to-high, we've got a means to calculate the frequency of the oscillator. We've ignored the negative voltage from the circuit because with PIC microcontrollers, every input pin has a clamp diode ensuring only voltages within the range 0-Vcc are accepted. In fact, a PIC is a pretty robust device and can handle really large +ve and -ve voltages (http://www.electro-tech-online.com/microcontrollers/96653-detecting-12v-pic-input-running-5v-off-7805-a.html ). The only thing we need to do is make sure the input diodes are protected by large value resistors.

So the principle is we send a pin high, wait, set it to an input then wait to see how long it is before we get a response back on the input pin. If the delay is larger or smaller than expected, we can confidently say that a metallic object is present. If only we could work out the "natural" oscillation of our LC circuit....

This website had just what we were looking for! http://www.deephaven.co.uk/lc.html

If we type in an inductor and capacitor value, it works out the expected frequency of the circuit. Perfect!

So now we have a very basic metal detector circuit. What now?

About a year ago, we started work on an electronic board game (Blood Bowl). After hitting problems with capacitive sensing, not much more was done with it. But this latest development has got us thinking - the playing pieces in the game are (pewter) metal (but the same approach could be used for many board games, with a small piece of metal inserted into the base of the playing pieces). If we could use inductive sensing to detect when a piece is placed/removed from the board, our idea of a digital board game could well be back on! And coupled with the alarm clock audio player we came up with a few months back, could even include sound effects too!

Given that a chess board has 8x8 = 64 squares, and a board game has 300 or more playing squares, it's going to be important to keep costs down on this idea. So we're looking for 

a) cheap inductors

b) cheap capacitors

c) accurate capacitors (there's no point using -20%/+80% caps to detect a 25% change in inductance!)

d) easy to use components (there's going to be a lot of soldering!)

So we came up with a shopping list.

These surface mount inductors from Farnell are less than 5p each in volumes of 100+

They're 1.5mH and accurate to 10%. They're in an 1812 surface mount package, so just a bit bigger than the SMT resistors we're already familiar with

These surface mount capacitors are 1.5uF, also accurate to 10% and cost less than 3p each.

They're also in the familiar 1206 SMT package so should be quite easy to work with.

If we use a 1.5mH inductor and a 1.5uF capacitor, in theory we should be able to create an LC oscillator which runs at about 100khz - ideally we could use "bigger" value components and get a slower oscillation; but a PIC micro running of a 20Mhz crystal should be plenty fast enough to read any variance in a 100khz signal, so we're trying to keep the cost down and use as cheap components as we can get hold of!

Using the components we've identified, each square on the board will cost 8p in components (not including the MCU or any external i/o expanders or shift registers). Although this isn't a massive cost, for anything more than a simple chess-type board, things could easily get very expensive, very quickly. For example, a Blood Bowl board is 15x26 squares in size: that's 390 squares. For just the inductors and capacitors, that's £31.20. Not a massive cost for a one-off prototype, but quite pricey if we ever decide to make more than one!

Before we go crazy buying up loads of kit and components, it's probably best to try the idea out with a few rows and columns on a board game board. That's exactly what we're going to do - and post the results here in a few days.......

Blood Bowl Digital

It's almost Xmas and time to down tools for a while and get all Christmas-y (despite what some people will tell you, tinsels and baubles still lead soldering irons and wire strippers in the Xmas stakes).
But before we wind down for the holiday season, we've been busy working on a website for our Digital Blood Bowl game board. We've called it Blood Bowl Digital.

A preview of the site can be found at http://www.nerdclub.co.uk/bloodbowl
You can create teams and build online rosters and assign attributes and skills to all your players.
The idea behind this is to have a gateway between an online team/games manager and a way of getting player data into the game board.

Hopefully - if we manage to keep on the "nice list" for the next few days - we'll have some spanky 20x4 character displays to actually demonstrate something come Boxing Day.....

Stripping paint from Blood Bowl miniatures

Yesterday morning the postie delivered a whole team of (second-hand eBay bargain) Orcs to Nerd Towers and - as is normal with most things when something new arrives - we immediately dropped everything and spent some time getting all excited about the newest thing to be working on!

They're the "older" - 2nd or 3rd edition - style Orc team called The Orcland Raiders, not the American Football style team we've mentioned in a previous post, but they were (relatively) cheap with the added bonus of already being painted.

An orc team from Games Workshop. We're not expecting ours to be painted to anywhere near this standard!

 None of us here have painted (or even shown any interest in) miniatures-based board games for nearly twenty years or more, so having a pre-painted team seemed like a good idea. Until they arrived....

The paint job on each miniature is ok-ish.
The basic colours are in the right places, and sometimes even the details are quite nicely done. But the colours seemed a bit "muddy" and not all the finer details were picked out in quite the way we'd have liked, so we've all decided to buy each other a set of Citadel paints (or similar acrylic-based colours) for Xmas and have a "getting-re-aquainted-with-painting-miniatures-again" session in the New Year.

Which means stripping all the miniatures we have and starting again.
We tried the usual tricks of Dettol, Fairy power spray and a whole heap of other detergents (there's no excuse in not keeping the place clean and tidy any more) but each was quite fiddly and required lots of soaking, scrubbing, re-soaking and so on. So we put on some rubber gloves and dropped the miniatures into some industrial strength paint and varnish remover. This is a white jelly-like substance, but the miniatures are ready for scrubbing after just 30 minutes soak.

The stripper causes the acrylic paint (and top coat varnish) to become a slimy coating over the entire model:

A quick scrub with a toothbrush and most of the paint comes off in just a minute or two under a running tap. Not all of the paint came off in one go, with some of the paint proving quite stubborn in the deepest of recesses. However, this does help show up some of the finer details of the model, which may have got lost under the previous paint job.

After each model is stripped, we leave to soak in a bottle of clean water, to remove any nasty chemical residue left by the paint stripper, then dab dry with a towel and leave to dry out for a few hours in front of the fire.

We're going to take reference photos of all our stripped models, so that we can see where the finer details are after we've splodged paint all over them - it's very easy to miss the little bits and bobs, but it's these tiny examples of attention to detail that make the miniatures so impressive in the first instance - it'd be a shame not to show off the exquisite modelling to its best, which means painting and highlighting these parts that could otherwise go un-noticed.

Serial character LCD driver with Flash eeprom

No sooner had we got our serial character LCD display working than we were moving on to the next stage of the project - reading text from an Atmel AT45DB041D Flash eeprom chip to decide what to display on the screen.

We're already familiar with these chips, from our multiple servo controller board from back in May.
The idea is to store strings of text in these chips, then simply set a pointer (to tell the PIC where to start reading from) and get the microcontroller to read the text back and display it on the LCD.

We did look at I2C and other serial eeprom alternatives (at £1.20 each these Atmel chips are quite expensive for eeprom and at 4Mbit, are much bigger than we're ever going to need!) but most other (non-Flash) chips run at 100kz, or 400khz at best (yes, that's kilohertz, not Mhz). This will obviously make drawing text on the LCD run really slowly which is something we're keen to avoid.

These little Atmels can work up to 20Mhz. Which by happy coincidence is how fast the master chip will be running anyway, so hopefully we won't lose too much time reading and displaying text to the screen.

We wired our Flash eeprom chip up to PORTD on an 18F4550 (using RD.0-RD.3) and hacked some code together to read and write data to/from the chip. Amazingly, it worked first time!

AllDigital
Config PORTC = Output
Config PORTD = Output
Config PORTD.2 = Input

configuration:
       Symbol enablepin = PORTC.0
       Symbol clockpin = PORTC.1
       Symbol datapin = PORTC.2
     
declarations:
       Dim tmp As Byte
       Dim i As Byte
       Dim lcdi As Byte
       Dim lcdbyte As Byte
       Dim lcdbytetosend As Byte
       Dim rs As Bit
       Dim flag As Byte
       Dim mask As Byte
       Dim pageaddr As Word
       Dim byteaddr As Byte
       Dim byteswritten As Word
       Dim bytesread As Word
       Dim streamwrite As Bit
       Dim streamread As Bit
     
init:
       WaitMs 200
     
       Define SPI_CS_REG = PORTD
       Define SPI_CS_BIT = 0
       Define SPI_SCK_REG = PORTD
       Define SPI_SCK_BIT = 1
       Define SPI_SDI_REG = PORTD
       Define SPI_SDI_BIT = 2
       Define SPI_SDO_REG = PORTD
       Define SPI_SDO_BIT = 3
       SPIPrepare

       Gosub initialiselcd
       Gosub initialiseeeprom
     
       pageaddr = 1
       byteaddr = 0
       Gosub readanddisplaydata
            
loop:
     
       pageaddr = 1
       Gosub readanddisplaydata
       WaitMs 4000
       lcdbytetosend = 0x01 'clear screen
       Gosub writelcdcommand
     
       byteaddr = byteaddr + 16
       If byteaddr > 60 Then byteaddr = 0
     
       WaitMs 1000

Goto loop
End

writelcdnibble:
       Low enablepin
       Low clockpin
       If rs = 1 Then High datapin Else Low datapin

       Gosub toggleclockpin
     
       'shift in 4 bits
       mask = 8
       For lcdi = 1 To 4
              flag = lcdbyte And mask
              If flag = 0 Then Low datapin Else High datapin
              Gosub toggleclockpin
              mask = ShiftRight(mask, 1)
       Next lcdi
            
       'now strobe the clock one more time because ST+SC are tied
       Gosub toggleclockpin

       'toggle the enable pin to "flush" the data into the lcd
       Low datapin
       High enablepin
       Low enablepin
     
Return

toggleclockpin:
       'toggle the clock pin
       High clockpin
       Low clockpin
Return

writelcddata:
       rs = 1
       Gosub senddatatolcd
Return

writelcdcommand:
       rs = 0
       Gosub senddatatolcd
Return

senddatatolcd:
       lcdbyte = ShiftRight(lcdbytetosend, 4)
       Gosub writelcdnibble
       lcdbyte = lcdbytetosend And 15
       Gosub writelcdnibble
Return
     
initialiselcd:
       For i = 1 To 3
              WaitMs 50
              lcdbytetosend = 0x20
              Gosub writelcdcommand
       Next i
     
       WaitMs 50
       lcdbytetosend = 0x28 '4 bits, 2 lines, 5x7 font
       Gosub writelcdcommand
     
       WaitMs 50
       lcdbytetosend = 0x0c 'display on, no cursors
       Gosub writelcdcommand
     
       WaitMs 50
       lcdbytetosend = 0x06 'entry mode auto-increment
       Gosub writelcdcommand
     
       WaitMs 50
       lcdbytetosend = 0x01 'clear screen
       Gosub writelcdcommand
     
       'send a space character to the display to test
       WaitMs 50
       lcdbytetosend = 32
       Gosub writelcddata

Return

initialiseeeprom:
       Gosub set256pagesize
       Gosub chiperase
     
       pageaddr = 1
       byteaddr = 0
       WaitMs 100
     
       Gosub startstreamwrite
       For i = 0 To 63
              tmp = LookUp("Blood Bowl Griff Oberwald Varag Ghoulchew The Mighty Zug "), i
              SPISend tmp
       Next i
       Gosub endstreamwrite
     
Return

startstreamread:
       streamread = 1
       SPICSOn
       SPISend 0xe8 'stream read (legacy mode)
       SPISend pageaddr.HB
       SPISend pageaddr.LB
       SPISend byteaddr
       SPISend 0x00 'four don't care bytes
       SPISend 0x00
       SPISend 0x00
       SPISend 0x00
       bytesread = 0
Return

endstreamread:
       SPICSOff
       streamread = 0
Return

startstreamwrite:
       SPICSOff
       SPICSOn
       SPISend 0x82 '0x82 'write THROUGH buffer1 command
       SPISend pageaddr.HB '5 don't care bits + 11 address bits
       SPISend pageaddr.LB 'is the same as sending page address as hb/lb
       SPISend byteaddr 'last eight bits are buffer start byte
       byteswritten = 0
       streamwrite = 1
       WaitMs 5
Return

endstreamwrite:
       SPICSOff 'this causes the flash buffer to automatically get written to memory
       WaitMs 5
       streamwrite = 0
Return

set256pagesize:
       SPICSOn
       SPISend 0x3d
       SPISend 0x2a
       SPISend 0x80
       SPISend 0xa6
       SPICSOff
Return

chiperase:
       SPICSOn
       SPISend 0xc7
       SPISend 0x94
       SPISend 0x80
       SPISend 0x9a
       SPICSOff
       WaitMs 100
Return

readanddisplaydata:
       lcdbytetosend = 0x01 'clear screen
       Gosub writelcdcommand

       Gosub startstreamread
       For i = 1 To 16
              SPIReceive lcdbytetosend
              'for testing
              tmp = byteaddr + i
              Write tmp, lcdbytetosend
              Gosub writelcddata
       Next i
       Gosub endstreamread
Return

Note that in the initialiseeeprom routine we actually blank the Flash chip and write some data to it. In the final version of this code, we'll transfer data to Flash eeprom via a USB connection, but read it back just the same. Although this is just a basic test, it proves the idea of us storing character/player information in eeprom and calling it up and displaying it on a character-based LCD. All with just a few extra wires from the master microcontroller.

 [photo or video goes here]

Note that in this example we're using a rather tiny 2x16 character LCD (because we had some hanging around). We've got our fingers crossed that Santa will bring some larger 4x20 displays, like the one below which uses the same Hitachi 44780 controller chip, so the code should work for both.

With four lines of twenty characters, we can split player names over two lines (to allow really long forenames/surnames) and write player stats (MA, ST, AG, AV) on a single line - each stat (0-9) would take up four characters (XX-digit-space) so the output could look something like

 GRIFF
 OBERWALD

 MA4 ST5 AG8 AV9

Or, if we can get the player's name on a single line, something like:

 GRIFF OBERWALD

 MA   ST   AG   AV  
  4    5    8    9  

Blood Bowl miniatures

Back in the late 80s, Blood Bowl was all the rage, even with the cool kids who didn't even know that it had anything to do with Warhammer Fantasy miniatures, nor that Dungeons & Dragons was a game and not just an animated cartoon series on kids' TV.

Sadly none of our miniatures survived many house moves over the years (we've been nerds for a long time) - and maddeningly, the earlier, rarer pieces are commanding quite a price on eBay these days! Rather than pay over £30 for a team of original pieces, we've been looking for something a bit cheaper....

The original Blood Bowl teams were heavily armoured, with each character having lots of spikes, pads, over-sized shoulder pads and the like. The miniatures in the different teams looked very much like their Warhammer fantasy war-gaming counterparts (only without weapons).

The original Games Workshop Blood Bowl miniatures followed in this line.
But for us, Blood Bowl is first and foremost a strategy game of fantasy football that happens to include goblins and orcs and elves and other fantasy races. It's the game of football that makes the game fun and interesting to play, not the creatures that make up the different teams.

So it was really quite refreshing to find a team that were not only relatively cheap to buy (albeit second-hand) but they look more like a football team than a murdering crowd of goblins from Dungeons & Dragons:

Of course, for testing our electronic game board we can use copper discs (two pence pieces are the perfect size) but the whole thing would look much more like a board game with the correct pieces on it! Unfortunately it's that time of year again where buying stuff willy-nilly off the internet is out of the question, as friends and family members are on the look-out for gift ideas; so we'll just have to sit tight and see what Santa brings in a few weeks. In the meantime, there's the board to finish so we'll post some more updates here soon......

Blood Bowl electronic board - slave board complete

Here's a quick update on our slave board for the Blood Bowl electronic board

The top board is underside of the slave board, which is basically a 40-pin 16F877A (any 40-pin PIC with hardware UART/USART would do, even the 18F4550 - but you'd be spending a lot more than necessary on your slave chip and not using most of the peripherals that you'd paid for! We just used one of the many 16F chips we had knocking around, not necessarily the cheapest/best fit for the job. One of the cheaper 16Fs from Farnell is the 16F1939 available for about £2.80 per unit)

The bottom board shows an arrangement of four 1x4 board modules (ok, it's actually 2 of our earlier 2x4 boards but the wiring is exactly the same!) We've wired them so that the two boards vertically share the same "row" signal wire. So both the boards on the left will come "live" at the same time, when row1 is sent high by the master board. Then the boards on the right will both come on at the same time. The two orange wires are the "row" signal wires and will connect to the master controller. The grey wires (to the left) will connect to the inputs on the slave controller.

Although not immediately obvious from the nasty photo (iPad cameras are about as good as cheap HP ones in low light) the slave board is simply a PIC microcontroller, a crystal, 4 wires (1 power, 1 ground, 1 serial TX, 1 serial trigger/handshaking line on the RX pin) and all the remaining digital i/o pins pulled to ground through some 100K SMT resistors.

Blood Bowl board game slave board

Our intelligent Blood Bowl game board consists of two PIC micros which talk to each other via serial (during testing we're using 9600 baud but will crank this up for the final version). The slave board is simply a 40-pin 16F877A with pull-down resistors on all the digital i/o pins.

To allow for maximum flexibility, we're designing this slave board to accept as wide a range of PIC microcontrollers as possible, including some of the 18F series chips (if you have some hanging around from other projects, why not use them instead of buying in new?) Allowing for the power, ground, TX and RX pins (which are in the same place in the 40-pin 16F and 18F chips), as well as the useless Vusb pin on the 18F (useless in this case since we can't use UART and USB together) and the handshaking line we've got a maximum of 30 input pins (we could use the RX pin for handshaking, but for now we'll keep that clear in case we can come up with a use for it in future). In the diagram above, all available i/o pins have been taken out to a set of SMT (1206 sized) resistor pads, and all the resistors are tied to ground (making them pull-down resistors on each input).

30 inputs is an awkward number to work with since each board module is 4 squares in size the maximum number of inputs we can use is 28 (4*7=28). So we've got two free input pins on the slave board should the need arise, as we develop the concept further.


Slave Board

Intelligent board game (Blood Bowl) development

Here are some photos of the latest board game development;
although we're working on a Blood Bowl clone, the same technology could - in theory - be used for a large number of games, with different board sizes. To date, we've settled on a 4-square module and will make our board game(s) up from this/these.

These photos are from our 4x2 boards (earlier design) but the principles work the same for both.
On the sides of each playing square (N,S,E and W) we drilled a 1mm hole and soldered some pcb studs

The studs are slightly raised on the playing surface of the game board. This isn't as nasty as it sounds - for our Blood Bowl game, it means we can add some "flocking" or similar covering but still get the playing pieces to make a good contact with the pins.

stupid cheap HP camera - even in "macro mode" it doesn't quite know what to focus on!

The plan is to weight our playing piece bases with a small copper disk (something like a 2 pence piece would be ideal, only we don't want to get thrown in prison for "defacing a coin of the realm" or whatever the punishment is these days!). Placing these on the playing side of the board bridges the two connections between the "rows" output pin on the master controller and the "columns" input pin on the slave - so when the slave is asked "which inputs are high/low" this can be used to work out which squares have playing pieces on them.

once again, a nice focussing job by our little HP camera

The tracking of which playing piece is on which square will be done by the master IC. For these early prototypes, we're more concerned about proving the concept of tracking which piece is being lifted/replaced to/from the board.

Creating the playing squares for an intelligent board game board

While toner-transferring and etching our game board "modules" something became obvious - though it's not something we'd thought of when designing our PCBs. The photo below shows our game board etched onto a piece of eurocard sized (160mm x 100mm) copper-clad board

While trimming to size, we realised that the bit cut off the bottom was almost exactly the right size for a single row of 4 playing squares (the printed module above shows a 2x4 grid of playing squares). It then occurred to us that there's no real reason why we couldn't create modules that were 1x4 instead of 2x4.

After all, the top row still has to be connected to the bottom row using a wire jumper/via even when they are drawn/etched on the same piece of board. So here's the new PCB layout for four playing squares at a time:

Since the spacing of the playing squares is 30mm (standard Blood Bowl size) the PCB is also 30mm high (with the playing squares pretty much in the middle of each "strip" of 1x4 squares).

If you want smaller playing squares, simply resize the whole PCB. The overall size will shrink to match the size of each playing square so they should still be able to be cut to size and placed side-by-side, without affecting the spacing between playing squares.

4x1 Board Piece

As you can see, they line up perfectly for connecting horizontally once etched and cut to size:

A little bit of multi-core wire or maybe even some gloopy solder should connect the two boards, edge-to-edge.

Electronic board game - Blood Bowl clone

Some interesting developments over the last few evenings as we've put together all kinds of ideas for an intelligent board for a board game (like, our old favourite Blood Bowl).
Our original proposal - based on freeing up as many pins as possible from two 40-pin PIC microcontrollers - was to allow for up to 600 squares, or a grid of 20x30

To allow for as much flexibility as possible, while at the same time making it relatively easy to understand, we've decided on a modular approach. Our board game will actually be made up of a grid of 4x2 "blocks" which can then be wired together in any arrangement. It means we've lost the flexibility of really wacky board layouts (although using the same technology it should be possible to create one-off boards with pretty much any layout as required) but does mean that we can simplify making boards of different dimensions.
(it also means that anyone who buys their copper boards in eurocard 100mmx160mm size can still make a board game, using a "patchwork" of smaller boards)

4x2 Board Piece

Each playing square in this board is marked out by a "cross" shape on the board. Small through-hole studs are soldered to this underside, so that on the playing side of the board, a small contact point is visible on the playing surface. Each playing piece has a conductive base (a copper coin glued to the bottom would suffice!) and when placed over the four points of a cross, makes a connection between the top and right contacts and the bottom/left contacts.

Using the above layout, we can place these pieces side-by-side and join the edges, while connecting each group of top/right contacts together using short pieces of (insulated) wire

Using this approach, we've designed our Blood Bowl board.
It's not quite 30 x 20, but we found that vertically connecting 7 "rows" of 4 contacts means for each row we can read back up to 28 lines of "column" data. By placing four of these smaller boards side-by-side, our board size is 28 x 16 playing squares. Not a bad compromise and certainly a sizeable playing area for a lot of different board games.

So what does it look like? In short, a nightmare!

As you can see, each smaller board is connected to the board horizontally next to it (the traces were deliberately lined up to make this bit quite easy). Every 7 vertical rows of contacts are connected via wire traces (shown in this diagram by different coloured bars) and each group of these 7x4 = 28 contacts is then connected to the slave microcontroller via a short wire (the connection points for these wires are circled in a matching colour).

There are 16 wire connect points - these go to the master PIC. The 28 traces from the bottom/left sets of contact points are connected to the slave. By flashing one of the 16 wires at a time, and reading the input values on the 28 inputs, we should be able to work out which set(s) of contacts are being bridged by a playing piece on the board.

That's the theory anyway.......

Using 2 PIC micros for a huge input array

After spending some time thinking about a large board game input device - which simply tracks the position of each piece by comparing the current board state to a previously known state - we've decided that a multi-plexed approach will probably be the easiest to implement.

The problem with a multi-plexed approach is that whatever size grid is used determines the number of pins needed (so a 10 x 10 grid needs 10+10=20 i/o pins).

Rather than try the idea out with something simple, then discover it doesn't expand well for bigger/more complex games, we've decided to have a go at quite a complex game, and - if it works - scale it back for simpler board games. For now, we're concentrating on tracking the positions of "dumb" game pieces on the board throughout a game.

One of our favourite geek-games of the 80s was Blood Bowl (which thanks to a console remake being released in 2011 is seeing a bit of revival in recent months). Now, the original Blood Bowl board was a massive 15 x 26 = 390 squares in size.

Obviously, using a PIC with only about 30 spare pins is never going to cut it. So we're back to either using analogue inputs or increasing the i/o pins using shift registers. After much discussion, however, one idea really started to appeal: use two PIC microcontrollers!

This is not only cheaper than implementing a whole array of shift registers, but also gives us a bit more oomph to play with, as we could split game play up over a master and a slave controller.

We're planning on using the master to activate an entire "row" of inputs (the output Port1 in this previous port) but then to start listening on a serial RX pin for a response from the slave. The slave micro simply looks at the input state of all the pins (uC Port2 input in this previous post) and sends this back to the master via serial TX.

Because the master knows which row it activated, it can decode the value received over serial and work out which combination of buttons/inputs were activated. Now, by using 2 x 18F4550 chips, we've up to 30 pins available on each chip and a grid of 30 x 30 inputs (900 squares) is suddenly achievable.

For our Blood Bowl game, we could easily implement a 15 x 26 grid of squares and still have about 15 i/o pins freed up on our master controller (this controlling 15 rows, with the 26 inputs on each column being read by the slave controller). With this in mind, and after much more discussion (and a few more cups of tea and a whole packet of hob-nobs) we reckon we could come up with a generic board game controller which would have:

a) support for up to 600 squares (e.g. 20x30 but not necessarily in a square formation)
b) an LCD display for each player/side which can display current game status
c) built-in dice roll and other random-number generators
d) ability to calculate results/outcomes which would otherwise require dice rolls and table look-ups in the rule book

Although we've not actually built anything yet, this is quite an exciting development.
We remember Blood Bowl as being a great game, but bogged down with dice rolling, looking up results in tables, applying modifiers based on the playing piece type and so on. The Third Edition of Blood Bowl tried to do away with a lot of this by using a simpler dice system, but eventually the same thing happened: the immediate action could be resolved quickly (did a particular action succeed or fail) but when this affected another players ability, yet more dice rolls and table look-ups were necessary.

 If we could remove all this dice rolling and referring back to the rule book and introduce a simple interface - so a player could pick up a piece to identify which is being moved, then press a button to say which action they were performing - the microcontroller could do all the random number generating and issue resolving; simply displaying a message on an LCD screen to the user, to inform them of the outcome and what to do next.

Here's how our Blood Bowl game could look with the clever electronics in place: