Apply suggestions from code review

Spell Pac-Man properly

Co-authored-by: ll-nick <[email protected]>

demo/README.md

@@ -27,5 +27,5 @@ For a smooth out-of-the-box experience, we recommend using [Visual Studio Code](
 - Enjoy a full-blown IDE with code-completion, code-navigation etc.
   - Compile via `Ctrl+Shift+B`
   - View, run and debug unit tests via [Testing](https://code.visualstudio.com/docs/editor/testing) sidebar
-  - Debug the PacMan Demo via [Run and Debug](https://code.visualstudio.com/docs/editor/debugging) sidebar
+  - Debug the Pac-Man Demo via [Run and Debug](https://code.visualstudio.com/docs/editor/debugging) sidebar
   - Debug with breakpoints etc.

docs/Tutorial.md

@@ -1,6 +1,6 @@
 # Arbitration Graphs Tutorial
 
-Let's write an agent for the famous PacMan game using Arbitration Graphs 🕹️
+Let's write an agent for the famous Pac-Man game using Arbitration Graphs 🕹️
 
 **TL;DR:** Find links to the individual tasks at the bottom of this page.
 
@@ -10,7 +10,7 @@ Let's write an agent for the famous PacMan game using Arbitration Graphs 🕹️
 ### Goal
 
 The goal of this tutorial is to help you understand how to use the Arbitration Graphs library.
-To keep things interesting, we will re-implement some parts of our PacMan demo.
+To keep things interesting, we will re-implement some parts of our Pac-Man demo.
 
 We'll start by looking into the implementation of a single behavior component
   and then learn how to integrate it into an arbitration graph using a simple priority arbitrator.
@@ -48,7 +48,7 @@ Enjoy a full-blown IDE with code-completion, code-navigation etc.
 - Explore the repo in the Explorer sidebar
 - Compile via `Ctrl+Shift+B`
 - View, run and debug unit tests via [Testing](https://code.visualstudio.com/docs/editor/testing) sidebar
-- Debug the PacMan Demo via [Run and Debug](https://code.visualstudio.com/docs/editor/debugging) sidebar
+- Debug the Pac-Man Demo via [Run and Debug](https://code.visualstudio.com/docs/editor/debugging) sidebar
 - Debug with breakpoints etc.
 
 </details>
@@ -111,7 +111,7 @@ Each behavior component is implemented in a separate `<name>_behavior.hpp` file
 
 Next, there is `environment_model.hpp`.
 You guessed it, it contains the environment model for the arbitration graph.
-In it, we store things like current positions of PacMan and the ghosts, the maze, several utility functions
+In it, we store things like current positions of Pac-Man and the ghosts, the maze, several utility functions
   and other things required by the behavior components.
 
 The `cost_estimator.hpp` file will be relevant for a later task when we cover [cost arbitrators](./tasks/5_cost_arbitration.md).

docs/tasks/1_implement_behavior_component.md

@@ -13,12 +13,12 @@ Before we start building our arbitration graph, we want to take a closer look in
 Don't worry, most of the behavior components are already implemented for you
   but we want to make sure you have an idea of how they work.
 
-With the current state of the arbitration graph, PacMan will just move around and eat dots until a ghost gets too close.
+With the current state of the arbitration graph, Pac-Man will just move around and eat dots until a ghost gets too close.
 That's great and all but if we ate a power pellet, we want to take advantage and chase the ghosts to eat them for extra points!
 
 To do this, we need to implement the `ChaseGhost` behavior component.
 It essentially does the exact opposite of the `AvoidGhost` behavior component
-  but is only applicable when PacMan ate a power pellet.
+  but is only applicable when Pac-Man ate a power pellet.
 We can ensure that's always the case using the behavior's invocation condition.
 
 But wait - the current implementation of the invocation condition is not complete.
@@ -33,7 +33,7 @@ Finish the implementation of the `checkInvocationCondition()` and `getCommand()`
 
 ## Instructions
 
-- Build and run the game, take a look at the arbitration graph and observe how PacMan behaves.
+- Build and run the game, take a look at the arbitration graph and observe how Pac-Man behaves.
 - Run the unit tests and note that the `ChaseGhost` `scheckInvocationConditionFalse` test is failing
 - Open the implementation of the `ChaseGhost` behavior component in `src/chase_ghost_behavior.cpp`.
 - The `checkInvocationCondition()` function is already implemented but does not check for the presence of a ghost.

docs/tasks/2_extend_arbitration_graph.md

@@ -27,7 +27,7 @@ Integrate the `ChaseGhost` behavior component into the arbitration graph defined
 - Add the `ChaseGhost` behavior component as a new member of the `PacmanAgent` class and initialize it in the constructor.
 - Extend the `PacmanAgent` parameter struct to include the parameters for the `ChaseGhost` behavior component.
 - Add a new option to the priority arbitrator.
-- Run the game, take a look at the new arbitration graph and observe how PacMan behaves.
+- Run the game, take a look at the new arbitration graph and observe how Pac-Man behaves.
 
 ## Solution
 

docs/tasks/4_nested_arbitrators.md

@@ -13,7 +13,7 @@ We have now implemented a few behavior components and integrated them into the a
 So far, all behavior components are children of the root arbitrator.
 
 Let's make things a bit more interesting by adding a long-term behavior component that's also about eating dots.
-The `ChangeDotCluster` behavior will move to an area in the maze where there is a higher density of dots.
+The `ChangeDotCluster` behavior will move Pac-man to an area in the maze where there is a higher density of dots.
 
 For now, we'll just decide between the two dot eating strategies using chance.
 We can achieve that by adding them to a random arbitrator which is then added as an option to the root arbitrator.
@@ -30,7 +30,7 @@ Add the `EatClosestDot` and `ChangeDotCluster` behavior components to a random a
 - Add a random arbitrator as a new member of the `PacmanAgent` class, analogous to the priority arbitrator.
 - Add the `EatClosestDot` and `ChangeDotCluster` behavior components as options to the random arbitrator.
 - Add the random arbitrator as an option to the root arbitrator.
-- Run the game and observe how PacMan behaves.
+- Run the game and observe how Pac-Man behaves.
 
 ## Solution
 

docs/tasks/6_verification.md

@@ -9,12 +9,12 @@ Execute only safe commands and add a fallback strategy.
 
 ## Context
 
-The arbitration graph is now complete and PacMan is eating dots like a pro.
+The arbitration graph is now complete and Pac-Man is eating dots like a pro.
 But there is one last topic we want to talk about: **safety and robustness**.
 
 Depending on your application, you might only want to execute commands that you know meet certain criteria. 
 The specific requirements will depend on your application and could be anything from physical constraints to safety requirements.
-In our case, we only want to execute commands where PacMan does not run into walls.
+In our case, we only want to execute commands where Pac-Man does not run into walls.
 
 We can ensure that commands obey these requirements by adding a verifier to the arbitrators.
 The arbitrator will then run the **verification step** and only choose commands that pass this step.
@@ -39,9 +39,9 @@ We can mark a behavior component as last resort fallback layer in order to exclu
 After all, it's our last straw and it's better to execute that than to do nothing.
 
 In our case, we will add a `StayInPlace` behavior component.
-PacMan is not actually able to stop, so he will just keep moving back and forth.
+Pac-Man is not actually able to stop, so he will just keep moving back and forth.
 Probably not an ideal strategy to win the game, but we can be sure to have a comprehensible command at all times.
-Also, PacMan will never run into a wall with this behavior component.
+Also, Pac-Man will never run into a wall with this behavior component.
 
 Phew, that was long read. Time to get our hands dirty!