How are rules evaluated?

icemacsea

I am frustrated with the lack of info on how rules get evaluated. Here's my first question:

1) Are rules evaluated in the order that they appear in the editing window?

This would only seem logical and I hope it's the case, but if it is, then:

2) Is a rule that is placed in the behavior section of another rule evaluated only if the outer-most rule's condition is met?

It seems to me that even when a rule is nested like that, it executes if it flips from false to true -- regardless of whether or not the outer condition is valid. If this is so, I don't know why you can put rules in the behavior section of another rule. You get the impression that the second rule is dependent on the outcome of the evaluation of the first rule, but it's not. Am I missing something here? Thanks for any clarification that anyone can offer.

tatiang

1) yes.
2) yes.

If you have an example of something that you think should be working but isn't, post the rules and we can explain further.

icemacsea

OK, this is a simple file with 2 actors. I'm using the touchDelay method (from the EscapeThisRoom template) to keep more than one "touch event" rule from firing off at a time.

The first actor just has one rule (not shown here) that senses when touchDelay goes from false to true, causing it to set a timer for 0.5 seconds. When the timer goes off, it resets the rule back to false.

So in my second actor we have these two rules. Both handle the touch event and both check touchDelay. touchDelay must be false for either of the rules to fire.

If the first rule fires, it sets the rule1Done attribute to true and does the same to touchDelay. It also writes a Debug message to the window, saying basically, I fired.

If the second rule fires, it checks the rule1Done attribute. If true, it writes a message saying that it fired. If false, it writes a message saying it did not fire.

What I would expect is for the first rule to fire when I touch the actor and then when I touch it again, for the second rule to fire. If I take out the rule within a rule (and just test for all three events/attributes up front) that is exactly what happens. But with this rule within a rule structure, only the otherwise portion of rule 2 fires. Ever. This makes me think that the second rule is getting evaluated first in this case. ???????? Thanks for your help!

tatiang

Can you send me a link to download your project file? It's a little complicated to think through without seeing it.

gyroscope

Hi @icemacsea you've created two rules with one difference (a boolean called self.ruleID) but with two different ways of programming; both relevant on their own but not together.

So to explain more: the first and second rules: when touch is pressed and when game.touch... is false are common to both; so is the boolean attribute self.ruleID common except one is when false and one is when true.

Therefore "boil down" the double set of touch is pressed and when game.touch into one rule, nest the boolean in another rule, and use the otherwise section of that for the opposite condition.

Important point to make here: it seems that you have the attribute game.touchDelay true for both when self.ruleID is true or false... I guess that's a mistake.

Rule: When touch is pressed AND when game.touch... is false
Rule(nested): When self.ruleID is true
Change Attribute game.touchDelay to true
Otherwise
Change Attribute game.touchDelay to false

Because there are a few other "variations on a theme" with the above rules/behaviours depending on what you are wanting to achieve, it might not be exactly what you're after; although it's safe to say the rules/behviours of my straightforward example above are "watertight" and will function properly; so at the least hopefully it'll help clear your mind about programming logic.

icemacsea

I don't know how to embed a link, but the file is at:

http://icemacsea.com/Rules.gameproj.zip

Thanks for your help, gyroscope. I have read your response but will have to come back later and ponder it more deeply (I have to go out soon). In my reading of the whole touchDelay principle, the only place you ever want to set it to false is in the actor that sets the timer. The idea is to prevent a "cascading effect" where one rule is fires as a result of a touch event and consequently changes the game state in some way, which subsequently causes another rule to fire (which also handles the touch event), when what you really wanted was only the first rule to fire as a result of the first touch, then on the second touch, you want that other rule to fire ...

I don't pretend to understand exactly why it's necessary to use a timer to prevent this, but I have found that the timer method works well. At least until I start nesting rules inside of rules, then all bets seem to be off! Thanks, people!

tatiang

Maybe I'm just dense today but I hope I'm getting this...

Is a good example of this a three-state button (say a counter)? So if counter=1 and touch is pressed, change counter to 2; if counter=2 and touch is pressed, change counter to 3. And you're wanting to prevent a single touch from changing counter from 1 to 3?

tatiang

If so, here's how I would set it up.

icemacsea

Thanks, tatiang! I like your method much better than the timer method used in the EscapeThisRoom template. I never understood why a timer was used there, but it worked, so I just stayed with it.

Of course, the example file I posted was a big simplification of what I was really trying to do, and I won't get into that here, but with your method, I am unable to replicate my nested rule problem. It may have had something to do with that timer, I don't know.

Thanks again!

tatiang

You're welcome! Glad it works for you.