Simulated Robot Football
David Goodyear, Jonathan Tanton Brown, Pete Wood
Department of Computer Science, University of Kent, Canterbury
dag6@kent.ac.uk, jdt4@kent.ac.uk, paw4@kent.ac.uk
Abstract
In recent years there has been a growing
interest in robot football with a number of
annual tournaments being held and an
international standard set of rules being devised.
These set of rules have largely been created by
RoboCup, an international joint project to
promote AI, robotics, and related fields. The
overall goal of RoboCup is:
“By 2050, develop a team of fully autonomous
humanoid robots that can win against the human
world champion team in soccer.”
This paper will discuss our design and
implementation of a set of programs used for the
simulation version of robotic football (i.e. where
the robots are simulated on computers rather than
in the real world). It will begin with a short
introduction to robot football and machine
learning before detailing our main aims and
objectives, decisions made during the development
cycle and how these were implemented before
drawing together conclusions about how well these
aims and objectives were executed.
1. Introduction
This project was chosen because of the
strengths in the team and our keen interest in
football. As well as a good knowledge of the Java
programming language (the language used
throughout this project) we all enjoy and follow
football making this an attractive and potentially
challenging assignment. There were a number of
different routes that could be taken as far as
simulating football players in programs was
concerned. We could have developed systems for
tactical and strategic coordination between players,
or focused more on visual processing techniques.
However, we decided that we would focus our
efforts on learning algorithms such as neural
networks or genetic algorithms.
We found the concept of programs that “learn”
highly appealing as it was something that none of
us had done before. The idea that we could write a
computer program that could learn how to respond
-1-
to different situations was fascinating. At a very
early stage in the project it was decided
unanimously that we would design and develop a
team of simulated robot football players using
neural networks that would recognise certain
patterns of play and respond accordingly.
2. Background
2.1. What is RoboCup?
The idea of RoboCup is to provide a standard
problem for researchers to explore artificial
intelligence and robotics where a wide range of
technologies can be examined and integrated. The
concept of a robotic world cup was first introduced
in 1993 and after a two-year feasibility test an
announcement was made on the introduction of the
first international conferences and football games.
In July 1997 the first official conference and games
were held in Nagoya, Japan and have been held
every year since at different venues around the
world and covered by the international media.
There are five main leagues in RoboCup; a
simulation league where teams compete on a
simulated playing field on computers, a small-sized
robot league, a middle-sized robot league, a four-
legged robot league and a humanoid league. Due to
time and resource constraints the simulation league
was the only option available to us.
2.2. The Soccer Server
Games of football are played on computers
using the RoboCup simulator called the soccer
server. The RoboCup soccer monitor (see figure 1)
allows visualisations of the game to be displayed
on the users screen using the X windows system.
The server is written to allow multiple virtual
soccer players to connect in an unspecified
computing environment with real time demands as
well as semi-structured conditions. This allows
researcher to focus their efforts on cooperation and
learning techniques rather than the details of
connecting.

