The PacMan Project

weaverchurchΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 4 χρόνια και 10 μήνες)

371 εμφανίσεις

The PacMan Project

A Programming Projec
t for Software
Construction, 1


by Per S. Laursen


This projec
t concerns a small Java program, which implements a very simple version of the



game. The game has been written u
sing the

Java environment, which you
must also use during the project. During the project, you will have to discover the logic of the game,
examine and modify the existing code, and finally add new code to the game. The details of the
projects ar
e given in the
Project Steps


Project time frame

The project will run during all
Software Construction

classes in week 17
, and during Monday in
week 18

pril 20

). That is, you have 15

classes to work on the project.

It is up to you if

you want to use more time on the project, but you are not obligated to do so. However, the project

be handed in at the end of the
Software Construction

classes on


Project groups

It is
strongly encouraged

that you do this project in grou
ps of

. Groups of three
s are

allowed. If it is absolutely impossible for you to find a partner, you are allowed to
do the project individually.

Project structure

It is very important to understand that this project is an

project. This means that you
should work on the project during the given time, and then hand in the work you have completed,
even if this is only a few of the first steps. On the other hand, if you feel that you have “completed”
the entire project within
a few hours, you should try to think of something more
to do in
the final steps of the project.

The overall purpose of the project is to evaluate your current skill level
Software Construction

Project format

When you hand in the project
, t
wo parts must be delivered:

A report

Java code

The report can follow the report template available in BlackBoard, but you are not obligated to do

it is only meant as a help to those who find it difficult to structure the report properly.

The Java code

should simply be the final version of your PacMan scenario (see
Appendix A: A

duction to GreenFoot
), including any modification and additions
you have made to the

I will prefer that you hand in your material on electronic form

there i
s no need to print out the
report. You can hand in the material to me on a USB memory key, a CD/DVD, or send it by e
. However, I must receive your material
no later than April
, at 14
. If you
d the material by e
mail, I must confirm the reception of the material.

Partner evaluation

Ideally, both partners in a group should contribute equally to the project. Try to avoid that one
person performs most of the work, while the other person remains
passive. If you feel that the work
on the project does not proceed as it should, feel free to contact me, so we can have a talk about the
When the project has ended, you can also fill out a
partner evaluation form
, if you want
to mention any issu

regarding the project work.

The partner evaluation form can be found at

Project steps

The project is

divided into several
, starting out with some fairly easy steps, and gradually
progressing to some more challenging steps. The purpose is to make sure that everybody is capable
of completing at least a few of the steps. However, I do

expect that
everybody can complete all
of the steps, within the given time. You should complete as many steps as possible, but when the
given time has passed, you must hand in the result of your project, no matter how many steps you
have completed.

Step 0

ng the Greenfoot environment

The PacMan game has been created using the GreenFoot programming environmemt, which you
must also use during the project. See the

Introduction to Greenfoot

for more details on
Greenfoot. So, the natural first step is s
imply to install GreenFoot on your computer. You can
download GreenFoot from BlackBoard, where is it found under
Construction, Projects,
. Note that GreenFoot is a fairly
small program, only about 5 mb.

Usually, Greenfoot will
be installed in the

Once you have GreenFoot up and running on your computer
, you should download the PacMan

from BlackBoard, where is it found under
Construction, Projects, Pacman
. If you
are using your own computer, you can just put the PacM
an scenario in
. If
you are using a school computer, it is a good idea to put the scenario on your H:
drive, or on a USB
memory key instead.

When the PacMan scenario is installed, you can open the scenario from Greenfoot. Click on
ompile all”, click on “Reset”, click on “Run”, and start playing the game!

Step 1

Understanding the logic of the game

When the PacMan game is running, your first task is to
discover the logic of the game

looking in the Java code. The game is q
uite simple; use the arrow keys to move PacMan around in
the world, and see what happens to him. In general, the game can be won (PacMan turns into a
trophy), or lost (PacMan turns into a skull). During the game, PacMan can change color. Try to
work out wh
at the conditions are for the behavior of PacMan, related to the objects he meets in the
the logic of the game in the report

(Tip: PacMan has some
health points
, which change when PacMan eats something…)

Step 2

From logic to Java code

verything PacMan does is a result of the Java code in the program. The task in this step is to
examine the actual Java code in the program, and see how it relates to the logic of the game

In other words; identify those parts of the code which implement a
specific part of the logic. For
instance: PacMan changes color according to some specific logic, which parts of the code i
ment that logic? Do this for all parts of the logic, and
describe your findings in the report.

Step 3

Code modification

By no
w, you should have a fair understanding of the Java code in the PacMan program. This should
enable you to
do some simple modifications of the program
. Modify the code in the following


Make it a bit harder for PacMan to win the game, by changing

the points awarded (or
subtracted) for eating the various objects in the world
. You might also change the condition
for winning the game


the creation of objects
in the PacMan world,
so that more dots, cherries and ants are
created at the start of t
he game

Modify the movement of PacMan, so he will move two squares instead of one, if the Space
bar is held down when the arrow keys are used

In each case, you should
describe the changes you have made to the code in the

Step 4

Adding new subc


The next step is to
add two entirely new subclasses

to the PacMan program; a

subclass and a

subclass. Both of these subclasses must inherit from the

