As I was figuring out a good way to properly shut down the game, I found it hard to visualize the code flow. In what order does things happen? And who is responsible for what?
I deliberately chose to use “a good way” instead of “the best way”, as code usually changes through out the project. What you start with isn’t always what ends up in the release version. It’s hard to say this early what is “best”. And “best” is a term which is relative to your project. It doesn’t matter what other say about SOLID principles and design patterns and clean code architecture and whatnot. What works for your game is a good solution.
The code editor in Godot is good enough for day-to-day coding. There is no secret that it lacks the same tools as IDE’s has for static languages. I also use JetBrains Rider, and could hook it up to the project to start inspecting it, now that Rider has support for GDScript. But I found the thought of starting up the program a bit tedious, so I used pen and paper instead.
To visualize the code flow I drew what is called a sequence diagram. It is a type of diagram that is often used to visualize communication between clients and servers. But it is also useful for this case.
This what my code flow looked it:
When the place() function in the GameMode class was being called, it called validate_end_game() on the GameState. Which, after a bit of validation, emitted a ready_to_end signal. This flowed into the GameBoard, which enabled the End Game button.
Upon clicking the End Game button, GameBoard emitted an end_game signal. The Player class picked up the signal and called the end_game function on GameState, which started the actual process of ending and shutting down the game.
This diagram made it clear that the code took a detour from Board to Player, before going back to State. I don’t know what I was thinking when I wrote this. Must have been one of those late night coding sessions. In this case, it didn’t make sense that the Player class should have anything to do with shutting down the game.
The solution was to call GameState.end_game() directly from GameBoard.on_click_end_game. With this solution I could delete some code and simplify the architecture a bit.
This turned out to be a very useful diagram to draw for getting a birds eye view of the code.