Faculty of Computer Engineering and Media

Course work Specification 2021/22

Module name: Introduction to Object Orientated

Programming in C++
Module code: IMAT1908
Title of the Assignment: Implementing the Inheritance concept in
Graphical Arcade Style 2D Game – Snake
This coursework item is: (delete as appropriate) Summative
This summative coursework will be marked anonymously No
The learning outcomes that are assessed by this coursework are:
• Write a suite of classes for use in the solution of a well-defined simple
problem.
• Understanding the inheritance between the classes.
• Communicate the design of classes in a document produced to a professional
standard.
• Produce a substantial individual piece of work in the form of a working
program as part of a personal portfolio.
This coursework is: (delete as appropriate) Individual

This coursework constitutes 100% to the overall module mark.

Date Set: Tuesday 24th January 2022
Date & Time Due: Deliverable # 1: Friday 25th February, 2022 at
12:00 (Midday) (35%)

Deliverable # 2: Thursday 5th May, 2022 at 12:00

(Midday) (65%)
Your marked coursework and feedback will be
available to you on: Deliverable # 1: 25th
If for any reason this is not forthcoming by the due date your module March, 2022
leader will let you know why and when it can be expected. The
Associate Professor Student Experience
([email protected]) should be informed of any
issues relating to the return of marked coursework and feedback.
Deliverable # 2:
Note that you should normally receive feedback on your coursework by Monday 6th June 2022
no later than 20 University working days after the formal hand-in
date, provided that you have met the submission deadline.

When completed, you are required to submit your coursework to:

Deliverable # 1:
1. Completing the Lab 4.
2. Code (C++ source and .h files) as a solution (folder with .sln in it) as a .zip file
on Blackboard.
Deliverable # 2:
3. Code (C++ source and .h files) as a solution (folder with .sln in it) including any
assets used as a .zip file on Blackboard.
4. A short document describing your approach to testing and any documented
test cases to the TurnItIn link on Blackboard.
If you need any support or advice on completing this coursework please visit the Student
Matters tab on the Faculty of Technology Blackboard page.
Late submission of coursework policy: Late submissions will be processed in accordance
with current University regulations which state:
“the time period during which a student may submit a piece of work late without authorisation and have
the work capped at 40% [50% at PG level] if passed is 14 calendar days. Work submitted
unauthorised more than 14 calendar days after the original submission date will receive a mark of 0%.
These regulations apply to a student’s first attempt at coursework. Work submitted late without
authorisation which constitutes reassessment of a previously failed piece of coursework will always
receive a mark of 0%.”
Academic Offences and Bad Academic Practices:
These include plagiarism, cheating, collusion, copying work and reuse of your own work, poor
referencing or the passing off of somebody else's ideas as your own. If you are in any doubt about
what constitutes an academic offence or bad academic practice you must check with your tutor.
Further information and details of how DSU can support you, if needed, is available at:
http://www.dmu.ac.uk/dmu-students/the-student-gateway/academic-support-office/academic-
offences.aspx and
http://www.dmu.ac.uk/dmu-students/the-student-gateway/academic-support-office/bad-academic-
practice.aspx

Tasks to be undertaken:

Deliverable # 1:

• Complete the Lab 4.

• In addition to Lab 3, add the additional subclasses (You will need a header
(placed in the include folder) and a source file (placed in the src folder).
• Add a method overload in your class.
• With the method overloading use the inheritance in more broad way, show the
inheritance between each class.
• The code should use a form of object orientated code structure.
• The code should focus on reusability and adequate commenting.
• Remember to implement proper file management.

Deliverable # 2:

You are to implement a version of the classic arcade game Snake in C++ using the
Visual Studio IDE with the SFML libraries. The mechanics of the game are as follows:
• The player controls a moving snake that’s goal is to eat the food (dots) on the
screen.
• The snake is within a box that has four walls. If the snake hits any of these
walls, the game is over.
• The playing area is a grid so that if the direction of the snake is correct it won’t
miss the food.
• Each of the pieces of food that are collected add a point to the players score.
 • As the pieces are eaten, a section is added to the snake.
• If the snake hits itself, the game is over.

The requirements of the submission are:

• The game should have a snake that can move in the x and y directions using
the arrow keys.
• The walls should have collision detection so that the game can end.
• The snake should have collision detection so that the game can end.
• The player should be able to score points.
• Food should be displayed to the screen and be eaten.
• The snake should be able to eat the food and increase its length.
• You are required to complete only 5 levels (5 food elements) before there is a
win condition.
• The code should use a form of object orientated code structure.
• The code should focus on reusability and adequate commenting.

To be submitted for assessment:

Deliverable # 1:

1) Code (C++ source .cpp and .h files) as a solution, in a compressed .zip style
file onto Blackboard.

