Multi-player Internet Game: Chinese Checkers

Transcription

1 Cardiff University School of Computer Science Multi-player Internet Game: Chinese Checkers BSc Computer Science Final Year Project Philip Legg Date: 26 th April 2006

2 Abstract The aim of this project was to design and implement a Multiplayer Internet Game of Chinese Checkers. This required building a system that was capable of playing the game, along with providing Client-Server functionality that could support up to six players in a game. As an advanced feature, the system was also to have an intelligent computer opponent that a user could play against. The system was developed by taking an Object Oriented approach, and was implemented using Java 1.5. The project was broken down into the three sections, creating a basic version of the game, the addition of networking features and finally the computer opponent. This helped manage the overall task throughout the year. The final system successfully meets the objectives set out above. A user is capable of playing up to five other users over a network connection, or can play against the computer. The computer opponent is of a beginner standard and makes use of the Mini-max search algorithm. The system has been thoroughly tested and has been found to have only a few minor errors, none of which affect the overall performance of the user s experience. The latest version of the game is available to use at This report provides a detailed account of the development of Chinese Checkers. 1

3 Acknowledgements I would like to thank Dr. Andrew C. Jones for his guidance throughout the year as my Project Supervisor. I would also like to thank Faye Whelan, John Legg and Pam Legg for their help and support during the project. Finally, I would like to thank Vicky Reynolds, Marc Norton, Adam Bennett and Laura Whelan for their assistance with testing the final system. 2

4 Table of Contents Abstract... 0 Acknowledgements... 2 Table of Contents Introduction and Background Requirements Specification Game Design Layout of the Game Playing the Game Rules of Chinese Checkers Designing CRC Cards Game Implementation GUI Implementation Adding Control to the GUI ActionListener events MouseListener events HyperlinkListener events Finding valid moves Network Play Design Client-Server Design Approaches taken for designing Server Designing CRC Cards Network Play Implementation Developing the Game Server Developing the Server Threads Developing the Client Side Receiving Messages on the Client Side Sending Messages on the Client Side Computer Opponent Design Mini-max Algorithm Alpha-Beta Pruning Applying Mini-max to Chinese Checkers

5 8. Computer Opponent Implementation Finding all available moves Constructing the Mini-max Tree Move Evaluation Searching the Mini-max Tree System Testing Testing Criteria Computer Opponent Testing Testing Evaluation Evaluation of the System Basic Game Evaluation Network Play Evaluation Computer Opponent Evaluation Future Work Improvements for Chinese Checkers Real World Applications Conclusion Glossary References and Bibliography References Bibliography Appendix A: Aims, Objectives and Work Plan Appendix B: Mid-Term Progress Report Appendix C: User Guide Appendix D: Source Code

6 1. Introduction and Background Chinese Checkers is a board game for two to six players, adapted from another game called Halma 1. It is played on a board in the shape of a six pointed star, with the aim being to move a player s pieces from one point of the star to the opposite point on the board. Players are able to make a variety of moves such as steps and jumps. For a complete set of rules for how to play Chinese Checkers, please see Appendix C, User Guide. I chose to make a game of Chinese Checkers due to the number of players that can play in one game, compared to traditional two player board games. This made it an ideal choice for creating an online version of the game. It was also encouraged that the game should be relatively unknown, compared to more common games such as Chess and Draughts. From looking at what other versions of Chinese Checkers are available, I found the alternatives quite limiting. I felt that not one version that I found catered for all the needs that I, as a consumer, was after. For instance, I found a well presented version by a company called Truantduck 2, but it had no online multiplayer facilities. Other versions I found tended to look quite dated which made the experience of playing less enjoyable. For the design of the system I have taken an object oriented approach, and used classes to break down sections into manageable parts. The use of UML (Unified Modelling Language) diagrams has also been used to convey ideas within the report. It is assumed the reader understands the basic notation of UML. For the implementation of the project, I have used Java 2 SDK v1.5. I chose Java purely because it is a language I am comfortable with and have much greater experience using than other programming languages that are available. Since Java was being used to write the code, the use of separate

7 classes was ideal as this is well supported within Java, being an object oriented language. The project required the implementation of a basic computer opponent. As this is a basic opponent, it does not perform to the standards expected from other implementations of the game found during researching. To develop a computer opponent of a high standard was beyond the scope of the project. The opponent plays using an interpretation of the Mini-max Search Algorithm, along with pruning techniques similar to Alpha-Beta Pruning, and plays to a novice standard. The server function of the system provided some decisions to be made, as to whether to have a centralised server running on a dedicated machine, or to take a peer-to-peer approach. Since the system needed to have support for up to six players, then a simple one-to-one Client-Server approach was not sufficient. It was considered to have a centralised server for the game, but this involved using a second computer that would constantly run the server application. Since the server program is not particularly consuming for processor resources, it seemed slightly wasteful to take this approach. Instead, the server is run by the player wishing to initialise a game. This involved some changes to how the server would function, which are discussed later in the project. The following report gives details of the original requirements specification (section 2) of the system. This document was written before starting the project, and so shows what was expected by the end of the project. Following this are the design and implementation phases of the project. These are broken down into the three main areas: the basic game system (sections 3 and 4), the client and server interactions (sections 5 and 6), and the computer opponent (sections 7 and 8). After the implementation stages of the project, the report gives detail of the testing of the system (section 9) and the evaluation of the system (section 10). Following this, the report gives details of the future work for developing the system further (section 11) and a conclusion of the project task (section 12). 6

8 2. Requirements Specification This document outlines the requirements of the system for the Multiplayer Internet Game. The specification gives a breakdown of all areas of the system, and also details the level of necessity of each area. Primary requirements required for the basic system are marked as Level 1 features, Secondary requirements that would create a more suitable user environment are marked as Level 2 features, and possible additions are marked as Level 3. Functional Requirements Description Level F1 The system should have a client application that is capable of allowing a user to play either a human or computer opponent. F1.1 The client should be capable of communicating with the server component of the system. F1.1.1 The client should be able to open and close 1 connections with the server. F1.1.2 The client should be able to specify which 1 server they wish to connect to to allow peer to peer connections. F1.1.3 The client should be capable of sending game 1 moves and action commands. F1.1.4 The client should be capable of receiving and 1 dealing with game moves and action commands. F1.2 The client should have a Graphical User Interface that the game is played using. F1.2.1 The GUI should display the game board and 1 player board pieces. F1.2.2 The board pieces should be movable by either 1 dragging and / or clicking on the new position. F1.2.3 The GUI should allow access to all of the client 1 and server options. F1.3 The client application should conform to the rules of Chinese Checkers. F1.3.1 The client should recognise all available legal 1 moves in the game. F1.4 The client should feature a computer opponent. F1.4.1 The computer should play to a reasonable level 2 of intelligence. F1.4.2 The computer should recognise all available 2 legal moves in the game. F1.5 The client should be able to store results from recent games F1.5.1 The client should recall highest jump combo counts 3 F1.5.2 The client should recall lowest move counts 3 7

9 F2 The system should have a server application that is capable of processing connections from the client in the system. F2.1 The server should be capable of either 2, 3, 4 or 6 1 clients simultaneously in one game. F2.2 The server should be capable of listening for game 1 requests. F2.3 The server should be capable of hosting multiple 2 games. F2.4 The server should be capable of closing a 1 connection. F2.5 The server should be able to show a client all 2 connected users. F2.6 The server should be able to allow a client to 2 challenge a particular user. F2.7 The server should be able to allow a client to challenge any available user. 2 F2.8 The server should be capable of receiving client data. 1 F2.9 The server should be capable of sending data to 1 client(s). F2.10 The server should be able to recognise the rules of 1 Chinese Checkers. F2.11 The server should allow clients to chat to each other F The server should allow clients to send a 2 message to all users. F The server should allow clients to send a 2 message to a particular user. F2.12 The server should be able to store results from recent games. F The server should recall the clients who have 3 achieved the highest jump combos. F The server should recall the clients who have 3 achieved the lowest move counts. F2.13 The server should know the name of the client F The server should know they name of the 2 client when they connect F The server should recognised registered 3 players F Stats about registered players should be stored 3 Non-Functional Requirements NF1 The system should be capable of running on a PC with at least 90 MHz Pentium Processor (or equivalent) and 32MB RAM NF2 The system should be implemented using the Java programming language 1 1 8

