[Good first issue]: Add different options for colouring game graphics by player

[edwardchalstrey1]

Currently edges and nodes in draw_tree are black by default, but there is also a "gambit" colour scheme. There are a couple of ideas I have for improving upon this:

• 1) Ensure the "gambit" colour scheme scales for many players, or alternatively throw an error saying that colour scheme only supports games with up to 6 players for games with >6 players
• 2) Add a 3rd colour scheme for "distinctipy" which makes use of this package to choose a set of n unique/distinct colours for players (or use some other custom method to get unique colours)
• Feel free to add as many colour schemes options as you like

See the get_player_color function.

[Srinath0916]

Hi @edwardchalstrey1 , I'm interested in Project 3 for GSoC and would like to tackle this issue. I've already explored the get_player_color function and plan to integrate distinctipy to handle $N$-player color scaling.

[edwardchalstrey1]

Hi @Srinath0916 thanks for your comment. We encourage you to apply to GSoC following the guidance here (if you didn't already). We are planning to use some "good first issues" to evaluate applicants alongside their applications. Students interested in Project 3 from our list may be instructed to take a look at this. If you submit an application with an interest in another project(s) from the list, we may direct you to different issues.

[Manik-Khajuria-5]

Hello @edwardchalstrey1 @tturocy

I was encountering an issue while generating a PNG file from the CLI, even after installing the required dependencies:

Ghostscript (provides gs command)

Despite having all the necessary tools installed, the PNG file was not being generated.After debugging the code, I identified the root cause. The issue was not related to Arch Linux or missing dependencies. The problem was that the code attempted to convert a temporary file path that was never actually written. As a result, the conversion command was being executed on a non-existent PDF file.The issue has now been resolved by updating the logic to use the actual PDF path returned by the generate_pdf() function instead of the unused temporary path. Please let me know if you would like me to share the specific code changes for review.

---

---