The robotic game board came together over the span of about 6 years. On this page I will give some details on the progress throughout the years, some of the design choices, and some of the setbacks. Most of what is on this page is from memory. While I took decent photo’s I remember very little. It did turn into a bit of a long story, but I did not want to spread it over several pages. I included a lot of pictures to compensate.
Downloads
I put the downloads at the top for people interested. It comes with a disclaimer.
Be warned, that this project is a big and complicated one. It is definitely not for beginners. I have tried to include all files required to make this board and make it work, but the project span was so big I am not sure if I have found everything you will need. I will not make a tutorial on how to make it, so expect to design and fix stuff yourself. The 3D files include a step file and a 3D PDF of each assembly, but drawings for the wood and metal parts will have to be derived from the STEP files. I do answer questions when needed, but don’t rely on me helping you making it work. I am not responsible for this project working for you. With the disclaimer out of the way, the files:
The first try
In 2018 I started on this project with the belief that it was a complicated but doable project. The early phase was mostly about building a working board, thinking that all other things are simply a good amount of coding to make it work.
Basic requirements
The basic requirements for the robotic board game were:
- Make a board that can automatically play a game similar to Roborally;
- The style for this game should be steampunk (I did not simply want to copy Roborally and like steampunk)
- The player should only have to play the cards, the board will take care of the rest;
- The player plays physical cards. An app or a webpage is not nearly as cool, and I lack the skill to do that anyway;
- The Roborally options cards are NOT included in this game;
- Up to 8 players should be able to play the game;
- The game should be somewhat affordable to build;
- The robots should appear to move on their own. Overhead tools moving the bots was not preferred;
- The robots need to be controlled both in position and rotation. Each bot has a facing, which is important to the game;
- Multiple maps should be possible to play on the board;
- At least a full minimum Roborally playing field (board and starting tile), of 12×16 should be playable on this board;
- The game should run standalone. At the time I sucked at software, but was decent at firmware, so the game should run on a microcontroller;
- Stepper motor control should ideally be done by something else than my code;
How it moves the robots
The robots need to be moved without the players being able to see the mechanism, and with swappable playing fields. Early on it was clear that magnets were the answer. By having 2 magnets in each robot, one north side up and one south side up, I would be able to pick up a robot from underneath with a similar magnet arrangement. By moving the magnets under the board, I could move the pieces.
Several things have been tried. Electromagnets were too weak and heated up too much. Neodymium magnets were strong enough to not only move the bots, but also rotate them. To grip the robot, the head with the magnets goes moves up towards the robot. To let go of the robot, the gripper simply moves down so the magnets no longer affect each other.
Fancy arrays of magnets were attempted and square magnets to improve the force. In the end two 3x6mm round neodymium magnets were used in both the gripper and robot. To create low friction 4mm PTFE tubes are placed under each bot as a sliding surface.
The small size and spacing of the magnets in each piece is so that robots are not attracted to each other. This small spacing does mean that the gripper needs to get quite close to the robot, so only a thin sheet of non-magnetic material is allowed to be in between the gripper and the robot. In my case this was a piece of glass 30x40cm from a picture frame.
The head
The head connects to the gantry and is moved using timing belts. Two functions are on the head. The servo motor that moves the magnets up and down, and a DC motor with potmeter feedback to twist the magnets. The DC motor and potmeter was because I needed 360 degrees of movement, and I thought this would be more compact. Whether this was better than a servo motor with a gear ratio to get it to 360 degrees is up for debate.
The gantry
The gantry of the boardgame is a coreXY system. It has both motors stationary. This arrangement was decided on to speed up the board and only have cables stationary and on the head. The endstops were located one on the head, and one close to the motors.
The moving part of the gantry has aluminium rods and plain bearings to save weight. The rods on the static side are steel with ball bushings because it is stronger. Ball bearings are used as idlers for the timing belts.
The base frame
The base frame was made with 9mm plywood and 3D printed parts. The corners are printed to give them a nice rounded edge. The lid can be removed with 2 screws. Also in the frame is a power connector. Inside the frame are several holes for the power connectors and lid mounting. The motors stick through the bottom to save space.
Finishing the board
To finish the board, it was disassembled and the wood was stained. Brass strips and 3D prints were used to mount the glass to the board. Also at this stage the connectors on the side for the cardreaders were mounted. In the photo’s are the old connectors, one for each cardreader.
The electronics
Inside the board, on the side of the motors the electronics were mounted. The controller that is in charge of the motion control is an Arduino Uno with a CNC shield, running a version of GRBL that can handle coreXY. Next tot the Arduino Uno is an Arduino Mega that handles the control of the magnetic head, as well as the cardreaders. The Arduino Mega talks to the Uno using a serial line to control the motion.
I also crammed analog multiplexers, motor drivers and voltage regulators in this space. I tried to fit everything required to make the game work in this space. This did get cramped very quickly, since the gap for all the electronics was only about 5cm wide.
The cardreaders
The cardreaders were the most experimental part of this project. A test setup was made to read the cards. Each game card would get a barcode containing the value of the card. This code would be encoded in a pharmacode, since this type of barcode has nice thick bars and is easy to decode.
A moving head would move past all the cards to read the barcode. On the head was an IR led and a phototransistor, looking through a slit mask to read the barcode. When the head moves past the cards, it showed a nice graph with peaks and valleys corresponding with the bars. A graph is included in the photos.
With the test out of the way, a cardreader was made to test. This cardreader has 5 spots for cards, a set of rails for a moving head, leds for life and damage, and an arm to read the player input on when to read the cards or power down. By design the cardreader is pretty dumb. It has a 10 pin connector to the board, but the cardreader itself has no intelligence, the board is handling all the control of the cardreaders.
The basics of the code
The goal was to make the Arduino Mega handle the entire game. It handles the cardreader movement and input, and move the magnetic head. The Arduino also handled the robot position for each robot, and all the game rules.
The controller hold the map in memory. Whenever a bot needs to move, all game rules are checked to see what else needs to move as well. There is also a phase where the board moves the bots, based on belts and spinners. The board keeps track of the life of each player, and the cards to be played.
An important feature is pathfinding. Under normal circumstances the players move with the board game rules, and bots simply push each other. However, when a bot dies, it needs to be moved to the parking row to get it out of the way. Here the bot can ignore game elements like walls and pits, but it does need to navigate around other bots. A* pathfinding was included into the controller to see if a bot could be moved to a parking row. If not, the board would move all the players in the way to the parking row temporarily as well.
I will spare the details since 90% of the code was ditched later. Only the part that talks to the Arduino Uno with the CNC shield and the part that moves the magnetic head have remained. All other functions have either moved to the hub or the software.
How this project stalled
Late 2018 this project stalled, mostly due to the cardreaders. The DIY barcode scanner seemed sensible, but while the graph showed the barcode perfectly, the microcontroller only got to 90% reliability, too little to be playable. I tried for a long time to improve reliability, but in the end I never managed to fix it. My choice to make a cheap cardreader made a cardreader that hardly worked.
A secondary issue is the Arduino Mega running the game. It is big for an Arduino, but still lacks the RAM and the memory to really make it work easily. Running A* pathfinding with too little memory available to even store the entire grid complicated an already complex piece of code. The Arduino Mega was too slow, had too little memory, and had to do too much.
Debugging the code while the bots and the board are not physically visible was also a challenge that was bigger than expected. Everything had to be tested mostly blind.
Last, and this was the final straw, I moved house during all of this. Having a stalled project, and a months long distraction was enough to stall the project to beyond a point where I was able to pick it up again.
The second try
The project had been mostly dead for years at this point. However, colleagues knew about this project, and a particular one kept pestering me about this project. I did want to continue with it, but lack of time and other projects (mostly HP45) kept me from working on it. In late 2022 I started again on the project. 2 things needed to change.
New cardreaders
The first were the cardreaders. The “as cheap as possible” requirement was dropped and replaced for “find something that works”. The part I ultimately chose was the Waveshare 1D/2D barcode scanner module. They cost around €40 each, so they are far from cheap, but at this point I just wanted to make this work.
The new codes would be a DataMatrix code, which holds the entire function of the card in text. A quick test setup confirmed that the concept worked well. A new cardreader was designed that uses this barcode scanner. The barcode scanner head does need to be removed from the main board to make it fit in the scanner head.
The cardreaders head has two switches. One is the home position, as far left as possible. The second touches cams behind each card. This is how the read head knows that it is in front of a card and can read.
New software
The second was the project architecture. The original project was designed to run on an Arduino Mega. This caused a debugging nightmare. In the meantime I had learned enough Python that I felt I could do write this code in that. The new architecture would be that the computer completely plays the game. It receives the cardreaders through the board, but the computer plays the game. The board simply mirrors the movement of the software. This meant that I could test all the code away from the board, and then simply link the board later.
I spent a good part of late 2022 and 2023 working on this project. I made a better cardreader, tested that to work, wrote the entire foundation of the software, with the part that renders the board and the robots, and the part that enacts all the rules. However, another round of home improvements stalled the project again.
Third times the charm
The second hiatus lasted until early 2024, less than a year, and now that I finally had a good foundation I wanted to “finish” this project by April 2024, where “finish” meant being able to play the game without too many bugs.
A lot of tasks for this project started running all at the same time.
More software
The software was continuously improved to add features and remove bugs. A non-comprehensive list is:
- The menu was split into three tabs to make space for more buttons
- Functions for the serial connection to the board were added
- The loop that actually plays the game was added
- Debugging options for playing cards without the cardreaders were added
- The cardreaders were slowly implemented
- Debugging buttons were added for every function that I might want to control
- Selection of the desired board got possible
- Functions to manually place the targets and bots on the field got added
- All game rules that should be configurable got their own buttons
- When with play testing new problems were found with the limitations of this game, functions were added to change the behavior of the game.
- Gaining health became easier
- Touching the flag got slightly more complicated
- Parking row got virtual walls surrounding them
New board electronics
At some point it became time to link the software to the board. For this I use the serial linking code I have written for the HP45 controller project. I have copied it so directly that there is still references to inkjet in the code. However, when I started testing the link to the board, I got mysterious errors. Random numbers and characters started to go missing in the communication from the software to the board. I did try and find it, but to no avail.
The troubles with the software not linking were at some point so bad, that I considered starting over with the code, and going back to running the entire game in firmware. I am glad I didn’t, because that might have killed the project again.
The solution was to remove the Arduino Mega, and replace it with a Teensy, the microcontroller for which the serial linking code was written. The microcontroller chosen was a Teensy 3.2. It is 5V tolerant, and is from a generation I know to be compatible with my code. It is also no longer available, so for anyone replicating this project, you are going to have to change that. The Teensy 3.2 has one issue, and that is that it does not have enough pins to control the cardreaders as well.
Hubs
The solution to the board not being able to control the cardreaders was to add hubs. Each hub has a microcontroller and the hardware to control up to 4 cardreaders. The hub itself also has a few leds and a button, so I can add a timer later if I feel like it. The microcontroller on the hub is a Teensy 4.1. I do enjoy the fact that each hub’s microcontroller is 10x more powerful than the main board controller, but the less powerful Teensies did not survive the chip shortage.
Each of the hubs are connected to the board with a 5 pin connector and talks to the board with a serial line. Each hub is designed to be hot-swappable, and each cardreader plugged into the hub is also hot-swappable. The board knows a hub is being plugged in through a sense pin in the 5 pin connector, and each hub knows a cardreader is being plugged in by looking at the potmeter pin that is used to read the arm.
New new cardreaders
A final revision of the cardreaders was designed. This revision was more about ease of manufacture than it was about new functions. During the project, more cardreaders were built, I only built 6 cardreaders, since finding 8 players at once seems unlikely, and each cardreader still takes quite a lot of time and money to make.
Another addition was clear light covers on the cardreaders. I only have FDM printers, but a colleague of mine has a DLP printer, and I could convince him to print the parts for me in clear resin. The light covers were cleaned up, masked, and painted brass color with an airbrush. Then extra details were added with a brush.
Special thanks to Sebastien Ritsma for the printing of all the clear parts.
The new covers were actually so clear that a separate diffuser was added to even the light. This was a white FDM printed cover printed in vaze mode to make it thin enough to be translucent.
Inside the base the wires come together. A 10 wire cable enters the cardreader with all the control wires and 5V power. Here it gets split to all the functions. Then from the base to the read head, another 10 wire ribboncable is used to connect directly to all functions on the head, the 2 endstops, the motor and the cardreader. All the wires were sleeved in a black sleeve to hide them. The ribboncable to the cardreader was split to the individual wires to make it more flexible, the wire to the readhead was kept as a ribboncable
A set of test cards was printed to play the game until I got something better. These cards were laminated with matte plastic and cut to size. The human readable portion is at the top, a datamatrix code with the computer readable part is at the bottom of the card.
Final architecture
The final hierarchy is as follows. The software runs on a computer or laptop. It can be played through the debug menu, but for real games it needs the input from the cardreaders through the board. The software talks to the board through serial using a USB connection.
The board is controlled with a Teensy 3.2. This microcontroller directly controls the gantry magnet head movement, up, down, left and right. The Teensy 3.2 also has a serial connection with an Arduino Uno running GRBL. This Uno is responsible for moving the gantry head in X and Y. The Teensy 3.2 also has 2 serial connections to the 2 hubs.
Each hub uses a Teensy 4.1 and has all the hardware to control 4 cardreaders. The hub has the connectors for each hub, motor drivers, shift registers to get enough inputs, and a few leds and a button.
Each of the cardreaders has a potmeter, an addressable led strip, a motor, two limit switches and a barcode scanner that talks to the hub using serial. This is directly wired with a 10 pin connector to the hub.
That means that on a board with 6 cardreaders, a total of 10 serial lines are active at the same time.
Card design
The final cards were designed and rendered in Solidworks. I wanted something that looked like a steampunk device, and something that had nixie tubes and gauges. The dimensions of the cards are 44x68mm, which is a fairly standard (small) size for a card. This size mostly comes down to the cardreaders, which were already quite big with cards this small.
Below is the 3D view, and the renders of some of the fronts and the backs of the cards. The nixie tube tells the instruction and the amount. This can be forward, back, turn left and right, and for the experimental cards, laser and strave. The available numbers are 1-3. Below the nixie is a space for a number, and a dial. The dial moves in one of nine positions, roughly corresponding with the height of the priority. The three white spaces are for the 3 numbers of the priority, which are added later. The white square at the bottom is for a datamatrix code that holds the information of this card.
The back is designed to be some tanks and a heater. It also has a steam whistle. The pipes don’t attach, I don’t know what the thing is supposed to do, but I like the way it looks. If I were a better designer I might have designed something calmer, but I like the way it turned out. An added benefit is that reading the card through the backside is difficult with this busy of a design, where as the test cards were easily readable through the back.
The cards are printed on A4 sheets of paper. Each sheet holds 16 cards, and a standard game has 5 sheets, or 80 cards. Another sheet with experimental cards is included as well. The sheets are designed in Gimp. Here the cutting lines, numbers, datamatrix code and cover line are added as well. These sheets are printed double sided in the highest color resolution possible, all sheets with bad alignment discarded, good sheets are laminated with 75 micron matte plastic, cut into rectangles using the cutting lines, and the corners cut with a special punch at a 7mm radius.
Game board design
For the board I had a friend of mine design a tileset. Special thanks to Govert Combée (https://glopoly.eu/) for his amazing help with the clanks and the tileset for this game. Govert is most familiar with Blender, so the tileset was designed in Blender. Sadly due to the use of certain models, I can only share the tileset, but not the source files.
The current tileset includes the floor, belts, rotators, walls, pits, repair points, lasers, pushers, the starting positions for each player and the parking position. More tiles might be possible in the future, but this is the set of tiles at the moment.
The tileset is used in a program called Tiled. This is a perfect tool to design a map with a tileset. Designing a new map is easy, and the output of this program is directly loaded into my software, no conversions required. Tiled also outputs a PNG image of the map, which then can be loaded into GIMP to add a border and do some corrections.
With these tilesets several game boards were designed. I have made some designs of my own, and some designs based on Roborally. Each design is printed on A3 paper (one map on each side), which was then laminated to protect the print from the game pieces. A3 laminating machines are available, but they are sold at a premium. Each field was then cut to size, and the corners clipped to round them.
I do share my own designs, but not the ones based on the original game. However, you have the tileset, Tiled is free (though consider donating) and sites exist that keep a record of every Roborally map that are perfect for reference, such as this one. Do keep in mind that the original Roborally has a lot of expansions, and I have not implemented most of the exotic tiles. A board requires the parking row at the bottom, and one (and only one) starting position for each player. Everything else is up to your own imagination.
Element design
The same Govert that did the excellent tileset also designed 5 of the clanks in Blender. Another Clank was designed by me to make the even 6. I first printed them with FDM, but this gave a challenge to tell which side the pieces were facing. I eventually relented and had the parts printed in resin. Al the clanks were then painted in the player colors. The clanks have the magnets and PTFE tubes in the base to move them.
The flags were printed with resin and FDM. This design was made in Solidworks. The tiny cranes stand on stilts so that the game pieces can drive under them without colliding. The pieces were painted, and the flags were colored in to make them visible.
As time of writing there are no more game pieces, though there are plans for more game elements in the future.
Carry crate
With all the cardreaders, the board, the hubs and all the game elements, there is now quite a lot of stuff I have to take with me to play this game. For this I built a crate and special containers for all the elements. There is a crate for the board, a crate for 4 cardreaders, a hub and all the elements, and a final crate for 2 more cardreaders and a hub. I won’t share a design file, since the design I made sort of sucks. The final dimensions of the crates are 52x61cm, with a height around 18cm.
The containers for the bots, the flags and the cards were based on a 3D printable uno crate that I saw online. I did redesign the crates myself since I also needed to design the inserts, and wanted to change some things. The design files for the containers are included in the download files. The container for the bots have 3x3mm magnets in them to hold the robots by the magnets. The container for the cards simply has an insert that holds the cards. The container for the flags has an insert that hold the flags precisely, in one possible orientation. It is a bit challenging to get the flags in, but does hold 2 in a compact space.
I did feel fancy and painted the outside of the crates, with accents to differentiate them. The first of the big crates holds the board and maps. The second of the big crates holds four cardreaders, a hub, the cards, game pieces and all power cables. The two big crates are stained wood. The smaller crate holds two more cardreaders and a hub, and is painted white.
Final thoughs
This project has been one of the most complex things I have ever done. The number of interacting pieces, the scale, how polished everything was. I have never done something quite like it. However, there is plenty of room for improvement and things that I might have done different if I would start over.
A good thing, the board has worked surprisingly well, including the GRBL side. The board as I use it now is basically the board as I made it 6 years ago. I have changed the microcontroller, and changed the wiring to the cardreaders, but the core mechanics and function is still original.
The cardreaders, the bane of this project now work amazing. I dislike the price of them, and how laborious they still are to make, but they provide an amazing interface to this game. I like that I managed to hide all electronics in the cardreaders.
I love the steampunk style that I pulled of. The board, the cardreaders, the gameboards and cards, everything looks like it belongs together.
For the bad points, I am not going to lie, the software sort of sucks. I know enough Python to write this mess, but not enough to write it well. Things that definitely should be objects are not, things that definitely should NOT be objects are, this whole project had a complete lack of planning, leaving me to constantly add variables and functions that should run fairly deep. The code is pure spaghetti, and I am amazed that it even works. Don’t get me wrong, I am incredibly proud of how it works, but not at how it is made.
Future improvements
There are still some things left I want to do, but wont for a while.
Still needed is ways for the game to communicate with the players without looking at the computer. Right now the players do not know what card is playing, if the board is moving, and when they need to play the next cards. The leds on the cardreaders still need some animations to clear things up. There is also an idea to add an extra game piece on the board, and some tiles, that is moved each card, and when the cards can be dealt again. All of these are fun ideas for the future.
I do want to keep adding some features. I want a deathmatch and capture the flag game mode. Adding teams is a great addition with these game modes, with or without friendly fire. The original game has interesting tiles like ledges, that I would love to add. Given that the code is not that clean anymore, this is not going to be simple, but I can still read the code, so I want to try. A timer for the players to play their cards is also on the list.
There are some cards I want to try and make. Some of these are simple, such as strave, move back 2 and pause and/or shoot laser. Others are more complex. Ideas are jump cards, that allow you to jump spaces while ignoring other obstacles, and lasers that push or twist other robots. The latter might actually fix one of the annoying problems with the original game, which is that when a player gets ahead too much, it becomes difficult for other players to catch up, especially if these players are also fighting each other.
I am still considering adding the options cards. The keyword here is “considering”. The options are weird cards that add an extra dimension by allowing robots to break the rules. The issue is that each options card is basically an exception to the entire code I have written so far. Also, the options cards often need extra inputs like turns, or direction, so I would have to make a massive modification to the cardreaders. The options cards are on the pile of additions that I might do if I do keep playing this game in the future.
I do want a break from this project for a while. I cannot promise if I will add any of the fixes and features, or if I will ever continue with this project. I do like where I have gotten, and will definitely pick it up again if I will continue playing this game.
License
The project described on this page is licensed under the Creative commons – Attribution – ShareAlike license.