Project: Minesweeper Online EDA095

Size: px

Start display at page:

Download "Project: Minesweeper Online EDA095"

Julius Lloyd
6 years ago
Views:

1 Project: Minesweeper Online EDA095 Oscar Axelsson, D11, Elliot Jalgard, D10, Philip Mårtensson, D10, Daniel Olsson, D11, May 19, 2015

2 1 Background The goal of this project was to decide upon and implement a programming assignment specifically revolving around network programming. Our choosen assignment was to implement a multiplayer enabled version of the popular Minesweeper game [1], allowing two players to compete with each other. In addition it was decided that the game should incorporate an integrated chat system for the two participating players. In traditional Minesweeper the player is presented by a grid of clickable squares. Beneath some of these squares are hidden mines and if the player clicks on a square containing a mine then the game is over. If a non-mine square is clicked then the square opens up and displays a number which signifies the total amount of mines located in the adjacent squares. Using this information it is up to the player to avoid clicking on mines until all mines have been avoided. In our multiplayer edition of this game, the goal is somewhat reversed and it is up to each player to find the most mines by clicking on them directly. The game is carried out in turns between the players. If a player clicks on a mine then he or she can continue on the same turn and try to find another mine. If however a non-mine is found then the turn is switched over to the other player. The first player who finds at least half of the total amount of mines wins. One of the group members had previously worked with a Minesweeper clone in Java. This implementation was used as base for our work. The original code had no multiplayer or network support and implemented the traditional Minesweeper concept previously explained. The original code can be found in [2]. 2 Requirements Specification A requirements specification was created before the system implementation started. Most of these requirements were included in the final implementation. At first there was some uncertainty regarding the purpose of the server and how it should be implemented. It was considered that the server could act as a sort of matchmaker which set up peer-to-peer connections between two players. It was also considered that it should be responsible for relaying changes between the two players, as well as keeping track of the current state of the field. Because of this there were no initial requirements on the server, instead we made two test versions of the servers and ended up with the latter non-peer-to-peer solution. The complete requirements specification is given below. 2.1 General Requirements The chat and game shall be contained in the same application window. A player enters his or her nickname at the start of the program. A player enters the address and port of the server at start of the program. The system should be written in Java. 1

3 2.2 Server Requirements After two clients have connected, the server should start the game. When a game has finished, the server should restart the game. The server should only support two players at all times. The server shall generate the game field and send it to the players when a game begins. The server keeps track of the number of mines each player has found. 2.3 Chat Requirements New messages in the chat should immediately be sent to the other player. A player writes a message in a field and then presses enter to send it. The full chat history is displayed for both players. A message in the chat history consists of one line and has the format: <NAME> says: <MESSAGE> 2.4 Game Requirements A square is opened by clicking on it. Must be exactly two players to play. Each player has a time limit of 15 seconds during his or her turn. When a square has been clicked by a player, the other player immediately sees the same change. A players loses his or her turn when a square not containing a mine is clicked. When it is not the players turn, he or she can not click on any square. The mine squares found by the current player is colored blue, while the ones found by the competing player is colored red. The game field consists of 16x16 squares. The game field contains 53 randomly selected mine squares. The remaining time of the turn is always displayed for the current player. 2

4 3 Model The system can be seperated into four different parts for an easier overview: The server The client The communication protocol between client and server The GUI describing the actual game The responsibilities of each part as well as important classes and threads are presented below. 3.1 The Server The server is responsible for connecting two clients to itself, and then provide these players with a server-generated game field. The server receives changes in the game from the clients in order to keep track of the game as well as relay changes to the other player. The server keeps track of the score between the players and when to end the game because someone won. The classes describing the server side are the following: Game The class Game describes a model of the game, providing functions such as game field generation and counting the score between players. The methods in this class are called by the Server-class during initialisation of a new game, and when new player input has arrived at the server InputThread InputThread is a thread class responsible for reading incoming data from the clients. This functionality is threaded in order to not block other parts of the server running simultaneously. The messages received are in the form of Message objects, which have been converted to Json objects for easy transfer. These Json objects are then reconverted in InputThread to their original Message object. In order to convert between Java and Json objects, a third party library called gson was used [3] OutputThread The OutputThread thread class is similar to InputThread, with the difference that it handles outgoing messages to the clients instead. This class thus converts Message objects from Java to Json and transmits them Server The Server class contains the base functionality of the server. Its constructor is responsible for connecting to two clients and then start the game. The class also acts as a monitor, as the field messages contains incoming and outgoing Message-objects to the clients accessed by InputThread and OutputThread. 3

