add a skeleton for the FSM, the basic architecture.

[PurpleProg]

Finite State Machine

Summary

This PR add the base of the Finite State Machine
It's just a draft, so we can discuss how to implement that essential feature, which need to be scalable and clear (i mean understandable, readable). This is an exemple of how we could use classes as states.

Related Issues

related to #83, the state manager

✅ Checklist:

• 🛠️ I have tested my code, and it works as expected (e.g., game runs without errors).
• 📝 I have made sure that the code follows the project's formatting and style guidelines.
• 💬 Code is commented (if applicable)

[PurpleProg]

Also, i think the codebase is somewhat messy, maybe we could remove CLI and rename GUI to game or something generic like that. There is so much stuff everywhere for such a few lines of codes (1000 line of python out of 3500 lines of random markdown and stuff). A general structure clean up could be usefull. For exemple font and images could be inside data.
And the current GUI class (could become the state manager) is currently a dataclass, but dataclasses are, well, for data, for instances that are ment to be compared to each other, like items but not a main game loop. idk it just feel weird to have a dataclass here, a normal class would look cleaner and more readable to me.

I am sorry if that looks... picky ? annoying ? I'm trying to be constructive but it's not easy lol. And that's just my opinion, i might be totally wrong.

[ultimateownsz]

Also, i think the codebase is somewhat messy, maybe we could remove CLI and rename GUI to game or something generic like that. There is so much stuff everywhere for such a few lines of codes (1000 line of python out of 3500 lines of random markdown and stuff). A general structure clean up could be usefull. For exemple font and images could be inside data. And the current GUI class (could become the state manager) is currently a dataclass, but dataclasses are, well, for data, for instances that are ment to be compared to each other, like items but not a main game loop. idk it just feel weird to have a dataclass here, a normal class would look cleaner and more readable to me.

What would be your suggestion to rename it? First it was py_version and pygame so that's why I'm confused. A better structure is a good idea. Data classes look to me more readable, but I think it's more a preference, I think we can refactor it to a normal class, because pygame doesn't support data classes out of the box and could give us more problems later on.

I am sorry if that looks... picky ? annoying ? I'm trying to be constructive but it's not easy lol. And that's just my opinion, i might be totally wrong.

I value your opinion! This is good constructive feedback!

[ultimateownsz]

Finite State Machine

Summary

This PR add the base of the Finite State Machine It's just a draft, so we can discuss how to implement that essential feature, which need to be scalable and clear (i mean understandable, readable). This is an exemple of how we could use classes as states.

Related Issues

related to #83, the state manager

✅ Checklist:

* [x]  🛠️ I have tested my code, and it works as expected (e.g., game runs without errors).

* [x]  📝 I have made sure that the code follows the project's formatting and style guidelines.

* [x]  💬 Code is commented (if applicable)

Hmm, yes, I was first thinking of a simple enum state machine class, and later work on other iterations. Perhaps it's best to see what works best, and try out different results! Perhaps a combination of enums or what you proposed is a good idea.

This is what I just found just now how we could integrate a more game dev approach to it, with this library: https://github.com/benmoran56/esper

[PurpleProg]

a combination of the two seem good, as we might encapsulate the game logic (like player turns and all) inside the gamerunning state, and use something like that.

[ultimateownsz]

a combination of the two seem good, as we might encapsulate the game logic (like player turns and all) inside the gamerunning state, and use something like that.

Do you want to work on this or do you suggest we work together on different solutions?

[ultimateownsz]

Will this class handle just the game states or run the whole game?

[PurpleProg]

that one is just the state of the game during gameplay, so not the whole game, the whole game would be ran by the currently named GUI class.

[PurpleProg]

a combination of the two seem good, as we might encapsulate the game logic (like player turns and all) inside the gamerunning state, and use something like that.

Do you want to work on this or do you suggest we work together on different solutions?

I would like to work on that yes, but if you wanna try something else let me know.

[ultimateownsz]

You have my permission to work on that, you have permissions to assign yourself to that task in github projects! @PurpleProg

[PurpleProg]

that way of handling states is pretty much working rn. It should make it easier to add a state, as you can make your own file, the only time you have to change other's work is when you want to add a way of switching to your new state. And as it use a stack, it's cool because it remember the last ones, when you exit a states it's nice and easy to go back to the last one. What do you think about it ?

[ultimateownsz]

I think deleting CLI code just to make the codebase more clear is not the best approach, we could use some code of it perhaps in the pygame code to a certain degree or perhaps work later on the CLI game if it's needed.

Overall your PR looks good, I would still add enums to the code to make it more clear which state you are adding as (new) contributor.

[PurpleProg]

Overall your PR looks good, I would still add enums to the code to make it more clear which state you are adding as (new) contributor.

i don't understand how enums would help here. Could you explain that a bit more pls ?

[ultimateownsz]

• Using enums could allow us to clearly define all possible states in one place. This helps others understand the available states at a glance.
• Since enums provide a fixed set of values, they reduce the likelihood of typos or invalid state transitions.
• State transitions in the FSM become easier to read and debug because the states have meaningful names.
• As the game grows, enums make it straightforward to add new states without affecting other parts of the code significantly.

For example:

from enum import Enum

class GameState(Enum):
    MENU = 1
    PLAYING = 2
    PAUSED = 3
    GAME_OVER = 4

Do you think this could help? Or do you think this could make it harder?

[PurpleProg]

enums are a fixed set of constants. But the current game states are not constants. So what we could do is to set them as integer and just check which state is currently selected, but, we would lose the advantages of using a stack. And i think that would not add anything more that classes, as we can use the state.__class__.__name__ to access the name of the class, so i don't think using enums would be better that classes.

[ultimateownsz]

Hmm, I think your approach sounds better, do what you think works best. I don't have much experience with using it, need to see it in action I suppose.

[PurpleProg]

Hmm, I think your approach sounds better, do what you think works best. I don't have much experience with using it, need to see it in action I suppose.

you can try do write your own state, for example a simple "paused" state with just a simple transparent overlay. And bind buttons to enter and exit your "pause" (the pause state name is already taken but you get the idea)

[ultimateownsz]

Do you need a review on this PR again?

[PurpleProg]

Yes, sure ! I think most of the work is done, the only thing left are the MainMenu state (but that can be done in another PR). So #85 and #84 are pretty much done, and #86 and #87 are almost done. There isn't really debug features, but I think it should be lightweight and modular so yeah. And merging this will allow others to work on their owns states.

[PurpleProg]

in fact i just didn't add any debug features, I will add a few tomorow.