Add structure to the READMEs

exercises/13/create_function/README.md

@@ -7,7 +7,7 @@ In this exercise we will write some helper functions for the game board.
 The file [`Board.cpp`](../../../lib/Board.cpp) defines functions to manipulate the game Board, for example finding where
 the walls and the portals are.
 
-## Board.cpp
+## Background: Board.cpp
 
 The Board itself is represented in memory as a 2 dimensional array. A cell in this grid can be for example walkable, a
 wall, a pellet, a super pellet or a portal.

exercises/15/build_files/README.md

@@ -4,7 +4,7 @@
 
 In this exercise we will add a couple of files to the project.
 
-## CMake
+## Background: CMake
 
 As described in the slides, the project is defined by several CMake files. The ones we are interested
 is [`CMakeLists.txt`](../../../CMakeLists.txt) in the root project folder and

exercises/15/unit_test/README.md

@@ -2,7 +2,7 @@
 
 # Exercise: Create and run a unit test
 
-## Board Unit Tests
+## Background: Board Unit Tests
 
 The game board is covered by unit tests. They are located in the `testBoard.cpp` file within the `test` directory. They
 don't check every single tile on the board, but they do assume that the board shape is not changed significantly. If you

exercises/16/unique_ptr_pacman/README.md

@@ -2,6 +2,8 @@
 
 # Exercise: std::unique_ptr<PacMan>
 
+## Background:
+
 (corentin: maybe something about } that destroys things)
 We are going to play with using std::unique_ptr as we discussed in the slides. Since we will be reverting these changes
 back, do take a copy of the GameState files before we start. We will change PacMan within GameState into a std::
@@ -9,3 +11,7 @@ unique_ptr<PacMan>, once this has been done the code will not compile, because t
 the GameState class. Go through and figure out what needs to be updated. Can we change one of the ghosts into a std::
 unique_ptr? Are there any current design problems we will run into? What do these design issues say about ownership of
 data?
+
+## Exercise
+
+1.

exercises/17/create_class/README.md

@@ -2,6 +2,12 @@
 
 # Exercise: Simple class
 
+## Background:
+
 4. Create an empty class named `Clyde` within the `.hpp` file. Look at other ghost `.hpp` files and see how they define
    the class. It does not need to inherit from the `Ghost` base class and it does not need any functions. But if you
    have extra time, try to inherit from the Ghost class and see what happens when you try to compile.
+
+## Exercise
+
+1.

exercises/17/make_ghost/README.md

@@ -2,6 +2,8 @@
 
 # Exercise: Add Clyde as a Ghost
 
+## Background:
+
 We have three ghosts within the project. Blinky, Inky and Pinky. But Clyde is missing. Implement Clyde and their
 behavior.
 
@@ -9,3 +11,7 @@ Clyde always chases PacMan so the only thing you should need is where PacMan is
 the scatter behavior as the other ghosts.
 
 Where are the graphics for Clyde in the assets file and how can we make sure the ghost will be correctly rendered?
+
+## Exercise
+
+1.

exercises/17/refactor_out_ghost_state/README.md

@@ -4,7 +4,7 @@
 
 In this exercise we will create a class that abstracts away common functionality.
 
-## Visibility
+## Background: Visibility
 
 The main difference between `class` and `struct` is the default visibility. All members of a struct are publicly
 accessible by default. A class on the other hand is private by default, so some sort of `public:` access is needed to
@@ -12,7 +12,7 @@ give users access to things like constructors and functions.
 
 Everything can be made private in a C++ class, even constructors.
 
-## Default behavior
+## Background: Default behavior
 
 If possible, we want to rely on the default behavior of the member variables of a class. This simplifies the design of
 your class and reduces the things you need to worry about.
@@ -39,7 +39,7 @@ When someone wants to create an instance of `GridPosition`, they need to give th
 could set them to 0, but they still need to be given. Trying to create an instance of `GridPosition` with no values
 given will not compile.
 
-## Game State
+## Background: Game State
 
 `GameState` is a class that holds the instances of all the game objects (ghosts, pacman, pellets, etc). Roughly every 16
 milliseconds the `step()` function inside of `GameState` will be called.

exercises/21/is_intersection/README.md

@@ -2,6 +2,12 @@
 
 # Exercise: Create isIntersection function
 
+## Background:
+
 waage: Maybe the "isIntersection" for the AI. Create an array of GridPosition and array of bool and loop through to
 check "isWalkableForPacMan" and then return the different kinds of intersections (top/right, right/bottom, bottom/left,
-left/top)
+left/top)
+
+## Exercise
+
+1.

exercises/23/algorithm_pellets/README.md

@@ -4,6 +4,10 @@
 
 Use algorithms in Pellet and SuperPellet
 
-# Pellet
+## Background: Pellet
 
-Turn algorithm into raw loop, make students use algorithms.
+Turn algorithm into raw loop, make students use algorithms.
+
+## Exercise
+
+1.