10 The requirements given are how I perceive the system to be. For deciding what the requirements of the system are, there are different aspects that are taken into consideration. Firstly, to re-create the game Chinese Checkers, obviously the requirements of the original game need to also be requirements of this game also. Therefore, The client should recognise all available legal moves in the game, is clearly a primary concern that needs to be addressed in the system. Secondly, the ability for the user to be able to interact with the system is another obvious concern. Without this, the system would be deemed worthless, as the user would not be able to play the game. Therefore, all concerns in Functional Requirement F1.2, The client should have a Graphical User Interface that the game is played using are of importance, as they relate to the user giving input and the computer displaying its output. Finally, the system has been stated to have specific abilities. Apart from being able to play the game, the game needs to provide an Internet play facility. Also, the system will ideally provide a Computer Opponent that a user can play against. Each of these carries additional ideas that stem from other game experiences, such as whether to offer the ability to chat to other network players during the game, and whether the computer should have varying levels of skill that it can perform to. To offer these extended features are not primary concerns of the system, and vary between the categories of Secondary objectives and possible additions. The remaining requirements listed are features that could enhance the experience of the game, such as offering a high scores table that can record the number of moves taken. As nice as it would be to incorporate these into the system, they can be regarded as possible additions since they do not have any affect to the performance of the main objectives. 9

11 3. Game Design This section deals with the design of the basic game interface and user interactions. This involves the look and feel of the game, how the user can play the game, and how the system adheres to the rules of Chinese Checkers. 3.1 Layout of the Game The presentation of the game was an important factor to me when designing the system. As mentioned previously, when researching other available implementations of Chinese Checkers, many had a dated look and feel to them, with limited colour palettes such as the early 16 colours available in Windows. I wanted to go for a design that was presented clearly, which gave a simple yet attractive look and feel for the user. The layout that I chose is similar to that of many recent computer board games. I decided on a portrait window, with the game board at the top, and a status window below. The window would be used for conversations between players and also to provide the user with any information they might need (such as connection status when connecting to a multi-player game). The user interface will be written using the Java Swing Toolkit, and also using the Graphics Toolkit. Java Swing will be used to create menus and also the command window and input line, whereas the Graphics toolkit can be used to import the graphical objects used for the board display. 3.2 Playing the Game For a user to actually be able to play the game, there must be a method for selecting which board piece to move and to where. An obvious choice would be to use the mouse to click on the board pieces. Then the user could either click where they wish to move the piece to, or could even drag and drop the piece. 10

12 The game will need to register that the mouse button has been clicked, then determine where the click is and if this relates to the players piece. Obviously, the system should not allow a user to move the other player s pieces so this needs to be checked also. There will also be times that mouse clicks should not be recognised as moves, for instance when a game is not started or if a game has just finished. 3.3 Rules of Chinese Checkers The system must know the rules behind Chinese Checkers so that it can be recognised what a user can and can not do. First of all, the game is turnbased, so one player will make a move, and then another player will make a move. For this, a simple counter can be used to keep track of which player number s turn it is. For the moves available in Chinese Checkers, a player has three possible options of what move to make: Make a step, which is simply one move in one of the six directions. Make a jump, which is jumping over one other piece on the board in any direction. Make a multiple jump, which is jumping over a series of pieces on the board. Given a piece selected by a player, the system needs to be able to find all available steps and all available jumps. The system will also need to be able to determine that if a step is taken then once the player has taken the move then their turn is over, else if they make a jump, they may be able to jump on further and so their turn continues until they choose to end by making a double click on the last space. The final rule that needs to be addressed is how the players win. This is done by getting all the pieces from one side of the board to the other, and fitting the 11

13 pieces into the star point (as the board is a six pointed star). Once each move is taken, there should be a check as to whether the pieces are at the goal area, and if all ten pieces are there then to finish the game. 3.4 Designing CRC Cards The system is to have three main classes that are the core aspects to the whole project. These are: GameInterface this will deal with all aspects related to the user interface of the system, and also with all input and output that the user makes and receives. GameControl this will deal with all aspects related to the control of the game, initialising the player and board properties, and ensuring that the rules of the game are upheld. NetplayComms this will deal with all aspects related to the network play of Chinese Checkers. This will be discussed later in the report, but is mentioned here due to being at the core of the program. The system also needs classes that are used to hold the state of information used within the game. These classes are: Board this will deal with initialising a board object. Space the board object is made up of 121 Space objects that refer to each individual space on the board. Player this will deal with initialising a player object. PlayerPiece the player object is made up of 10 PlayerPiece objects that refer to each individual player piece in the game. The following pages show the CRC cards for each of the above classes, (excluding NetplayComms, which is detailed further in Section 5). 12

14 Class: GameInterface Responsibilities: Displaying GUI to user Taking input from the user via the mouse or keyboard Showing output from the system to the user via the screen Collaboration: GameControl GameControl Class: GameControl Responsibilities: Dealing with received data Check possible valid moves Updating the state of the board Updating the state of the player Collaboration: Board Board Player Class: Board Responsibilities: Initialising each space on the board Providing accessor methods to board and space information Collaboration: Space Space Class: Space Responsibilities: Maintaining the state of a particular space on the board Collaboration: Class: Player Responsibilities: Initialising each player piece on the board Providing accessor methods to player and player piece information Collaboration: PlayerPiece PlayerPiece 13

15 Class: PlayerPiece Responsibilities: Collaboration: Maintaining the state of a particular player piece on the board Based on these CRC cards and the descriptions of each class s job, a Class Diagram can be formed to show the interactions between each class. GameInterface NetplayComms 1 1 GameControl Player Board 1 10 PlayerPiece Space 14

16 15

17 4. Game Implementation This section will detail how I constructed the basic system for the game, based on the Game Design given in Section 3. I tackled the situation by firstly designing the GUI (Graphical User Interface), and then plugging the functionality of the system in afterwards. This gave a system where the game could in effect be played on one machine by human players. The pieces could be moved and the rules were understood by the system, which became the Practice mode of the system, where either one player can control all players, or two or more players can play on one machine (depending on the number of users at the one machine). 4.1 GUI Implementation The basis of the GUI is constructed using Java Swing. This allowed for a standard window to be created, and using the BorderLayout keyword, meant that objects could be easily positioned within the window. Creating the text field and text area at the bottom of the screen was relatively simple, as these are standard Swing tools. Also, for creating the status panel, which gives information on whether a game is in play, and the player names involved, was fairly straight forward. The status text is a simple JLabel that is updated with new text on specific actions. The player names are also JLabels, but when they are updated, they are updated with HTML code. This allows the colour and size of the text to be specified, as they change depending on whose go it is. The major task involved with the GUI was the actual board itself. Using the Container keyword to initialise the area, there is a separate class within the GameInterface called GameBoardPanel. This uses the Graphics toolkit with the paintcomponent method. Within the paintcomponent method, there are three parts that draw different objects depending on the state of the game. When the program is started, the actual board design is drawn straight away. 16