5 One important method is the onmessagereceived-method, this is called as new messages arrives from the clients to the server. The method will interpret the contents of the message and perform suitable actions such as updating the game state or relay chat messages. This class contains the main-method for the server side of the system ServerGUI ServerGUI describes a simple GUI for the server, showing the number of connected clients. 3.2 The client The client side of the communication is rather small (apart from the GUI classes presented later). It handles communication with the server and updates the GUI as the game progresses. The classes on the client side are the following: Client Client is responsible for establishing a connection to a server as well as provide the GUI with methods to communicate with the server. As the user plays the game using the GUI, i.e. clicks on the squares, the method click is called and sends the coordinates of the clicked square to the server which is then able to update the state of the game. Similiar to the Server, Client contains a method named onmessagereceived which will interpret commands arriving from the server and update the GUI accordingly. This class contains the main-method of the client side. This method will ask the user for the server address and port, as well as the players username InputThread InputThread on the client side is implemented the same way as the previously described class with the same name on the server side. The only difference being it communicates with a Client-object instead of a Server-object OutputThread As with InputThread, OutputThread is implemented in the same way as its counterpart at the server side. 3.3 The Communication Protocol The communication protocol is at the application layer and is used to define how data sent between the clients and server should be interpreted. The components of the protocol are the following: 4

6 3.3.1 Message The Message-class acts as a container for data sent over the network. It is provided with commonly used constructors and methods getting and setting the contents. Some typical contents stored in a Message-object are the ID of the client who sent the message, new entries in the chat, as well as coordinates for clicks on the game field Protocol Protocol is not a Java class, but rather a Java enum which defines protocol constants used by both client and server during message interpretation. 3.4 The GUI Most of the GUI classes were provided in the code on which this project is based. However, new components providing the chat functionality has of course been added. Some of the older components of the GUI were modified in order to communicate with the Client-class. The classes were of course also updated for the multiplayer mode, such as mine squares being colored based on which player clicked on it. It should be noted that the GUI contains some logic also available at the server side. More specifically, it contains the logic for calculating the changes after a mine click. While it is common practice to seperate the logic from the user interface, this decision was made to reduce the amount of necessary data to send over the network. The reason is that all information that needs to be sent about a click on the game field is the click itself, and the server and other client can calculate the changes themselves instead of sending all the modified squares back and forth. Most of the GUI components are simple Java swing classes without need of deeper explanation. However there is one Thread-class called TimeHandler which is responsible for counting down the time without being blocked by other parts of the GUI. 4 User Manual In order to start the application, one of the players has to start the server. This is done by starting Server.jar by either double clicking on it or if that does not work run the following command in a terminal: java -jar Server.jar Afterwards, both players need to start the client and connect to the server. This is done by double clicking on Client.jar on both computers, or if that does not work by running the following command from a terminal: java -jar Client.jar When the client starts then the username should be entered as well as the 5

7 address and port of the server. Then click OK to connect. When both clients have connected the game will begin. 5 Conclusion In conclusion the project was successful and most of the initial ideas were implemented in the final product. Altough originally it was considered that the server was to play a larger role in the application, supporting more features such as matchmaking for many clients at the same time. This idea was however never implemented because we did not go with the peer-to-peer approach. The approach we did go with allowed for a nicer design where the server contained all (or most of) the logic of the game, which was thus seperated from the clients. An improvement to this could have been to keep track of many different game sessions in the server, as a single server for only two players may be considered as a waste. Doing this would not require too much extra work, but some changes to the application layer protocol and data structures may be needed. There are some bad parts of the program, mainly related to error handling, that would not be accepted if this was a commercial product. For example, if a client connects to the server and then disconnects before the other client has connected, the server will stop working until restarted. There is also a rather rare bug sometimes occuring when coloring a mine square in which it will be colored wrong in one of the clients. We have looked into this bug but did not find any solution, but because of its rarity it can be neglected. All in all we thought the project was fun and good practice. It was especially appriciated that we could select our own application to implement freely as it provided us with more motivation and allowed us to practice finding requirements in a system, as opposed to how other courses often give you these requirements from the beginning. 6 Program Listings The source code and the program itself can be downloaded from: References [1] Minesweeper (video game), Wikipedia, Minesweeper_%28video_game%29, ( ) [2] minesweeper, Github, ( ) [3] google-gson, Github, ( ) 6

Solving Minesweeper Using CSP

Solving Minesweeper Using CSP AI Course Final Project Gil & Chai Usage (After using Makefile) java player/aiplayer