Figure 1. The soccer monitor screen.
Matches are carried out in a server/client
fashion. Each client controls the actions of one
player while the server provides a virtual field,
simulates the movements of all the players and the
ball, sends messages to the clients and makes sure
the game is played within the rules. Each client
must connect to the server through a port and
communication is carried out via UDP/IP. The
server sends messages to each client/player that
tells them what they can see, hear and sense. The
client sends messages back in response to this data
and tells the player what to do, making the client
program act just like the players brain.
3. Aims
Our primary aim of the project was to produce
a team of players that were capable of beating all
other teams being developed by students at the
University of Kent. Our players would implement a
neural network in order to learn about the
opposition so the more games they played the more
our team would improve. It would also allow the
individual players to learn during a game, thus
improving the chances of winning.
However, as will be explained further in this
report, it was not possible for the neural network to
be fully implemented and we therefore had to
choose another approach. Our decision was to
create a rule based system that would use genetic
algorithms to learn, with our overall aim remaining
the same, i.e. to create a team of players capable of
beating all other teams being produced by students
at the University of Kent.
-2-
4. Preliminary Investigations
4.1. Understanding the Server
Before detailing the steps we took in order to
implement the neural network it was important that
we understood the soccer server and the messages
this would send, including the timing and the
content. It was vital this was understood in some
detail as the project would depend on the
successful parsing of information and making sure
the right values were sent to the neural network.
We therefore consulted as much documentation
about these messages as possible. This proved to be
quite difficult as the documentation that was
available was somewhat dated and different
protocols were attainable. The only way to find out
exactly what we were being sent was to connect to
the server and receive messages sent to us. Below
is an example message:
(see 43 ((line t) 6.2 -17)
((ball) 16.8 15))
The first piece of information we are told is the
type of message it is, in this case a “see” message.
This is then followed by the cycle time, “43” and
then the different things the player can see. In this
example the player can see the top line, “line t” at a
distance of 6.2m and a direction of -17º and the
ball at a distance of 16.8m and at 15º. This is a
fairly typical message, although they are generally
much longer as the player can usually see more
things.
Each half is split into 3000 cycles, each cycle
lasting 100ms. This makes the half of a game last
five minutes. A player is only allowed to send up to
three messages per cycle, but they usually only
send one (only one kick, dash, turn or turn_neck
can be sent each cycle). The server sends “see”
messages and “sense” messages at different
intervals, with “hear” messages being sent at any
time. “See” messages are sent every 150ms and
“sense” messages sent every 100ms. It was
important we understood the timings correctly as
we required our players to make decisions with the
most up to date information available to them, and
we also had to make all the decisions and send the
message within one cycle.
4.2. Protocol Versions
Because RoboCup has been around for several
years we encountered problems with the different
protocols available. The protocol we initially began
to use sent the same data but the “see” messages
were slightly different. In version 9 of the protocol
the server (using the previous example) would
send:
(see 43 ((line t) 6.2 -17)
((ball) 16.8 15))
However, we changed to version 7 as this was
what the RoboCup manual used. In doing so the
messages were sent slightly differently:
(see 43 ((l t) 6.2 -17) ((b) 16.8
15))
The words “line” and “ball” had been replaced
with letters - “l” and “b”. Although this was not a
major problem it became a hindrance as some of
the first code we wrote was based on version 9 of
the protocol and when we changed to 7 our code
fell over.
4.3. Choosing a Learning Algorithm
There were a few options open to us when it
came to choosing a learning algorithm and we
narrowed it down to two: Neural networks and
genetic algorithms.
4.3.1. Neural Networks. A neural network
consists of a number of interconnected neurons
called nodes. They work by inputting data into the
input nodes and processing these through the
network to the output node. The number and
strength (the weight) of the connections between
the nodes determines the final output. The theory is
that the neural network works in the same way as
an incredibly primitive biological brain. A human
brain however contains billions of neurons and
connections so even if scientists understood fully
the dynamics of human brains it is still beyond our
computing capacity to simulate them.
A neural network typically has three layers; the
input layer, the hidden layer and the output layer:
Figure 2. A simple neural network
-3-
In this simple example there are just two input
nodes and two output nodes, with four hidden layer
nodes. Input values are entered at the input nodes
and processed through the network. As the values
pass through each connection they are multiplied
by the associated weight, a number between 0 and
1. The summations of these weighted values are
worked out at each node and if a threshold value is
reached they are passed onto the next layer, until
eventually there is a value in the output nodes (see
section 3.1.1. in the corpus of material).
Neural networks can learn through a number of
techniques, all of which involve changing the
weights associated with the interconnections
between the nodes. They are used for pattern
recognition amongst other things. They have three
main advantages:
1. They have the ability to learn through
example
2. They are more fault tolerant than most
other learning algorithms
3. They are more suited to real-time
operations due to their high computational
rates.
4.3.2. Genetic Algorithms. Genetic algorithms are
inspired by Darwin’s theory of evolution. The
algorithm begins with a set of solutions to a
problem called the population. Solutions from one
population are taken and used to form new
populations. It is hoped that the new population
will be better at solving the problem than the old
one. The population that is chosen to “reproduce”
is the population that provides the best solution to
the problem, much like survival of the fittest in
biology.
A basic genetic algorithm has the following
steps:
1. Generate a random population of n suitable
solutions
2. Evaluate the fitness of each solution in the
population
3. Create a new population by selecting the
best two performing solutions and combine
them to produce offspring. Then mutate the
offspring slightly and place them in the
new population.
4. Use the new population and run the
algorithm again.
5. If you are satisfied with the results stop,
else go to step 2.
Genetic algorithms also have three main
advantages:
1. They converge from a random population
to a number of solutions
 2. They do not rely on any assumptions or
