Amazingly Raku - Part 8: The Future

[94.8] Published 9. December 2020.

This part presents my future plans for the module and bundled programs. Some of them are realistic, others not so much...

The numbers refer to issue numbers on the module GitHub page.

[1] Add a difficulty method, by moving the code from «maze-solver-summary». It gives a value that indicates the perceived difficulty of traversing the maze.
[2] Add a method for rotating the maze (90, 180 and 270 degrees). It rotates the cell values, and changes the values. (E.g. rotating '╗' to the right gives '╚'.)
[3] Similarly, a flip method that mirrors the maze horizontally or vertically.

[4] Figure out why letting $m go out of scope terminates the program. (The workaround is calling «new» as $m.new(…) instead of creating a new object with $m = Game::Amazing.new(…).)
[5] Choose a better colour scheme for the current position, user path and the shortest path.

[6] Figure out how to disable cursor movement, or how to set the cursor in the middle of the maze (workaround). The problem is that after we "print" the text to the screen, the cursor remains after the last character insterted (the exit). When the user presses the down or right arrow key, the program gives an annoying beep to indicate that the user tries to move the cursor out of the text. The current workaround is to set the focus on the «Help« button, as that tackles the four arrow keys. Note that the result is that the «Exit» key is highligthed after a left arrow keypress. And pressing Return after that will acrtivate the button and terminate the program.
[7] Add a tunnel vision mode, where the user moves straight ahead (with the space bar), using the arrow keys to make a turn. The maze is always shown with the user facing up, so will be rotated when the user makes a turn. Reuse internal functionality made for 'is-traversable-wall' for this, and make them public.
[8] Choose a better colour scheme for the current position, user path and the shortest path. The colours are better than in «amazing-termbox», but could be better.
[9] Highlight the entrance on program start, and the exit when the user reaches it.

[amazing.gtk - The Editor]

[10] Show the length of the shortest path after each change.
[11] Show the difficulty rating after each change.
[12] Write a help window text for Edit mode.
[13] Rewrite the code highlighting the coverage (when the maze is untraversable). The current implementation does one cell at a time, and is slow - especially on larger mazes (or slower pc's).
[14] Add buttons for the toggle direction functionality. The way it is done in «amazing-termbox» (albeit only for information) is a good starting point.

[15] Generate and distribute mazepacks (collection of maze files), either as downloadable zip-files or online and let the program handle it behind the scenes

[16] Two players, each on their own computer. They start out in their own corner (the entrance or the exit), and the goal is to reach the other corner (exit or entrance) first (before the other player). The path is not shown. The maze is only shown when both users are ready.
Either show the maze the same way for both users, or rotate it (180 degrees) for the second player so that they both start out at the top left corner.
Alt A. Use one game as the master, and the other as client; i.e. direct communication between them, and not via a server.
Alt B. A Server, hosted by me.
Alt C. A server that is part of the module, so the users can run it themselves.

[17] Refuse working with maze files without the «.maze» ending. Some of the programs are lax here.

This text will not be changed. I'll update the issues on GitHub, and add new ones there.

And that's it.