## What are you going to do?
In this project, you will apply the content of the course and structure your own problem solving with classes
and objects. Your task is to implement a simple version of the game Missile Command, and write a short report
in which you describe how to solve the problem and meet the project criteria. Before you read on, you can audition
a full-scale version of the game here:
https://games.aarp.org/games/atari-missile-command (warning: high volume)
Your implementation will be a scaled-down version of the game. The project assignment is graded from A-F.
By implementing a simple version of the game according to given criteria, as well as providing answers to
requested points in your report, you will reach the grade E. For a higher rating, you need to solve more problems.
After this level, there are a four different extra choices that build on the base game,
where each extra selection has its own criteria that must be met. Every extra election you implement,
and meet criteria for, increases your rating by one level. There is no order to these extra choices,
you get to mix these freely in whatever order you yourself are comfortable with. See the following list
for grading:
- Grade E: base game + report
- Grade D: base game + report + 1 extra choice
- Grade C: base game + report + 2 extra choice
- Grade B: base game + report + 3 extra choice
- Grade A: base game + report + 4 extra choice
Note* that an extra choice must be fully implemented according to its criteria in order to achieve its score.
Half-finished, or "almost finished", solutions are not counted.
## How do you draw objects to a window?
In order to create a window and draw objects, you will use a ready-made library called
SFML (Simple and Fast Multimedia Library). With this library, you can quickly and smoothly
get started with drawing objects.
The following code sample creates a window and draws an edge-to-edge green circle in the window:
```cpp
#include <SFML/Graphics.hpp>
int main()
{
sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
sf::CircleShape shape(100.f);
shape.setFillColor(sf::Color::Green);
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}
window.clear();
window.draw(shape);
window.display();
}
return 0;
}
```
To get started, you'll get some sample code to start from. It's perfectly fine to use the code given,
but it's not a requirement that it has to be used. The purpose of the code is to introduce, for example:
- How to create the foundation for running a visual project with SFML.
- How you can create your own classes for in-game objects that will...
- updated over time (e.g. position).
- drawn to the window with new position.
- Mathematics for calculating...
- New position based on a direction and speed over time.
- distance between two positions.
- angle of rotation based on a particular direction.
## Grading criteria
**Code criteria:**
- No memory leaks.
- No obvious crashes.
- Code should be written in English and be clear to read and understand.
- An objket-oriented solution with inheritance and polymorphism should be used.
- It is allowed to use anything from the standard library ('std')
- This includes, for example, 'vector', smart pointer, etc.
**For a grade of E:**
- There must be a characteristic class **Tower** used in the game.
- There should only be one tower that can fire missiles.
- There should be some kind of "cooldown" to fire missiles.
For example, there may be a limitation of one (1) second before a missile can be fired again.
Thus, it may happen that the player chooses to fire a missile,
but nothing happens because the tower "cools down".
- There must be a property abstract base class **Projectile** from which projectile types inherit.
- There must be a proprietary class **Missile** that inherits from **Projectile** and is used in the game.
- When the player presses the left mouse button, the tower should fire a missile to the position of the mouse in the window.
- Missiles are visual projectiles that travel in a straight line to their destination.
- When a missile reaches its destination, it should "disappear". However, it is okay (and recommended)
to "reuse" the missile again instead of de-allocating and creating new ones.
- When a missile reaches its destination, all meteorites within a smaller radius should also be destroyed.
- There must be a characteristic class **Meteorite** that inherits from **Projectile** and is used in the game.
- Metorits should travel from the sky down to the ground in a straight line. The line that meteorites travel
should have random direction to the ground. So they shouldn't just fall "straight down".
- When a meteorite reaches the ground, it should "disappear" and the player loses one of their remaining lives.
Like missiles, it is okay (and recommended) to "reuse" meteorites instead of de-allocating and creating new ones.
- There should be a visual difference between different objects drawn in the game.
- It should be clear to tell the difference between turrets, missiles and meteorites.
- The graphics don't have to be "pretty". It's ok to use simple shapes and colors to draw the game.
- There are no requirements for "animations". Thus, the tower does not have to "aim", but can be a
fixed square at the bottom of the window.
- There should be an array/container where all pointers (of the same base class type) for missiles and
projectiles should be collected.
- All missiles and projects should be allocated on the heap, and pointers to these objects should
be mixed in a single array/container.
- It is allowed to use a container from the standard library for this, such as 'std::vector'.
- Polymorphism should be used in some form.
- The player starts with three (3) lives. The game continues until the player has 0 lives and loses,
i.e. when three different meteories have reached the ground. The player's task is thus to destroy meteorites
before they reach the ground to continue playing. The player's remaining life should be visualized in some way,
for example by drawing three symbols or a number in the corner of the window.
- The game can be started immediately the program starts. When the game is over, the player should be
presented with the text "Game Over" followed by the program can be terminated.
**Extra choice for higher grades:**
-**Menu**
- Should be presented to the player when the program starts, and returned to when the game is over.
- There should be no limit to how many times the game can be launched from the menu and returned back.
So recursion is **not** ok here.
- There should *at least* be two choices for the player to choose from in the menu: start the game and exit.
- **More towers**
- There should be three (3) towers instead of one (1).
- When the player chooses to fire a missile, it should be fired from the nearest turret (to the destination)
that is not on "cooldown". If all the turrets are on "cooling", no missile can be fired.
- **Game rounds**
- Instead of a continuous game that only ends when the player loses, there should be "game rounds".
- During a game round, a definite number of meteorites should be created.
- The player wins a game round when all meteorites in that round are destroyed.
- There should be some clear indication that a new round of play is being started,
such as a certain text in the window.
- The number of meteorites should increase with each game round. For example,
the first round may contain five (5) meteorites, the second round ten (10) meteorites,
the third round fifteen (15) meteorites, etc.
- **Highscores**
- The player should accumulate some kind of points during their gameplay. For example, the player can
get points based on playing time, or the number of meteorites that the player destroys.
- During playing time, the player should always see their current score. For example, the score
can be drawn as a number in one of the corners of the window.
- Up to five (5) highest score scores should be stored to one file between program runs.
The points in the file should be stored in order.
- When the game is over, the player's score should be compared to the previous highest score results in
the saved file, and entered into the file if the current score is part of the five highest score results.
This may mean that if there are already five (5) results since before, the current score should
overwrite one of these.
- When the game is over, the resulting points should be presented to the player, as well as the
updated list of the five (5) highest scores.
- It is allowed, but not required, for the player to write his name for his score.
**What the report should contain**
- The report must be cleanly written in either Swedish or English. Cleanly written means that you
should read through and fix language and spelling errors.
- Feel free to use programs like Microsoft Word or Google Docs to help you with this.
There is no strict limit on the number of words in the report, but the following points should be included:
1. What grade you aspire to with what you implemented.
2. A class diagram that shows an overview of your classes in the program.
- Class names and relationships should be presented.
- Important functions and variables in classes should be presented. You don't need to view all
functions and variables in classes. Examples of important features can be 'Update' or 'Draw'.
3. Explain how you met the requirements for the grade you are striving for.
- Your motivation should clearly state that you meet all the criteria for the grade.
4. Argue the pros and cons of your implementation.
- What have you learned along the way?
- What would you have done differently if you were to redo the project today?
## Tips
- Create an abstract base class 'SceneObject' from which all game objects inherit, such as towers and projectiles.
- This makes it possible to manage any scene object with polymorphism. For example, this class
can have the (pure) virtual functions 'Update' and 'Draw' (from 'sf::Drawable') that any
scene object can choose to overshadow.
- Note that there is a criterion that says all projectiles should be stored in the same array/container,
and this meets the criterion. There is nothing to prevent more types of scene objects from being in the
same collection. :)
- Create a container class 'Scene' that manages stores all scene objects.
- This makes it easier to manage all scene objects. For example, the scene may have a function
'Update' which itself iterates and calls 'Update' for all scene objects.
DescriptionIn this final assignment, the students will demonstrate their ability to apply two ma
Path finding involves finding a path from A to B. Typically we want the path to have certain properties,such as being the shortest or to avoid going t
Develop a program to emulate a purchase transaction at a retail store. Thisprogram will have two classes, a LineItem class and a Transaction class. Th
1 Project 1 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of
1 Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of