The PacMan Project

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

15 Αυγ 2012 (πριν από 5 χρόνια και 7 μέρες)

378 εμφανίσεις


The PacMan Project



A Programming Projec
t for Software
Construction, 1
st

Semester


by Per S. Laursen



Introduction

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

classic

PacMan

game. The game has been written u
sing the
GreenFoot

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

section.


Project time frame

The project will run during all
Software Construction

classes in week 17
, and during Monday in
week 18

(A
pril 20
th



27
th
). That is, you have 15
-
16

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
must

be handed in at the end of the
Software Construction

classes on
Monday

27
th
.


Project groups

It is
strongly encouraged

that you do this project in grou
ps of
two

students
. Groups of three
studen
t
s are
not

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
open
-
ended

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
challenging
to do in
the final steps of the project.

The overall purpose of the project is to evaluate your current skill level
in
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
so


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
S
hort

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


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
-
mail
to
psl@rhs.dk
. However, I must receive your material
no later than April
27
th
, at 14
.30
. If you
sen
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
problems.
When the project has ended, you can also fill out a
partner evaluation form
, if you want
to mention any issu
e
s

regarding the project work.

The partner evaluation form can be found at
http://laerer.rhs.dk/susanneru/pair
-
learning/Pair%20Evaluation.doc


Project steps

The project is

divided into several
steps
, 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
not

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


Installi
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
appendix

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
SW
-
Construction, Projects,
Pacman
. Note that GreenFoot is a fairly
small program, only about 5 mb.

Usually, Greenfoot will
be installed in the
folder
C:
\
Greenfoot
.


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

from BlackBoard, where is it found under
SW
-
Construction, Projects, Pacman
. If you
are using your own computer, you can just put the PacM
an scenario in
C:
\
Greenfoot
\
scenarios
. 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
“C
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
,
without

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
world.
Describe
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

E
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
mple
-
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
three

ways:



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



Modify

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
report
.



Step 4


Adding new subc
lasses

(passive)

The next step is to
add two entirely new subclasses

to the PacMan program; a
Star

subclass and a
Bomb

subclass. Both of these subclasses must inherit from the
Actor

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



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



Bomb
: If PacMan eats a
Bomb
, 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
Star

and
Bomb

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

to 3

%, and the probability to populate a
cell with a
Bomb

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
Star

and
Bomb

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
Ghost

class. A
Ghost

is an actor which


like in the real
game


chases PacMan. If a
Ghost

catches PacMan, PacMan dies. If a
Ghost

meets an object (like
a
Dot
), 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
Ghost

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
more

than
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



C
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
Star
, 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
hased



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
many

changes to the code…



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

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


see the GreenFoot

API

documentation for more information on this.



Change the objective of the game
.

Instead of winning the game at a fixed score, you
may
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



Appendix

A
: A short introduction to Greenfoot


The
Greenfoot

environment is a
simple
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
structure
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
World

and
Actor
.


The
World

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
two
-
dimensional visual interface, like a simple game or simulation. The
World

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
World
, which will contai
n code specific for your own pa
rticular
“world”. If you double
-
click on the
World

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

class.


In Greenfoot, any world will be inhabited by
Actors
. Any object which is to “live” in a Greenfoot
world must be a subclass of
Actor
. 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
Actor

class. The actual
behavior of a specific
Actor

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

must
implement the method
act
()
, 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 (
www.greenfoot.org
) contains a lot of helpful material for
learning about
Greenfoot. A good starting point is the tutorial:
http://www.greenfoot.org/doc/tutorial/tutorial.html

When you are

familiar with the basics of Greetfoot, you can proceed to

the Programmers Manual:
http://www.greenfoot.org/doc/manual.html
. Note that you do
not

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.