How we made a board game with a remote control - Part 2
Last time I told you about the technical component of our “smart” board game, what problems we faced and what happened in the end.
Today I want to tell in more detail about the mobile application, the first game and how they created miniatures for it.
The first article can be found here: How we did a board game with remote control - Part 1
Attention! A lot of pictures on.
In the comments to the previous article correctly noted that it is better not to make a game, but a platform on the basis of which you can already create games using the available mechanics. Initially, we planned this, but as a result, we realized that we would not be able to do something in isolation from the game. Just because of the lack of experience in game design or familiar game designers who could tell us which mechanics should be supported.
Therefore, we decided that we would implement all the basic functions of the platform (moving, dynamic lighting, hints) in our first game, which we will invent ourselves. And then, using the experience gained, we will make a full-fledged game designer.
As I wrote earlier, all platform management is carried out through a mobile application that connects to it using the BLE protocol.
In fact, to implement any game you need to write a full-fledged mobile application for it, in which you describe all the rules and mechanics.
In the process of writing the application, we performed all testing by connecting to the platform, which is not very convenient. Therefore, in order to simplify debugging, we have made a simple software emulator within the application, on which data is also displayed as they would be displayed on the playing field.
At the very beginning, we encountered the problem that the data that leaves the application is lost. Found that when using BLE, the maximum packet size that can be sent is 20 bytes. Therefore, we break all outgoing data on BLE into packets of 20 bytes, in the header of which the “Gate” parameter is written. This parameter helps Arduino to understand which particular platform component this package belongs to. On the Arduino side, processing these packets is elementary:
After we broke the streaming data between the smartphone and the BLE-module to transfer packets of 20 bytes, the data ceased to disappear, but often came to Arduino in a distorted form. It turned out that we did not take into account that the Arduino serial port has a buffer of 64 bytes. At buffer overflow the data was lost, and the subsequent were distorted. Increasing the size and creating your own buffer did not always help. I had to write a protocol wrapper over the BLE transport to reliably send and receive data.
Due to the use of such a “protocol”, data exchange was slightly slowed by checks of the integrity of the transmitted data, however, reliability is more critical for the game - it will be insulting if the AOE displaysome ability will not be complete or the hero will not be moved when confirming a move on a mobile phone.
To display objects on the playing field, we used the principle of layers in OS window subsystems:
The main volume of data transferred between the mobile application and the platform is LED repainting. For optimization purposes, a couple of algorithms have been added:
So you decided to play. Below I will describe how it looks from the outside:
This is a gameplay that works in the current version. Due to the lack of experience in game design, we may not see obvious jambs or opportunities. For example, it is always painful to wait for your next move. In the current implementation, the waiting time can reach 1.5 minutes. In the next version of the prototype, we plan to add RFID tag readers, which will allow to diversify the gameplay. For example, use cards with RFID tags that you can use outside of your turn.
Thumbnails love everything! And we are no exception. Therefore, in parallel with the collection of mechanics and programming, we were engaged in inventing our own miniatures. I think from the pictures it is clear that our game is about fantasy cats fighting in the arena.
Because we do not know how to draw from the word in general, we turned to our friend, who with great pleasure began to draw "fighting cats".
For the basis she took our own pets. So, in her house there lived a huge and angry cat named “Pirate” - it is he who is the basis of the Warrior miniature.
A couple of weeks we got our first sketches.
From the articles on the production of board games, I realized that in Russia, the creation of miniatures is bad enough and many order them in Finland or Germany.
Before we started producing miniatures, we needed to make a master model for each character, which is quite enough for a prototype. At first we wanted to make them from polymer clay, but it turned out that there were no miniaturists among our friends, and it was too expensive to make to order. Therefore, we decided that we would first print them on a 3D printer. For this, our friend made us the 3D models of our first characters in Zbrush.
With the help of FDM printing, we failed to print out figures of acceptable quality, which was quite expected.
Fortunately, my wife has SLA 3D printers at work.
Stereolithography (SLA) is a 3D printing technology that allows using a light source, layer by layer, using the photopolymerization process, to transform liquid materials into solid objects. The thickness of the layers, during printing using the SLA technology, is several times less than during printing using FDM, hence the quality of the finished product is higher.
A few days later we were given our first miniatures.
The quality of these miniatures is much higher, but still does not reach the production ones obtained by molding plastics. The blame for this is the support that, after removal, leaves noticeable traces. In theory, we could “cut” the figures into separate parts and print each one separately, without using supports, and then glue them together. But it would take a lot of time, and in the future it may still change.
Each figure stands on its base, which we also printed on a 3D printer. Inside the base is a neodymium magnet. The size and thickness of the magnet was chosen empirically so that the figure would quietly magnetise to the electromagnet on the carriage of the platform, but would not react to the neighboring figures.
At the moment we are engaged in improving the physical characteristics of the platform and the reliability of all components. We replace plywood with polycarbonate and ABS plastic, improve the mounting of the platform components to each other and make the playing field removable so that it can be changed into a different form factor field (for example, hexagonal). The next step is to create a full-fledged MVP, which is not a shame to show people.
With the game a little harder. Of course you want to fully focus on the implementation of the platform, without reference to a specific game. However, we are well aware that no one is interested in a platform without a game.
Thank you all for your criticism / advice / interest. We had an idea about creating a version without using mechanics, but with the ability to determine the position and type of the figure on the field. I think the following article will write after the creation of MVP .
Today I want to tell in more detail about the mobile application, the first game and how they created miniatures for it.
The first article can be found here: How we did a board game with remote control - Part 1
Attention! A lot of pictures on.
In the comments to the previous article correctly noted that it is better not to make a game, but a platform on the basis of which you can already create games using the available mechanics. Initially, we planned this, but as a result, we realized that we would not be able to do something in isolation from the game. Just because of the lack of experience in game design or familiar game designers who could tell us which mechanics should be supported.
Therefore, we decided that we would implement all the basic functions of the platform (moving, dynamic lighting, hints) in our first game, which we will invent ourselves. And then, using the experience gained, we will make a full-fledged game designer.
Mobile app
As I wrote earlier, all platform management is carried out through a mobile application that connects to it using the BLE protocol.
Few gifs
In fact, to implement any game you need to write a full-fledged mobile application for it, in which you describe all the rules and mechanics.
In the process of writing the application, we performed all testing by connecting to the platform, which is not very convenient. Therefore, in order to simplify debugging, we have made a simple software emulator within the application, on which data is also displayed as they would be displayed on the playing field.
At the very beginning, we encountered the problem that the data that leaves the application is lost. Found that when using BLE, the maximum packet size that can be sent is 20 bytes. Therefore, we break all outgoing data on BLE into packets of 20 bytes, in the header of which the “Gate” parameter is written. This parameter helps Arduino to understand which particular platform component this package belongs to. On the Arduino side, processing these packets is elementary:
if (NewCommandReady) {
switch (CurrentGate) {
case1:
processLEDCommand();
break;
case2:
processDriverCommand();
break;
case3:
processMagnetCommand();
case4:
//тест break;
}
//команда обработана
NewCommandReady = false;
}
After we broke the streaming data between the smartphone and the BLE-module to transfer packets of 20 bytes, the data ceased to disappear, but often came to Arduino in a distorted form. It turned out that we did not take into account that the Arduino serial port has a buffer of 64 bytes. At buffer overflow the data was lost, and the subsequent were distorted. Increasing the size and creating your own buffer did not always help. I had to write a protocol wrapper over the BLE transport to reliably send and receive data.
Due to the use of such a “protocol”, data exchange was slightly slowed by checks of the integrity of the transmitted data, however, reliability is more critical for the game - it will be insulting if the AOE displaysome ability will not be complete or the hero will not be moved when confirming a move on a mobile phone.
To display objects on the playing field, we used the principle of layers in OS window subsystems:
- Each object or action that is highlighted (characters, obstacles, the path of movement of the hero, the available area of application of the ability and the rest) uses its own layer.
- When applying layers (for example, the AOE area over the available application area of the ability), the initial state of the LEDs is remembered. As a result, it is possible to return the original color when the top layer disappears.
The main volume of data transferred between the mobile application and the platform is LED repainting. For optimization purposes, a couple of algorithms have been added:
- To repaint the diodes, a buffer is used in which changes are made up to the moment when these changes are to be displayed on the physical board.
- Repainting a single LED within the same command is excluded.
- When repainting (for example, shifting the area of the AOE ability by 1 cell), the current state of the LED board is analyzed. If the color of the LED in the new state does not differ from the previous one - no commands on the Arduino will be received for its repainting.
Game process
So you decided to play. Below I will describe how it looks from the outside:
- Insert the plug into the outlet and turn on the game.
- At each start, an automatic calibration occurs to determine the exact number of steps of the stepper motor to move 1 square.
- In parallel, we connect the smartphone to the game using Bluetooth.
- In the mobile application, each player chooses a hero with whom he wants to play. After everyone has made their choice, click “START”.
- Each of the characters has its own color. The game will automatically highlight the cage where you need to put your hero figure.
- The game takes place sequentially. The first move is made by the player who first chose the hero, the second by the second, and so on.
- Each character has a certain number of Action Points (MP), which can be spent on moving around the arena or using abilities.
- Each ability has its own recovery time, which is calculated in rounds. Within the mobile application there are 2 concepts: Turn - the interval from the beginning to the end of the current actions of the player. Round - the sum of the moves of all the players participating in the game. At the moment, the move of one player is limited to 30 seconds.
- On the field there are obstacles through which the player can not pass or use most of the abilities. Now they are simply highlighted in red on the playing field, but in the future they will have a physical embodiment.
- You can move the field with the help of special abilities that each character has. For example teleporting mage. Unlike the standard movement, when a player lays the route of his hero, cell by cell, when using these abilities, the player indicates only the end point. As a result, there is a need for an algorithm to search for the shortest path to the specified point, bypassing all the objects with which a collision is possible (figurines of other heroes, obstacle figures, etc.).
This problem is solved quite simply with the help of graphs and BFS passage through the cells.
In short, the essence of the algorithm is to mark the cells along the distance from the current position of the hero to the specified cell (indicated in orange), to which the hero must be moved.
After finding the desired cell, the return path is searched for by the cells in such a way that the distance from the starting point to the next cell must be 1 less than to the current cell (the passage is marked in yellow). After returning to the initial position (green cell), a sequence of points is formed, which is the shortest path. This sequence is transmitted to the Arduino as a team to move the hero. - After the death of the hero, the game automatically moves his figure to the “home zone”. The home zone is the cell in which the figure is placed at the beginning of the game. Each player has its own. After the start of the game in the home zone can not enter or use the ability there. This is done so that it is impossible to catch a player during a rebirth. For the player whose hero was defeated, the game ends in 1 round. After he re-engages.
- At the moment, the winner is the player whose hero was the last to remain on the field, beating his rivals. But the condition may be different, for example, the one who won the first N frags wins.
This is a gameplay that works in the current version. Due to the lack of experience in game design, we may not see obvious jambs or opportunities. For example, it is always painful to wait for your next move. In the current implementation, the waiting time can reach 1.5 minutes. In the next version of the prototype, we plan to add RFID tag readers, which will allow to diversify the gameplay. For example, use cards with RFID tags that you can use outside of your turn.
Thumbnails
Thumbnails love everything! And we are no exception. Therefore, in parallel with the collection of mechanics and programming, we were engaged in inventing our own miniatures. I think from the pictures it is clear that our game is about fantasy cats fighting in the arena.
Because we do not know how to draw from the word in general, we turned to our friend, who with great pleasure began to draw "fighting cats".
For the basis she took our own pets. So, in her house there lived a huge and angry cat named “Pirate” - it is he who is the basis of the Warrior miniature.
A couple of weeks we got our first sketches.
From the articles on the production of board games, I realized that in Russia, the creation of miniatures is bad enough and many order them in Finland or Germany.
Before we started producing miniatures, we needed to make a master model for each character, which is quite enough for a prototype. At first we wanted to make them from polymer clay, but it turned out that there were no miniaturists among our friends, and it was too expensive to make to order. Therefore, we decided that we would first print them on a 3D printer. For this, our friend made us the 3D models of our first characters in Zbrush.
With the help of FDM printing, we failed to print out figures of acceptable quality, which was quite expected.
Fortunately, my wife has SLA 3D printers at work.
Stereolithography (SLA) is a 3D printing technology that allows using a light source, layer by layer, using the photopolymerization process, to transform liquid materials into solid objects. The thickness of the layers, during printing using the SLA technology, is several times less than during printing using FDM, hence the quality of the finished product is higher.
A few days later we were given our first miniatures.
The quality of these miniatures is much higher, but still does not reach the production ones obtained by molding plastics. The blame for this is the support that, after removal, leaves noticeable traces. In theory, we could “cut” the figures into separate parts and print each one separately, without using supports, and then glue them together. But it would take a lot of time, and in the future it may still change.
Each figure stands on its base, which we also printed on a 3D printer. Inside the base is a neodymium magnet. The size and thickness of the magnet was chosen empirically so that the figure would quietly magnetise to the electromagnet on the carriage of the platform, but would not react to the neighboring figures.
Total
At the moment we are engaged in improving the physical characteristics of the platform and the reliability of all components. We replace plywood with polycarbonate and ABS plastic, improve the mounting of the platform components to each other and make the playing field removable so that it can be changed into a different form factor field (for example, hexagonal). The next step is to create a full-fledged MVP, which is not a shame to show people.
With the game a little harder. Of course you want to fully focus on the implementation of the platform, without reference to a specific game. However, we are well aware that no one is interested in a platform without a game.
Thank you all for your criticism / advice / interest. We had an idea about creating a version without using mechanics, but with the ability to determine the position and type of the figure on the field. I think the following article will write after the creation of MVP .