Best Way to Track Progress - "Ready or Not" Flag

[atum]

All,

What is the best, and most efficient, manner that you use for tracking progress.  Within the same ball, it is easy, but after a drain and the next ball starts it gets far more complicated.

I am using defined player variables to track this information and set values.  For example, I would set a value to 0 upon game initiation, and then set it to a value of 1 when completed.  Or I would set a value that flips between 1 and 0 to show if a mode is enabled.  It would have a check for start that it is equal to 1.  So I can flip it back and forth to make it operate only when I want.

##Config where all global varies are defined
player_vars:
    mode_start_ready:
        initial_value: 0
        value_type: int

##Mode where event happens and mode ready flag is set
variable_player:
    EVENT:
        mode_start_ready:
            int: 1
            action: set

##Mode where flag is checked to see if mode should start
mode:
    start_events: mode_start_hit{(current_player.mode_start_ready==1)

Is this a good way of handling this scenario?  Or do others have better/more creative ways of handling these scenarios.

Thanks!

Avery

[jabdoa]

There are certain logic elements to track this. Either state_machines, counters, accruals or sequences. I personally prefer to have a state machine per mode which tracks progress and then embeds other elements such as shots or counters for certain transitions. All those elements can persist their state between balls. Same is true for modes which can restart on the next ball of the same player.

Jan

[atum]

Jan,

I will have to play around with the state_machines a bit.  I get the gist of it, but will have to implement in one place to make sure I get it.  Can you move forward and backward?  The one example doesn't show going backward.  I have where my mode start is active, and then is deactivated when a mode or multiball is active, so I would wan't to revert back to the "off" state.

What I ran into was achievements and other things would lose their state between balls.  I would have it in started status, but then on next ball it would be nowhere.  So I added my code to tell it that yes, its in that state.  Then I can run a check on ball_starting{is my flag true} to put it back into that state.

Is my way going to be more taxing from a computer perspective when I am actually running my game?  Or just different?  I have the entire base of my game done, and am then going to build out my modes, multiballs, wizards, etc.  (about 19 modes).  So I don't want to build it in a way that will bog it down during actually gameplay and then have to fix it on the back end.

Thanks again!

Avery

[jabdoa]

Hi Avery,

State Machines can go any way. It can do almost everything (even though might become ugly at some point). See https://en.wikipedia.org/wiki/Finite-state_machine for details.

Achievements should keep their state. However, when started they will go back to enabled on the next ball by default. If you want to change this settings: http://docs.missionpinball.org/en/dev/config/achievements.html#restart-on-next-ball-when-started.

CPU and memory-wise this should not make any difference unless you build thousands of modes with ten thousands of state machines.

Jan

[atum]

 Jan,

I struggled for a bit to get it all to work, but I got it working.  I think it is a bit easier than what I was doing (certainly easier to keep track of once this things gets crazy full of different modes and tons of code).  Thanks so much!  I had to reference a couple different documents, including the skill shot to really see how to use this.  I have some additions to the help document.

Tomorrow I will create a PR on the help docs to bulk that up for people in the future with some missing details that hung me up.  e.g., the first state has to be called "start" or major errors are thrown.

Thanks for the help as always!

Avery