COMP2006代做、代写C++程序语言

项目预算：开发周期：发布时间：要求地区：

COMP2006, 2023/2024, Coursework Requirements: GUI Framework
Contents
Overview........................................................................................................................................................... 2
Getting started:................................................................................................................................................. 3
General requirements (apply to both parts):.................................................................................................... 4
Some clarifications (based on questions in previous years): ............................................................................ 6
General marking criteria for both part 1 (CW1) and part 2 (CW2): .................................................................. 7
Coursework Part 1 Functional Requirements................................................................................................... 8
Coursework part 2 functional requirements .................................................................................................. 11
Handling of program states (total max 6 marks, 2 are advanced).............................................................. 11
Input/output features (total max 6 marks, 2 are advanced) ...................................................................... 11
Displayable object features (total max 15 marks, 6 are advanced)............................................................ 12
Collision detection (4 marks, 2 is advanced)............................................................................................... 14
Animations, foreground scrolling and zooming (Max total 15 marks, 3 are advanced)............................. 15
Tile manager usage (Max 4 marks, 2 are advanced)................................................................................... 17
Other features (Max total 10 marks, 6 are advanced)................................................................................ 17
Overall impact/impression (Max 20 marks, 20 are advanced) ................................................................... 18
Overview
This coursework has two parts – an initial ‘easier’ part to get you working on this earlier, and the final part
which is more complex and lets you innovate more. Your part 2 coursework can be completely different
and separate to your part 1 – you do not need to build on the part 1 submission to make part 2, although
doing so may save some work.
Part 1 aims to introduce you to a C++ framework for building GUI programs. You should be able to get full
marks on that part if you work through the demos and spend time doing the coursework. Part 2 aims to
give you the freedom to do more with the framework and potentially create something impressive. The aim
is that your total mark for part 1 and part 2 should be representative of your ability with C++ (or the effort
you put into the coursework).
The coursework framework is a simplified cut-down framework covering just the essentials and aims to
simplify the process of software development for you. It may seem large to you but in fact is very small
compared with the sizes and complexities of class libraries you would usually be working with in C++. You
will need to understand some C++ and OO concepts to be able to complete the coursework but will
(deliberately) not need to understand many complex features initially, so that the coursework can be
released earlier in the semester.
There are two demo tutorials (labelled Demo A and Demo B) which you should work through to help you
to understand the basics. Please complete these to understand how to do part 1. There are also some
examples in the coursework code provides, to illustrate how you can do some things. Your submissions
must be different enough from the demo tutorials and supplied examples that it is clear to the markers that
you do understand the concepts rather than just copying them.
Part 1 is designed to be easy to complete. (You should be able to check the marking criteria in advance and
know what mark to expect – hopefully full marks for each of you.) A zip file of your project (including all
source, project and resource files), as well as a demo video (up to 3 minutes) showing how you meet the
marking criteria MUST be uploaded to Moodle.
Part 2 is more advanced and is designed to be harder to complete. Part 2 is designed to be hard in some
parts! You may not be able to do all parts. Please do what you can and make sure it compiles and runs etc.
Submission of documentation, code and the demo video (up to 6 minutes) will be via Moodle.
Failing to upload your project, documentation and the demo video will count as a failed submission and
result in a mark of 0.
You may complete and demo the coursework on Windows, Linux or Mac. As long as you can submit your
code and do us a demo, we don’t mind what operating system you use.
Getting started:
1. Download the zip file of the coursework framework. Unzip it and open it in Visual Studio – on
your own computer or the windows virtual desktop. Compile and run the initial framework to
ensure that it compiles and runs with no problems on your computer. Read the getting started
document if you are stuck. You can also use the lab PCs or the windows virtual desktop.
(Mac, Linux) Optionally: If you prefer then you can follow the instructions provided on Moodle to
build on Mac or Linux. We are assuming that, if you wish to do this, it is because you are the expert
on Mac or Linux so will be able to resolve any issues. This should ensure that those who are more
comfortable on a different operating system are able to use it, but please be aware that we may
not be able to support issues on these platforms.
Whatever you run this on, you will need to be able to demonstrate your work for marking as well
as to submit your source code files to Moodle. (It should be possible for you to demo on any
platform you wish and/or demo on the windows virtual desktop, if necessary, by copying files back
into the visual studio project.)
2. Do the coursework tutorial demo A and ensure that you understand about the basic features of
the BaseEngine class and drawing the background, including the tile manager and handling input.
3. Do the coursework tutorial B and ensure that you understand about the basic features of simple
displayable objects, moving them around and displaying them.
4. Skim through the Frequently Asked Questions document to ensure that you know what is in it.
This document has developed over the years to address questions which I often get asked. It will
also give you clues to things you may not know of may not think of.
5. Start on the requirements for part 1, using what you learned from demo tutorials A and B.
Coursework part 1 should not be too bad using the walkthroughs for demo A and demo B and the
samples. Try changing which object type is created in the mainfunction.cpp file (change which line
is commented out to change which demo to run) and look at the provided demos.
You may want to consider the ‘SimpleDemo’ demo, for things like string displaying, and potentially
either the BouncingBall or Maze demos if you can’t work out things like the TileManager. Work on
only the simple demos initially! You will not need the more advanced demos until you get to part 2.
6. Once you have completed part 1, look at the part 2 requirements and decide on how you will
develop a program to be able to do as many of these as you wish, considering what you learned
from part 1. You should think about which requirements you will attempt at the start rather than
trying to consider this later because some programs will make them more complex to achieve than
others. Note: in some cases, you may find it impractical to integrate some requirements into your
main program. In that case, don’t forget that you could use a fancy ‘intro’ or ‘ending’ screen (state)
to demo things that may not fit into your main program (e.g. TileManager in past years has not
always fitted for some students, and has been used on an intro screen). Think outside the box and
remember that your aim is to get the best mark, not be exact in matching some existing program
idea or to make the best game ever.
General requirements (apply to both parts):
You MUST meet the following general requirements for both part A and part B:
1. All the code that you submit must be either your own work or copied from the supplied demos.
Where you use code from demos it will not get your marks unless you have modified it enough to
show your own understanding.
You may NOT use work from anyone else.
You may NOT work with other people to develop your coursework.
You may NOT have someone else write any or all the code in your submission.
You will be required to submit a simple documentation sheet making clear that you understand
this.
2. Create a program which runs without crashing or errors and meets the functional requirements
listed below and on the following page. Look at the Hall of Fame page to see some examples of
previous work and decide on a basic idea for your program. You don’t need to implement that
much for part 1, but part 2 will involve finishing it.
3. Avoid compilation warnings in your code. Usually these mean that there is a potential issue with
your program. Try to avoid compilation warnings as any warnings may make us investigate whether
they mean that there are C++ issues with your program.
4. Your program features which are assessed must be different from all the demos and from
exercises A and B. i.e. do not copy demo code or the lab exercises code too closely. You will not get
marks for copying code but would get some marks for your own modifications which show your
understanding of C++ if you did similar things to the demos. In other words, change the code at
least enough to show that you understand what it is doing and haven’t just blindly copied it.
5. You must not alter existing files in the framework without prior agreement with from the module
convenor (which would require a good reason) – the aim of the coursework is to work with an
existing framework not to improve it (even though there are many possible improvements).
Note: subclassing existing classes and changing behaviour in that way is permitted, and is
encouraged, as you don’t need to change the existing files to do that.
I tried to make the classes flexible enough to allow behaviour to be modifiable by subclasses
relatively easily.
6. The aim of this coursework is the investigate your ability to understand existing C++ code and to
extend it using sub-classing, rather than to use some alternative libraries:
• Your program MUST use the supplied framework in the way in which it is intended. i.e. the
way in which demo tutorials A and B use it to draw the background and moving objects is the
way that you should use it.
• You must not alter the supplied framework files. See comments above for point 5.
• You should not use any external libraries other than standard C++ class libraries, and libraries
which are already used by the framework code, unless a requirement specifically says you may
do so. There are many useful libraries which you could use to improve your programs, but the
point of this exercise is to show that you can understand and use the library I supply.
7. There are 10 functional requirements in part 1, worth 2% of the module mark each, for a total of
20% of the module mark for this part of the coursework.
When you have completed the coursework part 1, submit a zip of your source code and a demo
video to Moodle:
• Clean your program (use the ‘Clean Solution’ option under the build menu – to delete the
temporary files.
• Delete the hidden .vs folder in the root of your project directory. This can become huge
but is not needed and will make your zip file unnecessarily big.
• Zip up the rest of your project directory and submit it to ‘part 1 coursework submission’ on
Moodle.
• Your submission should include all the supplied files (including demo files) as well as your
new files in the zip file you submit.
• Also include your completed documentation sheet(s) in your submission – as a separate
file outside of the zip.
• If you worked on Mac or Linux, please include your make files etc that you used, ideally in a
format which we can use to build and test the code ourselves, along with summary
instructions of how we can build and run the program ourselves if necessary.
It should be possible when you have done this for someone to download the zip file, unzip it, do a
‘rebuild all’ to rebuild it, and run it, with no other changes. (Or for us to build/run it on Linux/Mac if
appropriate.)
It should also be possible for us to check your documentation file to see whether the mark matched
what you expected or where any issues were.
8. There are 80 marks available for part 2 requirements, for a total of 80% of the module mark.
These are usually a lot harder than the part 1 requirements. Start with the easy ones! You may set
a time limit so that you don’t overdo it.
Read the requirements carefully!
When you have completed part 2 upload the project file to the CW2 submission on Moodle, as you
did for CW1 (i.e. clean it, delete the .vs directory and zip the folder).
A demo video is required to show the program running and explain how you meet the criteria.
You will need to upload a documentation file explaining which features you achieved.
Some clarifications (based on questions in previous years):
The key priority is that you understand the code. The assessment aim is to test your ability to understand
C++ code and to write it – not to copy paste. Here are some examples of things which are and are not
allowed as far as marking is concerned:
• If you take a demo and just add some changes then you are assessed only on your changes.
i.e. if maze demo already did something (e.g. background drawing, pause facility, etc) then it
doesn’t count for a mark for you because you did not write it yourself.
Similarly, it does not count as you creating a new subclass because you didn’t.
Please start from a new class and add your own code to it.
• If instead you write your own code and take from the demos the understanding of how they do it –
possibly even copying some parts of the code, but showing your own understanding of it when you
do, then that is OK. (This is partly why we ask you to demo it – so you can answer questions if
necessary.) E.g. if you copy the way that pause works and implement it correctly then you would
understand how it works and be able to explain it.
• As another example, if you copy whole functions, such as a draw function, from a demo, that is also
a case of something being the same as maze demo. If you do so and make a slight change to make
it a different colour then it’s basically the same apart from that slight change, so it is not different
enough. Don’t do that please as you won’t get the marks.
• However, you CAN copy small parts into your own classes, showing your understanding of them. In
which case you should be able to explain how they work if asked.
General marking criteria for both part 1 (CW1) and part 2 (CW2):
You will lose marks if any of the following apply. In each case we will apply a percentage mark penalty to
your mark.
• Your program crashes on exit or has a memory leak. (Lose 10% of your mark.)
• Your program crashes at least once during its operation. (Lose 20% of your mark.)
• Your program crashes multiple times. (Lose 30% of your mark.)
• Your program crashes frequently. (Lose 40% of your mark.)
• Your program has some odd/unexpected behaviour/errors. (Lose at least 10% of your mark.)
• Your program has a lot of unexpected behaviour/errors. (Lose at least 20% of your mark.)
• You have changed framework files without prior agreement. (Lose at least 20% of your mark.)
The mark sheet that will be used for marking for parts 1 and 2 has entries for the above and your marker
will annotate it according to their experience of your demo (or their running) of your software.
Coursework Part 1 Functional Requirements
Functional requirements: (2 marks each).
Note: the markers will use the literal text below (both the bold and non-bolded text) to determine
whether a requirement was met or not. Please read the criteria carefully to ensure that you don’t miss
anything. If I need to clarify any of these criteria I will do so and let you know that it was updated.
To try to avoid you missing specific parts I have labelled key aspects of each requirement in a list.
In general, the requirements below get progressively harder (in that they need more understanding of the
framework and C++ to do the later ones) but please do check later ones even if you decide some earlier one
is too hard for you to do.
1. Create an appropriate sub-class of BaseEngine with an appropriate background which is different
from the demos.
a. Create an appropriate new sub-class of the base engine.
b. Give it an appropriate background.
c. Ensure that the background is different to the demos.
d. Name your class using your capitalised username followed by the text Engine. e.g. if your
username was psxabc then your class would be called PsxabcEngine.
2. Show your ability to use the drawing functions:
a. Draw your background ensuring that you use at least one of the shape drawing functions
to draw on the background.
b. and that you draw at least one image to the background,
c. which is different from the demos and shows your understanding.
A blank background will not get this mark – even if you change the colour – you MUST use one
of the shape drawing functions (i.e. a drawBackground…() function other than
drawBackgroundPixel() ) and at least one image, to show your understanding.
3. Draw some text on the background.
a. Draw some text onto the background (not foreground)
b. and ensure that the text is not obliterated when moving objects move over it.
c. Ensure that moving objects can/do move over at least part of this text, so that the object
appears in front of the text, and demonstrate that it is redrawn after the object has moved.
i.e. show that you understand how the background and foreground are drawn to and when to
draw text.
4. Have some changing text, refreshing/redrawing appropriately which is drawn to the foreground
(not background), in front of moving objects.
a. This text may change over time (e.g. showing the current time, or a counter) or could show
a score which changes, for example.
b. It could also be drawn to the foreground as a part of an object (e.g. a moving label) if you
wish, but does not need to move around with objects if you don’t want it to.
c. When the text changes, the old text should be appropriately removed from the screen.
d. The text must be drawn such that moving objects would move under it rather than on top
of it though. i.e. not to the background, and basically it means it’ll be drawn after at least
some of the objects.
e. For marking we will check the code where it is drawn if there is any doubt. E.g. whether the
function which draws it is called before or after drawing objects. (Look at the different
functions to see which to use – the point of this mark is to see whether you realised the
difference between drawing changing text to foreground rather than background.
5. Provide a user controlled moving object which is a sub-class of DisplayableObject and different to
the demos:
a. Have a moving object.
b. that the user can move around,
c. using either the keyboard OR the mouse (or both)
d. and is different to the demos.
Note: you could have an indirect subclass of DisplayableObject if you wish (i.e. a subclass of a
subclass of DisplayableObject). The aim of this requirement is for you to show that you
understand how to use EITHER the keyboard or mouse input functions (or both) as well as to
show that you can create a moving object.
6. Ensure that both keyboard and mouse input are handled in some way and do something. At least
one of these input methods should influence one or more moving objects, from requirement 5. The
starting point is probably to look at whether you used mouse or keyboard for the moving object
above and just use the other one here. E.g. if you user-controlled object is mouse controlled then
make it so that something happens when a key is pressed (e.g. a counter is incremented, which
appears on the screen – see requirement 4). Or if your object is keyboard controlled, you need to
handle mouse movement or button pressing. Both mouse and keyboard could influence the
moving object if you prefer, or one could change something else.
a. You handle both keyboard input AND mouse input and they both do something.
b. Something(s) should visibly change for both – e.g. some position of something or value of
something or displayed image, or…
7. Provide an automated moving object which is a sub-class of DisplayableObject and different from
the one in requirement 5.
a. Provide a second moving object (separate to the user-controlled one, with a different
class)
b. whose movement is not directly controlled by the player,
c. which moves around,
d. which acts differently to the objects in the samples/demos/code that I provided,
e. and which looks different to the objects in the demos and to your object in requirement 5.
i.e. show that you understand something about how to make an object move on its own,
without user input (changing its x and y coordinates and redrawing it appropriately). Your
object must have some behaviour that is different to the demos (i.e. a copy-paste of the demo
code is not sufficient) and you must be able to explain how it works and justify that it is
different from the demos in some way. Your object must also have a different appearance to
the object in requirement 5 and look different to the demos/samples as well.
8. Include collision detection between a user-controlled (req. 5) and an automated (req. 7) moving
object, so that they interact with each other.
a. You need to check for a collision between the two objects.
b. Something should happen when they collide, and something should visibly change – e.g.
something moves, direction of travel changes, or something is shown.
c. Collision detection should be at least as good as rectangle-rectangle interaction and should
work properly.
This means that at least two of your objects should react to each other when they collide. Hint:
look at UtilCollisionDetection.h if you don’t want to do the maths for rectangle or circle intersection
yourself – and see MazeDemoObject.cpp for an example of using these functions. Assessment of
whether you achieved this or not will be on the basis that the intersection of two objects is
correctly assessed and something happens in reaction to this (e.g. objects move, change direction,
something else changes (e.g. a score) etc). Rectangle-rectangle or circle-circle interaction is fine for
meeting this requirement.
9. Create your own subclass of TileManager.
a. Create a subclass of the tile manager which has different behaviour (at least a little) to the
demos, is drawn to the background, and is visible to the user when the program is run.
b. Name your class using your username followed by the text TileManager. e.g. if your
username was psxabc then your class would be called PsxabcTileManager.
c. Explain the difference(s) from the demo versions.
Hint: Look at the existing demos, including the bouncing ball demo. Display the tile manager on
the background, so that the tiles are visible. It must be different from the demos but can still be
simple. You are just showing that you understand how to use the tile manager class. Use a
different tile size and number of rows and columns to the demos (e.g. 13x13 tiles and 6 rows
and 9 columns if you can’t think of some numbers yourself). Your TileManager must not be a
copy of an existing one, or just an implementation of the demo tutorial example without
change. i.e. you must show some understanding of how to do this, not just blindly repeat the
steps of demo tutorial A.
10. Have at least one moving object interacted correctly with the tile manager, changing a tile:
a. Ensure that at least one of your moving objects visibly changes specific tiles when it passes
over them – using the position checking appropriately.
b. The tile must be changed and redrawn correctly so that the user sees the change.
Consider the bouncing ball demo if you can’t work out how to do this from the information in
demos A and B, but you need to have at least some difference in behaviour from that.
Assessment will check that you correctly detected the specific tile that the moving object was
over and handled it appropriately.
Coursework part 2 functional requirements
Again, key parts of requirements have been highlighted with letters to try to ensure that you don’t miss
something – you need to meet ALL the lettered sub-requirements to get the mark.
The following requirements apply, and have a variety of marks available:
Handling of program states (total max 6 marks, 2 are advanced)
1. Add states to your program (max 6 marks). This means that your program correctly changes its
behaviour depending upon what state it is in. Each stage should have a correctly drawn background
which is different to the demos, and are NOT trivial (e.g. a blank background). This could use an
image, a tile manager or be drawn using the fundamental drawing functions on the base engine.
You can get a variety of marks for this:
2 marks:
a. a start-up state, a pause state and a running state,
b. which differ in some way in both the appearance and behaviour.
2 marks:
c. at least five states
d. including at least one win or lose state as well as those mentioned above. (Note: if you are
not doing a game, then have a state which allows a reset, e.g. ‘load new document’ in a
text editor.)
e. There must be significant differences between the states in behaviour and/or appearance.
The program must be able to correctly go back from the win/lost (or reset) state to the
starting state to start a new game/document, correctly initialising any data.
2 marks (advanced):
f. implement the state model (design pattern) using subtype polymorphism rather than
if/switch statements in each function. Note: You may still need some if statements etc to
enter the states, but the current state object is used to determine how to act in each
function.
Look up the ‘State Pattern’ to see what this means and think about it. These are advanced
marks, so we will not explain how to do this beyond the following: there will be a basic state
base class and a subclass for each of the different states. Your BaseEngine sub-class will need to
know which state object is currently valid and the different methods will call virtual methods
on this object. The different behaviour will therefore occur due to having a different object
being used for each state rather than having a switch in each of the methods. If you have if or
switch statements specifying what to do in different states, then you won’t have done it
properly, so you won’t get these marks. You should NOT have more than the one sub-class of
BaseEngine if you do it correctly. If you had to create multiple sub-classes of BaseEngine then
your implementation is wrong (and there will be other issues since you may have more than
one window as well).
Input/output features (total max 6 marks, 2 are advanced)
2. Save and load some non-trivial data (max 6 marks). You can use either C++ classes or the C
functions to do this – your choice will not affect your mark.
You can get a variety of marks for this:
2 marks: most basic saving and loading, as follows:
a. save AND load at least one value to/from a file, e.g. a high score to a file (e.g. a single
number to a file)
2 marks: completed the saving/loading above, and load some more complex, structured data, e.g.
map data for levels, or formatted text documents where the formatting will be interpreted. The
main criteria are:
b. It must be multiple read/write operations, of multiple values with some kind of structure to
the file, rather than just a string of 3 numbers, for example.
c. Something must visibly change depending upon what is loaded (e.g. set tiles according to
data read and/or set positions of moving objects according to the data).
2 marks (advanced): completed the above but also save/load the non-trivial state of the program
to a file.
d. A user should be able to save where they are (e.g. the current document that they are
working on or the state of a game – saving all relevant variables for all objects)
e. and they should be able to reload this state later, with everything acting correctly and
continuing from where it was.
f. Note: this means saving/reloading the positions/states of all moving objects as well as
anything like changeable tiles, etc.
g. You will need to provide some way to reload from the state as well – e.g. when the
program starts (e.g. choosing to load or start a new game) or in response to some
command from the user (e.g. pressing S for save and L for load?).
This is meant to be non-trivial and may need some thought and debugging to make it work
properly.
Displayable object features (total max 15 marks, 6 are advanced)
3. Use appropriate sub-classing with automated objects (max 2 marks):
a. multiple displayable objects
b. from at least three displayable object classes,
c. with different appearances and behaviour from each other
d. and you should have an intermediate class of your own between the framework class and
your end class,
e. the intermediate class adds some non-trivial behaviour.
i.e. you are showing that you can create a subclass which adds some behaviour, and some other
subclasses of that class which add more behaviour.
Example: a complex example can be found in ExampleDragableObjects.h:
DragableObject and DragableImageObject are both DragableBaseClassObjects, which is a
DisplayableObject, so DragableBaseClassObjects is an intermediate class which adds some nontrivial behaviour.
4. Create and destroy displayable objects during operation of a state (max 4 marks): for example,
add an object which appears and moves for a while for the player to chase if a certain event
happens, a bomb that can be dropped by a player, or a bullet that can be fired. Note that
something like pressing a key to drop a bomb which then blows up later, while displaying a
countdown on the bomb, and then changes the tiles in a tile manager would meet some
requirements (i.e. marks) in one feature.
2 marks: Objects appear to be created or destroyed over time, which means you:
a. dynamically add one or more displayable objects to the program temporarily after a
state has started (i.e. you add to the object list or make some object visible).
b. and ensure that the object cannot interact with anything else before it is added or after
it is ‘destroyed’. E.g. if you make the object invisible then it is not collision detecting
with anything while it is not visible.
c. You must not just re-create the entire object array contents to do this, although you
could add to the end of it. (Please see the methods on DisplayableObjectContainer.)
d. This requirement is not met by the re-creation of objects when you change states. The
idea behind this requirement is that moving objects appear and disappear while using
the program within the state.
For the above criterion you can hide/show an object rather than actually creating/deleting
them. Remember if you do tho