Players with the same amount of points are overrided in the Map DS with all the results. Replace it with an alternative that lets save more than one element with the same key or simply replace it with a vector of pairs.

The players don't know what is the start direction (only a point is shown). Add an arrow or distinctive marker to show which is the starting direction.

Use the glm library instead of self defined math classes and functions.
The class Font is actually using glm, but the other are still using the classes Point and Vector.

As an alternative for snap package, the automatic generation of a flatpak (and posterior publication on flathub would be neat.

The information of the players (name, color, etc) is hard coded in main.cpp.
It may be more flexible to directly read from text files (txt, json, yaml) and parse it into variables.

The snap pkg can only be launched from the terminal. Add a new .desktop file with the specifications for the application.

The winner blinks, but it is placed in the original position (assign by the vector insertion in main.cpp) and not depending of the amount of points that the player has.

The Debug and Release builds are equally verbose and it can be annoying for users starting the game through the terminal (once install). A solution could be adding a Macro under a def/ifndef definition to separate them from the rest of the code.

Switch between floating window and full screen when pressing F11

There is a lot of folders and scripts that could be reorganized to establish a better general order.
New folders:

• scripts
• static

Add new font rendering capabilities into the game. Add more fonts, sizes, style (bold, italic, etc) and built in blinking and fading effect (maybe through shaders?)

It is not always possible to play against other Humans!
Add some fellow robots (AI) to play against.

Until now the game cannot be closed. It can be directly closed from window decorators or shortcuts, but there is no implemented way to close the game from the game.

The actual scoring system is inconsistent and not so clear for new players.
New possible scoring system for p players and be m a position between first and last player:

• last player = 0 points
• first player = p - 1 points
  And therefore in general:
• m-th player = p - m points

The max amount of point can stay the same (p * 5, eg: 2 players -> 10 points), but include a system with min. amount of points of difference between 1st and 2nd place (2, maybe?).

The scoring is calculated and updated in player_manager.cpp.

• Calculation -> PlayerManager::update_score()
• Check if the max. amount was obtained -> PlayerManager::check_score()

Having a snap package can make the distribution and install of the game easier

As an alternative to using cmake as an installation method would be neat if there is at least a .deb package for Debian/Ubuntu. It can be created using cmake and cpack.

The AI works (it can take some decisions) but it sucks! It really sucks.
It generates a bottleneck and the fps are going down, really fast.
The planning algorithm can be improve, research some Path Planning Algorithms. The actual algorithms only waits until one of the edge conditions are meet and than take a decision. Maybe a better approach would be to set goals for the AI to reach and then try to reach them (with some tolerance) and then set a new goal. That would generate some sort of human feeling about the decisions that the AI takes. A consequence of that would be, that the game would be turned to something very similar as the Snake Game. This Process could be use to train a Machine Learning Algorithm for the AI.

AppImage is a good packaging alternative to snaps (less controversial).
It would be nice to create it automatically through the CMakeLists.txt, similar to the creation of the DEB package (see #9) and add it in the release files. I don't know if there is some sort of store for AppImages.

The arrow is over the player. It would be nicer if the arrow has some offset with the player (over the direction line).
A blinking effect would also be pretty.

While trying on a virtual machine (Gnome Boxes) running Manjaro, I experienced a really high fps and the game wasn't really playable. Limit the number fps to a max. constant.

The window has a min. size, but it can be even bigger than the display if the user just try it.
Take the size of the primary display (see full screen solution for issue #10) and use it as a max. boundary.