WiFiQuest

 Here's our first attempt at a 4x4 light-up panel. The idea here is to connect all the 5v and ground pins on the panel together, using copper tape, and create a daisy-chain effect from one strip of LEDs to the next By cutting away at the circuit board, where the 5v and ground pins are, we could create a continuous connection by adding a simple blob of solder from pin to copper strip. Needless to say, it didn't work! But that's probably a good thing - because when it didn't work, it forced us to abandon the idea of using copper tape for the LEDs (connecting each to the next using wires at the end of each strip) which allows us to use the same surface for running copper tape for our hall sensor input array. Our second design was much more successful. It may be easier to think of this as two panels, overlayed into one space. Firstly, there's the LED strip, chopped into bits, and connected up again, into a "snake-like" layout Then underneath this, we have our ...

 So far, we've focused on creating an "input device" for tracking pieces moving around a playing surface. One of the things we really wanted to focus on - and have refused to budge on, over ten years of development - is that the "augmented board" really shouldn't get in the way of the game. We don't want the board to just  be an input device for playing a video game. The idea has always been to keep the action on the board, not on the screen. We even spent some time investigating having a blank screen app, and game action prompts being audio-only. But that made things difficult when trying to explain "you need you place something here on this square" and a tabletop game skirmish game could quickly begin to feel like a chess board, with instructions like "place something on square A4". Having to stop the flow of the game, for someone to count out rows and columns on an (imaginary) grid over an irregular playing surface, in order to pla...

 The idea of losing the data wire, and requiring only power and ground to make our board sections work feels almost revolutionary! Suddenly, we could have board sections on top of buildings (for large, open area wargame type scenarios). But reducing our connectors down to just two pins (instead of three) also means a slight problem - because a two-pin connector isn't symmetrical. And, as we've already discussed, having boards with just two pins can mean all kinds of problems if someone were to rotate the board around, and try to connect incompatible pins together And the answer was as simple as it was obvious. Simply stop trying to make the board panels symmetrical! Don't allow people to rotate the boards to connect them together! In fact, making the board panels in such a way that they could be  rotated only means additional complexity in working out where each square on the board is, in physical space. As the board piece rotates, the physical location in space of our 0,0 ...

 Suddenly, the idea of having wifi modules that can automagically connect to a home network seems like a great idea for a multi-part board gaming surface. Instead of having a single, master controller that all the hardware eventually connects to, then using that as a bridge to the app running on a phone/tablet, we can just have the app and the board game pieces talk to each other seamlessly over wifi. And the best thing? One less wire. There'd be no need for a data wire or even for all the board pieces to be physically connected to each other. You could have one over here, one over there, one somewhere else.... So long as there was a consistent means of getting power to the devices, each one could effectively be a stand-alone unit. We could even put a rechargeable battery in each board section - just switch them on, throw them down onto the table, and you're ready to play! Of course, having multiple board sections for a nice large playing area (such as a HeroQuest dungeon or a ...

 These little ESP8266 NodeMCU modules are great little things. You can get them to boot up, connect to a router and then immediately start broadcasting their presence over UDP. What's the point in that? Well, the idea is that we would have our app listening on a UDP port, and when an incoming message is received from a new device just booting up, the server could "shout back" at it. When the NodeMCU client hears the server shouting back at it, the client will have the server's IP address. At this point, the client could STFU and try to make a TCP connection to the server (to ensure connection stability). If any of the UDP packets don't get through, there's no problem. The client keeps shouting until it's heard back from the server. If the server misses the client's UDP packet, nothing happens - the client shouts again a few seconds later. If the server hears the client and shouts back, but that  packet gets lost, nothing happens; the client just shouts...

 Many long-time users of the Arduino platform are probably already familiar with the ESP8266. It started out as a wifi-to-serial module you could hook up to your Arduino and send messages over wifi to your flashing LEDs and motor controllers. Then it appeared as an integrated board, and multiple variations hit the market. A common one is the NodeMCU and it's derivatives. These are great little Arduino-compatible modules that you can set up in the Arduino IDE as programmable controllers (just like an AVR ATMEGA328 or similar microcontroller) but they have loads of other cool features (not least of all, multi-threading!) But most of us stick to using them like a beefed-up Arduino (they have loads  of RAM memory and plenty of programmable storage to run pretty sophisticated firmware on them). It was while playing with one of these for a completely unrelated project, that I suddenly hit on the idea of having a "network" of board game playing surfaces, all broadcasting over wi...