Best practices: Why are switches better to trigger actions?

JackBQuick

I know this may be a dumb question but I've seen rules like this:

If touch is pressed
...Change self.jump attribute to True
Otherwise
...Change self.jump attribute to False

If self.jump attribute is True
...Do this
Otherwise
...Do that

* * * * * * * * * * * * * * * * * * * * * * * * *

Why is the above better than:

If touch is pressed
...Do this
Otherwise
...Do that

* * * * * * * * * * * * * * * * * * * * * * * * *

I've seen this enough times used by people who know what they are doing to know this is the proper way to do things. I just don't know why. Is this an organizing thing? or does it affect the actor's behaviour?

Thanks in advance for you answer.

JohnPapiomitis

The first one allows for more complex actions im pretty sure. Example in my current game i have a bike that animates the wheels to a certain speed wen the pedal button is pressed. then also it animate left and right or forward and reverse depending on which way its rolling and how much momentum it has. On top of that i have trick buttons. If i have when touch is pressed on the trick button it changes image or animates the trick it wont work, because the wheel animations threw expressions override other animations and change image behaviors. But if i have the change image or trick set up the first way, with the wheel animations based on the speed and direction put into the otherwise section, It works perfect. Hope that cleared it up a little.

scitunes

often times the event that triggers the "switch" is not ongoing. For example, if you want a whole bunch of things to happen when touch is pressed, those behaviors will only work while the player's finger is on the screen and will stop when the finger is removed. The only exception to this is when a timer is used with run to completion checked, but timers tend to hurt frame rates. However, if I use a switch like you show above the touch can be pressed for only an instant and that is enough to trigger the boolean attribute. Once the boolean is triggered everything in the second rule can be executed even though the finger is no longer touching the screen.

For whatever reason it also just seems to be more reliable in GS. For example, GS is really bad about collision (IMO). So having a rule that says when overlapping with actor "floor" and when spacebar is pressed change self.linear.velocity.Y to 100 should be a good way to set up jumping rules that stops a double or tripple jump. Problem is, GS doesn't always notice that you are touching the floor and so you will hammer away on the spacebar and nothing happens. But if you have a rule that says when overlaps with floor change self.allowjump to true and then have a rule within your jump rules that switches self.allowjump to false it works 100%.

I am hoping the new update will fix the collision detection issue. We'll see...

JackBQuick

@JohnPapiomitis & @scitunes - Thanks! That explains a lot, actually. I haven't gotten into trouble yet for doing it improperly but it's only a matter of time, I know. I appreciate your descriptions and examples -- it helps me to better understand. Thanks again!

ToastKitten

I just do it for mental organization. It makes thinking out the logic of a situation a lot easier, so long as my booleans are named according to the situation x]

synthesis

Here is a keen way to do this...a bit slicker...

[ DEFAULT VALUES ]
change attribute mySwitchValue = 0
change attribute activateSomething = 0
change attribute DEactivateSomething = 0

When touch is released
...change attribute mySwitchValue = (mySwitchValue+1)%2

When mySwitchValue = 1 >>>
...change attribute activateSomething = 1
...[ do a whole bunch of stuff ]
otherwise
...change attribute DEactivateSomething = 1
...[ do a whole bunch of other stuff ]

When activateSomething = 1 >>>
...[ do this thing once when the switch is activated ]
...change attribute activateSomething = 0 (last line to shut reset the rule)

When DEactivateSomething = 1 >>>
...[ do this thing once when the switch is DEactivated. ]
...change attribute DEactivateSomething = 0 (last line to shut reset the rule)

A WALK THRU:
The above first sets the values to work with as a default.
Then on the press...a switch tree is started...
The first rule is the master switch. The first line is the switch trigger. That algo basically ping pongs the switch back and forth from 0 to 1 on each press.

The remaining rules handle the switch. Then those switch other things and so on. You can make these trees as long or short as you want. But what it does is creates a sequential chain of events that can add a bit of organic logic to your program as well as can enhance the way things work within the game/app. These trees can be your friend. The more you use them...the more you will see their true potential.

JackBQuick

Thanks, synthesis!

I keep forgetting about ping ponging the switch back and forth, e.g. (mySwitchValue+1)%2. It's a quick alternative to setting boolean attributes.