18 Then if a game is started, the player pieces are also drawn to the panel. Finally, if a player is moving, the highlight piece is drawn to show which space is selected by the user. The basis to the code that performs these tasks is give below: Image img = //get image that is to be drawn Point point = //get point where image should be drawn int x = (int)point.getx(); int y = (int)point.gety(); if(img!=null) { painter.drawimage(img,x,y,this); } This code is looped for the number of times a specific object needs to be drawn in different positions. So, it would loop 121 times for the board pieces and 10 times for the player pieces. With the board displayed on screen along with the basic Swing features, this completes our User Interface for the game. 4.2 Adding Control to the GUI For the GUI to be of use, event listeners need to be added to catch the user s interactions. There are three different listeners that are included in GameInterface, these being ActionListener, MouseListener and HyperlinkListener ActionListener events The ActionListener is used within the game to listen for options that the user may choose to select. At the start of the game, the user must navigate through the MenuBar at the top of the screen to select whether they wish to Play a Local Game, or Play a Network Game. These both direct GameInterface to display one of two different option screens, to choose the options for a local or network game. These are simple 17

19 JFrame windows that are displayed. Again, these have ActionListeners attached to them to detect the user s choices; however these are within separate classes within GameInterface to help make reading the code easier. These are NewGameOptionsListener and NetworkListener. Both implement ActionListener like before, and work in exactly the same way to catch events, using the command: ae.getactioncommand() == //whatever it may be equal to where ae is the ActionEvent defined in the method. Another feature where an ActionListener is used is for the text field used for communications at the bottom of the screen. By giving the text field the name command, then if the action event thrown is equal to command, then it shows the user wishes to send the message they have typed (despite what the actual message text is). The text can then be retrieved and sent on to NetplayComms for further action (discussed in Section 6) MouseListener events As the main device used for the actual game play, the MouseListener is an important aspect of the program. The actual movement of game pieces is controlled using the mouse. Therefore, the Container that holds the board display (discussed in Section 4.1), has a MouseListener added to it, and events are thrown whenever a mouse button is clicked. Firstly, if a mouse button is pressed within the board area, it checks whether the game is started or whether it has not ended yet. If these are true, it performs another test to see whether it is this player s turn, or if we are in Practice mode. If these are true again we then concentrate on the actual movement of the pieces. The program determines whether the user has actually clicked on a space or not. This is done in GameControl by searching for any space that is within a 18

20 given range from where the mouse has been clicked. If this succeeds then the user has clicked on that space and the space number is returned to GameInterface. Otherwise -1 is returned which indicates out of bounds. The next part has three stages, relating to where in the move process the user may be. These are defined as playerfirstmove, playernextmove, playerlastmove. Depending on which stage the system is in, the appropriate move type will be sent to either NetplayComms if the user is playing online or GameControl otherwise. If the user is in the playerfirstmove, GameControl will determine whether the piece clicked is a piece of that player s, and if so, find all the possible steps and single jumps that the player could make. It then waits until playernextmove is triggered when the user clicks again on a new space. Once the user is in playernextmove, GameControl will check whether the space clicked is in the jump range or step range of moves found on the previous move. If the move taken was a step then the code jumps straight to playerlastmove to finish the player s turn. If the move taken was a jump though, then like before, we find all the possible jumps that can be made from the new space. Once the player has jumped once, they can not then change to step moves. If the player has clicked on the space they started on, this allows them to retract their move and the system goes back to playerfirstmove. If the player clicks on a space twice, this signifies the end of their jumps and so the system moves into playerlastmove. Finally, when a player is in playerlastmove, GameControl sends a message to board to indicate that the start space is now empty and that the finish space is now occupied. It also sets the new positions in the player state class. The system then checks whether the player s pieces are at the goal spaces yet. If all ten pieces are there then GameControl sends a message to GameInterface to display that the player has won the game. 19

21 4.2.3 HyperlinkListener events This is briefly included in GameInterface and is used for the Help feature available via the MenuBar. The Help window is a JEditorPane and is navigated in a Web Browser fashion, displaying HTML pages that contain the information. Therefore, Hyperlinks are used for the navigation to find the help that the user is after. What the listener does is simply alter the cursor to a hand when a hyperlink is activated, and then change the help page to what the hyperlink is pointing to. 4.3 Finding valid moves This section gives further detail of how the GameControl class manages to find game moves. This relates to Section of how the moves are made by the user. Within the GameControl class there is a 2D array that holds information about move spaces. It has 121 elements representing each of the spaces on the board. For each of these elements, it lists 6 numbers that are the neighbours to that space, starting from the top left and working clockwise around, with their values being between 0 and 120. If there is a -1 as one of the 6 values, this means that the piece can not move in that particular direction since it is out of bounds (the edge of the board). By passing a value between 0 and 120, the method validstep will look through the related array from above to find all that spaces neighbours. For each of the elements in the neighbours array it checks whether it is out of bounds, and also whether it is occupied (by checking with the board class). If neither of these are true then the space is available for the player to step to, and the space number is put into a new array. Once all neighbours are considered this new array is sent back. 20

22 The method validjump works in a similar way. The difference here is that if the neighbouring space is occupied, the system then takes the space value of the occupied space and finds its neighbours in the move array. It then checks whether the space on the other side of the occupied space is available to jump to. This is done by checking in the same direction that was checked by the original space, otherwise the piece would not be jumping in a straight line like the rules require. Again, all spaces that are available to jump to are sent back in a new array. 21

23 5. Network Play Design This sections deals with the design of the network play feature of the game. This includes planning how to incorporate a client-server feature into the game, what type of server to operate, whether this should be a centralised server or a peer to peer link, and how to allow the system to support and communicate between up to six players. 5.1 Client-Server Design In all network systems, we need a client and a server. The client has the job of receiving input from the user and sending this to the server. The server then needs to process this received information in some way and return some information back to the client. Java is well suited for simple client-server communications since it offers a wide range of functions that help to create network applications. The system requires that up to six players can play in one game, and so this means that there should be six clients that are playing the game and sending move information, and one server that should be capable of receiving move information and update all other players with this move. Along with move information, the clients should be able to send chat messages to the other players through the server, along with player and connection information, such as what each player s name is, and their socket details. The system needs to have a server that is capable of hosting the network games. Originally, this was to be a centralised server dedicated to running the Chinese Checkers server program and all players would connect through this to play their games. However, this idea became a little ambitious as it meant having a computer system switched on permanently for anyone to be able to play the game. It also meant that there would need to be a waiting room feature, where a user can connect to find all the existing games waiting to begin and connect to one of them. This would have been quite a complex 22

24 system to create, which I did attempt but once understanding what would have been required, I felt was beyond the project requirements and the timescale that I had for designing the system. Instead, the server was designed as a lightweight application that can be executed on any machine supporting Java, which will support one network game of Chinese Checkers. Since this only supports one game at a time then, it seemed to make sense to include this with the actual game program, and then one user can host the game by executing the server application on their machine whilst playing the game. With users able to host their own games in this fashion, in effect this allows for many games to be played at once without consuming one machine and having a complex system that deals with multiple games. The only disadvantage to such a system is that a user can not log onto a central server to find other players without arranging the game beforehand. 5.2 Approaches taken for designing Server For the client, it is relatively straight forward to send a message to a server. The issue occurs for how the server can process this information and forward this on to other clients. To begin, I designed a simple client-server echo application. This was quite straightforward, and based on Java s Socket features. This allowed a client application to connect to a server application, and then the client could type a line of text and the server would return it written in capital letters. This helped to understand the interactions involved in creating a network application. The problem occurred when trying to connect more than one user to this server application. What would happen is that the original client could write messages and receive responses, but it was only once the original client had disconnected that the server would start returning information to the second client. This obviously would not be suitable for the game, as all players need to be connected throughout the entire game. 23

