Bang! the board game (server & client)
There are many activities to do for your hobby. Playing Board games with friends can be one of them. But, due to the extension of COVID 19, it is hard for us to gather a lot of people and enjoy these games. Furthermore, even if it is not for COVID 19, it was still difficult for us to gather people with knowledge and experience with this game. Through our term project of Software Engineering, we made a program for a Board game called ‘Bang!”, using Software Engineering Techniques.
The game ‘Bang!’ is a game which has a background on the western era. The game can have up to 7 players, with different roles, such as sheriff, vice, renegade, outlaws. Each role has to fulfill different conditions to win the game. This can be done with the help of several cards, such as Bang! or Mancato!. The extension pack holds many scenarios that can turn the tables of the game. We made this program based on the Server and Client system along with many Protocols for effective communications and controls. We also use a neat User Interface for better use.
The main objective of this project is making people enjoy and have fun with our project. To do this, we have to make sure that while connecting clients and server, there has to be no errors or issues with connection. Also, the interface has to be intuitive for people to understand and play. And we have to check if the server can contain more than 7 clients to start the game. For further improvement, we’ve set the limit of clients to 10000. This will determine the success of the project.
There are several techniques used in this project. First, we made the server to allow many clients to communicate with the server. For better communication, we made a sub-server that will be connected to the clients one-on-one and let these sub-servers communicate with the main server. These sub-servers are managed by Thread-pool in the main server and this relieves the main server.
Next, we made Managers to follow certain protocols which allows us to manage and control clients efficiently. The Managers are divided to manage each game, player and session. This will prevent bottle-necks occurring from sub-servers and receive data from each sub-servers. Each manager will do their work.
Finally we made the architecture efficient to reduce throughput to the main server leading to the reduction of overload. The main server will only give certain messages to the clients and the clients will each do the given order such as dispensing cards and running the game.
Our project is based on Client-Server architecture. Through this, we can show how clients and servers communicate with each other. The modeling of our project will show how the server reacts and works when new clients join the server. We also used timeout and other methods for effective communications and resource management.
There are two types of requirements, functional and non-functional requirements. The functional requirements are the following :
The board game “Bang!” is popular among people and we wanted to make this game possible to play with other players online.
The game basically requires Character cards, Playing cards, Role cards and others and it also requires Scenario Cards in Extension packs for various game environments.
When people play our game, they need to have intuitive and also neat interfaces for better use.
A lot of people have to enjoy this game online, and these people need specific rooms to play privately. For this, we need a server to let clients communicate with each other and passwords for private rooms.
This requirement is needed for fluent communication with servers and clients. We’ve set a limit of 10 seconds for communication and if the response time exceeds our limit, the connection between them will automatically break.
We’ve tried to set the response time of the server below 1 second for each client for better connection.
We’ve tried to make the server simple and light with Raspberry PI. Still, it needed not to be lagged behind, so we tried to simplify and relieve the work for the main server, such as only giving certain orders to sub-servers and clients during the game, which makes the server simple and well-performing.
We’ve used a behavioral model to illustrate the action servers take when new clients join. We’ve show this with activity diagram and the diagram follows :
The diagram shows how the server behaves when new clients join the server. First, when the server is activated, it gets assigned a new port number by port forwarding and initializes the thread pool. After that, it waits for new clients to join and check status for clients joined. When new clients try to enter the server, the server checks availability if the client can join the server. If it can’t, the server tells the client why they can’t join the server. (Ex. redundant ID, Wrong Password) If the client is accessible to the server, the server creates a capitalizer, which is a sub-server for the client. It also creates Player Manager, Game Manager, Session Manager. When this work is done, the sub-server joins the pool which was initialized at server activation. When the command for server termination is accepted, the server sends all connected clients connection break messages and terminates all sub-servers in the Thread pool. After checking total termination of sub-servers, the main server closes.
We’ve used Client-Server Architecture design to show our system to show how servers and clients interact with each other. The architecture follows :
The architecture design shows that when clients access the server, it gets assigned a sub-server and this sub-server interacts with the server through the internet. Also, you can see that Player Manager, Session Manager, Game Manager do their work assigned.
First, we have to check if the system meets the requirements. First we had to check functional requirements.
- Board game implementation (Bang!)
- We’ve made the program to accept 7 players to play the game, through online.
- Game rules and other requirements implementation
- The players have to get a certain position for the game randomly and they have to choose a role, scenario and their character to play.
- Neat and intuitive User Interface
- The users can be immersed into the game with a neat and intuitive user interface. They can check who to target, what to do and which card to use, what kind of equipped card they have.
- The server has to be secured with a random password and has a limitation of 7 people.
- Connection Timeout between server and client (10 Seconds)
- We implemented this part with the following code, and the result is below the code :
- Server : We’ve made the server respond to each client below 1 seconds. This can be unavailable according to the environment condition of each client.
- Performance using Raspberry PI
- As you can see, the figure below shows that we’ve used Raspberry PI for server performance.
Furthermore, we’ve had a test on the system to check if the server can tolerate 10000 clients. We’ve first used JMeter for the test. We’ve set 9999 clients for the initial test set, but the computer went out of memory when about 4000 clients accessed the server. The result follows :
We’ve found that there were no issues or problems with 4000 clients on the server.
Next, we’ve used the Socket_V3 tool for testing. The test was focused on communication with server and client. Under the condition that 4000 clients are on the server, we’ve checked if the server can respond well to the client. The result follows :
We’ve found that there were no problems or issues with communicating with the server no matter how many clients were on the server.
Sheriff : The king of the game. Target of Outlaw and renegade
Vice : The role of helping Sheriff. Same target as Sheriff.
Outlaw : The opposite team of Sheriffs. The goal is to kill the Sheriff.
Renegade : No one is a team. The goal is to survive alone.
<Bang!> card : 1 damage to one player within range.
<Mancato!> card : Disable the effect of the <Bang!> card.
ThreadPool : A kind of pool that collects and manages Threads.
SessionManager : Check the connection status with the server in real time and check for abnormal disconnection.
PlayerManager : Manage access and exit of other players.
GameManager : Engage in game progress and UI placement related to the game. (ex. card usage, HP damage, etc.)
Capitializer : A sub-server created in one-to-one correspondence with each client when a client connects.
JMeter : Java program designed to test the performance of client-server structured software
Socket_V3 : A program that lets you access the server and send messages and receive responses.
Our project isn’t over yet. We will update card functions and new cards necessary for the game. Also, even though we’ve set the limit of accessible clients to 10000, only 7 clients can enjoy the game now, so we will make more private rooms for many players to enjoy the game. Last but not least, we are going to upgrade the user interface to make people more immersed in the game.
Through following the steps of Software Engineering, it was efficient and easy to understand the whole system. This led us to make the system to show better performance. Furthermore, testing in the validation step made us check the actual performance of the system, and made us realize the importance of Software Engineering. Still, it wasn’t easy to build and follow the Engineering Step, because it was difficult. But the result was satisfying, so we would be glad to follow this step whenever we launch a new project.
The copyright for board games is in daVinci Editrice S.r.l.
Please be aware that unauthorized copying or use may be subject to legal punishment.
Copyright - (ⓒ daVinci Editrice S.r.l. Via S. Penna, 24 I-06132 Perugia, Italy)