Inspiration: BubbleFighter is inspired by a 2D casual competitive game, QQTang. When the game starts, all players are divided into two sides, and each person controls a character. Arrow keys control the movement, and the sugar bubble will be put by pressing the space. Sugar bubbles will explode syrup after 5 seconds. If the character touches the syrup, it will be trapped and suffocated to death after 5 seconds.At this time, if the companion walks by, he can be rescued, and if the opponent walks by, he will die immediately. One more line.
GAME NETWORK ARCHITECTURE
• We present a game network that utilizes the consensus protocol RAFT implementation.
• Additionally, we introduce learning algorithms for RAFT optimization.
• The game is currently built on a grid-based UI.
• We have also integrated RSA signatures and validators for encryption and security.
GAME DEMO
GAME LAYER
Game layer is the frontend, the UI. We tried 2 ways to build and integrate the UI, including using Simple and Fast Multimedia Library (SFML) and the Unity3D.
• UI by SFML
Firstly, we used SFML by C++ and built a simple UI shown as follows, which contained a grid-based map, 2 players (squares) and each of which could drop some bombs (circles). SFML is multi-media, multi-platform and multi-language. The five modules including system, window, graphics, audio and network ease the development of games and multimedia applications. Also, players on different platforms are able to interact with each other.
In order to integrate the UI with the raft layer, we used file I/O, the architecture of which is as the following diagram. A readFile.txt and a writeFile.txt are the bridge to connect the UI and the consensus client layer. When the player moves in the UI, the movement will be converted as a command like “move player_id position”, and be written into the writeFile.txt, so the consensus client layer is able to read the movement and execute it in the raft process. Identically, when some other players send a movement command by raft, the consensus client layer will write the movement command received into the readFile.txt, so the UI will read from it and update the status.
The reason why we decided to implement this way is because of the error of compilation integration. As we used the NuRaft framework, it has a complicated and complete compilation system. The UI we achieved relies on the SFML package, and it needs to make up a dependency in the compilation process. However, we were not able to find a way to integrate the two compilation processes together. Therefore, the file I/O became a good option.
However, there was a new problem coming out with the file I/O. When the game layer and the consensus client layer read and wrote the file at the same time, there would be some contents getting missed, so the performance of moving synchronization was not very good. Therefore, we tried to use Unity3D. On the one hand, it had the better UI looking. On the other hand, we could use TCP/IP protocol instead of using the file I/O.
• UI by Unity3D
ABOUT US