25 The second approach that I tried was Multicasting. Whilst researching methods of broadcasting data, I came across Multicasting. Again, I created a simple application that returned text in capital letters and tested with multiple clients. This system appeared to work, and could cope with numerous clients all connecting, and all clients would hear the responses from the server. When tested over the real Internet (i.e. not within the same IP domain), I found that this failed. I learnt that Multicasting is designed to be used only within the same network where information passed between all systems can be trusted since it is internal. The third and final approach taken was to create the simple client-server like before, but to add the use of Threads. By using Threads it allows multiple instances of a class to be executed. Therefore, when a new user connects to the server it can simply create a new Thread that can deal with that client. This approach worked with the simple application created and so was to be adapted for use in the Chinese Checkers game. 5.3 Designing CRC Cards The network feature of the program will have three classes associated with it. These are: NetplayComms this is the client side of the network that is linked in with the actual game components. GameControl and GameInterface send information here to be passed onto the network. Server this is the entry point to the server application. It will listen for new connections, which when they are detected will be accepted by the server and have a new Thread created for the client. ServerThread this is the Thread that each client has associated with it. This is the where communication from each client is dealt with, before being passed to the main Server or to the other clients. The following pages should the CRC cards for each of these classes. 24

26 Class: NetplayComms Responsibilities: Initialising connection to network Sending messages to the network Receiving messages from the network Collaboration: Server ServerThread ServerThread Class: Server Responsibilities: Listening for and accepting connections from clients Storing information of all players and connection data Displaying server messages to terminal Collaboration: NetplayComms Class: ServerThread Responsibilities: Connecting clients to game Setting up network game Sending messages to all connected players Receiving messages from client Collaboration: Server Server NetplayComms NetplayComms 25

27 26

28 6. Network Play Implementation This section details how I constructed the Network Play feature of Chinese Checkers, based on the design issues mentioned in Section 5. The task was tackled by developing the server system that could send messages to multiple users, and then incorporating this into the existing game so that game moves, player messages and game commands could be sent and received over the network. 6.1 Developing the Game Server As mentioned in the design phase, the server is to operate by using Threads that will deal with each player as they connect to the server. This means that each user can connect to the server without blocking any other users, and so can also send information to the server at the same time. To provide this feature, the following code was used: while (listening) { new ServerThread(this, serversocket.accept()).start(); } Since listening is always true, this code constantly loops, yet the new ServerThread can only ever be created if there is a connection to accept on the server socket. Once there is a connection to accept, then the ServerThread is started and the loop will wait again for another connection. The server also has basic elements of Swing included, which simply displays a message window that shows the status of the server on the computer that the server is executed on (i.e. the host computer). The last main feature of the Server class is that it holds data that all players will need to be able to access. Because the main interactions take place on 27

29 dynamic Threads which can not be referenced as individual entities, we need a storage area that all Threads can access. Therefore, the Server class stores player colours, player names, and setup information. By doing this, it means that when the game is started, all Threads can access these lists to display information about who a player is playing against. With the basic features of the Server class covered, we can discuss the ServerThread class where all the main interactions after connection take place. 6.2 Developing the Server Threads Once a player is connected to the server, all the interactions between the user and the server are through the ServerThread. The ServerThread uses a static vector that stores the access details of all the players. When a user connects to the server they are added to this vector list. By using a static vector list, this means that the same object is used in each instance of ServerThread, and so they are all updated when a player joins. The ServerThread then checks how many players are connected to the server. If there is only one player then it returns a /newgame command to the client, which will prompt the user to set up a new network game. If there are more users connected than players required for the game, the server sends a /serverfull command to the client, which will tell the user that the server is full. Otherwise, the server will send a /joingame message, along with attributes relating to number of players and their colours back to the client so that the user can select their colour and enter a name. When the server receives these choices back, the server stores these values and either starts the game if there is the required number of players, or makes the user wait until there are. 28

30 Once the user has been setup on the server, for as long as they are connected, the Thread will listen for messages a client may send. Like before, these can either be moves, commands or messages. When the ServerThread receives a message that is not related to the game setup, it is assumed this is either a game move or a player message, both of which need to be broadcast to all other users. The following code sends a given message to all connected users: protected static void sendmessagetoall(string message) { synchronized(users) { Enumeration e = users.elements(); while (e.hasmoreelements()) { ServerThread st = (ServerThread)e.nextElement(); try { synchronized(st.out) { st.out.println(message); } st.out.flush(); } catch(exception ex) { stoprequested = true; } } } } } This code (which is adapted from an example given on the JavaWorld 3 website), synchronises the users vector so that no changes can be made until after these action can be performed, then for each user in the vector, it sends them the message to be broadcast

31 6.3 Developing the Client Side We have already discussed how the Server takes messages sent from the Client, and either stores them for reference or passes them on using the synchronised broadcast technique. Now we shall look at the Client side of the system, and how this can fit into the existing Chinese Checkers system. When the NetplayComms is initialised, it connects to the server using Sockets. This is straightforward in Java and has been discussed in the previous sections. Once the Client is connected, in a similar fashion to the Server, we set up the Client to constantly listen to incoming messages. Any message sent from the Server to the Client will be detected by this, and can be processed in the appropriate manner. Again, sending messages is the same syntax as before, and we have a separate method that is responsible for doing this. Although the Client operates in a similar method to the Server in terms of what it can do, the task of receiving and sending messages are more important since it is the Client that processes them, whereas for the most part the Server purely acts as a carrier of messages. We will focus on the tasks of receiving and sending messages on the Client side in more detail Receiving Messages on the Client Side When a Client receives a message from the Server, it needs to determine what type of message it is. Game moves and game command messages all begin with a slash / to distinguish this. Therefore, the Client side first checks whether the message received begins with a slash. If it does, it goes on to determine which command was sent, and performs the necessary actions. There are three types of game move commands that can be sent, these are /firstmove, /nextmove and /finalmove, all of which carry an attribute of the appropriate space number. These simply fire the corresponding methods mentioned earlier in GameControl. 30

32 If a message does not begin with a slash then it is a chat message. This can be either from the system or messages sent from other players using the chat window. All these messages are simply displayed as output in the status window for all users to see. Since all the messages are sent as Strings containing all the information, if there are attributes contained within the string, for instance the game moves or the setup instructions, we need to split the string into parts. There is a short method called splitmessage that performs this for the system and returns an array of strings. The system can then use each part of the string for the appropriate task Sending Messages on the Client Side The Client side has two sendmessage methods. This is to distinguish between messages sent by the system and messages sent by the user. The first method has one argument of a String called message, which is used when the system wishes to send a command over the network. This method will simply send the message without altering the contents at all. The second method has two arguments; both types are Strings, one called name and one called message. This is used for any messages sent using the chat window, and so it tags the player s name to their message, and adds the text says: between the two. This will then either send the message over the network if the user is connected, or if playing a local game, will return it to the GameInterface. This means the message is in the correct format for displaying in the chat window. 31

33 7. Computer Opponent Design This section details how the Computer Opponent was designed for the Chinese Checkers system. This takes into consideration the techniques of developing a Computer Opponent for a board game, and how to provide the computer with a level of intelligence suitable for playing the game. 7.1 Mini-max Algorithm After researching on the Internet for methods of designing computer opponents for games, I found the most common approach to be the Mini-max algorithm. The Mini-max algorithm is an algorithm designed of logical two player games, such as Chess. With such games, given a situation in the game, it is possible to determine what moves a player can make since there are a set of strict rules about how a player can move about the game board. With this in mind, it is fair to say that a computer could perform the same task of finding all available moves given a situation in the game, if it knew the rules of the game. The Mini-max algorithm makes use of a search tree. A tree structure has a top node (known as a parent), and this parent has a number of children. Then each of these children has children, and so branches of the tree are formed. This process continues for however deep a tree is required. The tree can then be traversed by travelling along the branches of the tree to find different elements held at the nodes. In Mini-max, we use a search tree for storing information about the moves a player can make. Given a top node bearing the current position, each of the children to this node would hold a possible move that the first player could make. Each of these moves would also be given an evaluation score that determines how beneficial the move is to this first player. The evaluation 32

