A Programming Project for Software Construction, 1Stsemester

The PacMan Project

A Programming Project for Software Construction, 1stSemester

by Per S. Laursen

Introduction

This project concerns a small Java program, which implements a very simple version of the classicPacMan game. The game has been written using 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 are 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 (April 20th – 27th). 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 Monday27th.

Project groups

It is strongly encouraged that you do this project in groups of two students. Groups of three students 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, two 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 Short Introduction 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 is 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 . However, I must receive your material no later than April 27th, at 14.30. If you send 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 issues regarding the project work. The partner evaluation form can be found at

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 – Installing the Greenfoot environment

The PacMan game has been created using the GreenFoot programming environmemt, which you must also use during the project. See the appendixIntroduction to Greenfoot for more details on Greenfoot. So, the natural first step is simply 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 scenariofrom BlackBoard, where is it found under SW-Construction, Projects, Pacman. If you are using your own computer, you can just put the PacMan 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 “Compile 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 quite 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 what 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

Everything 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 implement that logic? Do this for all parts of the logic, and describe your findings in the report.

Step 3 – Code modification

By now, 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 the 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 subclasses (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 eats 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 these 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 removed 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 structure 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 – Changing 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 allowed 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 the state where PacMan is chased – 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 movement 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 movement 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 changes 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 intention 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 limited. 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. The 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” your 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 contain code specific for your own particular “world”. If you double-click on the World class box in Greenfoot, you are taken to a web site with documentation 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 aretaken 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 behavior 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: you are familiar with the basics of Greetfoot, you can proceed to the Programmers Manual: 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, but otherwise try to learn from the existing scenarios, and by experimenting a bit.