First of all, it was great to see the interest this project has generated. Thank you everyone!
It’s a humbling and very motivating experience, seeing people’s reactions, reading through the feedback, both praising and suggesting changes, makes me want to create more things 😉
This project has been featured on a number of websites:
Updates to the project
Few additions have been made during last week:
- New game: Connect 4
- New game: Tic Tac Toe
- Further code optimizations, that cut the memory footprint almost in half!
Both new games can be played with a single magnetic piece – this piece is then used to touch the cell where each player wants to make a move.
Since cells are color coded per player, new cells can be taken over by players without losing any existing cells (i.e. players are always adding cells, instead of moving pieces on the board), and those 2 games have only single piece type (which is different than Checkers, Chess, etc.) there is no need to keep physical game pieces on the board throughout.
This allows for a quicker and easier cleanup/setup for the next game.
12 thoughts on “Smart Game Board – Updates”
hyee, your project is so cool! i wanted to make an electronic chess for my final project, but i do not know on how to make a direction for every pieces on the board. if u dont mind, may i know how u make it and the coding for the direction guide of the pieces.
I’ll try to explain some concepts, but please feel free to ask if anything isn’t clear 🙂
First thing to keep in mind, while using this approach for detecting the pieces on the board (magnet on the piece, hall effect sensor in the board) is: the pieces are indistinguishable. Each piece has same magnets, so technically we won’t be able to detect which piece is where in code, as we don’t have a way of determining that. This is very important as it determines the game logic altogether.
What we know is the starting state. We know which pieces are supposed to be placed at which cells. Thus we make assumption that once all the cells required to begin a game are occupied, the pieces on them are correct.
From here we track the change of the board state: if a piece is lifted from cell (x1, y1) , we know which piece type was there before, thus when we see a piece being added to a cell (x2, y2) next, we assume that it’s the piece that has been lifted from (x1, y1).
This has obvious limitations (i.e. if we lift 2 pieces off the board, and then add 1 back, we wouldn’t know which of those 2 pieces was put back, or even if it was totally different piece altogether). But this limitation isn’t preventing us from implementing chess, or checkers, or many other games.
Interesting case here is, what if player lifts (removes) a piece that has been “beaten” by the opposite player? Well, we know that this piece has been lost, thus when it’s removed from the board, we know it won’t come back.
And to answer second part of your question: how do we know which pieces can move where? Well, we implement that part, knowing the rules of the game 🙂 And then just check what’s the piece type and get the moves for it. The implementation may be as simple as a list of 2D points, which contain coordinates relative to the current piece position. Example: if the list of possible moves contains point (1, 1) then we know that the piece can be moved to cell 1 up and 1 to the right from current position.
Interesting things to consider: we can implement the set of moves per piece type just once, and then check which player the piece belongs to, and modify the set appropriately (i.e. reverse Y to allow moves in the opposite direction – this is clearly visible in case of Checkers).
There’s more to that, just the game state tracking has some interesting cases to consider (i.e. for each game piece, we need to know the type, player, if it’s been lost and should be removed, etc.), but I hope this should clarify few matters.
Hope that helps! Please let me know if you have any additional questions.
And good luck! 🙂
ohhh thank you for the explanation. does it means that i have to declare every pieces for every cell? and is it suitable if i use “for loop” coding in arduino for this part ? if u dont mind, can i have your coding for this part as my reference as it would give me a clear understanding. 🙂
Sorry for the late reply 🙂 To answer your question – yes, you need to store the state of each cell, with the type of the game piece (pawn, king, etc.) being one of the variables.
The “for loop” is perfectly appropriate to iterate through the cells (it’s one of the basic constructs of most languages, and of course fully supported on Arduino 🙂 ).
I’ll go ahead and send the code to your e-mail, I hope you’ll find it useful! 🙂
Hello,I’ve read your explanation.Thank you do much for that.May I ask for the coding as reference so I could understand better?
I sent the sources to your e-mail.
Hope that helps! Let me know if you have any questions.
I love your project. Could You send me the code?
I would be grateful.
Hi Nicolò, I sent the sources to your e-mail. Let me know if you have any questions, or something is unclear 🙂
You can send me the coding as reference ? I see the explanation, but i keep questions that can be solved by the coding, thanks
Hi Jônatas, I sent the sources to your e-mail. I should clean it up and put on github, but I’m always finding myself busy with things… Hopefully one day! 🙂
Could I see how you’ve implemented the tracking in the board please. Thanks
Hi Anne! I e-mailed you the source code. The idea for tracking is simple – we know the starting state of the board (which piece is where), we track which piece is then lifted, and where on the board a new piece appears (this is the one that is being moved) – based on that we update the states. It does have limitations, since we only know if a cell on the board is occupied or not, if player were to remove all the pieces and then put them back in different order, we wouldn’t know that.