State machine diagram for "play game 3 times"

[ChrisGNZ]

Hi All

I'm trying to develop my first BGA game, but I may have bitten off more than I can chew The game I have been granted a license for is quick to play so normally you play the game 3 times and accumulate points, and the person with the most points after 3 games wins. Here is my attempt a state diagram for such a scheme:

https://ibb.co/JQqjkyZ

Does this look like a valid approach? Are there any existing games on BGA with a similar multiple-game structure that I could look at the source code and learn from?

Many thanks in advance!

[Tisaac]

Hi All

I'm trying to develop my first BGA game, but I may have bitten off more than I can chew The game I have been granted a license for is quick to play so normally you play the game 3 times and accumulate points, and the person with the most points after 3 games wins. Here is my attempt a state diagram for such a scheme:

https://ibb.co/JQqjkyZ

Does this look like a valid approach? Are there any existing games on BGA with a similar multiple-game structure that I could look at the source code and learn from?

Many thanks in advance!

Sounds good.
Just use a global to know how much game you played out of 3.

[ChrisGNZ]

Thanks for your reply, Tisaac!

Please bear with me as I seek more info from yourself or other forum readers about BGA states.

In my diagram ( https://ibb.co/JQqjkyZ ) I have a single state # 40 called "Player Turn". But within the player's turn are some moves and choices of actions, and so forth. Should I expand the states.inc to cover states and transitions for all the possible actions and moves that a player can make in their turn, or is that not really the purpose of the BGA states?

I guess I have yet to understand how detailed and fine-grained the BGA states should be...

Thanks again!

[RicardoRix]

It all depends. Both can work.

It's quite likely with complicated turns to have a step-by-step set of states. But you don't have to. It could all be handled in the UI maybe with some kind of internal states.

The most important thing to keep in mind, is that the player can press F5 at any time, so you may not want to rewind too much. And is a good robust way to test your code.
You can also use the BGA Undo feature to set the Undo state at the beginning of the players turn.

[Tisaac]

+1 for RicardoRix's answer.

The two extreme are :
1] change of state for each click the user make
2] do everything in the frontend and only send the complete turn to backend (so using just 1 state)

Pro :
1] make a very structured backend. Makes the frontend dumb (ie no logic involved)
2] make it easier to undo since you basically never send anything to back

Cons :
1] undo is a bit harder to program.
2] duplicate logic because you still need to check validity of the moves in backend anyway

[ChrisGNZ]

THanks for your replies, RicardoRix and Tisaac!

Tisaac's last point "duplicate logic because you still need to check validity of the moves in backend anyway" is giving me much pause for thought!

Maybe for that reason, I'll try to model the player-moves that are very clearly a change of state.

Thanks everyone!