Deliverable # 2:

1) Code (C++ source .cpp and .h files) as a solution and any assets used, in a
compressed .zip style file onto Blackboard.
2) A maximum of 5 minutes recorded video through Panopto, demonstrating the
functionalities of the game.
 3) A short document (maximum 3 pages in 12pt) describing your approach to
software testing as well as any documented test cases to be submitted to
TurnItIn.
How the work will be marked: Using the outlined matrix and returned electronically.
To ensure a high mark you need to achieve good functionality with high quality code.
Module leader/tutor name: Dr. Daniyal Haider
Contact details: [email protected]

Should you need any further information or advice please email

[email protected]

See next 2 pages for coursework marking scheme of Deliverable # 1 &

2.
 Deliverable # 1 Marking Rubrics
0-29 30-39 40-49 50-59 60-69 70-79 80-89 90-100
Code Logic Little or no A significant The The majority of Nearly all of All the In addition to
Weight work has been portion of the fundamental the OO logic the classes concept of the criteria
80.00% done in programme concept of by using logic have using required for
implementation have not class has classes and been classes have the 70-79%
or design. been been method implemented been mark range
implemented. implemented, overloading and is implemented some
Innovation
albeit with have been largely bug well. extensions of
some bugs. implemented, free. Efficiency of the student’s
albeit with the methods design have
some bugs have been been
considered. specified and
implemented.
Code Ignored code Ignored code Poor code Some code Significant Code Code
Presentation standards. No standards. standards. standards elements of standards standards
Weight use of Some use of Some use of implemented the solution adhered to adhered to
10.00% structures such functions or functions or with but poor contain the across the across the
as loops or objects. No objects. No OO. use of code code. A near whole of the
Innovation
arrays to OO OO standard completely project with a
reduce implemented implemented. and an OO OO project. completely
repeated code. approach. OO
No OO approach.
implemented.
Code No code Unstructured Vaguely Code is neat Code has Code has Code has
Organisation structure with code with structured and been split been split been split
Weight little or no comments code with commented into header appropriately appropriately
10.00% comments. that are some effectively but and source and this is into header
difficult to commenting. lacked files. reflected in and source
comprehend. effective Comments the directory files. Areas Innovation
splitting into could have structure. that need
source and been Effective use comments
header. improved. of have been
comments. carefully
considered.

5
 Deliverable # 2 Marking Rubrics
0-29 30-39 40-49 50-59 60-69 70-79 80-89 90-100

Game Game mechanics Games The The majority of Nearly all of All game In addition to the
Mechanics have not been mechanics fundamental the game the game mechanics criteria required for
Weight achieved. Little or have partially game mechanics mechanics have been the 70-79% mark
55.00% no work has been been mechanics have been have been implemented range some
done in achieved. A have been implemented, implemented well. extensions of the
implementation or significant implemented, albeit with and the Efficiency of student’s design have
Innovation
design. portion of the albeit with some bugs game is the been specified and
mechanics some bugs. largely bug algorithms implemented in the
have not been free. has been game.
implemented. considered
throughout
the game.
Code Ignored code Ignored code Poor code Some code Significant Code Code standards
Presentation standards. No standards. standards. standards elements of standards adhered to across the
Weight use of structures Some use of Some use of adhered to. the game adhered to whole of the project
20.00% such as loops or functions or functions or Repeated use contain the across the with a completely OO
arrays to reduce objects. No objects. No of functions or use of code game code. approach. Innovation
repeated code. OO OO objects. standard A near
No OO implemented implemented. Implementation and an OO completely
implemented. of some but approach. OO project.
poor OO.
Code No code structure Unstructured Vaguely Code is neat Code has Code has Code has been split
Organisation with little or no code with structured and been split been split appropriately into
Weight comments. comments that code with commented into header appropriately header and source
10.00% are difficult to some effectively but and source and this is files. Areas that need
comprehend. commenting. lacked files. reflected in comments have been
Innovation
effective Comments the directory carefully considered.
splitting into could have structure.
source and been Effective use
header. improved. of
comments.
Testing Poor testing. No effective Basic testing Some testing Some good Good testing Good extensions of
Weight testing. with no with some testing. throughout. the testing design.
15.00% discussion of description of
the process. the process. Innovation