34 score is decided by considering the rules of the game that the algorithm is being applied to. Once all of the first player s possible moves are stored into the tree, for each of these moves we determine what moves the second player could make in response to the previous move. Again, these are all given an evaluation score of how beneficial they are to the second player. Once these are complete in the tree, the same is done again for the first player for the new children, and this process can continue on until a situation is reached where the game would come to an end, for instance in Chess, if a checkmate position was found. The algorithm is called Mini-max because a player would intend to minimise their opponent s chances of winning whilst maximising their own, hence why each move has an evaluation score given to it. A player would choose the branch in the tree that gives the lowest scores for the opponent whilst giving high scores for itself. 7.2 Alpha-Beta Pruning Using Mini-max for a computer opponent, it is intended that the entire tree is constructed to the end game situation to provide a strong opposition. However, this can be time consuming and computationally expensive. What we can introduce to try to resolve these problems is Alpha-Beat Pruning. The aim of Alpha-Beta Pruning is to reduce the number of nodes that the system needs to evaluate whilst constructing the search tree. When the system is constructing the search tree, if there is a particular branch that is scoring low evaluation values when there are other branches which are much more successful in the system s favour, then we can stop traversing the weak branches. This allows the system to focus only on the moves it may realistically make that provide a much stronger position. It also means that if system resources allow it, the tree could be traversed deeper down the successful branches to achieve a much better result. 33

35 Each level in the search tree is referred to as a ply. So if a tree searched down 8 levels it would be 8-ply. This is a useful aspect of designing a search tree for Mini-max, as it can be used to provide different standards of computer opponent. A system that searches the entire tree could be expert whereas a system that only searches to a 3-ply level could represent a novice player. This can relate to the real world, where we consider whether a novice player would look ahead at the possibilities available in three moves time in a game of Chess. A human player may be able to get checkmate in just four moves, but just not be able to see how. 7.3 Applying Mini-max to Chinese Checkers As stated in Section 7.1, Mini-max is intended for two player games, whereas Chinese Checkers can support between two and six players. This provided some issues whilst trying to plan for the computer opponent. Considering the original Mini-max tree, by traversing the tree down 2-ply would give each player a turn and it would be the first players turn to move again. For a six player game, the tree would need to be traversed down by 6- ply to give each player a turn. These are the minimum number of traverses needed within the tree, since given a player, to make an educated move; they need to consider all other players in the game. Obviously, if we travelled further down the tree then the move would be of a greater benefit to the player. Secondly, for each level in the tree, there can be a very large number of moves available. This is because for each piece, they can step in up to six directions (given there are no obstructions), they can jump in up to six directions, and if they have jumped, they can jump again in another of the six directions. Therefore, a player can in effect make an infinitely long move, since there is no upper bound to the number of jumps a move can make. To avoid this, the computer opponent can be designed to not consider spaces that it has visited before in that same move. A player would find no benefit of performing such a move, as the path taken to reach a space is irrelevant. 34

36 Finally, the evaluation score for a six player game is much more complicated. Each space on the board has a number assigned to it, from 0 as the bottommost space up to 120 as the top-most space. Therefore, the top and bottom players can easily try to minimise/maximise the space value to land upon as one of he considerations when taking a move. For the players playing across the board though, they could recognise when they are at a goal relatively easily (since the goal spaces are defined for each player), but not as easy to define when they are near to the goal area. This would be a situation where weighted values for spaces would be required, but because of the nature of the game, each player would need their own set of weighted values for spaces that would benefit them. After several design attempts, it was decided that due to time, that only a two player computer opponent would be implemented. 35

37 8. Computer Opponent Implementation This section details how the Computer Opponent of Chinese Checkers what implemented into the current system, based on the design issues discussed in Section 7. The computer opponent is mainly dealt with within the GameControl class, which deals with finding and evaluating the available moves. There is a separate class called MinimaxNode that is used when constructing the Minimax Tree, which holds information related to the player moves, and maintains the structure of the tree. Within GameControl, by using the method nextgo, which simply moves the turn value to the next player, if we are playing the computer and the turn value is not zero (indicating the human player), then we fire computemove(). 8.1 Finding all available moves The first task of the computer opponent is to find all available moves that it could make. For each player piece, the computer will try to find the possible jump moves available and the possible step moves available. The methods used within GameControl to do this are findavailablemoves(), which is a loop that goes through each of the player s pieces, and for each piece, this method will invoke recursivejumpmove(vector) and singlestepmove(vector), which are the two methods responsible for finding the moves. As the title suggests, recursivejumpmove calls itself within the method to find moves that involve multiple jumps, whereas singlestepmove is only called once for each piece since multiple steps are not allowed. Each move, whether it is a single step, one jump, or multiple jumps, is stored as a Vector that lists the spaces that the piece moves from and to, referred to 36

38 from within these methods as onepossiblemove. These are all put into another Vector group called allpossiblemoves. 8.2 Constructing the Mini-max Tree Once allpossiblemoves contains information for the current player, the computer can begin constructing the tree. The Vector allpossiblemoves is cloned to the Vector rootmoves so that allpossiblemoves can be reused later on whilst constructing the tree for the deeper levels. Firstly, the tree is initialised with a root node, using the MinimaxNode class. As a root node, this holds no actual move for the computer to consider, but helps maintain the structure of the tree by containing a Vector to list the children nodes in. For each move in the list, we determine an evaluation score for that particular move (discussed in Section 8.3), and create a new MinimaxNode called move. Each node holds the move Vector, the evaluation score, a Vector to list its children in and a reference to its parent node. The computer then changes the state of the Board class as if the move had been performed and sets turn to the next player (which is the human opponent). The computer then clears the Vector allpossiblemoves and performs findavailablemoves again but this time from the human opponent s point of view. Once this has been repeated for the human player, it is performed on the computer opponent once more. Afterwards, the Board state is reset to its original state so that the game continues correctly. The Mini-max tree that is constructed by the above operations is 3-ply. This means that the computer opponent can make a move based on the position of its opponent and also itself. In effect, it means the computer can plan its moves so that it will make a move that will benefit its next turn. 37

39 8.3 Move Evaluation Whilst constructing the Mini-max tree, each move has an evaluation score associated to it. The score is based on the quality of the move and how beneficial it would be to play it. Since the game is designed for the two player mode only, the evaluations are adapted to suit the players in the top and bottom board positions. For both the computer and human players, a high score indicates a good move whereas a low score indicates a poor move. The first check is aimed to move get the player pieces out of the start area as soon as possible. This is so that pieces are not left behind, since it is harder to move pieces across the board when there are fewer pieces in the centre area. If the start space of the move vector is in the start area then it scores highly, and scores extra if the end space is not in the start area (this means the player is moving into the centre area). If a move ends with a piece moving back into a start area that was not into the start area at the start of the move then the score will decrease. Similarly, the next check that is made is whether a move will put the player piece in a goal position. Obviously this is a highly beneficial move and so is weighted to show this. If a player starts outside the goal and ends within the goal then they score highly. If a player is already within goal and is simply moving to another goal space then the score is much less, and if the player starts in the goal area and moves outside of it then they loss points. After this, the computer will check the distance of the move. The further the distance of a move the better it is for the player. A strong tactic for succeeding in the game is finding multiple jump moves that get the pieces across the board in as few moves as possible so this is an important issue when considering moves. The score given depends on whether the start space is higher or lower than the end space (depending on whether it is the human or computer player being evaluated). The distance between the spaces is used as a basis for the score, by finding the modulus of first-last (where first and 38

40 last refer to the space numbers). Low scores are given to moves where the spaces are next to each other (such as steps to the side). The evaluation then checks how many elements are in the move Vector. This refers to how many hops a move has. Steps only have two, whereas multiple jumps can be much higher. The score given depends on whether it is a multiple jump or a single step or jump. Similarly to the distance check, the computer now performs the same but instead of using the space numbers, it uses space evaluation numbers. These are weighted values that give centre spaces weaker scores, up to the goal areas which are rated highly. Since this is a two player game, the left and right sides of the board are also given a low rating since players are not aiming for areas in those directions. Following this, the computer then checks to find how far behind the piece is. Similar to an earlier test at the starting area, pieces that are further behind should be moved to avoid them falling too far behind. If they are left behind too long, fewer pieces are in the centre area to use for jumping over. The final test is related to the end of the game. Earlier it was mentioned that moving a piece from one goal space to another is not beneficial in the early stages of the game. However, towards the end, the computer may need to arrange the pieces to fit in the last few. Therefore, if there are over seven pieces at the goal, then they can move further into the goal area to make space for the others. 8.4 Searching the Mini-max Tree Once the tree has been constructed with the appropriate move information and the evaluation scores, the computer opponent needs to search through the tree as a whole structure to determine the optimum solution. The search is performed as a depth-first traversal, where, at each node in the tree we look at each of its children first, and then to the parent. To convey this 39