prior knowledge of the search space
3. A genetic algorithm search runs based on
probabilistic rules instead of deterministic
ones.

4.3.3. Our Decision. We decided to implement a

neural network as the learning algorithm our
players would use. Other groups working on the
same kind of project at the University of Kent had
chosen to use a genetic algorithms approach and
we thought we would be more unique by choosing
this. One of the advantages of a neural network is
that is suited to real-time operations and the
decisions our players make would indeed be in Figure 3. The structure for message parsing
real-time. Also, the fact that neural networks were
computationally fast was also a factor in our 5.2. Implementing the Neural Network
choice, as we knew decisions would have to be
made fairly quickly as cycles only lasted 100ms. As with most neural networks designed in
Additionally, none of us had any prior knowledge software we decided that we would have three
of neural networks and we liked the fact it would layers; an input layer, one hidden layer and an
be a challenge. output layer. Initially we produced a Neuron class
that represented each neuron in the network and
5. Technical Implementation Synapse class that represented each connection
between the neurons. The class Neuron would take
5.1. Message Parsing in all the values passed to it, sum them and check
whether the summation is greater than the
threshold value. If it is greater the output of this
The first thing we needed to consider was how
summation can be passed to the next layer. Each
to handle the messages we were sent from the
Synapse class would simply take one input value
server. As we were being sent three different types
and multiply this by the weight associated with it to
of messages (see, hear and sense) we decided that
give an output. However, after some testing we
it would make more sense in having three separate
found that this implementation was much too slow.
classes to deal with each, since we received them at
Even on a much simplified network that had just 18
different times. We created a SeeBrain for see
input nodes, seven hidden nodes and four output
messages, HearBrain for hear messages and
nodes it was taking well over 100ms just to create
FeelBrain for sense messages. A further class was
the classes and process the data through. After
written to receive the messages and pass them to
more testing we found that it was the creation of all
the correct brains. This was called SensoryInput.
the classes that was taking the most time. With 18
Once the individual brains have the message it is
input nodes, 7 hidden nodes and 4 output nodes
their job to take the relevant information and pass
there were 18x7x4 Synapse classes being created.
this onto the main PlayerBrain where the neural
With the other node classes this meant we were
network would be implemented (see figure 3).
creating 533 classes before we had even made
The three brains all work in generally the same
calculations. With the size of the network only
way. They take in the string that is given to them
going to increase we needed to think of another
by the SensoryInput class and break it down into
possible implementation.
substrings by looking at the where the brackets are
We then decided to model the different layers
located. These substrings are then broken down
of the neural network as arrays. This would
further until eventually it has the values for the
eliminate the large overheads of creating hundreds
different objects the player can see. These are then
of Java objects into just creating one. We also
fed into the neural network as each possible object
decided to make the network even simpler with
seen is an input node.
only two input neurons, two hidden layer neurons
and two output neurons. We hoped that with this
simple network we could learn a couple of
situations and grow the network from there. The
two input values we choose were the distance and

-4-
direction of the ball, and the two values we wished
to output were the turn value (which direction the
player turns) and the dash value (how fast the
player runs):
Figure 4. The 2x2x2 neural network
To create this small network in Java we created
a number of arrays. The first was called
neuronTypes, and this was used to identify which
input neuron the value for the balls distance and
direction should be loaded into. We then created a
neuronOutputTypes to extract the correct output
value. These arrays were of String type, but we
also required arrays that would handle the actual
values, so we created the output layer, a one-
dimensional array called outputLayer, and two
two-dimensional arrays called inputLayer and
hiddenLayer. The reason inputLayer and
hiddenLayer were two-dimensional was so we
could store the value and the weights associated
with that neuron in the same array. This enabled us
to save valuable time during the processing stage.
Instead of taking well over 100ms to process
data through the network it was now taking
nanoseconds. We then tested to see how long it
took to parse the messages and then process the
network. We found it took around 2 or 3
milliseconds almost every time, but occasionally it
would jump to 30 or 40. We discovered the reason
for this was that Java did its own garbage
collection automatically when a certain amount of
memory was being used, so every now and then it
would take time out to clear this. It was decided we
would manually perform our own garbage
collection every time the messages were processed
through the network. This increased the average
time to parse and process the messages, but it
meant that this whole process never took more than
about 10ms.
5.3. Backpropagation
The backpropagation algorithm starts by
initialising all the weights in the neural network to
random values, usually in a range of -0.5 to 0.5.
The data is then fed through the network to give
some output. The algorithm works by assuming
you will know what you want at the output nodes
and therefore what you actually get will have an
-5-
error. If you wanted to have an output of 30 and
you get an output of 50 you have an error of 20. It
is this error that leads to the next phase which gives
the algorithm its name – the errors are fed back
through the network and changes are made to the
weights of the nodes depending on how much that
node contributes to the error at the output. The
algorithm repeats this process until the outputs
produced for the training data are sufficiently close
to the desired outputs; in other words until the error
is sufficiently small (further explanation is given in
section 3.1.1. in the corpus of material).
For the backpropagation algorithm to work you
must first train it using training data. Since we only
had a small network to begin with we decided that
we would train the network to recognise the
following simple situation:

