David Reade 99755629
Tim Kelly 50221221
For our project we have implemented a one player internet version of the popular strategy game Battleship. The game is presented as a java applet using AWT technology and incorporates images and sounds to create a more realistic gaming effect. We have used artificial intelligence techniques to create a "smart" computer player. This computer player was developed to mimic the way in which humans play the game to give it a realistic effect. We developed our computer player using the agenda class, specifically the stack class to generate children and decide next moves.
Researching this project involved familiarising ourselves with various aspects of java programming such as designing applets, creating graphical user interfaces, importing sounds and images and using both mouse events and mouse motion events. The basic layout for designing applets is well documented and easy to implement. Creating a working, visually sound graphical user interface was important to us, as this area is new to both of us, but it is an area in which we both wish to develop our skills. Along with the GUI we also wanted to branch into the area of programming that involves graphics and sounds as along with gaming, these are the areas on which we plan to build on for next year.
Our other objectives were to introduce ourselves to applets first hand and to gain some practical experience in implementing them and creating graphical user interface which were easy to use. We feel that this project has been of great benefit to both of us and has allowed us to develop our programming skills especially in the area of artificial intelligence and also in the area of web development.
This project has allowed us to work as a team to develop a relatively large scale project. This was our first time developing a program of this size and planning was essential in enabling us to reach our objectives. We developed a plan in the early stages and we tried to follow it as closely as possible. By setting weekly goals for ourselves we could keep control and ensure that we kept progressing towards a finalised version of the game.
Some of the aspects of this project prevented us from meeting each deadline but our ability to plan ahead and assess problems developed immensely over the weeks.
The project is programmed entirely in java as it was ideally suited to develop a small game to be run on the internet. It does not need to be installed directly on a machine as it is hosted on the web and the only requirement for viewing is that Jdk 1.2 is installed somewhere on the viewing machine. We developed five main java classes to create this project:
ComputerBattleshipPlayer -also contains Agenda class code
Each of these classes have specific methods, some of which are inherited. Each class serves a purpose in the overall development of this project. The classes are closely linked and we have tried to implement good OO programming practices throughout the project from start to finish. Each of these classes and their relation to each other and the program as a whole are documented in 2.1 System Architecture.
This applet contains two grids of 100 squares each, which are contained within an applet which is 450 pixels wide and 480 pixels high.
The init method of the applet is always called to allow the applet to prepare for execution. Within this class all the images and prepared for loading into the applet. The images and sounds are located in folders which are accessed via the parameter names given on the webpage
This is done within the makeGui method. It uses a gridbaglayout and displays the text window as well as the action buttons. has the action
The game starts off at mode_none and creates two players .It calls the makeGui method and then sets the mode so that the players can be created, one a human and the other the computer.
This class is responsible for graphically creating the grid sand all of the operations needed to be performed on those grids. Its methods are defined in the attached javadoc. This class imports from java.awt because its methods perform operations on the images of the grid. It also extends canvas which allows it to use all of the graphical tools for drawing. The main functions of this class are to allow for images to be placed on the tiles of the grid. By doing this we were able to assign ships to spaces and values to ships so that hits and misses can be recorded. The main functionality of the grid is to contain the game and contains the methods which are responsible for controlling the semantics of the game. Each grid is connected to a mouse listener so that the human player can both place his own ships on the grid and fire at the ships of the computer. The grid is responsible for deciphering whether or not the players have hit a ship or not.
3. BattleshipPlayer class
This is the abstract super class from which we derived our human class and our computer class. Its constructor and method details are contained in the attached javadoc. It allows the players grids be accessed by mouse events and motions. This is possible by the importing of the java.awt. Class specifically the mouseEvent,MouseListener and the MouseMotionListener. This class declares the methods responsible for mouse actions and handling shots which are used in the sub classes.
4. HumanBattleshipPlayer class
This class is derived from the BattleshipPlayer class. Its constructor and method details are contained in the attached javadoc. This class is responsible for dealing with the interactions of the human player with the game. It deals with generating the coordinates of mouse actions within the confinements of the grid, and handles some of the AI involved with the computers actions. We decided to allow this class and the computer class to handle each others shots on their own grids. When we start the game and take a shot it is the computer class who fires that shot at his own grid on our human players behalf and vice versa. This component is modelled on the real life version where one player relays his coordinates to the other and has his opponent handle the shot on his behalf. Primarily we got a version of the game working with only two instances of the human class. After we had created this class all the frame work was in place for the development of the computer class.
This class is also derived from the BattleshipPlayer class. Its constructor and method details are contained within the attached javadoc. This class was our main class used to develop the AI for the computer player. Besides handling shots for the computer player this class is responsible for generating valid and intelligent coordinates for the computers next move. It provides a number of methods which are responsible for checking the validity of coordinates generated and for generating the possible children of a successful hit by the computer. To implement AI within this class we also included the Agenda class, from which we used the stack class to hold data. We used the class node which implements the interface item to generate children. We chose this method because we are both familiar with the use of the stack class and the interface item. The AI techniques used within this class are discussed later in this manual.
Development of our project can be broken into five specific areas. These are the main areas under which each major part of the project takes place. When we started this project this is how we divided the project with each of these areas being a specific goal which we needed to achieve.
Designing the applet and all of the functions which can take place within the confines of that applet was a new concept to both of us as programmers. Applets and their development are very well documented so we started with designing a basic applet and learning how to use the features available to us. The primary issues here were with the layout of the applet and understanding the full working of all features. We had to learn about importing images and sounds and how they are used within applets. Once we had a basic layout for the applet and an understanding of how the grid would work within it we moved onto developing the graphical user interface to put it all together. However as development progressed and we started implementing the human player, we had to return to working on the applet to develop mouse actions to handle human actions within the grids of the applet.
This was one of the main areas within developing the applet. After we had developed a basic BattleshipGrid which could be filled with imported images we then needed to learn how to display what we had developed. The first thing which we developed for our applet was some buttons and the text area. When these were in place we could add the grids to the applet. We used the GridBagLayout which is the most versatile of all the AWT layouts and allowed us to specify exactly where we wanted to place our components. We were then able to display an applet of our two grids along side of the action buttons and the dialogue box.
After we had an applet up we had to represent the ships on the grid. To do this we had to develop a method to place the ships on the grid and to display the ships where they were placed. We started by writing a method to display a horizontal ship and when we were able to represent one ship and cover one ship we developed the methods to place the ships both vertically and horizontally and to display the ships where they were placed. We had to develop a method to prevent the ships from being placed on top of each other. At this stage of development we had an applet and could display our grids and randomly place our ships within them.
When we got to this stage we had to start development on the human player. This brought with it many problems mainly related to the mouse actions. Neither of us had on worked on developing mouse actions before and we had do coordinate them with the actions the user could perform within the confines of the grid. When we had a moving version of the human player we had to incorporate the methods with the grid class so that we could represent mouse events as either hits or misses. This was the first time that we had a working version of the game, although you could only play against yourself. When we had completed the human player we had to start development of the computer player.
Starting development on the computer player took some research. We decided on a number of ways to make it smart, but mainly we followed the pattern of human play. We had to find the right balance and not create a game where the computer could not be beaten. We looked at algorithms like MinIMax but these had little relation to this game because the game you play is not directly related to the game your opponent is playing ,i.e the moves you make on your grid cannot influence the moves or hits your opponent gets on his grid. This is the basic layout of our computer player.
The first feature that we had to develop was a random coordinate generator. This along with an array of possible coordinates ensured that we did not hit duplicate squares when we were taking random shots. At this point we had a one player game implemented but the computer player had no way of knowing if he had hit a ship or not.
The first thing that we had to set up was our stack to hold the coordinates. We also set up an interface item and a node class so that we could generate, store and retrieve children -from the stack. We tried a number of options before steeling for the layout that we have now. At first we were going to all the possible children of each square hit but after trying to implement this we found it inadequate so we only develop four children on the first hit. After this we hit south if its valid and if it's a hit we have a direction. If it's a miss we continue west of the original hit and then north until we get a hit. After we get a direction we generate one child each time. If we get a hit in a direction we generate the next child in that direction. If we get a miss we go to the opposite direction and proceed until the ship is sunk. South and West take priority so that so that when we change direction to North or East and we get a miss going North or East we don't change to South or West, we go random again. This behaviour mimics human play of the game and therefore makes it relatively fair.
When we were developing and testing the effectiveness of the computer player we had to account for numerous unseen scenarios. We had to develop a method to ensure that all shots took place were on the board. At first we did not generate children if they were off of the board but we later added invalid coordinates to the stack in order maintain the control structure that we had implemented.
The Main code used for developing the AI for the computer player is contained within three methods. Generate children is the first, which generates four children of each first hit, South ,West ,North and East. GenerateNewChildren is the next method. This method includes all the possible scenarios of the next hit. It decides on direction and checks validity of shots. Both of these methods are used in the generating of children after we have had a successful hit on a ship. GenerateHit is responsible for removing the coordinates from the stack, doing some checking and passing the coordinates to the human player to take a shot on the computers behalf. This method is closely related to the handleShot method within the human player. Between these methods is a fine web which we have developed in order to produce a "smart" computer player. The Computer players design can be broken down into stages:
WEEK 1: By the end of week one we had learned about applets and were able to develop and use basic features of applets. We had gathered research on applets and had developed the overall class structure which we used and to implement the game.
WEEK 2: By the end of week two we had learned how to develop basic GUI's using panels and buttons. We also had a basic grid class containing a hundred tiles of water images. We developed a gridBagLayout to layout to present the grids within the applet. At this stage we had an applet that contained the buttons which we needed and the blank grids.
WEEK 3:By the end of this week we had developed a grid class which was responsible for all of the operations of the ships within the grids i.e placing them randomly and painting over them with water. At this stage we had the framework available to create our players.
WEEK 4: By now we had a visual layout complete with graphics and sounds. We started development on the human player, developing mouse events and actions and tying all of this in with operations in the grid class such as taking shots and placing ships.
WEEK 5:At this stage we started development on the computer player. The computer player links closely with the human player so we continued development on both of these classes in order to achieve our goals. We had developed a computer player that could be smart but in testing we discovered possible scenarios which we had not accounted for so we had to continue development until these where taken care of.
WEEK 6 : We continued development on our players, fixing small details that only occurred in certain occasions. We had developed a game that could beat a human player and we started coordinating all of our documentation for presentation.
research in developing this project we referred to a number of books
on developing java applets over the web. It is from reading these
books that we developed the specifications of this project. We also
used the WWW and links are given to the sources of our information.
The Agenda class that we used was taken from last semesters AI notes
by Fintan Costello.