41 within the program, we use nested for loops, where each loop looks to the children of that node. Before each for loop we check the evaluation score for the current node. If the score is less than 50 then we do not look at the node s children, else we do and the for loop is reached. This is an adaptation to Alpha-Beta pruning, which prevents weak branches from being pursued further. For each path through the tree we determine the overall evaluation score for it. Since the computer opponent is only using a 3-ply search tree, this means that in the tree we have a score for the computer s current move, then the human player s move and then the computer s response to that. The computer adds together the two scores for its own moves, and subtracts the score for the human player. The computer searches through each path of the tree to find the highest score from this calculation. This should provide two good moves for the computer whilst offering the human player a much weaker move. Once the computer s move has been found in the tree, the move vector is retrieved from the node. Using this, the computer simply calls the move methods with each of the space values given by the vector list. This is done using a simple for loop that repeats for the number of jumps that the move involves. 40

42 9. System Testing This section discusses the testing procedures used for Chinese Checkers, and results from tests made on the system, and an evaluation of the system performance. To assist for testing, I had five volunteers that, before this project, had not played the game before, two male and three female. All of the test users are capable computer users but not Computer Science students, or related disciplines. They are use to using computer software, whilst not use to considering the techniques and methods used in the background programming. I felt that this gave me a typical sample of users of the system. 9.1 Testing Criteria To test the system, I had to consider the areas of concern that should be focused on where an end-user opinion would be more beneficial than my own. I felt that an important consideration was whether the software was easy to use. As a requirement that can not be measured, it seemed that test users were ideal for measuring this area of the system. My intention was to monitor their use of the software to see how they managed playing the game, as well as navigating the options for the game. After playing the game, I would also ask the player to comment on their experience with regards to the user interface and how they interact with the system. The second main area I felt that user testing would benefit was for the Computer Opponent. As the designer of the game and the opponent itself, I felt I was too involved with the project to test the computer s abilities, since I know how it performs. By using testers who had not played Chinese Checkers before, it meant that after teaching them the rules of the game and allowing them to practice a few times, I had novice players. This was about the ability level that the computer was to play to, and so the computer should be able to 41

43 win some of the test games. I intended to allow two of the testers more practice than the rest so that they were of a higher standard that would have more of a chance at beating the computer. The last test was to involve the Network Play mode. This would be a six player game between myself and the five testers. By this point, all players would be use to the system and understand the game well. This would offer the testers a chance to experience the online facilities that the game offers, and see how it functions. Following the game, I would then ask for feedback of the experience and any comments that they wish to make. 9.2 Computer Opponent Testing Below are the results of the five testers against the computer opponent. All games are two players, with the tester as blue and the computer as green. The ratings given to each of the players is reflective of how many times they have played the game previous to the test matches. Before the testing took place, all testers played practice games against other human opponents to learn the rules and understand the different moves available. This also involved learning how to control the movement of pieces. Faye Whelan Ability: Intermediate Winner: Computer Moves taken: 48 Winner: Faye Moves taken: 50 42

44 Vicky Reynolds Ability: Intermediate Winner: Vicky Moves taken: 54 Winner: Vicky Moves taken: 47 Adam Bennett Ability: Novice Winner: Computer Moves taken: 58 Winner: Computer Moves taken: 56 43

45 Marc Norton Ability: Novice Winner: Computer Moves taken: 52 Winner: Marc Moves taken: 55 Laura Whelan Ability: Novice Winner: Computer Moves taken: 47 Winner: Laura Moves taken: 46 Each of the testers managed to understand the rules and found the movement of the board pieces a simple task. When playing against the computer, some users found themselves selecting pieces that they just moved. This is because the system does not move the human player s piece on the screen until the computer moves also (although the computer recognises the human player s new position). Hence it appears to a user that the mouse click has not been detected by the computer, and so they try again. This is a known issue in the software that I had to advise the test users of. 44

46 9.3 Testing Evaluation From the testing performed on the system, there is a variation of results obtained for the computer opponent. The number of moves varies between 46 and 58 for the different games that were played. Although this may seem like a fairly large difference in result, there is one aspect that should be considered for the game. The number of moves it takes a player to finish in is highly dependence on their opponent. If a player makes either very poor moves (by not moving their pieces out quick enough) or very good moves (by blocking multiple jumps for the opponent) then it can take the opponent much longer to finish the game. With this in mind, I feel that the computer results are of a good standard for a novice player. The distribution of the results is actually very interesting, as most players managed to win one game and lose their other game. Out of the ten games played, the computer managed to win five of these, which I feel is good for the basic player that I had aimed to implement. Players tended to lose their first game in the test, but then would win their second game against the computer. This is not down to experience as all players had practice time playing against each other beforehand, but down to learning how the computer will respond to situations. 45

47 10. Evaluation of the System This section discusses how well the system performs the tasks it is designed for. We will consider the three main areas, the basic game system, the network feature and the computer opponent Basic Game Evaluation The basic game system consists of the GUI, the state of the player pieces and board spaces, the user interactions and move validations. The Basic Game is what is available to a user playing on the Practice Mode. Personally I feel that the GUI has a clean appearance to it, where the board is clearly visible and not overly distracting with fancy graphics, yet the pieces have an interesting appearance rather than a simple circle in one colour. The OO approach that was attempted for the board spaces and player pieces managed to work well. By having arrays to access each object, it meant that referring to objects was relatively simple, and using accessor methods to retrieve data from these classes also proved beneficial. It is possible that instead of requiring a board and a space class that there could have been just a space class, since once the spaces were initialised, the board class acts purely as a gateway between the main program and the space objects. However, by having it separate it does help to keep the code tidy and easy to understand for a reader. The user interactions with the system are relatively straight forward, being for the most part just the mouse pointer. This was the obvious choice of input, as using a keyboard would be inappropriate and awkward given the shape of the board. The keyboard is used purely for text entry, if a user wishes to enter a message into the message window. I feel that the mouse control is suited for the game, and for a player, the distinction between single and double clicks to perform multiple jumps works well also. 46

48 The move validation within the code is a fundamental part of the program, which without would cause the whole system to be useless. Therefore it was crucial that this performed well and without any errors. The method of how it finds available moves is well performed, by searching the neighbours of the given space. The use of arrays to list the neighbouring spaces proved to be a good idea, it in effect acts as a list of pointers directing where the next space is. This was necessary since the board has an awkward structure compared to simpler game boards such as Chess or Draughts. Overall, I am very pleased with the performance of the Basic Game system. It allows two or more human players to play together on one machine successfully. The only problems lie with features that due to time never managed to be implemented. The system was to have a timer for timing how long a player takes for their move. Also, the system was to have a high score table, with the players who finish in the quickest time and moves. This would have been especially useful for when the Network feature was to be added. Lastly, the system has no preferences that can be altered by the user. Options to switch on and off the timer, setting player names, and even loading different board shapes never became implemented, again, due to time, and the need to focusing on the other areas of the project Network Play Evaluation The network play feature allows up to six users playing the game on the Internet. This involved creating a Client class within the program that could be used for network communications, and also a Server application that can host the game information and allow communications to pass from one client to all other connected users. This would allow for game moves, commands and messages to be passed between all players so that they all experience the same game. The server managed to succeed in allowing up to six players to play a game of Chinese Checkers, along with passing commands and messages between 47