If the ball is greater than 20m away turn
towards it but don’t run

If the ball is less than 20m away turn and
run towards it
After implementing the mathematics of the
algorithm we began to train the network somewhat
unsuccessfully. We had a number of problems, one
of which was to do with normalising our inputs.
We were advised to use input values of between 0
and 1, but the distance of the ball could be anything
up to 160m away, and the direction of the ball
could be from -180° to 180°. We decided we would
therefore normalise the inputs by dividing them by
the maximum possible error we could receive at
the output nodes, being 160 for ball distance and
360 for ball direction.
Another problem was to do with the sigmoid
function that was required during the
backpropagation algorithm. The problem here was
that it would never get to negative numbers. There
were a couple of ways round this. Firstly we could
have used another version of this function that
allowed for negative values called the tan sigmoid,
but eventually we just worked around the problem
by assuming we would never use negative
numbers. For example, if we had to turn -10° we
would simply turn 190° as this amounted to the
same thing.
We eventually managed to get the neural
network learning this one situation after around
500 cycles through the backpropagation algorithm.
Now we knew the mathematics was working we
attempted to learn every combination for ball
distance and direction – all 57600 (160*360) of
them. Here however, the algorithm did not work as
we had hoped. Instead of learning the two rules we
had told it, the network seemed to just take an
average of the maximum errors we were giving, as
Dash converged to 80 (maximum error of 160) and
Turn converged to 180 (maximum error of 360).
We consulted a neural network expert, Dr.
Konstantinos Sirlantzis, who showed us that there
was more than one way to teach a neural network
using backpropagation; an online method and a
batch method. Online means you backpropagate
every time data is processed through the network,
whereas batch means you run all the training
patterns and sum the errors to find an overall
average error and then backpropagate using this
average. We tried them both but still the network
failed to learn, more often than not converging to
the average of the maximum error.
After this failed we assumed there must be
something wrong with the code we had written so
we went through it line by line and calculated each
weight update manually to make sure it was doing
exactly what we wanted. A couple of mistakes
were found; we were applying the sigmoid function
twice to the same value and there were brackets in
the wrong place, but other than these small typos
the mathematics worked as we planned and even
after fixing these mistakes it still was not learning
the patterns we presented.
We were introduced with the following
problem: Should we continue with the neural
network which was the backbone of the client
programs we had written or should we consider a
different learning algorithm? We decided to give
ourselves a deadline on the neural network and if it
still wasn’t working by this date we would be
forced to consider some other implementation,
likely to be some kind of genetic algorithm.
In the remaining weeks of using the neural
network we went through our code with Dr.
Sirlantzis but he could see nothing wrong with how
it was implemented. In the backpropagation
algorithm there are many different variables we
could change. The learning rate for example is one
parameter used and we altered this from values
such as 0.001 to 2000, but this didn’t seem to have
any effect. We then tried changing the number of
hidden layer neurons in the network from two to
higher numbers because we thought that maybe
there were not enough routes through the network
for all the combinations of patterns to be learnt.
After weeks of tweaking and testing the
network simply was not working and we decided
we had to change our approach dramatically and
implement a rule based client that used a genetic
algorithm to learn.
-6-
5.4. Synchronisation Issues
While we were developing the neural network
not much attention was paid to the synchronisation
of the threads we created. We always knew this
would have to be done but we thought it would be
better to clean up the code and synchronise it when
the neural network was working, but since it never
did work properly we decided to implement this
before we continued with the genetic algorithm to
save any more work in the future.
Two threads are created by our program, one of
them being the PlayerBrain and the other
containing the smaller brains and SensoryInput
class. The main motivations behind synchronising
the threads were two fold: Firstly we wanted to
make sure we only sent a maximum of three
commands per cycle (this was the maximum
number allowed by the server) and secondly we did
not want to be in a situation where we were reading
and writing data on the same arrays. We had to
create a semaphore to ensure that decide() - the
method used to make the decisions - was blocked
until told to run. Since sense body messages are
sent every 100ms (the same time as one cycle) we
agreed this would be used to call decide().
However, there was another problem in that see
messages were sent every 150ms, which meant that
every third cycle we would have two messages
being sent to us. Since we wanted see messages to
be loaded into the arrays first we had to call
decide() and then sleep for 15ms and use a second
semaphore to block until all the see parameters
were loaded. This would ensure that decisions were
not being made on the previous cycle’s
information.
5.5. Implementing Genetic Algorithms
The approach we took with the genetic
algorithm was to design the player so he could
recognise different situations. In each situation he
would have some actions, but the genetic algorithm
would be responsible for learning what value the
action should take. For example, if the player is in
a situation where he must turn and then run, the
genetic algorithm does not actually change the fact
that the player will turn and run, but it will
determine how fast and what direction the player
will take.
The first step therefore was to write down all
the different situations we wanted our players to
recognise and then code them. This was different
for each type of player - midfielder, defender, etc
and proved quite a hard task in itself. We spent a
lot of time testing the code to make sure each
situation was being recognised correctly. It was
here that we noticed there was a problem. The
player primarily uses what he can see to work out
the situation he is in, but when the information is
loaded into the arrays, if something cannot be seen
this piece of information is not updated and
therefore the array could hold old information. We
solved this problem by setting a default value for
all the elements of -999. Therefore the player knew
he could not see an object if the value stored for it
was -999.
The second step was to implement a
mechanism that would ensure the players only sent
a maximum of three commands per cycle. This was
done by creating a linkedlist of length three and
adding commands to this. The first command
would be taken and sent to the server and the next
cycle the second command would be sent. This
ensured only one action command was sent per
cycle. The only time the player made a decision
was when the arraylist of commands was empty,
thus making sure we only queue a maximum of
three messages (there can only be one kick, turn,
dash or turn_neck command per cycle, but say
messages are allowed to be sent as well as any of
the previous ones). Another linkedlist of length
three was created for say messages. This meant that
both action commands and say commands could be
sent in the same cycle without exceeding the
number of messages per cycle the server allowed.
The next stage in implementing the genetic
algorithm was to create an array, where each
element refers to a specific dash, turn, kick or
turn_neck value. In accordance with the process
outlined in section 4.3.2. of this document we
would set all the values in the array to a valid,
random number.
Once this is complete we need to implement a
scoring system. We planned to complete this by
having a kind of “fantasy football” scoring system
where the coach would rate the players depending
on how well they play. For example, ten points
would be awarded to a player who scores a goal,
two points for a completed pass etc. This way we
rate the fitness of each player and can now select
the two best players ready to produce the next
generation of players.
However, since the failure of the neural
network time was always against us. After we
coded the players to recognise the different
situations they were in we made the decision to
stop working on the genetic algorithm as we knew
we would not have time to implement, test and
then train it. This was disappointing because we
made good progress in the two months we worked
-7-
on it, and felt that had we had more time we would
have done a good job of it. However, we felt the
time would be put to better use by tidying up and
documenting the code we already had and
beginning the documentation.
5.6. Optimisation Issues
With cycle times being just 100ms it was
obviously important that our program executed
everything it required and sent the messages to the
server within this time. Even though we changed
the learning algorithm the overall structure of our
program remained the same, with the smaller
brains parsing the information and loading the
values into arrays which will be used to make
decisions. This meant that optimising the brains,
especially the see brain which was used most often,
would save processing time whether we used a
neural network or genetic algorithms.
The main operation the see brain did was to
break the message up into substrings (see section
5.1. of this document). However, this is time
consuming because a lot of comparisons were
being made. The optimised version was almost
rewritten from scratch – instead of breaking the
string down into smaller and smaller substrings it
went through the message indexing the string. This
meant it only had to go through it once and index
where specific brackets were. Depending on where
these brackets were and how many parameters
were contained within meant we could identify
which objects the player could see and extract the
necessary information.
This new indexing of the see message instead
of breaking it down meant that the time it took to
process one message went from an average of
about 10ms down to an average of about 3ms.
We also went through the PlayerBrain to
optimise the different loops that were required and
tidied up the code to make it as efficient as
possible. After all these changes were made we
managed to decrease the total processing time,
from when we initially get the messages to sending
our own messages to the server from 30ms to less
than 1ms.
6. Conclusions
Obviously we did not achieve our major
objective for this project which was to implement a
neural network so our players could learn about the
opposition and progressively improve their
performance. We were very disappointed about this
because we spent such a long amount of time on
this but were unable to fully diagnose why the
network failed without risking missing the
deadline. Neither our supervisor nor Dr. Sirlantzis
could find any problems so it remains a mystery.
Maybe we missed some vitally important detail or
didn’t present the training patterns in a way that
allowed the network to learn. However, we did
choose a challenging project and one of the risks
we identified was not being able to implement the
neural network, which unfortunately proved to be a
reality.
Since we spent such a long time on the neural
network we had left ourselves a tight schedule for
learning, implementing and training a genetic
algorithm. As we progressed with the algorithm we
began to accept the fact that the algorithm was not
going to be fully implemented. It was frustrating
because we quickly learned how they worked and
strongly believed that had we chosen this approach
over the neural network we would have made a
really good job of it. As it turned out we had too
little time and only managed to implement the
players recognising the situations they found
themselves in.
Although we did not meet our aims for the
project we don’t feel that it was a wasted effort.
We all now fully understand neural networks and
genetic algorithms in some detail, and all learnt
from the experience. If we were to begin the
project again we would seriously consider
implementing a genetic algorithm from the start.
The message parsing and dealing of messages
would be kept the same but after progressing with
both learning algorithms as far as possible we
thought we would have done a better job with the
genetic algorithm. We also agreed that we should
have paid more attention to the synchronisation of
the threads before we began working on the neural
network. A lot of time was spent on this after the
failure of the neural network and the time we
would have saved by completing the task before
starting on the network would have been valuable
as we began to reach the deadline.
As far as future work is concerned there are
various routes we could take. Finishing the genetic
algorithm would obviously be the first thing to do,
but we would have liked to implement a more
useful coach. The coach we actually managed to
implement was quite primitive but eventually he
would have been necessary to record how well the
players were doing and so be able to choose the
players that could win the game (natural selection)
in order to produce offspring.
-8-
7. Acknowledgements
We would like to firstly thank our project
supervisor Colin Johnson for his continued input
and support for the project. Colin helped in
numerous ways, including suggests about how we
implement the neural network using arrays instead
of classes, as well as providing us with the
backpropagation algorithm. He was always
available for meetings and discussed our problems
until he was sure we understood how to overcome
them. Additionally he was a tremendous help with
respect to the genetic algorithm and the write up of
documentation, including this paper.
We would also like to thank Dr. Konstantinos
Sirlantzis for his much appreciated help while we
struggled with the neural network. Kostas never
hesitated when we asked to meet with him and
discuss our implementation of the network, and he
was always available for further meetings and gave
us invaluable insights into the workings of neural
networks. Without his help we would not have
understood our problems with the network as well
as we did and he was genuinely disappointed when
we had to abandon the network for a different
approach.
8. References
[1] RoboCup Official Site
http://www.robocup.org/
[2] Neural Networks: Computerized Brains
http://www.glencoe.com/norton/n-instructor-
/updates/1999/8299-4.html
[3] Introduction to Genetic Algorithms
http://cs.felk.cvut.cz/~xobitko/ga/
[4] Introduction to Backpropagation Neural
Network
http://www.geocities.com/neuralbug/neural_ne
tworks.htm
[5] Bentley. P. J., Digital Biology. Simon &
Schuster, 2001
[6] Coppin, Ben. Artificial Intelligence
Illuminated, Jones & Bartlett, 2004
[7] Müller, Berndt. Neural Networks: An
Introduction, Berlin, 1990
[8] Barnes, D. Object Orientated Programming
with Java, Prentice Hall, 2000