Is 20mm the new 15mm? Why isn't it more popular?

A little while back, we got hold of some 15mm soldiers.
We discovered that painting such little miniatures required a different approach to our earlier painting techniques. Then we got some 15mm zombies. But they were way out of scale.

Our soldier miniature was enormous and chunky, and the zombies - although well sculpted and full of character, even at such a small scale - tiny and puny. It turned out that our solider was nearer 20mm and the zombies were "true" 15mm scale.

For a large horde of zombies, we figured that 15mm would be a good scale to use. Except when we came to put terrain and build a bit of interest and detail into the playing surface, things looked a little odd. Our zombieville terrain includes some outdoor scenarios, so it seemed obvious to get hold of some little cars. Die cast Corgi cars would be great. Except they look massive compared to our 15mm zombies.

Now when it somes to model-making, miniature diorama building and the like, things like scale and size start to get a bit tricky. Model makers are sticklers for scale. Tabletop wargamers tend to work with miniatures of a certain size.

Tabletop gaming miniatures used to be 25mm. The idea being that an average human character would stand at about 1.8m (1800mm) high, and at a scale of 1:72, an 1800mm high himan would be scaled down to 1800/72  = 25mm.

Then, about fifteen years or more ago, miniature painters started to demand more detail on their models. Miniatures were more commonly created at 28mm, with the argument that a model which was 25mm high to the eyeline should be about 28mm in total height.

So far so good, but in the last few years, we've started to see heroic scale miniatures - these are basically "big and chunky" 28mm miniatures - which are nearer 32mm in size (with 28mm being the height to the eyeline). Because they are a bit bigger, the models have lots of nice detail, and are a little easier to paint. And as 32mm has become the popular "heroic scale" and with the advent of super-detailed, resin-cast miniatures, 35mm is becoming the new 28mm (or the new 32mm, or the new 35mm scale... you get the idea).

Likewise, 15mm miniatures are also seeing "scale creep" - with many 15mm miniatures actually measuring anywhere between 16mm - 19mm high. Having already discovered that "true" 15mm models are too small, and 25mm miniatures are too big to use alongside street furniture, like Corgi cars, what we need is something somewhere inbetween....

As luck would have it, Elheim Miniatures do a range of 20mm gaming pieces. Their website states "All our miniatures are 1/72 scale (20mm in wargame sizes)..."

Incredibly, Elheim sell a whopping 20 zombies for just £12.
Compare that to 28mm (or 32mm heroic scale if you like) where you can easily pay between £4 and £14 per single miniature(?!) and you can see that 20mm offers great value for money.

The sculpts are nice and detailed, but small enough to be quickly painted too (we eventually managed seven zombies in about two-and-a-half hours, not including Quickshade drying time).

And just as importantly - for a zombie apocalypse scenario with outdoor settings - they're just the right size for use with our terrain and street furniture. We're keen to stick to models that are easily accessible, so if anyone else wishes to play the same scenario(s), they can use easily-sourced "props" for the game (like die-cast cars from a local charity shop or supermarket, as we managed).

(included in the photo above is a Hot Wheels car, from Asda that cost just 99p)