49 all computers. However, there are a few issues that I have with how the system operates in this mode. Firstly, I would have preferred to have made a fully functional server that could host more than one game. During design and implementation, I had considered this and thought of ways it could have been done, but it would have involved requiring an additional computer to act as the server, and developing a more advanced waiting room, where users connect to before playing the game. Instead, the server is now a part of the application that one player can launch from within the game and host the network game themselves. Then other users connect to their machine to play. I felt that a simple server was sufficient for the project, rather than creating a whole new system that would deal with multiple Internet games. Once the game is in progress there are no problems and it functions just as the Practice mode discussed in section The second main issue I have with the server is how games are finished. Once a game is over, it is assumed users will only want that one game, and will disconnect. In reality, some users may wish to stay on the server and some may wish to leave. Like before, this would have meant moving around all the pointers to the players, and may result in an awkward number of players, i.e. five players can not play, or the host of the server may wish to leave. This goes back to the centralised server idea, which would be better but much more time consuming and beyond the scope of the project. Related to the previous issue, the server also experiences problems when users disconnect from it. Leaving during a game will obviously cause problems for the other players, but it is problems related to how the server deals with it. I attempted to have it so that the client sent a disconnect message to the server, the server then replies giving the client permission to leave, then the server disconnects from the client then client disconnects from the server. The server seems to be left in a bad state when players leave though, and this affects other users who try to play on it. Since it is a server hosted by a player though, they can simply shut it down and create a new 48

50 server for players to connect to. This is one benefit of having it maintained by the actual players. One addition that was to be implemented into the system but was left out due to time restrictions was move validation on the Server side. This would simply check whether the move was valid at the Server before sending the move on to the other players. This would have been useful, especially if the centralised Server was created, as it would that Rogue Clients could not cheat. If a user had an adapted version of Chinese Checkers that does not check if the moves made are valid then all other users would be sent these false moves. However, if a secure Server could detect these false moves then rogue users could be banned from the service. With the Server being hosting by a user, they could have adapted the Server application also, so I felt this approach was only a major benefit if the Server had been a secure, centralised design. Overall, the server is capable of the tasks it is required to do. Clients are able to connect to it and pass information to all other connected users, and so a game can be carried out across the connection. However, it is perhaps not the best solution to the problem, which would have been a centralised server with more control over players connecting and disconnecting. As stated before though, this would have been beyond the scope of the project and the time allocated to this stage of development Computer Opponent Evaluation The Computer Opponent allows for a user to play Chinese Checkers against the computer. It plays to a novice standard, using a 3-ply Mini-max tree to give some insight into future moves but without taking too long to perform moves which would bore a player. From personal experience and from the user testing performed in Section 9, I am satisfied with the abilities of the Computer Opponent. From playing against it, it is clear that it thinks ahead, as some moves are made to position 49

51 pieces for a better move on the next turn. Similarly, some moves are made to block the user s strongest move (had the computer not have moved there). A serious issue I have with the Computer Opponent is that once a user has made their move, the display is not updated with their move until the Computer makes their move also. This means that a user sees their move and the computer s move made at the same time. A similar issue is that a user does not get to see the computer s actual move (their sequence of jumps), but instead they just see the new position. Both of these issues are to do with how Java repaints the Graphics object used to display the board. Despite attempts to rectify the problem, the system still updates the board after the computer takes its move. As mentioned, it is related to how Java processes Graphics, but I do intend to resolve this situation as it affects the feel of playing the game. An obvious improvement to this area of the game would be to add varying skill levels. These could be determined by looking further down a Mini-max tree. Although my initial aim was to create a novice computer opponent, I would have liked to have had the chance to create this skilled opponent. However, I found problems whilst using Java creating this tree. I attempted to write recursive code for creating the tree, but this failed badly and caused Java to have serious memory issues. This is due to the high number of possible moves available in any one go in Chinese Checkers. Because of these issues, the tree used in the game is actually hard coded to 3-ply, rather than recurring only three times. If a tree was to be extended much further, a hard coded version would become computationally expensive, especially considering the number of moves that would be held within the tree. Overall, I feel that the Computer Opponent is suitable for the project. It plays to a good standard and is capable of beating novice players. The processing that is involved is relatively quick for the task it is performing, and moves are usual made within 2-4 seconds by the computer. Obviously though, there is much improvement that can be made to improve the intelligence of the system. 50

52 11. Future Work This section details the aspects of the system that could be developed further, given more time to work on the project. It will also discuss the possibilities of expanding the system and its capabilities to focus on other real world problems Improvements for Chinese Checkers As mentioned in Section 10, there are areas of concern within the program, some of these are minor issues although there are some important issues also. As I intend to carry on and develop this program on further, after this project, my first area to deal with involves the Computer Opponent, and the repainting of Graphic objects. When a move is made by a user, their piece is not moved until the computer is ready to move also. This leads to users repeatedly clicking on the mouse because they are under the impression that the move has not registered with the computer. Also, when the computer moves, no black highlight circle is shown on the moving spaces because once the computer decides which move to make the actual move happens far too quickly. Attempts have been made to slow down each step, but still the Graphics are not drawn on screen. This is an issue with Java, although there should be a method to resolve the problem, which I shall continue to try and find. Whilst discussing the Computer Opponent, I would like to add levels of ability to it. As mentioned before, this will involve creating a complete Mini-max tree, which at present the system is incapable of. The memory issues with Java need to be addressed here, as whilst trying to create a large tree beforehand the system kept throwing Java Memory Heap errors. Again, I would have thought this problem could be rectified, but as of yet no solution has been found. 51

53 For the Network Play feature, I would like to create a dedicated server that can handle multiple games. It would involve having a dedicated machine to act as the server that all users connect to. From here, a user can choose to host a new game or join an existing game, all on the server machine. It would involve creating a much more advance GUI to deal with the waiting room aspect of the system (where a user is connected but not in an actual game). Since the system would be on a much larger scale, users may need to register with the system to protect their user name. Then their account could hold information of their game scores and records. The system would also be able to host the high score tables discussed earlier, which would hold records from all registered users. Issues with users connecting and disconnecting would also need to be addressed and fully working, since one user disconnecting could affect the communications of all other users playing. This is a task that I would like to pursue, given the required time to implement such a system. Finally, there are minor tweaks I would make to the actual game, such as adding a timer to tell a user how long their move has taken, and options for the user to change the game experience. These are features that are designed to please the user rather than improve functionality, but would still be suitable additions to the system Real World Applications The game of Chinese Checkers is designed purely for entertainment values, as all games are. However, the techniques and algorithms that the game is based on are much more valuable that this, and could be adapted to suit for real world problems. This section of the report is to discuss the possible uses of the methods used by Chinese Checkers. 52

