Unformatted Attachment Preview
SE 120: Object-Oriented Programming
Due 23rd April 2020
Due to getting request from MoE to post marks out of 80% before 23
April, The deadline is advanced and some requirements are cancelled.
New Dead line 19th April 2020
1. Project due date is Thursday April 23, 2020 advanced to 19 April 2020. No late
projects will be accepted.
a. Due to getting request from MoE to post marks out of 80% before 23 April, The
deadline is advanced and some requirements are cancelled.
2. The project weight is 25% of the total mark.
3. The project is divided into two phases:
a. Phase 1: Getting familiar with Greenfoot:
i. This phase worth’s 10% out of 25%.
ii. In this part you will be given step by step instructions that will help be in
building the basic classes and functionalities of this game. At the end of
this phase, you should have a functioning game but with limited features.
b. Phase 2: Building extra features and implementing advanced OO concepts
i. This phase worth’s 15% out 25%.
ii. In this phase, you must modify and continue on what you have done in
phase one to complete the game functionality and implement all features
to fulfill the Project Requirements.
4. You can work on the project individually or in a group but the maximum number of
students in a group is three. However, copying and claiming someone else’s work is not
accepted at all. It will be reported and penalized according to the university cheating
5. Students working in a group must understand all parts of the project as any part of the
code may be discussed verbally during the project evaluation with any student.
6. What to submit? Each team should submit a soft copy on Moodle of your solution that
includes the following items:
• Report consists of:
o A cover page having the following information:
Page 1 of 6
▪ Course name/code/ section number
▪ Team members: names and students ID numbers
Analysis: Describe the problem including input and output in your own
▪ Describe the major steps for solving the problem.
▪ UML diagrams.
Your programs’ codes.
Testing: Describe how you test this program along with a block comment at
the end containing sample output.
▪ A zipped file that includes a folder which Include all classes, images,
necessary files to run your code in Greenfoot.
▪ Your code must contain a block comment describing its purpose,
descriptive comments for each of the methods, and a few in-code
comments, where appropriate.
Page 2 of 6
The only help that you are allowed to get on this project should come from your instructor and
TA. No outside help is allowed. Honestly, this project is so easy that everything you have in
your lecture notes should be enough. A reminder on the no-cheating policy: This class carries a
non-cheating policy. You may discuss general ideas with friends, but your solution must be
coded separately and represent individual team work. If cheating is discovered, both parties will
take equal blame. You have been warned!
Car Driving Game
Overview and Background
In this project, you will develop a Car Driving Game using Greenfoot environment and IDE.
Like the one shown below.
Checkout these examples but note that they are not complete:
Page 3 of 6
There are two types of requirements in this project that you need to fulfill: Coding
Requirements and Car Driving Game Requirements which are presented next.
A. Coding Requirements:
From the game description, rules, feature, you should decide which classes and fields to
All fields must be private attributes.
Use inheritance concepts to maximize sharing code between classes.
• No field should be declared in more than one class.
• Methods doing the same behaivour should be moved to super classes and only
overridden in subclasses when needed.
Each class must also contain a private, static attribute to count the number of objects
created of that type, and an accessor to return that number.
Each class must contain a constructor, and a toString() method. The
toString()should return a string of the values of all attributes of the class.
You must implement the comparable interface for player’s cars
• All subclasses must base the comparisons on the price.
It is expected you will be using the "extends", "this" and "super" keywords quite often.
You must use Abstract classes and method concepts whenever appropriate.
B. Car Driving Game Requirements:
Driver car is the car that the player will control while playing the game. The user should be able
to move the car to the left, right, up, and down to avoid collision or to pass over objects to
collect points. The game should support three types of Driver Car:
Entry-Level: supports only left and right movements using left and right keyboard
Middle-Level: It support all the Entry-Level features plus it supports speed up and slow
down using up and down keyboard arrows.
Higher-level: It support all the Middle -Level features plus it supports playing sounds
such as horn sound when pressing space, break sound when slowing down, engine sound
at start and while moving.
Different cars should have different pictures.
Page 4 of 6
Other Vehicles on the Road:
Your game should support at least three types of vehicles moving on the road while the game is
running. These are the required features that you should implement:
Sedan Car: this is a small car that does not change its direction from right to left or from
left to right.
Four-wheel Car: this is a larger car that moves randomly in the road.
Truck: this vehicle plays a truck sound when the player car moves next to them.
Different vehicles should have different pictures.
Other Game Objects:
The game should include four objects that appear on the road or on its sides while playing the
game. These objects are:
Fuel Station: it is rectangle colored object that appears randomly on the road. The
player’s car gets fueled when it passes over it.
Coin: this is coin shaped object that is displayed randomly on the road. The player can
collect points when his/her car passes over it.
Tree: this is an object of type tree that is displayed on the sides of the road.
Game rules and features:
The player should avoid other vehicles on the road.
The player losses 100 points for every accident.
The game is over after three accidents.
The game is over when fuel level reaches zero.
The game plays sound when the user pass over the sides of the road and counts that as
The game plays crash sound when the player’s car hits another.
The players car is upgraded for every 500 points collected.
The game starts with full Fuel but the fuel level decreases with distance or play time.
The player collects 50 points for each coin his/her car hits.
The player’s car gets fueled when it passes over it.
The game should support three levels as follows:
o Level 1: things moves slowly and shows only sedan cars and other game objects.
o Level 2: things moves faster than level 1 and shows Sedan cars, Four-wheel car
cars, and other game objects.
o Level 3: things moves faster than level 2 and shows Sedan cars, Four-wheel car
cars, Trucks, and other game objects.
The game should show the following on the screen while the player is playing:
Page 5 of 6
Highest score: The highest score achieved by any player of this game.
Score: shows the points collected so far.
Level: the current Level.
Lives: shows how many accidents you are allowed to make before the game
o Fuel: shows how much fuel left.
The player wins the game after finishing all the levels without making 3 accidents.
At the end of the game, it displays a list of top 5 players scores.
Page 6 of 6