With our scale now sorted out (seriously, why isn't 20mm more popular for tabletop gaming?) it was time to crack open the Army Painter Mega Set and see how they looked painted up. As the sculpts are a little larger and have a bit more detail than the "true" 15mm minis (though not so much as to require as much time and effort as the 28mm/32mm models) we decided to go back to our preferred painting method:

1. Prime the miniatures with white spray

2. Splash on bright base colours

3. Hit the miniature with Quickshade Dark Tone (we used Dark rather than Strong Tone to create a higher contrast between the edges and crevasses in the sculpt - these miniatures are still quite small, so a high-contrast approach works well)

4. After drying, coat with Dullcote to take the shine away, and add some very simple edge highlights. There is no need to spend a great deal of time on this stage, but picking out the odd highlight can really make the difference when the model is viewed from arm's length on the tabletop.

(once again, the flash on the camera makes the edge highlights on these models look much more severe than they are in real life - though we did use quite high contrasting colours)

5. Mix up some Tamiya Clear Red and black in and splosh on the gore!

For our cars, we simply coated the original vehicle, straight from the packet, in Quickshade Dark Tone. We applied the tone quite liberally to help reduce the effect of any brushstrokes, but took care to avoid "pooling" where possible.

This time we left the car, without applying Dullcote, to keep the slightly shiny effect (after drying, the Dark Tone wasn't quite as shiny as we expected). This is because most modern cars are finished with a metallic (rather than purely matt) paint, so the slight sheen simulated the car paint finish quite well. The Dark Tone picks out all the edges and door outlines and so on quite nicely.

Maybe we went a step too far this time - the orange edge highlighting just didn't quite work on this one. Maybe it was the choice of colours, or maybe it was just an effect that isn't suitable for this kind of model. But in future we're going to just stick to Dark Tone and call it done!

We think that the 20mm zombies (and survior) models look great on the tabletop alongside the easily-sourced die-cast cars. There's a whole raft of easily-found street furniture and terrain building materials available in 1:72 (and, if you really need it 1:76) scale and even model railway 00 scale. And it all fits in quite nicely with our 20mm miniatures.

Grumpy Paul even suggested using some old "Linka" moulds to make terrain and buildings for this new scale. Although not exactly a perfect match for our 1" square grid (a four-section terrace takes up almost 5" on the board), a short terrace of houses can be quickly and easily made up by casting just a few pieces, and they don't look too small or out-of-scale for the miniatures:

(painting the brickwork on these models was quite quick - mix up a red/brown paint and dry-brush directly onto the bare plaster; the white appears as the mortar between the bricks. If necessary, a quick sepia wash can tone the shade whole model down, but - since our zombies are so cartoon-y - we quite like the bright-and-clean look, for now)

20mm miniatures are almost as cheap, per unit, as 15mm miniatures (whereas 28mm are comparatively expensive) and terrain is cheap and easily found in a range of styles. Which begs the question - why isn't 20mm more popular for tabletop gaming??

Cirque du Soleil Kooza - back to their breath-taking best!

If you've seen any of the Cirque du Soleil shows in recent years, you'd be forgiven for thinking twice about their latest show, Kooza, currently showing at the Albert Hall in London.

In fact, since seeing Quidam in their Big Top in Manchester, a number of years ago, we've much preferred their performances in the tent, rather than what seems to be their new home, at the Albert Hall. But it's not just the venue that's been a bit disappointing in recent years. Sure, Varekai was very clever, but it lacked the sparkle and excitement of Saltimbanco.

Alegria was full of in-flight trapeze trickery but the whole show looked like it wasn't quite big enough to fill the Albert Hall - Dralion was far more impressive, despite the large set pieces, for being in the confines of the Big Top.

Totem was technically very impressive, with large video screens merging with live action performance, but the actual choreography left a little to be desired - it was almost as if the technology had taken precedence over the performance: until Totem, we hadn't ever seen a performer miss a trick or fail or fall. If nothing else, the performers were expert at disguising, if not avoiding, mistakes - but Totem was littered with failed attempts at big set pieces.

And the less said about the abysmal Michael Jackson tribute, the better!

Nick and I have seen a lot of the Cirque du Soleil shows both in the UK and across Europe. Early shows like Quidam, Saltimbanco and Dralion were filled with breath-taking acrobatics and circus skills; things which made you gasp and marvel, as well as scratch your head at the sheer bizarreness of it all!

Later shows like Varekai and Totem were a bit, well, "meh". And we should really have insisted on a refund for the Michael Jackson tribute show  - it stank!

When Kooza was first advertised, we gave it a miss.
We'd spent enough of our hard-earned with Cirque, and the last two or three shows had been, frankly, disappointing. So we weren't going to be stung again (the cost of the tickets has steadily increased over the years, from about £25 to over £65 for the latest shows).

Then somehow, we had a date in the diary and a day out in London planned (sure Brighton is only an hour and half away on the train, but anyone who's ever used the Southern Trains service will understand why you need to set aside a whole day to make the trip!) and were, once again, off to the Albert Hall. It was with some trepidation we arrived for a matinee performance.

Being wary of overspending at yet another below-par performance, we didn't even see the programme notes which said that Kooza was "...a return to the origins of Cirque du Soleil: it combines two circus traditions - acrobatic performance and the art of clowning. The show highlights the physical demands of human performance in all its splendor and fragility, presented in a colorful mélange that emphasizes bold slapstick humor."

In all honesty, the programme "information" is often little more than pretentious fluff, even in their good shows! But reading further, the programme also revealed that the artistic directors for Kooza were some of the original Cirque du Soleil directors. In short, they said, we were in for a treat!

From the moment the on-stage live band started thumping out their world-music/heavy-metal fusion riffs it felt like "classic" Cirque. The clowns were great. The acrobats were amazing. The whole performance fizzed with excitement, and the performers couldn't put a foot wrong. The show was funny, and smart; the acrobatics incredible and the feats of physical exertion unbelievable.

In the second half, the show turned almost burlesque, with tall skeletal characters and feather boas dancing across the stage. The music kept things moving along at a pace, and the performances were breath-taking. It was almost impossible to watch the guys on the "wheels of death" without gasping out loud!

I was asked, as we left the show, how it had been (friends and family knew we were hesitant about going). The answer easily fit into 160 characters. Simply put, Cirque got good again.

If you've ever seen Cirque du Soleil and ever wondered what all the fuss was about (or had the misfortune to think that horrible TV show with Ruby Wax was anything to do with them) get some tickets to Kooza and see what they're really all about. If you've never seen Cirque du Soleil, this is one of the better shows we've seen - so don't let dodgy reviews about past shows put you off (but, equally, give the MJ Tribute a wide berth!)

It's been a long time since Cirque put on such a (quite literally at times) breath-taking show. If you like live performances of any kind - live music, dance, magic, comedy, circus skills, stunts, or a combination of any or all of these, Kooza delivers on every level. A great show!

Connecting to an OV7670 camera with a PIC microcontroller

Before even starting with this little module (that arrived just after Xmas, so we've had to wait a couple of weeks before we got our hands dirty with it!) we probably spent about four hours trawling the 'net looking for ways of not only setting the device up over the I2C-alike interface, but also getting the image data out.

There are plenty of websites which describe sending commands to the camera over I2C (it's actually called SCCB but it is pretty much I2C in all but name) but there's very little about getting at the actual image data. There are a few websites which mention accessing the image data via the RX/TX pins - but our module doesn't have these.

It turn out - after much research - that there are two versions of this camera module. One has a FIFO/eeprom chip onboard which captures the image data and streams it out over standard UART/serial pins. The cheaper modules (so, obviously, the type we have) doesn't support this - you need to grab the image data off the pins yourself.

Again, information on how to do this over the I2C bus is pretty thin on the ground. Then we found this: http://core-electronics.com.au/vga-ov7670-camera-module-i2c-640x480.html

Under "reviews" it says:

The I2C like interface is only for camera control. The camera image data is output over a parallel bus. Now that starts to explain things a little....

Another website gives pretty in-depth details about grabbing the image data: http://embeddedprogrammer.blogspot.co.uk/2012/07/hacking-ov7670-camera-module-sccb-cheat.html

Of particular interest to us on this page is the following timing chart:

Now, we're not too bothered about capturing a full 640x480 pixels at VGA 30fps speed. We're planning on capturing a scaled-down version of the image (usually called QQCIF) which is 88 x 72 pixels. We're planning on driving the PCLK line ourselves from a microcontroller pin (rather than derive it from the main clock source) so we don't have to worry about complex timing protocols or making sure we can buffer or send the image data in chunks between the VSYNC/HREF pulses. If we control the PCLK (pixel clock) we effectively control when the VSYNC/HREF lines go high/low.

If we could just find a way of setting those pesky register values.....

Before we can use the camera module, even to talk to it over the I2C bus, we need to provide it with a clock signal. This is not the "pixel clock" - but a generic clock, to get it up and running (much like you need to give a microcontroller a crystal or other clock signal, as well as any I2C/SPI clock signals). Since we're using a crystal for our PIC, we can also put the CLKOUT pin onto the camera's XCLK (external clock) pin. We're using a 20Mhz crystal for our PIC, which means the camera module is also getting a 20Mhz clock pulse (the camera module datasheet recommends a 10Mhz-48mhz main clock source - some users have reported success with 8Mhz or lower and some people have reported problems if the clock source is too slow).

Because we're expecting the image data to appear on the D0-D7 pins of the camera module (rather than over a serial-type connection, which the FIFO versions support) as well as needing to drive/monitor a number of other pins on the camera, we're using a beefy 40-pin PIC; we could get away with a 28-pin variety, like an 18F2455 but sticking with a 40-pin chip, like an 18F4550 or even the lowly 16F877A means we've plenty of spare I/O and onboard peripherals, should we need them in future.

The only thing we were particular about with this set-up is that the D0-D7 pins of the camera module are mapped to the PORTx0 - PORTx7 pins on the PIC. This allows us to read the image data byte directly off an input PORT, instead of having to build up the byte from individual bits scattered across a number of different input port pins. Because we can't be sure whether the camera module uses an open collector on the D0-D7 pins (effectively driving them low and letting them float otherwise) or actively drives them both high and low to represent the image data, we're using an input port with active pull-up resistors. Similarly, because the SCCB/I2C lines use open collectors to drive the pins low and then float when released, we need to make sure they're connected to Vcc through pull-up resistors (4K7 or 10K should suffice).

Define CONFIG = 0x3f32
Define CLOCK_FREQUENCY = 20
Define STRING_MAX_LENGTH = 30

AllDigital
Symbol led_pin = PORTC.5
Symbol tx = PORTC.6
Symbol rx = PORTC.7

Symbol sda = PORTC.5
Symbol scl = PORTC.4

definitions:
     Dim state As Byte
     Dim i As Byte
     Dim j As Byte
     Dim k As Byte
     Dim data As Byte
   
     Const i2c_read_addr = 0x43
     Const i2c_write_addr = 0x42
   
initialise:

     state = 0
     Hseropen 9600

bootup:
     WaitMs 1000
     High led_pin
     WaitMs 1000
     Low led_pin
     Hserout "READY", CrLf
     WaitMs 1000

loop:

     Select Case state
   
           Case 0 'after bootup
           High led_pin
           For i = 0 To 0xc9
                 I2CRead sda, scl, i2c_read_addr, i, data
                 Hserout "ADDR ["
                 k = i
                 Gosub k_to_hex
                 Hserout "] VALUE "
                 k = data
                 Gosub k_to_hex
                 Hserout CrLf
           Next i
           state = 1
         
         
           Case 1 'we've just read the register values back
           Low led_pin

         
     EndSelect
Goto loop
End

k_to_hex:
     j = ShiftRight(k, 4)
     j = j And 15
     If j = 15 Then Hserout "F"
     If j = 14 Then Hserout "E"
     If j = 13 Then Hserout "D"
     If j = 12 Then Hserout "C"
     If j = 11 Then Hserout "B"
     If j = 10 Then Hserout "A"
     If j < 10 Then Hserout #j
   
     j = k And 15
     If j = 15 Then Hserout "F"
     If j = 14 Then Hserout "E"
     If j = 13 Then Hserout "D"
     If j = 12 Then Hserout "C"
     If j = 11 Then Hserout "B"
     If j = 10 Then Hserout "A"
     If j < 10 Then Hserout #j
Return

A simple I2C to UART/serial routine enabled us to read back the settings from the camera device. Some of the values were not quite the same as the default values in the datasheet, but we demonstrated that we were actually communicating with the device (and not just reading static) by removing the XCLK line and receiving all 0xFF as expected. Our default register values are listed below:

ADDR [00] VALUE FF
ADDR [01] VALUE 80
ADDR [02] VALUE 8C
ADDR [03] VALUE 00
ADDR [04] VALUE 01
ADDR [05] VALUE 77
ADDR [06] VALUE 35
ADDR [07] VALUE 40
ADDR [08] VALUE 78
ADDR [09] VALUE 01
ADDR [0A] VALUE 76
ADDR [0B] VALUE 73
ADDR [0C] VALUE 00
ADDR [0D] VALUE 00
ADDR [0E] VALUE 01
ADDR [0F] VALUE 43
ADDR [10] VALUE 7F
ADDR [11] VALUE 80
ADDR [12] VALUE 00
ADDR [13] VALUE 8F
ADDR [14] VALUE 4A
ADDR [15] VALUE 00
ADDR [16] VALUE 00
ADDR [17] VALUE 11
ADDR [18] VALUE 61
ADDR [19] VALUE 03
ADDR [1A] VALUE 7B
ADDR [1B] VALUE 00
ADDR [1C] VALUE 7F
ADDR [1D] VALUE A2
ADDR [1E] VALUE 01
ADDR [1F] VALUE 00
ADDR [20] VALUE 04
ADDR [21] VALUE 02
ADDR [22] VALUE 01
ADDR [23] VALUE 00
ADDR [24] VALUE 75
ADDR [25] VALUE 63
ADDR [26] VALUE D4
ADDR [27] VALUE 80
ADDR [28] VALUE 80
ADDR [29] VALUE 07
ADDR [2A] VALUE 00
ADDR [2B] VALUE 00
ADDR [2C] VALUE 80
ADDR [2D] VALUE 00
ADDR [2E] VALUE 00
ADDR [2F] VALUE 36
ADDR [30] VALUE 08
ADDR [31] VALUE 30
ADDR [32] VALUE 80
ADDR [33] VALUE 08
ADDR [34] VALUE 11
ADDR [35] VALUE 1A
ADDR [36] VALUE 00
ADDR [37] VALUE 3F
ADDR [38] VALUE 01
ADDR [39] VALUE 00
ADDR [3A] VALUE 0D
ADDR [3B] VALUE 00
ADDR [3C] VALUE 68
ADDR [3D] VALUE 88
ADDR [3E] VALUE 00
ADDR [3F] VALUE 00
ADDR [40] VALUE C0
ADDR [41] VALUE 08
ADDR [42] VALUE 00
ADDR [43] VALUE 14
ADDR [44] VALUE F0
ADDR [45] VALUE 45
ADDR [46] VALUE 61
ADDR [47] VALUE 51
ADDR [48] VALUE 79
ADDR [49] VALUE 00
ADDR [4A] VALUE 00
ADDR [4B] VALUE 00
ADDR [4C] VALUE 00
ADDR [4D] VALUE 04
ADDR [4E] VALUE 00
ADDR [4F] VALUE 40
ADDR [50] VALUE 34
ADDR [51] VALUE 0C
ADDR [52] VALUE 17
ADDR [53] VALUE 29
ADDR [54] VALUE 40
ADDR [55] VALUE 00
ADDR [56] VALUE 40
ADDR [57] VALUE 80
ADDR [58] VALUE 1E
ADDR [59] VALUE 91
ADDR [5A] VALUE 94
ADDR [5B] VALUE AA
ADDR [5C] VALUE 71
ADDR [5D] VALUE 8D
ADDR [5E] VALUE 0F
ADDR [5F] VALUE F0
ADDR [60] VALUE F0
ADDR [61] VALUE F0
ADDR [62] VALUE 00
ADDR [63] VALUE 00
ADDR [64] VALUE 50
ADDR [65] VALUE 30
ADDR [66] VALUE 00
ADDR [67] VALUE 80
ADDR [68] VALUE 80
ADDR [69] VALUE 00
ADDR [6A] VALUE 94
ADDR [6B] VALUE 0A
ADDR [6C] VALUE 02
ADDR [6D] VALUE 55
ADDR [6E] VALUE C0
ADDR [6F] VALUE 9A
ADDR [70] VALUE 3A
ADDR [71] VALUE 35
ADDR [72] VALUE 11
ADDR [73] VALUE 00
ADDR [74] VALUE 00
ADDR [75] VALUE 0F
ADDR [76] VALUE 01
ADDR [77] VALUE 10
ADDR [78] VALUE 00
ADDR [79] VALUE 00
ADDR [7A] VALUE 24
ADDR [7B] VALUE 04
ADDR [7C] VALUE 07
ADDR [7D] VALUE 10
ADDR [7E] VALUE 28
ADDR [7F] VALUE 36
ADDR [80] VALUE 44
ADDR [81] VALUE 52
ADDR [82] VALUE 60
ADDR [83] VALUE 6C
ADDR [84] VALUE 78
ADDR [85] VALUE 8C
ADDR [86] VALUE 9E
ADDR [87] VALUE BB
ADDR [88] VALUE D2
ADDR [89] VALUE E5
ADDR [8A] VALUE 00
ADDR [8B] VALUE 00
ADDR [8C] VALUE 00
ADDR [8D] VALUE 0F
ADDR [8E] VALUE 00
ADDR [8F] VALUE 00
ADDR [90] VALUE 00
ADDR [91] VALUE 00
ADDR [92] VALUE 00
ADDR [93] VALUE 00
ADDR [94] VALUE 50
ADDR [95] VALUE 50
ADDR [96] VALUE 01
ADDR [97] VALUE 01
ADDR [98] VALUE 10
ADDR [99] VALUE 40
ADDR [9A] VALUE 40
ADDR [9B] VALUE 20
ADDR [9C] VALUE 00
ADDR [9D] VALUE 99
ADDR [9E] VALUE 7F
ADDR [9F] VALUE C0
ADDR [A0] VALUE 90
ADDR [A1] VALUE 03
ADDR [A2] VALUE 02
ADDR [A3] VALUE 03
ADDR [A4] VALUE 00
ADDR [A5] VALUE 0F
ADDR [A6] VALUE F0
ADDR [A7] VALUE C1
ADDR [A8] VALUE F0
ADDR [A9] VALUE C1
ADDR [AA] VALUE 14
ADDR [AB] VALUE 0F
ADDR [AC] VALUE 00
ADDR [AD] VALUE 80
ADDR [AE] VALUE 80
ADDR [AF] VALUE 80
ADDR [B0] VALUE 00
ADDR [B1] VALUE 00
ADDR [B2] VALUE 00
ADDR [B3] VALUE 80
ADDR [B4] VALUE 00
ADDR [B5] VALUE 04
ADDR [B6] VALUE 00
ADDR [B7] VALUE 66
ADDR [B8] VALUE 00
ADDR [B9] VALUE 06
ADDR [BA] VALUE 00
ADDR [BB] VALUE 00
ADDR [BC] VALUE 00
ADDR [BD] VALUE 00
ADDR [BE] VALUE 00
ADDR [BF] VALUE 00
ADDR [C0] VALUE 00
ADDR [C1] VALUE 00
ADDR [C2] VALUE 00
ADDR [C3] VALUE 00
ADDR [C4] VALUE 00
ADDR [C5] VALUE 00
ADDR [C6] VALUE FF
ADDR [C7] VALUE FF
ADDR [C8] VALUE 06
ADDR [C9] VALUE C0

There are enough recognisable "default" values consistently being read back to convince us that we're talking to the camera device (some register values vary a little from read-to-read, but these are values like "white balance" which, if the module is working under "auto-balance" mode, you'd expect to be changing over time anyway). But there are also enough that vary quite a bit from the datasheet to make us wonder whether we're working with a newer/older model, or whether the data is getting messed up somewhere along the way. So far, we're not sure - it could be either; the next job is to set some register values and see if they are retained (strangely, to set a register value, you write to SPI address 0x42 but for reading, you read from address 0x43 - there's probably a reason for this to do with full-duplex communication or something, but it does seem a little strange!).

There's a quick-and-simple test for these modules that a lot of people mention - cover the lens with the lens cap and read back the image data. A fully black image should be a sequence of 0x00 and 0x80 bytes, apparently.

Let's get this thing wired up and find out.....

15mm zombies

"Last Night In Zombieville" is our co-op game being planned for multiple players. This morning a small parcel filled with some 15mm zombies from Khurasan Miniatures turned up so we were keen to try a few out. Our thirty-strong horde looked great on the playing surface (though there's a very real possibility we're going to need about twice as many for a real multi-player zombie-fest!)

Having already tried a number of different painting methods for 15mm minis, and with about 30 zombies to try out, we decided to try the traditional white-undercoat-and-black-ink-wash approach, to see how it compared with earlier methods.

We'd already got a few soldier models painted up, but were surprised to find that these miniatures seemed much smaller - not just shorter, but far less "bulky". So what was going on?

It turns out that, much like the 28mm scale, 15mm miniatures are suffering from "scale creep". What this basically means is that manufacturers make their models a bit "chunkier" to make them easier to paint. But they're no longer the original scale (a 28mm model originally derived from a 25mm miniature - and 28mm models are now quite often 32mm, and up to 35mm tall).

Above - a supposed-15mm soldier measures 20mm from feet to top of head (the angle of the photo doesn't show it very well but we did actually measure from the top of the base - where the feet start - and did not include the thickness of the base in the measurement)

Our zombie miniatures, however, are about 16mm from feet to top-of-head. Still actually a little bigger than the 15mm "standard" but close enough. They're also much "skinnier" than the 20mm soldiers. It seems that we're going to have to be a little careful about where we source "matching" miniatures from in future. But for now, we've a zombie horde to paint!

Unlike what seems like everyone else on the internet is doing, we thought we'd try undercoating in white this time:

Then, just as we do with our 28mm models, added block colours to the larger areas

As with our other miniatures, we went one shade "brighter" than we wanted our final miniatures to be. But not to worry - the water-based Dark Tone will soon take care of those garish colours!

Now the miniatures are showing a lot of their detail, they're just a little bit dark - even for zombies. Painting over the darkened colours with the original shades (and, on occasion paler/brighter shades for extreme highlights) brought the models up to their final colour scheme.

(like most "tabletop quality" miniature painting, these zombies look fine from a few feet away - or when viewed in a small 480x320 image, but click on the image, or look at them up close and the illusion is shattered! These minis are painted to look good in large horde from across the tabletop - not individually up close)

Last stage - for the zombies at least - is a bit of gore around the hands and mouth. Blood red is far too bright for this, so we made a mix of red and black ink. The ink gives the darkened red a little bit of "sheen" to indicate fresh, wet blood.

(the black ink in the semi-translucent red gloss paint gives the illusion of depth - blood that is getting old and starting to congeal, with a bright, shiny red to indicate fresh blood from repeated wounds)

Where some of the models have "holes" sculpted into their limbs, these two got a generous application of blood/gore red. We also applied a messy red blob around the mouth (apparently zombies aren't known for their table manners and meticulous use of knives and forks) and a dribble down the front - zombies are really messy eaters!

(The flash on the camera shows the blood red to be far brighter in colour than it appears on the models, but picks up the glistening, wet-look of the blood effect quite nicely. Even at 15mm, you wouldn't want to meet these tiny terrors down a dark alleyway!)

A smattering of Tamya Clear Gloss Red finishes the gore effect and adds an extra bit of wet-look glisten to the final model. This is applied by dipping an old, short-bristled brush into the paint and shaking off the excess (a bit like when preparing a brush for dry-brushing, except keeping a little of the wet paint in the bristles). Then use a finger to pull the bristles back and flick a few drops of wet red paint onto the miniature from a distance of about three or four inches.

New Year, new scale, new games, new painting

Just before Xmas we received a parcel of PCBs from a manufacturer in China. What with real life and Christmas and New Year, we've not really had much chance to do anything with them, other than test the functionality a few. But with a New Year comes another raft of resolutions - and one of ours is to get some games finished!

Here's how we can fit six boards together to make a football sized/shaped board game, perfect for a fantasy football game

Laying them out slightly differently and we get a more "square" shaped board, perfect for small scale skirmish games

As well as our fantasy football game, we're planning a zombie co-op game. This is pretty daunting though, just because of the number of miniatures we'll need! There's barely time to paint up a football team, and finishing our Space Marines seemed to take ages, so the thought of having to paint up 30 or 40 zombies, as well as character "heroes" is pretty overwhelming.

During 2014 we noticed 15mm becoming a popular scale for tabletop gaming; it's only really when you've decided to give the scale a go and come to actually buy miniatures that the reason why becomes clear:

We decided on 15mm for our zombie skirmish game, really just as a way of proving that our electronic board game would be suitable for scales other than 28mm. But it also provides a cheap way of amassing zombie hordes (£4 for 8 zombies, a fiver for 12 compared to almost four quid per individual miniature at 28mm makes it  a substantially cheaper scale to collect!). Smaller miniatures mean we can also fit a larger map onto a smaller playing surface - ideal for playing a game set in a modern town with lots of buildings and streets.

And smaller scale miniatures also mean quicker painting times (in theory) so we decided to try a couple of different approaches. In almost all painting guides for 15mm, the general consensus is to start with a black undercoat. It's noted also that painting schemes for 15mm tend to be very "high contrast" - the creases and crevasses on the miniatures are almost always black, with brighter colours used in place of highlights (because of the much smaller surface area available to paint).

We started with some 15mm "army solider" miniatures we had hanging around - compatible with games like Flames of War - and began by gluing a 3mm magnet onto the base of each. Although not normally associated with zombie-based games, they're the first 15mm minis we had to hand, and they can always come in useful for other games - as well as for imposing martial law during the early days of a zombie outbreak!

 (Shown in the photo are some 15mm characters that have been cut off their bases, with a view to mounting on clear acrylic bases. In the end we gave up on this approach - cutting the miniatures off is a very time consuming process, the miniatures are easily damaged during this process, and the surface area of the feet for attaching to the clear bases is tiny)

Centring the magnet can be tricky while the glue is wet. It's important to use something non-metallic to push the magnet into the centre. Try to use your fingers, and you'll just end up with magnet and miniature super-glued to your skin!

With the magnets mounted, it was relatively easy to place these on a metal tray and spray paint them with Army Painter black primer. The magnets lifted the entire base off the tray a tiny amount, allowing the paint to get all around (and under) the bases as well as the model.

(although the flash on the camera makes these minis look grey, they're actually a dark, matt black)

Our first attempt at 15mm painting was to block colour, leaving areas of black between the plain-coloured panels. This gave a pleasing result, but we felt that a lot of detail was being missed. And the painting method was almost as slow as for painting 28mm, with the constant correcting and touching-up areas where the brush slipped and dotted paint in the wrong places!

Although the result was quite pleasing (in a super-bright, cartoon-y like way that we're quite fond of) the process was simply too fiddly to use for a zombie horde; we needed a quicker, easier method of bulk-painting, not just repeating our current method but on a much smaller scale.

Another method we'd seen was to dry-brush the black miniature with white, then use thin paints, almost like a glaze, to add colour over the highlighted parts of the model.

This method actually worked quite well at the start. But as we got beyond basic block colours, and applying highlighted edges, we found the thinned down paint difficult to control and suffered lots of paint overlap. And that the miniscule bits of white still occasionally left showing gave the miniature a slightly "dusty" look - although the miniature did manage to keep a bit of the "realism" of the sculpting.

Our final approach is more akin to combination of our method of painting for 28mm, with Army Painter Quickshade, and this second method. Firstly, we undercoated the miniature in black, then drybrushed with a mid grey - this is not to provide a base for the top coat, as with the white-and-glaze approach, but to simply point out where the details are on the model (with the camera flash, the photos seem to show a lot of detail, but it is difficult to pick them out an entirely black model when painting).

We then painted the tiny areas on the miniature, using plain block colours - taking care to leave areas of black still showing, in the deepest recesses of the model.

Then we added a wash of Army Painter (water-based) Strong Tone. This is the A/P version of GW's Nuln Oil apparently - either would suffice; because speed is of the essence here, we used the water-based ink, rather than the original Strong Tone in a tin (which requires a 24 hour drying time and then Dullcote to remove the shine - all adding to the time taken to get a miniature finished).

Strong tone darkens down all of the colours - the water-based version more-so than the varnish-in-a-tin - but enables a surprising amount of detail to still show through. So we picked up  the original colours and repainted them over the ink-washed model, using them almost like an edge highlight, leaving lots of the underlying, darker shades showing.

Although the camera flash has de-saturated the colours in the photo, the miniature retains the detail, while appearing quite colourful, using this hybrid approach. It's not as quick as painting using glazes over white (a technique we just couldn't master) but is much quicker than using our "traditional" approach as for 28mm models.

If we get some time over the coming weekend, perhaps we'll be able to paint a batch of 10 or so soldiers, and time how long they take, as we did for our Space Marines. At least then, we'll have an idea of how long to set aside for painting a zombie horde of 30 or 40 miniatures!

PCBs arrived from China

It's taken a few weeks for them to finally get here, and it's been a nerve-wracking couple of weeks, since the factory were unable to validate that they were sending the correct serial data out of the "data" pin, but today a large box arrived via DHL.

With over £600-worth of circuit boards, still untested fully (the factory confirmed that the hall sensors were going from high-to-low but hadn't been able to demonstrate them working with the test software I emailed over) it was with some trepidation we peeked inside.
Until the boards were actually hooked up and failed, there was still the chance that we hadn't just exchanged a load of cash for a boxful of expensive book covers!

"Sophia" from the factory remained supremely confident, and emailed to say she'd stuck a little something into the box...

We're still not exactly sure how a free bluetooth headset should instill more confidence. But it was a nice touch anyway. A visual inspection of the boards was pretty encouraging - everything looked to be in order, each pair of boards were packed individually in their own anti-static bags, and well supported in the carton with plenty of polystyrene.

All that remained was to actually test the boards!
Since alignment of the connectors is absolutely critical, these have been left off- we'll solder our three-pin connectors on them here (we're not actually decided on the final design, so far it's looking like 0.1" pitch pin header type square sockets) using a jig to ensure that every connector is in exactly the right place (even a millimetre or two of deviation would cause board sections to go out of alignment and we just couldn't have that!)

So on with the testing.....
We used exactly the same test rig as for our hand-soldered and homebrew made boards.

100% success rate! Phew. That was a real relief.
We've now got enough boards to make up either 10 individual football pitches.... or one enormous, massive skirmish battlefield!

Enhanced wifi controller for digital board game

Our digital board game idea depends heavily on a wi-fi based module, to transfer data from the game board to the tablet/smartphone/PC that is hosting the app running the game rules. We've spent a lot of time investigating lots of different methods of getting data from the board into some kind of controller, including

• USB (suitable really only for PCs)
• Serial (suitable for PCs and some Android tablets)
• RF devices (a bit buggy and susceptible to noise)
• Audio (works with all tablets, even crazy Apple iDevices)
• Ethernet (works with everything but requires lots of wires)

Eventually, and thanks to the super-cheap ESP8266 modules that recently flooded onto the market, we went with wifi (prior to the ESP8266 we'd given up on wifi as too expensive, using either WiFly or HLK-RM04 modules).

Now there are a number of convoluted ways of getting your SSID and password into the wifi module (including setting it up as an access point, connecting your phone to it, running an app, entering the SSID/password combination then closing the app, disconnecting the phone from the AP, rebooting the wifi module in "client" mode, reconnecting your phone to your home router and starting another app, then using UDP broadcasts to find out the ip address of the wifi module) but in the end we went with something a little simpler - a screen and a rotary dial to "type in" your SSID and password into the wifi module (it retains this information during power cycles, so shouldn't need to be done too often).

Now that's been working fine for a while now, and we're at the point where we're able to share a few videos with people to gauge the level of interest for an electronically enhanced board game platform. Mostly, people have been really excited by it. But there have been maybe one or two people who didn't quite understand that the idea is to speed up tabletop gaming, by having the smart device do all the dice rolling and conflict resolution for you - they wanted to be able to roll dice and somehow enter the results into the game.

At first, we just dismissed this idea as the rambilngs of a few RGP-obsessed lunatics. But over time, we just got to thinking - well, why not? So we've added a bit of extra code to our wifi module, to allow the user to select a dice roll result, using the rotary dial and push button.

The first thing to do was draw some 1-bit bitmaps of dice. This wasn't as easy as we'd hoped (grab some images off Google, resize, reduce colour depth) and we ended up drawing each dice shape, pixel by pixel.

Of the two types, we preferred the "inverted" dice (though the "white" dice also look pretty nice, we may yet use those!) so squashed them up together (to remove any unnecessary blank pixels, to keep our RAM usage down to a minimum) then ran a simple VB script to create one big array of bitmap data.

Here's a video of it in action:

While we've provided a method for players to roll dice and enter their results into the app, it's a little bit cumbersome and not very satisfactory - stopping the game to interact with technology, to then return back to the board game, breaks up the feeling of playing a tabletop game: rolling dice and placing them over some kind of "reader" which could then automatically extract the dice result from the actual dice face would be a far more "fluid" way of playing the game. It's just a shame that we can't do that just yet!

[blog post edit: Oh yes we can - http://nerdclub-uk.blogspot.co.uk/2014/12/dice-reading-photo-image-processing.html ]