54 An obvious first choice would be to focus on the Network side of the system. In effect, what we have created is a means for up to six people to communication over the Internet. Although not a new technology, this is the same principle that is used for chat applications such as MSN Messenger. These also have a server that a user connects to, and passes messages to other connected users via this server. Also, messages can be sent to multiple users in one chat conversation, like users of Chinese Checkers can do too. The only difference is the fact that in a chat application users send understandable English, whereas in Chinese Checkers, users can send messages of their own, but the system also send control messages without the users realising. When considering the game, and the computer opponent playing the game, it finds all possible moves and chooses the best one to satisfy its need. This is similar to ideas from Discrete Mathematics, such as the Travelling Salesman and the Chinese Postman algorithms. These are all path finding algorithms for travelling along each edge of a graph or to each node in a graph. (The term graph refers to a Discrete Maths graph, which is a collection of nodes joined together by edges or paths). By adapting the layout of the board, and setting the rules of how somebody can travel around, we could find all the possible routes to travel around a group of places. This could be designed for Couriers who need to deliver items to specific addresses, or to in-car route planning devices. In effect, the Chinese Checkers software simply has a set of rules of how something can move around, and then finds all the routes available based on these rules. Applying this to vehicles, we could state that they can only drive on roads, and then we could find all routes available to a destination. 53

55 12. Conclusion The project aim was to create a Multi-player Internet Game, using a game that is not so typically known. I created a game of Chinese Checkers since I felt this was an uncommon game that would also work well as an Internet game since up to six players can play in a game. The game has three modes of play, these being Network Play, Computer Opponent or Practice Game. I feel that I have successfully met the criteria of the project. The game is fully playable and recognises the rules of Chinese Checkers. In a Practice game, the system allows up to six human players play on one computer. In a Network game, the system allows up to six human players to play over an Internet connection. In a Computer Opponent game, the system allows one human player to play against a computer opponent. I feel that I have also gone beyond the aims of the initial task, as the implementation of a computer opponent was not asked for in the initial project specification. This was a task that was to be attempted if the rest of the system was completed successfully. There are, as mentioned in Section 11, areas within the project that I would like to focus on further. These are to either improve current aspects of the system to add features to enhance the user experience. There is also potential to use the system created in this project to develop further systems of use to the wider public. With both of these concerns in mind, I feel that the project can be extended further, and so I shall continue to expand upon it. If I had to take on this task again, there are a few changes I would have made to the approach I took. Initially, I broke this project down into three parts, the basic game, the network feature and the computer opponent. I feel this worked well; however, I could have planned for the interactions between each section to have worked better in the design phases. These issues only became apparent when implementation had begun for the Network feature, 54

56 which caused problems to arise due to my misunderstanding of Client/Server communications. This meant that whilst coding was to be taking place, I found myself researching networking techniques and building sample programs to try to understand networking issues. As a result, I now have a greater understanding of the topic area, which means that in the design stages I could plan for the interactions much better. Overall I am very happy with the result of this project. I feel I have vastly improved my skills in Java programming, and learnt techniques I did not know before, which will be of great benefit in future software development. I have also enhanced my knowledge of Network Communications and Artificial Intelligence, and have experienced how these ideas are to be put into practice in a real world application. 55

57 13. Glossary CRC GUI HTML IP MSN OO SDK UML Class Responsibility Collaboration Graphical User Interface HyperText Markup Language Internet Protocol Microsoft Network Object Oriented Software Development Kit (also known as Standard Development Kit) Unified Modelling Language 56

58 14. References and Bibliography 14.1 References A web-based version of Chinese Checkers, played to experience how a Computer opponent would play, and to improve my own abilities at the game throughout the project. Site provides general information on Chinese Checkers, such as the History of the game, rules, variations, and freeware software. Building an Internet Chat System: used for understanding Multithreaded Client/Server interactions. Also provided code samples that have been adapted for their intended use in Chinese Checkers Bibliography Title: Computer Game-Playing: Theory and Practice Author: M.A. Bramer. Published: Ellis Horwood, Title: Core Java 2: Advanced Features v2. Published: Cay S. Horstmann, Gary Cornell. Published: Prentice Hall PTR, Title: Java in Easy Steps. Published: Mike McGrath. Published: Computer Step, Title: JavaChess : a distributed chess game and intelligent opponent Author: Edward J. Donovan. Published: BSc Computer Science Thesis,

59 Minimax Explained: provides a general overview to the Minimax algorithm. Minimaxing and pruning with many players: provides information about approaches that could be taken for developing Minimax for multiple players. Alpha-beta Pruning: provides general information about Alpha-beta pruning and how this technique can be incorporated into the Minimax algorithm. Provides general information on Chinese Checkers, including a description of the game, a variations that can be played. Writing a Server side of a Socket: used for understanding how sockets work and the communications involved between a Client and a Server. Also provided ideas for early Server attempts. (All web sites were last accessed on 22 nd April 2006.) 58

60 Appendix A: Aims, Objectives and Work Plan This document was completed at the beginning of the Project. It gives detail of how the Project will be broken down throughout the year, along with the aims and objectives to be achieved on completion. 59

61 60

62 61

63 62

64 63

65 64

66 65

67 66

68 67

69 Appendix B: Mid-Term Progress Report This document was completed mid-point during the Project. It details the progress that has been made, along with the future work to be carried out. 68

70 69

71 Appendix C: User Guide This document is provided with the software, accessible via the Help menu. It gives a simple introduction to the game of Chinese Checkers, along with details of how to play and setting up a Network game. 70

72 Chinese Checkers User Guide Aim of the Game: Chinese Checkers is a game for 2 to 6 players, played on a six pointed star. The aim is to move your ten pieces from your starting point of the star, to the point that is directly opposite on the board. The game is turn-based, clockwise starting from blue, and on each turn, a play must make a move. There are 3 types of move that a player may be able to make: Single Step: This is where a piece moves to any vacant neighbouring space. Single Jump: This is where a piece jumps another (of any colour) to land in a vacant space on the opposite side. Multiple Jumps: Like above, but a piece can carry on providing there are jumps available and vacant spaces to land in. The first player to get all 10 pieces to the opposite point on the board is the winner. Tip: The fastest way to travel across the board is by performing multiple jumps. By trying to position pieces to transport other pieces across the board is a useful technique for winning the game. Bear in mind though, that any path that you can travel across, your opponents may be able to travel across also! 71

73 There are three types of game available within Chinese Checkers: Network Play: Played across the Internet with up to 5 other players. Computer Play: Played against the Computer in the 2 player mode. Practice Play: Played on one machine where a user can control all players (e.g. can be used for 2 players on one machine) Each of these modes can be selected using the Game menu at the top of the display. To play on the Internet, click Play Network Game, else click Play Local Game. Setting up a Network Game Once selecting Network Game, you will be asked if you wish to Host or Join a game. To Host is to start a new game where you set the number of players and users connect to you. To Join is to join an existing game that another user is hosting. If you choose to Host, you will be asked to select how many players for the game. Once doing this, the game will wait for the other users to connect. Note: the other users will require your IP address to connect to the game. If you choose to Join, you will be asked to enter the IP address of the Host. Once done, the game will attempt to connect. If successful, it will display the game details waiting on that Host. If you still wish to join, click OK. As above, the game will wait until there are enough players to play. During a Network game, you can communicate with other players. To do this, simply write your message in the command line at the bottom of the display. The message will appear in the message window on each player s game. Once the game has been played, to leave the Host simply click End Current Game in the Game menu. This will bring you back to the original empty board screen. 72

74 Playing against the Computer or in Practice Once clicking Play Local Game, you will see the following display: This simply allows you to choose whether to play against the Computer or in Practice mode. Also, it allows you to choose how many players for the game (Computer mode only allows two players). Once clicking OK, the game will load up to be played. At any time during play, you can click End Current Game to return to the original empty board screen. Controlling the Board Pieces To control the movement of the board pieces, the mouse is used. On your turn, by simply clicking the mouse on a piece will highlight it with a black circle. To move this piece, click on the space you wish to move it to. If performing a Single Step, then this will end your turn. If you are jumping a piece, the selected space will be highlighted. You can either make another jump from this highlighted space, or end your turn by clicking on the new space again. If during a jump move you decide to retract your move, click on the original piece. You can now select a new piece to move. 73