Which is more efficient? (Nested versus not nested rules)

Twayne2Twayne2 Member, PRO Posts: 458

Is it more efficient for the system to check for nested rules in the else section of an over-arching rule, or to look for another rule in the do section of the over-arching rule? Or even to look for nested rules in the else section of a nested rule in the do section of the over-arching rule?

For instance:

If I press fire,

do:

  • if global attribute is 1,
    do: X

  • if global attribute is 2,
    do: Y.

OR

do:

  • if global attribute is 1,
    do: X

else:

  • if global attribute is 2,
    do: Y.

Another option is

If I press fire,
If global attribute is 1,

do:
X

else:

If global attribute is 2,

do:
Y.

So you can have an over-arching rule with an else, a rule with nested rules, or a rule with nested rules with some rules nested in the else section of the first rule. Or, a fourth option is that you can have a never-ending chain of rules, "if global attribute is 1, do X, else, (new rule), if global attribute is 2, do Y. (- still going gives>>>), else, (new rule), if global attribute is 3, do Z, else, (new rule)...

There are probably even be more ways of nesting rules. Are they all equally efficient? The system reads top to bottom right? So does it matter? (Sorry, I probably was confusing... How do you all take screenshots of the rules section in GS? It looks neat in the forum when talking about stuff. Do you all crop a full-screen screenshot? Or do Macs have the option to choose a screenshot area?).

Comments

  • bob loblawbob loblaw Member, PRO Posts: 525
    edited March 4

    depends what you want to do i guess.eg.
    if you’re just asking if a variable = a specific value, a bunch of if/then statements work, and in the design of gs for editing, are probably easier to go through.

    if/else if functions are probably a slight bit more technical but cleaner if you’re looking at values in a range, but you need to make sure you nest in the right order.

    eg:

    three separate if/then rules with 2 conditions:

    if a>=1 and a < 5 then....
    if a >=5 and a< 20 then....
    if a >= 20

    could be nested, and i think better done as:

    if a >= 20 then....
    else if a >= 5 then....
    else if a >=1 then.....

    the nested logic is cleaner, but would need to be ordered properly to work right. in the example above, if the logic was flipped to start with if a>=1, then if a=20, behaviour would be activated for the first rule that meets the condition (a>=1) instead of for a>=20.

    bottom line, if you can use less logic to get he same result, it’s better.

  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,926
    edited March 5

    Any time you ask a compiler to evaluate an expression, it's going to take a little bit of time.

    So coding:

    If A then ___
    If B then ___

    (2 expressions) is going to take a little longer than:

    If A then ___
    Else ___

    (1 expression)

    But coding:

    If A then ___
    Else if B then ___

    is still evaluating two expressions if A is true.

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • ArmellineArmelline Member, PRO Posts: 4,916

    @tatiang said:
    But coding:

    If A then ___
    Else if B then ___

    is still evaluating two expressions.

    Wouldn't that only evaluate 2 if it isn't A? If it's A, it doesn't look into the else, surely? So it would still be better than two separate, non-nested rules.

    At least that's what I always presumed, though only @adent42 will know for sure how GS actually evaluates things.

  • bob loblawbob loblaw Member, PRO Posts: 525

    less code/logic means less space/smaller file.

  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,926

    @Armelline said:

    @tatiang said:
    But coding:

    If A then ___
    Else if B then ___

    is still evaluating two expressions.

    Wouldn't that only evaluate 2 if it isn't A? If it's A, it doesn't look into the else, surely? So it would still be better than two separate, non-nested rules.

    At least that's what I always presumed, though only @adent42 will know for sure how GS actually evaluates things.

    Sorry, yes. I double- and triple-checked what I had written but should have quadruple checked! =P

    I was trying to make the point that the "else if B" would still need to be evaluated if A is true. I went back and edited that post just now.

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • Twayne2Twayne2 Member, PRO Posts: 458
    edited March 7

    @bob loblaw said:
    less code/logic means less space/smaller file.

    Would nesting be less logic?

    Okay, it looks like nesting is a little more effecient. Thanks for all your imputs everyone! :smiley:

    Now, is it bad for a lot of timers to be going simultaneously? Not set to go off at the same time though? Or would one timer nested into the next, so once one triggers the next begins, be better? For instance, since a game I am working on has waves of troops, is it bad to have timers all going for "after 4 seconds", "after 10 seconds", and so on, or should it be "after 4 seconds, after 6 seconds, after so on seconds, (subtracting all previous timers). Sounds much better. And now it is clear to me, it is. One timer at a time, triggering once another has finished.

  • bob loblawbob loblaw Member, PRO Posts: 525
    edited March 7

    @Twayne2 it’ll depend on what you’re doing, like i showed in my example in my first post. it’s only a small example, that will make an unnoticeable difference, but as you start making larger projects, less space used helps.

    in your project, if you can make it work with one timer, it’ll be more efficient.

  • Twayne2Twayne2 Member, PRO Posts: 458

    Yeah, it kind-of doesn't seem to be much different... except with timers. Having one at a time would clearly make the system have less work to do. Alrighty then.

Sign In or Register to comment.