exercises/24/lambda-fy/README.md

@@ -2,4 +2,10 @@
 
 # Exercise: Refactor into Local Lambda
 
+## Background:
+
 Find a small function and turn it into a lambda.
+
+## Exercise
+
+1.

exercises/25/pacman_bot/README.md

@@ -2,6 +2,8 @@
 
 # Exercise: PacMan Bot
 
+## Background:
+
 PacMan can be controlled with the keyboard, but those inputs can be automated. The only thing that needs to change is
 the value within the InputState class.
 
@@ -9,3 +11,7 @@ Start by giving InputState random values on each update and then program in a fi
 Right for 3 seconds, then down, right, up, right". This should pickup the first super pellet.
 
 In this exercise, the input code in processEvents is not needed.
+
+## Exercise
+
+1.

exercises/advanced/blue_pellet/README.md

@@ -2,4 +2,10 @@
 
 # Exercise: Blue Pellet
 
+## Background:
+
 A pellet that makes the ghosts stop
+
+## Exercise
+
+1.

exercises/advanced/game_over/README.md

@@ -2,6 +2,8 @@
 
 # Exercise: Game Over
 
+## Background:
+
 In this exercise you will add a game over state to the game. After PacMan has lost all of his lives the game will be
 over. PacMan should not respawn and the ghosts should stop.
 
@@ -10,3 +12,7 @@ indicate the game over state itself.
 
 If the game is over, the text "Game Over" should be drawn over the game board. You do not need to implement a new game,
 for this exercise restarting the application is enough.
+
+## Exercise
+
+1.

exercises/advanced/generic_teleporting/README.md

@@ -2,9 +2,15 @@
 
 # Exercise: Generic Teleporting
 
+## Background:
+
 In the game and the exercise above, the teleports are linked to each other. These systems are not very generic. Update
 the teleporting system so that two teleport doors are linked with each other.
 
 For example so you can enter a teleport from somewhere on the bottom row and exit from somewhere on the right column.
 
 You do not need to allow for many teleports like this, only 2 doors.
+
+## Exercise
+
+1.

exercises/advanced/high_score/README.md

@@ -2,4 +2,8 @@
 
 # Exercise: Read and Write High Score to a file
 
-(std::filesystem)
+## Background: std::filesystem
+
+## Exercise
+
+1.

exercises/advanced/hitbox_collision/README.md

@@ -2,4 +2,8 @@
 
 # Exercise: Hitbox collision
 
-AABB
+## Background: AABB
+
+## Exercise
+
+1.

exercises/advanced/increased_ghost_speed/README.md

@@ -2,6 +2,8 @@
 
 # Exercise: Increased Ghost Speed
 
+## Background:
+
 Currently the ghosts move at a fixed rate. But in the original game, the ghosts would move slightly faster and faster as
 the game went on.
 
@@ -13,3 +15,7 @@ You could increase the speed after each time the ghost is eaten for example, or
 after N seconds.
 
 Also ask yourself, how would you test this?
+
+## Exercise
+
+1.

exercises/advanced/multiple_generic_teleporters/README.md

@@ -2,6 +2,12 @@
 
 # Exercise: Multiple Generic Teleporters
 
+## Background:
+
 Continuation from above. Take the generic teleporting system you made and allow for more than 1 set of doors.
 
 You might want to look into coloring/tinting each pair a certain color so the player will know what door leads to where.
+
+## Exercise
+
+1.

exercises/advanced/new_level/README.md

@@ -2,8 +2,14 @@
 
 # Exercise: New Level
 
+## Background:
+
 In this exercise you will need to reset the game board but keep score and lives the same. This should happen when PacMan
 eats the last pellet or super pellet.
 
 The ghosts and pacman should go back to their original position and all of the pellets should respawn. This can go on
 forever, but you can look at the next exercise for more information.
+
+## Exercise
+
+1.

exercises/advanced/vertical_teleport/README.md

@@ -2,6 +2,12 @@
 
 # Exercise: Vertical Teleport
 
+## Background:
+
 The teleporters are programmed to work only on the horizontal axis. Change the board to add teleporters at the top and
 bottom row. This also requires a code change when teleporting happens. These new teleporters only need to function like
 the existing teleporters and you do not need to add more than one on each row.
+
+## Exercise
+
+1.

exercises/advanced/victory/README.md

@@ -2,6 +2,8 @@
 
 # Exercise: Victory Screen
 
+## Background:
+
 As a continuation of the Game Over and New Level exercises. If PacMan beats 3 levels, the game has been beaten and a
 victory screen should be shown.
 
@@ -9,3 +11,7 @@ A count of how many levels have been beaten needs to be stored and this should b
 levels.
 
 This should function similarly to the Game Over state but used to indicate that the player won the game.
+
+## Exercise
+
+1.