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: Battleship BattleshipPlayer BattleshipGrid HumanBattleshipPlayer 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.
1.Battleship
class
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. 2.BattleshipGrid
class 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. 5.ComputerBattleshipPlayer
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.
For
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.
|
- | 
Project Preparation
OO Models
Z-specification
1. Proposal
1. Functional
Spec.
1.
Object Oriented Metrics
1.
Object Oriented Models
|