class. The behavior of the
new classes are as follows:

: If PacMan eat
s a
, his health points are restored back to the value it had when the
game started, no matter the current value of the health points

: If PacMan eats a
, he dies immediately!

Both of these classes are “passive”, in the sense that objects of t
hese classes do not move around in
the PacMan world.
Obviously, we need to put some


objects into the PacMan world
initially. Set the probability to populate a cell with a

to 3

%, and the probability to populate a
cell with a

to 8


In the report, describe the new subclasses, and the changes you
needed to do to the existing classes

Note:You can find graphics for the


class in the “images” folder in the PacMan
scenario, but you are also welcome to use your own…

Step 5

Adding a new subclass (active)

We now extend the set of actors with a

class. A

is an actor which

like in the real

chases PacMan. If a

catches PacMan, PacMan dies. If a

meets an object (like
), the object should be r
emoved from the game, making it harder for PacMan to win the game.

Adding too many chasing ghosts may make the game too hard… A major challenge here is of
course to figure out how a

should move around in the world.

Step 6

Improving the code

The st
ructure of the code in the PacMan game is not ideal, and having to add new subclasses to the
code may have made this even clearer.
Look through the code for places to improve the code
Remember that a good programmer tries to avoid having the same code in
a program

once! This can be avoided by rewriting some methods into more general methods, and also by
adding more base classes to the code.
For each improvement you make

to the code
, describe
why and how you have made the improvement

Step 7

hanging the game

Compared to the original PacMan game, this game is obviously extremely simple. The game can be
made more interesting in a lot of ways. Below are some suggestions:

Change the behavior of the Star
, such that when PacMan eats a
, he is al
lowed to eat
ghosts as well. Of course, the ghosts should then change the behavior from chasing PacMan
to fleeing from PacMan, just like in the original game. Also, this state should only last for a
certain period of time, after which the game returns to t
he state where PacMan is c

and killed

by ghosts.

Add obstacles to the world

In the real game, PacMan cannot move freely, since there are
walls outlining various routes in the world. If you add obstacles to the world, the code for
handling the mov
ement of PacMan (and ghosts) becomes more complicated, and the code
for laying out the initial objects must also be modified.

Game resolution
. The PacMan world is a “cell world”, with a 12x12 grid of cells, each cell
being 40x40 pixels. This makes the move
ment of objects quite “jumpy”. Making the
movement more fluid will require to run the game in a different resolution, perhaps with
each cell being just 1x1 pixels. Doing this will require

changes to the code…

Add a score board
. It would be nice to be
able to keep track of the current score

PacMan. This will require that you work with drawing of text

see the GreenFoot


documentation for more information on this.

Change the objective of the game

Instead of winning the game at a fixed score, you
e.g. change the objective to be to score as many points as possible. In order to do this, the
world should be re
populated once all objects with a positive score have been eaten. This
will introduce “levels” or “stages” into the game.

For all the cha
nges to the game that you decide to make, you should describe:

How the change affects the logic of the game

How the existing code was modified

The new code added to the program

You can do as many changes to the game as you wish, and you are not limited to

the changes
described above. Be creative! But also remember to be realistic


: A short introduction to Greenfoot


environment is a
programming environment well suited for making two
dimensional games and simulations.

The i
ntention of Greenfoot is to give the user a much simpler
“interface” to Java programming, than the sometimes overwhelming NetBeans interface. If you
examine the menu
in Greenfoot, you will see that

the number of actions you can perform
is very li
mited. You can basically just open a “scenario” (like a “project” in NetBeans), enter your
code using a rather simple editor (see later), and finally compile and run your code.

Note, however, that Greenfoot is still a full Java programming environment. Th
e entire Java library
is still available for you to use. In addition to this, Greenfoot provides five extra library class, the
two most important classes being



class is the class which takes care of management of the “world” you
r Greenfoot project
revolves around. As mentioned before, Greenfoot is well suited for making programs which have a
dimensional visual interface, like a simple game or simulation. The

class contains a
number of methods for handling such a world.
In an actual program, you will most probably create
a class which is a subclass of
, which will contai
n code specific for your own pa
“world”. If you double
click on the

class box in Greenfoot, you are taken to a web site with
ion of the methods available in the


In Greenfoot, any world will be inhabited by
. Any object which is to “live” in a Greenfoot
world must be a subclass of
. Again, if you click on the Actor class box in Greenfoot, you are

taken to

a web site with documentation of the methods available in the

class. The actual
behavior of a specific

must of course be provided by you. In particular, all

implement the method
, which is called by Greenfoot to invoke the beh
avior of the actor.

The simplicity of Greenfoot does come at at small price. The editor, compiler and debugger are not
as sophisticated as they are in NetBeans, which may sometimes make it a bit more tedious to enter
and debug code. However, if you follow

the advice about
compiling often
, it is usually not too hard
to find errors. If you do get stuck, do not hesitate to ask for help!

The Greenfoot website (
) contains a lot of helpful material for
learning about
Greenfoot. A good starting point is the tutorial:

When you are

familiar with the basics of Greetfoot, you can proceed to

the Programmers Manual:
. Note that you do

need to read each and every part
of this documentation in order to use Greenfoot. Use it when you get stuck
, b
ut otherwise try to
learn from the existing scenarios, and by experimenting a bit.